921
品《阿裏巴巴大數據實踐-大數據之路》一書（上）
7月有人推薦阿裏巴巴剛出的這本書《阿裏巴巴大數據實踐-大數據之路》，到亞馬遜一看才是預售狀態，拍下直到8月才拿到。
翻看目錄一看，歡喜的很，正好出差兩天就帶在身邊，由於在機場滯留超過12個小時，就把它讀完了。
用“品”字有以下幾個原因，一是市麵上充斥著太多的大數據平台技術的書，諸如hadoop，spark等占據了大部，但對於如何管好大數據卻缺乏真知灼見，二是這本書的確幹貨很多，誠意實足，明顯來自阿裏實操人員的經驗，從作者是阿裏巴巴數據技術與產品部就可知道，三是內容跟筆者的專業相符，裏麵提到的任何一方麵筆者都有實操或管理經驗，想來自己有資格去品評這本書，最後，阿裏巴巴的數據量在那裏，其大數據平台曆經考驗，突然透露一些技術秘密，對於任何有誌於搞大數據的企業或個人，都應該去學習一下。
因此用“品”，不能像看一般的書那樣一目十行，要能發現裏麵的先進理念，結合企業或自身的實際看到差距，從中找到可以借鑒的地方，指導後續的大數據工作。
大數據博大精深，正如這本書也是集體創作一樣，受限筆者的水平，讀書筆記也隻能浮光掠影的走一遭，如果你覺得有啟示，可以去買一本，自己來品一品。
首先是一張鎮樓圖，阿裏巴巴的大數據係統的體係架構圖，劃分為數據采集、數據計算、數據服務及數據應用四層，後麵的內容就是圍繞這張圖展開的，技術含量有多高，大家都懂的，如果讀到後麵迷失了，可以重新回過頭來理解這張圖。
筆者這裏選取的內容，主要是與自身企業對標後感覺有特點的，一般的內容就不提了，當然這僅是筆者的看法，因此建議讀完本文後自己去看看原書，不定會獲得更多的啟示。
一、數據采集
1、線上主動采集工具
阿裏巴巴針對web和app端有兩個專門的采集工具Aplus.Js和UserTrack，大多傳統公司由於長期經營線下，對於web，app等的主動采集能力是偏弱的，一般數據管理部門對於web或app端的采集基本是源端推送過來的文件，對於采集沒有實際主導權，內容豐富程度大打折扣，同時無論是web的js腳本還是app的sdk,實際上都是有一定的技術門檻，企業app源端由於受限於合作夥伴的能力，往往采集能力不夠，數據質量參差不齊。
互聯網源端的日誌留存，到底哪些是源端本身的要求，哪些是大數據管理的要求，需要想清楚，大數據管理部門如果想獲得更好的數據，是否考慮要往前走一步，畢竟OLAP和OLTP對待數據的角度不一樣，人家沒必要為你留你所需要的數據。
企業的大數據管理部門，能否適應互聯網的新的形式，打破條線分割，在常規的數據庫，文本，消息等采集基礎上，新增線上的主動采集工具，是巨大的挑戰。
當前一些企業提供的企業級大數據采集工具，是缺了這條腿的，以後企業往線上走，這個PaaS能力的確是要具備的。
2、數據同步
阿裏巴巴實現了諸如oracle的歸檔日誌的增量采集，應該是比較成熟的，自己企業也采用過類似的OGG技術，雖然可行，但開銷很大，新增和存量的合並代價很高， DSG希望能雄起。
現在分庫分中心的表越來越多，對於數據同步的配置越加複雜，阿裏巴巴的tddl分布式數據庫引擎可以通過建立中間邏輯來整合統一分庫分表的訪問，的確值得借鑒。
很多企業的抽取數據源種類繁多，管理複雜，阿裏搞了IDB來實現數據庫的統一管理，基於這個元數據能力，在數據同步時，阿裏可以采用oneclick來實現數據采集的一健配置和批量化同步，管理的深度和厚度可見一般。
阿裏針對數據漂移也給出了解決建議，其實數據漂移問題在每個企業都大量存在，比如運營商計費話單的記錄更新時間，日誌時間，業務時間和抽取時間往往不一致，這會導致業務的邏輯問題，你可能在上月底12點未到打的電話，業務記錄卻會在本月的話單裏。
二、數據計算
1、MaxCompute離線計算引擎
阿裏的MaxCompute離線計算引擎彌補了hadoop的很多缺陷，它提供了一個集成管理方案，包括統一的授權，資源管理，數據控製和權限分配等，並提供一個易用的客戶端，支撐Web、SDK、CLT、IDE等4種訪問模式，集群數量可以到幾萬台，安全控製能力加強，這些都是當前很多商用hadoop版本難以做到的。
其計算核心就是網傳的飛天內核，包括Pangu(盤古分布式文件係統)、Fuxi（伏羲資源調度係統）、Shennong（神農監控模塊）等。
2、統一開發平台
筆者的企業也有這類平台，但跟阿裏的還是有差距，它其實是一個工具集，功能更完備，體係化程度更好。
（1）在雲端（D2）
D2是集成任務開發、調試及發布、生產任務調度及大數據運維，數據權限申請及管理功能的一站式數據開發平台，並能承擔數據分析工作台的功能。
這個其實非常類似筆者企業的DACP，但由於DACP要能對接各類源係統，因此底層的邏輯其實更複雜，實施難度更大，而D2基本隻要對接MaxCompute，這其實也是自主研發的一個好處，功能可以做的更強大，體驗更好，但相對比較封閉。
（2）SQLSCAN
SQLSCAN將在任務開發中遇到的各類問題，如用戶編寫的SQL質量差、性能低、不遵守規範等，總結形成規則，並通過係統及研發流程保障，事前解決故障隱患，避免時候故障。
這個功能對於將平台推到一線至關重要，我們的DACP在推廣過程中，碰到大量的SQL優化問題，但無論是通過培訓還是其他方式，其實都遠沒有係統中固化規則的好，阿裏的實踐很好，開發平台一定要記住不可能人人都是代碼專家，要用係統化的方式解決問題，這是平台能夠規模化的一個核心要素。
關於DACP功能過於龐大的問題，筆者其實也明顯感覺到了，阿裏的關於開發平台拆分為多個產品的一些思路給了啟示，這是有利於小步快跑的原則的，為每個模塊取不同的名字，也有利於專項資源的投入。
（3）DQC
DQC（數據質量中心）主要關注數據質量，通過配置數據質量校驗規則，自動在數據處理任務過程中進行數據質量方麵的監控。
其主要有數據監控和數據清洗兩大功能，數據監控主要是設置規則並報警，有強規則和弱規則之分，強規則可以阻斷任務執行，數據清洗的方式跟我們的大致類似，在引入過程中不進行清洗，入庫後，再基於配置的規則進行清洗。
（4）在彼岸
主要將通用的、重複性的操作沉澱在測試平台中，避免人肉，提高測試效率，筆者所在企業的大數據自動化測試雖然也有一些，但功能不夠強大，在彼岸的功能包括數據對比（支持不同集群、異構數據庫的表做數據對比，比如數據量、字段統計值SUM，AVG等）,數據分布等
從阿裏的統一開發平台可以看出來，其不僅提供了從任務開發到運維的整套工具，還特別注重體係的完整性和規則的沉澱，這類平台工具實際很難由第三方公司提供，而傳統企業除了自身研發力量不夠，往往由於業務需求的壓力導致在IT這類基礎平台層麵的研發投入不足，一味靠資源和人力的投入去解決一些其實無解的問題，同時將報表取數人員和產品開發人員混編在一起，造成疲於應對需求的局麵，這是值得深思的。
3、實時技術
阿裏巴巴基於TimeTunnel來進行實時數據的采集，原理和Kafka等消息中間件類似，采用StreamCompute進行流式處理，跟Storm，Stream也類似，對於實時統計的問題，它提的些方案值得借鑒。
在商業智能統計類實時任務中，對於資源消耗有一類是非常高的，那就是去重指標，實時任務為了追求性能，計算邏輯一般在內存完成，在計算去重時，勢必要把去重的明細數據保留下來，當去重的明細數據達到上億時，內存中放不小，怎麼辦？
精確去重可以通過數據傾斜來進行處理，把一個節點的內存壓力分到多個節點，在模煳去重的前提下，可以采用相關的去重算法，把內存使用量降到千分之一甚至萬分之一，布隆過濾器就是一種，其簡單來講就是不保存明細數據，隻保留明細數據對應哈希值的標記位，當然會出現哈希值碰撞的情況。
實時任務在運行中會計算很多維度和指標，這些數據如何存呢？由於實時任務大多是多線程處理的，意味著數據存儲必須能夠較好的支持多並發讀寫，並且延時需要在毫秒級才能滿足實時的性能要求，一般使用Hbase，Tair等列式數據存儲係統。
當然諸如HBASE等係統缺點也比較明顯，必須使用rowkey, 而rowkey的規則限製了讀寫的方式，顯然沒有關係型數據庫那麼方便，但對於海量數據的實時計算和讀寫，一般還是適用的，針對HBASE阿裏提供了表名和rowkey設計的一些實踐經驗。
比如rowkey可以采取MD5+主維度+維度標識+字維度+時間維度+子維度2，例如賣家ID的MD5的前四位+賣家ID+app+一級類目+ddd+二級類目ID，以MD5的前四位作為rowkey的第一部分，可以把數據散列，讓服務器整體負載均衡，避免熱點的問題。
筆者一直覺得對於實時數據是不需要建模的，看來還是太天真了，也許主要是實時應用在當前很多企業場景不多所致，但阿裏顯然不一樣，其實時統計能力至關重要，無論是雙11大屏還是阿裏的生意參謀，都把實時統計指標作為一個賣點，實時模型跟離線模型的建模理念是一致的，比如阿裏的流式模型分為五層，ODS層、DWD層、DWS層、ADS層及DIM層，關於每層的含義在筆者後續的文章中會介紹，這裏就不再描述了。
本文簡要談了阿裏的數據采集和數據計算，下一篇還會談到數據服務、數據挖掘、數據建模、數據管理及數據應用等，非常精彩，雖然對於很多企業來講，這些平台和工具可能過重，但思想是先進的。
對於在做類似產品的大公司或者致力於大數據運營的大企業，則要好好研究一下， 它山之石，可以攻玉。
轉自與數據同行公眾號
阿裏巴巴大數據-玩家社區 https://yq.aliyun.com/teams/6/
---阿裏大數據博文，問答，社群，實踐，有朋自遠方來，不亦說乎……
最後更新：2017-08-14 10:32:52