這個blog用來積累設計資料倉庫需要考慮的一些問題：
1、 源系統資料調研
也就是所謂的源系統資料，需要怎麼調研，調研一些什麼呢？
目前認為需要確認業務的流程（其實就是業務流程對應的後臺表的關係）， 因為應用系統流程變更，最好設定業務流程的文件維護業務知識，作為知識積累

2、在第三正規化建模和維度建模之間的選擇
目前主流的建模方式是維度建模，三正規化建模，實體建模等，這裡建議在ods層上新增第三正規化建模，結合維度建模形成資料集市。

3、資料模型設計中的取捨
資料模型設計過程中需要考慮的因素很多，很多時候設計的過程是一個取捨的過程。基本不可能滿足各個特性指標的最優化。在過程中需要重點考慮以下三點：

1. 擴充套件性：資料模型的穩定性是指相對的穩定性，是指在源系統、業務邏輯變化的時候，能通過少的成本快速擴充套件模型。第三正規化資料倉庫建模方法遷採用豎表方法來滿足模型的擴充套件性，缺帶來了效率上的一定問題。維度模型方法在資料粒度不發生變化的時候，需要通過修改表結構，擴充套件欄位方法，做模型應對業務的擴充套件，相對更復雜些。結合GP表新增欄位困難的現實，平臺要求所有要求寬表預留欄位方法，來保證後續的擴充套件。另外目前的平臺中存在的缺點是，源系統新增欄位，會引發資料倉庫中多個層次的表需要修改，成本較大，後續需要提供一些公用的工具方法進行改進。
2. 效能：效能是ETL的效率和儲存空間的平衡，同時一些體系化和擴充套件性的改進也會對單個的ETL效能有一定的犧牲。資料平臺在IDL層採用了簡單的映象方法，犧牲儲存獲取ETL效率的優化和邏輯上的簡化。但是一定要杜絕過度使用這種方法，而且必須要有對應的資料生命週期制度，清除無用的歷史資料。
3. 體系化：體系要求模型在符合業務視角，使用者能夠方便的從模型中準確找到對應的資料項，並能方便讀取。同時，資料倉庫又是強調整合過程。資料平臺在寬表設計中強調高內聚、低耦合的理念，在物理實現中，將業務關係大，源系統影響差異小的進行整合；業務關係小，源系統影響差異大的進行分而置之。

4、實施方法

軟體工程實踐普遍提到的方法有瀑布法和迭代法，什麼方法是實施阿里資料平臺建設。資料平臺國際站和中文站分別採用了這兩種方法。阿里巴巴資料倉庫的現實是業務在前面跑、平臺的建設如果採用瀑布法，必須要有更快的速度，趕超業務變化搭建。所以應當採用集中所有優勢兵力，集中攻破的方法。而迭代的方法，需要保持人員在相對穩定的情況，理念統一、堅持，通過不斷的改進來是做實施，實施週期較長，影響較小，可以及時做適當的調整

參考：https://www.cnblogs.com/davidwang456/articles/9024021.html

資料平臺的建設思想：
第一個是對重複的事情，這一個平臺團隊做精做專，而且重複的事情只做一次，減少投入。
另外統一化，可以推一些標準，推一些資料管理的模式，減少業務之間的對接成本，這是平臺的一大價值。
最重要的是為業務整體效率負責，包括開發效率、迭代效率、維護運維資料流程的效率，還有整個資源利用的效率，這都是要讓業務團隊對業務團隊負責的。無論我們推什麼事情，第一時間其實站在業務的角度要考慮他們的業務成本。