第2章 日記采集

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

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

2.1 瀏覽器的頁面日志采集

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

2.1.1 頁面瀏覽日志采集流程

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

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

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

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

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

2.1.2 頁面交互日記采集

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

業(yè)務(wù)方在元數(shù)據(jù)管理界面注冊需要采集交互日志的業(yè)務(wù)、具體的業(yè)務(wù)場景以及場景下的具體交互采集點(diǎn)，注冊完成后，系統(tǒng)生成對應(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ù)互動響應(yīng)代碼一起觸發(fā)和執(zhí)行

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

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

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

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

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

日志隔離分發(fā)

2.2 無線客戶端的日志采集

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

2.2.1 頁面事件

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

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

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

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

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

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

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

2.2.3 特殊場景

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

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

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

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

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

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

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

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

2.2.6 日志傳輸

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

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

2.3.1 典型場景

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

2.3.2 大促保障

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

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

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

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

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

同步方式分為

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

3.1.1 直連同步

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

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

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

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

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

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

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

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

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

存在的問題：

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

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

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

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

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

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

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

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

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ù)自動生成配置信息
• 簡化操作步驟，實現(xiàn)建表、配置任務(wù)、發(fā)布、測試操作一鍵化處理
• 降低數(shù)據(jù)同步的技能門檻

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

3.3.3 增量與全量同步的合并

隨著業(yè)務(wù)發(fā)展，數(shù)據(jù)量變大，如果周期全量同步會影響效率。這時，可以選擇每次同步新變更的增量數(shù)據(jù)，然后與上一個同步周期的全量數(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層的一個頑疾，通常是指ODS表的同一個業(yè)務(wù)日期數(shù)據(jù)中包含前一天或后一天的凌晨附近的數(shù)據(jù)或者丟失當(dāng)天的變更數(shù)據(jù)
舉例：
用戶在當(dāng)天23點(diǎn)59分59秒支付的訂單，但是由于支付系統(tǒng)需要處理一系列流程或者網(wǎng)絡(luò)故障等原因，導(dǎo)致更新時間變?yōu)榈诙?1點(diǎn)02分，統(tǒng)計支付訂單時，就會變成統(tǒng)計為第二天的數(shù)據(jù)

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

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

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

4.1.1 統(tǒng)一計算平臺

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

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

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

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

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

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

略

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

略

第5章 實時技術(shù)

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

5.1 簡介

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

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

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

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

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

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

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

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

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

1、去重指標(biāo)

• 精確去重
• 模糊去重

布隆過濾器

基數(shù)估計

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

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

• 數(shù)據(jù)類型
  中間計算結(jié)果
  最終結(jié)果數(shù)據(jù)
  維表數(shù)據(jù)
• 表名設(shè)計
  設(shè)計規(guī)則：匯總層標(biāo)識+數(shù)據(jù)域+主維度+時間維度
  例如： dws trd _s lr dtr ，表示匯總層交易數(shù)據(jù)，根據(jù)賣家（ sir ）主維度
  +O 點(diǎn)截至當(dāng)日（ dtr 進(jìn)行統(tǒng)計匯總。
• rowkey設(shè)計
  設(shè)計規(guī)則： MD5 ＋主維度＋維度標(biāo)識＋子維度 ＋時間維度＋子維度
  例如：賣家 ID MD5 前四位＋賣家 ID+ app 級類目 ID+ddd ＋二級類目 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ù)過程建模出來的實時事實明細(xì)層。例如：訂單的支付明細(xì)表，退款明細(xì)表，用戶的訪問日志明細(xì)表
數(shù)據(jù)舉例：訂單粒度的支付記錄，一筆訂單只有一條記錄。

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

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

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

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

5.3.3 維表使用

事實表：表格里存儲了能體現(xiàn)實際數(shù)據(jù)或詳細(xì)數(shù)值，一般由維度編碼和事實數(shù)據(jù)組成。例如下圖的
維度表：表格里存放了具有獨(dú)立屬性和層次結(jié)構(gòu)的數(shù)據(jù)，一般由維度編碼和對應(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)

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

6.1.1 DWSOA

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

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

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

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

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

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

6.1.2 OpenAPI

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

6.1.3 SmartDQ

SmartDQ封裝了跨異構(gòu)數(shù)據(jù)源和分布式查詢功能，把邏輯表的作用真正發(fā)揮出來了。SmartDQ開放給業(yè)務(wù)方通過寫SQL的方式對外提供服務(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)用場景主要是商家端實時直播
uTiming：主要提供即時任務(wù)和定時任務(wù)，應(yīng)用場景主要是滿足用戶運(yùn)行大數(shù)量任務(wù)的需求

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

todo 2022-3-24 17:07:39

總結(jié)

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

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