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層，關于每層的含義在筆者後續的文章中會介紹，這裡就不再描述了。
本文簡要談了阿裡的資料采集和資料計算，下一篇還會談到資料服務、資料挖掘、資料模組化、資料管理及資料應用等，非常精彩，雖然對于很多企業來講，這些平台和工具可能過重，但思想是先進的。
對于在做類似産品的大公司或者緻力于大資料營運的大企業，則要好好研究一下， 它山之石，可以攻玉。
<a target="_blank">---阿裡大資料博文，問答，社群，實踐，有朋自遠方來，不亦說乎……</a>