業務簡介
人力家是由阿里釘釘和人力窩共同投資成立，幫助客戶進入人力資源數字化，依靠產品技術創新驅動戰略的互聯網公司。公司主要提供包括人事管理、薪酬管理、社保管理、增值服務在內的人力資源SaaS服務，加速對人力資源領域賦能，實現人力資源新工作方式。目前已服務電子商務、零售服務等領域的多行業客戶。
人力家是一家典型的創業公司，目前處於一個競爭激烈的市場環境中，公司具有多產品性質，每個產品的數據具有獨立性，同時爲了配合內部CRM數據需求，更好地把數據整合，對於數倉團隊來說是一個不小的挑戰，對於數倉團隊要求的是穩，準，及時響應。需要數倉團隊既要滿足內部的數據需求，也需要在計算的成本上實現優化。
業務痛點
在使用阿里雲大數據計算服務MaxCompute過程中發現隨着存量數據增加，增量數據去重成本越來越大，具體分析發現有如下4個原因
增量數據量級少
公司雖然是多產品，但每天新增的用戶數據和歷史變化的數據量相對於歷史全量數據的量級（GB）比較下處於較小的數據量級（MB）。
歷史數據二次計算
對於增量數據去重，每天利用昨日曆史全量+今日新增數據開窗去重計算，但歷史全量數據需要更新的數據部分其實很少，每次都需要把歷史數據拉出來進行開窗去重計算，這無疑一筆比較大的計算成本。
開窗去重計算成本大
使用row_number函數開窗去重取得業務主鍵的最新數據需要把昨日曆史數據+今日數據合併計算，用戶表有億級別大小，但爲了數據去重節省存儲成本和後續的建模運算，這部分成本是偏大的，其實大部分歷史數據沒有更新，本質上是不需要再次參與運算處理，每天一次的用戶表去重單條SQL預估費用達到4.63元（按量付費）。
全量拉取成本大
如果每天全量拉取業務庫數據，數據量是億級別，但其實更新的數據量級少，對於業務端的db壓力大，嚴重影響業務端db性能。
Transaction Table2.0數據去重改進
MaxCompute新增Transaction Table2.0（下文簡稱事務表2.0)表類型在2023年6月27日開始邀測，MaxCompute支持基於事務表2.0實現近實時的增全量一體的數據存儲、計算解決方案。人力家數倉研發團隊開始第一時間瞭解其特性和功能，人力家數倉團隊發現其特性主鍵模型可以用來進行數據去重，減少開窗計算成本問題，主要實現方式如下。
- 每日增量用戶基礎信息開窗去重；
- 由於主鍵表的主鍵不能爲空，需要過濾出業務主鍵爲空的數據；
- 把每日增量數據開窗去重後的數據直接insert into 主鍵表，系統會自動進行按照業務主鍵進行去重計算。
具體改進實踐措施
整體對比
| 去重SQL執行時間(單位s） | 去重SQL預估成本(單位元） | |
| 普通表 | 151 | 4.63 |
| Transaction Table2.0 | 72 | 0.06 |
成本和計算時間對比
1、建表語句和插入更新語句
更新語句
2、成本和計算
分區表去重運行預估成本：
預估費用，不能作爲實際計費標準，僅供參考，實際費用請以賬單爲準。
主鍵表去重運行預估成本：
預估費用，不能作爲實際計費標準，僅供參考，實際費用請以賬單爲準。
分區表計算時間和資源
事務表2.0主鍵表計算時間和資源
通過上述對比，用戶表每天的計算SQL成本從4.63元下降到0.06元，計算時間縮短一半，reduce_num明顯增加，map端減少，reduce端的數據量明顯變多。
事務表2.0支持近實時增量寫入和timetravel查詢特性，在數據頻繁寫入的場景中，必然會引入大量的小文件，需要設計合理高效的合併策略來對小文件進行合併以及數據去重，解決大量小文件讀寫IO低效以及緩解存儲系統的壓力，但也要避免頻繁Compact引發嚴重的寫放大和衝突失敗。
目前主要支持兩種數據合併方式：
- Clustering：只是把Commit的DeltaFile合併成一個大文件，不改變數據內容。系統內部會根據新增的文件大小、文件數量等因素週期性地執行，不需要用戶手動操作。主要解決小文件IO讀寫效率和穩定性問題。
- Compaction：會把所有的數據文件按照一定策略進行Merge操作，生成一批新的BaseFile，相同PK的數據行只存儲最新的狀態，不包含任何歷史狀態，也不會包含任何系統列信息，因此BaseFile本身不支持timetravel操作，主要用於提升查詢效率。支持用戶根據業務場景主動觸發，也支持通過設置表屬性由系統週期性自動觸發。
綜上面對主鍵表面對增量數據時，並不會馬上對其進行小文件合併，這樣會有大量的小文件產生，小文件會佔有大量的存儲空間且不利於數據查詢速度，針對以上情況，我們可以在insert into 後增加手動合併下主鍵表的小文件或者也可通過配置表屬性按照時間頻率、Commit次數等維度自動觸發Compaction機制，或等待系統進行的Clustering合併。如果是每日的新增僅一次的數據更新，這裏更推薦使用系統的Clustering機制。
注意點：
desc extend table_name顯示出來的file_num 和 size是包含回收站數據的，目前沒辦法準確顯示，可以清空回收站數據或者Compaction 觀察日誌結尾的filenum數量。
數據時空旅行查詢和歷史數據修復
對於事務表2.0類型的表，MaxCompute支持查詢回溯到源表某個歷史時間或者版本進行歷史Snapshot查詢（TimeTravel查詢），也支持指定源表某個歷史時間區間或者版本區間進行歷史增量查詢（Incremental查詢）, 需要設置acid.data.retain.hours纔可以使用TimeTravel查詢和Incremental查詢。
數據時空旅行查詢
1、基於TimeTravel 查詢截止到指定時間（例如datetime格式的字符串常量）的所有歷史數據（需要設置）
select * from mf_tt2 timestamp as of '2023-06-26 09:33:00' where dd='01' and hh='01';
查詢歷史數據和版本號
show history for table mf_tt2 partition(dd='01',hh='01');
查詢截止到指定version常量的所有歷史數據
select * from mf_tt2 version as of 2 where dd='01' and hh='01';
2、基於Incremental 查詢指定時間（例如datetime格式的字符串常量）區間的歷史增量數據，常量值需要根據具體操作的時間來配置
select * from mf_tt2 timestamp between '2023-06-26 09:31:40' and '2023-06-26 09:32:00' where dd= '01' and hh='01';
查詢指定version區間的歷史增量數據
select * from mf_tt2 version between 2 and 3 where dd ='01' and hh = '01';
數據修復
基於TimeTravel 查詢截止到指定時間的全量數據直接insert into 一張臨時表，清空當前事務表2.0主鍵表數據，把臨時表數據insert into當前事務表2.0主鍵表。
注意事項及未來規劃
動態硬刪數據
對於歷史數據沒辦法硬刪除（這部分需要依賴flink-cdc），目前可以通過軟刪實現，或者通過一段時間的歷史數據積累，拿出所有歷史數據進行過濾重新整體插入主鍵表；這裏提一點就是flink-cdc+flink-sql支持delete實時硬刪數據，但是單表的flink-cdc任務比較重，多個表需要不同的server-id，對於業務系統源頭斷的db壓力大，不是很推薦，期待後續的cdas整庫同步。
存儲空間增加
事務表2.0主鍵模型數據存儲空間相比於分區表開窗後的數據佔有的存儲空間大一點，主要是開窗後的數據分佈更均勻，數據壓縮比更大，但是相對於sql每次的每天一次的計算成本，存儲空間所佔有的每日費用處於較低的費用級（可忽略）。
flink-cdc
配合flink-cdc直接可以直接實現準實時數據同步，提高數據新鮮度。
整庫同步
期待阿里雲實時計算Flink的cdas語法目標端整合MaxCompute端做到整庫同步和ddl變更。
物化視圖
利用物化視圖+flink-cdc組合方式可以做到
作者：石玉陽 人力家 高級數據研發工程師
點擊立即免費試用雲產品 開啓雲上實踐之旅！
本文爲阿里雲原創內容，未經允許不得轉載。