阿里巴巴數(shù)據(jù)平臺總共分為四個基本層級：

數(shù)據(jù)采集層：數(shù)據(jù)采集包括日志采集和數(shù)據(jù)庫數(shù)據(jù)同步兩部分厕宗，其中日志采集包括：Aplus.JS是Web端日志采集技術(shù)方案画舌；UserTrack是APP端日志采集技術(shù)方案。

數(shù)據(jù)計算層：阿里巴巴的數(shù)據(jù)計算層包括兩大體系：數(shù)據(jù)存儲及計算云平臺（離線計算平臺MaxCompute和實時計算平臺StreamCompute）和數(shù)據(jù)整合及管理體系（內(nèi)部稱之為“OneData”）已慢。從數(shù)據(jù)計算頻率角度來看曲聂，阿里數(shù)據(jù)倉庫可以分為離線數(shù)據(jù)倉庫和實時數(shù)據(jù)倉庫。離線數(shù)據(jù)倉庫主要是指傳統(tǒng)的數(shù)據(jù)倉庫概念佑惠，數(shù)據(jù)計算頻率主要以天（包含小時朋腋、周和月）為單位；如T-1膜楷，則每天凌晨處理上一天的數(shù)據(jù)乍丈。阿里數(shù)據(jù)倉庫的數(shù)據(jù)加工鏈路也是遵循業(yè)界的分層理念，包括操作數(shù)據(jù)層（Operational Data Store把将，ODS）轻专、明細(xì)數(shù)據(jù)層（Data Warehouse Detail，DWD）察蹲、匯總數(shù)據(jù)層（Data Warehouse Summary请垛，DWS）和應(yīng)用數(shù)據(jù)層（Application Data Store催训，ADS）。

數(shù)據(jù)服務(wù)層：數(shù)據(jù)服務(wù)層對外提供數(shù)據(jù)服務(wù)主要是通過統(tǒng)一的數(shù)據(jù)服務(wù)平臺（為方便閱讀宗收，簡稱為“OneService”）漫拭。OneService以數(shù)據(jù)倉庫整合計算好的數(shù)據(jù)作為數(shù)據(jù)源，對外通過接口的方式提供數(shù)據(jù)服務(wù)混稽，主要提供簡單數(shù)據(jù)查詢服務(wù)采驻、復(fù)雜數(shù)據(jù)查詢服務(wù)（承接集團用戶識別、用戶畫像等復(fù)雜數(shù)據(jù)查詢服務(wù)）和實時數(shù)據(jù)推送服務(wù)三大特色數(shù)據(jù)服務(wù)匈勋。

數(shù)據(jù)應(yīng)用層：對內(nèi)礼旅，阿里數(shù)據(jù)平臺產(chǎn)品主要有實時數(shù)據(jù)監(jiān)控、自助式的數(shù)據(jù)網(wǎng)站或產(chǎn)品構(gòu)建的數(shù)據(jù)小站洽洁、宏觀決策分析支撐平臺痘系、對象分析工具、行業(yè)數(shù)據(jù)分析門戶饿自、流量分析平臺等汰翠。對外，有服務(wù)于商家的數(shù)據(jù)產(chǎn)品——生意參謀昭雌。

日志采集

01复唤、阿里巴巴的日志采集體系方案包括兩大體系：

Aplus.JS是Web端（ 基于瀏覽器）日志采集技術(shù)方案；

UserTrack是APP端（無線客戶端）日志采集技術(shù)方案烛卧。

02佛纫、瀏覽器的頁面日志采集（Aplus.JS）

頁面瀏覽（展現(xiàn)）日志采集

您想了解大數(shù)據(jù)領(lǐng)域的哪些相關(guān)問題，也歡迎給我們留言唱星。【大數(shù)據(jù)開發(fā)學(xué)習(xí)資料領(lǐng)取方式】：加入大數(shù)據(jù)技術(shù)學(xué)習(xí)交流扣扣群522189307雳旅，私信管理員即可免費領(lǐng)取開發(fā)工具以及入門學(xué)習(xí)資料

顧名思義跟磨，頁面瀏覽日志是指當(dāng)一個頁面被瀏覽器加載呈現(xiàn)時采集的日志间聊。此類日志是最基礎(chǔ)的互聯(lián)網(wǎng)日志，也是目前所有互聯(lián)網(wǎng)產(chǎn)品的兩大基本指標(biāo)：頁面瀏覽量（Page View抵拘，PV）和訪客數(shù)（UniqueVisitors哎榴，UV）的統(tǒng)計基礎(chǔ)。

在HTML文檔內(nèi)植入日志采集腳本的動作可以業(yè)務(wù)服務(wù)器在響應(yīng)業(yè)務(wù)請求時動態(tài)執(zhí)行僵蛛，也可以在開發(fā)頁面時由開發(fā)人員手動植入尚蝌。在阿里巴巴，這兩種方式均有采用充尉，其中自動方式的占比較高飘言。

頁面交互日志采集

當(dāng)頁面加載和渲染完成之后，用戶可以在頁面上執(zhí)行各類操作驼侠。隨著互聯(lián)網(wǎng)前端技術(shù)的不斷發(fā)展姿鸿，用戶可在瀏覽器內(nèi)與網(wǎng)頁進行的互動已經(jīng)豐富到只有想不到?jīng)]有做不到的程度谆吴，互動設(shè)計都要求采集用戶的互動行為數(shù)據(jù)，以便通過量化獲知用戶的興趣點或者體驗優(yōu)化點苛预。交互日志采集就是為此類業(yè)務(wù)場景而生的。

交互日志呈現(xiàn)高度自定義的業(yè)務(wù)特征（例如活動頁面的游戲交互和購物車頁面的功能交互兩者截然不同）。在阿里巴巴蚂会，通過“黃金令箭”的采集方案來解決交互日志的采集問題园细。

黃金令箭的步驟：配置元數(shù)據(jù)->業(yè)務(wù)方把交互日志采集代碼植入目標(biāo)頁面，并將采集代碼與需要監(jiān)測的交互行為做綁定->當(dāng)用戶在頁面上產(chǎn)生交互行為時昔馋，采集代碼觸發(fā)執(zhí)行筹吐。

頁面日志的服務(wù)端清洗和預(yù)處理

A、依托算法識別非正常的流量并歸納出對應(yīng)的過濾規(guī)則集加以濾除绒极。

B骏令、數(shù)據(jù)缺項補正：例如，用戶登錄后對登錄前的日志做身份信息的回補垄提。

C榔袋、無效數(shù)據(jù)剔除：某些情況下，因業(yè)務(wù)變更或配置不當(dāng)導(dǎo)致的無效數(shù)據(jù)铡俐。

D凰兑、日志隔離分發(fā)：基于數(shù)據(jù)安全，某些日志在進入公共環(huán)境之前需要做隔離审丘。

03吏够、無線客戶端的日志采集（UserTrack）

無線客戶端的日志采集采用SDK來完成，在阿里巴巴內(nèi)部使用名為UserTrack的SDK來進行無線客戶端的日志采集滩报。無線客戶端的日志采集和瀏覽器的日志采集方式有所不同锅知，移動端的日志采集根據(jù)不同的用戶行為分成不同的事件，“事件”為無線客戶端日志行為的最小單位脓钾∈鄱茫基于常規(guī)的分析，UserTrack（UT）把事件分成了幾類可训，常用的包括頁面事件（同前述的頁面瀏覽）和控件點擊事件（同前述的頁面交互）等昌妹。

頁面事件

阿里巴巴提供了對頁面事件的無痕埋點，即無須開發(fā)者進行任何編碼即可實現(xiàn)握截。對于手動方式埋點飞崖，UT提供了兩個接口分別用于頁面展現(xiàn)和頁面退出時調(diào)用（這樣可以得到停留時長），還提供了添加頁面擴展信息的接口谨胞。

為了節(jié)約計算和分析的成本固歪，UT提供了透傳參數(shù)功能：把當(dāng)前頁面的某些信息，傳遞到下一個頁面胯努，甚至下下個頁面的日志中牢裳∈跷停可以使用阿里SPM超級位置模型來進行來源去向的追蹤。

控件點擊及其他事件

和瀏覽器客戶端的日志采集一樣贰健，交互日志也呈現(xiàn)出高度自定義的業(yè)務(wù)特征胞四。記錄了：基本的設(shè)備信息、用戶信息伶椿、控件所在頁面名稱辜伟、控件名稱和控件的業(yè)務(wù)參數(shù)。

04脊另、高級功能

無線客戶端曝光日志預(yù)聚合：可以利用無線客戶端的本地存儲進行曝光日志預(yù)聚合导狡。

無線客戶端回退識別：由于無線客戶端存在明顯的回退行為，需要利用頁面生命周期偎痛，識別頁面的復(fù)用旱捧，配合棧的深度來識別是否是回退行為。

H5和native日志統(tǒng)一

APP的native頁面采用sdk進行采集踩麦，而H5頁面采用基于瀏覽器的頁面日志采集方案枚赡，因此目前這是兩套不同的方案，需要一種方式進行統(tǒng)一谓谦。阿里巴巴選擇將H5日志歸到Native日志的方案：H5頁面瀏覽->觸發(fā)JS腳本并搜集當(dāng)前頁面參數(shù)->JS腳本將所采集的數(shù)據(jù)打包到一個對象中贫橙，然后調(diào)用WebView框架的JSBridge接口，調(diào)用移動客戶端對應(yīng)的接口方法反粥，將埋點數(shù)據(jù)對象當(dāng)作參數(shù)傳入卢肃。

設(shè)備標(biāo)識

對于登錄用戶，可以使用用ID進行唯一標(biāo)識才顿，但是很多日志行為并不要求用戶登錄莫湘，這就導(dǎo)致很多情況下采集上來的日志都沒有用戶ID。阿里巴巴采用UTDID方案郑气，但就目前的進展來說幅垮，UTDID還未實現(xiàn)其使命。

無線客戶端日志傳輸

無線客戶端的日志傳輸竣贪，一般不是產(chǎn)生一條上傳一條军洼，而是先存儲在本地巩螃，然后再伺機上傳演怎。

05、日志采集的挑戰(zhàn)

日志分流與定制處理：由于數(shù)據(jù)量巨大避乏，盡可能早的進行分流爷耀。

采集與計算一體化設(shè)計：對應(yīng)于PV日志的解決方案是SPM規(guī)范（在頁面的URL內(nèi)可以看見SPM參數(shù)）和SPM元數(shù)據(jù)中心；對應(yīng)于自定義日志的解決方案是黃金令箭/APP端的日志規(guī)范及其配置中心拍皮。

2016年的雙11歹叮，阿里日志采集瀏覽等核心用戶行為日志均實現(xiàn)了100%全量及實時服務(wù)跑杭，支持天貓所有會場的實時推薦。在雙11中咆耿，用戶的瀏覽德谅、點擊、滾屏等每個操作行為萨螺，都實時影響到后續(xù)為其推薦的商品窄做，很好的提高了用戶體驗。

數(shù)據(jù)同步

數(shù)據(jù)同步的幾種方式：

直連同步：通過ODBC/JDBC等接口直連數(shù)據(jù)庫慰技，對源系統(tǒng)性能影響較大椭盏。

數(shù)據(jù)文件同步：簡單，實用吻商，松耦合掏颊，可加密、可壓縮艾帐。

數(shù)據(jù)庫日志解析同步：比如oracle的ogg乌叶，對源系統(tǒng)影響小。需要注意的是：要根據(jù)業(yè)務(wù)系統(tǒng)的實際情況柒爸，選擇D刪除記錄的處理邏輯枉昏。

阿里巴巴的數(shù)據(jù)同步方式：

批量數(shù)據(jù)同步：通過DataX來實現(xiàn)，能滿足多方向揍鸟、高自由度的異構(gòu)數(shù)據(jù)交換服務(wù)產(chǎn)品兄裂；對于不同的數(shù)據(jù)源，能夠通過插件的形式提供支持阳藻。

實時數(shù)據(jù)同步：通過TT來實現(xiàn)晰奖。

數(shù)據(jù)同步遇到的問題與解決方案：

分庫分表的同步：阿里巴巴是通過TDDL分布式數(shù)據(jù)庫引擎把多張表的訪問變成單張表的訪問。

增量與全量同步的合并：當(dāng)然增量和前一天的全量合并腥泥，傳統(tǒng)是采用merge方式（update+insert）匾南，但大數(shù)據(jù)平臺基本都不支持update操作，現(xiàn)在比較推薦的方式是：將當(dāng)天的增量數(shù)據(jù)和前一天的全量數(shù)據(jù)做全外連接蛔外，重新加載最新的全量數(shù)據(jù)蛆楞。這種方式的性能比update要高得多。

數(shù)據(jù)漂移的處理：

數(shù)據(jù)漂移是指ODS表的同一個業(yè)務(wù)日期中包含前一天或后一天凌晨附近的數(shù)據(jù)或者丟失當(dāng)天的變更數(shù)據(jù)夹厌。

處理方法：多獲取一部分第二天的數(shù)據(jù)（比如跨日以后的15分鐘）豹爹，然后根據(jù)可以判斷業(yè)務(wù)時間的字段，過濾矛纹，排序等方式來得到需要的數(shù)據(jù)臂聋。

阿里的上述方法，涉及到排序，其實代價也是有點高的孩等，如果沒有標(biāo)準(zhǔn)的處理模塊艾君，自己寫起邏輯來也是有些麻煩。很多情況下肄方，如果數(shù)據(jù)稍微差一點關(guān)系不大的業(yè)務(wù)冰垄，我們都選擇不做處理。

數(shù)據(jù)計算層

一权她、阿里巴巴的數(shù)據(jù)計算層包括：

數(shù)據(jù)存儲及計算平臺（離線計算平臺MaxCompute和實時計算平臺StreamCompute）

數(shù)據(jù)整合及管理體系（OneData）

二播演、統(tǒng)一計算平臺MaxCompute（離線）

有幾萬臺機器，存儲近1000PB

功能組件：SQL伴奥、MR写烤、Graph、Spark拾徙、R洲炊、Volume

三、統(tǒng)一開發(fā)平臺

D2（在云端）：集成任務(wù)開發(fā)尼啡、調(diào)試及發(fā)布暂衡，生產(chǎn)任務(wù)調(diào)度及大數(shù)據(jù)運維，數(shù)據(jù)權(quán)限申請及管理等功能的一站式數(shù)據(jù)開發(fā)平臺崖瞭，并能承擔(dān)數(shù)據(jù)分析工作臺的功能狂巢。

使用D2進行數(shù)據(jù)開發(fā)的基本流程：用戶使用IDE進行計算節(jié)點的創(chuàng)建，可以是SQL/MR任務(wù)书聚，也可以是Shell任務(wù)等唧领，設(shè)置好節(jié)點屬性及依賴關(guān)系，進行試運行雌续，并可以發(fā)布到生產(chǎn)環(huán)境斩个。

SQLSCAN：包括代碼規(guī)范類規(guī)則檢查（命名規(guī)范等）、代碼質(zhì)量類規(guī)則檢查（分母為0等）驯杜、代碼性能類規(guī)則檢查（大表掃描等）受啥。

DQC：數(shù)據(jù)質(zhì)量監(jiān)控規(guī)則包括--主鍵監(jiān)控、表數(shù)據(jù)量及波動監(jiān)控鸽心、重要字段的非空監(jiān)控滚局、重要枚舉字段的離散值監(jiān)控、指標(biāo)值波動監(jiān)控顽频、業(yè)務(wù)規(guī)則監(jiān)控等藤肢。阿里數(shù)據(jù)倉庫采用非侵入式清洗策略，在數(shù)據(jù)同步過程中不進行清洗冲九，避免影響同步效率谤草，在數(shù)據(jù)進入ODS層之后進行清洗。

在彼岸：用于大數(shù)據(jù)系統(tǒng)的自動化測試平臺莺奸，將通用性丑孩、重復(fù)性的操作沉淀在測試平臺中，避免被“人肉”灭贷，提高測試效率温学。

在彼岸--數(shù)據(jù)對比：表級對比規(guī)則主要包括數(shù)據(jù)量和全文對比；字段級對比規(guī)則主要包括字段的統(tǒng)計值（如sum甚疟、avg仗岖、max、min等）览妖、枚舉值轧拄、空值、去重數(shù)讽膏、長度值等檩电。

在彼岸-數(shù)據(jù)分布：提取表和字段的一些特征值，并將這些特征值與預(yù)期值進行比對府树。表級數(shù)據(jù)特征提取主要包括數(shù)據(jù)量俐末、主鍵等；字段級數(shù)據(jù)特征提取主要包括字段枚舉值分布奄侠、空值分布卓箫、統(tǒng)計值、去重數(shù)垄潮、長度值等烹卒。

數(shù)據(jù)脫敏：將敏感數(shù)據(jù)模糊化。

四弯洗、任務(wù)調(diào)度系統(tǒng)

調(diào)度配置：常規(guī)的配置是手工方式甫题，如果出錯；阿里巴巴采用手工配置和自動識別相結(jié)合的方式涂召。任務(wù)提交時坠非，SQL解析引擎自動識別此任務(wù)的輸入表和輸出表，輸入表自動關(guān)聯(lián)產(chǎn)出此表的任務(wù)果正，輸出表亦然炎码。通過此種方式，解決了上述問題秋泳，可以自動調(diào)整任務(wù)依賴潦闲，避免依賴配置錯誤。

五迫皱、數(shù)據(jù)時效性

離線：延遲時間粒度為天歉闰；準(zhǔn)實時：延遲時間粒度為小時辖众；實時：延遲時間粒度為秒。

離線和準(zhǔn)實時都可以在批處理系統(tǒng)中實現(xiàn)和敬，比如Hadoop凹炸、MaxCompute等，只是調(diào)度周期不一樣而已昼弟，而實時數(shù)據(jù)則需要在流式處理系統(tǒng)中完成啤它。

六、流式技術(shù)架構(gòu)：流式技術(shù)架構(gòu)中的系統(tǒng)跟離線處理是有交叉的舱痘，兩套技術(shù)方案并不是完全獨立的变骡，并且在業(yè)界中有合并的趨勢。

數(shù)據(jù)采集

不管是數(shù)據(jù)庫變更日志芭逝，還是引擎訪問日志塌碌，都會在服務(wù)器上落地成文件，所以只要監(jiān)控文件的內(nèi)容發(fā)生變化旬盯，采集工具就可以把最新的數(shù)據(jù)采集下來誊爹。一般情況下，出于吞吐量以及系統(tǒng)壓力上的考慮瓢捉，并不是新增一條記錄就采集一次频丘，而是基于下面的原則，按批次對數(shù)據(jù)進行采集：數(shù)據(jù)大小限制原則--當(dāng)數(shù)據(jù)大小達(dá)到限制條件時觸發(fā)采集泡态；時間閾值原則--當(dāng)時間達(dá)到一定條件時觸發(fā)采集搂漠。實時采集下來的數(shù)據(jù)一般放入數(shù)據(jù)中間件，比如Kafka某弦、TimeTunnel等桐汤。

數(shù)據(jù)處理

實時處理計算引擎有Storm、SparkStreaming靶壮、Flink怔毛、StreamingCompute等。StreamingCompute：在Storm基礎(chǔ)上包裝一層SQL語義腾降，方便開發(fā)人員通過寫SQL就可以實現(xiàn)實時計算拣度，而不需要關(guān)心計算狀態(tài)細(xì)節(jié)；當(dāng)然螃壤，它也支持傳統(tǒng)模式的開發(fā)抗果；還提供了流計算開發(fā)平臺，在這個平臺上就可以完成應(yīng)用的相關(guān)運維工作奸晴，而不需要登錄服務(wù)器操作冤馏，極大提高運維效率。

實時數(shù)據(jù)處理遇到的幾個典型問題：

A寄啼、去重指標(biāo)：模糊去重的第一個--布隆過濾器在實時指標(biāo)計算中的應(yīng)用逮光；模糊去重的第二個方法--基數(shù)估計代箭，估算的去重值可能比真實值小，也可以大涕刚，存儲1億條數(shù)據(jù)只需要幾KB的內(nèi)存嗡综，適用統(tǒng)計精讀要求不高，統(tǒng)計維度非常粗的情況副女，比如整個大盤的UV數(shù)據(jù)蛤高，基數(shù)估計在各個維度值之間不能共用蚣旱，比如統(tǒng)計全天小時的UV數(shù)據(jù)碑幅，就需要有24個基數(shù)估計對象。

B塞绿、數(shù)據(jù)傾斜：數(shù)據(jù)傾斜是ETL中經(jīng)常遇到的問題沟涨，比如計算一天中全網(wǎng)訪客數(shù)或者成交額時，最終的結(jié)果只有1個异吻，通常應(yīng)該是在一個節(jié)點上完成相關(guān)的計算任務(wù)裹赴。因此，在數(shù)據(jù)量非常大的時候诀浪，單個節(jié)點的處理能力是有限的棋返，就需要進行分桶處理，充分利用每個桶的CPU和內(nèi)存資源雷猪。第一種情況是去重指標(biāo)分桶--通過對去重值進行分桶Hash睛竣，相同的值一定會被放在同一個桶中去重，最后再把每個桶里面的值進行加和得到總值求摇；第二種情況是非去重指標(biāo)分桶--此時數(shù)據(jù)隨機分發(fā)到每個桶中射沟，最后再把每個桶的值匯總。

C与境、事務(wù)處理：上面提到的幾個流計算系統(tǒng)幾乎都提供了數(shù)據(jù)自動ACK验夯、失敗重發(fā)以及事務(wù)信息等機制，這些機制都是為了保證數(shù)據(jù)的冪等性摔刁。

數(shù)據(jù)存儲

在實踐中一般使用HBase挥转、MongoDB等列式存儲系統(tǒng)，這些系統(tǒng)的讀寫效率都能達(dá)到毫秒級共屈。但是這些系統(tǒng)的缺點也是明顯的扁位，以HBase為例，一張表必須要有rowkey趁俊，而rowkey是按照ASCII碼來排序的域仇，這就像關(guān)系型數(shù)據(jù)庫的索引一樣，rowkkey的規(guī)則限制了讀取數(shù)據(jù)的方式寺擂，如果業(yè)務(wù)方需要使用另一種讀取數(shù)據(jù)的方式暇务，則必須重新輸出rowkey泼掠。從這個角度來看，HBase沒有關(guān)系數(shù)據(jù)庫方便垦细，但HBase可以存儲幾十TB的海量數(shù)據(jù)庫择镇，而關(guān)系數(shù)據(jù)庫必須要分庫分表才能實現(xiàn)這個量級的數(shù)據(jù)存儲。因此括改，對于海量數(shù)據(jù)的實時計算腻豌，一般會采用NoSql數(shù)據(jù)庫，以應(yīng)對大量的多并發(fā)讀寫嘱能。

數(shù)據(jù)服務(wù)：實時數(shù)據(jù)落地到存儲系統(tǒng)后吝梅，使用方就可以通過OneService等把數(shù)據(jù)對外進行共享。

流式數(shù)據(jù)模型：實時數(shù)據(jù)模型是離線數(shù)據(jù)模型的一個子集惹骂，在實時數(shù)據(jù)處理過程中苏携，很多模型設(shè)計就是參考離線數(shù)據(jù)模型實現(xiàn)的。

數(shù)據(jù)分層：ODS（實時接口層）对粪、DWD（實時明細(xì)數(shù)據(jù)層）右冻、DWS（實時通用匯總層）、ADS（實時個性化維度匯總層）著拭、DIM（維表層）纱扭。一般ODS和DWD會放在數(shù)據(jù)中間件中，供下游訂閱使用儡遮，而DWS和ADS會落地到在線存儲系統(tǒng)中乳蛾，DIM一般離線處理。在每一層中峦萎，可以按照重要性劃分等級屡久，優(yōu)先保障最高等級的實時任務(wù)。

通過一個簡單的例子來說明每一層存儲的數(shù)據(jù)：

A爱榔、ODS層：訂單粒度的變更過程被环，一筆訂單有多條記錄。

B详幽、DWD層：訂單粒度的支付記錄筛欢，一筆訂單只有一條記錄。

C唇聘、DWS層：賣家的實時成交金額版姑，一個賣家只有一條記錄，并且指標(biāo)在實時刷新迟郎。

D剥险、ADS層：外賣地區(qū)的實時成交金額，只有外賣業(yè)務(wù)使用宪肖。

E表制、DIM層：訂單商品類目和行業(yè)的對應(yīng)關(guān)系維表健爬。

多流關(guān)聯(lián)：實時采集兩張表的數(shù)據(jù)，每到來一條新數(shù)據(jù)時都在對方內(nèi)存表截止當(dāng)前的全量數(shù)據(jù)中查找么介，如果能找到則說明關(guān)聯(lián)成功直接輸出娜遵，否則需要把數(shù)據(jù)放在內(nèi)存中的自己表數(shù)據(jù)集合中等待。另外壤短，不管是否關(guān)聯(lián)成功设拟，內(nèi)存數(shù)據(jù)都需要備份到外部存儲系統(tǒng)中。還有久脯，訂單記錄的變更可能發(fā)生多次纳胧，需要根據(jù)訂單ID去重，避免A表和B表多次關(guān)聯(lián)成功桶现。同時躲雅，考慮到內(nèi)存關(guān)聯(lián)查找數(shù)據(jù)的性能鼎姊，一般會把數(shù)據(jù)按照關(guān)聯(lián)主鍵進行分桶處理骡和。

維表使用：在實時計算中，一般會使用當(dāng)前的實時數(shù)據(jù)（T）去關(guān)聯(lián)T-2的維表數(shù)據(jù)相寇。因為到達(dá)零點時慰于，T-1的維表數(shù)據(jù)還沒準(zhǔn)備好，所以一般在實時計算中維表關(guān)聯(lián)都統(tǒng)一使用T-2的數(shù)據(jù)唤衫，這樣對于業(yè)務(wù)來說婆赠，起碼關(guān)聯(lián)到的維表數(shù)據(jù)是確定的（雖然維表數(shù)據(jù)有一定的延時，但是許多業(yè)務(wù)的維表在兩天之間變化是很少的）佳励。如果維表數(shù)據(jù)量不是特別大休里，可以全量加載到內(nèi)存使用；如果維表數(shù)據(jù)量特別大赃承，則可以增量查找和LRU過期的形式妙黍，讓最熱門的數(shù)據(jù)留在內(nèi)存中。

數(shù)據(jù)服務(wù)層

阿里數(shù)據(jù)服務(wù)架構(gòu)演進過程如下：

DWSOA：一個需求一個接口瞧剖，編碼實現(xiàn)接口拭嫁，接口數(shù)量5000/年。開發(fā)效率低抓于，投入成本高做粤，擴展性差。

OpenAPI：一類需求一個接口捉撮，配置實現(xiàn)接口怕品，接口數(shù)量200/年。相比上一種方式巾遭，這種方式有效收斂了數(shù)量肉康。

SmartDQ：所有需求一個接口修己，配置實現(xiàn)接口，接口數(shù)量1迎罗，缺點是服務(wù)形式不夠豐富睬愤，只能滿足簡單的查詢服務(wù)需求（畢竟SQL并不能解決復(fù)雜的業(yè)務(wù)邏輯）。SmartDQ通過在OpenAPI的基礎(chǔ)上纹安，再抽象一層尤辱，用DSL（領(lǐng)域?qū)Ｓ谜Z言）來描述取數(shù)需求，新做一套DSL必然有學(xué)習(xí)成本厢岂，因此采用標(biāo)準(zhǔn)的SQL語法光督。

OneService：提供多種服務(wù)類型來滿足用戶需求。

A塔粒、OneService-SmartDQ：通過SQL語法提供簡單的查詢服務(wù)需求结借。

B、OneService-Lego：采用插件方式滿足個性化需求卒茬，為了避免插件之間相互影響船老，我們將插件做成微服務(wù)，使用Docker做隔離圃酵。Lego可以采用輕量級的Node.JS技術(shù)棧實現(xiàn)柳畔，適合處理高并發(fā)、低延遲的IO密集型場景郭赐。

C薪韩、OneService-iPush：主要提供websocket和long polling兩種方式，其應(yīng)用場景主要是商家端實時直播捌锭。比如雙11俘陷，此時使用websocket方式可以有效緩解服務(wù)器壓力，給用戶帶來最實時的體驗观谦。

D拉盾、OneService-uTiming：主要提供即時任務(wù)和定時任務(wù)兩種模式，其主要應(yīng)用場景是滿足用戶運行大數(shù)據(jù)量任務(wù)的需求坎匿。

最佳實踐：

資源分配：復(fù)雜的計算邏輯可以提前計算盾剩；Get接口只返回一條記錄，查詢代價小響應(yīng)時間短替蔬，List接口返回多條記錄告私，查詢時間相對較長，可以設(shè)計Get線程池和List線程池兩個獨立的線程池避免Get接口和List接口相互影響承桥；查詢可以在引擎層自動進行拆分查詢驻粟，然后再把查詢結(jié)果進行合并。

緩存優(yōu)化：元數(shù)據(jù)緩存、模型緩存蜀撑、結(jié)果緩存挤巡。

查詢能力：由于離線數(shù)據(jù)和實時數(shù)據(jù)存放在不同地方，并且離線數(shù)據(jù)最準(zhǔn)確酷麦，需要優(yōu)先使用離線數(shù)據(jù)矿卑，如果離線數(shù)據(jù)還未產(chǎn)出，則改用實時數(shù)據(jù)，這就是要對離線和實時進行合并查詢；能采用推送的叉钥，就不采用輪詢，因為輪詢對服務(wù)器壓力大爹耗。

限流、降級：限流就是直接降到0，降級就是只將存在問題的資源置為失效狀態(tài)。

數(shù)據(jù)挖掘中臺

2012年以前业舍，由于數(shù)據(jù)的規(guī)模還不是特別龐大，大部分挖掘應(yīng)用所需處理的樣本量在百萬以內(nèi)升酣，而處理的特征一般也少于100維舷暮，那時像SAS、SPSS拗踢、Clementine等單機版的數(shù)據(jù)挖掘軟件已經(jīng)能滿足大部分挖掘應(yīng)用的需求脚牍。

隨著數(shù)據(jù)量的爆炸向臀，如今挖掘平臺面對的訓(xùn)練數(shù)據(jù)量動輒上億巢墅，特征維度動輒百萬，因此需要分布式券膀、可視化的數(shù)據(jù)挖掘算法平臺君纫。

就數(shù)據(jù)挖掘的商業(yè)場景而言，可以分為兩大類：個體挖掘和關(guān)系挖掘芹彬。個體挖掘是指對單個實體的行為特征進行預(yù)測與分析蓄髓，關(guān)系挖掘是指研究多個實體間的關(guān)系特征，如商品的相似關(guān)系和競爭關(guān)系舒帮。

就數(shù)據(jù)挖掘的技術(shù)而言会喝，可以分為兩大類：數(shù)據(jù)挖掘數(shù)據(jù)中臺、數(shù)據(jù)挖掘算法中臺玩郊。

1肢执、數(shù)據(jù)中臺

數(shù)據(jù)挖掘的過程中包括兩類數(shù)據(jù)：特征數(shù)據(jù)和結(jié)果數(shù)據(jù)。算法需要的特征變量就是特征數(shù)據(jù)译红，算法最終輸出的商品銷量的預(yù)測結(jié)果就是結(jié)果數(shù)據(jù)预茄。

對于特征數(shù)據(jù)，挖掘項目中80%的時間可能都是在處理特征侦厚，這些特征的提取耻陕、清洗拙徽、標(biāo)準(zhǔn)化以及基于業(yè)務(wù)場景的再組合和二次加工往往工作繁重。因此诗宣，就想到可以按照標(biāo)準(zhǔn)膘怕、規(guī)范構(gòu)建一個全局特征庫，每個挖掘工程師只需訪問幾張物理表就能迅速搜集到大部分自己想要的特征召庞。

對于結(jié)果數(shù)據(jù)淳蔼，可以進行分層存儲：通用結(jié)果和個性化結(jié)果。

基于以上分析裁眯，可以把挖掘數(shù)據(jù)中臺分為三層：特征層FDM（Featural Data Mining Layer）鹉梨、個體中間層IDM（Individual Data Mining Layer）、關(guān)系中間層RDM（Relational Data Mining Layer）和應(yīng)用層ADM（Application-oriented Data Mining Layer）穿稳；分層架構(gòu)見下圖存皂。

特征層：用于存儲在模型訓(xùn)練前常用的特征指標(biāo)，并進行統(tǒng)一的清洗和去噪處理逢艘。

中間層：個體中間層IDM和關(guān)系中間層RDM統(tǒng)一稱為中間層旦袋。其中，IDM面向個體挖掘場景它改，用于存儲通用性強的結(jié)果數(shù)據(jù)疤孕；RDM面向關(guān)系挖掘場景，用于存儲通用性強的結(jié)果數(shù)據(jù)央拖。

應(yīng)用層：用來沉淀比較個性應(yīng)用的數(shù)據(jù)挖掘結(jié)果指標(biāo)祭阀。

2、算法平臺

算法中臺的建設(shè)目的是從各種各樣的挖掘場景中抽象出有代表性的幾類場景鲜戒，并形成相應(yīng)的方法論和實操模板专控。

比較有代表性的數(shù)據(jù)挖掘應(yīng)用場景：