第2章 日志采集
2.1 瀏覽器的頁面日志采集
主要分為兩類:頁面展現日志采集、頁面交互日志采集
2.1.1 頁面瀏覽日志采集流程
一次HTTP請求中發(fā)生了什么:
https://blog.csdn.net/qq_40804005/article/details/82876209
以訪問淘寶首頁為例,
(1)輸入URL
(2)發(fā)起HTTP請求,一個標準的HTTP請求包含請求行(方法、URL、版本號)、請求報頭(header)、請求正文(可選)
(3)服務端接受并解析.返回包括狀態(tài)行(包括狀態(tài)碼)、響應報頭、響應正文(html)
頁面瀏覽日志采集過程:
(1)客戶端日志采集,植入HTML文檔javascript,通過該腳本獲取各種信息.
(2)客戶端日志發(fā)送,日志采集與發(fā)送一般會集成在同一個腳本內,大部分情況采集完成即進行上報.
(3)服務端日志收集,服務端向客戶端發(fā)送確認信息,并將得到的日志寫入緩存.
(4)服務端日志解析存檔,經過日志解析程序處理,日志被解析出來,并注入消息通道.
2.1.2 頁面交互日志采集
當用戶在頁面上產生指定行為時,采集代碼與響應代碼一起觸發(fā)執(zhí)行
2.1.3 頁面日志服務器端清洗和預處理
(1)識別流量攻擊、網絡爬蟲和作弊流量
(2)數據缺項補正
(3)剔除無效數據
(4)日志隔離分發(fā),主要考慮數據安全問題.
2.2 無線客戶端日志采集
無線客戶端的日志采集采用SDK完成.
事件是無線客戶端日志行為的最小單位.
2.2.1 頁面事件
頁面事件記錄三類信息:
(1)設備及用戶的基本信息
(2)被訪問頁面信息(cur_page)
(3)訪問基本路徑(來源pre_page\enter_from)
透傳參數可以是的當前一些信息傳遞到下一個甚至下下個頁面的日志中
2.2.3 特殊場景
可在客戶端對只需要計數的一些事件做適當聚合,減少日志采集服務端請求.
2.2.4 H5&Native日志統一
為什么要統一:
(1)采用SDK可以采集到更多設備相關數據
(2)SDK會先在本地緩存,然后借機上傳,網絡狀況不佳時延遲上報
具體流程:
(1)H5頁面瀏覽、交互依然使用js腳本獲取
(2)打包日志后調用移動客戶端對應接口方法,將埋點數據對象作為參數傳入
(3)移動客戶端日志采集SDK,封裝提供接口,實現將傳入內容轉換成移動客戶端日志格式
2.3日志采集的挑戰(zhàn)
應對日志爆發(fā)式增長:盡可能靠前地不知路由差異,盡可能早地進行分流,將分類任務前置到服務端
采集與計算一體化設計
第3章 數據同步
3.1 數據同步基礎
3.1.1 直連同步
通過定義好的規(guī)范接口API和基于動態(tài)鏈接庫的方式直接連接業(yè)務庫.
3.1.2 數據文件同步
約定好文件編碼、大小、格式等,直接從源系統生成數據的文本文件.
3.1.3 數據庫日志解析同步
獲取所有的數據記錄變更.
通過數據庫日志解析進行同步的方式性能好、效率高,對業(yè)務系統影響較小,但存在一些問題:
(1)數據延遲.更新量超出系統處理峰值.
(2)投入較大.需要在源數據和目標數據庫之間部署系統實時抽取數據.
(3)數據漂移和遺漏.在業(yè)務日期數據中包含前一天活后一天凌晨附近的數據或者丟失當天變更數據.
3.2阿里數據倉庫的同步方式
3.2.2 實時數據同步
通過解析Mysql的binlog日志來實時獲得增量的數據更新,并通過消息訂閱模式來實現數據的實時同步.
3.3數據同步遇到的問題與解決方案
3.3.3 增量與全量同步的合并
傳統數據整合方案中,合并技術大多采用merge方式(update+insert)
當前流行的大數據平臺基本不支持update,現在推薦的方式是全外連接+數據全量覆蓋重新加載(insert overwrite) 性能高,保留時間較短
3.3.5 數據漂移的處理
數據漂移通常指ODS表同一個業(yè)務日期數據中包含前一天或后一天凌晨附近的數據或者丟失當天變更數據.
時間戳字段通常分四類:
(1)表中記錄數據更新時間時間戳字段
(2)日志中標識數據記錄更新時間的時間戳字段
(3)數據庫記錄業(yè)務發(fā)生時間的時間戳字段(服務端時間)
(4)標識數據記錄被抽取到時間的時間戳字段(客戶端時間)
處理方法:
(1)多獲取后一天的數據
(2)通過多個時間戳字段限制時間來獲取相對準確的數據
第5章 實時技術
5.1 簡介
數據時效性一般分為三種,離線、準實時、實時
5.2 流式技術
5.2.1 數據采集
從采集數據種類來看主要分為兩種:
(1)數據庫變更日志
(2)引擎訪問日志
5.2.2 數據處理
1.去重指標
精確去重,需要進行數據傾斜處理
模糊去重,使用去重算法,損失精度,如布隆過濾器、基數估計
2.數據傾斜
去重指標分桶,對去重值進行分桶Hash
非去重指標分桶
5.2.3 數據存儲
中間計算結果
最終結果數據
維表數據
第9章 阿里巴巴數據整合及管理體系
9.2規(guī)范定義
9.2.2 指標體系
操作細則
(1)派生指標種類
事務型指標:對業(yè)務活動進行衡量的指標
存量型指標:對實體對象某些狀態(tài)的統計
復合型指標:事務型指標和存量型指標復合出的指標
(2)復合指標舉例
比率型、比例型、變化量型、統計型、排名型
9.3 模型設計
9.3.2 模型層次
操作數據層ODS
公共維度模型層CDM-包括明細數據層DWD和匯總數據層ADS
應用數據層ADS
9.3.3 基本原則
1 高內聚低耦合
2 核心模型與擴展模型分離 比如搜索,先記錄核心數據
3 公共處理邏輯下沉及單一
4 成本與性能平衡
5 數據可回滾
6 一致性
7 命名可理解
9.4 模型實施
9.4.1 業(yè)界常用模型實施過程
Kimball模型實施過程
(1)高層模型:對業(yè)務過程中的維表和事實表的圖形描述
(2)詳細模型:為高層模型填補缺失信息
(3)模型審查、再設計和驗證
(4)提交ETL設計和開發(fā)
Inmon模型實施過程
將模型劃分為三個層次,分別是實體關系圖層(ERD層)、數據項集(DIS層)和物理層(physical model)
ERD層:業(yè)務中實體或主題域以及它們之間的關系
DIS層:描述了數據模型中的關鍵字、屬性以及細節(jié)數據之間的關系
物理層:描述了數據模型的物理特性
9.4.2 OneData實施過程
首先,進行充分的業(yè)務調研與需求分析
其次,進行數據總體架構設計,主要是對數據域對數據進行劃分
然后,構建總線矩陣、明確統計指標
再次,進行規(guī)范定義與匯總模型設計
最終,進行數據代碼開發(fā)
總線矩陣:明確每個數據域下有那些業(yè)務過程,業(yè)務過程與哪些維度相關
第10章 維度設計
10.1 維度設計基礎
10.1.1 維度基本概念
維度建模中,度量稱為事實,環(huán)境稱為維度.
維度一般作為查詢約束、分類匯總以及排序.
維度使用主鍵標識唯一性,包括代理建和自然建,代理建一般用于處理緩慢變化維,不具備業(yè)務含義;自然鍵具有業(yè)務含義.
10.1.2 維度基本設計方法
第一步:選擇維度或新建維度.保證維度唯一性
第二步:確定主維表.一般是ODS表,直接與業(yè)務系統同步.
第三步:確定相關維表.
第四步:確定維度屬性.
要點:
(1)維度盡可能豐富
(2)區(qū)分數值屬性和事實
(3)沉淀出通用的維度屬性
10.1.4 規(guī)范化和反規(guī)范化
當屬性層次被實例化為一系列維度,而不是單一維度時,被稱為雪花模式.
出于易用性和性能的考慮,維表一般是不規(guī)范的.在實際實用中,幾乎總是使用維表的空間來換取簡明性和查詢性能.
10.1.5一致性維度和交叉探查
一致性的幾種表現形式:
共享維表
一致性上卷
交叉屬性
10.2維度設計高級主題
10.2.1 維度整合
垂直整合:不同來源表包含相同數據集,只是存儲的信息不同.比如淘寶會員系統中包括會員基礎信息表、會員擴展信息表、會員等級信息表、天貓會員等級信息表.
水平整合:即不同來源表包含不同數據集,不同子集之間無交叉也可部分交叉.比如不同的會員體系進行整合,淘寶會員、支付寶會員水平整合.
10.2.2 水平整合
方案一:不同分類實例化為不同維度,同時在主維度中保存公共屬性
方案二:維護單一維度,包含所有可能屬性.
主要考慮三個原則:
擴展性,效能,易用性
10.2.3 垂直拆分
主維度與冗余信息產出時間不一致,比如商品主維度1.30產出,商標、品牌等3.產出.
類似的,搜索用戶行為數據(這不是維表)原始日志基于impr_id,不帶events,不過反作弊首先完成,然后再merge events數據,最后merge doc級別的events,通過反作弊.
10.3 維度變化
10.3.1 緩慢變化維
三種處理方式:
(1)重寫維度值.不保留歷史數據,始終取最新數據.
(2)插入新的維度行.保留歷史數據,維度值變化前的事實和過去的維度值關聯,維度變化后的事實和當前維度值關聯.
(3)添加維度列.
10.3.2 快照維表
采用快照的方式.簡單有效,理解性好.但存儲浪費大.
10.3.3 極限存儲
歷史拉鏈存儲,新增兩個時間戳字段(start_dt, end_dt)記錄維度的有效時間
阿里的極限存儲:
(1)透明化.上層做視圖操作或在Hive中hook.
(2)分月做歷史拉鏈表.
10.3.4 微型維度
使用極限存儲,需要避免維度的過度增長.
通過將一些屬性從維表中移出,放置到全新維表中解決維度過度增長的問題,微型維度將通過不穩(wěn)定的屬性從主維度中移出,并放置到新表中實現.
10.4 特殊維度
10.4.1 遞歸層次
具有父子關系的維度設計
(1)將維度扁平化
(2)設計層次橋接表(記錄關系)
10.4.2 行為維度
維度與事實相關,如交易、物流等稱之為行為維度
(1)快照事實行為維度,比如交易金額、信用分值
(2)分組事實行為維度,根據金額劃分的等級
(3)復雜邏輯事實行為維度,商品熱度(根據多種事實計算得到)
兩個原則:
(1)避免過快增長
(2)避免耦合度過高
10.4.3 多值維度
針對多值維度,主要處理方式有三種
(1)降低事實表的力度
(2)采用多字段
(3)采用通用橋接表
10.4.4 多值屬性
保持維度主鍵不變,將多值屬性放在維度的一個屬性字段中.
保持維度主鍵不變,將多值屬性放在維度多個屬性字段中.
一個維度值存放多條記錄,重復維度值.
第11章 事實表設計
11.1 事實表基礎
11.1.1 事實表特性
緊緊圍繞著業(yè)務過程來設計，通過獲取描述業(yè)務過程的度量來表達業(yè)務過程
事實表中一條記錄所表達的業(yè)務細節(jié)程度被稱為粒度。粒度可以是維度屬性組合所表示的細節(jié)程度，一種是所表示的具體業(yè)務含義。
維度也可以存儲到事實表中，這種維度被稱為退化維度。
事實表有三種類型：事務事實表、周期快照事實表、累計快照事實表
11.1.2 事實表設計原則
（1）盡可能包含所有與業(yè)務過程相關的事實
（2）只選擇與業(yè)務過程相關的事實
（3）分解不可加性事實為可加組件
（4）在選擇維度和事實前明確維度
（5）同一個事實表中不能有多重不同粒度的事實
（6）對空值進行處理
（7）使用退化維度提高事實表的易用性
11.1.1.3 事實表設計方法
第一步：選擇業(yè)務過程及確定事實表類型
第二步：聲明粒度
第三步：確定維度
第四步：確定事實
第五步：冗余維度
11.2 事務事實表
下單、支付、成功完結是三種事務
事務事實表可以是針對單個事務，也可以是針對多個事務的。
11.2.6 事實的設計準則
（1）事實完整性
（2）事實一致性
（3）事實可加性
11.3 周期快照事實表
當需要對一些狀態(tài)度量進行追蹤時，則需要聚集與之相關的事務才能進行識別計算。
11.3.1 特性
（1）用快照采樣狀態(tài)：以預定的間隔采樣狀態(tài)度量。這種間隔聯合一個或多個維度，江北用來定義快照事實表粒度，每行都將包含記錄所涉及的狀態(tài)的事實
（2）密度與稀疏性：事務事實表是稀疏的，而快照事實表是稠密的，無論是否發(fā)生事務，都會記錄一行
（3）半可加性：快照事實表在每個采樣周期內是不能對狀態(tài)度量進行匯總的。
11.3.3 注意事項
（1）事務與快照成對設計
（2）附加事實，保存上一周期狀態(tài)
（3）周期選擇
11.4 累計快照事實表
11.4.4 物理實現
（1）全量表形式。一般以日期作為分區(qū)，記錄前天全量數據與當天增量數據的融合。
（2）全量表變化形式。針對事實表數據量很大的情況
（3）以業(yè)務實體的結束時間分區(qū)。
11.7 聚集型事實表
11.7.1 聚集的基本原則
一致性。聚集表必須提供與查詢明細粒度一致的查詢結果。
避免單一表設計。不要再同一個表中存儲不同層次的聚集數據。
聚集粒度可不同。
11.7.3 阿里公共匯總層
數據公用性。
不跨數據域。
區(qū)分統計周期。
11.7.4 聚集補充說明
1.聚集是不跨越事實的
聚集是針對原始星形模型進行的匯總，橫向鉆取是針對多個事實基于一致性維度進行的分析，多采用融合事實表。
2.聚集帶來的問題
聚集會增加ETL維度的難度。當子類目對應一級類目發(fā)生變更時，先前存在的、已經被匯總到聚集表中的數據需要被重新調整。
第12章 元數據
12.1 元數據概述
元數據打通了源數據、數據倉庫、數據應用，記錄了數據從產生到消費的全過程。
元數據按用途可分為技術元數據和業(yè)務元數據。
技術元數據包括：分布式系統存儲的元數據、分布式計算系統運行的元數據、數據開發(fā)平臺中數據同步、計算任務、任務調度等信息、數據質量和運維相關元數據。
業(yè)務元數據包括：業(yè)務過程、維度屬性、指標等規(guī)范化定義；數據應用元數據
12.2 元數據應用
基于現有底層數據已經有下游使用的情況，我們可以通過下游所使用的元數據指導數據參考建模。
所使用的元數據包括：
表的基礎元數據，如下游情況、查詢次數、關聯次數、聚合次數、產出時間
表的關聯關系元數據，包括關聯關系表、關聯類型、關聯字段、關聯次數
表的字段基礎元數據，包括字段名稱、字段注釋、查詢次數、關聯次數、聚合次數、過濾次數
第13章 計算管理
13.1 系統規(guī)劃
HBO，基于歷史的優(yōu)化器。根據任務歷史執(zhí)行情況為任務分配更合理的資源，包括內存、CPU以及Instance個數。
CBO，基于代價的優(yōu)化器。優(yōu)化器有多個模塊相互組合協調工作，包括元數據、統計信息、優(yōu)化規(guī)則集、核心計劃器
13.2 任務優(yōu)化
13.2.1 Map傾斜
導致Map端長尾的兩種情況：
上游文件大小不均勻，小文件特別多。
某個值特別多，Hash過后過于集中。
解決方案：
合并小文件。
distribute by rand()將Map端分發(fā)后的數據重新按照隨機值再進行一次分發(fā)。
13.2.2 join傾斜
導致join傾斜的集中情況：
join的某路輸入比較小。
join的每路輸入都比較大，且長尾是控制導致的。
join的每路輸入都比較大，且長尾是熱點導致的。
方案：
Mapjoin
將空值處理為隨機值
將熱點key去除，對主表數據用熱點key切分成熱點數據和非熱點數據兩部分分別處理，最后合并。
13.2.3 Reduce傾斜
Reduce端負責對Map端梳理后的有序key-value鍵值對進行聚合，即進行Count、Sum、Avg等聚合操作，得到最終的聚合結果。
導致Reduce傾斜的情況：
對同一個表按照維度不同的列進行count distinct操作
Map端直接聚合時出現key值分布不均勻
動態(tài)分區(qū)數過多時造成小文件過多
多個distinct同時出現在一段sql代碼中，數據會被分發(fā)多次，也會造成數據膨脹
解決方案：
第二種情況，對熱點key進行處理
第三種情況，把符合不同條件的數據放到不同的分區(qū)，避免多次insert overwrite
第四種情況，如果出現多個需要去重的指標，那么在把不同指標join在一起之前，一定要確保指標的粒度是原始表的數據粒度。
