213
品《阿裏巴巴大數據實踐-大數據之路》一書(下)
今天繼續談阿裏的這本書，包括數據服務平台、數據挖掘平台、數據建模、數據管理及數據應用，希望於你有啟示。
1、數據服務平台
數據服務平台可以叫數據開放平台，數據部門產出海量數據，如何能方便高效地開放出去，是我們一直要解決的難題，在沒有數據服務的年代，阿裏的數據開放的方式簡單、粗暴，一般是直接將數據導出給對方，我想，現在大多公司的開放應該也是如此吧，雖然PaaS喊了這麼多年，但真正成就的又有幾個？
即使如阿裏，在數據開放這個方向上的探索和實踐，至今也有7個年頭了，任何關於數據開放畢其功於一役的做法都將失敗，任何一次數據開放的改進都是伴隨著對於業務理解的深入而成長起來的。
阿裏的數據開放經曆四個階段，DWSOA、OpenAPI、SmartDQ和OneService：
DWSOA：是數據服務的第一個階段，也就是將業務方對數據的需求通過SOA服務的方式暴露出去，由需求驅動，一個需求開發一個或者幾個接口，編寫接口文檔，開放給業務方調用。
這種架構簡單，但接口粒度很粗，靈活性不高，擴展性差，複用率低，隨著業務需求的增加，接口的數量大幅增加，維護成本高企，同時，開發效率不高，一個接口從需求開發到上線，按阿裏說法至少1天，其實遠遠不止，如果要變更1-2個字段，也要走一整套流程，這應是大多數公司的常態。
OpenAPI：DWSOA的明顯問題是煙囪式開發，很難沉澱共性數據，OpenAPI將數據按照統計粒度進行聚合，同樣維度的數據，形成一張邏輯表，采用同樣的接口描述，針對某一類的查詢，隻需要調用一個接口即成，這種形式可以有效收斂接口，筆者公司對外服務很多也是這種形式，比如通過封裝幾十個位置服務API，統一對外提供靈活查詢能力，但其實複雜邏輯的接口還是需要采用一事一議的方式，即第一種方式。
SmartDQ：數據維度是非可控的，隨著數據的深度使用，OpenAPI顯然會急劇增加，維護映射的壓力會很大，阿裏於是再抽象一層，用DSL（Domain Specific Language,領域專用語言）來描述取數需求，支撐標準的SQL，至此，所有的簡單查詢服務減少到另一個接口，這降低了數據服務的維護成本。
傳統的方式查問題需要查源碼，確認邏輯，而SmartDQ隻需要檢查SQL的工作量，並可以開放給業務方通過寫SQL的方式對外提供服務，SmartDQ封裝了跨域數據源和分布式查詢功能，通過邏輯表屏蔽了底層的物理表細節，不管是HBASE還是MySQL，是單表還是分庫分表，這極大簡化了操作的複雜度。
其實中國移動經營分析規範很早就提出了即席查詢、偽代碼等的封裝方式，筆者企業也通過自助取數的方式在實踐，阿裏在落地上做的比較好，其是集大成者，傳統企業的大數據類產品往往隻能在單點實現突破，無法用一隻團隊始終如一的堅持做一個產品，比如企業的自助取數平台在設計時沒想到需要支撐大數據時代的跨異構數據庫，由於當初的自助取數團隊和當前的DACP的團隊完全是兩撥人，很難實現既有能力的傳承。
阿裏的思路說不上很超前，但它不僅落地了，而且在不停演進，這也許就是企業自主研發的價值，它的產品始終流著同樣的血液。
OneService：SQL顯然無法解決複雜的業務邏輯，SmartDQ其實隻能滿足簡單的查詢服務需求，正如我們的自助取數也僅能滿足50-60%的臨時取數一樣，企業遇到的場景還有以下幾類：個性化的垂直業務場景、實時數據推送服務、定時任務服務，OneService主要是提供多種服務類型來滿足客戶需求，分別是OneService-SmartDQ、OneService-Lego、OneService-iPush、OneService-uTiming。
Lego被設計成一個麵向中度和高度定製化數據查詢需求，支持插件機製的服務容器，筆者理解就是提供定製環境和暴露接口，你要怎麼做就怎麼做。
iPush應用產品是一個麵向TT、MetaQ等不同消息源，通過定製過濾規則，向Web、無線等終端推送消息的中間件平台。
Utiming是基於在雲端的任務調度應用，提供批量數據處理服務，支撐用戶識別、用戶畫像、人群圈選三類服務的離線計算以及服務數據預處理、入庫，這個感覺是非常個性化的一個應用。
2、數據挖掘
阿裏構建了一套架構於阿裏雲MaxConpute、GPU等計算集群之上，匯聚了阿裏大量優質的分布式算法，包括數據處理、特征工程、機器學習算法、文本算法等，可高效完成海量、億級維度數據的複雜計算，同時提供一套極易操作的可視化編輯頁麵，大大降低了數據挖掘的門檻，提高了建模效率。
其選擇的計算框架是MPI，其核心算法都是基於阿裏雲的MaxCompute的MPI實現的。
其算法平台也集成了絕大部分業界主流的機器學習算法。
讓筆者有點吃驚的是阿裏還搞了數據挖掘中台，這個筆者以前也想做過，但後來發現跟數據倉庫的融合模型（比如寬表）有很多類似之處，因此沒堅持下去。
阿裏將數據中台分為三層：特征層（FDM）、中間層和應用層（ADM）,其中中間層包括個體中間層（IDM）和關係中間層（RDM），如下圖所示：
FDM層：用於存儲在模型訓練常用的特征指標，這個跟融合模型的寬表類似，筆者很好奇阿裏的數據倉庫的DWS僅僅是匯聚層還是包括了寬表，否則跟這個FDM是有很大雷同的。
IDM層：個體挖掘指標中間層，麵向個體挖掘場景，用於存儲通用性強的結果數據，其實在筆者看來就是通用標簽庫的源表，那個ADM就是個性標簽的源表，不知道有沒理解對。
數據挖掘這一章很短，缺乏一些細節，想來跟部門的定位有關，數據挖掘一般應用導向，核心的東西大多可能掌握在各類業務部門的挖掘師手中，筆者對於數據挖掘中台的實際價值還是有疑問的，畢竟挖掘千變萬化，數據倉庫建模好理解，但數據挖掘搞中台如何能跟得上變化？
3、數據模型
數據建模在這本書占據了三分之一篇幅，可見其重要性，首先談談阿裏數據模型的曆史吧，其實跟筆者還有很多淵源，因為2005-2007年間為公司服務的某合作夥伴大量BI人員跳槽到了阿裏，據說構建了阿裏的一代數據倉庫係統，這些人員很多跟筆者共事過，現在讀來，還是有點感慨。
（1） 曆史發展
第一階段：完全應用驅動的時代，數據完全以滿足報表需求為目的，將數據以與源結構相同的方式同步到Oracle，這跟筆者當年剛進公司的情況類似。
第二階段：隨著阿裏業務的快速發展，數據量飛速增長，性能成為一個較大問題，需要通過一些模型技術改變煙囪式的開發模型，消除數據冗餘，提升數據一致性，來自傳統行業的數據倉庫工程師開始嚐試架構工程領域比較流行的ER模型+維度模型方式應用到阿裏巴巴集團，構建出一個四層的模型架構，即ODL（數據操作層）+BDL（基礎數據層）+IDL（接口數據層）+ADL（應用數據層）。ODL與源係統一致，BDL希望引入ER模型，加強數據的整合，構建一致的基礎數據模型，IDL基於維度模型方法構建集市層，ADL完成應用的個性化和基於展現需求的數據組裝，這個對應筆者所在企業的當前的ODS，DWD，DWA/DWI及ST層，但阿裏在構建ER時碰到了較大的挑戰，主要是業務快速發展，人員快速變化、業務知識功底的不夠全麵，導致ER模型產出困難。
阿裏得出了一個結論：在不太成熟、快速變化的業務層麵，構建ER模型的風險很大，不太適合去構建ER模型，說的有點道理，比如運營商業務相對比較穩定，國際上也有一些最佳實踐，從概念-領域-邏輯-物理的全局把控上還能應對，但麵對變化，的確有其限製。
第三個階段：阿裏業務和數據飛速發展，迎來了hadoop為代表的分部署存儲計算的快速發展，同時阿裏自主研發的分布式計算平台MaxCompute也在進行，因此開始建設自己的第三代模型架構，其選擇了以Kimball的維度建模為核心理念的模型方法論，同時進行了一定的升級和擴展，構建了阿裏巴巴集團的公共層模型數據架構體係。
阿裏模型分為三層：操作數據層（ODS）、公共維度模型層（CDM）和應用數據層（ADS），模型層包括明細數據層（DWD）和匯總數據層（DWS）。
ODS：把操作係統數據幾乎無處理的存放到數據倉庫係統中。
CDM：又細分為DWD和DWS，分別是明細數據層和匯總數據層，采用維度模型方法作為理論基礎，更多采用一些維度退化方法，將維度退化至事實表中，減少事實表和維表的關聯，提高明細數據表的易用性，同時在匯總數據層，加強指標的維度退化，采取更多的寬表化手段構建公共指標數據層，提升公共指標的複用性。
ADS：存放數據產品個性化的統計指標數據，根據CDM與ODS加工生成。
具體見如下模型架構圖：
關於模型的分層每個行業都可以基於自己的實際去劃分，沒有所謂的最佳實踐，比如筆者所在的企業，源端維度一致性非常好，DWD主要做標準化工作，屏蔽ODS變化導致的上層改動，關於維度建模的理念更多體現在DWA/DWI層中。
（2） 模型實施
OneData是阿裏的模型設計理論，我覺得寫得很好，你看完這個過程，基本會搞清楚維度建模的各個步驟，強烈建議結合後麵的維度和事實表建模進行精讀，主要步驟如下：
數據調研：業務調研需要對業務係統的業務進行了解，需求分析則是收集分析師運營人員對數據或者報表的需求，報表需求實際是最現實的建模需求的基礎。
架構設計：分為數據域劃分和構建總線矩陣，數據域劃分是指麵向業務分析，將業務過程或者維度進行抽象的集合，業務過程可以概括為一個個不可拆分的行為事件，如下單、支付等。構建總線矩陣需要明確每個數據域下遊哪些業務過程，業務過程與哪些維度相關，並定義每個數據域下的業務過程和維度。
規範定義：規範定義主要定義指標體係，包括原子指標、修飾詞、時間周期和派生指標，關於指標的規範定義阿裏有單獨的一節描述，大家可以好好學習一下，很多時候細節決定成敗。
模型設計：模型設計主要包括維度及屬性的規範定義、維表、明細事實表和匯總事實表的模型設計。
最後，用一張圖鎮樓，這張圖可值回書價哦。
本書後麵用兩大節來介紹維度設計和事實表設計，由於過於細節，筆者就不再展開了，如果你是建模人員，一定要好好看看，也可以參考《數據倉庫工具箱-維度建模權威指南》這本書，一般在建模過程中你碰到的很多問題它都有解決策略，你未來可能碰到的建模問題，這本書也提及了很多，是建模人員的寶貴的實戰參考材料。
4、數據管理
數據管理涉及的東西很多，這本書具體提到了元數據、計算管理、存儲和成本管理和數據質量，相對內容比較單薄，我挑兩點說一下：
一直聽說阿裏財大氣粗，所有數據都永久保留，其實是謬傳，人家也是節約過日子的，看下圖你就知道了：
應對層出不窮的數據和應用，數據工程師其實很難確認哪些數據是最重要的，需要優先保障，阿裏巴巴提出了數據資產等級的方案，旨在解決消費場景知曉的問題，其將數據劃分為五個等級，毀滅性質、全局性質、局部性質、一般性質及未知性質，代號從A1到A5。
那麼如何個每份資產打上等級標簽呢，就是借助強大的元數據能力，了解哪些表服務於哪些數據產品，基於血緣分析可以講整個消費鏈路上打上某一類資產的標簽，假如將阿裏巴巴生意參謀定位等級A2,則所有相關鏈路的表的等級都是A2，從而啟動對應的保障措施,這個跟筆者企業的大數據保障方法類似，從應用重要程度確定表的保障等級。
5、數據應用
阿裏主要介紹了對外的數據產品平台生意參謀和服務於內部的數據產品平台。
生意參謀本質上就是為自己的渠道提供的增值服務，是很成功的一款決策支持產品，體現了一個產品如何從小做起，逐步長成一個龐然大物的過程：
對內數據產品的演進幾乎是每一個公司BI係統的發展翻版，但顯然它已經長成大樹了，從臨時取數階段，到自動化報表階段（比如BIEE），再到自主研發BI階段（第三方滿足不了自己了），最後到數據產品平台（更加體係化）。
當前阿裏的數據產品平台，包括PC和APP版本，共有四個層次，即數據監控、專題分析、應用分析及數據決策。
到這裏，基本就讀完了，整本書都是經驗之談，讀下來閃光頻現，建議可以多讀幾遍。
這本書也引發了筆者一些思考，為什麼他們能做成？我們傳統企業大數據的差距在哪裏？是機製流程問題？數據產品的傳承問題？合作夥伴的問題？核心能力自控問題？業務對於數據產品的驅動力問題？小步快跑落地問題？企業產品的規劃問題？
有些遺憾的是，這本書更多是就技術談技術，鮮有數據內容方麵的深度闡述，跟直接的價值創造還有距離，比如標簽庫的管理，核心算法研究，DMP怎麼做的等等，當然這個可能跟阿裏的大數據管理組織分工有關係，也涉及企業的一些商業秘密。
其實要想了解的東西還有很多，包括機製流程，團隊分工，部門協同，中台戰略在大數據的落地等等，希望有機會學習。
期盼有更多的企業能分享他們在大數據方麵的實踐經驗，這對提升國內整體大數據管理水平很重要。
品《阿裏巴巴大數據實踐-大數據之路》一書（上）
最後更新：2017-08-21 11:32:34