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

1，窺見數(shù)據(jù)三重門

全局著眼，登高望遠，窺見數(shù)據(jù)的三重門：ODS，DW，APP

每一層的存在分管著不同的數(shù)據(jù)工作，一起探探門里的細節(jié)，把握清晰的脈絡。

ODS層：是關注用戶重點事務的原始業(yè)務表，重在離線統(tǒng)計用戶細節(jié)的行為日志表。日志表可以包含業(yè)務表的相關數(shù)據(jù)，但是缺乏結構，需要ETL。

DW層：將ODS層作為直接的數(shù)據(jù)源，去建設滿足業(yè)務分析要求的數(shù)倉，進行基礎整合BAS，然后開發(fā)出事實層/維度層/寬表層。其目的將一大坨數(shù)據(jù)整合分類，方便快速查詢。

APP層：是我們熟知的應用層，有報表，數(shù)據(jù)產(chǎn)品，API接口，特征數(shù)據(jù)，專題集市，OLAP， 業(yè)務系統(tǒng)。

三層形成上下游的環(huán)形網(wǎng)絡，缺一不可。從而解耦三者的關系實現(xiàn)低耦合高內聚任重道遠。

2，危險的金字塔

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

因為ODS數(shù)據(jù)源：業(yè)務表，埋點日志的采集 兩大源頭，一些細枝末節(jié)的變動，牽動ODS基礎層，生產(chǎn)一只黑蝴蝶，讓DW/APP層來一場雪崩。累慘數(shù)據(jù)工程師。

業(yè)務表和日志采集：動要有原則：

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

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

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

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

3，動一下就是一萬年

數(shù)據(jù)開發(fā)的工作流程是這樣的。

接到一個數(shù)據(jù)需求，

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

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

第三步，需要哪些數(shù)據(jù)資源權限。

第四步，用SQL實現(xiàn)出自己的ETL邏輯代碼。

第五步，測試自己的邏輯代碼，看看小單位數(shù)據(jù)是否合理。

第六步，提交審核，生產(chǎn)數(shù)據(jù)（回溯數(shù)據(jù)很慢）。

其實在大數(shù)據(jù)量面前，生產(chǎn)數(shù)據(jù)的過程是漫長的，需要花費很多時間去等待。

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

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

第五步一定要多花點時間反復校驗，不要因為小細節(jié)而花大時間回溯數(shù)據(jù)。

4，借助工具

用IDE 管理自己的ETL代碼，方便查找。

高亮的語法提示也能更好的發(fā)現(xiàn)細節(jié)。

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

多寫wiki，磨練寫作基本功，沉淀常用的數(shù)據(jù)方法。

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

數(shù)據(jù)倉的經(jīng)典模型

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

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

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

3.私信我“大數(shù)據(jù)”

我將與您分享一套最新的大數(shù)據(jù)學習資源和全套開發(fā)工具

推薦閱讀：合肥汽車網(wǎng)