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