建站
咨詢
售后
建站咨詢
新聞中心
1、背景
在數(shù)倉分層架構(gòu)體系中，從 ODS層到 DWD層數(shù)據(jù)轉(zhuǎn)換需要進(jìn)行數(shù)據(jù)清洗、脫敏、列式壓縮等步驟。在B站用戶行為埋點(diǎn)數(shù)據(jù) ODS到 DWD層轉(zhuǎn)換過程中，為了解決日增千億條、20+TB/天增量規(guī)模下數(shù)據(jù)重復(fù)攝取帶來的資源嚴(yán)重消耗的問題，引入了北極星（B站用戶埋點(diǎn)行為分析鏈路）分流，按照部門進(jìn)行分表。在埋點(diǎn)設(shè)計(jì)中使用spmid模型，將事件類型拆分為瀏覽 pv、曝光 show、點(diǎn)擊 click等多個(gè)事件類型，并以這些事件類型作為除天、小時(shí)分區(qū)以外的第三級(jí)分區(qū)，再以事件類型產(chǎn)品來源作為四級(jí)分區(qū)。通過基于部門業(yè)務(wù)區(qū)分按照埋點(diǎn)事件類型+產(chǎn)品來源以多表多分區(qū)控制的形式，最大程度降低下游任務(wù)文件數(shù)據(jù)攝取數(shù)量以減少資源消耗。
成都創(chuàng)新互聯(lián)公司是專業(yè)的神池網(wǎng)站建設(shè)公司，神池接單;提供網(wǎng)站制作、網(wǎng)站設(shè)計(jì),網(wǎng)頁設(shè)計(jì),網(wǎng)站設(shè)計(jì),建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行神池網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊(duì),希望更多企業(yè)前來合作!
如圖所示，用戶埋點(diǎn)由邊緣上報(bào) bfe-agent到網(wǎng)關(guān) gateway，經(jīng)過kafka數(shù)據(jù)緩沖后通過 lancer collector數(shù)據(jù)分發(fā)至 ods hive，再通過北極星分流完成 ODS到 DWD層數(shù)據(jù)轉(zhuǎn)換。DWD層數(shù)據(jù)服務(wù)于搜索推薦、推薦、廣告、AI等應(yīng)用場(chǎng)景。在原有 ODS到 DWD數(shù)據(jù)轉(zhuǎn)換中使用Spark離線分流方案。
2、Spark離線分流方案
Spark小時(shí)任務(wù)定期調(diào)起 ETL任務(wù)完成 DWD分流、數(shù)據(jù)同步，由于在讀 ods時(shí)由于源表數(shù)據(jù)量過大造成 Spark緩存 miss，繼續(xù)分流需要重新讀全表數(shù)據(jù)存在讀放大問題造成文件重復(fù)攝取。
離線分流讀放大問題
隨著各部門中心業(yè)務(wù)的擴(kuò)展，分流表日益增加，而在使用離線Spark sql分流過程中由于多表寫入會(huì)重復(fù)讀取源表數(shù)據(jù)，而源表的數(shù)據(jù)規(guī)模過大造成緩存失效，從而重復(fù)攝取源表數(shù)據(jù)的讀放大問題日漸顯現(xiàn)。
分流任務(wù)資源消耗高
ODS-DWD同步資源消耗因重復(fù)攝取 ODS源表文件跟隨分流表擴(kuò)展持續(xù)增加，部分資源使用不合理。
DWD同步時(shí)效性低
在分區(qū)通知調(diào)度模式下，DWD層數(shù)據(jù)只會(huì)在ODS表分區(qū)通知才會(huì)進(jìn)行同步，為了保證 DWD表的及時(shí)產(chǎn)出需大量資源滿足同步需要。在高峰期資源使用出現(xiàn)堆積時(shí) ods-dwd同步容易超過1h+。
為了解決這些問題，我們引入新的解決方案--基于Flink的實(shí)時(shí)增量計(jì)算。
3、Flink實(shí)時(shí)增量計(jì)算
如下圖所示，實(shí)時(shí)北極星增量計(jì)算方案由 Flink HDFS File Source通過掃描 Lancer任務(wù)每次 checkpoint產(chǎn)出的可見文件進(jìn)行增量消費(fèi)計(jì)算，與維表數(shù)據(jù)join之后打?qū)?，分發(fā)至 Flink Multi Hive Sink，在這里完成多表多分區(qū)分流，sink內(nèi)部集成 Archer（B站大數(shù)據(jù)任務(wù)調(diào)度系統(tǒng)）調(diào)度下游搜索、推薦、廣告等數(shù)據(jù)分析業(yè)務(wù)。由于 Main表文件數(shù)量在實(shí)時(shí)分區(qū)寫入場(chǎng)景下文件數(shù)依然過高，因此在sink表之后對(duì)Main表單獨(dú)添加基于Spark的小文件合并。
增量計(jì)算方案預(yù)期收益主要包含：
- 讀放大問題解決
Flink DAG支持 Source數(shù)據(jù)下發(fā)之后可自定義分區(qū)輸出無需重復(fù)攝取，用以解決讀放大問題。
- 分流資源降低
在解決讀放大問題后，源表數(shù)據(jù)攝取只會(huì)執(zhí)行一次，降低資源消耗。另外在 ODS產(chǎn)生一批可見文件即進(jìn)行計(jì)算，最大程度降低分流任務(wù)同步資源消耗。
- 時(shí)效性提升
時(shí)效性由小時(shí)級(jí)最高可提高至分鐘級(jí)，增量計(jì)算即在 ODS產(chǎn)生一批文件之后就會(huì)對(duì)文件進(jìn)行消費(fèi)，理論最高可在 ODS分區(qū)歸檔之后的一次 Checkpoint間隔即可完成 DWD表數(shù)據(jù)完全同步。
4、多級(jí)分區(qū)小文件解決方案
實(shí)時(shí)分流在解決以上幾個(gè)問題同時(shí)，在灰度上線過程中發(fā)現(xiàn)文件數(shù)量相比離線分流方案增長(zhǎng)超100倍，下游Spark分析任務(wù)在讀取實(shí)時(shí)分流表加載文件時(shí)由于文件讀放大問題導(dǎo)致內(nèi)存不足執(zhí)行失敗。于是解決小文件問題將成為該方案最終落地是否成功的關(guān)鍵。由于實(shí)時(shí)分流在每5min一次 Checkpoint執(zhí)行文件斬?cái)鄷?huì)產(chǎn)生大量小文件，導(dǎo)致ns讀寫壓力變大，下游Spark在讀取目錄過程中也增加資源消耗導(dǎo)致任務(wù)執(zhí)行超時(shí)。在分析了落地文件后發(fā)現(xiàn)很多小文件是由于四級(jí)分區(qū)并發(fā)度分配不合理導(dǎo)致 bucket的數(shù)量增加從而產(chǎn)生大量的小文件。因此通過在保證計(jì)算能力下盡力減少 bucket數(shù)量則可以降低打開的文件數(shù)量。
4.1 基于 Flink Partitioner Shuffle優(yōu)化
在270+四級(jí)分區(qū)下，按照全并發(fā)分配模式，每天將產(chǎn)生約1億4千萬文件數(shù)。通過使用 Flink Partitioner，對(duì)于 Reader下發(fā)的數(shù)據(jù)按照所屬四級(jí)分區(qū)進(jìn)行加簽（tag），根據(jù)每個(gè) tag對(duì)應(yīng)歷史分區(qū)落地?cái)?shù)據(jù)大小比例配比計(jì)算subtask分配區(qū)間，在分配區(qū)間內(nèi)隨機(jī)分發(fā)至某個(gè) subtask，文件數(shù)量由原來一億四千萬/天降為150w/天。文件數(shù)縮減100+倍。
優(yōu)化前
270 (四級(jí)分區(qū)) * 1800 (并發(fā)度) * 12 (每小時(shí)文件斬?cái)啻螖?shù)) * 24 (每天小時(shí)數(shù)) = 139968000 (約14000w)。
優(yōu)化后
5000 (Shuffle數(shù)量) * 12(每小時(shí)文件斬?cái)啻螖?shù)) * 24 (每天小時(shí)數(shù)) = 1440000（150w） 。
如上圖所示，可能存在大量 partition僅需一個(gè) bucket分桶即可完成文件落地，不需要所有Bucket處理。因此按照 partition所需 bucket數(shù)量進(jìn)行合理分配是解決問題的關(guān)鍵。
但是這里有個(gè)弊端，在出現(xiàn)流量激增場(chǎng)景下，該方案可能會(huì)導(dǎo)致部分subtask熱點(diǎn)從而導(dǎo)致任務(wù)出現(xiàn)嚴(yán)重堆積（如佩洛西事件，導(dǎo)致部分subtask流量超過平時(shí)12+倍），需要手動(dòng)調(diào)整 shuffle方案以消除熱點(diǎn)。這樣導(dǎo)致運(yùn)維成本較高，并且用戶在使用該方案時(shí)門檻較高，需要長(zhǎng)時(shí)間的壓測(cè)調(diào)試才能將多分區(qū)之間的比例調(diào)整均勻。如果能夠?qū)?shí)時(shí)作業(yè)處理能力與文件數(shù)量之間根據(jù)流量自動(dòng)平衡，這樣運(yùn)維成本可以降低另外用戶在使用時(shí)無門檻，只需配置開關(guān)即可。因此提出 Auto Shuffle推測(cè)執(zhí)行以解決小文件合并問題。
4.2 Auto Shuffle推測(cè)執(zhí)行小文件解決方案
1、支持自定義分桶 Tag規(guī)則
根據(jù) row的字段來確認(rèn)分桶的規(guī)則，支持根據(jù)udf自定義。
2、計(jì)算 row的大小
直接按照 row字節(jié)數(shù)大小計(jì)算，即為row的壓縮前大小。
3、滾動(dòng)窗口+類背包算法+統(tǒng)一字典排序
滾動(dòng)窗口
以環(huán)形數(shù)組的形式記錄配額，配額在分配后，各個(gè) subtask對(duì)桶內(nèi)的更新相互間未知的，很容易造成單桶超過8g，現(xiàn)在想到的解決辦法是通過8G/一個(gè)小時(shí)內(nèi)滾動(dòng)時(shí)間窗口的次數(shù)/并發(fā)度來調(diào)整。
統(tǒng)一字典排序
主要目標(biāo)是為了合并背包算法結(jié)果，盡可能將不同 subtask相同tag分發(fā)到相同的桶里(由于tag分發(fā)排序不穩(wěn)定)。上線選擇使用 tag hashcode排序，減少計(jì)算量。
加簽背包算法
類似Flink1.12小文件合并采用的BinPack策略，在此基礎(chǔ)上添加Tag識(shí)別，每個(gè)分桶歸屬于單個(gè)Tag。注意在使用以上基于weight加簽背包的計(jì)算結(jié)果 shuffle時(shí)，容易受到作業(yè)反壓的影響從而導(dǎo)致上圖 shuffle operator接收到的數(shù)據(jù)變少，由于JM無法區(qū)分流量降低和反壓影響，因此會(huì)根據(jù) weight主動(dòng)降低 subtask配額，這樣會(huì)導(dǎo)致shuffle算子后續(xù)算子處理能力下降，繼而增加反壓陷入惡性循環(huán)，在測(cè)試過程中效果表現(xiàn)不佳。后續(xù)在參考根據(jù)各四級(jí)分區(qū)落地文件大小預(yù)設(shè)比例的思想，取消主動(dòng)降低 subtask配額的操作，按照上游分發(fā)的大小按比例分配subtask，效果表現(xiàn)良好，但文件數(shù)量會(huì)略高于預(yù)設(shè)比例（比例調(diào)整會(huì)導(dǎo)致文件數(shù)量增加）。
4、維護(hù)比例模型狀態(tài)
在堆積恢復(fù)時(shí)按照重啟前最后一次生成的比例模型來計(jì)算 subtask分發(fā)，減少因啟動(dòng)造成文件數(shù)膨脹問題(486000單次checkpoint增量)。
5、冷啟動(dòng)問題解決
由于冷啟動(dòng)時(shí)，沒有流量參考，為了降低文件數(shù)只能通過計(jì)算tag占用方式分發(fā)subtask，這樣的累加操作為O(n)，在初始化時(shí)cpu壓力較大，吞吐不達(dá)預(yù)期。因此支持UDF預(yù)設(shè)置tag規(guī)則以及比例，按照該比例進(jìn)行預(yù)分發(fā)，在第一次窗口計(jì)算前按照預(yù)設(shè)比例進(jìn)行O(1)分發(fā)。
5、Flink增量計(jì)算方案落地
在落地過程中，我們面臨很多問題和挑戰(zhàn)，尤其是在降本增效的大背景下，對(duì)于新方案落地提出了高要求。首先面臨的是在資源緊缺情況下如何適應(yīng)相對(duì)物理機(jī)集群而言環(huán)境較為惡劣的混部集群。在混部環(huán)境下需要實(shí)時(shí)任務(wù)做到以下幾點(diǎn)：
- （事前）分流任務(wù)穩(wěn)定性提升
- （事中）分流任務(wù)需快速恢復(fù)，即 Fast-FailOver
- （事后）分流任務(wù)頻繁重啟下不影響數(shù)據(jù)質(zhì)量
基于這樣的要求，在實(shí)時(shí)分流任務(wù)中在 Flink Runtime\SQL\Connector以及實(shí)時(shí)平臺(tái)層應(yīng)用很多功能優(yōu)化以滿足要求。
5.1 分流任務(wù)穩(wěn)定性提升
首先影響任務(wù)穩(wěn)定的主要有以下幾點(diǎn)：
- JobManager穩(wěn)定性問題
- Subtask間負(fù)載均衡
- Subtask熱點(diǎn)傾斜
解決方案：
5.1.1 JobManager穩(wěn)定性問題解決
- Metrics Disabled
我們?cè)诓檎?JobManager掛的RC過程中，發(fā)現(xiàn)經(jīng)常由于 JobManager OOM導(dǎo)致任務(wù)重啟，尤其在打開原生監(jiān)控時(shí)經(jīng)常出現(xiàn)。在 Dump內(nèi)存進(jìn)行分析后發(fā)現(xiàn)，Jobmanager內(nèi)存80%以上存儲(chǔ)的是各個(gè) TM上報(bào)的 Metrics，由于打開原生監(jiān)控會(huì)主動(dòng) pull額外的Metrics從而加重內(nèi)存壓力導(dǎo)致 OOM。因此實(shí)現(xiàn) Metrics Disabled關(guān)閉部分Metrics對(duì)JM上報(bào)，問題解決。
- JobManager HA
在混部環(huán)境下 JobManger常會(huì)因所在 Container被驅(qū)逐而導(dǎo)致Jobmanager掛掉。因此通過開啟JM HA在JobManger掛掉的過程中，保持TM運(yùn)行狀態(tài)，并重連JobMaster，取消社區(qū)JM心跳超時(shí)就Cancel Task的行為以保證任務(wù)持續(xù)穩(wěn)定運(yùn)行。
5.1.2 Subtask間負(fù)載均衡
- 基于backlog負(fù)載均衡
非hash shuffle場(chǎng)景下，F(xiàn)link默認(rèn)提供了rebalance或rescale partitioner用于在下游算子的不同并行度間均勻地分發(fā)數(shù)據(jù)（round-robin方式）。在環(huán)境問題（例如機(jī)器異構(gòu)等）導(dǎo)致下游算子的不同并行度之間處理能力不均衡時(shí)，會(huì)導(dǎo)致部分subtask數(shù)據(jù)堆積，造成反壓。為此，我們引入了下游subtask之間的負(fù)載均衡機(jī)制，并默認(rèn)提供了基于backlog進(jìn)行負(fù)載均衡的實(shí)現(xiàn)。通過運(yùn)用該負(fù)載均衡機(jī)制，可以使得數(shù)據(jù)根據(jù)下游subtask的處理能力進(jìn)行分發(fā)，減少環(huán)境問題導(dǎo)致的反壓等問題。
5.1.3 Subtask傾斜問題解決
- Reader File Split負(fù)載均衡
File Split在 Round Robin分發(fā)時(shí)，由于split大小不同以及機(jī)器異構(gòu)等原因，造成部分subtask處理split速度變慢導(dǎo)致熱點(diǎn)堆積。通過JobManager維護(hù)Reader算子運(yùn)行狀態(tài)，在Monitor異步線程分發(fā)時(shí)根據(jù)各reader算子是否空閑來分配split，以類似生產(chǎn)者-消費(fèi)者模式實(shí)現(xiàn)Reader算子對(duì)于File split處理負(fù)載均衡。
5.2 分流任務(wù)快速恢復(fù)
由于實(shí)時(shí)分流任務(wù)以較小資源流式增量消費(fèi)，在北極星較大流量場(chǎng)景下任務(wù)在重啟的幾分鐘內(nèi)會(huì)造成嚴(yán)重堆積，另外在重啟過程中可能出現(xiàn)資源搶占造成實(shí)時(shí)任務(wù)無法及時(shí)恢復(fù)，因此需要實(shí)時(shí)分流任務(wù)具備快速恢復(fù)的能力。主要從以下幾點(diǎn)出發(fā)，增加恢復(fù)速度
- Checkpoint快速恢復(fù)
- 維表Join支持FailOver
- Yarn調(diào)度資源搶占解決
5.2.1 Checkpoint快速恢復(fù)
- Regional Checkpoint
北極星分流場(chǎng)景下Flink作業(yè)的并行度非常大，非常容易因?yàn)榄h(huán)境波動(dòng)等原因?qū)е虏糠謘ubtask的checkpoint失敗。默認(rèn)配置下，這會(huì)導(dǎo)致作業(yè)的checkpoint失敗，從而導(dǎo)致在作業(yè)恢復(fù)時(shí)需要重放大量的數(shù)據(jù)，造成不必要的資源浪費(fèi)。通過引入regional checkpoint，可以做到在部分subtask的checkpoint失敗時(shí)，作業(yè)的checkpoint仍然可以成功。配合Flink社區(qū)提供的region failover的功能，可以極大地提高作業(yè)在部分subtask失敗時(shí)從checkpoint恢復(fù)的速度。
配置參數(shù)：execution.checkpointing.regional.enabled=true，execution.checkpointing.regional.max-tolerable-consecutive-failures-or-expiratinotallow=3，execution.checkpointing.regional.max-tolerable-failure-or-expiration-ratio=1，execution.checkpointing.tolerable-failed-checkpoints=3
5.2.2 維表Join支持FailOver
- ShutDown Hook Failover
在北極星分流場(chǎng)景下，使用 HDFS維表 Left Join。HDFS維表加載過程是定期將 HDFS文件反序列化并以 KV形式放入內(nèi)存和 RocksDB中，緩存級(jí)別為 TM級(jí)。一旦出現(xiàn) slot通信失敗將 shutdown整個(gè) TM，緩存需重新加載。通過 JDK1.0提供的 ShutDown Hook在 slot失敗時(shí)單獨(dú)清理 Slot對(duì)象，保留 TM級(jí)別緩存，支持 Region FailOver在 slot單獨(dú)恢復(fù)時(shí)提高恢復(fù)速度。
5.2.3 Yarn調(diào)度資源搶占
- Session提交
在集群資源緊張的情況下，任務(wù)重啟時(shí)會(huì)發(fā)生由于資源被Pending任務(wù)搶占而無法啟動(dòng)的問題。這會(huì)導(dǎo)致高優(yōu)任務(wù)的資源需求無法滿足，時(shí)常需要人工介入處理。通過Session提交方式，在任務(wù)漂移時(shí)保留占用的資源不釋放，保證任務(wù) FailOver成功。
5.3 分流任務(wù)數(shù)據(jù)質(zhì)量保證
在任務(wù)頻繁重啟過程中，容易觸發(fā)各功能點(diǎn)的Corner Case導(dǎo)致數(shù)據(jù)質(zhì)量異常。在考慮功能的健壯性基礎(chǔ)上，結(jié)合Flink兩階段提交能力保證數(shù)據(jù)處理Exactly Once。ODS數(shù)據(jù)在分流任務(wù)處理過程中主要經(jīng)過Flink File Source以及Multi Hive Sink，在Flink connectors實(shí)現(xiàn)過程中結(jié)合Checkpoint實(shí)現(xiàn)數(shù)據(jù)處理 Exactly Once。另外在維表Join處理上，也可能發(fā)生維表Join異常導(dǎo)致DQC異常。
5.3.1 File Source兩階段提交
- 文件處理Exactly Once
通過掃描ODS表目錄并根據(jù)目錄下索引文件得到可見文件，基于分區(qū)寫入文件修改時(shí)間單調(diào)遞增的特性，Checkpoint記錄已轉(zhuǎn)換Splits的文件最大Modify Time。任務(wù)重啟后掃描的文件過濾出小于記錄的modify time即可保證文件處理精確一次。
- Split分發(fā)Exactly Once
文件在轉(zhuǎn)換Split之后，將會(huì)由Monitor統(tǒng)一下發(fā)至Reader算子，在分發(fā)過程中，Monitor負(fù)責(zé)記錄未發(fā)送的split，Reader算子記錄已接收的split，保證split分發(fā)不丟不重。
- Split轉(zhuǎn)換RowData Exactly Once
Split在轉(zhuǎn)換為RowData過程中，原生的 HiveTableFileInput不支持Checkpoint，沒有記錄split，任務(wù)在重啟時(shí)會(huì)導(dǎo)致split重復(fù)讀取導(dǎo)致數(shù)據(jù)重復(fù)。通過改造在checkpoint時(shí)記錄當(dāng)前每個(gè)Split處理的SplitNumber，在重啟恢復(fù)Reopen Split時(shí)從上次記錄的Split Number處開始消費(fèi)，保證Split轉(zhuǎn)換RowData時(shí)精確一次。
5.3.2 維表加載數(shù)據(jù)準(zhǔn)確性
- 維表加載降級(jí)
由于維表加載需要訪問外部系統(tǒng)，容易產(chǎn)生異常導(dǎo)致維表加載失敗。由于業(yè)務(wù)存在根據(jù)維表加載的數(shù)據(jù)進(jìn)行where過濾，一旦維表數(shù)據(jù)異常則會(huì)發(fā)生數(shù)據(jù)丟失。因此在維表加載數(shù)據(jù)異常時(shí)主動(dòng)降級(jí)至上一個(gè)分區(qū)，雖然可能會(huì)導(dǎo)致部分新的數(shù)據(jù)join miss，但在最大程度上降低數(shù)據(jù)丟失風(fēng)險(xiǎn)。
- 文件鎖保證原子性
內(nèi)部在使用維表join時(shí)，選擇了直接通過加載hdfs目錄的方式加載數(shù)據(jù)。在沒有使用分區(qū)通知機(jī)制的情況下，加載是否完成只能通過Spark是否寫完作為最終標(biāo)志，由于是天級(jí)別目錄小時(shí)級(jí)更新場(chǎng)景，因此對(duì)于檢查SUCCESS文件的方法并不具備原子性。通過加文件鎖的方式，即判斷加載數(shù)據(jù)前后的文件時(shí)間是否發(fā)生變更保證HDFS維表加載原子性。
5.3.3 Multi Hive Sink數(shù)據(jù)質(zhì)量保證
- 文件兩階段處理
這里使用社區(qū)版本，即在寫出文件時(shí)為隱藏文件，執(zhí)行 Checkpoint時(shí)Close文件，在下一次checkpoint成功之后notify執(zhí)行rename操作保證數(shù)據(jù)一致性。
- 多表多級(jí)分區(qū)提前調(diào)度問題
在內(nèi)部分流場(chǎng)景下，為了減小下游數(shù)據(jù)攝取數(shù)量，由二級(jí)分區(qū)分流成為四級(jí)分區(qū)，四級(jí)分區(qū)在社區(qū)版本分區(qū)提交過程中，由于調(diào)度是小時(shí)級(jí)別，則需要判斷該分區(qū)下所有四級(jí)分區(qū)全部ready之后才能通知下游調(diào)度，僅通過watermark無法滿足該要求。我們通過在狀態(tài)中記錄Flink Bucket的Open和Close狀態(tài)，來判斷當(dāng)前小時(shí)分區(qū)下所有的四級(jí)分區(qū)是否完全結(jié)束。
- 集成archer新增Archer commit policy
傳統(tǒng)實(shí)時(shí)調(diào)度離線的方法通過打時(shí)間差方式進(jìn)行，需要平臺(tái)側(cè)通過定時(shí)調(diào)度拉起下游，為了保證不被提前調(diào)起，還要加分區(qū)是否創(chuàng)建兜底保障，調(diào)度任務(wù)拉起與上游分區(qū)通知存在gap。通過archer commit主動(dòng)通知方式可以解決這一gap帶來的調(diào)度不準(zhǔn)確的問題，因此通過集成archer在hive commit算子內(nèi)增加archer commit policy，對(duì)分流表下游調(diào)度基于主動(dòng)通知的模式拉起，保障數(shù)據(jù)質(zhì)量和調(diào)度準(zhǔn)確性。
6、實(shí)時(shí)增量計(jì)算落地效果
實(shí)時(shí)增量計(jì)算在北極星分流場(chǎng)景落地后，相比原有離線分流方案在各方面有顯著提升。
資源使用降低
在資源使用上整體資消耗降低約20%，峰值資源消耗降低約46%。
數(shù)據(jù)時(shí)效性提升
小時(shí)級(jí)分區(qū)歸檔時(shí)間平均提升20%，在 ODS-DWD ETL平均2TB每小時(shí)數(shù)據(jù)場(chǎng)景下，小時(shí)級(jí)同步99線保持30min內(nèi)，50線在17min內(nèi)。
分區(qū)可擴(kuò)展性增強(qiáng)
支持在同步資源不變條件下繼續(xù)拆分多表多級(jí)分區(qū)。
7、未來展望
在實(shí)時(shí)數(shù)倉流批一體的大背景下，實(shí)踐通過 Flink+Hudi方式打造北極星分流流批一體，整合實(shí)時(shí)離線鏈路降低資源開銷，并且通過 Hudi clustering能力進(jìn)一步降低讀取數(shù)據(jù)量，達(dá)到查詢加速的效果。
8、參考資料
[1]https://mp.weixin.qq.com/s/PQYylmHBjnnH9pX7-nxvQA
[2]https://mp.weixin.qq.com/s/E23JO7YvzJrocbOIGO5X-Q
[3]https://nightlies.apache.org/flink/flink-docs-release-1.16/docs/dev/table/sourcessinks/
[4]https://mp.weixin.qq.com/s/O0AXF74j6UvjtPQp5JQrTw
[5]??https://mp.weixin.qq.com/s/NawxeiP-_DFpyoekRrzlLQ??
本期作者
朱正軍
嗶哩嗶哩資深開發(fā)工程師
分享名稱：B站基于Flink的海量用戶行為實(shí)時(shí)ETL應(yīng)用實(shí)踐
網(wǎng)頁URL：http://m.5511xx.com/article/djgeeco.html
