讀完《大數據之路：阿里巴巴大數據實踐》，開啓大數據進擊之旅（兩萬字長文，慎點！）

寫在前面：我是「雲祁」，一枚熱愛技術、會寫詩的大數據開發猿。暱稱來源於王安石詩中一句 [ 雲之祁祁，或雨於淵 ] ，甚是喜歡。


寫博客一方面是對自己學習的一點點總結及記錄，另一方面則是希望能夠幫助更多對大數據感興趣的朋友。如果你也對 數據中臺、數據建模、數據分析以及Flink/Spark/Hadoop/數倉開發 感興趣，可以關注我的動態 https://blog.csdn.net/BeiisBei ，讓我們一起挖掘大數據的價值~


每天都要進步一點點，生命不是要超越別人，而是要超越自己！ (ง •_•)ง

一、前言

最近一直在看《大數據之路：阿里巴巴大數據實踐》一書，讀完之後感覺受益良多。第一，對於整個大數據的體系有了更多且清晰的認知；第二，對於不同系統的邏輯處理方式給予了引導；第三，畢竟是阿里多年技術的累計產出，而且都是阿里技術大牛寫的，乾貨相當多；最後，如果對於大數據方向想有更深入的瞭解，推薦大家閱讀 ο(=•ω＜=)ρ⌒☆！

一直以來，我都對大數據真正的價值有思考。後來才發現，大、快、多樣性只是表象，大數據的真正價值在於生命性和生態性。

阿里將這類數據稱之爲“活數據”：活數據是全本記錄、實時驅動決策和迭代，它的價值是隨着使用場景和方式動態變化的，不可估量。

二、阿里巴巴大數據系統體系架構

首先是一張鎮樓圖，阿里巴巴的大數據系統的體系架構圖，劃分爲數據採集、數據計算、數據服務及數據應用四層，後面的內容就是圍繞這張圖展開的，技術含量有多高，大家都懂的，如果讀到後面迷失了，可以重新回過頭來理解這張圖。

數據計算分層：操作數據層、明細數據層、彙總數據層和應用數據層。通過數據倉庫不同層次之間的加工過程實現從數據資產向信息資產的轉化，並對整個過程進行有效的元數據管理及數據質量處理。

三、數據採集

阿里巴巴的日誌採集體系方案包括兩大體系：Aplus.JS是Web端日誌採集技術方案 ；UserTrack是APP端的日誌採集方案。 大多傳統公司由於長期經營線下，對於Web，APP等的主動採集能力是偏弱的，一般數據管理部門對於Web或APP端的採集基本是源端推送過來的文件，對於採集沒有實際主導權，內容豐富程度大打折扣，同時無論是Web的JS腳本還是APP的SDK,實際上都是有一定的技術門檻，企業APP源端由於受限於合作伙伴的能力，往往採集能力不夠，數據質量參差不齊。

互聯網源端的日誌留存，到底哪些是源端本身的要求，哪些是大數據管理的要求，需要想清楚，大數據管理部門如果想獲得更好的數據，是否考慮要往前走一步，畢竟OLAP和OLTP對待數據的角度不一樣，人家沒必要爲你留你所需要的數據。

企業的大數據能否適應互聯網的新的形式，打破條線分割，在常規的數據庫、文本、消息等採集基礎上，新增線上的主動採集工具，是巨大的挑戰。當前一些企業提供的企業級大數據採集工具，是缺了這條腿的，以後企業往線上走，這個PaaS能力的確是要具備的。

在採集技術的基礎上，阿里巴巴用面向各個場景的埋點規範，來滿足通用瀏覽、點擊、特殊交互、APP事件、H5及APP裏的H5和Native日誌數據打通等多種業務場景。

3.1 瀏覽器的頁面日誌採集

3.1.1 頁面瀏覽日誌採集

1. 在HTML文檔內的適當位置增加一個日子採集節點，但瀏覽器解析到這個節點時，將自動觸發一個特定的HTTP請求到日誌採集服務器。
2. 植入採集腳本的動作可以由服務器在相應業務請求時動態執行，也可以在開發頁面時由開發人員手動植入。
3. 採集到日誌後大多會立刻將日誌發送到日誌採集服務器，服務器立即返回成功響應，並將日誌存儲到日誌緩存區。
4. 順序讀取日誌並處理，轉存成標準日誌文件，加入到實時消息通道供後端程序讀取和進一步處理。

3.1.2 頁面交互日誌採集

交互日誌因爲頁面類型的不同，無法規定統一的採集內容，故以技術服務的形式採集交互日誌。

由業務方註冊要採集好交互日誌的業務、業務場景和場景下具體的採集點，由系統自動生成採集日誌的代碼模板。

3.1.3 服務器端數據清洗和預處理

• 識別流量攻擊、網絡爬蟲和虛假流量
• 數據缺項補正
• 剔除無效數據
• 基於數據安全和業務特性的日誌隔離分發

3.2 無線客戶端的日誌採集

無線客戶端的日誌採集採用採集 SOK 來完成，在阿里巴巴內部，多使用名爲 UserTrac 來進行無線客戶端的日誌採集。

“事件”爲無線客戶端日誌行爲的最小單位。基於常規的分析， UserTrack (UT ）把事件分成了幾類，常用的包括頁面事件（同前述的頁面瀏覽）和控件點擊事件（同前述的頁面交互）等。

3.3 日誌採集的挑戰

3.3.1 日誌分流與定製處理

PV日誌的請求位置（URL）是隨着頁面所在業務類型的不同而變化的。不僅考慮日誌服務器端的分佈計算方案，而且將分類任務前置到客戶端。

3.3.2 採集與計算一體化

以URL的正則集來對日誌進行分類會隨着日誌複雜度的增長榨乾硬件集羣。由用戶自己制定需要採集的頁面，系統自動對頁面採集的來的日誌進行計算。

3.3.3 大促保障

日誌數據在阿里系乃至整個電商系應該都是體量最大的一類數據，在“雙 11”期間，日誌必然會暴漲，近萬億的數據量對日誌全鏈路說，無疑是不小的挑戰。

從端上埋點採集，到日誌服務器收集，經過數據傳輸，再到日誌時解析、實時分析，任何一個環節出現問題，全鏈路保障就是失敗的。考慮到服務器的收集能力（如峯值QPS等）、數據傳輸能力（ TT 的搬運速度）、實時解析的吞吐量、實時業務分析的處理能力，阿里在各環節都做了不少的工作。

四、數據同步

對於大數據系統來說，包含數據從業務系統同步進入數據倉庫和數據從數據倉庫同步進入數據服務或數據應用兩個方面。

源業務系統的數據類型多種多樣，有來源於關係型數據庫的結構化數據，如 MySQL Orac le DB2, SQL Server ：也有來源於非關係型數據庫的非結構化數據，如 Ocean Base HBase Mongo DB 等，這類數據通常存儲在數據庫表中：還有來源於文件系統的結構化或非結構化據，如阿里雲對象存儲 oss 、文件存儲 NAS 等，這類數據通常以文件形式進行存儲。

數據同步需要針對不同的數據類型及業務場景選擇不同的同步方式。總的來說，同步方式可以分爲三種：

• 直連同步 數據直抽
• 數據文件同步
• 數據庫日誌解析同步

4.1 阿里數據倉庫的同步方式

• 批量數據同步
  數據類型統一採用字符串類型（中間狀態），
  DataX對不同的數據源提供插件，將數據從數據源讀出並轉換爲中間狀態存儲，
  傳輸過程全內存操作，不讀寫磁盤，也沒有進程間通信。

• 實時數據同步
  通過解析MySQL的binlog日誌來實時獲得增量的數據更新，並通過消息訂閱模式來實現數據的實時同步，
  日誌數據 ——> 日誌交換中心 ——> 訂閱了該數據的數據倉庫，
  針對訂閱功能，可以支持主動、被動訂閱、訂閱端自動負載均衡，數據消費者自己把握消費策略。可以訂閱歷史數據，隨意設置訂閱位置，並具有屬性過濾功能。

4.2 數據同步問題

• 分庫分表處理
  建立了一箇中間層的邏輯表來整合分庫分表，使得外部訪問中間層的時候，與訪問單庫單表一樣簡潔。
  阿里巴巴的 TDDL ( Taobao Distributed Data ayer ）就是這樣一個分佈式數據庫的訪問引擎，通過建立中間狀態的邏輯表來整合統一分庫分表的訪問，TDDL 是在持久層框架之下、 JDBC 驅動之上的中間件。

• 高效同步和批量同步
  統一管理不同源數據庫的元數據信息，強化版的元數據管理平臺，要求數據同步配置透明化。通過庫名和表名即可通過元數據管理平臺唯一定位，再由自動化的數據同步平臺完成建表、配置任務、發佈、測試的一鍵化處理。

• 增量與全量同步的合併
  全外連接與insert overwrite代替merge與update；
  採用分區，每天保持一個最新的全量版本，每個版本僅保留較短的時間週期如3天至一週；
  方式爲當天的增量數據與前一天的全量數據合併，生成當天的全量數據。

• 數據同步性能
  阿里實踐出一套實踐出一套基於負載均衡思想的新型數據同步方案，通過目標數據庫的元數據估算同步任務的總線程數，以及通過系統預先定義的期望同步速度估算首輪同步的線程數，同時通過數據同步任務的業務優先級決定同步線程的優先級，最終提升同步任務的執行效率和穩定性。

• 數據漂移
  常見於0點時分左右，數據按照日期劃分跨天的問題。冗餘獲取0點左右的數據，根據多種時間字段來排序去重，重新劃分和補錄數據。

五、離線數據開發

5.1 MaxCompute離線計算引擎

阿里的MaxCompute離線計算引擎彌補了hadoop的很多缺陷，它提供了一個集成管理方案，包括統一的授權，資源管理，數據控制和權限分配等，並提供一個易用的客戶端，支撐Web、SDK、CLT、IDE等4種訪問模式，集羣數量可以到幾萬臺，安全控制能力加強，這些都是當前很多商用hadoop版本難以做到的。

接人層提供 HTTP 服務、 Cache 、負載均衡，實現用戶認證和服務層面的訪問控制。

邏輯層又稱作控制層，是 MaxCompute 的核心部分，實現用戶空間和對象的管理、命令的解析與執行邏輯、數據對象的訪問控制與授權等功能。

其計算核心就是網傳的飛天內核，包括Pangu(盤古分佈式文件系統)、Fuxi（伏羲資源調度系統）、Nuwa/ZK (Namespace服務）、Shennong（神農監控模塊）等。

5.2 統一開發平臺

阿里數據開發平臺集成了 個子系統來解決實際生產中的各種痛點。圍 Max Comp te 計算平臺，從任務開發、調試、測試、發佈、監控、 到運維管理，形成了整套工具和產品，既提高了開發效率，又保證了數據質量，並且在確保數據產出時效的同時，能對數據進行有效管理。

5.2.1 在雲端（D2）

D2是集成任務開發、調試及發佈，生產任務調度及大數據運維數據權限申請及管理等功能的一站式數據開發平臺 並能承擔數據分析工作臺的功能。

5.2.2 SQLSCAN

SQLSCAN將在任務開發中遇到的各類問題，如用戶編寫的SQL質量差、性能低、不遵守規範等，總結形成規則，並通過系統及研發流程保障，事前解決故障隱患，避免時候故障。

5.2.3 DQC

DQC（數據質量中心）主要關注數據質量，通過配置數據質量校驗規則，自動在數據處理任務過程中進行數據質量方面的監控。

其主要有數據監控和數據清洗兩大功能，數據監控主要是設置規則並報警，有強規則和弱規則之分，強規則可以阻斷任務執行，數據清洗的方式跟我們的大致類似，在引入過程中不進行清洗，入庫後，再基於配置的規則進行清洗。

5.2.4 在彼岸

主要將通用的、重複性的操作沉澱在測試平臺中，避免人肉，提高測試效率。在彼岸的功能包括數據對比（支持不同集羣、異構數據庫的表做數據對比，比如數據量、字段統計值SUM、AVG、MAX MIN等）、數據分佈、數據脫敏等

從阿里的統一開發平臺可以看出來，其不僅提供了從任務開發到運維的整套工具，還特別注重體系的完整性和規則的沉澱，這類平臺工具實際很難由第三方公司提供，而傳統企業除了自身研發力量不夠，往往由於業務需求的壓力導致在IT這類基礎平臺層面的研發投入不足，一味靠資源和人力的投入去解決一些其實無解的問題，同時將報表取數人員和產品開發人員混編在一起，造成疲於應對需求的局面，這是值得深思的。

5.3 任務調度系統

• 調度系統分爲調度引擎（ Phoenix Engine ）和執行引擎（Alisa）。
• 狀態機分爲工作流狀態機與任務狀態機，工作流包含待提交、已創建、正在執行、成功、失敗等各個工作節點；而任務狀態則是在工作流之下的一系列狀態，例如執行中的等待狀態。
• 通過事件驅動，生成調度實例，在兩種狀態機之間切換執行調度，根據狀態的不同也在調度引擎和執行引擎之間切換。

六、實時技術

阿里巴巴基於TimeTunnel來進行實時數據的採集，原理和Kafka等消息中間件類似，採用StreamCompute進行流式處理，跟Storm類似，對於實時統計的問題，它提的些方案值得借鑑。

6.1 流式技術架構

架構分爲數據採集、數據處理、數據存儲、數據服務四部分。

6.1.1 數據採集

從數據源採集數據均已文件的形式保存，通過監控文件內容的變化，使用數據大小的限制和間隔時間閾值的限制來共同決定採集的頻率。
將數據落到數據中間件之後，可由流計算平臺來訂閱數據。

時效性和吞吐量是數據處理中的兩個矛盾體 ，很多時候需要從業務的角度來權衡使用什麼樣的系統來做數據中轉。

6.1.2 數據處理

SQL語義的流式數據分析能力。

• 流式處理的原理：多個數據入口、多個處理邏輯，處理邏輯可分爲多個層級逐層執行。
• 數據傾斜：數據量非常大時，分桶執行。
• 去重處理：精確去重使用數據傾斜的方式，模糊去重使用哈希來減少內存佔用。
• 事物處理：超時補發、每批數據自帶ID、將內存數據備份到外部存儲。

在商業智能統計類實時任務中，對於資源消耗有一類是非常高的，那就是去重指標，實時任務爲了追求性能，計算邏輯一般在內存完成，在計算去重時，勢必要把去重的明細數據保留下來，當去重的明細數據達到上億時，內存中放不小，怎麼辦？

精確去重可以通過數據傾斜來進行處理，把一個節點的內存壓力分到多個節點，在模糊去重的前提下，可以採用相關的去重算法，把內存使用量降到千分之一甚至萬分之一，布隆過濾器就是一種，其簡單來講就是不保存明細數據，只保留明細數據對應哈希值的標記位，當然會出現哈希值碰撞的情況。

6.1.3 數據存儲

• 實時系統要求數據存儲滿足多線程多併發以及毫秒級的低延時。
• 表名設計和rowkey設計遵循數據均衡分佈、同一主維度的數據在同一張物理表。

實時任務在運行中會計算很多維度和指標，這些數據如何存呢？由於實時任務大多是多線程處理的，意味着數據存儲必須能夠較好的支持多併發讀寫，並且延時需要在毫秒級才能滿足實時的性能要求，一般使用HBase、Tair等列式數據存儲系統。

當然諸如HBase等系統缺點也比較明顯，必須使用rowkey，而rowkey的規則限制了讀寫的方式，顯然沒有關係型數據庫那麼方便，但對於海量數據的實時計算和讀寫，一般還是適用的，針對HBase阿里提供了表名和rowkey設計的一些實踐經驗。

比如rowkey可以採取MD5+主維度+維度標識+字維度+時間維度+子維度2，例如賣家ID的MD5的前四位+賣家ID+app+一級類目+ddd+二級類目ID，以MD5的前四位作爲rowkey的第一部分，可以把數據散列，讓服務器整體負載均衡，避免熱點的問題。

6.2 流式數據模型

數據模型設計是貫通數據處理過程的，流式數據處理也 樣，需要對數據流建模分層。實時建模跟離線建模非常類似，數據模型整體上分爲五層（ ODS DWD DWS ADS DIM ）。

由於實時計算的侷限性，每一層中並沒有像離線做得那麼寬，維度和指標也沒有那麼多，特別是涉及回溯狀態的指標，在實時數據模型幾乎沒有。

整體來看，實時數據模型是離線數據模型的 個子集，在實時數據處理過程中，很多模型設計就是參考離線數據模型實現的。

• 數據分層
  ODS：直接從業務採集來的原始數據，包含所有業務的變更過程。存儲於數據中間件。
  DWD：根據業務過程建模出來的事實明細。存儲於數據中間件。
  DWS：各個維度的彙總指標，該維度是各個垂直業務線通用的。落地到存儲系統。
  AWS：各個維度的彙總指標，適用於某個業務條線獨有的維度。落地到存儲系統。
  DIM：實時維表層，由離線的維表導入。離線處理。

其中， ODS層到 DIM 層的 ETL 處理是在離線系統中進行的，處理完成後會同步到實時計算所使用的存儲系統。 DIM 層和 DWD 層會放在數據中間件中，供下游訂閱使用。而 DWS 層和 ADS 層會落地到在線存儲系統中，下游通過接口調用的形式使用。

在每一層中，按照重要性劃分爲 P0、 P1、P2、P3 等級， P0 屬於最高優先級保障。根據不同的優先級給實時任務分配不同的計算和存儲資源，力求重要的任務可以得到最好的保障。

另外，字段命名、表命名、指標命名是按照 OneData 規範來定義的，以便更好地維護和管理。

• 多流關聯
  多個流關聯時，只有能匹配上的數據會被輸出到下游，否則存儲到外部存儲系統中。當有更新進來的時候，從外部存儲系統中重新讀取數據到內存，從已執行完成的部分繼續執行。

6.3 大促挑戰＆保障

大促是電商行業的狂歡節，在這期間，各個業務系統面臨的峯值都會達到最高點，每年大促的海量數據處理給實時計算的性能和保障提出了很大的挑戰。

6.3.1 大促特徵

大促和日常比較，在數據量以及要求上有非常大的區別，日常不怎麼關注的點，在大促的時候會被放大，並且 天中的峯值特別明顯，數據量是其他時間點的幾倍甚至數十倍，這對系統的抗壓能力要求非常高，不能因爲洪流的到來而把系統壓垮。

1. 毫秒級延時
2. 洪峯明顯
3. 高保障性

由於關注的人非常 ，只要出現數據延遲或者數據質量的問題，業務方的反彈就比較大，並且會第 時間感知到數據異常。因此，在大促般都要求高保障性， 些特殊的情況甚至需要做到強保障。

對於強保障的數據，需要做多鏈路冗餘（從來集、處理到數據服務個數據鏈路都需要做物理隔離）（見圖 5.7 ）。當任何 條鏈路出現問時，都能夠 鍵切換到備鏈路，並且需要對業務方透明，讓下游感知到有鏈路上的切換（由於各個鏈路計算的速度有 定的差異，會導致數據在切換時出現短時間下跌的情況，使用方需要做指標大小的判斷，避免指標下跌對用戶造成困擾）。

4. 公關特性
大促期間，數據及時對公衆披露是一項重要的工作，這時候要求實時計算的數據質量非常高。這裏面涉及主鍵的過濾、去重的精準和口徑的統一等一系列問題，只有把每一個環節都做好才能保障和離線的數據一致。

6.3.2 大促保障

1. 如何進行實時任務優化
   (1）獨佔資源和共享資源的策略
   (2）合理選擇緩存機制，儘量降低讀寫庫次數
   (3）計算單元合併，降低拓撲層級
   (4）內存對象共享，避免字符拷貝
   (5）在高吞吐量和低延時間取平衡

2. 如何進行數據鏈路保障

實時數據的處理鏈路非常長（數據同步→數據計算→數據存儲→數據服務），每一個環節出現問題，都會導致實時數據停止更新。實時計算屬於分佈式計算的 種，而單個節點故障是常態的，這種情況在直播大屏中表現特別明顯，因爲數據不再更新，所有的用戶都會發現數據出現了問題。因此，爲了保障實時數據的可用性，需要對整條計算鏈路都進行多鏈路搭建，做到多機房容災，甚至異地容災。

6.3.3 如何進行壓測

數據壓測主要是蓄洪壓測，就是把幾個小時甚至幾天的數據積累下來，並在某個時刻全部放開，模擬“雙 11 ”洪峯流量的情況，這裏面的數據是真實的。比如通過把實時作業的訂閱數據點位調到幾個小時或者幾天前，這時候每一批讀到的數據都是最多的，對實時計算的壓力也最大。

產品壓測還細分爲產品本身壓測和前端頁面穩定性測試。

七、數據服務

數據服務平臺可以叫數據開放平臺，數據部門產出海量數據，如何能方便高效地開放出去，是我們一直要解決的難題，在沒有數據服務的年代，數據開放的方式簡單、粗暴，一般是直接將數據導出給對方。這種方式不僅低效，還帶來了安全隱患等諸多問題。

即使如阿里，在數據開放這個方向上的探索和實踐，至今也有10個年頭了，任何關於數據開放畢其功於一役的做法都將失敗，任何一次數據開放的改進都是伴隨着對於業務理解的深入而成長起來的。

7.1 數據服務平臺

阿里數據服務架構演進過程如圖所示。基於性能、擴展性和穩定性等方面的要求，我們不斷升級數據服務的架構，依次經歷了內部代號爲 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，是單表還是分庫分表，這極大簡化了操作的複雜度。

阿里的思路說不上很超前，但它不僅落地了，而且在不停演進，這也許就是企業自主研發的價值，它的產品始終流着同樣的血液。

OneService：SQL顯然無法解決複雜的業務邏輯，SmartDQ其實只能滿足簡單的查詢服務需求，正如我們的自助取數也僅能滿足50-60%的臨時取數一樣，企業遇到的場景還有以下幾類：個性化的垂直業務場景、實時數據推送服務、定時任務服務，OneService主要是提供多種服務類型來滿足客戶需求，分別是OneService-SmartDQ、OneService-Lego、OneService-iPush、OneService-uTiming。

Lego被設計成一個面向中度和高度定製化數據查詢需求，支持插件機制的服務容器，我理解就是提供定製環境和暴露接口，你要怎麼做就怎麼做。

iPush主要提供 Web Socket long polling 兩種方式，其應用場景主要是商家端實時直播。是一個面向TT、MetaQ等不同消息源，通過定製過濾規則，向Web、無線等終端推送消息的中間件平臺。

uTiming是基於在雲端的任務調度應用，提供批量數據處理服務，支撐用戶識別、用戶畫像、人羣圈選三類服務的離線計算以及服務數據預處理、入庫，這個感覺是非常個性化的一個應用。

7.2 性能優化

1. 資源分配
   剝離複雜的計算邏輯，將其交由數據共同層處理；
   將Get類型與List類型的查詢分爲不同的線程池；
   執行計劃優化。比如拆分邏輯表的查詢到不同的物理表去執行、將List類型的查詢改變爲Get類型的查詢等。

2. 緩存優化
   元數據緩存、邏輯表查詢到物理表查詢的映射緩存、查詢結果緩存。

3. 查詢能力
   合併離線數據查詢與實時數據查詢，在離線數據無法查到結果的時候即時切換到實時查詢；
   對於需要輪詢的數據，採用推送代替輪詢。當監聽到數據有更新時，推送更新的數據。

八、數據挖掘

阿里構建了一套架構於阿里雲MaxConpute、GPU等計算集羣之上，匯聚了阿里大量優質的分佈式算法，包括數據處理、特徵工程、機器學習算法、文本算法等，可高效完成海量、億級維度數據的複雜計算，同時提供一套極易操作的可視化編輯頁面，大大降低了數據挖掘的門檻，提高了建模效率。

8.1 數據挖掘

其選擇的計算框架是MPI，其核心算法都是基於阿里雲的MaxCompute的MPI實現的。

MaxCompute MPI 的處理流程如圖所示，與分佈式計算系統的原理類似，不再贅述。其中伏羲爲阿里雲飛天系統的分佈式調度系統，女媧爲阿里雲飛天系統的分佈式一致性協同服務系統，盤古爲阿里雲飛天系統的分佈式文件存儲系統。

基於 MaxCompute MPI ，目前阿里巴巴的算法平臺已經集成了絕大部分業界主流的機器學習算法，從傳統的分類、聚類算法，到互聯網應用中非常流行的協同過濾、 PageRank 算法，再到當前最火熱的深度學習算法，這些算法基本可以滿足企業級數據挖掘應用的需要。

8.2 數據挖掘中臺體系

早在 2015 年，阿里巴巴集團便提出了中臺戰略，將一些通用的技術集成起來形成中臺技術體系，爲各業務部門提供統 、高效的技術服務，避免各業務部門在各自業務發展的過程中進行重複的技術建設造成不必要的資源浪費與時間消耗。對於數據挖掘技術而言，中臺發展的思路同樣適用，並且從長遠來看，構建數據挖掘中臺技術體系也是絕對有必要的。

阿里將數據中臺分爲三層：特徵層（FDM）、中間層和應用層（ADM）,其中中間層包括個體中間層（IDM）和關係中間層（RDM），如下圖所示：

• FDM 層：用於存儲在模型訓練前常用的特徵指標，並進行統一的清洗和去噪處理，提升機器學習特徵工程環節的效率。
• IDM 層 ：個體挖掘指標中間層，面向個體挖掘場景，用於存儲通用性強的結果數據，主要包含商品、賣家、買家、行業等維度的個體數據挖掘的相關指標。
• RDM 層：關係挖掘指標中間層，面向關係挖掘場景，用於存儲通用性強的結果數據，主要包含商品間的相似關係、競爭關係，店鋪間的相似關係、競爭關係等。
• ADM 層：用來沉澱比較個性偏應用的數據挖掘指標，比如用偏好的類目、品牌等，這些數據已經過深度的加工處理，滿足某一特點業務或產品的使用。

通過挖掘數據中臺的建設，能夠大幅度節省數據挖掘特徵工程的作時間，而中間層與應用層的分層設計則能更有效地管理通用的挖掘計算結果，大量減少重複的基礎數據挖掘工作。

九、數據模型

數據建模在這本書佔據了三分之一篇幅，可見其重要性。

9.1 典型的數據倉庫建模方法論

9.1.1 ER模型

傳統關係型數據庫的ER模型是基於具體業務實體的，而大數據領域的ER模型是建立於業務主題之上的。更着重描述業務主題之間的關係，將具體業務實體整合到了業務主題之下。業務主題理論上滿足3NF的範式要求。描述業務主題之間關係爲高層模型，其下的中層模型細化了主題的數據項，中層模型下的物理模型考慮物理存儲（分區、合併等）。

9.1.2 維度模型

度模型從業務需求出發，考慮業務事件（比如交易、還款等不可拆分的行爲），再將事件細分爲多個粒度，基於粒度再設計多種維度，最後選擇需要衡量的事實指標。維度模型重點關注需求分析，典型代表是星型模型和雪花模型。

9.1.3 Data Vault 模型

Data Vault Dan Linstedt 發起創建的一種模型，它是 模型的生，其設計的出發點也是爲了實現數據的整合，但不能直接用於數據分析決策。它強調建立一個可審計的基礎數據層，也就是強調數據的歷史性、可追溯性和原子性，而不要求對數據進行過度的一致性處理和整合同時它基於主題概念將企業數據進行結構化組織，並引入了更進一步的範式處理來優化模型，以應對遊、系統變更的擴展性。

9.1.4 Anchor 模型

Anchor Data Vault 模型做了進一步規範化處理， Lars. Ri:innback 的初衷是設計 個高度可擴展的模型，其核心思想是所有的擴展只是添加而不是修改，因此將模型規範到 6NF ，基本變成了 k-v 結構化模型。

9.2 阿里巴巴數據模型實踐

第一階段：完全應用驅動的時代，數據完全以滿足報表需求爲目的，將數據以與源結構相同的方式同步到Oracle，數據完全以滿足報表需求爲目的，將數據以與源結構相同的方式同步到 Oracle （稱作 ODS 層），數據工程師基於 ODS數據進行統計，基本沒有系統化的模型方法體系，完全基於對 Oracle數據庫特性的利用進行數據存儲和加工，部分採用 一些維度建模的緩慢變化維方式進行歷史數據處理。這時候的數據架構只有兩層，即
ODS+DSS。

第二階段：隨着阿里業務的快速發展，數據量飛速增長，性能成爲一個較大問題，需要通過一些模型技術改變煙囪式的開發模型，消除數據冗餘，提升數據一致性，來自傳統行業的數據倉庫工程師開始嘗試架構工程領域比較流行的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層中。

9.3 模型實施

OneData是阿里的模型設計理論，看完這個過程，基本會搞清楚維度建模的各個步驟，強烈建議結合後面的維度和事實表建模進行精讀，主要步驟如下：

數據調研：業務調研需要對業務系統的業務進行了解，需求分析則是收集分析師運營人員對數據或者報表的需求，報表需求實際是最現實的建模需求的基礎。

實施工作流圖鎮樓，大佬說這張圖就可以值回書價！ ∠( ᐛ 」∠)＿

架構設計：分爲數據域劃分和構建總線矩陣。數據域劃分是指面向業務分析，將業務過程或者維度進行抽象的集合，業務過程可以概括爲一個個不可拆分的行爲事件，如下單、支付等。構建總線矩陣需要明確每個數據域下游哪些業務過程，業務過程與哪些維度相關，並定義每個數據域下的業務過程和維度。

如表 9.5 所示是根據業務過程進行歸納，抽象出的數據域（部分示例）。

在進行充分的業務調研和需求調研後，就要構建總線矩陣了。需要做兩件事情 ：明確每個數據域下有哪些業務過程；業務過程與哪些維度相關，並定義每個數據域下的業務過程和維度。

如表 9.6 所示是供應鏈管理業務過程示例。

規範定義：規範定義主要定義指標體系，包括原子指標、修飾詞、時間週期和派生指標，關於指標的規範定義阿里有單獨的一節描述，大家可以好好學習一下，很多時候細節決定成敗。

模型設計：模型設計主要包括維度及屬性的規範定義、維表、明細事實表和彙總事實表的模型設計。

總結：OneData 的實施過程是一個高度迭代和動態的過程， 般採用螺旋式實施方法。在總體架構設計完成之後，開始根據數據域進行迭代式模型設計和評審。在架構設計、規範定義和模型設計等模型實施過程中，都會引人評審機制，以確保模型實施過程的正確性。

9.4 維度設計

將度量稱爲事實，將環境描述爲維度。維度的作用一般是條件約束、分類查詢與排序。

9.4.1 維度的基本設計原則

1. 從主維表與相關維表中提取維度屬性或者生成新的維度屬性，屬性越豐富越好。
2. 屬性是編碼類型的，要有文字描述。
3. 將需要複雜邏輯計算的屬性提前整理並保存下來。
4. 維表以空間換取簡明性和查詢性能。
5. 維度一致性。保證能夠交叉查詢。

不同數據域共享維表。
一致性上卷。某個維度的維度屬性是另一個維度的子集。
交叉屬性。兩個維度有部分屬性相同。

9.4.2 維度的整合與拆分

依據高內聚低耦合的原則，保證擴展性、易用性和高效性。

• 水平拆分與整合
  一般根據維度屬性類型和維度之間的關聯性來進行整合與拆分。要麼提取出公共維度屬性，分別保存個性化維度屬性；要麼整合到相同的維表中。
  若類型只有較少的重疊，則採取提取公用維度的做法，否則整合到一張維表中，即使類型重疊較多。但維度屬於兩個關聯性較小的業務條線，也要分開在不同的集市。

• 垂直拆分與整合
  由於維度產出的時間，使用的熱度，變化的頻率不盡相同，需要使用主從維表來解決。主維表存放穩定、產出時間早、熱度高的屬性，從表存放變化較快、產出時間晚、熱度低的屬性。

9.4.3 歷史數據歸檔

有3種歸檔策略：

1. 數據倉庫與前臺數據庫保持相同的歸檔算法。但在前臺歸檔算法複雜或者算法經常變化的情況下不適用。
2. 解析前臺數據庫的日誌並歸檔。當解析到增量日誌中的刪除標誌時歸檔，但要求前臺應用在數倉歸檔之後才真正刪除數據，之前僅做邏輯刪除，避免前後臺數據狀態不一致的情況。（推薦使用）
3. 數據倉庫自定義歸檔策略。但要求比前臺應用晚歸檔、少歸檔，避免出現前臺應用更新已歸檔數據的情況。

9.4.4 維度變化

維度的變化大多要慢於數據的變化，但根據業務情況不同，有時需要使用某個歷史時刻的維度。維度的歷史歸檔策略：

1. 僅保留維度最新的值。無法滿足需要使用歷史維度的情況。
2. 將新維度作爲新的一行數據存儲，同時記錄維度的生效時間和失效時間。關聯查詢時要帶上時間條件。
3. 將新維度作爲新的一列存儲，相當於舊值與新值的概念。但變化頻繁時不適用。
4. 保存維錶快照。根據數倉的數據更新週期，每個週期保存一份快照。根據時間和業務主鍵進行關聯。此方法簡單有效，但極浪費存儲。
5. 極限存儲。使用拉鍊表的方式存儲變化的數據，查詢時根據維度的生效時間和結束時間來關聯，但與2不同的是做了封裝將普通的查詢語句轉換爲帶有時間條件的查詢語句。而且使用生效時間按月做分區。（推薦）

使用極限存儲，僅限於維度變化即不快又不慢的情況，太快會導致維度數據太過龐大，太慢不需要極限存儲。而且保存維度歷史一般要求維度是枚舉值類型，如果類似積分這樣的連續值，則可能不適用。

9.4.5 特殊維度

遞歸層次維度
若維度存在層級關係，通過扁平化存儲，將上下層關係以不同的列的方式存儲在同一張維表中。
若層級關係是非均衡的，即枝幹的深度不一致，有兩種處理方式：

1. 回填：將維度向下虛擬，使其與起他枝幹的深度一致。
2. 層次橋接表：使用父層級、子層級、父子層級間隔來描述。

行爲維度
行爲維度是通過對客戶行爲的計算得到的維度，是否與主維表放在一起取決於維度變化的頻率，以及計算邏輯的複雜程度。

多值維度
即事實表的記錄與維表記錄是1對多的關係，比如申請書與卡片的關係。

1. 降低事實表的粒度。比如申請書降低到以卡片爲單位。但經常事實不允許。
2. 保留預留字段。比如申請書中預留多個卡片欄位。
3. 使用關聯表。但複雜度高不易維護。

9.5 事實表設計

1. 事實表
   事實表要儘可能多的包含與業務過程相關的度量。
   事實表包含的業務流程可以是一個也可以是多個，多個業務流程需要在更高層面的流程上有關聯，並且維度存在一定的相似性。
2. 事實表的粒度
   可以根據維度組合的細節程度，業務含義兩方面來表述。
   同一個事實表中的不同事實的粒度須一致。
3. 度量
   一般爲整數或浮點數。儘可能是可加的，避免類似百分比這種經過計算度量。
   多事實的事實表的度量是冗餘的，當某種事實只使用到部分度量時，將其他度量設置爲0。也可以使用同一個度量，但需要額外添加一個類型維度。
4. 退化維度
   保存在事實表中的維度屬性。
5. 事物表的類型
   事物事實表，週期快照事實表，累計快照事實表。累計快照事物表更適合處理起止時間明確的短生命週期實體，否則應該使用週期快照事實表。
6. 聚集
   聚集中的維度和度量和原事實表中的維度和度量保持一致。比如原事實表包含了買家與賣家，那麼聚集中可以同時包含買家與賣家相關的聚集維度。聚集的維度的粒度保持一致，不能出現按日彙總又出現按月彙總的數據，可以按照不同的列來保存；聚集的粒度可以和原事實的粒度不同，按照實際的需求來確定聚集的粒度。

十、數據管理

數據管理涉及的東西很多，這本書具體提到了元數據、計算管理、存儲和成本管理和數據質量，相對內容比較單薄，我挑兩點說一下。

一直聽說阿里財大氣粗，所有數據都永久保留，其實是謬傳，人家也是節約過日子的，看下圖你就知道了：

應對層出不窮的數據和應用，數據工程師其實很難確認哪些數據是最重要的，需要優先保障，阿里巴巴提出了數據資產等級的方案，旨在解決消費場景知曉的問題，其將數據劃分爲五個等級，毀滅性質、全局性質、局部性質、一般性質及未知性質，代號從A1到A5。

那麼如何個每份資產打上等級標籤呢，就是藉助強大的元數據能力，瞭解哪些表服務於哪些數據產品，基於血緣分析可以講整個消費鏈路上打上某一類資產的標籤，假如將阿里巴巴生意參謀定位等級A2，則所有相關鏈路的表的等級都是A2，從而啓動對應的保障措施,這個跟筆者企業的大數據保障方法類似，從應用重要程度確定表的保障等級。

十一、數據應用

阿里主要介紹了對外的數據產品平臺生意參謀和服務於內部的數據產品平臺。

生意參謀本質上就是爲自己的渠道提供的增值服務，是很成功的一款決策支持產品，體現了一個產品如何從小做起，逐步長成一個龐然大物的過程：

對內數據產品的演進幾乎是每一個公司BI系統的發展翻版，但顯然它已經長成大樹了。從臨時取數階段，到自動化報表階段（比如BIEE），再到自主研發BI階段（第三方滿足不了自己了），最後到數據產品平臺（更加體系化）。

當前阿里的數據產品平臺，包括PC和APP版本，共有四個層次，即數據監控、專題分析、應用分析及數據決策。

到這裏，基本就讀完了，整本書都是經驗之談，讀下來閃光頻現，小夥伴們有時間可以多讀幾遍啦( •̀ ω •́ )✧！