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

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.關注作者，您的關注是我寫作的最大動力

2.留下你寶貴的評論，哪怕一個字都行！

3.私信我“大數據”

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

本文為企業推廣，本網站不做任何建議，僅提供參考，作為信息展示！

推薦閱讀：小米旗艦機