走過2010年，回首走過的一年，全部精力投入到了數據平臺的建設過程中，在不斷的探索、嘗試中探索一條適合數據倉庫發展之路的數據模型建設方法；作爲數據平臺建設的主要驅動人，與團隊一起完成數據平臺基礎數據模型（寬表層）的搭建，應用遷移、實現應用項目在新的數據模型上實施。在建設的過程中，有過困惑、走過彎路，但獲得了對模型設計方法和理念的體會與沉澱。因此，我更多想對在數據平臺建設工作中的歷程、困惑、體會做一個梳理與總結。
一、 源系統數據調研
阿里數據倉庫普遍採用的建設方法是應用驅動型，源系統的業務邏輯知識散落在各個ETL開發與PD的頭腦中，缺乏總整體上對源系統的一個全面瞭解。全面的數據調研工作對後續數據倉庫模型中的設計具有非常重大的指導作用，在數據的取捨、數據整合策略、指標計算方法等方面對非常重要。數據平臺小組成立開始，第一項開展的工作就是對源系統的數據調研工作，調研過程中，我採用的方法和手段有：
1) 在源系統變更系統中查找表結構基本描述
2)confluence上搜索相關設計文檔
3) 向源系統的開發人員進行詢問
4) 自己操作現有源系統並輔助數據探查工作獲取源系統的數據業務邏輯與知識
這是一個相當耗費資源的工作，而且更大的挑戰在於源系統不斷地快速更新。當時數據平臺前期投入的全部精力對源系統調研，做了一個初步的瞭解。目前，對與源系統更新這塊，數據平臺在維護ODL源系統的模型文檔，數據平臺必須保證源系統變化後的業務知識體系維護在ODL模型中，這才能保持知識的不斷沉澱。
二、 在第三範式建模和維度建模之間的選擇
數據平臺在建設之初，團隊多來自傳統行業，經驗也來自於傳統行業經驗，缺乏對數據模型不能行業的建設經驗。數據平臺期望採用EDW的建設建模思想，建立一個相對穩定的基礎數據模型，但是當我們在採用這種設計理念在設計中，碰到的問題是，始終無法回答的問題是新的模型相對已有的數據模型，如何能在使用便捷性，效率方面有明顯的改善。
EDW強調從源系統的業務與數據出發，在企業全局高度進行業務對象抽象，建立企業級數據倉庫系統，使其能包容不同源系統的具體業務對象實例。它在物理化模型的方法，採用大量窄的豎表、數據對象類型標識方法來實現抽象的對象和屬性。這樣的做法帶來的好處是其擴展能力優越，數據視角統一；但是，它會丟失一些源系統的業務含義、必須藉助良好的元數據、碼錶解釋來完善數據的業務含義，它也會引發一個性能問題，因爲上層應用可能需要大量的多表關聯，豎轉橫操作。
數據平臺內部經過多次討論和實踐之後，基本捨棄了這種建設思路與理念。阿里巴巴源系統與傳統行業的源系統相比，具有鮮明的特點：變化極其迅速、數據倉庫應用要求快速響應，平均數據生命週期不長。在阿里巴巴實施EDW，成本巨大，滿足不了業務目標。
維度建模強調從數據倉庫應用角度出發，以空間換時間、採用星形數據模型、適當雪花化的處理手段建立數據倉庫應用模型；它強調採用一致的維度來保證各個模型數據統計的一致性。
目前阿里巴巴數據倉庫IDL層普遍採用了維度建模的思想，我們俗稱的寬表也是維度建模思想的一個物理化方法。關於事實表，在kimball維度建模理論中就定義了事實表有三種類型：“We compare thethree fundamental types of fact tables: transaction, periodic snapshot, andaccumulating snapshot.”。事務型事實表（transaction）的典型代表就是我的瀏覽寬表；週期性快照（periodic snapshot）事實表的典型代表就是會員、offer靜態信息表；而累計型快照的典型代表就是會員寬表中的各種行爲統計表。
目前我們還需要改進的是：
1) 加強對統一維度的整合，我們存在不同的地區、類目維度等，造成統計不統一。
2) 根據業務發展持續改進和優化現有寬表的物理實現
3) 加強模型的業務指標含義的統一與完善
三、 數據模型設計中的取捨
數據模型設計過程中需要考慮的因素很多，很多時候設計的過程是一個取捨的過程。基本不可能滿足各個特性指標的最優化。在過程中需要重點考慮以下三點：
1) 擴展性：數據模型的穩定性是指相對的穩定性，是指在源系統、業務邏輯變化的時候，能通過少的成本快速擴展模型。第三範式數據倉庫建模方法遷採用豎表方法來滿足模型的擴展性，缺帶來了效率上的一定問題。維度模型方法在數據粒度不發生變化的時候，需要通過修改表結構，擴展字段方法，做模型應對業務的擴展，相對更復雜些。結合GP表添加字段困難的現實，平臺要求所有要求寬表預留字段方法，來保證後續的擴展。另外目前的平臺中存在的缺點是，源系統添加字段，會引發數據倉庫中多個層次的表需要修改，成本較大，後續需要提供一些公用的工具方法進行改進。
2) 效能：效能是ETL的效率和存儲空間的平衡，同時一些體系化和擴展性的改進也會對單個的ETL效能有一定的犧牲。數據平臺在IDL層採用了簡單的鏡像方法，犧牲存儲獲取ETL效率的優化和邏輯上的簡化。但是一定要杜絕過度使用這種方法，而且必須要有對應的數據生命週期制度，清除無用的歷史數據。
3) 體系化：體系要求模型在符合業務視角，用戶能夠方便的從模型中準確找到對應的數據項，並能方便讀取。同時，數據倉庫又是強調整合過程。數據平臺在寬表設計中強調高內聚、低耦合的理念，在物理實現中，將業務關係大，源系統影響差異小的進行整合；業務關係小，源系統影響差異大的進行分而置之。
四、 團隊、協同、合作
數據平臺成立之初的工作，曾被認爲：“幾個人在進行神祕的工作”。數據平臺化工作絕對不能閉門造成，一定要重發發動源系統、應用層的力量，貼近實際業務情況進行設計。阿里巴巴業務發展的變化，容不得我們花費一年半載，輸出一個結果。
五、 實施方法
軟件工程實踐普遍提到的方法有瀑布法和迭代法，什麼方法是實施阿里數據平臺建設。數據平臺國際站和中文站分別採用了這兩種方法。阿里巴巴數據倉庫的現實是業務在前面跑、平臺的建設如果採用瀑布法，必須要有更快的速度，趕超業務變化搭建。所以應當採用集中所有優勢兵力，集中攻破的方法。而迭代的方法，需要保持人員在相對穩定的情況，理念統一、堅持，通過不斷的改進來是做實施，實施週期較長，影響較小，可以及時做適當的調整。