展會(huì)信息港展會(huì)大全

【深入MaxCompute】人力家:用MaxCompute 事務(wù)表2.0主鍵模型去重?cái)?shù)據(jù)持續(xù)降本增效
來(lái)源:互聯(lián)網(wǎng)   發(fā)布日期:2023-08-30 13:57:37   瀏覽:18433次  

導(dǎo)讀:簡(jiǎn)介: MaxCompute新增Transaction Table2.0(下文簡(jiǎn)稱事務(wù)表2.0)表類型在2023年6月27日開(kāi)始邀測(cè),支持基于事務(wù)表2.0實(shí)現(xiàn)近實(shí)時(shí)的增全量一體的數(shù)據(jù)存儲(chǔ)、計(jì)算解決方案。 作者: 石玉陽(yáng) 人力家 高級(jí)數(shù)據(jù)研發(fā)工程師 業(yè)務(wù)簡(jiǎn)介 人力家是由阿里釘釘和人力窩共同投...

簡(jiǎn)介:MaxCompute新增Transaction Table2.0(下文簡(jiǎn)稱事務(wù)表2.0)表類型在2023年6月27日開(kāi)始邀測(cè),支持基于事務(wù)表2.0實(shí)現(xiàn)近實(shí)時(shí)的增全量一體的數(shù)據(jù)存儲(chǔ)、計(jì)算解決方案。

作者:石玉陽(yáng)人力家高級(jí)數(shù)據(jù)研發(fā)工程師

業(yè)務(wù)簡(jiǎn)介

人力家是由阿里釘釘和人力窩共同投資成立,幫助客戶進(jìn)入人力資源數(shù)字化,依靠產(chǎn)品技術(shù)創(chuàng)新驅(qū)動(dòng)戰(zhàn)略的互聯(lián)網(wǎng)公司。公司主要提供包括人事管理、薪酬管理、社保管理、增值服務(wù)在內(nèi)的人力資源SaaS服務(wù),加速對(duì)人力資源領(lǐng)域賦能,實(shí)現(xiàn)人力資源新工作方式。目前已服務(wù)電子商務(wù)、零售服務(wù)等領(lǐng)域的多行業(yè)客戶。

人力家是一家典型的創(chuàng)業(yè)公司,目前處于一個(gè)競(jìng)爭(zhēng)激烈的市場(chǎng)環(huán)境中,公司具有多產(chǎn)品性質(zhì),每個(gè)產(chǎn)品的數(shù)據(jù)具有獨(dú)立性,同時(shí)為了配合內(nèi)部CRM數(shù)據(jù)需求,更好地把數(shù)據(jù)整合,對(duì)于數(shù)倉(cāng)團(tuán)隊(duì)來(lái)說(shuō)是一個(gè)不小的挑戰(zhàn),對(duì)于數(shù)倉(cāng)團(tuán)隊(duì)要求的是穩(wěn),準(zhǔn),及時(shí)響應(yīng)。需要數(shù)倉(cāng)團(tuán)隊(duì)既要滿足內(nèi)部的數(shù)據(jù)需求,也需要在計(jì)算的成本上實(shí)現(xiàn)優(yōu)化。

業(yè)務(wù)痛點(diǎn)

在使用阿里云大數(shù)據(jù)計(jì)算服務(wù)MaxCompute過(guò)程中發(fā)現(xiàn)隨著存量數(shù)據(jù)增加,增量數(shù)據(jù)去重成本越來(lái)越大,具體分析發(fā)現(xiàn)有如下4個(gè)原因

 增量數(shù)據(jù)量級(jí)少

公司雖然是多產(chǎn)品,但每天新增的用戶數(shù)據(jù)和歷史變化的數(shù)據(jù)量相對(duì)于歷史全量數(shù)據(jù)的量級(jí)(GB)比較下處于較小的數(shù)據(jù)量級(jí)(MB)。

 歷史數(shù)據(jù)二次計(jì)算

對(duì)于增量數(shù)據(jù)去重,每天利用昨日歷史全量+今日新增數(shù)據(jù)開(kāi)窗去重計(jì)算,但歷史全量數(shù)據(jù)需要更新的數(shù)據(jù)部分其實(shí)很少,每次都需要把歷史數(shù)據(jù)拉出來(lái)進(jìn)行開(kāi)窗去重計(jì)算,這無(wú)疑一筆比較大的計(jì)算成本。

 開(kāi)窗去重計(jì)算成本大

使用row_number函數(shù)開(kāi)窗去重取得業(yè)務(wù)主鍵的最新數(shù)據(jù)需要把昨日歷史數(shù)據(jù)+今日數(shù)據(jù)合并計(jì)算,用戶表有億級(jí)別大小,但為了數(shù)據(jù)去重節(jié)省存儲(chǔ)成本和后續(xù)的建模運(yùn)算,這部分成本是偏大的,其實(shí)大部分歷史數(shù)據(jù)沒(méi)有更新,本質(zhì)上是不需要再次參與運(yùn)算處理,每天一次的用戶表去重單條SQL預(yù)估費(fèi)用達(dá)到4.63元(按量付費(fèi))。

 全量拉取成本大

如果每天全量拉取業(yè)務(wù)庫(kù)數(shù)據(jù),數(shù)據(jù)量是億級(jí)別,但其實(shí)更新的數(shù)據(jù)量級(jí)少,對(duì)于業(yè)務(wù)端的db壓力大,嚴(yán)重影響業(yè)務(wù)端db性能。

 Transaction Table2.0數(shù)據(jù)去重改進(jìn)

MaxCompute新增Transaction Table2.0(下文簡(jiǎn)稱事務(wù)表2.0)表類型在2023年6月27日開(kāi)始邀測(cè),MaxCompute支持基于事務(wù)表2.0實(shí)現(xiàn)近實(shí)時(shí)的增全量一體的數(shù)據(jù)存儲(chǔ)、計(jì)算解決方案。人力家數(shù)倉(cāng)研發(fā)團(tuán)隊(duì)開(kāi)始第一時(shí)間了解其特性和功能,人力家數(shù)倉(cāng)團(tuán)隊(duì)發(fā)現(xiàn)其特性主鍵模型可以用來(lái)進(jìn)行數(shù)據(jù)去重,減少開(kāi)窗計(jì)算成本問(wèn)題,主要實(shí)現(xiàn)方式如下。

每日增量用戶基礎(chǔ)信息開(kāi)窗去重;由于主鍵表的主鍵不能為空,需要過(guò)濾出業(yè)務(wù)主鍵為空的數(shù)據(jù);把每日增量數(shù)據(jù)開(kāi)窗去重后的數(shù)據(jù)直接insert into 主鍵表,系統(tǒng)會(huì)自動(dòng)進(jìn)行按照業(yè)務(wù)主鍵進(jìn)行去重計(jì)算。

 具體改進(jìn)實(shí)踐措施

整體對(duì)比

 

去重SQL執(zhí)行時(shí)間(單位s)

去重SQL預(yù)估成本(單位元)

普通表

151

4.63

Transaction Table2.0

72

0.06

成本和計(jì)算時(shí)間對(duì)比

1、建表語(yǔ)句和插入更新語(yǔ)句

更新語(yǔ)句

2、成本和計(jì)算

分區(qū)表去重運(yùn)行預(yù)估成本:

預(yù)估費(fèi)用,不能作為實(shí)際計(jì)費(fèi)標(biāo)準(zhǔn),僅供參考,實(shí)際費(fèi)用請(qǐng)以賬單為準(zhǔn)。

主鍵表去重運(yùn)行預(yù)估成本:

預(yù)估費(fèi)用,不能作為實(shí)際計(jì)費(fèi)標(biāo)準(zhǔn),僅供參考,實(shí)際費(fèi)用請(qǐng)以賬單為準(zhǔn)。

分區(qū)表計(jì)算時(shí)間和資源

事務(wù)表2.0主鍵表計(jì)算時(shí)間和資源

通過(guò)上述對(duì)比,用戶表每天的計(jì)算SQL成本從4.63元下降到0.06元,計(jì)算時(shí)間縮短一半,reduce_num明顯增加,map端減少,reduce端的數(shù)據(jù)量明顯變多。

 合并小文件

事務(wù)表2.0支持近實(shí)時(shí)增量寫(xiě)入和timetravel查詢特性,在數(shù)據(jù)頻繁寫(xiě)入的場(chǎng)景中,必然會(huì)引入大量的小文件,需要設(shè)計(jì)合理高效的合并策略來(lái)對(duì)小文件進(jìn)行合并以及數(shù)據(jù)去重,解決大量小文件讀寫(xiě)IO低效以及緩解存儲(chǔ)系統(tǒng)的壓力,但也要避免頻繁Compact引發(fā)嚴(yán)重的寫(xiě)放大和沖突失敗。

目前主要支持兩種數(shù)據(jù)合并方式:

Clustering:只是把Commit的DeltaFile合并成一個(gè)大文件,不改變數(shù)據(jù)內(nèi)容。系統(tǒng)內(nèi)部會(huì)根據(jù)新增的文件大孝文件數(shù)量等因素周期性地執(zhí)行,不需要用戶手動(dòng)操作。主要解決小文件IO讀寫(xiě)效率和穩(wěn)定性問(wèn)題。

Compaction:會(huì)把所有的數(shù)據(jù)文件按照一定策略進(jìn)行Merge操作,生成一批新的BaseFile,相同PK的數(shù)據(jù)行只存儲(chǔ)最新的狀態(tài),不包含任何歷史狀態(tài),也不會(huì)包含任何系統(tǒng)列信息,因此BaseFile本身不支持timetravel操作,主要用于提升查詢效率。支持用戶根據(jù)業(yè)務(wù)場(chǎng)景主動(dòng)觸發(fā),也支持通過(guò)設(shè)置表屬性由系統(tǒng)周期性自動(dòng)觸發(fā)。

綜上面對(duì)主鍵表面對(duì)增量數(shù)據(jù)時(shí),并不會(huì)馬上對(duì)其進(jìn)行小文件合并,這樣會(huì)有大量的小文件產(chǎn)生,小文件會(huì)占有大量的存儲(chǔ)空間且不利于數(shù)據(jù)查詢速度,針對(duì)以上情況,我們可以在insert into 后增加手動(dòng)合并下主鍵表的小文件或者也可通過(guò)配置表屬性按照時(shí)間頻率、Commit次數(shù)等維度自動(dòng)觸發(fā)Compaction機(jī)制,或等待系統(tǒng)進(jìn)行的Clustering合并。如果是每日的新增僅一次的數(shù)據(jù)更新,這里更推薦使用系統(tǒng)的Clustering機(jī)制。

注意點(diǎn):

desc extend table_name顯示出來(lái)的file_num 和 size是包含回收站數(shù)據(jù)的,目前沒(méi)辦法準(zhǔn)確顯示,可以清空回收站數(shù)據(jù)或者Compaction 觀察日志結(jié)尾的filenum數(shù)量。

 數(shù)據(jù)時(shí)空旅行查詢和歷史數(shù)據(jù)修復(fù)

對(duì)于事務(wù)表2.0類型的表,MaxCompute支持查詢回溯到源表某個(gè)歷史時(shí)間或者版本進(jìn)行歷史Snapshot查詢(TimeTravel查詢),也支持指定源表某個(gè)歷史時(shí)間區(qū)間或者版本區(qū)間進(jìn)行歷史增量查詢(Incremental查詢), 需要設(shè)置acid.data.retain.hours才可以使用TimeTravel查詢和Incremental查詢。

數(shù)據(jù)時(shí)空旅行查詢

1、基于TimeTravel 查詢截止到指定時(shí)間(例如datetime格式的字符串常量)的所有歷史數(shù)據(jù)(需要設(shè)置)

select * from mf_tt2 timestamp as of '2023-06-26 09:33:00' where dd='01' and hh='01';

查詢歷史數(shù)據(jù)和版本號(hào)

show history for table mf_tt2 partition(dd='01',hh='01');

查詢截止到指定version常量的所有歷史數(shù)據(jù)

select * from mf_tt2 version as of 2 where dd='01' and hh='01';

2、基于Incremental 查詢指定時(shí)間(例如datetime格式的字符串常量)區(qū)間的歷史增量數(shù)據(jù),常量值需要根據(jù)具體操作的時(shí)間來(lái)配置

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區(qū)間的歷史增量數(shù)據(jù)

select * from mf_tt2 version between 2 and 3 where dd ='01' and hh = '01';

數(shù)據(jù)修復(fù)

基于TimeTravel 查詢截止到指定時(shí)間的全量數(shù)據(jù)直接insert into 一張臨時(shí)表,清空當(dāng)前事務(wù)表2.0主鍵表數(shù)據(jù),把臨時(shí)表數(shù)據(jù)insert into當(dāng)前事務(wù)表2.0主鍵表。

注意事項(xiàng)及未來(lái)規(guī)劃

動(dòng)態(tài)硬刪數(shù)據(jù)

對(duì)于歷史數(shù)據(jù)沒(méi)辦法硬刪除(這部分需要依賴flink-cdc),目前可以通過(guò)軟刪實(shí)現(xiàn),或者通過(guò)一段時(shí)間的歷史數(shù)據(jù)積累,拿出所有歷史數(shù)據(jù)進(jìn)行過(guò)濾重新整體插入主鍵表;這里提一點(diǎn)就是flink-cdc+flink-sql支持delete實(shí)時(shí)硬刪數(shù)據(jù),但是單表的flink-cdc任務(wù)比較重,多個(gè)表需要不同的server-id,對(duì)于業(yè)務(wù)系統(tǒng)源頭斷的db壓力大,不是很推薦,期待后續(xù)的cdas整庫(kù)同步。

存儲(chǔ)空間增加

事務(wù)表2.0主鍵模型數(shù)據(jù)存儲(chǔ)空間相比于分區(qū)表開(kāi)窗后的數(shù)據(jù)占有的存儲(chǔ)空間大一點(diǎn),主要是開(kāi)窗后的數(shù)據(jù)分布更均勻,數(shù)據(jù)壓縮比更大,但是相對(duì)于sql每次的每天一次的計(jì)算成本,存儲(chǔ)空間所占有的每日費(fèi)用處于較低的費(fèi)用級(jí)(可忽略)。

flink-cdc

配合flink-cdc直接可以直接實(shí)現(xiàn)準(zhǔn)實(shí)時(shí)數(shù)據(jù)同步,提高數(shù)據(jù)新鮮度。

整庫(kù)同步

期待阿里云實(shí)時(shí)計(jì)算Flink的cdas語(yǔ)法目標(biāo)端整合MaxCompute端做到整庫(kù)同步和ddl變更。

物化視圖

利用物化視圖+flink-cdc組合方式可以做到

 

贊助本站

人工智能實(shí)驗(yàn)室
相關(guān)內(nèi)容
AiLab云推薦
推薦內(nèi)容
展開(kāi)

熱門(mén)欄目HotCates

Copyright © 2010-2024 AiLab Team. 人工智能實(shí)驗(yàn)室 版權(quán)所有    關(guān)于我們 | 聯(lián)系我們 | 廣告服務(wù) | 公司動(dòng)態(tài) | 免責(zé)聲明 | 隱私條款 | 工作機(jī)會(huì) | 展會(huì)港