阿裡巴巴資料平台總共分為四個基本層級：
資料采集層：資料采集包括日志采集和資料庫資料同步兩部分，其中日志采集包括：Aplus.JS是Web端日志采集技術方案；UserTrack是APP端日志采集技術方案。
資料計算層：阿裡巴巴的資料計算層包括兩大體系：資料存儲及計算雲平台（離線計算平台MaxCompute和實時計算平台StreamCompute）和資料整合及管理體系（内部稱之為“OneData”）。從資料計算頻率角度來看，阿裡資料倉庫可以分為離線資料倉庫和實時資料倉庫。離線資料倉庫主要是指傳統的資料倉庫概念，資料計算頻率主要以天（包含小時、周和月）為機關；如T-1，則每天淩晨處理上一天的資料。阿裡資料倉庫的資料加工鍊路也是遵循業界的分層理念，包括操作資料層（Operational Data Store，ODS）、明細資料層（Data Warehouse Detail，DWD）、彙總資料層（Data Warehouse Summary，DWS）和應用資料層（Application Data Store，ADS）。
資料服務層：資料服務層對外提供資料服務主要是通過統一的資料服務平台（為友善閱讀，簡稱為“OneService”）。OneService以資料倉庫整合計算好的資料作為資料源，對外通過接口的方式提供資料服務，主要提供簡單資料查詢服務、複雜資料查詢服務（承接集團使用者識别、使用者畫像等複雜資料查詢服務）和實時資料推送服務三大特色資料服務。
資料應用層：對内，阿裡資料平台産品主要有實時資料監控、自助式的資料網站或産品建構的資料小站、宏觀決策分析支撐平台、對象分析工具、行業資料分析門戶、流量分析平台等。對外，有服務于商家的資料産品——生意參謀。
日志采集
01、阿裡巴巴的日志采集體系方案包括兩大體系：
Aplus.JS是Web端（ 基于浏覽器）日志采集技術方案；
UserTrack是APP端（無線用戶端）日志采集技術方案。
02、浏覽器的頁面日志采集（Aplus.JS）
頁面浏覽（展現）日志采集
如果你對大資料開發感興趣，想系統學習大資料的話，可以加入大資料技術學習交流扣扣群：數字5221數字89307，私信管理者即可免費領取開發工具以及入門學習資料
顧名思義，頁面浏覽日志是指當一個頁面被浏覽器加載呈現時采集的日志。此類日志是最基礎的網際網路日志，也是目前所有網際網路産品的兩大基本名額：頁面浏覽量（Page View，PV）和訪客數（UniqueVisitors，UV）的統計基礎。
在HTML文檔内植入日志采集腳本的動作可以業務伺服器在響應業務請求時動态執行，也可以在開發頁面時由開發人員手動植入。在阿裡巴巴，這兩種方式均有采用，其中自動方式的占比較高。
頁面互動日志采集
當頁面加載和渲染完成之後，使用者可以在頁面上執行各類操作。随着網際網路前端技術的不斷發展，使用者可在浏覽器内與網頁進行的互動已經豐富到隻有想不到沒有做不到的程度，互動設計都要求采集使用者的互動行為資料，以便通過量化獲知使用者的興趣點或者體驗優化點。互動日志采集就是為此類業務場景而生的。
互動日志呈現高度自定義的業務特征（例如活動頁面的遊戲互動和購物車頁面的功能互動兩者截然不同）。在阿裡巴巴，通過“黃金令箭”的采集方案來解決互動日志的采集問題。
黃金令箭的步驟：配置中繼資料->業務方把互動日志采集代碼植入目标頁面，并将采集代碼與需要監測的互動行為做綁定->當使用者在頁面上産生互動行為時，采集代碼觸發執行。
頁面日志的服務端清洗和預處理
A、依托算法識别非正常的流量并歸納出對應的過濾規則集加以濾除。
B、資料缺項補正：例如，使用者登入後對登入前的日志做身份資訊的回補。
C、無效資料剔除：某些情況下，因業務變更或配置不當導緻的無效資料。
D、日志隔離分發：基于資料安全，某些日志在進入公共環境之前需要做隔離。
03、無線用戶端的日志采集（UserTrack）
無線用戶端的日志采集采用SDK來完成，在阿裡巴巴内部使用名為UserTrack的SDK來進行無線用戶端的日志采集。無線用戶端的日志采集和浏覽器的日志采集方式有所不同，移動端的日志采集根據不同的使用者行為分成不同的事件，“事件”為無線用戶端日志行為的最小機關。基于正常的分析，UserTrack（UT）把事件分成了幾類，常用的包括頁面事件（同前述的頁面浏覽）和控件點選事件（同前述的頁面互動）等。
頁面事件
阿裡巴巴提供了對頁面事件的無痕埋點，即無須開發者進行任何編碼即可實作。對于手動方式埋點，UT提供了兩個接口分别用于頁面展現和頁面退出時調用（這樣可以得到停留時長），還提供了添加頁面擴充資訊的接口。
為了節約計算和分析的成本，UT提供了透傳參數功能：把目前頁面的某些資訊，傳遞到下一個頁面，甚至下下個頁面的日志中。可以使用阿裡SPM超級位置模型來進行來源去向的追蹤。
控件點選及其他事件
和浏覽器用戶端的日志采集一樣，互動日志也呈現出高度自定義的業務特征。記錄了：基本的裝置資訊、使用者資訊、控件所在頁面名稱、控件名稱和控件的業務參數。
04、進階功能
無線用戶端曝光日志預聚合：可以利用無線用戶端的本地存儲進行曝光日志預聚合。
無線用戶端回退識别：由于無線用戶端存在明顯的回退行為，需要利用頁面生命周期，識别頁面的複用，配合棧的深度來識别是否是回退行為。
H5和native日志統一
APP的native頁面采用sdk進行采集，而H5頁面采用基于浏覽器的頁面日志采集方案，是以目前這是兩套不同的方案，需要一種方式進行統一。阿裡巴巴選擇将H5日志歸到Native日志的方案：H5頁面浏覽->觸發JS腳本并搜集目前頁面參數->JS腳本将所采集的資料打包到一個對象中，然後調用WebView架構的JSBridge接口，調用移動用戶端對應的接口方法，将埋點資料對象當作參數傳入。
裝置辨別
對于登入使用者，可以使用用ID進行唯一辨別，但是很多日志行為并不要求使用者登入，這就導緻很多情況下采集上來的日志都沒有使用者ID。阿裡巴巴采用UTDID方案，但就目前的進展來說，UTDID還未實作其使命。
無線用戶端日志傳輸
無線用戶端的日志傳輸，一般不是産生一條上傳一條，而是先存儲在本地，然後再伺機上傳。
05、日志采集的挑戰
日志分流與定制處理：由于資料量巨大，盡可能早的進行分流。
采集與計算一體化設計：對應于PV日志的解決方案是SPM規範（在頁面的URL内可以看見SPM參數）和SPM中繼資料中心；對應于自定義日志的解決方案是黃金令箭/APP端的日志規範及其配置中心。
2016年的雙11，阿裡日志采集浏覽等核心使用者行為日志均實作了100%全量及實時服務，支援天貓所有會場的實時推薦。在雙11中，使用者的浏覽、點選、滾屏等每個操作行為，都實時影響到後續為其推薦的商品，很好的提高了使用者體驗。
資料同步
資料同步的幾種方式：
直連同步：通過ODBC/JDBC等接口直連資料庫，對源系統性能影響較大。
資料檔案同步：簡單，實用，松耦合，可加密、可壓縮。
資料庫日志解析同步：比如oracle的ogg，對源系統影響小。需要注意的是：要根據業務系統的實際情況，選擇D删除記錄的處理邏輯。
阿裡巴巴的資料同步方式：
批量資料同步：通過DataX來實作，能滿足多方向、高自由度的異構資料交換服務産品；對于不同的資料源，能夠通過插件的形式提供支援。
實時資料同步：通過TT來實作。
資料同步遇到的問題與解決方案：
分庫分表的同步：阿裡巴巴是通過TDDL分布式資料庫引擎把多張表的通路變成單張表的通路。
增量與全量同步的合并：當然增量和前一天的全量合并，傳統是采用merge方式（update+insert），但大資料平台基本都不支援update操作，現在比較推薦的方式是：将當天的增量資料和前一天的全量資料做全外連接配接，重新加載最新的全量資料。這種方式的性能比update要高得多。
資料漂移的處理：
資料漂移是指ODS表的同一個業務日期中包含前一天或後一天淩晨附近的資料或者丢失當天的變更資料。
處理方法：多擷取一部分第二天的資料（比如跨日以後的15分鐘），然後根據可以判斷業務時間的字段，過濾，排序等方式來得到需要的資料。
阿裡的上述方法，涉及到排序，其實代價也是有點高的，如果沒有标準的處理子產品，自己寫起邏輯來也是有些麻煩。很多情況下，如果資料稍微差一點關系不大的業務，我們都選擇不做處理。
資料計算層
一、阿裡巴巴的資料計算層包括：
資料存儲及計算平台（離線計算平台MaxCompute和實時計算平台StreamCompute）
資料整合及管理體系（OneData）
二、統一計算平台MaxCompute（離線）
有幾萬台機器，存儲近1000PB
功能元件：SQL、MR、Graph、Spark、R、Volume
三、統一開發平台
D2（在雲端）：內建任務開發、調試及釋出，生産任務排程及大資料運維，資料權限申請及管理等功能的一站式資料開發平台，并能承擔資料分析工作台的功能。
使用D2進行資料開發的基本流程：使用者使用IDE進行計算節點的建立，可以是SQL/MR任務，也可以是Shell任務等，設定好節點屬性及依賴關系，進行試運作，并可以釋出到生産環境。
SQLSCAN：包括代碼規範類規則檢查（命名規範等）、代碼品質類規則檢查（分母為0等）、代碼性能類規則檢查（大表掃描等）。
DQC：資料品質監控規則包括--主鍵監控、表資料量及波動監控、重要字段的非空監控、重要枚舉字段的離散值監控、名額值波動監控、業務規則監控等。阿裡資料倉庫采用非侵入式清洗政策，在資料同步過程中不進行清洗，避免影響同步效率，在資料進入ODS層之後進行清洗。
在彼岸：用于大資料系統的自動化測試平台，将通用性、重複性的操作沉澱在測試平台中，避免被“人肉”，提高測試效率。
在彼岸--資料對比：表級對比規則主要包括資料量和全文對比；字段級對比規則主要包括字段的統計值（如sum、avg、max、min等）、枚舉值、空值、去重數、長度值等。
在彼岸-資料分布：提取表和字段的一些特征值，并将這些特征值與預期值進行比對。表級資料特征提取主要包括資料量、主鍵等；字段級資料特征提取主要包括字段枚舉值分布、空值分布、統計值、去重數、長度值等。
資料脫敏：将敏感資料模糊化。
四、任務排程系統
排程配置：正常的配置是手工方式，如果出錯；阿裡巴巴采用手工配置和自動識别相結合的方式。任務送出時，SQL解析引擎自動識别此任務的輸入表和輸出表，輸入表自動關聯産出此表的任務，輸出表亦然。通過此種方式，解決了上述問題，可以自動調整任務依賴，避免依賴配置錯誤。
五、資料時效性
離線：延遲時間粒度為天；準實時：延遲時間粒度為小時；實時：延遲時間粒度為秒。
離線和準實時都可以在批處理系統中實作，比如Hadoop、MaxCompute等，隻是排程周期不一樣而已，而實時資料則需要在流式處理系統中完成。
六、流式技術架構：流式技術架構中的系統跟離線處理是有交叉的，兩套技術方案并不是完全獨立的，并且在業界中有合并的趨勢。
資料采集
不管是資料庫變更日志，還是引擎通路日志，都會在伺服器上落地成檔案，是以隻要監控檔案的内容發生變化，采集工具就可以把最新的資料采集下來。一般情況下，出于吞吐量以及系統壓力上的考慮，并不是新增一條記錄就采集一次，而是基于下面的原則，按批次對資料進行采集：資料大小限制原則--當資料大小達到限制條件時觸發采集；時間門檻值原則--當時間達到一定條件時觸發采集。實時采集下來的資料一般放入資料中間件，比如Kafka、TimeTunnel等。
資料處理
實時處理計算引擎有Storm、SparkStreaming、Flink、StreamingCompute等。StreamingCompute：在Storm基礎上包裝一層SQL語義，友善開發人員通過寫SQL就可以實作實時計算，而不需要關心計算狀态細節；當然，它也支援傳統模式的開發；還提供了流計算開發平台，在這個平台上就可以完成應用的相關運維工作，而不需要登入伺服器操作，極大提高運維效率。
實時資料處理遇到的幾個典型問題：
A、去重名額：模糊去重的第一個--布隆過濾器在實時名額計算中的應用；模糊去重的第二個方法--基數估計，估算的去重值可能比真實值小，也可以大，存儲1億條資料隻需要幾KB的記憶體，适用統計精讀要求不高，統計次元非常粗的情況，比如整個大盤的UV資料，基數估計在各個次元值之間不能共用，比如統計全天小時的UV資料，就需要有24個基數估計對象。
B、資料傾斜：資料傾斜是ETL中經常遇到的問題，比如計算一天中全網訪客數或者成交額時，最終的結果隻有1個，通常應該是在一個節點上完成相關的計算任務。是以，在資料量非常大的時候，單個節點的處理能力是有限的，就需要進行分桶處理，充分利用每個桶的CPU和記憶體資源。第一種情況是去重名額分桶--通過對去重值進行分桶Hash，相同的值一定會被放在同一個桶中去重，最後再把每個桶裡面的值進行加和得到總值；第二種情況是非去重名額分桶--此時資料随機分發到每個桶中，最後再把每個桶的值彙總。
C、事務處理：上面提到的幾個流計算系統幾乎都提供了資料自動ACK、失敗重發以及事務資訊等機制，這些機制都是為了保證資料的幂等性。
資料存儲
在實踐中一般使用HBase、MongoDB等列式存儲系統，這些系統的讀寫效率都能達到毫秒級。但是這些系統的缺點也是明顯的，以HBase為例，一張表必須要有rowkey，而rowkey是按照ASCII碼來排序的，這就像關系型資料庫的索引一樣，rowkkey的規則限制了讀取資料的方式，如果業務方需要使用另一種讀取資料的方式，則必須重新輸出rowkey。從這個角度來看，HBase沒有關系資料庫友善，但HBase可以存儲幾十TB的海量資料庫，而關系資料庫必須要分庫分表才能實作這個量級的資料存儲。是以，對于海量資料的實時計算，一般會采用NoSql資料庫，以應對大量的多并發讀寫。
資料服務：實時資料落地到存儲系統後，使用方就可以通過OneService等把資料對外進行共享。
流式資料模型：實時資料模型是離線資料模型的一個子集，在實時資料處理過程中，很多模型設計就是參考離線資料模型實作的。
資料分層：ODS（實時接口層）、DWD（實時明細資料層）、DWS（實時通用彙總層）、ADS（實時個性化次元彙總層）、DIM（維表層）。一般ODS和DWD會放在資料中間件中，供下遊訂閱使用，而DWS和ADS會落地到線上存儲系統中，DIM一般離線處理。在每一層中，可以按照重要性劃分等級，優先保障最高等級的實時任務。
通過一個簡單的例子來說明每一層存儲的資料：
A、ODS層：訂單粒度的變更過程，一筆訂單有多條記錄。
B、DWD層：訂單粒度的支付記錄，一筆訂單隻有一條記錄。
C、DWS層：賣家的實時成交金額，一個賣家隻有一條記錄，并且名額在實時重新整理。
D、ADS層：外賣地區的實時成交金額，隻有外賣業務使用。
E、DIM層：訂單商品類目和行業的對應關系維表。
多流關聯：實時采集兩張表的資料，每到來一條新資料時都在對方記憶體表截止目前的全量資料中查找，如果能找到則說明關聯成功直接輸出，否則需要把資料放在記憶體中的自己表資料集合中等待。另外，不管是否關聯成功，記憶體資料都需要備份到外部存儲系統中。還有，訂單記錄的變更可能發生多次，需要根據訂單ID去重，避免A表和B表多次關聯成功。同時，考慮到記憶體關聯查找資料的性能，一般會把資料按照關聯主鍵進行分桶處理。
維表使用：在實時計算中，一般會使用目前的實時資料（T）去關聯T-2的維表資料。因為到達零點時，T-1的維表資料還沒準備好，是以一般在實時計算中維表關聯都統一使用T-2的資料，這樣對于業務來說，起碼關聯到的維表資料是确定的（雖然維表資料有一定的延時，但是許多業務的維表在兩天之間變化是很少的）。如果維表資料量不是特别大，可以全量加載到記憶體使用；如果維表資料量特别大，則可以增量查找和LRU過期的形式，讓最熱門的資料留在記憶體中。
資料服務層
阿裡資料服務架構演進過程如下：
DWSOA：一個需求一個接口，編碼實作接口，接口數量5000/年。開發效率低，投入成本高，擴充性差。
OpenAPI：一類需求一個接口，配置實作接口，接口數量200/年。相比上一種方式，這種方式有效收斂了數量。
SmartDQ：所有需求一個接口，配置實作接口，接口數量1，缺點是服務形式不夠豐富，隻能滿足簡單的查詢服務需求（畢竟SQL并不能解決複雜的業務邏輯）。SmartDQ通過在OpenAPI的基礎上，再抽象一層，用DSL（領域專用語言）來描述取數需求，新做一套DSL必然有學習成本，是以采用标準的SQL文法。
OneService：提供多種服務類型來滿足使用者需求。
A、OneService-SmartDQ：通過SQL文法提供簡單的查詢服務需求。
B、OneService-Lego：采用插件方式滿足個性化需求，為了避免插件之間互相影響，我們将插件做成微服務，使用Docker做隔離。Lego可以采用輕量級的Node.JS技術棧實作，适合處理高并發、低延遲的IO密集型場景。
C、OneService-iPush：主要提供websocket和long polling兩種方式，其應用場景主要是商家端實時直播。比如雙11，此時使用websocket方式可以有效緩解伺服器壓力，給使用者帶來最實時的體驗。
D、OneService-uTiming：主要提供即時任務和定時任務兩種模式，其主要應用場景是滿足使用者運作大資料量任務的需求。
最佳實踐：
資源配置設定：複雜的計算邏輯可以提前計算；Get接口隻傳回一條記錄，查詢代價小響應時間短，List接口傳回多條記錄，查詢時間相對較長，可以設計Get線程池和List線程池兩個獨立的線程池避免Get接口和List接口互相影響；查詢可以在引擎層自動進行拆分查詢，然後再把查詢結果進行合并。
緩存優化：中繼資料緩存、模型緩存、結果緩存。
查詢能力：由于離線資料和實時資料存放在不同地方，并且離線資料最準确，需要優先使用離線資料，如果離線資料還未産出，則改用實時資料，這就是要對離線和實時進行合并查詢；能采用推送的，就不采用輪詢，因為輪詢對伺服器壓力大。
限流、降級：限流就是直接降到0，降級就是隻将存在問題的資源置為失效狀态。
資料挖掘中台
2012年以前，由于資料的規模還不是特别龐大，大部分挖掘應用所需處理的樣本量在百萬以内，而處理的特征一般也少于100維，那時像SAS、SPSS、Clementine等單機版的資料挖掘軟體已經能滿足大部分挖掘應用的需求。
随着資料量的爆炸，如今挖掘平台面對的訓練資料量動辄上億，特征次元動辄百萬，是以需要分布式、可視化的資料挖掘算法平台。
就資料挖掘的商業場景而言，可以分為兩大類：個體挖掘和關系挖掘。個體挖掘是指對單個實體的行為特征進行預測與分析，關系挖掘是指研究多個實體間的關系特征，如商品的相似關系和競争關系。
就資料挖掘的技術而言，可以分為兩大類：資料挖掘資料中台、資料挖掘算法中台。
1、資料中台
資料挖掘的過程中包括兩類資料：特征資料和結果資料。算法需要的特征變量就是特征資料，算法最終輸出的商品銷量的預測結果就是結果資料。
對于特征資料，挖掘項目中80%的時間可能都是在處理特征，這些特征的提取、清洗、标準化以及基于業務場景的再組合和二次加工往往工作繁重。是以，就想到可以按照标準、規範建構一個全局特征庫，每個挖掘工程師隻需通路幾張實體表就能迅速搜集到大部分自己想要的特征。
對于結果資料，可以進行分層存儲：通用結果和個性化結果。
基于以上分析，可以把挖掘資料中台分為三層：特征層FDM（Featural Data Mining Layer）、個體中間層IDM（Individual Data Mining Layer）、關系中間層RDM（Relational Data Mining Layer）和應用層ADM（Application-oriented Data Mining Layer）；分層架構見下圖。
特征層：用于存儲在模型訓練前常用的特征名額，并進行統一的清洗和去噪處理。
中間層：個體中間層IDM和關系中間層RDM統一稱為中間層。其中，IDM面向個體挖掘場景，用于存儲通用性強的結果資料；RDM面向關系挖掘場景，用于存儲通用性強的結果資料。
應用層：用來沉澱比較個性應用的資料挖掘結果名額。
2、算法平台
算法中台的建設目的是從各種各樣的挖掘場景中抽象出有代表性的幾類場景，并形成相應的方法論和實操模闆。
比較有代表性的資料挖掘應用場景：