模式1：屬於通用型強的廣泛收集資料，但是會造成很多冗餘和不合理。後期可支援的需求種類會寬泛很多，但是整體專案工程的進度會慢，專案返工的機率很高。目前的主要的應用場景現在只有一種，或正在摸索式中。
模式2：根據需求設計資料針對性強很多，能夠快速的梳理出依據需求得出資料支援關係。按照需求搭建資料產出速度很會很快，當然最終的資料結果可能僅適用case by case的解決問題。
兩種模式其實無論好壞，不同職責的部門可能距離業務需求的遠近不同，無權選擇採用的哪種模式解決問題。但是最終成熟的資料倉儲產品是符合兩種模式的優點的，這就需要兩種模式在不斷優化迭代中逐步完成。
如何分別不同的兩種模式，我們可以從實際的場景中看看兩種模式的反應情況，以便於遇到的時候能注意到利弊。
模式1：常見的實際場景
我們都知道並認同abc資料很重要，但是怎麼分析和使用沒有具體的方案。
例如，我們要分析業務的訂單資料，我們要將訂單資料納入到資料倉儲中。至於支援哪些維度和指標，分析師們以後會怎麼用資料。我們並不清楚。這個是典型的模式1。我很難判斷資料的重要優先順序，也很難合理設定出滿足今後需求的資料表結果。因此，我們只能依賴偏技術性的資料倉儲知識去做管理和維護。將業務庫的訂單資料全部拿過來，將訂單的系統日誌全部拿過來，將埋點的訂單資料全部拿過來。有什麼拿什麼過來形成最底層的ods層資料就好。幾百幾千的原始資料表資料被灌入到資料倉儲。
這個過程中我們是對資料不加任何多餘考慮的。既然不知道是否有不需要的資料，為了保障完整性全部拿來。也不會知道資料有什麼缺失，反正具體的需求是什麼我們也不知道。
拿來資料是比較方便的，ods層資料的只要苦力加個班幾天時間就可以將大量的資料灌入資料倉儲。接下來的一步就會非常困難，怎麼分類整理搭建輕度彙總層，將資料加工出彙總的明細資料。這個過程對於研發工程師最大的考驗是熟悉業務（熟悉業務和資料的「對映」關係）。訂單都包含什麼資訊，訂單的建立到消費經歷什麼環節，有多少環節，對應的狀態和引數是什麼？資料之間的關聯關係是一對一，一對多，多對多？訂單對應幾個使用者資訊，訂單資訊會被更改退嗎？
當任何不熟悉業務的資料工程師想要在ods層的基礎上去搭建上層資料的時候，都會陷入複雜的業務知識和邏輯中。我所經歷的類似工作內容中，能夠一次性搞定這塊資料倉儲搭建的至今成功案例非常少，除非公司業務簡單，老員工占多數，不然真是浩劫（當然解決辦法也有很多，這個以後再聊更深入點）。所以，如果遇見類似的場景要做2個判斷，a、業務的複雜度。b、有沒有老員工扛大旗。如果不符合這兩個條件，專案盡早認慫或者換思路解決問題。
模式2：常見的實際場景
我們現在有乙個資料需求，想看a頁面帶來的訂單轉化資料效果。表頭是日期、城市、模組（頁面整體、頁面子模組）、訂單數，訂單人數，支付訂單數、支付異常訂單數、支付金額，利潤金額。
根據需求去搭建資料倉儲就簡單很多，因為需求明確，所以首要任務是以需求為導向設計方案，在上述提到的資料表頭中我們很容易推斷出資料倉儲各層應該放什麼樣的內容。尤其是對於應用層、資料彙總層的設計，在為了僅滿足乙個需求的前提下是很容易給出方案的。那麼接下來的重點主要在於搞清楚業務資料中是否有我們需要的字段，我們從**抽資料即可（輕度彙總層的資料明細層，主要是對拿過來的ods層資料進行加工一輪，以便於符合資料倉儲標準和規範，因此這層的設計可有可無也不難處理）。
以上兩種模式在實際工作中，前者需要後期不斷實際需求的提出才能逐步摸清資料給出更好而方案。後者會在新一輪又一輪的資料需求提出過程中發現前期的方案不足慢慢自我優化迭代。
數倉理論知識
為什麼分層 1 清洗資料結構 每乙個資料分層都哦於他的作用域和職責，在使用表的時候能更方便定位和理解 2 統一開發 減少重複開發 規範資料分層，開發一些通用的中間層資料，能夠減少極大的重複計算 3 統一資料口徑 通過資料分層，提供統一的資料出口，統一對外輸出的資料口徑 4 複雜問題簡單化 將乙個複雜...
數倉建模 分層建設理論 03
簡單點兒，直接ods dm就可以了，將所有資料同步過來，然後直接開發些應用層的報表，這是最簡單的了 當dm層的內容多了以後，想要重用，就會再拆分乙個公共層出來，變成3層架構,這個過程有點類似 重構，就是在實踐中不斷的進行抽象 總結 數倉的建模或者分層，其實都是為了更好的去組織 管理 維護資料,所以當...
數倉的分層
一 數倉為什麼要分層？1 分層解耦，可以讓開發思路更加清晰，複雜問題簡單化 出錯時，可以精確定位資料 2 節省重複開發 3 脫敏 二 數倉的分層 以5層數倉為例 ods層 原始資料層，原始資料原封不動的直接匯入！dwd層 基於ods層，將原始資料進行清洗，篩選後的資料，把其中的明細開啟 例如 啟動日...