第2章 日記采集

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

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

2.1 瀏覽器的頁面日志采集

• 頁面瀏覽日志的采集，也就是當一個頁面被瀏覽器加載呈現時的日志采集
  包含兩大最基礎的數據：訪客數：UV（Unique Visitors）和瀏覽量PV（Page View）
• 頁面交互日志的采集，就是對用戶在瀏覽器上與網頁進行互動行為的數據采集

2.1.1 頁面瀏覽日志采集流程

采集-發送-收集-解析存檔
整個過程都是依照HTML規范和HTTP協議自動進行，減少人工干預，保證日志的準確性

客戶端日志采集
HTML文檔內植入采集腳本，一種是在服務器返回響應數據時動態植入（見下圖），一種是在開發頁面時手動植入。
采集的信息包含瀏覽行為的上下文信息、運行環境信息等等

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

服務端接收日志
日志服務器接收到日志請求后，一般會發回成功響應，以免影響頁面加載。同時將請求內容寫入日志緩沖區。

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

2.1.2 頁面交互日記采集

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

業務方在元數據管理界面注冊需要采集交互日志的業務、具體的業務場景以及場景下的具體交互采集點，注冊完成后，系統生成對應的采集代碼模板
黃金令箭使用方法參考：
https://github.com/alvarto/gulp-magix-spmlog
https://blog.naaln.com/2017/08/alibaba-data-track-1/

業務方將采集代碼植入頁面，并與交互行為做綁定

用戶產生指定行為，采集代碼、業務互動響應代碼一起觸發和執行

采集動作完成后，由采集代碼通過HTTP協議發送到日志服務器

2.1.3 頁面日志的服務器端清洗和預處理

識別流量攻擊、網絡爬蟲和流量作弊（虛假流量），通過算法識別并歸納出規則，對日志進行過濾。

數據缺項補正，比如取值歸一，標準化處理或反向補正

剔除無意義、已經失效或者冗余的數據

日志隔離分發

2.2 無線客戶端的日志采集

UserTrack（UT）根據用戶行為分成不同的事件，常用的包括頁面事件、控件點擊事件
對事件進行分類
一方面是因為不同事件的觸發時機、日志內容，實現方式有所差異
另一方面是為了更好的完成數據分析，降低后續處理的復雜性

2.2.1 頁面事件

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

設備及用戶的基本信息

被訪問頁面的信息，主要是業務參數，如商品ID，所屬店鋪

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

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

2.2.2 控件點擊及其他事件

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

2.2.3 特殊場景

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

2.2.4 H5 & Native日志統一

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

Native可以采集到更多的設備信息

Natvie會在本地緩存，網絡不佳也可以延遲上報，保證數據不丟失

2.2.5 設備標識

移動設備的唯一標識

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

2.2.6 日志傳輸

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

2.3 日志采集的挑戰

2.3.1 典型場景

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

2.3.2 大促保障

第3章 數據同步

3.1 數據同步基礎

數據存儲的方式不同，需要對數據同步進行不一樣的處理

數據類型

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

同步方式分為

• 直連同步
• 數據文件同步
• 數據庫日志解析同步

3.1.1 直連同步

通過定義好的API接口直接連接業務庫進行同步

• 優點：配置簡單，實現容易，適合操作型業務系統的數據同步
• 缺點：對源系統性能影響較大，數據量大時，會降低或者拉胯業務系統的性能
  

3.1.2 數據文件同步

通過哦約定好的文件編碼、大小、格式等，直接從源系統生成數據的文本文件，由專門的文件服務器傳輸到目標系統，然后加載到數據庫系統

• 適合多個異構的數據庫系統（如MySQL、Oracle，SQL Server、DB2等）
• 文件上傳可能丟包或錯誤，可以同時上傳一個校驗文件，內容包含數據量、文件大小等校驗信息，保證數據的準確性
• 源系統生成文件可以進行加密和加密，目標系統在進行解壓縮和解密，提高傳輸效率和安全性

3.1.3 數據庫日志解析同步

通過讀取歸檔日志文件收集數據信息，并判斷信息是否屬于被收集對象，再解析到目標數據文件。
可以通過網絡協議，實現源系統和目標系統之間的數據文件傳輸。

讀操作是在操作系統層面完成，不需要通過數據庫，不會給源系統帶來性能影響。

對性能影響較小，廣泛應用于業務系統到數據倉庫的數據同步

存在的問題：

• 數據延遲。批量操作可能導致更新量超出系統處理峰值
• 投入較大。需要部署一個系統實時抽取數據
• 數據漂移和遺漏。

3.2 阿里數據倉庫的同步方式

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

3.2.1 批量數據同步

阿里巴巴的DataX是一個能滿足多方向高自由度的異構數據交換服務產品。

• 數據源讀取轉換為中間狀態
  

3.2.2 實時數據同步

通過解析MySQL的binlong日志實時獲得數據更新，并通過消息訂閱模式實現數據的實時同步

3.3 數據同步遇到的問題和解決方案

3.3.1 分庫分表的處理

3.3.2 高效同步和批量同步

存在的問題

隨著業務的發展和變化，使用傳統的方式完成同步工作，一方面工作量特別大，另一方面降低開發人員工作熱情

數據源種類豐富，需要開發人員了解不同類型的特殊配置

真正的數據需求方，由于存在專業技能門檻，需要交給數據開發方來完成

基于以上問題，阿里巴巴研發了OneClick產品

• 不同數據源配置透明化，通過庫名和表名唯一定位，通過IDB接口獲取元數據自動生成配置信息
• 簡化操作步驟，實現建表、配置任務、發布、測試操作一鍵化處理
• 降低數據同步的技能門檻

注：IDB是阿里巴巴集團用于統一管理MySQL、OceanBase、PostgreSQL、 Oracle, SQL Server等關系型數據庫的平臺，它是一種集數據管理、結構管理、診斷優化、實時監控和系統管理于一體的數據管理服務；在對集 團數據庫表的統一管理服務過程中，IDB產出了數據庫、表、字段各個 級別元數據信息，并且提供了元數據接口服務。

3.3.3 增量與全量同步的合并

隨著業務發展，數據量變大，如果周期全量同步會影響效率。這時，可以選擇每次同步新變更的增量數據，然后與上一個同步周期的全量數據合并，獲得最新的全量數據。

傳統大多數采用merge（update+insert），現在比較推薦的是全外連接（full out join）+數量全量覆蓋加載（insert overwrite）

擴展：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

結果

namejob

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

3.3.4 同步性能的處理

略

3.3.5 數據漂移

從源系統同步進入數據倉庫的第一層數據成為ODS，數據漂移是ODS層的一個頑疾，通常是指ODS表的同一個業務日期數據中包含前一天或后一天的凌晨附近的數據或者丟失當天的變更數據
舉例：
用戶在當天23點59分59秒支付的訂單，但是由于支付系統需要處理一系列流程或者網絡故障等原因，導致更新時間變為第二天01點02分，統計支付訂單時，就會變成統計為第二天的數據

第4章 離線數據開發

原始數據收集后，只有被整合和計算，才能被用于洞察商業規律，挖掘潛在信息，從而實現大數據價值。

4.1 數據開發平臺

4.1.1 統一計算平臺

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

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

接入層提供HTTP服務、Cache、負載均衡、實現用戶認證和服務層面的繁文控制

邏輯層又稱控制層，是核心部分，實現用戶空間和對象的管理 、命令的解析和執行邏輯、數據對象的訪問控制和授權等。

計算層就是飛天內核，它包括Pangu分布式文件系統、Fuxi資源調度系統、Nuwa/ZK Namespace服務、Shennong監控模塊等

4.1.2 統一開發平臺

略

4.2 任務調度系統

略

第5章 實時技術

數據的價值是具有時效性的，如果不能及時處理數據并在業務系統中使用，就不能讓數據保持最高的“鮮活度”和價值最大化

5.1 簡介

按照數據的延遲情況，數據時效性一般分為三種：離線、準實時、實時

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

準實時：在當前小時處理N小時前的數據，延遲時間粒度為小時

實時：在當前時刻處理當前的數據，延遲時間粒度為秒
離線、準實時都可以在拍出來系統中實現，實時數據需要在流式處理系統中完成，業務系統每產生一條數據，就會立刻被采集并實時發送到流式任務中處理
流式數據處理特征

• 時效性高：實時采集、實時處理
• 常駐任務：任務一旦啟動就一直運行
• 性能要求高：需要在數據量快速膨脹的情況下也能保持高吞吐量和延時
• 應用局限性：業務復雜的場景，支持不足。具有上下文關系的情況下，數據到達時間的不確定性導致結果處理會有差異

5.2 流式技術架構

子系統功能劃分

數據采集

數據處理
數據去重

1、去重指標

• 精確去重
• 模糊去重

布隆過濾器

基數估計

2、數據傾斜

數據存儲

• 數據類型
  中間計算結果
  最終結果數據
  維表數據
• 表名設計
  設計規則：匯總層標識+數據域+主維度+時間維度
  例如： dws trd _s lr dtr ，表示匯總層交易數據，根據賣家（ sir ）主維度
  +O 點截至當日（ dtr 進行統計匯總。
• rowkey設計
  設計規則： MD5 ＋主維度＋維度標識＋子維度 ＋時間維度＋子維度
  例如：賣家 ID MD5 前四位＋賣家 ID+ app 級類目 ID+ddd ＋二級類目 ID

數據服務

5.3 流式數據模型

數據模型分為5層：ODW、DWD、DWS、ADS、DIM

5.3.1 數據分層

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

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

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

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

DIM層
實時維表層。例如商品維表、賣家維表、買家維表、類目維表。
數據舉例：訂單商品類目和行業的對應關系維表
實時為表層

5.3.2 多流關聯

5.3.3 維表使用

事實表：表格里存儲了能體現實際數據或詳細數值，一般由維度編碼和事實數據組成。例如下圖的
維度表：表格里存放了具有獨立屬性和層次結構的數據，一般由維度編碼和對應的維度說明(標簽)組成。

5.4 大促挑戰&保障

略

第6章 數據服務

數據部門產出的海量數據，如何方便高效的開放出去。本章將介紹服務架構的演進過程及詳細的技術細節。

6.1 服務架構演進

阿里不斷升級數據服務的架構，依次經理了DWSOA、OpenAPI、SmartDQ、OneService

6.1.1 DWSOA

根據需求通過SOA服務的方式，由需求驅動，一個需求開發一個或者幾個接口，編寫接口文檔，開放給業務方。
缺陷：

接口粒度較粗，靈活性不高，擴展性差，復用率低，

隨著業務對需求增加，接口數量也會一直增加，維護成本高

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

接口眾多不好維護

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

6.1.2 OpenAPI

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

6.1.3 SmartDQ

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

6.1.4 統一的數據層服務

統一的數據服務層（OneService）
服務類型：OneService-SmartDQ、OneService-Lego、OneService-iPush、OneService-uTiming
Lego：插件化開發微服務，用Docker做隔離
iPush：主要提供WebSocket和long polling，應用場景主要是商家端實時直播
uTiming：主要提供即時任務和定時任務，應用場景主要是滿足用戶運行大數量任務的需求

第7章 數據挖掘

todo 2022-3-24 17:07:39

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。