深深的感受到“細節決定成敗”，“蝴蝶效應“一句話細節體現工作品質也體現個人能力。今天覆盤迴顧一個個坑哭的小細節，更好的迎接未來挑戰。

1，窺見資料三重門

全域性著眼，登高望遠，窺見資料的三重門：ODS，DW，APP

每一層的存在分管著不同的資料工作，一起探探門裡的細節，把握清晰的脈絡。

ODS層：是關注使用者重點事務的原始業務表，重在離線統計使用者細節的行為日誌表。日誌表可以包含業務表的相關資料，但是缺乏結構，需要ETL。

DW層：將ODS層作為直接的資料來源，去建設滿足業務分析要求的數倉，進行基礎整合BAS，然後開發出事實層/維度層/寬表層。其目的將一大坨資料整合分類，方便快速查詢。

APP層：是我們熟知的應用層，有報表，資料產品，API介面，特徵資料，專題集市，OLAP， 業務系統。

三層形成上下游的環形網路，缺一不可。從而解耦三者的關係實現低耦合高內聚任重道遠。

2，危險的金字塔

三重門可以拆解成一個倒立的金字塔，這個倒立著的金字塔是危險的，總要一種搖搖欲墜的感覺，需要資料攻城獅們殫心竭慮的守護。

因為ODS資料來源：業務表，埋點日誌的採集 兩大源頭，一些細枝末節的變動，牽動ODS基礎層，生產一隻黑蝴蝶，讓DW/APP層來一場雪崩。累慘資料工程師。

業務表和日誌採集：動要有原則：

1，能新增值不要新增列，比如在json型別中加值，不要增加額外的列名。

2，能增加列不要新增一個表。

3，能加一個輔助表，不要重構原有表結構。

4，遵循添值，增列，副表的優先集，提前周知變化，早做應對。

3，動一下就是一萬年

資料開發的工作流程是這樣的。

接到一個數據需求，

第一步，我們要分析需求的合理性，能不能做。

第二步，我們要怎麼做，哪一種方式最合適，安全快速。

第三步，需要哪些資料資源許可權。

第四步，用SQL實現出自己的ETL邏輯程式碼。

第五步，測試自己的邏輯程式碼，看看小單位資料是否合理。

第六步，提交稽核，生產資料（回溯資料很慢）。

其實在大資料量面前，生產資料的過程是漫長的，需要花費很多時間去等待。

第五步的測試極為重要 ，而且需要使用八倍鏡，仔細推薦，認真核對。

比如：統計當日支付要看支付時間不要看下單時間應為下單可以在第二天支付。還有一個小小“=”號讓統計意義南轅北轍。也一定要主要主要表的欄位型別，不要望文生義，id不一定是數字。

第五步一定要多花點時間反覆校驗，不要因為小細節而花大時間回溯資料。

4，藉助工具

用IDE 管理自己的ETL程式碼，方便查詢。

高亮的語法提示也能更好的發現細節。

程式碼一定有做好格式處理，清晰可讀很重要。

多寫wiki，磨練寫作基本功，沉澱常用的資料方法。

工具不要多，兩個就夠了。

資料倉的經典模型

碼字不易，如果您覺得文章寫得不錯，

請您 1.關注作者，您的關注是我寫作的最大動力

我將與您分享一套最新的大資料學習資源和全套開發工具