第1章 總述
第2章 日志采集
第3章 數(shù)據(jù)同步
第4章 離線數(shù)據(jù)開發(fā)
第5章 實(shí)時(shí)技術(shù)
第6章 數(shù)據(jù)服務(wù)
第7章 數(shù)據(jù)挖掘

第1章 總述

2014年贸典，馬云提出惋砂，“人類正從IT時(shí)代走向DT時(shí)代”。如果說在IT時(shí)代是以自我控制庸队、自我管理為主宾尚，那么到了DT(Data Technology) 時(shí)代，則是以服務(wù)大眾、激發(fā)生產(chǎn)力為主笙各。以互聯(lián)網(wǎng)（或者物聯(lián)網(wǎng)）、云計(jì)算春感、大數(shù)據(jù)和人工智能為代表的新技術(shù)革命正在滲透至各行各業(yè)，悄悄地改變著我們的生活宰缤。

數(shù)據(jù)作為一種新的能源氧骤，正在發(fā)生聚變，變革著我們的生產(chǎn)和生活 ，催生了當(dāng)下大數(shù)據(jù)行業(yè)發(fā)展熱火朝天的盛景。但是如果不能對(duì)這些數(shù)據(jù)進(jìn)行有序输涕、有結(jié)構(gòu)地分類組織和存儲(chǔ)先口，如果不能有效利用并發(fā)掘它，繼而產(chǎn)生價(jià)值烫葬，那么它同時(shí)也成為一場(chǎng)“災(zāi)難”兑巾。無序委煤、無結(jié)構(gòu)的數(shù)據(jù)猶如堆積如山的垃圾，給企業(yè)帶來的是令人咋舌的高額成本寓免。

在阿里內(nèi)部蜈首，數(shù)據(jù)工程師每天要面對(duì)百萬級(jí)規(guī)模的離線數(shù)據(jù)處理作。阿里大數(shù)據(jù)井噴式的爆發(fā)，加大了數(shù)據(jù)模型辣卒、數(shù)據(jù)研發(fā)啡莉、數(shù)據(jù)質(zhì)量和運(yùn)維保障工作的難度轨帜。同時(shí)梢什，日益豐富的業(yè)態(tài)，也帶來了各種各樣、紛繁復(fù)雜的數(shù)據(jù)需求。

如何有效地滿足來自員工吨拗、商家像鸡、合作伙伴等多樣化的需求 蕊蝗，提高他們對(duì)數(shù)據(jù)使用的滿意度，是數(shù)據(jù)服務(wù)和數(shù)據(jù)產(chǎn)品需要面對(duì)的挑戰(zhàn)。如何建設(shè)高效的數(shù)據(jù)模型和體系，使數(shù)據(jù)易用，避免重復(fù)建設(shè)和數(shù)據(jù)不一致性别厘，保證數(shù)據(jù)的規(guī)范性；如何提供高效易用的數(shù)據(jù)開發(fā)工如何做好數(shù)據(jù)質(zhì)量保障；如何有效管理和控制日益增長(zhǎng)的存儲(chǔ)和計(jì)算消耗前塔；如何保證數(shù)據(jù)服務(wù)的穩(wěn)定，保證其性能娜搂；如何設(shè)計(jì)有效的數(shù)據(jù)產(chǎn)品高效賦能于外部客戶和內(nèi)部員工……這些都給大數(shù)據(jù)系統(tǒng)的建設(shè)提出了更多復(fù)雜的要求昌粤。

本書介紹的阿里巴巴大數(shù)據(jù)系統(tǒng)架構(gòu)，就是為了滿足不斷變化的業(yè)務(wù)需求，同時(shí)實(shí)現(xiàn)系統(tǒng)的高度擴(kuò)展性亮隙、靈活性以及數(shù)據(jù)展現(xiàn)的高性能而設(shè)計(jì)的。

阿里巴巴大數(shù)據(jù)系統(tǒng)體系架構(gòu)听想，主要分為數(shù)據(jù)采集壹甥、數(shù)據(jù)計(jì)算、數(shù)據(jù)服務(wù)和數(shù)據(jù)應(yīng)用四大層次晴氨。

圖1.1 阿里巴巴大數(shù)據(jù)系統(tǒng)體系架構(gòu)圖

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

阿里巴巴是一家多業(yè)態(tài)的互聯(lián)網(wǎng)公司，幾億規(guī)模的用戶（如商家、消費(fèi)者、商業(yè)組織等）在平臺(tái)上從事商業(yè)、消費(fèi)犀概、娛樂等活動(dòng)疤苹，每時(shí)每刻都在產(chǎn)生海量的數(shù)據(jù)，數(shù)據(jù)采集作為阿里大數(shù)據(jù)系統(tǒng)體系的第一環(huán)尤為重要。因此阿里巴巴建立了一套標(biāo)準(zhǔn)的數(shù)據(jù)采集體系方案杠人，致力全面、高性能隐轩、規(guī)范地完成海量數(shù)據(jù)的采集，并將其傳輸?shù)酱髷?shù)據(jù)平臺(tái)。

阿里巴巴的日志采集體系方案包括兩大體系： Aplus.JS Web日志采集技術(shù)方案承粤； UserTrack APP端日志采集技術(shù)方案楔脯。在采集技術(shù)基礎(chǔ)之上，阿里巴巴用面向各個(gè)場(chǎng)景的埋點(diǎn)規(guī)范疮蹦，來滿足通用瀏覽凿可、點(diǎn)擊、特殊交互、 APP 事件枯跑、H5 APP里的H5 Native日志數(shù)據(jù)打通等多種業(yè)務(wù)場(chǎng)景惨驶。同時(shí)，還建立了一套高性能敛助、高可靠性的數(shù)據(jù)傳輸體系粗卜，完成數(shù)據(jù)從生產(chǎn)業(yè)務(wù)端到大數(shù)據(jù)系統(tǒng)的傳輸。在傳輸方面纳击，采用TimeTunnel（TT）续扔，它既包括數(shù)據(jù)庫(kù)的增量數(shù)據(jù)傳輸，也包括日志數(shù)據(jù)的傳輸焕数； TT作為數(shù)據(jù)傳輸服務(wù)的基礎(chǔ)架構(gòu)纱昧，既支持實(shí)時(shí)流式計(jì)算，也支持各種時(shí)間窗口的批量計(jì)算堡赔。另外识脆，也通過數(shù)據(jù)同步工具（DataX同步中心，其中同步中心是基于DataX易用性封裝的）直連異構(gòu)數(shù)據(jù)庫(kù)（備庫(kù)）來抽取各種時(shí)間窗口的數(shù)據(jù)善已。

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

數(shù)據(jù)只有被整合和計(jì)算灼捂，才能被用于洞察商業(yè)規(guī)律，挖掘潛在信息换团，從而實(shí)現(xiàn)大數(shù)據(jù)價(jià)值纵东，達(dá)到賦能于商業(yè)和創(chuàng)造價(jià)值的目的。從采集系統(tǒng)中收集到的大量原始數(shù)據(jù)啥寇，將進(jìn)入數(shù)據(jù)計(jì)算層中被進(jìn)一步整合與計(jì)算偎球。

面對(duì)海量的數(shù)據(jù)和復(fù)雜的計(jì)算，網(wǎng)里巴巴的數(shù)據(jù)計(jì)算層包括兩大體系：數(shù)據(jù)存儲(chǔ)及計(jì)算云平臺(tái)（離線計(jì)算平臺(tái) MaxCompute和實(shí)時(shí)計(jì)算StreamCompute）和數(shù)據(jù)整合及管理體系（內(nèi)部稱之為“OneData”）辑甜。

阿里巴巴的大數(shù)據(jù)工程在這一體系下衰絮，構(gòu)建統(tǒng)一、規(guī)范磷醋、可共享的全域數(shù)據(jù)體系 猫牡，避免數(shù)據(jù)的冗余和重復(fù)建設(shè)，規(guī)避數(shù)據(jù)煙囪和不一致性邓线，充分發(fā)揮間里巴巴在大數(shù)據(jù)海量淌友、多樣性方面的獨(dú)特優(yōu)勢(shì)。借助這一統(tǒng)一化數(shù)據(jù)整合及管理的方法體系骇陈，我們構(gòu)建了阿里巴巴的數(shù)據(jù)公共層震庭，幫助相似大數(shù)據(jù)項(xiàng)目快速落地實(shí)現(xiàn)。

從數(shù)據(jù)計(jì)算頻率角度來看你雌，阿里數(shù)據(jù)倉(cāng)庫(kù)可以分為離線數(shù)據(jù)倉(cāng)庫(kù)和實(shí)時(shí)數(shù)據(jù)倉(cāng)庫(kù)器联。離線數(shù)據(jù)倉(cāng)庫(kù)主要是指?jìng)鹘y(tǒng)的數(shù)據(jù)倉(cāng)庫(kù)概念二汛，數(shù)據(jù)計(jì)算頻率主要以天（包含小時(shí)、周和月）為單位拨拓；如T-1肴颊，則每天凌晨處理上一天的數(shù)據(jù)。但是隨著業(yè)務(wù)的發(fā)展特別是交易過程的縮短渣磷，用戶對(duì)數(shù)據(jù)產(chǎn)出的實(shí)時(shí)性要求逐漸提高婿着，所以阿里的實(shí)時(shí)數(shù)據(jù)倉(cāng)庫(kù)應(yīng)運(yùn)而生〈捉纾“雙11”實(shí)時(shí)數(shù)據(jù)直播大屏竟宋，就是實(shí)時(shí)數(shù)據(jù)倉(cāng)庫(kù)的一種典型應(yīng)用。

阿里數(shù)據(jù)倉(cāng)庫(kù)的數(shù)據(jù)加工鏈路也是遵循業(yè)界的分層理念物独，包括：
1袜硫、操作數(shù)據(jù)層（Operational Data Store, ODS）
2氯葬、明細(xì)數(shù)據(jù)層（Data Warehouse Detail, DWD）
3挡篓、匯總數(shù)據(jù)層（Data Warehouse Summary, DWS）
4、應(yīng)用數(shù)據(jù)層（Application Data Store, ADS）
通過數(shù)據(jù)倉(cāng)庫(kù)不同層次之間的加工過程實(shí)現(xiàn)從數(shù)據(jù)資產(chǎn)向信息資產(chǎn)的轉(zhuǎn)化帚称，并且對(duì)整個(gè)過程進(jìn)行有效的元數(shù)據(jù)管理及數(shù)據(jù)質(zhì)量處理官研。

在阿里大數(shù)據(jù)系統(tǒng)中，元數(shù)據(jù)模型整合及應(yīng)用是一個(gè)重要的組成部分闯睹，主要包含數(shù)據(jù)源元數(shù)據(jù)戏羽、數(shù)據(jù)倉(cāng)庫(kù)元數(shù)據(jù) 、數(shù)據(jù)鏈路元數(shù)據(jù)楼吃、工具類元數(shù)據(jù) 數(shù)據(jù)質(zhì)量類元數(shù)據(jù)等始花。元數(shù)據(jù)應(yīng) 主要面向數(shù)據(jù)發(fā)現(xiàn)、數(shù)據(jù)管理等 孩锡，如用于存儲(chǔ)酷宵、計(jì)算和成本管理等。

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

當(dāng)數(shù)據(jù)已被整合和計(jì)算好之后躬窜，需要提供給產(chǎn)品和應(yīng)用進(jìn)行數(shù)據(jù)消費(fèi)浇垦。為了有更好的性能和體驗(yàn)，阿里巴巴構(gòu)建了自己的數(shù)據(jù)服務(wù)層荣挨，通過接口服務(wù)化方式對(duì)外提供數(shù)據(jù)服務(wù)男韧。針對(duì)不同的需求，數(shù)據(jù)服務(wù)層的數(shù)據(jù)源架構(gòu)在多種數(shù)據(jù)庫(kù)之上默垄，如MySQL和HBase等此虑。后續(xù)將逐漸遷移至阿里云云數(shù)據(jù)庫(kù)ApsaraDB for RDS（簡(jiǎn)稱“RDS”）和表格存儲(chǔ)（Table Store）等。

數(shù)據(jù)服務(wù)可以使應(yīng)用對(duì)底層數(shù)據(jù)存儲(chǔ)透明口锭，將海量數(shù)據(jù)方便高效地開放給集團(tuán)內(nèi)部各應(yīng)用使用」炎常現(xiàn)在，數(shù)據(jù)服務(wù)每天擁有幾十億的數(shù)據(jù)調(diào)用量，如何在性能况既、穩(wěn)定性这溅、擴(kuò)展性等方面更好地服務(wù)于用戶：如何滿足應(yīng)用各種復(fù)雜的數(shù)據(jù)服務(wù)需求：如何保證“雙11”媒體大屏數(shù)據(jù)服務(wù)接口的高可用……隨著業(yè)務(wù)的發(fā)展，需求越來越復(fù)雜棒仍，因此數(shù)據(jù)服務(wù)也在不斷地前進(jìn)悲靴。

數(shù)據(jù)服務(wù)層對(duì)外提供數(shù)據(jù)服務(wù)主要是通過統(tǒng)一的數(shù)據(jù)服務(wù)平臺(tái)（方便閱讀，簡(jiǎn)稱為“OneService”）莫其。 OneService以數(shù)據(jù)倉(cāng)庫(kù)整合計(jì)算好的數(shù)據(jù)作為數(shù)據(jù)源癞尚，對(duì)外通過接口的方式提供數(shù)據(jù)服務(wù)，主要提供簡(jiǎn)單數(shù)據(jù)查詢服務(wù)乱陡、復(fù)雜數(shù)據(jù)查詢服務(wù)（承接集團(tuán)用戶識(shí)別浇揩、用戶畫像等復(fù)雜數(shù)據(jù)查詢服務(wù)）和實(shí)時(shí)數(shù)據(jù)推送服務(wù)三大特色數(shù)據(jù)服務(wù)。

• 數(shù)據(jù)應(yīng)用層

數(shù)據(jù)已經(jīng)準(zhǔn)備好憨颠，需要通過合適的應(yīng)用提供給用戶胳徽，讓數(shù)據(jù)最大化地發(fā)揮價(jià)值。阿里對(duì)數(shù)據(jù)的應(yīng)用表現(xiàn)在各個(gè)方面爽彤，如搜索养盗、推薦、廣告适篙、金融往核、信用、保險(xiǎn)嚷节、文娛聂儒、物流等。商家硫痰，阿里內(nèi)部的搜索衩婚、推薦、廣告碍论、金融等平臺(tái)谅猾，阿里內(nèi)部的運(yùn)營(yíng)和管理人員等，都是數(shù)據(jù)應(yīng)用方鳍悠；ISV税娜、研究機(jī)構(gòu)和社會(huì)組織等也可以利用阿里開放的數(shù)據(jù)能力和技術(shù)。

阿里巴巴基于數(shù)據(jù)的應(yīng)用產(chǎn)品有很多藏研，本書選擇了服務(wù)于阿里內(nèi)部員工的阿里數(shù)據(jù)平臺(tái)和服務(wù)于商家的對(duì)外數(shù)據(jù)產(chǎn)品一一生意參謀進(jìn)行基礎(chǔ)性介紹敬矩。其他數(shù)據(jù)應(yīng)用不再贅述。對(duì)內(nèi)蠢挡，阿里數(shù)據(jù)平臺(tái)產(chǎn)品主要有實(shí)時(shí)數(shù)據(jù)監(jiān)控弧岳、自助式的數(shù)據(jù)網(wǎng)站或產(chǎn)品構(gòu)建的數(shù)據(jù)小站凳忙、宏觀決策分析支撐平臺(tái)、對(duì)象分析工具禽炬、行業(yè)數(shù)據(jù)分析門戶涧卵、流量分析平臺(tái)等。

第1篇 數(shù)據(jù)技術(shù)篇

第2章 日志采集

2.1 瀏覽器的頁(yè)面日志采集

2.1.1 頁(yè)面瀏覽日志采集

此類日志是最基礎(chǔ)的互聯(lián)網(wǎng)日志腹尖，也是目前所有互聯(lián)網(wǎng)產(chǎn)品的兩大基本指標(biāo)：頁(yè)面瀏覽量（PageView, PV）和訪客數(shù)（UniqueVisitors, UV）的統(tǒng)計(jì)基礎(chǔ)柳恐。頁(yè)面瀏覽日志是目前成熟度和完備度最高，同時(shí)也是最具挑戰(zhàn)性的日志來集任務(wù)热幔。

網(wǎng)頁(yè)瀏覽過程：

• 用戶在瀏覽器內(nèi)點(diǎn)擊淘寶首頁(yè)鏈接
• 瀏覽器向淘寶服務(wù)器發(fā)起HTTP請(qǐng)求
• 服務(wù)器接收并解析請(qǐng)求
• 瀏覽器接收到服務(wù)器的響應(yīng)內(nèi)容乐设，并將其按照文檔規(guī)范展現(xiàn)給用戶，完成一次請(qǐng)求

如果需要記錄這次瀏覽行為绎巨，則采集日志的動(dòng)作必然是附加在上述四個(gè)步驟中的某一環(huán)節(jié)內(nèi)完成的近尚。在第一步和第二步，用戶的請(qǐng)求尚未抵達(dá)服務(wù)器场勤；而直到第三步完成戈锻，我們也只能認(rèn)為服務(wù)器處理了請(qǐng)求，不能保證瀏覽器能夠正確地解析和渲染頁(yè)面却嗡，尚不能確保用戶已確實(shí)打開頁(yè)面舶沛，因此在前三步是無法采集用戶的瀏覽日志的嘹承。那么采集日志的動(dòng)作窗价，需要在第四步，也就是瀏覽器開始解析文檔時(shí)才能進(jìn)行叹卷。

根據(jù)前文所述撼港，可以很自然地得出在這一模式下最直接的日志采集思路：在HTML文檔內(nèi)的適當(dāng)位置增加一個(gè)日志采集節(jié)點(diǎn)，當(dāng)瀏覽器解析到這個(gè)節(jié)點(diǎn)時(shí)骤竹，將自動(dòng)觸發(fā)一個(gè)特定的HTTP請(qǐng)求到日志采集服務(wù)器帝牡。如此一來，當(dāng)日志采集服務(wù)器接收到這個(gè)請(qǐng)求時(shí)蒙揣，就可以確定瀏覽器已經(jīng)成功地接收和打開了頁(yè)面靶溜。

2.1.2 頁(yè)面交互日志采集

當(dāng)頁(yè)面加載和渲染完成之后，用戶可以在頁(yè)面上執(zhí)行各類操作懒震。

PY日志的采集解決了頁(yè)面流量和流量來源統(tǒng)計(jì)的問題罩息，但隨著互聯(lián)網(wǎng)業(yè)務(wù)的發(fā)展，僅了解用戶到訪過的頁(yè)面和訪問路徑个扰，已經(jīng)遠(yuǎn)遠(yuǎn)不能滿足用戶細(xì)分研究的需求瓷炮。在很多場(chǎng)合下，需要了解用戶在訪問某個(gè)頁(yè)面時(shí)具體的互動(dòng)行為特征递宅，比如鼠標(biāo)或輸入焦點(diǎn)的移動(dòng)變化（代表用戶關(guān)注內(nèi)容的變化）娘香、對(duì)某些頁(yè)面交互的反應(yīng)（可借此判斷用戶是否對(duì)某些頁(yè)面元素發(fā)生認(rèn)知困難）等苍狰。因?yàn)檫@些行為往往并不觸發(fā)瀏覽器加載新頁(yè)面，所以無法通過常規(guī)的PV日志采集方法來收集烘绽。

業(yè)務(wù)方將交互日志采集代碼植入目標(biāo)頁(yè)面淋昭，并將采集代碼與需要監(jiān)測(cè)的交互行為做綁定。當(dāng)用戶在頁(yè)面上產(chǎn)生指定行為時(shí)安接，采集代碼和正常的業(yè)務(wù)互動(dòng)響應(yīng)代碼一起被觸發(fā)和執(zhí)行响牛。隨后可被業(yè)務(wù)方按需自行解析處理，并可與正常的PV日志做關(guān)聯(lián)運(yùn)算赫段。

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

在大部分場(chǎng)合下呀打，經(jīng)過上述解析處理之后的日志并不直接提供給下游使用∨大希基于如下幾個(gè)原因贬丛，在對(duì)時(shí)效要求較寬松的應(yīng)用場(chǎng)合下，一般還需要進(jìn)行相應(yīng)的離線預(yù)處理给涕。

• 識(shí)別流量攻擊豺憔、網(wǎng)絡(luò)爬蟲和流量作弊（虛假流量）
  頁(yè)面日志是互聯(lián)網(wǎng)分析和大數(shù)據(jù)應(yīng)用的基礎(chǔ)源數(shù)據(jù)，在實(shí)際應(yīng)用中够庙，往往存在占一定比例的虛假或者惡意流量日志恭应，導(dǎo)致日志相關(guān)指標(biāo)的統(tǒng)計(jì)發(fā)生偏差或明顯謬誤。為此耘眨，需要對(duì)所采集的日志進(jìn)行合法性校驗(yàn)昼榛，依托算法識(shí)別非正常的流量并歸納出對(duì)應(yīng)的過濾規(guī)則集加以濾除。

• 數(shù)據(jù)缺項(xiàng)補(bǔ)正
  為了便利后續(xù)的日志應(yīng)用和保證基本的數(shù)據(jù)統(tǒng)計(jì)口徑一致剔难，在大多數(shù)情況下胆屿，需要對(duì)日志中的一些公用且重要的數(shù)據(jù)項(xiàng)做取值歸一、標(biāo)準(zhǔn)化處理或反向補(bǔ)正偶宫。反向補(bǔ)正非迹，即根據(jù)新日志對(duì)稍早收集的日志中的個(gè)別數(shù)據(jù)項(xiàng)做回補(bǔ)或修訂（例如，在用戶登錄后纯趋，對(duì)登錄前頁(yè)面日志做身份信息的回補(bǔ)）憎兽。

• 無效數(shù)據(jù)剔除
  在某些情況下，因業(yè)務(wù)變更或配置不當(dāng)吵冒，在采集到的日志中會(huì)存在一些無意義纯命、已經(jīng)失效或者冗余的數(shù)據(jù)項(xiàng)。這些數(shù)據(jù)項(xiàng)不僅消耗存儲(chǔ)空間和運(yùn)算能力桦锄，而且在偶然的情況下還可能干擾正常計(jì)算的進(jìn)行扎附，需要對(duì)此類數(shù)據(jù)進(jìn)行剔除。

• 日志隔離分發(fā)
  基于數(shù)據(jù)安全或者業(yè)務(wù)特性的考慮结耀，某些日志在進(jìn)入公共數(shù)據(jù)環(huán)境之前需要做隔離留夜。

原始日志經(jīng)過上述的清洗匙铡、修正，并結(jié)構(gòu)化變形處理之后碍粥，Web頁(yè)面日志的采集流程就算完成了鳖眼。此時(shí)的日志已經(jīng)具備了結(jié)構(gòu)化或者半結(jié)構(gòu)化的特征，可以方便地被關(guān)系型數(shù)據(jù)庫(kù)裝載和使用嚼摩。

2.2 無線客戶端的日志采集

無線客戶端的日志采集通過采集SOK來完成钦讳。

2.2.1 頁(yè)面事件

2.2.2 控件點(diǎn)擊及其他事件

2.2.3 特殊場(chǎng)景

2.2.4 H5 & Native日志統(tǒng)一

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

關(guān)于UV，對(duì)于登錄用戶枕面，可以使用用戶ID來進(jìn)行唯一標(biāo)識(shí)愿卒，但是很多日志行為并不要求用戶登錄，這就導(dǎo)致在很多情況下采集上來的日志都沒有用戶ID潮秘。PC端一般使用Cookie信息來作為設(shè)備的唯一信息琼开，對(duì)于APP來說，我們就要想辦法獲取到能夠唯一標(biāo)識(shí)設(shè)備的信息枕荞。

對(duì)于只有單APP的公司來說柜候，設(shè)備唯一標(biāo)識(shí)不是需要攻克的難題，但對(duì)于像阿里巴巴這樣擁有眾多APP的公司來說躏精，設(shè)備唯一標(biāo)識(shí)就顯得尤為重要渣刷。

2.2.6 日志傳輸

無線客戶端日志的上傳，不是產(chǎn)生一條日志上傳一條矗烛，而是無線客戶端產(chǎn)生日志后辅柴，先存儲(chǔ)在客戶端本地，然后再伺機(jī)上傳高诺。所謂伺機(jī)碌识，就需要有數(shù)據(jù)分析的支持碾篡，如在啟動(dòng)后虱而、使用過程中、切換到后臺(tái)時(shí)這些場(chǎng)景下分別多久觸發(fā)一次上傳動(dòng)作开泽。當(dāng)然單純地靠間隔時(shí)間來決定上傳動(dòng)作是不夠的牡拇，還需要考慮日志的大小及合理性（如單條日志超大，很可能就是錯(cuò)誤日志）穆律。另外惠呼，還需要考慮上傳時(shí)網(wǎng)絡(luò)的耗時(shí)，來決定是否要調(diào)整上傳機(jī)制峦耘。

后續(xù)的應(yīng)用可以是實(shí)時(shí)的應(yīng)用來訂閱TT收集到的消息剔蹋，進(jìn)行實(shí)時(shí)計(jì)算，也可以是離線的應(yīng)用定時(shí)來獲取消息辅髓，完成離線的計(jì)算泣崩。

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

對(duì)于目前的互聯(lián)網(wǎng)行業(yè)而言少梁，互聯(lián)網(wǎng)日志早已跨越初級(jí)的饑餓階段（大型互聯(lián)網(wǎng)企業(yè)的日均日志收集量均以億為單位計(jì)量），反而面臨海量日志的淹沒風(fēng)險(xiǎn)矫付。各類采集方案提供者所面臨的主要挑戰(zhàn)已不是日志采集技術(shù)本身凯沪，而是如何實(shí)現(xiàn)日志數(shù)據(jù)的結(jié)構(gòu)化和規(guī)范化組織，實(shí)現(xiàn)更為高效的下游統(tǒng)計(jì)計(jì)算买优，提供符合業(yè)務(wù)特性的數(shù)據(jù)展現(xiàn)妨马，以及為算法提供更便捷、靈活的支持等方面杀赢。

2.3.1 典型場(chǎng)景

• 日志分流與定制處理
  大型互聯(lián)網(wǎng)網(wǎng)站的日志類型和日志規(guī)模都呈現(xiàn)出高速增長(zhǎng)的態(tài)勢(shì)烘跺，而且往往會(huì)出現(xiàn)短時(shí)間的流量熱點(diǎn)爆發(fā)。這一特點(diǎn)脂崔，使得在日志服務(wù)器端采用集中統(tǒng)一的解析處理方案變得不可能液荸，其要求在日志解析和處理過程中必須考慮業(yè)務(wù)分流（相互之間不應(yīng)存在明顯的影響，爆發(fā)熱點(diǎn)不應(yīng)干擾定常業(yè)務(wù)日志的處理）脱篙、日志優(yōu)先級(jí)控制娇钱，以及根據(jù)業(yè)務(wù)特點(diǎn)實(shí)現(xiàn)定制處理。例如绊困，對(duì)于電商網(wǎng)站而言文搂，數(shù)據(jù)分析人員對(duì)位于點(diǎn)擊流前端的促銷頁(yè)面和位于后端的商品頁(yè)面的關(guān)注點(diǎn)是不一樣的，而這兩類頁(yè)面的流量又往往同等重要且龐大秤朗，如果采用統(tǒng)一的解析處理方案煤蹭，則往往需要在資源浪費(fèi)（盡可能多地進(jìn)行預(yù)處理）和需求覆蓋不全（僅對(duì)最重要的內(nèi)容進(jìn)行預(yù)處理）兩個(gè)選擇之間進(jìn)行取舍。這種取舍的結(jié)果一般不是最優(yōu)的取视。

• 采集與計(jì)算一體化設(shè)計(jì)
  以PV日志為例硝皂，頁(yè)面PY日志采集之后一個(gè)基礎(chǔ)性操作是日志的歸類與匯總。在早期的互聯(lián)網(wǎng)日志分析實(shí)踐中作谭，是以URL路徑稽物，繼而以URL（正則）規(guī)則集為依托來進(jìn)行日志分類的。在網(wǎng)站規(guī)模較小時(shí)折欠，這一策略還可以基本順利地運(yùn)轉(zhuǎn)下去贝或，但隨著網(wǎng)站的大型化和開發(fā)人員的增加，URL規(guī)則集的維護(hù)和使用成本會(huì)很快增長(zhǎng)到不現(xiàn)實(shí)的程度锐秦，同時(shí)失控的大規(guī)模正則適配甚至?xí)⑷罩居?jì)算硬件集群徹底榨干咪奖。這一狀況要求日志采集方案必須將來集與計(jì)算作為一個(gè)系統(tǒng)來考量，進(jìn)行一體化設(shè)計(jì)酱床。

在當(dāng)前的互聯(lián)網(wǎng)環(huán)境下羊赵，互聯(lián)網(wǎng)日志的規(guī)模化采集方案必須具備一個(gè)與終端設(shè)備的技術(shù)特點(diǎn)無關(guān)扇谣，具有高度擴(kuò)展彈性和適應(yīng)性，同時(shí)深入契合應(yīng)用需求的業(yè)務(wù)邏輯模型，并基于此制定對(duì)應(yīng)的采集規(guī)范交由產(chǎn)品開發(fā)人員執(zhí)行账胧。若非如此，則不足以保障采集->解析->處理->應(yīng)用整個(gè)流程的通暢汤纸。目前阿里已成功實(shí)現(xiàn)規(guī)范制定->元數(shù)據(jù)注冊(cè)->日志采集->自動(dòng)化計(jì)算->可視化展現(xiàn)全流程的貫通。通過一體化設(shè)計(jì)芹血，用戶甚至可以在不理解規(guī)范的前提下贮泞，通過操作向?qū)浇缑妫瑢?shí)現(xiàn)日志來集規(guī)范的自動(dòng)落地和統(tǒng)計(jì)應(yīng)用幔烛。日志本身不是日志采集的目的啃擦，服務(wù)于基于日志的后續(xù)應(yīng)用，才是日志采集正確的著眼點(diǎn)饿悬。

2.3.2 大促保障

日志數(shù)據(jù)在阿里系乃至整個(gè)電商系應(yīng)該都是體量最大的一類數(shù)據(jù)令蛉，在“雙ll”期間，日志必然會(huì)暴漲狡恬，近萬億的數(shù)據(jù)量對(duì)日志全鏈路來說珠叔，無疑是不小的挑戰(zhàn)。從端上埋點(diǎn)采集弟劲，到日志服務(wù)器收集祷安，經(jīng)過數(shù)據(jù)傳輸，再到日志實(shí)時(shí)解析兔乞、實(shí)時(shí)分析汇鞭，任何一個(gè)環(huán)節(jié)出現(xiàn)問題，全鏈路保障就是失敗的庸追。

圖2.4 數(shù)據(jù)處理全鏈路

• 端上實(shí)現(xiàn)了服務(wù)器端推送配置到客戶端霍骄，且做到高到達(dá)率
• 對(duì)日志做了分流，結(jié)合日志的重要程度及各類日志的大小淡溯，實(shí)現(xiàn)了日志服務(wù)器端的拆分
• 在實(shí)時(shí)處理方面读整，也做了不少的優(yōu)化以提高應(yīng)用的吞吐量
• 結(jié)合實(shí)時(shí)處理能力，評(píng)估峰值數(shù)據(jù)量血筑，在高峰期通過服務(wù)器端推送配置的方式對(duì)非重要日志進(jìn)行適當(dāng)限流绘沉，錯(cuò)峰后逐步恢復(fù)

整個(gè)日志處理流程還是比較長(zhǎng)的，對(duì)于對(duì)實(shí)時(shí)性要求極高的業(yè)務(wù)場(chǎng)景豺总，如上鏈路顯然不能滿足需求。

• 從業(yè)務(wù)上進(jìn)行改造择懂，采用端上記錄
• 在鏈路各環(huán)節(jié)做優(yōu)化喻喳，如從采集服務(wù)器直接完成解碼并調(diào)用業(yè)務(wù)API完成業(yè)務(wù)的計(jì)算（省去中間的傳輸和過多的處理）

在保證穩(wěn)定的同時(shí)擴(kuò)展功能，在穩(wěn)定及業(yè)務(wù)深度之間做到很好的平衡困曙。

在如上策略下表伦，2016年的“雙11”谦去，日志采集瀏覽等核心用戶行為日志均實(shí)現(xiàn)了100%全量及實(shí)時(shí)服務(wù)，支持天貓所有會(huì)場(chǎng)的實(shí)時(shí)推薦蹦哼。在“雙11”中鳄哭，用戶的瀏覽、點(diǎn)擊纲熏、滾屏等每個(gè)操作行為妆丘，都實(shí)時(shí)影響到后續(xù)為其推薦的商品，很好地提高了用戶體驗(yàn)局劲。

第3章 數(shù)據(jù)同步

同類型不同集群數(shù)據(jù)庫(kù)之間的數(shù)據(jù)同步：

• 主數(shù)據(jù)庫(kù)與備份數(shù)據(jù)庫(kù)之間的數(shù)據(jù)備份
• 主系統(tǒng)與子系統(tǒng)之間的數(shù)據(jù)更新

不同地域勺拣、不同數(shù)據(jù)庫(kù)類型之間的數(shù)據(jù)傳輸交換：

• 分布式業(yè)務(wù)系統(tǒng)與數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)之間的數(shù)據(jù)同步

大數(shù)據(jù)系統(tǒng)：

• 數(shù)據(jù)從業(yè)務(wù)系統(tǒng)同步進(jìn)入數(shù)據(jù)倉(cāng)庫(kù)
• 數(shù)據(jù)從數(shù)據(jù)倉(cāng)庫(kù)同步進(jìn)入數(shù)據(jù)服務(wù)或數(shù)據(jù)應(yīng)用

3.1 數(shù)據(jù)同步基礎(chǔ)

源業(yè)務(wù)系統(tǒng)的數(shù)據(jù)類型多種多樣：

• 來源于關(guān)系型數(shù)據(jù)庫(kù)的結(jié)構(gòu)化數(shù)據(jù)，如MySQL鱼填、Oracle药有、DB2,SQL Server等
• 來源于非關(guān)系型數(shù)據(jù)庫(kù)的非結(jié)構(gòu)化數(shù)據(jù)，如OceanBase苹丸、HBase愤惰、Mongo DB等
  （通常存儲(chǔ)在數(shù)據(jù)庫(kù)表中）
• 來源于文件系統(tǒng)的結(jié)構(gòu)化或非結(jié)構(gòu)化數(shù)據(jù)，如阿里云對(duì)象存儲(chǔ)oss赘理、文件存儲(chǔ)NAS等
  （通常以文件形式進(jìn)行存儲(chǔ)）

數(shù)據(jù)同步需要針對(duì)不同的數(shù)據(jù)類型及業(yè)務(wù)場(chǎng)景選擇不同的同步方式羊苟。總的來說感憾，同步方式可以分為三種：

• 直連同步
• 數(shù)據(jù)文件同步
• 數(shù)據(jù)庫(kù)日志解析同步

3.1.1 直連同步

直連同步是指通過定義好的規(guī)范接口API和基于動(dòng)態(tài)鏈接庫(kù)的方式直接連接業(yè)務(wù)庫(kù)蜡励，如ODBC/JD BC等規(guī)定了統(tǒng)一規(guī)范的標(biāo)準(zhǔn)接口，不同的數(shù)據(jù)庫(kù)基于這套標(biāo)準(zhǔn)接口提供規(guī)范的驅(qū)動(dòng)阻桅，支持完全相同的函數(shù)調(diào)用和SQL實(shí)現(xiàn)凉倚。

這種方式配置簡(jiǎn)單，實(shí)現(xiàn)容易嫂沉，比較適合操作型業(yè)務(wù)系統(tǒng)的數(shù)據(jù)同步稽寒。但是業(yè)務(wù)庫(kù)直連的方式對(duì)源系統(tǒng)的性能影響較大，當(dāng)執(zhí)行大批量數(shù)據(jù)同步時(shí)會(huì)降低甚至拖垮業(yè)務(wù)系統(tǒng)的性能趟章。如果業(yè)務(wù)庫(kù)采取主備策略杏糙，則可以從備庫(kù)抽取數(shù)據(jù)，避免對(duì)業(yè)務(wù)系統(tǒng)產(chǎn)生性能影響蚓土。但是當(dāng)數(shù)據(jù)量較大時(shí)宏侍，采取此種抽取方式性能較差，不太適合從業(yè)務(wù)系統(tǒng)到數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)的同步蜀漆。

圖3.1 直連同步示意圖.png

3.1.2 數(shù)據(jù)文件同步

數(shù)據(jù)文件同步通過約定好的文件編碼谅河、大小、格式等，直接從源系統(tǒng)生成數(shù)據(jù)的文本文件绷耍，由專門的文件服務(wù)器吐限，如FTP服務(wù)器傳輸?shù)侥繕?biāo)系統(tǒng)后，加載到目標(biāo)數(shù)據(jù)庫(kù)系統(tǒng)中褂始。當(dāng)數(shù)據(jù)源包含多個(gè)異構(gòu)的數(shù)據(jù)庫(kù)系統(tǒng)（如MySQL诸典、Oracle、SQLServer崎苗、DB2等）時(shí)狐粱，用這種方式比較簡(jiǎn)單、實(shí)用益缠。另外脑奠，互聯(lián)網(wǎng)的日志類數(shù)據(jù)，通常是以文本文件形式存在的幅慌，也適合使用數(shù)據(jù)文件同步方式宋欺。

由于通過文件服務(wù)器上傳、下載可能會(huì)造成丟包或錯(cuò)誤胰伍，為了確保數(shù)據(jù)文件同步的完整性齿诞，通常除了上傳數(shù)據(jù)文件本身以外，還會(huì)上傳一個(gè)校驗(yàn)文件骂租，該校驗(yàn)文件記錄了數(shù)據(jù)文件的數(shù)據(jù)量以及文件大小等校驗(yàn)信息祷杈，以供下游目標(biāo)系統(tǒng)驗(yàn)證數(shù)據(jù)同步的準(zhǔn)確性。另外渗饮，在從源系統(tǒng)生成數(shù)據(jù)文件的過程中但汞，可以增加壓縮和加密功能，傳輸?shù)侥繕?biāo)系統(tǒng)以后互站，再對(duì)數(shù)據(jù)進(jìn)行解壓縮和解密私蕾，這樣可以大大提高文件的傳輸效率和安全性。

圖3.2 數(shù)據(jù)文件同步示意圖.png

3.1.3 數(shù)據(jù)庫(kù)日志解析同步

目前胡桃，大多數(shù)主流數(shù)據(jù)庫(kù)都已經(jīng)實(shí)現(xiàn)了使用日志文件進(jìn)行系統(tǒng)恢復(fù)踩叭，因?yàn)槿罩疚募畔⒆銐蜇S富，而且數(shù)據(jù)格式也很穩(wěn)定翠胰，完全可以通過解析日志文件獲取發(fā)生變更的數(shù)據(jù)容贝，從而滿足增量數(shù)據(jù)同步的需求。

以O(shè)racle為例之景，可以通過源系統(tǒng)的進(jìn)程斤富，讀取歸檔日志文件用以收集變化的數(shù)據(jù)信息，并判斷日志中的變更是否屬于被收集對(duì)象闺兢，將其解析到目標(biāo)數(shù)據(jù)文件中茂缚。這種讀操作是在操作系統(tǒng)層面完成的戏罢，不需要通過數(shù)據(jù)庫(kù)屋谭，因此不會(huì)給源系統(tǒng)帶來性能影響脚囊。

然后可通過網(wǎng)絡(luò)協(xié)議，實(shí)現(xiàn)源系統(tǒng)和目標(biāo)系統(tǒng)之間的數(shù)據(jù)文件傳輸桐磁。相關(guān)進(jìn)程可以確保數(shù)據(jù)文件的正確接收和網(wǎng)絡(luò)數(shù)據(jù)包的正確順序悔耘，并提供網(wǎng)絡(luò)傳輸冗余，以確保數(shù)據(jù)文件的完整性我擂。數(shù)據(jù)文件被傳輸?shù)侥繕?biāo)系統(tǒng)后衬以，可通過數(shù)據(jù)加載模塊完成數(shù)據(jù)的導(dǎo)人，從而實(shí)現(xiàn)數(shù)據(jù)從源系統(tǒng)到目標(biāo)系統(tǒng)的同步校摩。

數(shù)據(jù)庫(kù)日志解析同步方式實(shí)現(xiàn)了實(shí)時(shí)與準(zhǔn)實(shí)時(shí)同步的能力看峻，延遲可以控制在毫秒級(jí)別，并且對(duì)業(yè)務(wù)系統(tǒng)的性能影響也比較小衙吩，目前廣泛應(yīng)用于從業(yè)務(wù)系統(tǒng)到數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)的增量數(shù)據(jù)同步應(yīng)用之中互妓。

通過數(shù)據(jù)庫(kù)日志解析進(jìn)行同步的方式性能好、效率高坤塞，對(duì)業(yè)務(wù)系統(tǒng)的影響較小冯勉。但是它也存在如下一些問題：

• 數(shù)據(jù)延遲
  例如，業(yè)務(wù)系統(tǒng)做批量補(bǔ)錄可能會(huì)使數(shù)據(jù)更新量超出系統(tǒng)處理峰值摹芙，導(dǎo)致數(shù)據(jù)延遲

• 投入較大
  采用數(shù)據(jù)庫(kù)日志抽取的方式投入較大灼狰，需要在源數(shù)據(jù)庫(kù)與目標(biāo)數(shù)據(jù)庫(kù)之間部署一個(gè)系統(tǒng)實(shí)時(shí)抽取數(shù)據(jù)

• 數(shù)據(jù)漂移和遺漏
  數(shù)據(jù)漂移，一般是對(duì)增量表而言的浮禾，通常是指該表的同一個(gè)業(yè)務(wù)日期數(shù)據(jù)中包含前一天或后一天凌晨附近的數(shù)據(jù)或者丟失當(dāng)天的變更數(shù)據(jù)

圖3.3 數(shù)據(jù)庫(kù)日志解析同步示意圖.png

由于數(shù)據(jù)庫(kù)日志抽取一般是獲取所有的數(shù)據(jù)記錄的變更（增交胚、刪、改）盈电，落地到目標(biāo)表時(shí)我們需要根據(jù)主鍵去重按照日志時(shí)間倒排序獲取最后狀態(tài)的變化情況蝴簇。對(duì)于刪除數(shù)據(jù)這種變更情況，針對(duì)不同的業(yè)務(wù)場(chǎng)景可以采用一些不同的落地手法挣轨。

下圖是某源業(yè)務(wù)系統(tǒng)中某表變更日志流水表军熏。其含義是：存在5條變更日志，其中主鍵為1的記錄有3條變更日志卷扮，主鍵為2的記錄有2條變更日志荡澎。

表3.1 某源表變更日志流水表.png

假設(shè)根據(jù)主鍵去重，按照流水倒序獲取記錄最后狀態(tài)生成的表為delta表晤锹。

針對(duì)刪除數(shù)據(jù)這種變更摩幔，主要有三種方式:

• 不過濾刪除流水：不管是否是刪除操作，都獲取同一主鍵最后變更的那條流水（剩余流水號(hào)4鞭铆、5兩條記錄）

• 過濾最后一條刪除流水：如果同一主鍵最后變更的那條流水是刪除操作或衡，就獲取倒數(shù)第二條流水（剩余流水號(hào)2焦影、5兩條記錄）

• 過濾刪除流水和之前的流水：如果在同一主鍵變更的過程中有刪除操作，則根據(jù)操作時(shí)間將該刪除操作對(duì)應(yīng)的流水和之前的流水都過濾掉（剩余流水號(hào)5一條記錄）

對(duì)于采用哪種方式處理刪除數(shù)據(jù)封断，要看前端是如何刪除無效數(shù)據(jù)的：

• 正常業(yè)務(wù)數(shù)據(jù)刪除

• 手工批量刪除：通常針對(duì)類似的場(chǎng)景斯辰，業(yè)務(wù)系統(tǒng)只做邏輯刪除，不做物理刪除坡疼，OBA定期將部分歷史數(shù)據(jù)直接刪除或者備份到備份庫(kù)

一般情況下彬呻，可以采用不過濾的方式來處理，下游通過是否刪除記錄的標(biāo)識(shí)來判斷記錄是否有效柄瑰。如果明確業(yè)務(wù)數(shù)據(jù)不存在業(yè)務(wù)上的刪除闸氮，但是存在批量手工刪除或備份數(shù)據(jù)刪除，例如淘寶商品教沾、會(huì)員等蒲跨，則可以采用只過濾最后一條刪除流水的方式，通過狀態(tài)字段來標(biāo)識(shí)刪除記錄是否有效授翻。

3.2 阿里數(shù)據(jù)倉(cāng)庫(kù)的同步方式

• 數(shù)據(jù)來源的多樣性：來源于多個(gè)關(guān)系型數(shù)據(jù)庫(kù)或悲，數(shù)據(jù)高度結(jié)構(gòu)化，易于被計(jì)算機(jī)系統(tǒng)處理

• 數(shù)據(jù)量巨大

需要針對(duì)不同的數(shù)據(jù)源類型和數(shù)據(jù)應(yīng)用的時(shí)效性要求而采取不同的策略藏姐。

3.2.1 批量數(shù)據(jù)同步

對(duì)于離線類型的數(shù)據(jù)倉(cāng)庫(kù)應(yīng)用隆箩，需要將不同的數(shù)據(jù)源批量同步到數(shù)據(jù)倉(cāng)庫(kù)，以及將經(jīng)過數(shù)據(jù)倉(cāng)庫(kù)處理的結(jié)果數(shù)據(jù)定時(shí)同步到業(yè)務(wù)系統(tǒng)羔杨。

當(dāng)前市場(chǎng)上的數(shù)據(jù)庫(kù)系統(tǒng)種類很多捌臊，有行存儲(chǔ)的和列存儲(chǔ)的，有開源的和非開源的兜材，每一種數(shù)據(jù)庫(kù)的數(shù)據(jù)類型都略有不同理澎，而數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)則是集成各類數(shù)據(jù)源的地方，所以數(shù)據(jù)類型是統(tǒng)一的曙寡。要實(shí)現(xiàn)各類數(shù)據(jù)庫(kù)系統(tǒng)與數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)之間的批量雙向數(shù)據(jù)同步糠爬，就需要先將數(shù)據(jù)轉(zhuǎn)換為中間狀態(tài)，統(tǒng)一數(shù)據(jù)格式举庶。由于這類數(shù)據(jù)都是結(jié)構(gòu)化的执隧，且均支持標(biāo)準(zhǔn)的SQL語(yǔ)言查詢，所以所有的數(shù)據(jù)類型都可以轉(zhuǎn)換為字符串類型户侥。因此镀琉，我們可以通過將各類源數(shù)據(jù)庫(kù)系統(tǒng)的數(shù)據(jù)類型統(tǒng)一轉(zhuǎn)換為字符串類型的方式，實(shí)現(xiàn)數(shù)據(jù)格式的統(tǒng)一蕊唐。

阿里巴巴的DataX就是這樣一個(gè)能滿足多方向高自由度的異構(gòu)數(shù)據(jù)交換服務(wù)產(chǎn)品屋摔。對(duì)于不同的數(shù)據(jù)源，DataX通過插件的形式提供支持替梨，將數(shù)據(jù)從數(shù)據(jù)源讀出并轉(zhuǎn)換為中間狀態(tài)钓试，同時(shí)維護(hù)好數(shù)據(jù)的傳輸装黑、緩存等工作。數(shù)據(jù)在DataX中以中間狀態(tài)存在弓熏，并在目標(biāo)數(shù)據(jù)系統(tǒng)中將中間狀態(tài)的數(shù)據(jù)轉(zhuǎn)換為對(duì)應(yīng)的數(shù)據(jù)格式后寫入恋谭。

3.2.2 實(shí)時(shí)數(shù)據(jù)同步

對(duì)于日志類數(shù)據(jù)來說，需要盡快以數(shù)據(jù)流的方式不間斷地同步到數(shù)據(jù)倉(cāng)庫(kù)硝烂。另外箕别，還有一些數(shù)據(jù)應(yīng)用铜幽，需要對(duì)業(yè)務(wù)系統(tǒng)產(chǎn)生的數(shù)據(jù)進(jìn)行實(shí)時(shí)處理滞谢，比如天貓“雙11”的數(shù)據(jù)大屏，對(duì)所產(chǎn)生的交易數(shù)據(jù)需要實(shí)時(shí)匯總除抛，實(shí)現(xiàn)秒級(jí)的數(shù)據(jù)刷新狮杨。這類數(shù)據(jù)是通過解析MySQL的binlog日志（相當(dāng)于Oracle的歸檔日志）來實(shí)時(shí)獲得增量的數(shù)據(jù)更新，并通過消息訂閱模式來實(shí)現(xiàn)數(shù)據(jù)的實(shí)時(shí)同步的到忽。具體來說橄教，就是建立一個(gè)日志數(shù)據(jù)交換中心，通過專門的模塊從每臺(tái)服務(wù)器源源不斷地讀取日志數(shù)據(jù)喘漏，或者解析業(yè)務(wù)數(shù)據(jù)庫(kù)系統(tǒng)的binlog或歸檔日志护蝶，將增量數(shù)據(jù)以數(shù)據(jù)流的方式不斷同步到日志交換中心，然后通知所有訂閱了這些數(shù)據(jù)的數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)來獲取翩迈。

阿里巴巴的TimeTunnel（TT）系統(tǒng)就是這樣的實(shí)時(shí)數(shù)據(jù)傳輸平臺(tái)持灰，具有高性能、實(shí)時(shí)性负饲、順序性堤魁、高可靠性、高可用性返十、可擴(kuò)展性等特點(diǎn)妥泉。

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

3.3.1 分庫(kù)分表的處理

隨著業(yè)務(wù)的不斷增長(zhǎng)，業(yè)務(wù)系統(tǒng)處理的數(shù)據(jù)量也在飛速增加洞坑，需要系統(tǒng)具備靈活的擴(kuò)展能力和高并發(fā)大數(shù)據(jù)量的處理能力盲链，目前一些主流數(shù)據(jù)庫(kù)系統(tǒng)都提供了分布式分庫(kù)分表方案來解決這個(gè)問題。但是對(duì)于數(shù)據(jù)同步來說迟杂，這種分庫(kù)分表的設(shè)計(jì)無疑加大了同步處理的復(fù)雜度刽沾。試想一下，如果有一個(gè)中間表逢慌，具備將分布在不同數(shù)據(jù)庫(kù)中的不同表集成為一個(gè)表的能力悠轩，就能讓下游應(yīng)用像訪問單庫(kù)單表一樣方便。

阿里巴巴的TDDL（Taobao Distributed Data Layer）就是這樣一個(gè)分布式數(shù)據(jù)庫(kù)的訪問引擎攻泼，通過建立中間狀態(tài)的邏輯表來整合統(tǒng)一分庫(kù)分表的訪問火架。

圖3.7 分庫(kù)分表處理.png

3.3.2 高效同步和批量同步

數(shù)據(jù)同步的方法通常是先創(chuàng)建目標(biāo)表鉴象，再通過同步工具的填寫數(shù)據(jù)庫(kù)連接、表何鸡、字段等各種配置信息后測(cè)試完成數(shù)據(jù)同步纺弊。這也是DataX任務(wù)的配置過程，同步中心對(duì)DataX進(jìn)行進(jìn)一步封裝骡男，通過源系統(tǒng)元數(shù)據(jù)降低了數(shù)據(jù)庫(kù)連接淆游、表和字段等信息的配置復(fù)雜度，但在實(shí)際生產(chǎn)過程中我們?nèi)匀粫?huì)遇到一些問題隔盛。

• 隨著業(yè)務(wù)的發(fā)展和變化犹菱，會(huì)新增大批量的數(shù)據(jù)同步，相似并且重復(fù)的操作會(huì)降低開發(fā)人員的工作熱情

• 數(shù)據(jù)倉(cāng)庫(kù)的數(shù)據(jù)源種類特別豐富吮炕，遇到不同類型的數(shù)據(jù)源同步就要求開發(fā)人員去了解其特殊配置

• 部分真正的數(shù)據(jù)需求方腊脱，如Java開發(fā)和業(yè)務(wù)運(yùn)營(yíng)，由于存在相關(guān)數(shù)據(jù)同步的專業(yè)技能門檻龙亲，往往需要將需求提交給數(shù)據(jù)開發(fā)方來完成陕凹，額外增加了溝通和流程成本

為了解決上述問題，網(wǎng)里巴巴數(shù)據(jù)倉(cāng)庫(kù)研發(fā)了OneClick產(chǎn)品：

• 對(duì)不同數(shù)據(jù)源的數(shù)據(jù)同步配置透明化鳄炉，可以通過庫(kù)名和表名唯一定位杜耙，通過IDB接口獲取元數(shù)據(jù)信息自動(dòng)生成配置信息

• 簡(jiǎn)化了數(shù)據(jù)同步的操作步驟，實(shí)現(xiàn)了與數(shù)據(jù)同步相關(guān)的建表拂盯、配置任務(wù)佑女、發(fā)布、測(cè)試操作一鍵化處理磕仅，并且封裝成Web接口進(jìn)一步達(dá)到批量化的效果

• 降低了數(shù)據(jù)同步的技能門檻珊豹，讓數(shù)據(jù)需求方更加方便地獲取和使用數(shù)據(jù)

3.3.3 增量與全量同步的合并（重點(diǎn)！）

在批量數(shù)據(jù)同步中榕订，有些表的數(shù)據(jù)量隨著業(yè)務(wù)的發(fā)展越來越大店茶，如果按周期全量同步的方式會(huì)影響處理效率。在這種情況下劫恒，可以選擇每次只同步新變更的增量數(shù)據(jù)贩幻，然后與上一個(gè)同步周期獲得的全量數(shù)據(jù)進(jìn)行合井，從而獲得最新版本的全量數(shù)據(jù)两嘴。

• 在傳統(tǒng)的數(shù)據(jù)整合方案中丛楚，合并技術(shù)大多采用merge方式（update+insert）

• 當(dāng)前流行的大數(shù)據(jù)平臺(tái)基本都不支持update操作

現(xiàn)在我們比較推薦的方式是全外連接（full outer join）＋數(shù)據(jù)全量覆蓋重新加載（insert overwrite），即如日調(diào)度憔辫，則將當(dāng)天的增量數(shù)據(jù)和前一天的全量數(shù)據(jù)做全外連接趣些，重新加載最新的全量數(shù)據(jù)。

在大數(shù)據(jù)量規(guī)模下贰您，全量更新的性能比update要高得多坏平。

此外拢操，如果擔(dān)心數(shù)據(jù)更新錯(cuò)誤問題，可以采用分區(qū)方式舶替，每天保持一個(gè)最新的全量版本令境，保留較短的時(shí)間周期（如3～7天）。另外顾瞪，當(dāng)業(yè)務(wù)系統(tǒng)的表有物理刪除數(shù)據(jù)的操作舔庶，而數(shù)據(jù)倉(cāng)庫(kù)需要保留所有歷史數(shù)據(jù)時(shí)，也可以選擇這種方式陈醒，在數(shù)據(jù)倉(cāng)庫(kù)中永久保留最新的全量數(shù)據(jù)快照惕橙。

下面我們以淘寶訂單表的具體實(shí)例來說明。淘寶交易訂單表孵延，每天新增吕漂、變更的增量數(shù)據(jù)多達(dá)幾億條，歷史累計(jì)至今的全量數(shù)據(jù)則有幾百億條尘应，面對(duì)如此龐大的數(shù)據(jù)量，如果每天從業(yè)務(wù)系統(tǒng)全量同步顯然是不可能的吼虎∪郑可行的方式是同步當(dāng)天的增量數(shù)據(jù)，并與數(shù)據(jù)倉(cāng)庫(kù)中的前一天全量數(shù)據(jù)合并思灰，獲得截至當(dāng)天的最新全量數(shù)據(jù)玷犹。

圖3.9 淘寶交易訂單同步示意圖.png

3.3.4 同步性能的處理

數(shù)據(jù)同步任務(wù)是針對(duì)不同數(shù)據(jù)庫(kù)系統(tǒng)之間的數(shù)據(jù)同步問題而創(chuàng)建的一系列周期調(diào)度的任務(wù)。在大型的數(shù)據(jù)調(diào)度工作臺(tái)上洒疚，每天會(huì)運(yùn)行大量的數(shù)據(jù)同步任務(wù)歹颓。針對(duì)數(shù)據(jù)同步任務(wù)，一般首先需要設(shè)定首輪同步的線程數(shù)油湖，然后運(yùn)行同步任務(wù)巍扛。

基于負(fù)載均衡思想的新型數(shù)據(jù)同步方案：核心思想是通過目標(biāo)數(shù)據(jù)庫(kù)的元數(shù)據(jù)估算同步任務(wù)的總線程數(shù)，以及通過系統(tǒng)預(yù)先定義的期望同步速度估算首輪同步的線程數(shù)乏德，同時(shí)通過數(shù)據(jù)同步任務(wù)的業(yè)務(wù)優(yōu)先級(jí)決定同步線程的優(yōu)先級(jí)撤奸，最終提升同步任務(wù)的執(zhí)行效率和穩(wěn)定性。

3.3.5 數(shù)據(jù)漂移的處理（重點(diǎn)：袄ā）

通常我們把從源系統(tǒng)同步進(jìn)人數(shù)據(jù)倉(cāng)庫(kù)的第一層數(shù)據(jù)稱為ODS或者staging層數(shù)據(jù)胧瓜。數(shù)據(jù)漂移是ODS數(shù)據(jù)的一個(gè)頑疾，通常是指ODS表的同一個(gè)業(yè)務(wù)日期數(shù)據(jù)中包含前一天或后一天凌晨附近的數(shù)據(jù)或者丟失當(dāng)天的變更數(shù)據(jù)郑什。

由于ODS需要承接面向歷史的細(xì)節(jié)數(shù)據(jù)查詢需求府喳，這就需要物理落地到數(shù)據(jù)倉(cāng)庫(kù)的ODS表按時(shí)間段來切分進(jìn)行分區(qū)存儲(chǔ)，通常的做法是按某些時(shí)間戳字段來切分蘑拯，而實(shí)際上往往由于時(shí)間戳字段的準(zhǔn)確性問題導(dǎo)致發(fā)生數(shù)據(jù)漂移钝满。

通常肉津，時(shí)間戳字段分為以下四類，根據(jù)其中的某一個(gè)字段來切分ODS表舱沧，這就導(dǎo)致產(chǎn)生數(shù)據(jù)漂移：

• 數(shù)據(jù)庫(kù)表中用來標(biāo)識(shí)數(shù)據(jù)記錄更新時(shí)間的時(shí)間戳字段（modified_time）
  在實(shí)際生產(chǎn)中這種情況最常見妹沙，但是往往會(huì)發(fā)生不更新modifiedtime而導(dǎo)致的數(shù)據(jù)遺漏，或者凌晨時(shí)間產(chǎn)生的數(shù)據(jù)記錄漂移到后一天熟吏。

• 數(shù)據(jù)庫(kù)日志中用來標(biāo)識(shí)數(shù)據(jù)記錄更新時(shí)間的時(shí)間戳字段（log_time）
  由于網(wǎng)絡(luò)或者系統(tǒng)壓力問題距糖，log_time會(huì)晚于proc_time，從而導(dǎo)致凌晨時(shí)間產(chǎn)生的數(shù)據(jù)記錄漂移到后一天牵寺。例如悍引，在淘寶“雙11”大促期間凌晨時(shí)間產(chǎn)生的數(shù)據(jù)量非常大，用戶支付需要調(diào)用多個(gè)接口帽氓，從而導(dǎo)致log_time晚于實(shí)際的支付時(shí)間趣斤。

• 數(shù)據(jù)庫(kù)表中用來記錄具體業(yè)務(wù)過程發(fā)生時(shí)間的時(shí)間戳字段（proc_time）
  僅僅根據(jù)proc_time限制，我們所獲取的ODS表只是包含一個(gè)業(yè)務(wù)過程所產(chǎn)生的記錄黎休，會(huì)遺漏很多其他過程的變化記錄浓领，這違背了ODS和業(yè)務(wù)系統(tǒng)保持一致的設(shè)計(jì)原則。

• 標(biāo)識(shí)數(shù)據(jù)記錄被抽取到時(shí)間的時(shí)間戳字段（extract_time）
  這種情況數(shù)據(jù)漂移的問題最明顯势腮。

理論上毡庆，這幾個(gè)時(shí)間應(yīng)該是一致的珍剑，但是在實(shí)際生產(chǎn)中种吸，這幾個(gè)時(shí)間往往會(huì)出現(xiàn)差異毯欣，可能的原因有以下幾點(diǎn)：

• 由于數(shù)據(jù)抽取是需要時(shí)間的，extract_time往往會(huì)晚于前三個(gè)時(shí)間

• 前臺(tái)業(yè)務(wù)系統(tǒng)手工訂正數(shù)據(jù)時(shí)未更新modified_time

• 由于網(wǎng)絡(luò)或者系統(tǒng)壓力問題署照，log_time或者modified_time會(huì)晚于proc_time

處理方法主要有以下兩種：

• 多獲取后一天的數(shù)據(jù)

既然很難解決數(shù)據(jù)漂移的問題祸泪，那么就在ODS每個(gè)時(shí)間分區(qū)中向前、向后多冗余一些數(shù)據(jù)建芙，保障數(shù)據(jù)只會(huì)多不會(huì)少没隘，而具體的數(shù)據(jù)切分讓下游根據(jù)自身不同的業(yè)務(wù)場(chǎng)景用不同的業(yè)務(wù)時(shí)間proc_time來限制。但是這種方式會(huì)有一些數(shù)據(jù)誤差岁钓，例如一個(gè)訂單是當(dāng)天支付的升略，但是第二天凌晨申請(qǐng)退款關(guān)閉了該訂單，那么這條記錄的訂單狀態(tài)會(huì)被更新屡限，下游在統(tǒng)計(jì)支付訂單狀態(tài)時(shí)會(huì)出現(xiàn)錯(cuò)誤品嚣。

• 通過多個(gè)時(shí)間戳字段限制時(shí)間來獲取相對(duì)準(zhǔn)確的數(shù)據(jù)

（1）根據(jù)log_time分別冗余前一天最后15分鐘的數(shù)據(jù)和后一天凌晨開始15分鐘的數(shù)據(jù)，并用modifiedtime過濾非當(dāng)天數(shù)據(jù)钧大，確保數(shù)據(jù)不會(huì)因?yàn)橄到y(tǒng)問題而遺漏翰撑。
（2）然后根據(jù)log_time獲取后一天15分鐘的數(shù)據(jù)；針對(duì)此數(shù)據(jù)，按照主鍵根據(jù)log_time做升序排列去重眶诈。因?yàn)槲覀冃枰@取的是最接近當(dāng)天記錄變化的數(shù)據(jù)（數(shù)據(jù)庫(kù)日志將保留所有變化的數(shù)據(jù)涨醋，但是落地到ODS表的是根據(jù)主鍵去重獲取最后狀態(tài)變化的數(shù)據(jù)）。
（3）最后將前兩步的結(jié)果數(shù)據(jù)做全外連接逝撬，通過限制業(yè)務(wù)時(shí)間proc_time來獲取我們所需要的數(shù)據(jù)浴骂。

下面來看處理淘寶交易訂單的數(shù)據(jù)漂移的實(shí)際案例。我們?cè)谔幚怼半p11”交易訂單時(shí)發(fā)現(xiàn)宪潮，有一大批在11月11日23:59:59左右支付的交易訂單漂移到了12日溯警。主要原因是用戶下單支付后系統(tǒng)需要調(diào)用支付寶的接口而有所延遲，從而導(dǎo)致這些訂單最終生成的時(shí)間跨天了狡相。即modified_time和log_time都晚于proc_time梯轻。

如果訂單只有一個(gè)支付業(yè)務(wù)過程，則可以用支付時(shí)間來限制就能獲取到正確的數(shù)據(jù)尽棕。但是往往實(shí)際訂單有多個(gè)業(yè)務(wù)過程：下單喳挑、支付、成功滔悉，每個(gè)業(yè)務(wù)過程都有相應(yīng)的時(shí)間戳字段伊诵，并不只有支付數(shù)據(jù)會(huì)漂移。

如果直接通過多獲取后一天的數(shù)據(jù)氧敢，然后限制這些時(shí)間日戈，則可以獲取到相關(guān)數(shù)據(jù)，但是后一天的數(shù)據(jù)可能已經(jīng)更新多次孙乖，我們直接獲取到的那條記錄已經(jīng)是更新多次后的狀態(tài)，數(shù)據(jù)的準(zhǔn)確性存在一定的問題份氧。

因此唯袄，我們可以根據(jù)實(shí)際情況獲取后一天15分鐘的數(shù)據(jù)，并限制多個(gè)業(yè)務(wù)過程的時(shí)間戳字段（下單蜗帜、支付恋拷、成功）都是“雙11”當(dāng)天的，然后對(duì)這些數(shù)據(jù)按照訂單的modified_time做升序排列厅缺，獲取每個(gè)訂單首次數(shù)據(jù)變更的那條記錄蔬顾。

此外，我們可以根據(jù)log_time分別冗余前一天最后15分鐘的數(shù)據(jù)和后一天凌晨開始15分鐘的數(shù)據(jù)湘捎，并用modified_time過濾非當(dāng)天數(shù)據(jù)诀豁，針對(duì)每個(gè)訂單按照l(shuí)og_time進(jìn)行降序排列，取每個(gè)訂單當(dāng)天最后一次數(shù)據(jù)變更的那條記錄窥妇。

最后將兩份數(shù)據(jù)根據(jù)訂單做全外連接舷胜，將漂移數(shù)據(jù)回補(bǔ)到當(dāng)天數(shù)據(jù)中。

第4章 離線數(shù)據(jù)開發(fā)

從采集系統(tǒng)中收集了大量的原始數(shù)據(jù)后活翩，數(shù)據(jù)只有被整合和計(jì)算烹骨，才能被用于洞察商業(yè)規(guī)律翻伺，挖掘潛在信息，從而實(shí)現(xiàn)大數(shù)據(jù)價(jià)值沮焕，達(dá)到賦能于商業(yè)和創(chuàng)造價(jià)值的目的吨岭。

面對(duì)海量的數(shù)據(jù)和復(fù)雜的計(jì)算，阿里巴巴的數(shù)據(jù)計(jì)算層包括兩大體系：數(shù)據(jù)存儲(chǔ)及計(jì)算平臺(tái)（離線計(jì)算平臺(tái)MaxCompute和實(shí)時(shí)計(jì)算平臺(tái)StreamCompute）峦树、數(shù)據(jù)整合及管理體系（OneData）辣辫。

4.1 數(shù)據(jù)開發(fā)平臺(tái)

阿里數(shù)據(jù)研發(fā)崗位的工作大致可以概括為：了解需求->模型設(shè)計(jì)->ETL開發(fā)->測(cè)試->發(fā)布上線->日常運(yùn)維->任務(wù)下線。

與傳統(tǒng)的數(shù)據(jù)倉(cāng)庫(kù)開發(fā)（ETL）相比空入，阿里數(shù)據(jù)研發(fā)有如下幾個(gè)特點(diǎn)：

• 業(yè)務(wù)變更頻繁：業(yè)務(wù)發(fā)展非陈缢快，業(yè)務(wù)需求多且變更頻繁

• 需要快速交付：業(yè)務(wù)驅(qū)動(dòng)歪赢，需要快速給出結(jié)果

• 頻繁發(fā)布上線：迭代周期以天為單位化戳，每天需要發(fā)布數(shù)次

• 運(yùn)維任務(wù)多：在集團(tuán)公共層平均每個(gè)開發(fā)人員負(fù)責(zé)500多個(gè)任務(wù)

• 系統(tǒng)環(huán)境復(fù)雜：阿里平臺(tái)系統(tǒng)多為自研，且為了保證業(yè)務(wù)的發(fā)展埋凯，平臺(tái)系統(tǒng)的迭代速度較快点楼，平臺(tái)的穩(wěn)定性壓力較大

通過統(tǒng)一的計(jì)算平臺(tái)（MaxCompute）、統(tǒng)一的開發(fā)平臺(tái)（D2等相關(guān)平臺(tái)和工具）白对、統(tǒng)一的數(shù)據(jù)模型規(guī)范和統(tǒng)一的數(shù)據(jù)研發(fā)規(guī)范掠廓，可以在一定程度上解決數(shù)據(jù)研發(fā)的痛點(diǎn)。

4.1.1 統(tǒng)一計(jì)算平臺(tái)

阿里離線數(shù)據(jù)倉(cāng)庫(kù)的存儲(chǔ)和計(jì)算都是在阿里云大數(shù)據(jù)計(jì)算服務(wù)MaxCompute上完成的甩恼。

大數(shù)據(jù)計(jì)算服務(wù)MaxCompute是由阿里云自主研發(fā)的海量數(shù)據(jù)處理平臺(tái)蟀瞧，主要服務(wù)于海量數(shù)據(jù)的存儲(chǔ)和計(jì)算，提供完善的數(shù)據(jù)導(dǎo)入方案条摸，以及多種經(jīng)典的分布式計(jì)算模型悦污，提供海量數(shù)據(jù)倉(cāng)庫(kù)的解決方案，能夠更快速地解決用戶的海量數(shù)據(jù)計(jì)算問題钉蒲，有效降低企業(yè)成本切端，并保障數(shù)據(jù)安全。

MaxCompute采用抽象的作業(yè)處理框架顷啼，將不同場(chǎng)景的各種計(jì)算任務(wù)統(tǒng)一在同一個(gè)平臺(tái)之上踏枣，共享安全、存儲(chǔ)钙蒙、數(shù)據(jù)管理和資源調(diào)度茵瀑，為來自不同用戶需求的各種數(shù)據(jù)處理任務(wù)提供統(tǒng)一的編程接口和界面。它提供數(shù)據(jù)上傳/下載通道仪搔、SQL瘾婿、MapReduce、機(jī)器學(xué)習(xí)算法、圖編程模型和流式計(jì)算模型多種計(jì)算分析服務(wù)偏陪，并且提供完善的安全解決方案抢呆。

圖4.1 MaxCompute體系架構(gòu)圖.png

4.1.2 統(tǒng)一開發(fā)平臺(tái)

圖4.2 開發(fā)工作流圖.png

4.2 任務(wù)調(diào)度系統(tǒng)

現(xiàn)代信息化條件下的戰(zhàn)爭(zhēng)，從太空的衛(wèi)星到空中的各類作戰(zhàn)飛機(jī)笛谦，從地面的導(dǎo)彈到坦克火炮抱虐，從水面的大小艦艇到水下的潛艇，還有諸如網(wǎng)絡(luò)饥脑、電磁環(huán)境等多種方式恳邀、多種維度的作戰(zhàn)空間，各種武器裝備灶轰、人員谣沸、作戰(zhàn)環(huán)境紛繁復(fù)雜，如何能夠準(zhǔn)確笋颤、合理地調(diào)配這些資源乳附，組織有序、高效的攻防體系贏得勝利伴澄，最關(guān)鍵的是需要有一個(gè)強(qiáng)大的指揮系統(tǒng)赋除。

在云計(jì)算大數(shù)據(jù)時(shí)代，調(diào)度系統(tǒng)無疑是整個(gè)大數(shù)據(jù)體系的指揮中樞非凌。

調(diào)度系統(tǒng)中的各類任務(wù)互相依賴举农，形成一個(gè)典型的有向無環(huán)圖。

在傳統(tǒng)的數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)中敞嗡，很多是依靠Crontab定時(shí)任務(wù)功能進(jìn)行任務(wù)調(diào)度處理的颁糟。這種方式有很多弊端:

• 各任務(wù)之間的依賴基于執(zhí)行時(shí)間實(shí)現(xiàn)，容易造成前面的任務(wù)未結(jié)束或失敗而后面的任務(wù)已經(jīng)運(yùn)行
• 任務(wù)難以并發(fā)執(zhí)行喉悴，增加了整體的處理時(shí)間
• 無法設(shè)置任務(wù)優(yōu)先級(jí)
• 任務(wù)的管理維護(hù)很不方便滚停，無法進(jìn)行執(zhí)行效果分析等

任務(wù)狀態(tài)機(jī)模型是針對(duì)數(shù)據(jù)任務(wù)節(jié)點(diǎn)在整個(gè)運(yùn)行生命周期的狀態(tài)定義，總共有6種狀態(tài)粥惧，狀態(tài)之間的轉(zhuǎn)換邏輯如下圖所示。

圖4.9 任務(wù)狀態(tài)機(jī)模型關(guān)系圖.png

工作流狀態(tài)機(jī)模型是針對(duì)數(shù)據(jù)任務(wù)節(jié)點(diǎn)在調(diào)度樹中生成的工作流運(yùn)行的不同狀態(tài)定義最盅，共有5種狀態(tài)突雪，其關(guān)系如下圖所示。

圖4.10 工作流狀態(tài)機(jī)模型關(guān)系圖.png

調(diào)度引擎（PhoenixEngine）基于以上兩個(gè)狀態(tài)機(jī)模型原理涡贱，以事件驅(qū)動(dòng)的方式運(yùn)行咏删，為數(shù)據(jù)任務(wù)節(jié)點(diǎn)生成實(shí)例，并在調(diào)度樹中生成具體執(zhí)行的工作流问词。任務(wù)節(jié)點(diǎn)實(shí)例在工作流狀態(tài)機(jī)督函、任務(wù)狀態(tài)機(jī)和事件處理器之間轉(zhuǎn)換，其中調(diào)度引擎只涉及任務(wù)狀態(tài)機(jī)的未運(yùn)行和等待運(yùn)行兩種狀態(tài)，其他5種狀態(tài)存在于執(zhí)行引擎中辰狡。

4.2.3 特點(diǎn)及應(yīng)用

• 調(diào)度配置：輸入輸出配置和自動(dòng)識(shí)別相結(jié)合
• 定時(shí)調(diào)度：共有5種時(shí)間類型：分鐘锋叨、小時(shí)、日宛篇、周娃磺、月，具體可精確到秒
• 周期調(diào)度：可按照小時(shí)叫倍、日等時(shí)間周期運(yùn)行任務(wù)偷卧，與定時(shí)調(diào)度的區(qū)別是無須指定具體的開始運(yùn)行時(shí)間
• 手動(dòng)運(yùn)行
• 補(bǔ)數(shù)據(jù)：在完成數(shù)據(jù)開發(fā)的發(fā)布以后，有些表需要進(jìn)行數(shù)據(jù)初始化
• 基線管理：按優(yōu)先級(jí)分類管理任務(wù)
• 監(jiān)控報(bào)警：設(shè)置電話吆倦、短信听诸、郵件等不同的告警方式，實(shí)現(xiàn)了日常數(shù)據(jù)運(yùn)維的自動(dòng)化

第5章 實(shí)時(shí)技術(shù)

在大數(shù)據(jù)系統(tǒng)中蚕泽，離線批處理技術(shù)可以滿足非常多的數(shù)據(jù)使用場(chǎng)景需求晌梨，但在DT時(shí)代，每天面對(duì)的信息是瞬息萬變的赛糟，越來越多的應(yīng)用場(chǎng)景對(duì)數(shù)據(jù)的時(shí)效性提出了更高的要求派任。數(shù)據(jù)價(jià)值是具有時(shí)效性的，在一條數(shù)據(jù)產(chǎn)生的時(shí)候璧南，如果不能及時(shí)處理并在業(yè)務(wù)系統(tǒng)中使用掌逛，就不能讓數(shù)據(jù)保持最高的“新鮮度”和價(jià)值最大化。（如“雙11”實(shí)時(shí)成交量統(tǒng)計(jì)）

5.1 簡(jiǎn)介

業(yè)務(wù)訴求是希望能在第一時(shí)間拿到經(jīng)過加工后的數(shù)據(jù)司倚，以便實(shí)時(shí)監(jiān)控當(dāng)前業(yè)務(wù)狀態(tài)并做出運(yùn)營(yíng)決策豆混，引導(dǎo)業(yè)務(wù)往好的方向發(fā)展。比如網(wǎng)站上一個(gè)訪問量很高的廣告位动知，需要實(shí)時(shí)監(jiān)控廣告位的引流效果皿伺，如果轉(zhuǎn)化率非常低的話，運(yùn)營(yíng)人員就需要及時(shí)更換為其他廣告盒粮，以避免流量資源的浪費(fèi)鸵鸥。在這個(gè)例子中，就需要實(shí)時(shí)統(tǒng)計(jì)廣告位的曝光和點(diǎn)擊等指標(biāo)作為運(yùn)營(yíng)決策的參考丹皱。

按照數(shù)據(jù)的延遲情況妒穴，數(shù)據(jù)時(shí)效性一般分為三種：

• 離線：在今天（T）處理N天前（T-N,N>=1）的數(shù)據(jù)，延遲時(shí)間粒度為天
• 準(zhǔn)實(shí)時(shí)：在當(dāng)前小時(shí)（H）處理N小時(shí)前（H-N,N>0,如0.5小時(shí)摊崭、1小時(shí)等）的數(shù)據(jù)讼油，延遲時(shí)間粒度為小時(shí)
• 實(shí)時(shí)：在當(dāng)前時(shí)刻處理當(dāng)前的數(shù)據(jù)，延遲時(shí)間粒度為秒

離線和準(zhǔn)實(shí)時(shí)都可以在批處理系統(tǒng)中實(shí)現(xiàn)（比如Hadoop呢簸、Max Compute矮台、Spark等系統(tǒng)）乏屯，只是調(diào)度周期不一樣而己，而實(shí)時(shí)數(shù)據(jù)則需要在流式處理系統(tǒng)中完成瘦赫。

簡(jiǎn)單來說辰晕，流式數(shù)據(jù)處理技術(shù)是指業(yè)務(wù)系統(tǒng)每產(chǎn)生一條數(shù)據(jù)，就會(huì)立刻被采集并實(shí)時(shí)發(fā)送到流式任務(wù)中進(jìn)行處理耸彪，不需要定時(shí)調(diào)度任務(wù)來處理數(shù)據(jù)伞芹。

流式數(shù)據(jù)處理一般具有以下特征：

• 時(shí)效性高：數(shù)據(jù)實(shí)時(shí)采集、實(shí)時(shí)處理蝉娜，延時(shí)粒度在秒級(jí)甚至毫秒級(jí)
• 常駐任務(wù)：一旦啟動(dòng)后就會(huì)一直運(yùn)行唱较，直到人為地終止
• 性能要求高：如果處理吞吐量跟不上采集吞吐量，計(jì)算出來的數(shù)據(jù)就失去了實(shí)時(shí)的特性
• 應(yīng)用局限性：實(shí)時(shí)數(shù)據(jù)處理不能替代離線處理

另外召川，由于數(shù)據(jù)源是流式的南缓，在數(shù)據(jù)具有上下文關(guān)系的情況下，數(shù)據(jù)到達(dá)時(shí)間的不確定性導(dǎo)致實(shí)時(shí)處理跟離線處理得出來的結(jié)果會(huì)有一定的差異荧呐。

5.2 流式技術(shù)架構(gòu)

在流式計(jì)算技術(shù)中汉形，需要各個(gè)子系統(tǒng)之間相互依賴形成一條數(shù)據(jù)處理鏈路，才能產(chǎn)出結(jié)果最終對(duì)外提供實(shí)時(shí)數(shù)據(jù)服務(wù)倍阐。各個(gè)子系統(tǒng)按功能劃分的話概疆，主要分為以下幾部分：數(shù)據(jù)采集、數(shù)據(jù)處理峰搪、數(shù)據(jù)存儲(chǔ)和數(shù)據(jù)服務(wù)岔冀。

圖5.2 流式技術(shù)架構(gòu)圖.png

在數(shù)據(jù)采集和數(shù)據(jù)服務(wù)部分實(shí)時(shí)和離線是公用的，因?yàn)樵谶@兩層中都不需要關(guān)心數(shù)據(jù)的時(shí)效性概耻。這樣才能做到數(shù)據(jù)源的統(tǒng)一使套，避免流式處理和離線處理的不一致。

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

一般來自于各個(gè)業(yè)務(wù)的日志服務(wù)器（例如網(wǎng)站的瀏覽行為日志鞠柄、訂單的修改日志等）侦高，這些數(shù)據(jù)被實(shí)時(shí)采集到數(shù)據(jù)中間件中，供下游實(shí)時(shí)訂閱使用厌杜。

數(shù)據(jù)采集是整個(gè)數(shù)據(jù)處理鏈路的源頭奉呛，是所有數(shù)據(jù)處理鏈路的根節(jié)點(diǎn)，既然需要做到實(shí)時(shí)計(jì)算夯尽，那么自然就需要做到實(shí)時(shí)采集了侧馅。

• 數(shù)據(jù)庫(kù)變更日志
• 引擎訪問日志

不管是數(shù)據(jù)庫(kù)變更日志還是引擎訪問日志，都會(huì)在業(yè)務(wù)服務(wù)器上落地成文件呐萌，所以只要監(jiān)控文件的內(nèi)容發(fā)生變化，采集工具就可以把最新的數(shù)據(jù)采集下來谊娇。一般情況下肺孤，出于吞吐量以及系統(tǒng)壓力上的考慮罗晕，并不是新增一條記錄就采集一次，而是基于下面的原則赠堵，按批次對(duì)數(shù)據(jù)進(jìn)行采集小渊。

• 數(shù)據(jù)大小限制：當(dāng)達(dá)到限制條件時(shí)，把目前采集到的新數(shù)據(jù)作為一批（例如512KB寫一批）
• 時(shí)間闡值限制：當(dāng)時(shí)間達(dá)到一定條件時(shí)茫叭，也會(huì)把目前采集到的新數(shù)據(jù)作為一批酬屉，避免在數(shù)據(jù)量少的情況下一直不采集（例如30秒寫一批）

只要上面的其中一個(gè)條件達(dá)到了，就會(huì)被作為一批新數(shù)據(jù)采集到數(shù)據(jù)中間件中揍愁。這兩個(gè)條件的參數(shù)需要根據(jù)業(yè)務(wù)的需求來設(shè)定呐萨，當(dāng)批次采集頻繁時(shí)，可以降低延時(shí)莽囤，但必然會(huì)導(dǎo)致吞吐量下降谬擦。

對(duì)于采集到的數(shù)據(jù)需要一個(gè)數(shù)據(jù)交換平臺(tái)分發(fā)給下游，這個(gè)平臺(tái)就是數(shù)據(jù)中間件朽缎。數(shù)據(jù)中間件系統(tǒng)有很多實(shí)現(xiàn)方式惨远，比如開源的系統(tǒng)有Kafka，而阿里巴巴集團(tuán)內(nèi)部用得比較多的是TimeTunnel（原理和Kafka類似）话肖，還有MetaQ北秽、Notify等消息系統(tǒng)。

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

數(shù)據(jù)被采集到中間件中后最筒，需要下游實(shí)時(shí)訂閱數(shù)據(jù)贺氓，并拉取到流式計(jì)算系統(tǒng)的任務(wù)中進(jìn)行加工處理。這里需要提供流計(jì)算引擎以支持流式任務(wù)的執(zhí)行是钥。

實(shí)時(shí)數(shù)據(jù)處理應(yīng)用出于性能考慮掠归，計(jì)算任務(wù)往往是多線程的。一般會(huì)根據(jù)業(yè)務(wù)主鍵進(jìn)行分桶處理悄泥，并且大部分計(jì)算過程需要的數(shù)據(jù)都會(huì)放在內(nèi)存中虏冻，這樣會(huì)大大提高應(yīng)用的吞吐量。當(dāng)然弹囚，為了避免內(nèi)存溢出厨相，內(nèi)存中過期的數(shù)據(jù)需要定時(shí)清理，可以按照LRU（最近最少使用）算法或者業(yè)務(wù)時(shí)間集合歸類清理（比如業(yè)務(wù)時(shí)間屬于T-1的鸥鹉，會(huì)在今天凌晨進(jìn)行清理）蛮穿。

下面就實(shí)時(shí)任務(wù)遇到的幾個(gè)典型問題進(jìn)行講解：

• 去重指標(biāo)

（1）精確去重：明細(xì)數(shù)據(jù)是必須要保存下來的，當(dāng)遇到內(nèi)存問題時(shí)毁渗，可以通過數(shù)據(jù)傾斜來進(jìn)行處理践磅，把一個(gè)節(jié)點(diǎn)的內(nèi)存壓力分到多個(gè)節(jié)點(diǎn)上。

（2）模糊去重：在去重的明細(xì)數(shù)據(jù)量非常大灸异，而業(yè)務(wù)的精度要求不高的情況下府适，可以使用相關(guān)的去重算法羔飞，把內(nèi)存的使用量降到千分之一甚至萬分之一，以提高內(nèi)存的利用率檐春。

• 數(shù)據(jù)傾斜

數(shù)據(jù)傾斜是ETL中經(jīng)常遇到的問題逻淌，比如計(jì)算一天中全網(wǎng)訪客數(shù)或者成交額時(shí)，最終的結(jié)果只有一個(gè)疟暖，通常應(yīng)該是在一個(gè)節(jié)點(diǎn)上完成相關(guān)的計(jì)算任務(wù)卡儒。在數(shù)據(jù)量非常大的時(shí)候，單個(gè)節(jié)點(diǎn)的處理能力是有限的俐巴，必然會(huì)遇到性能瓶頸骨望。這時(shí)就需要對(duì)數(shù)據(jù)進(jìn)行分桶處理，分桶處理和離線處理的思路是一樣的窜骄。

（1）去重指標(biāo)分桶：通過對(duì)去重值進(jìn)行分桶Hash锦募，相同的值一定會(huì)被放在同一個(gè)桶中去重，最后再把每個(gè)桶里面的值進(jìn)行加和就得到總值邻遏，這里利用了每個(gè)桶的CPU和內(nèi)存資源糠亩。

(2）非去重指標(biāo)分桶：數(shù)據(jù)隨機(jī)分發(fā)到每個(gè)桶中，最后再把每個(gè)桶的值匯總准验，主要利用的是各個(gè)桶的CPU能力赎线。

• 事務(wù)處理

由于實(shí)時(shí)計(jì)算是分布式處理的，系統(tǒng)的不穩(wěn)定性必然會(huì)導(dǎo)致數(shù)據(jù)的處理有可能出現(xiàn)失敗的情況糊饱。比如網(wǎng)絡(luò)的抖動(dòng)導(dǎo)致數(shù)據(jù)發(fā)送不成功垂寥、機(jī)器重啟導(dǎo)致數(shù)據(jù)丟失等。在這些情況下另锋，怎么做到數(shù)據(jù)的精確處理呢滞项？上面提到的幾個(gè)流計(jì)算系統(tǒng)幾乎都提供了數(shù)據(jù)自動(dòng)ACK、失敗重發(fā)以及事務(wù)信息等機(jī)制夭坪。

（1）超時(shí)時(shí)間：由于數(shù)據(jù)處理是按照批次來進(jìn)行的文判，當(dāng)一批數(shù)據(jù)處理超時(shí)時(shí)，會(huì)從拓?fù)涞膕pout端重發(fā)數(shù)據(jù)室梅。另外戏仓，批次處理的數(shù)據(jù)量不宜過大，應(yīng)該增加一個(gè)限流的功能（限定一批數(shù)據(jù)的記錄數(shù)或者容量等）亡鼠，避免數(shù)據(jù)處理超時(shí)赏殃。

（2）事務(wù)信息：每批數(shù)據(jù)都會(huì)附帶一個(gè)事務(wù)ID的信息，在重發(fā)的情況下间涵，讓開發(fā)者自己根據(jù)事務(wù)信息去判斷數(shù)據(jù)第一次到達(dá)和重發(fā)時(shí)不同的處理邏輯仁热。

（3）備份機(jī)制：開發(fā)人員需要保證內(nèi)存數(shù)據(jù)可以通過外部存儲(chǔ)恢復(fù)，因此在計(jì)算中用到的中間結(jié)果數(shù)據(jù)需要備份到外部存儲(chǔ)中勾哩。

上面的這些機(jī)制都是為了保證數(shù)據(jù)的幕等性股耽。

5.2.3 數(shù)據(jù)存儲(chǔ)

數(shù)據(jù)被實(shí)時(shí)加工處理（比如聚合根盒、清洗等）后，會(huì)寫到某個(gè)在線服務(wù)的存儲(chǔ)系統(tǒng)中物蝙，供下游調(diào)用方使用。這里的寫操作是增量操作敢艰，并且是源源不斷的诬乞。

實(shí)時(shí)任務(wù)在運(yùn)行過程中，會(huì)計(jì)算很多維度和指標(biāo)钠导，這些數(shù)據(jù)需要放在一個(gè)存儲(chǔ)系統(tǒng)中作為恢復(fù)或者關(guān)聯(lián)使用震嫉。其中會(huì)涉及三種類型的數(shù)據(jù)：

• 中間計(jì)算結(jié)果

在實(shí)時(shí)應(yīng)用處理過程中，會(huì)有一些狀態(tài)的保存（比如去重指標(biāo)的明細(xì)數(shù)據(jù)）牡属，用于在發(fā)生故障時(shí)票堵，使用數(shù)據(jù)庫(kù)中的數(shù)據(jù)恢復(fù)內(nèi)存現(xiàn)場(chǎng)。

• 最終結(jié)果數(shù)據(jù)

指的是通過ETL處理后的實(shí)時(shí)結(jié)果數(shù)據(jù)逮栅，這些數(shù)據(jù)是實(shí)時(shí)更新的悴势，寫的頻率非常高，可以被下游直接使用措伐。

• 維表數(shù)據(jù)

在離線計(jì)算系統(tǒng)中特纤，通過同步工具導(dǎo)入到在線存儲(chǔ)系統(tǒng)中，供實(shí)時(shí)任務(wù)來關(guān)聯(lián)實(shí)時(shí)流數(shù)據(jù)侥加。

前面提到實(shí)時(shí)任務(wù)是多線程處理的捧存，這就意味著數(shù)據(jù)存儲(chǔ)系統(tǒng)必須能夠比較好地支持多并發(fā)讀寫，并且延時(shí)需要在毫秒級(jí)才能滿足實(shí)時(shí)的性能要求担败。在實(shí)踐中昔穴，一般使用HBase、Tair提前、MongoDB等列式存儲(chǔ)系統(tǒng)吗货。由于這些系統(tǒng)在寫數(shù)據(jù)時(shí)是先寫內(nèi)存再落磁盤，因此寫延時(shí)在毫秒級(jí)：讀請(qǐng)求也有緩存機(jī)制岖研，重要的是多并發(fā)讀時(shí)也可以達(dá)到毫秒級(jí)延時(shí)卿操。

但是這些系統(tǒng)的缺點(diǎn)也是比較明顯的，以HBase為例孙援，一張表必須要有rowkey害淤，而rowkey是按照ASCII碼來排序的，這就像關(guān)系型數(shù)據(jù)庫(kù)的索引一樣拓售，rowkey的規(guī)則限制了讀取數(shù)據(jù)的方式窥摄。如果業(yè)務(wù)方需要使用另一種讀取數(shù)據(jù)的方式，就必須重新輸出rowkey础淤。從這個(gè)角度來看崭放，HBase沒有關(guān)系型數(shù)據(jù)庫(kù)方便哨苛。但是HBase的一張表能夠存儲(chǔ)幾TB甚至幾十TB的數(shù)據(jù)，而關(guān)系型數(shù)據(jù)庫(kù)必須要分庫(kù)分表才能實(shí)現(xiàn)這個(gè)量級(jí)的數(shù)據(jù)存儲(chǔ)币砂。因此建峭，對(duì)于海量數(shù)據(jù)的實(shí)時(shí)計(jì)算，一般會(huì)采用非關(guān)系型數(shù)據(jù)庫(kù)决摧，以應(yīng)對(duì)大量的多并發(fā)讀寫亿蒸。

下面介紹在數(shù)據(jù)統(tǒng)計(jì)中表名設(shè)計(jì)和rowkey設(shè)計(jì)的一些實(shí)踐經(jīng)驗(yàn)：

• 表名設(shè)計(jì)

設(shè)計(jì)規(guī)則：匯總層標(biāo)識(shí)＋數(shù)據(jù)域＋主維度＋時(shí)間維度例如：dws_trd_slr_dtr，表示匯總層交易數(shù)據(jù)掌桩，根據(jù)賣家（slr）主維度+O點(diǎn)截至當(dāng)日（dtr）進(jìn)行統(tǒng)計(jì)匯總边锁。

這樣做的好處是，所有主維度相同的數(shù)據(jù)都放在一張物理表中波岛，避免表數(shù)量過多茅坛，難以維護(hù)。另外则拷，可以從表名上直觀地看到存儲(chǔ)的是什么數(shù)據(jù)內(nèi)容贡蓖，方便排查問題。

• rowkey設(shè)計(jì)

設(shè)計(jì)規(guī)則：MD5＋主維度＋維度標(biāo)識(shí)＋子維度1＋時(shí)間維度＋子維度2

例如：賣家ID的MD5前四位＋賣家ID+app ＋一級(jí)類目ID+ddd ＋二級(jí)類目ID隔躲。

以MD5的前四位作為rowkey的第一部分摩梧，可以把數(shù)據(jù)散列，讓服務(wù)器整體負(fù)載是均衡的宣旱，避免熱點(diǎn)問題仅父。在上面的例子中，賣家ID屬于主維度浑吟，在查數(shù)據(jù)時(shí)是必傳的笙纤。每個(gè)統(tǒng)計(jì)維度都會(huì)生成一個(gè)維度標(biāo)識(shí)，以便在rowkey上做區(qū)分组力。

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

在存儲(chǔ)系統(tǒng)上會(huì)架設(shè)一層統(tǒng)一的數(shù)據(jù)服務(wù)層（比如提供HSF接口省容、HTTP服務(wù)等），用于獲取實(shí)時(shí)計(jì)算結(jié)果燎字。

實(shí)時(shí)數(shù)據(jù)落地到存儲(chǔ)系統(tǒng)中后腥椒，使用方就可以通過統(tǒng)一的數(shù)據(jù)服務(wù)獲取到實(shí)時(shí)數(shù)據(jù)（比如下面要講到的OneService），其好處是：

• 不需要直連數(shù)據(jù)庫(kù)候衍，數(shù)據(jù)源等信息在數(shù)據(jù)服務(wù)層維護(hù)笼蛛，這樣當(dāng)存儲(chǔ)系統(tǒng)遷移時(shí)，對(duì)下游是透明的

• 調(diào)用方只需要使用服務(wù)層暴露的接口蛉鹿，不需要關(guān)心底層取數(shù)邏輯的實(shí)現(xiàn)

• 屏蔽存儲(chǔ)系統(tǒng)間的差異滨砍，統(tǒng)一的調(diào)用日志輸出，便于分析和監(jiān)控下游使用情況

5.3 流式數(shù)據(jù)模型

數(shù)據(jù)模型設(shè)計(jì)是貫通數(shù)據(jù)處理過程的，流式數(shù)據(jù)處理也一樣惋戏，需要對(duì)數(shù)據(jù)流建模分層领追。實(shí)時(shí)建模跟離線建模非常類似，數(shù)據(jù)模型整體上分為五層（ODS响逢、DWD绒窑、DWS、ADS舔亭、DIM）回论。

由于實(shí)時(shí)計(jì)算的局限性，每一層中并沒有像離線做得那么寬分歇，維度和指標(biāo)也沒有那么多，特別是涉及回溯狀態(tài)的指標(biāo)欧漱，在實(shí)時(shí)數(shù)據(jù)模型中幾乎沒有职抡。

整體來看逆皮，實(shí)時(shí)數(shù)據(jù)模型是離線數(shù)據(jù)模型的一個(gè)子集状知，在實(shí)時(shí)數(shù)據(jù)處理過程中满俗，很多模型設(shè)計(jì)就是參考離線數(shù)據(jù)模型實(shí)現(xiàn)的呛踊。

5.3.1 數(shù)據(jù)分層

• ODS層

操作數(shù)據(jù)層状勤，是直接從業(yè)務(wù)系統(tǒng)采集過來的最原始數(shù)據(jù)祟昭，包含了所有業(yè)務(wù)的變更過程静汤，數(shù)據(jù)粒度也是最細(xì)的飘诗。在這一層冈钦，實(shí)時(shí)和離線在源頭上是統(tǒng)一的郊丛，這樣的好處是用同一份數(shù)據(jù)加工出來的指標(biāo)，口徑基本是統(tǒng)一的瞧筛，可以更方便進(jìn)行實(shí)時(shí)和離線間數(shù)據(jù)比對(duì)厉熟。例如：原始的訂單變更記錄數(shù)據(jù)、服務(wù)器引擎的訪問日志较幌。

• DWD層

DWD層是在ODS層基礎(chǔ)上揍瑟，根據(jù)業(yè)務(wù)過程建模出來的實(shí)時(shí)事實(shí)明細(xì)層，對(duì)于訪問日志這種數(shù)據(jù)（沒有上下文關(guān)系乍炉，并且不需要等待過程的記錄）绢片，會(huì)回流到離線系統(tǒng)供下游使用，最大程度地保證實(shí)時(shí)和離線數(shù)據(jù)在ODS層和DWD層是一致的岛琼。例如：訂單的支付明細(xì)表底循、退款明細(xì)表、用戶的訪問日志明細(xì)表衷恭。

• DWS層

訂閱明細(xì)層的數(shù)據(jù)后此叠，會(huì)在實(shí)時(shí)任務(wù)中計(jì)算各個(gè)維度的匯總指標(biāo)。如果維度是各個(gè)垂直業(yè)務(wù)線通用的，則會(huì)放在實(shí)時(shí)通用匯總層灭袁，作為通用的數(shù)據(jù)模型使用猬错。比如電商網(wǎng)站的賣家粒度，只要涉及交易過程茸歧，就會(huì)跟這個(gè)維度相關(guān)倦炒，所以賣家維度是各個(gè)垂直業(yè)務(wù)的通用維度，其中的匯總指標(biāo)也是各個(gè)業(yè)務(wù)線共用的软瞎。例如：電商數(shù)據(jù)的幾大維度的匯總表（賣家逢唤、商品、買家）涤浇。

• ADS層

個(gè)性化維度匯總層鳖藕，對(duì)于不是特別通用的統(tǒng)計(jì)維度數(shù)據(jù)會(huì)放在這一層中，這里計(jì)算只有自身業(yè)務(wù)才會(huì)關(guān)注的維度和指標(biāo)只锭，眼其他業(yè)務(wù)線一般沒有交集著恩，常用于一些垂直創(chuàng)新業(yè)務(wù)中。例如：手機(jī)淘寶下面的某個(gè)愛逛街蜻展、微淘等垂直業(yè)務(wù)喉誊。

• DIM層

實(shí)時(shí)維表層的數(shù)據(jù)基本上都是從離線維表層導(dǎo)出來的，抽取到在線系統(tǒng)中供實(shí)時(shí)應(yīng)用調(diào)用纵顾。這一層對(duì)實(shí)時(shí)應(yīng)用來說是靜態(tài)的伍茄，所有的ETL處理工作會(huì)在離線系統(tǒng)中完成。維表在實(shí)時(shí)應(yīng)用的使用中跟離線稍有區(qū)別施逾，后面章節(jié)中會(huì)詳細(xì)說明敷矫。例如：商品維表、賣家維表音念、買家維表沪饺、類目維表。

ODS層：訂單粒度的變更過程闷愤，一筆訂單有多條記錄整葡。
DWD層：訂單粒度的支付記錄，一筆訂單只有一條記錄讥脐。
DWS層：賣家的實(shí)時(shí)成交金額遭居，一個(gè)賣家只有一條記錄，并且指標(biāo)在實(shí)時(shí)刷新旬渠。ADS層：外賣地區(qū)的實(shí)時(shí)成交金額俱萍，只有外賣業(yè)務(wù)使用。
DIM層：訂單商品類目和行業(yè)的對(duì)應(yīng)關(guān)系維表告丢。

5.3.2 多流關(guān)聯(lián)

在流式計(jì)算中常常需要把兩個(gè)實(shí)時(shí)流進(jìn)行主鍵關(guān)聯(lián)枪蘑，以得到對(duì)應(yīng)的實(shí)時(shí)明細(xì)表。在離線系統(tǒng)中兩個(gè)表關(guān)聯(lián)是非常簡(jiǎn)單的，因?yàn)殡x線計(jì)算在任務(wù)啟動(dòng)時(shí)已經(jīng)可以獲得兩張表的全量數(shù)據(jù)岳颇，只要根據(jù)關(guān)聯(lián)鍵進(jìn)行分桶關(guān)聯(lián)就可以了照捡。但流式計(jì)算不一樣，數(shù)據(jù)的到達(dá)是一個(gè)增量的過程话侧，并且數(shù)據(jù)到達(dá)的時(shí)間是不確定的和無序的栗精，因此在數(shù)據(jù)處理過程中會(huì)涉及中間狀態(tài)的保存和恢復(fù)機(jī)制等細(xì)節(jié)問題。

比如A表和B表使用ID進(jìn)行實(shí)時(shí)關(guān)聯(lián)瞻鹏，由于無法知道兩個(gè)表的到達(dá)順序悲立，因此在兩個(gè)數(shù)據(jù)流的每條新數(shù)據(jù)到來時(shí)，都需要到另外一張表中進(jìn)行查找新博。如A表的某條數(shù)據(jù)到達(dá)薪夕，到B表的全量數(shù)據(jù)中查找，如果能查找到赫悄，說明可以關(guān)聯(lián)上寥殖，拼接成一條記錄直接輸出到下游；但是如果關(guān)聯(lián)不上涩蜘，則需要放在內(nèi)存或外部存儲(chǔ)中等待，直到B表的記錄也到達(dá)熏纯。多流關(guān)聯(lián)的一個(gè)關(guān)鍵點(diǎn)就是需要相互等待同诫，只有雙方都到達(dá)了，才能關(guān)聯(lián)成功樟澜。

圖5.6 多流關(guān)聯(lián)示例.png

在上面的例子中误窖，實(shí)時(shí)采集兩張表的數(shù)據(jù)，每到來一條新數(shù)據(jù)時(shí)都在內(nèi)存中的對(duì)方表截至當(dāng)前的全量數(shù)據(jù)中查找秩贰，如果能查找到霹俺，則說明關(guān)聯(lián)成功，直接輸出：如果沒查找到毒费，則把數(shù)據(jù)放在內(nèi)存中的自己表數(shù)據(jù)集合中等待丙唧。另外，不管是否關(guān)聯(lián)成功觅玻，內(nèi)存中的數(shù)據(jù)都需要備份到外部存儲(chǔ)系統(tǒng)中想际，在任務(wù)重啟時(shí)，可以從外部存儲(chǔ)系統(tǒng)中恢復(fù)內(nèi)存數(shù)據(jù)溪厘，這樣才能保證數(shù)據(jù)不丟失胡本。因?yàn)樵谥貑r(shí)，任務(wù)是續(xù)跑的畸悬，不會(huì)重新跑之前的數(shù)據(jù)侧甫。

另外，訂單記錄的變更有可能發(fā)生多次（比如訂單的多個(gè)字段多次更新），在這種情況下披粟，需要根據(jù)訂單ID去重咒锻，避免A表和B表多次關(guān)聯(lián)成功；否則輸出到下游就會(huì)有多條記錄僻爽，這樣得到的數(shù)據(jù)是有重復(fù)的虫碉。

以上是整體的雙流關(guān)聯(lián)流程，在實(shí)際處理時(shí)胸梆，考慮到查找數(shù)據(jù)的性能敦捧，實(shí)時(shí)關(guān)聯(lián)這個(gè)步驟一般會(huì)把數(shù)據(jù)按照關(guān)聯(lián)主鍵進(jìn)行分桶處理，并且在故障恢復(fù)時(shí)也根據(jù)分桶來進(jìn)行碰镜，以降低查找數(shù)據(jù)量和提高吞吐量兢卵。

5.3.3 維表使用

在離線系統(tǒng)中，一般是根據(jù)業(yè)務(wù)分區(qū)來關(guān)聯(lián)事實(shí)表和維表的绪颖，因?yàn)樵陉P(guān)聯(lián)之前維表的數(shù)據(jù)就已經(jīng)就緒了秽荤。而在實(shí)時(shí)計(jì)算中，關(guān)聯(lián)維表一般會(huì)使用當(dāng)前的實(shí)時(shí)數(shù)據(jù)（T）去關(guān)聯(lián)T-2的維表數(shù)據(jù)柠横，相當(dāng)于在T的數(shù)據(jù)到達(dá)之前需要把維表數(shù)據(jù)準(zhǔn)備好窃款，并且一般是一份靜態(tài)的數(shù)據(jù)。

5.4 大促挑戰(zhàn)＆保障

• 毫秒級(jí)延時(shí)
• 洪峰明顯
• 高保障性
• 公關(guān)特性

第6章 數(shù)據(jù)服務(wù)

數(shù)據(jù)部門產(chǎn)出的海量數(shù)據(jù)牍氛，如何能方便高效地開放出去晨继，是我們一直想要解決的難題。在沒有數(shù)據(jù)服務(wù)的年代搬俊，數(shù)據(jù)開放的方式簡(jiǎn)單紊扬、粗暴，一般是直接將數(shù)據(jù)導(dǎo)出給對(duì)方唉擂。這種方式不僅低效餐屎，還帶來了安全隱患等諸多問題。

6.1 服務(wù)架構(gòu)演進(jìn)

6.1.4 統(tǒng)一的數(shù)據(jù)服務(wù)層

圖6.5 統(tǒng)一的數(shù)據(jù)服務(wù)層（OneService）架構(gòu)示意圖.png

6.2 技術(shù)架構(gòu)

6.3 最佳實(shí)踐

6.3.1 性能

• 資源分配
  剝離計(jì)算資源玩祟、查詢資源分配腹缩、執(zhí)行計(jì)劃優(yōu)化

• 緩存優(yōu)化
  元數(shù)據(jù)緩存、模型緩存空扎、結(jié)果緩存

• 查詢能力
  合并查詢庆聘、推送服務(wù)

6.3.2 穩(wěn)定性

• 發(fā)布系統(tǒng)
  元數(shù)據(jù)隔離、隔離發(fā)布

• 隔離
  機(jī)房隔離勺卢、分組隔離伙判、

• 安全限制

• 監(jiān)控
  調(diào)用日志采集、調(diào)用監(jiān)控

• 限流黑忱、降級(jí)

第7章 數(shù)據(jù)挖掘

7.1 數(shù)據(jù)挖掘概述

高速增長(zhǎng)的業(yè)務(wù)必然催生大數(shù)據(jù)挖掘應(yīng)用的蓬勃發(fā)展宴抚。當(dāng)我們從業(yè)務(wù)系統(tǒng)中能夠輕松采集到海量數(shù)據(jù)時(shí)勒魔，往往會(huì)發(fā)現(xiàn)里面的有效數(shù)據(jù)信息卻越來越稀疏，有效數(shù)據(jù)和無效數(shù)據(jù)的增長(zhǎng)率是不成比例的菇曲。因此冠绢，如何從海量數(shù)據(jù)中挖掘出有效信息形成真正的生產(chǎn)力，是所有大數(shù)據(jù)公司需要面對(duì)的共同課題常潮。

數(shù)據(jù)挖掘技術(shù)與數(shù)據(jù)倉(cāng)儲(chǔ)及計(jì)算技術(shù)的發(fā)展是相輔相成的弟胀，沒有數(shù)據(jù)基礎(chǔ)設(shè)施的發(fā)展與分布式并行計(jì)算技術(shù)，就不會(huì)有深度學(xué)習(xí)喊式，更不會(huì)見證AlphaGo的神奇孵户。

近年來，阿里巴巴數(shù)據(jù)挖掘應(yīng)用也呈現(xiàn)出井噴式的增長(zhǎng)態(tài)勢(shì)岔留。面向海量會(huì)員和商品的全局畫像夏哭、基于自然人的全域ID-Mapping、廣告精準(zhǔn)投放平臺(tái)献联、千人千面的個(gè)性化搜索與推薦技術(shù)竖配、非人流量與惡意設(shè)備的識(shí)別、商業(yè)競(jìng)爭(zhēng)情報(bào)的自動(dòng)化挖掘系統(tǒng)....這些或傳統(tǒng)或新興的大數(shù)據(jù)挖掘應(yīng)用已深入阿里巴巴業(yè)務(wù)的各個(gè)環(huán)節(jié)里逆，“無數(shù)據(jù)不智能进胯，無智能不商業(yè)”，大數(shù)據(jù)與AI/機(jī)器學(xué)習(xí)融合后的新商業(yè)革命己然到來原押。

基于大數(shù)據(jù)的企業(yè)級(jí)數(shù)據(jù)挖掘需要包含兩個(gè)要素：

• 面向機(jī)器學(xué)習(xí)算法的并行計(jì)算框架與算法平臺(tái)
• 面向企業(yè)級(jí)數(shù)據(jù)挖掘的算法資產(chǎn)管理體系

7.2 數(shù)據(jù)挖掘算法平臺(tái)

7.3 數(shù)據(jù)挖掘申臺(tái)體系

7.4 數(shù)據(jù)挖掘案例

7.4.1 用戶畫像

用戶畫像即是為用戶打上各種各樣的標(biāo)簽龄减，如年齡、性別班眯、職業(yè)、商品品牌偏好烁巫、商品類別偏好等署隘。這些標(biāo)簽的數(shù)目越豐富，標(biāo)簽越細(xì)化亚隙，對(duì)用戶的刻畫就越精準(zhǔn)磁餐。

例如，分析某用戶為女性阿弃，可能僅僅是將與女性相關(guān)的服裝诊霹、個(gè)人護(hù)理等商品作為推薦結(jié)果反饋給該用戶：但若根據(jù)用戶以往的瀏覽、交易等行為挖掘出進(jìn)一步的信息渣淳，如用戶的地理信息為海南脾还，買過某幾類品牌的服裝，則可以將薄款的入愧、品牌風(fēng)格相似的服裝作為推薦結(jié)果鄙漏。

一般而言嗤谚，用戶畫像可以分為基礎(chǔ)屬性、購(gòu)物偏好怔蚌、社交關(guān)系巩步、財(cái)富屬性等幾大類。對(duì)于刻畫淘寶網(wǎng)購(gòu)用戶桦踊，則應(yīng)側(cè)重于他們?cè)诰W(wǎng)購(gòu)上的行為偏好椅野。

下面以用戶女裝風(fēng)格偏好為例，講解該用戶標(biāo)簽是如何基于全域數(shù)據(jù)產(chǎn)出的籍胯。

購(gòu)買過淘寶商品的讀者對(duì)商品詳情頁(yè)都不會(huì)陌生竟闪，一件商品的關(guān)鍵特征除了反映在商品圖片和詳情頁(yè)中以外，主要可以采集的信息是商品的標(biāo)題以及參數(shù)描述芒炼。女裝有哪幾種風(fēng)格瘫怜？

首先需要將女裝行業(yè)下的商品標(biāo)題文本提取出來，對(duì)其進(jìn)行分詞本刽，得到龐大的女裝描繪詞庫(kù)鲸湃。然而，淘寶商品的標(biāo)題由賣家個(gè)人撰寫子寓，并不能保證其中的詞語(yǔ)都與商品風(fēng)格描述相關(guān)暗挑。因此，對(duì)于所得到的女裝描繪詞庫(kù)斜友，首先炸裆，需要根據(jù)詞語(yǔ)權(quán)重去除無效的停用詞，方法如計(jì)算TF-IDF值鲜屏。其次烹看，在女裝商品的參數(shù)描述中，如果已經(jīng)包含了一種商品風(fēng)格洛史，例如“通勤”“韓版”等常見風(fēng)格惯殊，那么通過計(jì)算詞庫(kù)中詞語(yǔ)與參數(shù)描述中風(fēng)格詞的相似度，可以過濾得到女裝風(fēng)格詞庫(kù)也殖，利用無監(jiān)督機(jī)器學(xué)習(xí)如LDA等方法可以計(jì)算出一種風(fēng)格所包含的詞匯及這些詞匯的重要性土思。

那么，買家偏好什么風(fēng)格昵忆嗜？在淘寶網(wǎng)上己儒，買家擁有瀏覽、搜索捆毫、點(diǎn)擊闪湾、收藏、加購(gòu)物車以及交易等多種行為绩卤，針對(duì)每種行為賦予不同的行為強(qiáng)度（比如瀏覽行為強(qiáng)度弱于交易行為）响谓，再考慮該商品的風(fēng)格元素組成损合，就能夠通過合理的方式獲知買家對(duì)該風(fēng)格的偏好程度了。

對(duì)于這樣的商品偏好計(jì)算娘纷，數(shù)據(jù)挖掘人員需要仔細(xì)分析用戶偏好的商品的類型嫁审、品牌、風(fēng)格元素赖晶、下單時(shí)間律适，這一系列行為可以構(gòu)成復(fù)雜的行為模塊。同理遏插，利用機(jī)器學(xué)習(xí)算法捂贿，可以從用戶行為中推測(cè)其身份，例如男生和女生胳嘲、老年與青年偏好的商品和行為方式存在區(qū)別厂僧，根據(jù)一定的用戶標(biāo)記，最后能夠預(yù)測(cè)出用戶的基礎(chǔ)身份信息了牛。

7.4.2 互聯(lián)網(wǎng)反作弊

• 賬戶／資金安全與網(wǎng)絡(luò)欺詐防控
• 非人行為和賬戶識(shí)別
• 虛假訂單與信用炒作識(shí)別
• 廣告推廣與APP安裝反作弊
• UGC惡意信息檢測(cè)