第2章 日記采集

阿里巴巴日志采集的兩大體系

• Web端，基于瀏覽器日志采集技術(shù)方案：Aplus.JS
• APP端，無線客戶端日志采集技術(shù)方案：UserTrack

2.1 瀏覽器的頁面日志采集

• 頁面瀏覽日志的采集，也就是當(dāng)一個(gè)頁面被瀏覽器加載呈現(xiàn)時(shí)的日志采集
  包含兩大最基礎(chǔ)的數(shù)據(jù)：訪客數(shù)：UV（Unique Visitors）和瀏覽量PV（Page View）
• 頁面交互日志的采集，就是對(duì)用戶在瀏覽器上與網(wǎng)頁進(jìn)行互動(dòng)行為的數(shù)據(jù)采集

2.1.1 頁面瀏覽日志采集流程

采集-發(fā)送-收集-解析存檔
整個(gè)過程都是依照HTML規(guī)范和HTTP協(xié)議自動(dòng)進(jìn)行，減少人工干預(yù)，保證日志的準(zhǔn)確性

客戶端日志采集
HTML文檔內(nèi)植入采集腳本，一種是在服務(wù)器返回響應(yīng)數(shù)據(jù)時(shí)動(dòng)態(tài)植入（見下圖），一種是在開發(fā)頁面時(shí)手動(dòng)植入。
采集的信息包含瀏覽行為的上下文信息、運(yùn)行環(huán)境信息等等

客戶端日志發(fā)送
采集腳本執(zhí)行時(shí)，向日志服務(wù)器發(fā)起日志請(qǐng)求。大多數(shù)情況下會(huì)立即執(zhí)行發(fā)送，個(gè)別場(chǎng)景下會(huì)延遲發(fā)出。
日志采集和發(fā)送模塊集成在一個(gè)腳本內(nèi)，采集到的信息一般以URL參數(shù)形式放在HTTP請(qǐng)求行內(nèi)。

服務(wù)端接收日志
日志服務(wù)器接收到日志請(qǐng)求后，一般會(huì)發(fā)回成功響應(yīng)，以免影響頁面加載。同時(shí)將請(qǐng)求內(nèi)容寫入日志緩沖區(qū)。

日志服務(wù)器解析文檔
由專門的日志處理程序順序讀出，并按照約定處理邏輯解析。
然后轉(zhuǎn)存入日志文件，并注入實(shí)時(shí)消息通道，供其他程序讀取和加工處理。

2.1.2 頁面交互日記采集

由于終端類型、頁面內(nèi)容、交互方式和用戶實(shí)際行為的千變?nèi)f化不可預(yù)估，交互日志的采集無法規(guī)定統(tǒng)一的采集內(nèi)容。
阿里巴巴通過一套"黃金令箭"的的采集解決方案來解決，步驟如下

業(yè)務(wù)方在元數(shù)據(jù)管理界面注冊(cè)需要采集交互日志的業(yè)務(wù)、具體的業(yè)務(wù)場(chǎng)景以及場(chǎng)景下的具體交互采集點(diǎn)，注冊(cè)完成后，系統(tǒng)生成對(duì)應(yīng)的采集代碼模板
黃金令箭使用方法參考：
https://github.com/alvarto/gulp-magix-spmlog
https://blog.naaln.com/2017/08/alibaba-data-track-1/

業(yè)務(wù)方將采集代碼植入頁面，并與交互行為做綁定

用戶產(chǎn)生指定行為，采集代碼、業(yè)務(wù)互動(dòng)響應(yīng)代碼一起觸發(fā)和執(zhí)行

采集動(dòng)作完成后，由采集代碼通過HTTP協(xié)議發(fā)送到日志服務(wù)器

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

識(shí)別流量攻擊、網(wǎng)絡(luò)爬蟲和流量作弊（虛假流量），通過算法識(shí)別并歸納出規(guī)則，對(duì)日志進(jìn)行過濾。

數(shù)據(jù)缺項(xiàng)補(bǔ)正，比如取值歸一，標(biāo)準(zhǔn)化處理或反向補(bǔ)正

剔除無意義、已經(jīng)失效或者冗余的數(shù)據(jù)

日志隔離分發(fā)

2.2 無線客戶端的日志采集

UserTrack（UT）根據(jù)用戶行為分成不同的事件，常用的包括頁面事件、控件點(diǎn)擊事件
對(duì)事件進(jìn)行分類
一方面是因?yàn)椴煌录挠|發(fā)時(shí)機(jī)、日志內(nèi)容，實(shí)現(xiàn)方式有所差異
另一方面是為了更好的完成數(shù)據(jù)分析，降低后續(xù)處理的復(fù)雜性

2.2.1 頁面事件

每條頁面事件記錄三類信息

設(shè)備及用戶的基本信息

被訪問頁面的信息，主要是業(yè)務(wù)參數(shù)，如商品ID，所屬店鋪

訪問基本路徑，如頁面來源，來源的來源，用于還原完整的訪問行為
UT提供了兩個(gè)接口
頁面展示時(shí)調(diào)用接口，記錄狀態(tài)信息，但此時(shí)不發(fā)送日志
頁面退出時(shí)調(diào)用接口（退出有可能是點(diǎn)擊了其他商品、返回、退出APP）發(fā)送日志
還有一個(gè)是頁面退出前，頁面擴(kuò)展信息的接口，比如給店鋪詳情頁添加店鋪ID，店鋪類別
上述3個(gè)接口需配合使用，頁面展示和頁面退出必須成對(duì)使用

為了平衡采集、計(jì)算和分析的成本，UT提供了透?jìng)鲄?shù)功能，就是把當(dāng)前頁面的某些信息，傳遞到下一個(gè)甚至下下一個(gè)頁面的日志中

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

控件點(diǎn)擊事件除了記錄設(shè)備信息、用戶信息，還記錄了控件所在頁面的名稱、控件的名稱、控件的業(yè)務(wù)參數(shù)
其他事件，就是用戶可以根據(jù)業(yè)務(wù)場(chǎng)景需求，使用自定義事件來采集相關(guān)信息，UT幫助提供了一些額外的功能，比如記錄事件的名稱、時(shí)長(zhǎng)、攜帶的屬性、對(duì)應(yīng)的頁面
UT還提供了一些默認(rèn)的采集方法，比如引用崩潰，應(yīng)用退出，頁面前后臺(tái)切換

2.2.3 特殊場(chǎng)景

比如場(chǎng)景曝光，提倡對(duì)這類日志進(jìn)行聚合，以減少對(duì)日志服務(wù)器的請(qǐng)求，適當(dāng)減少日志的大小。利用頁面的生命周期實(shí)現(xiàn)適當(dāng)?shù)木酆霞按_定發(fā)送時(shí)機(jī)。
再比如明顯的回退行為，點(diǎn)擊回退按鈕，滑屏等，舉例
A主頁面->B分類頁->C詳情頁->回退到B分類頁->D詳情頁。如果按照普通的路徑來處理，第二次進(jìn)入B分類頁的來源就會(huì)記錄為C詳情頁，以此類推，就會(huì)記錄到很多B分類頁的來源都來自于詳情頁。這種就需要做特殊處理

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

移動(dòng)應(yīng)用粗分為3種：原生應(yīng)用（Native APP）、網(wǎng)頁應(yīng)用（HTML5 APP、web APP）、混合模式移動(dòng)應(yīng)用（Hybird APP）
現(xiàn)在很多都是采用Hybird APP，頁面就在Native 和 H5 之間互跳，導(dǎo)致無法還原用戶路徑，數(shù)據(jù)容易丟失
這時(shí)候就需要將兩類日志進(jìn)行歸一，阿里巴巴采用的是把H5日志向Native日志歸
原因有二：

Native可以采集到更多的設(shè)備信息

Natvie會(huì)在本地緩存，網(wǎng)絡(luò)不佳也可以延遲上報(bào)，保證數(shù)據(jù)不丟失

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

移動(dòng)設(shè)備的唯一標(biāo)識(shí)

• PC端一般用Cookie
• 移動(dòng)端設(shè)備就很復(fù)雜了，包括MEI,IMSI,MAC UDID,IDFA,IMEI。系統(tǒng)的升級(jí)、用戶的自我保護(hù)意識(shí)更強(qiáng)，導(dǎo)致獲取設(shè)備的信息更難了
  阿里采用的是UTDID，而且隨著IOS和安卓系統(tǒng)對(duì)權(quán)限控制的不斷升級(jí)，方案和算法也一直在調(diào)整

2.2.6 日志傳輸

無線客戶端日志的上傳，不是產(chǎn)生一條上傳一條，而是產(chǎn)生日志后，存儲(chǔ)在客戶端本地，在伺機(jī)上傳。
上傳時(shí)時(shí)向服務(wù)器發(fā)送post請(qǐng)求，服務(wù)端進(jìn)行校驗(yàn)，然后追加到本地文件存儲(chǔ)。存儲(chǔ)方式采用nginx的accesslog，按天存儲(chǔ)。
日志服務(wù)器通過消息隊(duì)列（TimeTunel ，TT）來實(shí)現(xiàn)日志服務(wù)器到數(shù)據(jù)的計(jì)算的服務(wù)器

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

2.3.1 典型場(chǎng)景

• 日志分流和定制處理
  業(yè)界通用的是采集日志請(qǐng)求路徑幾乎歸一，阿里日志的請(qǐng)求URL是隨著頁面所在業(yè)務(wù)類型不同二變化的
• 采集與計(jì)算一體化設(shè)計(jì)

2.3.2 大促保障

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

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

數(shù)據(jù)存儲(chǔ)的方式不同，需要對(duì)數(shù)據(jù)同步進(jìn)行不一樣的處理

數(shù)據(jù)類型

• 關(guān)系型數(shù)據(jù)庫，如MySql，Oracle，DB2，SQL Server等
• 非關(guān)系性數(shù)據(jù)庫，如MongoDB，Redis，HBase，OceanBase等
• 阿里云對(duì)象存儲(chǔ)OSS，華為云對(duì)象存儲(chǔ)OBS等

同步方式分為

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

3.1.1 直連同步

通過定義好的API接口直接連接業(yè)務(wù)庫進(jìn)行同步

• 優(yōu)點(diǎn)：配置簡(jiǎn)單，實(shí)現(xiàn)容易，適合操作型業(yè)務(wù)系統(tǒng)的數(shù)據(jù)同步
• 缺點(diǎn)：對(duì)源系統(tǒng)性能影響較大，數(shù)據(jù)量大時(shí)，會(huì)降低或者拉胯業(yè)務(wù)系統(tǒng)的性能
  

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

通過哦約定好的文件編碼、大小、格式等，直接從源系統(tǒng)生成數(shù)據(jù)的文本文件，由專門的文件服務(wù)器傳輸?shù)侥繕?biāo)系統(tǒng)，然后加載到數(shù)據(jù)庫系統(tǒng)

• 適合多個(gè)異構(gòu)的數(shù)據(jù)庫系統(tǒng)（如MySQL、Oracle，SQL Server、DB2等）
• 文件上傳可能丟包或錯(cuò)誤，可以同時(shí)上傳一個(gè)校驗(yàn)文件，內(nèi)容包含數(shù)據(jù)量、文件大小等校驗(yàn)信息，保證數(shù)據(jù)的準(zhǔn)確性
• 源系統(tǒng)生成文件可以進(jìn)行加密和加密，目標(biāo)系統(tǒng)在進(jìn)行解壓縮和解密，提高傳輸效率和安全性

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

通過讀取歸檔日志文件收集數(shù)據(jù)信息，并判斷信息是否屬于被收集對(duì)象，再解析到目標(biāo)數(shù)據(jù)文件。
可以通過網(wǎng)絡(luò)協(xié)議，實(shí)現(xiàn)源系統(tǒng)和目標(biāo)系統(tǒng)之間的數(shù)據(jù)文件傳輸。

讀操作是在操作系統(tǒng)層面完成，不需要通過數(shù)據(jù)庫，不會(huì)給源系統(tǒng)帶來性能影響。

對(duì)性能影響較小，廣泛應(yīng)用于業(yè)務(wù)系統(tǒng)到數(shù)據(jù)倉庫的數(shù)據(jù)同步

存在的問題：

• 數(shù)據(jù)延遲。批量操作可能導(dǎo)致更新量超出系統(tǒng)處理峰值
• 投入較大。需要部署一個(gè)系統(tǒng)實(shí)時(shí)抽取數(shù)據(jù)
• 數(shù)據(jù)漂移和遺漏。

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

數(shù)據(jù)倉庫的特性之一：集成，整合不同的數(shù)據(jù)來源，不同形式的數(shù)據(jù)。
針對(duì)不同的數(shù)據(jù)源類型和數(shù)據(jù)應(yīng)用的時(shí)效性要求才去不同的策略

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

阿里巴巴的DataX是一個(gè)能滿足多方向高自由度的異構(gòu)數(shù)據(jù)交換服務(wù)產(chǎn)品。

• 數(shù)據(jù)源讀取轉(zhuǎn)換為中間狀態(tài)
  

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

通過解析MySQL的binlong日志實(shí)時(shí)獲得數(shù)據(jù)更新，并通過消息訂閱模式實(shí)現(xiàn)數(shù)據(jù)的實(shí)時(shí)同步

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

3.3.1 分庫分表的處理

3.3.2 高效同步和批量同步

存在的問題

隨著業(yè)務(wù)的發(fā)展和變化，使用傳統(tǒng)的方式完成同步工作，一方面工作量特別大，另一方面降低開發(fā)人員工作熱情

數(shù)據(jù)源種類豐富，需要開發(fā)人員了解不同類型的特殊配置

真正的數(shù)據(jù)需求方，由于存在專業(yè)技能門檻，需要交給數(shù)據(jù)開發(fā)方來完成

基于以上問題，阿里巴巴研發(fā)了OneClick產(chǎn)品

• 不同數(shù)據(jù)源配置透明化，通過庫名和表名唯一定位，通過IDB接口獲取元數(shù)據(jù)自動(dòng)生成配置信息
• 簡(jiǎn)化操作步驟，實(shí)現(xiàn)建表、配置任務(wù)、發(fā)布、測(cè)試操作一鍵化處理
• 降低數(shù)據(jù)同步的技能門檻

注：IDB是阿里巴巴集團(tuán)用于統(tǒng)一管理MySQL、OceanBase、PostgreSQL、 Oracle, SQL Server等關(guān)系型數(shù)據(jù)庫的平臺(tái)，它是一種集數(shù)據(jù)管理、結(jié)構(gòu)管理、診斷優(yōu)化、實(shí)時(shí)監(jiān)控和系統(tǒng)管理于一體的數(shù)據(jù)管理服務(wù)；在對(duì)集 團(tuán)數(shù)據(jù)庫表的統(tǒng)一管理服務(wù)過程中，IDB產(chǎn)出了數(shù)據(jù)庫、表、字段各個(gè) 級(jí)別元數(shù)據(jù)信息，并且提供了元數(shù)據(jù)接口服務(wù)。

3.3.3 增量與全量同步的合并

隨著業(yè)務(wù)發(fā)展，數(shù)據(jù)量變大，如果周期全量同步會(huì)影響效率。這時(shí)，可以選擇每次同步新變更的增量數(shù)據(jù)，然后與上一個(gè)同步周期的全量數(shù)據(jù)合并，獲得最新的全量數(shù)據(jù)。

傳統(tǒng)大多數(shù)采用merge（update+insert），現(xiàn)在比較推薦的是全外連接（full out join）+數(shù)量全量覆蓋加載（insert overwrite）

擴(kuò)展：mysql 全外連接：指返回左右表中所有的記錄和左右表中連接字段相等的記錄

舉例
第一張member表：

idname

1	張三
2	李四
3	王五

第二張job表：

idmemberIdjob

1	1	老師
2	3	工人
3	4	律師

SELECTmember.name,job.job FROMmember mFULL JOIN job j ON m.id = j.memberId

結(jié)果

namejob

張三	老師
李四	null
王五	工人
null	律師

3.3.4 同步性能的處理

略

3.3.5 數(shù)據(jù)漂移

從源系統(tǒng)同步進(jìn)入數(shù)據(jù)倉庫的第一層數(shù)據(jù)成為ODS，數(shù)據(jù)漂移是ODS層的一個(gè)頑疾，通常是指ODS表的同一個(gè)業(yè)務(wù)日期數(shù)據(jù)中包含前一天或后一天的凌晨附近的數(shù)據(jù)或者丟失當(dāng)天的變更數(shù)據(jù)
舉例：
用戶在當(dāng)天23點(diǎn)59分59秒支付的訂單，但是由于支付系統(tǒng)需要處理一系列流程或者網(wǎng)絡(luò)故障等原因，導(dǎo)致更新時(shí)間變?yōu)榈诙?1點(diǎn)02分，統(tǒng)計(jì)支付訂單時(shí)，就會(huì)變成統(tǒng)計(jì)為第二天的數(shù)據(jù)

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

原始數(shù)據(jù)收集后，只有被整合和計(jì)算，才能被用于洞察商業(yè)規(guī)律，挖掘潛在信息，從而實(shí)現(xiàn)大數(shù)據(jù)價(jià)值。

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

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

大數(shù)據(jù)計(jì)算服務(wù)MaxCompute,有四部分組成，客戶端、接入層、邏輯層、存儲(chǔ)與計(jì)算層

客戶端包括Web、SDK、CLT（Command Line Tool）、IDE

接入層提供HTTP服務(wù)、Cache、負(fù)載均衡、實(shí)現(xiàn)用戶認(rèn)證和服務(wù)層面的繁文控制

邏輯層又稱控制層，是核心部分，實(shí)現(xiàn)用戶空間和對(duì)象的管理 、命令的解析和執(zhí)行邏輯、數(shù)據(jù)對(duì)象的訪問控制和授權(quán)等。

計(jì)算層就是飛天內(nèi)核，它包括Pangu分布式文件系統(tǒng)、Fuxi資源調(diào)度系統(tǒng)、Nuwa/ZK Namespace服務(wù)、Shennong監(jiān)控模塊等

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

略

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

略

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

數(shù)據(jù)的價(jià)值是具有時(shí)效性的，如果不能及時(shí)處理數(shù)據(jù)并在業(yè)務(wù)系統(tǒng)中使用，就不能讓數(shù)據(jù)保持最高的“鮮活度”和價(jià)值最大化

5.1 簡(jiǎn)介

按照數(shù)據(jù)的延遲情況，數(shù)據(jù)時(shí)效性一般分為三種：離線、準(zhǔn)實(shí)時(shí)、實(shí)時(shí)

離線：在今天處理N天前的數(shù)據(jù)，延遲時(shí)間粒度為天

準(zhǔn)實(shí)時(shí)：在當(dāng)前小時(shí)處理N小時(shí)前的數(shù)據(jù)，延遲時(shí)間粒度為小時(shí)

實(shí)時(shí)：在當(dāng)前時(shí)刻處理當(dāng)前的數(shù)據(jù)，延遲時(shí)間粒度為秒
離線、準(zhǔn)實(shí)時(shí)都可以在拍出來系統(tǒng)中實(shí)現(xiàn)，實(shí)時(shí)數(shù)據(jù)需要在流式處理系統(tǒng)中完成，業(yè)務(wù)系統(tǒng)每產(chǎn)生一條數(shù)據(jù)，就會(huì)立刻被采集并實(shí)時(shí)發(fā)送到流式任務(wù)中處理
流式數(shù)據(jù)處理特征

• 時(shí)效性高：實(shí)時(shí)采集、實(shí)時(shí)處理
• 常駐任務(wù)：任務(wù)一旦啟動(dòng)就一直運(yùn)行
• 性能要求高：需要在數(shù)據(jù)量快速膨脹的情況下也能保持高吞吐量和延時(shí)
• 應(yīng)用局限性：業(yè)務(wù)復(fù)雜的場(chǎng)景，支持不足。具有上下文關(guān)系的情況下，數(shù)據(jù)到達(dá)時(shí)間的不確定性導(dǎo)致結(jié)果處理會(huì)有差異

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

子系統(tǒng)功能劃分

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

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

1、去重指標(biāo)

• 精確去重
• 模糊去重

布隆過濾器

基數(shù)估計(jì)

2、數(shù)據(jù)傾斜

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

• 數(shù)據(jù)類型
  中間計(jì)算結(jié)果
  最終結(jié)果數(shù)據(jù)
  維表數(shù)據(jù)
• 表名設(shè)計(jì)
  設(shè)計(jì)規(guī)則：匯總層標(biāo)識(shí)+數(shù)據(jù)域+主維度+時(shí)間維度
  例如： dws trd _s lr dtr ，表示匯總層交易數(shù)據(jù)，根據(jù)賣家（ sir ）主維度
  +O 點(diǎn)截至當(dāng)日（ dtr 進(jìn)行統(tǒng)計(jì)匯總。
• rowkey設(shè)計(jì)
  設(shè)計(jì)規(guī)則： MD5 ＋主維度＋維度標(biāo)識(shí)＋子維度 ＋時(shí)間維度＋子維度
  例如：賣家 ID MD5 前四位＋賣家 ID+ app 級(jí)類目 ID+ddd ＋二級(jí)類目 ID

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

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

數(shù)據(jù)模型分為5層：ODW、DWD、DWS、ADS、DIM

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

ODS層
ODS是屬于操作數(shù)據(jù)層，是直接從業(yè)務(wù)系統(tǒng)采集過來的最原始數(shù)據(jù)，包含了所有業(yè)務(wù)的變更過程，數(shù)據(jù)粒度也是最細(xì)的。例如：原始的訂單變更記錄，服務(wù)器引擎的訪問日志。
數(shù)據(jù)舉例：訂單粒度的變更過程，一筆訂單有多條記錄。

DWD層
DWD層是在ODS層的基礎(chǔ)上，根據(jù)業(yè)務(wù)過程建模出來的實(shí)時(shí)事實(shí)明細(xì)層。例如：訂單的支付明細(xì)表，退款明細(xì)表，用戶的訪問日志明細(xì)表
數(shù)據(jù)舉例：訂單粒度的支付記錄，一筆訂單只有一條記錄。

DWS層
計(jì)算各個(gè)維度的匯總指標(biāo)。例如：電商數(shù)據(jù)的幾大維度匯總表。賣家、商品、買家
數(shù)據(jù)舉例：賣家的實(shí)時(shí)成交金額，一個(gè)賣家只有一條記錄，且實(shí)時(shí)刷新

ADS層
個(gè)性化維度匯總層，針對(duì)不是特別通用的統(tǒng)計(jì)維度數(shù)據(jù)。例如：淘寶下面的某個(gè)愛逛街、微淘等垂直業(yè)務(wù)
數(shù)據(jù)舉例：外賣地區(qū)的實(shí)時(shí)成交金額，只有外賣業(yè)務(wù)使用

DIM層
實(shí)時(shí)維表層。例如商品維表、賣家維表、買家維表、類目維表。
數(shù)據(jù)舉例：訂單商品類目和行業(yè)的對(duì)應(yīng)關(guān)系維表
實(shí)時(shí)為表層

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

5.3.3 維表使用

事實(shí)表：表格里存儲(chǔ)了能體現(xiàn)實(shí)際數(shù)據(jù)或詳細(xì)數(shù)值，一般由維度編碼和事實(shí)數(shù)據(jù)組成。例如下圖的
維度表：表格里存放了具有獨(dú)立屬性和層次結(jié)構(gòu)的數(shù)據(jù)，一般由維度編碼和對(duì)應(yīng)的維度說明(標(biāo)簽)組成。

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

略

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

數(shù)據(jù)部門產(chǎn)出的海量數(shù)據(jù)，如何方便高效的開放出去。本章將介紹服務(wù)架構(gòu)的演進(jìn)過程及詳細(xì)的技術(shù)細(xì)節(jié)。

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

阿里不斷升級(jí)數(shù)據(jù)服務(wù)的架構(gòu)，依次經(jīng)理了DWSOA、OpenAPI、SmartDQ、OneService

6.1.1 DWSOA

根據(jù)需求通過SOA服務(wù)的方式，由需求驅(qū)動(dòng)，一個(gè)需求開發(fā)一個(gè)或者幾個(gè)接口，編寫接口文檔，開放給業(yè)務(wù)方。
缺陷：

接口粒度較粗，靈活性不高，擴(kuò)展性差，復(fù)用率低，

隨著業(yè)務(wù)對(duì)需求增加，接口數(shù)量也會(huì)一直增加，維護(hù)成本高

開發(fā)效率低，無法快速響應(yīng)業(yè)務(wù)，從需求、開發(fā)、測(cè)試、上線流程長(zhǎng)。即使增加一兩個(gè)字段，也要走整套流程。

接口眾多不好維護(hù)

SOA：面向服務(wù)架構(gòu)（Service-Oriented Architecture）
百度百科：面向服務(wù)架構(gòu)（SOA）是一個(gè)組件模型，它將應(yīng)用程序的不同功能單元（稱為服務(wù)）進(jìn)行拆分，并通過這些服務(wù)之間定義良好的接口和協(xié)議聯(lián)系起來。接口是采用中立的方式進(jìn)行定義的，它應(yīng)該獨(dú)立于實(shí)現(xiàn)服務(wù)的硬件平臺(tái)、操作系統(tǒng)和編程語言。這使得構(gòu)建在各種各樣的系統(tǒng)中的服務(wù)可以以一種統(tǒng)一和通用的方式進(jìn)行交互。
簡(jiǎn)單理解就是根據(jù)業(yè)務(wù)的需求，把系統(tǒng)拆分成大小剛好的，合適的，獨(dú)立部署的模塊，每個(gè)模塊之間互相獨(dú)立。
參考：https://www.zhihu.com/question/42061683?sort=created

6.1.2 OpenAPI

將數(shù)據(jù)按照統(tǒng)計(jì)粒度進(jìn)行聚合，同樣維度的數(shù)據(jù)，形成一張邏輯表。
缺陷：隨著時(shí)間推移，對(duì)數(shù)據(jù)的深度使用，維度越來越多，OpenAPI接口也越來越多，帶來大量對(duì)象關(guān)系映射的維護(hù)工作。

6.1.3 SmartDQ

SmartDQ封裝了跨異構(gòu)數(shù)據(jù)源和分布式查詢功能，把邏輯表的作用真正發(fā)揮出來了。SmartDQ開放給業(yè)務(wù)方通過寫SQL的方式對(duì)外提供服務(wù)，業(yè)務(wù)方不需要關(guān)心底層由多少物理表組成，甚至不需要關(guān)心物理表是HBase還是MySQL。

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

統(tǒng)一的數(shù)據(jù)服務(wù)層（OneService）
服務(wù)類型：OneService-SmartDQ、OneService-Lego、OneService-iPush、OneService-uTiming
Lego：插件化開發(fā)微服務(wù)，用Docker做隔離
iPush：主要提供WebSocket和long polling，應(yīng)用場(chǎng)景主要是商家端實(shí)時(shí)直播
uTiming：主要提供即時(shí)任務(wù)和定時(shí)任務(wù)，應(yīng)用場(chǎng)景主要是滿足用戶運(yùn)行大數(shù)量任務(wù)的需求

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

todo 2022-3-24 17:07:39

總結(jié)

以上是生活随笔為你收集整理的【大数据之路-阿里巴巴大数据实践】第一篇 数据技术篇的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。