《大數據之路：阿里巴巴大數據實踐》：看阿里人從IT時代走向DT時代的經驗之談！

時間 2020-07-09

原文原文鏈接

1、前言

最近一直在看《大數據之路：阿里巴巴大數據實踐》一書，讀完以後感受受益良多。第一，對於整個大數據的體系有了更多且清晰的認知；第二，對於不一樣系統的邏輯處理方式給予了引導；第三，畢竟是阿里多年技術的累計產出，並且都是阿里技術大牛寫的，乾貨至關多；最後，若是對於大數據方向想有更深刻的瞭解，推薦你們閱讀！前端

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

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

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

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

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

3、數據採集

阿里巴巴的日誌採集體系方案包括兩大致系：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 頁面瀏覽日誌採集

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

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 的搬運速度）、實時解析的吞吐量、實時業務分析的處理能力，阿里在各環節都作了很多的工做。

4、數據同步

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

源業務系統的數據類型多種多樣，有來源於關係型數據庫的結構化數據，如 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、離線數據開發

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）。
狀態機分爲工做流狀態機與任務狀態機，工做流包含待提交、已建立、正在執行、成功、失敗等各個工做節點；而任務狀態則是在工做流之下的一系列狀態，例如執行中的等待狀態。
經過事件驅動，生成調度實例，在兩種狀態機之間切換執行調度，根據狀態的不一樣也在調度引擎和執行引擎之間切換。

6、實時技術

阿里巴巴基於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、 P一、P二、P3 等級， P0 屬於最高優先級保障。根據不一樣的優先級給實時任務分配不一樣的計算和存儲資源，力求重要的任務能夠獲得最好的保障。

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

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

6.3 大促挑戰＆保障

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

6.3.1 大促特徵

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

毫秒級延時
洪峯明顯
高保障性

因爲關注的人很是，只要出現數據延遲或者數據質量的問題，業務方的反彈就比較大，而且會第時間感知到數據異常。所以，在大促般都要求高保障性，些特殊的狀況甚至須要作到強保障。

對於強保障的數據，須要作多鏈路冗餘（歷來集、處理到數據服務個數據鏈路都須要作物理隔離）（見圖 5.7 ）。當任何條鏈路出現問時，都可以鍵切換到備鏈路，而且須要對業務方透明，讓下游感知到有鏈路上的切換（因爲各個鏈路計算的速度有定的差別，會致使數據在切換時出現短期下跌的狀況，使用方須要作指標大小的判斷，避免指標下跌對用戶形成困擾）。

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

6.3.2 大促保障

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

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

6.3.3 如何進行壓測

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

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

7、數據服務

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

即便如阿里，在數據開放這個方向上的探索和實踐，至今也有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 性能優化

資源分配
剝離複雜的計算邏輯，將其交由數據共同層處理；
將Get類型與List類型的查詢分爲不一樣的線程池；
執行計劃優化。好比拆分邏輯表的查詢到不一樣的物理表去執行、將List類型的查詢改變爲Get類型的查詢等。
緩存優化
元數據緩存、邏輯表查詢到物理表查詢的映射緩存、查詢結果緩存。
查詢能力
合併離線數據查詢與實時數據查詢，在離線數據沒法查到結果的時候即時切換到實時查詢；
對於須要輪詢的數據，採用推送代替輪詢。當監聽到數據有更新時，推送更新的數據。

8、數據挖掘

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

8.1 數據挖掘

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

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

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

8.2 數據挖掘中臺體系

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

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

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

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

9、數據模型

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

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 維度的基本設計原則

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

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

9.4.2 維度的整合與拆分

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

水平拆分與整合
通常根據維度屬性類型和維度之間的關聯性來進行整合與拆分。要麼提取出公共維度屬性，分別保存個性化維度屬性；要麼整合到相同的維表中。
若類型只有較少的重疊，則採起提取公用維度的作法，不然整合到一張維表中，即便類型重疊較多。但維度屬於兩個關聯性較小的業務條線，也要分開在不一樣的集市。
垂直拆分與整合
因爲維度產出的時間，使用的熱度，變化的頻率不盡相同，須要使用主從維表來解決。主維表存放穩定、產出時間早、熱度高的屬性，從表存放變化較快、產出時間晚、熱度低的屬性。

9.4.3 歷史數據歸檔

有3種歸檔策略：

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

9.4.4 維度變化

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

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

使用極限存儲，僅限於維度變化即不快又不慢的狀況，太快會致使維度數據太過龐大，太慢不須要極限存儲。並且保存維度歷史通常要求維度是枚舉值類型，若是相似積分這樣的連續值，則可能不適用。

9.4.5 特殊維度

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

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

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

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

下降事實表的粒度。好比申請書下降到以卡片爲單位。但常常事實不容許。
保留預留字段。好比申請書中預留多個卡片欄位。
使用關聯表。但複雜度高不易維護。

9.5 事實表設計

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

10、數據管理

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

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

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

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