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

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

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

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

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

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

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

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

2，危險的金字塔

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

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

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

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

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

3，能加一個輔助表，不要重構(gòu)原有表結(jié)構(gòu)。

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

3，動一下就是一萬年

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

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

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

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

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

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

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

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

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

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

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

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

4，借助工具

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

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

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

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

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

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

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

請您 1.關(guān)注作者，您的關(guān)注是我寫作的最大動力

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

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

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

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