1. 導(dǎo)讀

BitSail 是字節(jié)跳動(dòng)開源數(shù)據(jù)集成引擎，支持多種異構(gòu)數(shù)據(jù)源間的數(shù)據(jù)同步，并提供離線、實(shí)時(shí)、全量、增量場(chǎng)景下全域數(shù)據(jù)集成解決方案，目前支撐了字節(jié)內(nèi)部和火山引擎多個(gè)客戶的數(shù)據(jù)集成需求。經(jīng)過字節(jié)跳動(dòng)各大業(yè)務(wù)線海量數(shù)據(jù)的考驗(yàn)，在性能、穩(wěn)定性上得到較好驗(yàn)證。

10 月 26 日，字節(jié)跳動(dòng)宣布 BitSail 項(xiàng)目正式在 GitHub 開源，為更多的企業(yè)和開發(fā)者帶來便利，降低數(shù)據(jù)建設(shè)的成本，讓數(shù)據(jù)高效地創(chuàng)造價(jià)值。本篇內(nèi)容將圍繞 BitSail 演講歷程及重點(diǎn)能力解析展開，主要包括以下四個(gè)部分：

• 字節(jié)跳動(dòng)內(nèi)部數(shù)據(jù)集成背景
• BitSail 技術(shù)演進(jìn)歷程
• BitSail 能力解析
• 未來展望

2. 字節(jié)跳動(dòng)內(nèi)部數(shù)據(jù)集成背景

一直以來，字節(jié)跳動(dòng)都非常重視并貫徹“數(shù)據(jù)驅(qū)動(dòng)”這一理念，作為數(shù)據(jù)驅(qū)動(dòng)的一環(huán)，數(shù)據(jù)中臺(tái)能力的建設(shè)至關(guān)重要，而這其中，數(shù)據(jù)集成作為數(shù)據(jù)中臺(tái)建設(shè)的基礎(chǔ)，主要解決了異構(gòu)數(shù)據(jù)源的數(shù)據(jù)傳輸、加工和處理的問題。

BitSail 源自字節(jié)跳動(dòng)數(shù)據(jù)平臺(tái)團(tuán)隊(duì)自研的數(shù)據(jù)集成引擎 DTS（全稱 Data Transmission Service，即數(shù)據(jù)傳輸服務(wù)），最初基于 Apache Flink 實(shí)現(xiàn)，至今已經(jīng)服務(wù)于字節(jié)內(nèi)部業(yè)務(wù)接近五年，現(xiàn)已具備批式集成、流式集成和增量集成三類同步模式，并支持分布式水平擴(kuò)展和流批一體架構(gòu)，在各種數(shù)據(jù)量和各種場(chǎng)景下，一個(gè)框架即可解決數(shù)據(jù)集成需求。此外，BitSail 采用插件式架構(gòu)，支持運(yùn)行時(shí)解耦，從而具備極強(qiáng)的靈活性，企業(yè)可以很方便地接入新的數(shù)據(jù)源。

3. BitSail 演進(jìn)歷程

3.1  全域數(shù)據(jù)集成引擎演進(jìn)三階段

字節(jié)跳動(dòng)數(shù)據(jù)集成引擎 BitSail 演進(jìn)的歷程可以分為三個(gè)階段：

① 初始期：2018 年以前公司沒有統(tǒng)一的數(shù)據(jù)集成框架，對(duì)每個(gè)通道都是各自實(shí)現(xiàn)，因此依賴的大數(shù)據(jù)引擎也比較零散，如 MapReduce 、Spark ，數(shù)據(jù)源之間的連接也是網(wǎng)狀連接，整體的開發(fā)和運(yùn)維成本都比較高。

② 成長(zhǎng)期：可以分為三個(gè)小階段。

• 2018 - 2019 ：隨著 Flink 生態(tài)不斷完善，越來越多的公司將 Flink 作為大數(shù)據(jù)計(jì)算引擎的首選，字節(jié)跳動(dòng)也不例外，并在 Flink 上持續(xù)探索，并于 2019 年提出基于 Flink 的異構(gòu)數(shù)據(jù)源間傳輸，完成批式場(chǎng)景的統(tǒng)一。
• 2020 - 2021 ：隨著 Flink 批流一體的完善，字節(jié)跳動(dòng)對(duì)原有架構(gòu)進(jìn)行較大升級(jí)，并覆蓋了流式場(chǎng)景，完成批流場(chǎng)景的統(tǒng)一。
• 2021 - 2022 ：接入了 Hudi 數(shù)據(jù)湖引擎，解決 CDC 數(shù)據(jù)實(shí)時(shí)同步問題，并提供湖倉(cāng)一體解決方案。

③ 成熟期：2022 年開始全域數(shù)據(jù)集成引擎的整體架構(gòu)已經(jīng)穩(wěn)定，并經(jīng)過字節(jié)跳動(dòng)內(nèi)部各業(yè)務(wù)線生產(chǎn)環(huán)境的考驗(yàn)，在性能和穩(wěn)定性上也得到充分的保障，于是團(tuán)隊(duì)希望能夠?qū)⒛芰?duì)外輸出，為更多的企業(yè)和開發(fā)者帶來便利，降低數(shù)據(jù)建設(shè)的成本，讓數(shù)據(jù)高效地創(chuàng)造價(jià)值。

3.2  BitSail 數(shù)據(jù)集成引擎技術(shù)架構(gòu)演進(jìn)

3.2.1 基于 Flink 的異構(gòu)數(shù)據(jù)源傳輸架構(gòu)

基于 Flink 1.5 DataSet API 實(shí)現(xiàn)的異構(gòu)數(shù)據(jù)源傳輸架構(gòu)，只支持批式場(chǎng)景?？蚣芎诵乃枷胧牵瑢?duì)原始輸入層數(shù)據(jù)抽象為 BaseInput，主要用于拉取源端的數(shù)據(jù)；對(duì)輸出層抽象為 BaseOutput，負(fù)責(zé)將數(shù)據(jù)寫到外部系統(tǒng)。同時(shí)，框架層提供了基礎(chǔ)服務(wù)，包括類型系統(tǒng)（Type System）、自動(dòng)并發(fā)度（Auto Parallelism）、流控（Flow Control）、臟數(shù)據(jù)檢測(cè)（Dirty Data）等等，并對(duì)所有的數(shù)據(jù)源通道生效。

以下介紹一個(gè)批次場(chǎng)景上比較有意思的功能，也是實(shí)際業(yè)務(wù)中面臨的一些痛點(diǎn)。

上圖左上部分是原始的 Flink 運(yùn)行日志，從這個(gè)日志里看不到任務(wù)進(jìn)度數(shù)據(jù)和預(yù)測(cè)數(shù)據(jù)，如當(dāng)前任務(wù)運(yùn)行的百分比、運(yùn)行完成所需時(shí)間。

左下部分則是 Flink UI 界面提供的任務(wù)運(yùn)行的元信息，可以看到讀寫條數(shù)都是 0 ，從 Flink 引擎角度，由于所有算子作為一個(gè)整體是沒有輸入和輸出的，這是合理的，但從用戶角度就無法看到任務(wù)整體進(jìn)度信息和當(dāng)前處理記錄條數(shù)，從而導(dǎo)致用戶懷疑這個(gè)任務(wù)是否已經(jīng)卡住。圖中右邊是改造之后的效果，日志中明確輸出當(dāng)前處理了多少條數(shù)、實(shí)時(shí)進(jìn)度展示、消耗時(shí)間等等，該功能在字節(jié)內(nèi)部上線后，得到了很多業(yè)務(wù)的好評(píng)。

下面介紹一下具體的實(shí)現(xiàn)。

首先回顧 Flink Task 的執(zhí)行過程，與傳統(tǒng)的 MapReduce、Spark 的驅(qū)動(dòng)模型不一樣，F(xiàn)link 是以任務(wù)驅(qū)動(dòng)，JM 創(chuàng)建好 Split 之后，Task 是常駐運(yùn)行，不斷向 JM 請(qǐng)求新的 Split，只有所有的 Split 處理完之后，Task 才會(huì)退出。此時(shí)，如果用總的完成的 Task 個(gè)數(shù)除以總的 Task 個(gè)數(shù)，進(jìn)度將出現(xiàn)一定程度的失真。最開始，所有的 Task 都在運(yùn)行，不斷地去拉取 Split，我們看到的進(jìn)度會(huì)是 0，等到 JM 的 Split 處理完之后，所有的 Task 會(huì)集中退出，可以看到進(jìn)度會(huì)突然跳動(dòng)到 100%，中間是缺少進(jìn)度信息的。

為了解決這個(gè)問題，我們還是要回到數(shù)據(jù)驅(qū)動(dòng)本身，以 Split 的維度來衡量整個(gè) Job 的運(yùn)行過程。圖中右邊所展示的是，通過 Flink UI 提供的 API，可以拿到整個(gè)任務(wù)的拓?fù)湫畔?，將其分為兩層算子并進(jìn)行改造，分別是 Source 層和 Operator 層。

Source 層?

我們修改了原生的 Source API，具體的話包括兩個(gè)部分，第一個(gè)是創(chuàng)建 Split 之后，我們會(huì)去拿到 Total Split 的個(gè)數(shù)，將它上載到 Metric 里；其次是 Source里的每個(gè) Task 每處理完一個(gè) Split 之后，我們會(huì)上報(bào)一個(gè) CompletedSplit。最終我們通過 Flink UI 是可以拿到當(dāng)前已經(jīng)完成的 Split 個(gè)數(shù)以及總共的 Split 個(gè)數(shù)，并用完成的 Split 個(gè)數(shù)來除以總共的 Split 個(gè)數(shù)來衡量 Source 節(jié)點(diǎn)的進(jìn)度。

Operator 層?

首先我們會(huì)看當(dāng)前 Operator 上游節(jié)點(diǎn)的輸出多少條，以及當(dāng)前節(jié)點(diǎn)它讀取了多少條，并用當(dāng)前節(jié)點(diǎn)讀取的條數(shù)除以它的上游節(jié)點(diǎn)的輸出條數(shù)作為當(dāng)前 Operator 的進(jìn)度。同時(shí)，這里我們做了一個(gè)梯度限制，就是當(dāng)前節(jié)點(diǎn)的進(jìn)度只能小于等于它的上游節(jié)點(diǎn)進(jìn)度。

3.2.2 基于 Flink 批流一體的架構(gòu)

以下是批流一體的架構(gòu)，相對(duì)于原有架構(gòu)，字節(jié)跳動(dòng)數(shù)據(jù)平臺(tái)團(tuán)隊(duì)完成如下升級(jí)：

• 將 Flink 版本從 1.5 升級(jí)到 1.9，同時(shí)我們分析了 DataSet API，統(tǒng)一升級(jí)到 DataStream API，以支持批流一體架構(gòu)。
• 對(duì)數(shù)據(jù)源支持進(jìn)行擴(kuò)充，除了原有的離線數(shù)據(jù)源之外，增加了實(shí)時(shí)數(shù)據(jù)源，如消息隊(duì)列。
• 對(duì)框架層完成拓展，支持 Exactly Once、支持 Event Time 寫入、Auto DDL 等功能。
• 對(duì)引擎層進(jìn)行改進(jìn)，增加推測(cè)執(zhí)行、Region Failover 等功能。
• 在 Runtime 層也做了進(jìn)一步的擴(kuò)充，支持云原生架構(gòu)。

我們分析一個(gè)實(shí)時(shí)場(chǎng)景中比較典型的鏈路，MQ 到 Hive 這個(gè)鏈路。

左圖（Shuffle）是目前社區(qū)的實(shí)現(xiàn)方式，很多數(shù)據(jù)湖的寫入，比如 Hudi、Iceberg 基本上也是這個(gè)結(jié)構(gòu)。這套結(jié)構(gòu)分為兩層算子，第一層是我們的數(shù)據(jù)處理層，負(fù)責(zé)數(shù)據(jù)的讀取和寫入；第二層算子是一個(gè)單節(jié)點(diǎn)的提交層，它是一個(gè)單并發(fā)，主要負(fù)責(zé)元信息的提交，比如去生成 Hive 的分區(qū)或者做一些其他的元信息動(dòng)作。

這個(gè)架構(gòu)的優(yōu)勢(shì)是其整體拓?fù)洌〝?shù)據(jù)處理流程）比較清晰，算子功能定位也比較清楚，但是它有一個(gè)明顯的缺陷，加入一個(gè)單并發(fā)節(jié)點(diǎn)后，導(dǎo)致整個(gè)任務(wù)變成 Shuffle 連接。而 Shuffle 連接天然的弱勢(shì)是，當(dāng)遇到 Task Failover 的時(shí)候，它會(huì)直接進(jìn)行全局重啟。?

右圖（Pipelined）是改造之后的數(shù)據(jù)處理流程，數(shù)據(jù)寫入部分沒有變化，變化的是后面的提交部分，這樣的設(shè)計(jì)考慮是是保持原有 Pipeline 架構(gòu)，以實(shí)現(xiàn) Task 容錯(cuò)時(shí)不會(huì)進(jìn)行全局重啟。廢棄了原有的單并發(fā)提交節(jié)點(diǎn)，把所有元信息的提交拿到 JM 端處理，同時(shí) Task 和 JM 的通訊是通過 Aggregate Manager 來實(shí)現(xiàn)。改為這套架構(gòu)之后，在大數(shù)據(jù)量場(chǎng)景下，其穩(wěn)定性得到了顯著的提升。

3.2.3 基于 Flink 湖倉(cāng)一體的架構(gòu)

引入湖倉(cāng)一體架構(gòu)的目的是解決 CDC 數(shù)據(jù)的近實(shí)時(shí)同步。

右圖是原有架構(gòu)，處理流程包括三個(gè)模塊：

• 拉取批次任務(wù)：用來拉取 CDC 全量的數(shù)據(jù)，寫到 Hive 里作為一個(gè)基礎(chǔ)的鏡像。
• 實(shí)時(shí)任務(wù)：拉取 CDC 的 Changelog，并實(shí)時(shí)寫入 HDFS，作為一個(gè)增量數(shù)據(jù)。
• 離線調(diào)度任務(wù)：周期性地進(jìn)行 Merge，將全量數(shù)據(jù)和增量數(shù)據(jù)進(jìn)行合并，形成新的全量數(shù)據(jù)。

上述架構(gòu)比較復(fù)雜，并依賴 Flink、Spark 等多種計(jì)算引擎，在實(shí)時(shí)性方面，只能做到 T+1，最快也只能做到小時(shí)級(jí)延遲，無法有效支撐近實(shí)時(shí)分析場(chǎng)景。從效率來說，存儲(chǔ)開銷比較大，每個(gè)分區(qū)都是一個(gè)全量鏡像，而且計(jì)算成本較高，每次 Merge 都需要進(jìn)行全局 Shuffle。

右圖是升級(jí)后的架構(gòu)，主要的升級(jí)點(diǎn)包括：??

• 將 Flink 1.9 升級(jí)到 Flink 1.11，接入了 Hudi 數(shù)據(jù)湖引擎，以支持 CDC 數(shù)據(jù)近實(shí)時(shí)同步。這是因?yàn)?Hudi 引擎有完備的索引機(jī)制以及高效的 Upsert 性能。
• 對(duì) Hudi 引擎也進(jìn)行了多項(xiàng)基礎(chǔ)改進(jìn)，以提高整體的寫入效率和穩(wěn)定性。

最終實(shí)施的效果，近實(shí)時(shí)寫入，整體的延遲在 10 分鐘以內(nèi)，綜合性能比原有架構(gòu)提升 70% 以上。至此，完成了全域數(shù)據(jù)集成架構(gòu)統(tǒng)一，實(shí)現(xiàn)一套系統(tǒng)覆蓋所有同步場(chǎng)景。

3.3  架構(gòu)演進(jìn)過程實(shí)踐經(jīng)驗(yàn)分享

下面介紹實(shí)際演進(jìn)過程中的一些思考、問題和改進(jìn)方案。

表類型選擇?

數(shù)據(jù)湖是支持多種表格式的，比如 CopyOnWrite（簡(jiǎn)稱COW）表、MergeOnRead（簡(jiǎn)稱MOR）表。COW 表的優(yōu)勢(shì)在于讀性能比較好，但是會(huì)導(dǎo)致寫放大，MOR 表正好相反，寫的性能比較好的，會(huì)導(dǎo)致讀放大。具體選擇哪種表格式，更多要根據(jù)大家的業(yè)務(wù)場(chǎng)景來決定。

我們的業(yè)務(wù)場(chǎng)景是為了解決 CDC 數(shù)據(jù)的近實(shí)時(shí)同步，CDC 數(shù)據(jù)有個(gè)明顯的特點(diǎn)，是存在大量的隨機(jī)更新。這個(gè)場(chǎng)景下選擇 COW，會(huì)導(dǎo)致寫放大的問題比較嚴(yán)重，所以我們選擇了 MOR 表。上圖就是一個(gè) MOR 表查詢和寫入的流程。第一個(gè)是列存儲(chǔ)的基礎(chǔ)鏡像文件，我們稱之為 Base 文件，第二個(gè)是行存儲(chǔ)的增量日志，我們稱之為 Log 文件。

每次查詢時(shí)，需要將 Log 文件和 Base 文件合并，為了解決 MOR 表讀放大的問題，通常我們會(huì)建一個(gè) Compaction 的服務(wù)，通過周期性的調(diào)度，將 Log 文件和 Base 文件合并，生成一個(gè)新的 Base 文件。

Hudi 實(shí)時(shí)寫入痛點(diǎn)?

如圖所示，這是原生的 Hudi 實(shí)時(shí)寫入的流程圖。

首先，我們接入 Hudi 數(shù)據(jù)，會(huì)進(jìn)入 Flink State，它的作用是索引。Hudi 提供了很多索引機(jī)制，比如 BloomIndex。但是 BloomIndex 有個(gè)缺陷，它會(huì)出現(xiàn)假陽(yáng)性，降級(jí)去遍歷整個(gè)文件，在效率上有一定的影響。Flink State 的優(yōu)勢(shì)是支持增量更新，同時(shí)它讀取的性能會(huì)比較高。經(jīng)過 Flink State 之后，我們就可以確認(rèn)這條記錄是 Upsert，還是 Insert 記錄，同時(shí)會(huì)分配一個(gè) File Id。

緊接著，我們通過這個(gè) File Id 會(huì)做一層 KeyBy，將相同 File 的數(shù)據(jù)分配到同一個(gè)Task。Task 會(huì)為每一個(gè) File Id 在本地做一次緩存，當(dāng)緩存達(dá)到上限后，會(huì)將這批數(shù)據(jù) Flush 出去到 hoodie client 端。Hoodie client 主要是負(fù)責(zé)以塊的方式來寫增量的 Log 數(shù)據(jù)，以 Mini Batch 的方式將數(shù)據(jù)刷新到 HDFS。

再之后，我們會(huì)接一個(gè)單并發(fā)的提交節(jié)點(diǎn)，最新的版本是基于 Coordinator 來做的，當(dāng)所有的算子 Checkpoint 完成之后，會(huì)提交元信息做一次 Commit，認(rèn)為這次寫入成功。同時(shí) Checkpoint 時(shí)，我們會(huì)刷新 Task 的緩存和 hoodie client 的緩存，同時(shí)寫到 HDFS。通常，我們還會(huì)接一個(gè) Compaction 的算子，主要用來解決 MOR 表讀放大的問題。

這個(gè)架構(gòu)在實(shí)際的生產(chǎn)環(huán)境會(huì)遇到如下問題：?

（1）當(dāng)數(shù)據(jù)量比較大的時(shí)候，Flink State 的膨脹會(huì)比較厲害，相應(yīng)地會(huì)影響 Task 的速度以及 Checkpoint 的成功率。

（2）關(guān)于 Compaction 算子，F(xiàn)link 的流式任務(wù)資源是常駐的，Compaction 本身是一個(gè)周期性的調(diào)度，如果并發(fā)度設(shè)置比較高，往往就意味著資源的浪費(fèi)比較多。

（3）Flink 提供了很多資源優(yōu)化的策略，比如 Slot Sharing，來提高整體的資源利用率，這就會(huì)導(dǎo)致資源搶占的問題，Compaction 會(huì)和真正的數(shù)據(jù)讀寫算子來進(jìn)行資源的搶占。Compaction 本身也是一個(gè)重 I/O、CPU 密集型操作，需要不斷地讀取增量日志、全量日志，同時(shí)再輸出一個(gè)全量數(shù)據(jù)。

針對(duì)上述問題，我們優(yōu)化了 Hudi 的寫入流程。

首先我們會(huì)采集 CDC 的 Change Log，并發(fā)送到消息隊(duì)列，然后消費(fèi)消息隊(duì)列中的 Change Log，然后我們進(jìn)行如下三個(gè)優(yōu)化：?

（1）廢棄了原先的 Flink State，替換為 Hash Index。Hash Index 的優(yōu)勢(shì)是不依賴外部存儲(chǔ)。來了一個(gè) Hoodie Record 之后，只需要一個(gè)簡(jiǎn)單的哈希處理，就知道它對(duì)應(yīng)的 Bucket。

（2）將 Compaction 服務(wù)獨(dú)立成一個(gè)離線的任務(wù)，并且是周期性的調(diào)度，用來解決資源浪費(fèi)和資源搶占的問題。

（3）將 Task 緩存和 Hudi 緩存做了合并，因?yàn)槊看?Checkpoint 都需要刷新 Task 緩存，Hudi 緩存需要寫入 HDFS，如果緩存的數(shù)據(jù)量比較多，會(huì)導(dǎo)致整個(gè) Checkpoint 時(shí)間比較長(zhǎng)。

優(yōu)化之后，穩(wěn)定性方面，可以支持百萬(wàn)級(jí)的 QPS；端到端的 Checkpoint 延時(shí)控制在 1 分鐘以內(nèi)，Checkpoint 成功率可以做到 99%。

4. BitSail 能力解析

目前技術(shù)架構(gòu)比較成熟，并經(jīng)過字節(jié)跳動(dòng)各業(yè)務(wù)線的驗(yàn)證，在數(shù)據(jù)的穩(wěn)定性和效率上都能得到一定的保障。因此，我們希望能把自己沉淀的經(jīng)驗(yàn)對(duì)外輸出，給更多企業(yè)和開發(fā)者帶來便利，降低大家數(shù)據(jù)建設(shè)的成本，讓數(shù)據(jù)創(chuàng)造高效的價(jià)值。為了達(dá)到這個(gè)目標(biāo)，我們要解決兩個(gè)能力的構(gòu)建。

4.1  低成本共建能力

數(shù)據(jù)集成有一個(gè)明顯的網(wǎng)絡(luò)效應(yīng)，每個(gè)用戶所面臨的數(shù)據(jù)集成的場(chǎng)景也是不一樣的，因此需要大家的共同參與，完善數(shù)據(jù)集成的功能和生態(tài)，這就需要解決共建成本的問題，讓大家都能低成本地參與整個(gè)項(xiàng)目的共建和迭代。

在 BitSail 中，我們通過兩個(gè)思路推進(jìn)這個(gè)能力建設(shè)。

4.1.1 模塊拆分

所有的模塊糅合在一個(gè)大的 jar 包中，包括引擎層、數(shù)據(jù)源層、基礎(chǔ)框架層，模塊耦合比較嚴(yán)重，數(shù)據(jù)處理流程也不清晰。針對(duì)這個(gè)問題，我們按照功能模塊進(jìn)行劃分，將基礎(chǔ)框架和數(shù)據(jù)源從引擎中獨(dú)立出來，同時(shí)我們的技術(shù)組件采取可插拔的設(shè)計(jì)，以應(yīng)對(duì)不同的用戶環(huán)境，比如臟數(shù)據(jù)檢測(cè)、Schema 同步、監(jiān)控等等，在不同的環(huán)境中會(huì)有不同的實(shí)現(xiàn)方式。

4.1.2 接口抽象

框架對(duì) Flink API 是深度綁定，用戶需要深入到 Flink 引擎內(nèi)部，這會(huì)導(dǎo)致整體 Connector 接入成本比較高。為了解決這個(gè)問題，我們抽象了新的讀寫接口，該接口與引擎無關(guān)，用戶只要開發(fā)新的接口即可。同時(shí)在內(nèi)部會(huì)做一層新的抽象接口與引擎接口的轉(zhuǎn)換，這個(gè)轉(zhuǎn)換對(duì)用戶是屏蔽的，用戶不需要了解底層引擎細(xì)節(jié)。

4.2  架構(gòu)的兼容能力

不同公司依賴的大數(shù)據(jù)組件和數(shù)據(jù)源的版本不一樣，同時(shí)還會(huì)遇到版本前后不兼容問題，因此需要完善架構(gòu)的兼容能力，以解決不同環(huán)境下的快速安裝、部署和驗(yàn)證。我們同樣有兩個(gè)思路來建設(shè)這個(gè)能力。

4.2.1 多引擎架構(gòu)

當(dāng)前架構(gòu)和 Flink 引擎深度綁定，在使用場(chǎng)景方面受到一定的限制，比如有些客戶用了 Spark 引擎或者其他引擎。Flink 引擎依賴比較重的情況下，對(duì)于簡(jiǎn)單場(chǎng)景和小數(shù)據(jù)量場(chǎng)景，整體的資源浪費(fèi)比較嚴(yán)重。

為解決此問題，我們?cè)谝鎸宇A(yù)留了多引擎入口，在已經(jīng)預(yù)留的 Flink 引擎基礎(chǔ)之上，接下來會(huì)擴(kuò)展到 Spark 引擎或者 Local Engine。? 具體實(shí)現(xiàn)方面，我們對(duì)執(zhí)行的環(huán)境進(jìn)行了一層抽象，不同的引擎會(huì)去實(shí)現(xiàn)我們的抽象類。同時(shí)，我們探索 Local 執(zhí)行方式，對(duì)小數(shù)據(jù)量在本地通過線程的方式來解決，不用去啟動(dòng) Flink Job 或類似的處理，提高整體資源的使用效率。

4.2.2 依賴隔離

目前系統(tǒng)存在一些外部環(huán)境中沒有的內(nèi)部依賴，大數(shù)據(jù)底座也是綁定的公司內(nèi)部版本，我們進(jìn)行了三個(gè)方面的優(yōu)化：

• 剔除公司內(nèi)部依賴，采取開源的通用解決方案，以應(yīng)對(duì)不同的業(yè)務(wù)場(chǎng)景。
• 大數(shù)據(jù)底座方面，采用 Provided 依賴，不綁定固定底座，運(yùn)行時(shí)由外部指定，針對(duì)不兼容的場(chǎng)景，通過 Maven Profile 和 Maven Shade 隔離。
• 針對(duì)數(shù)據(jù)源多版本和版本不兼容的問題，采取動(dòng)態(tài)加載的策略，將數(shù)據(jù)源做成獨(dú)立的組件，每次只會(huì)加載需要的數(shù)據(jù)源，以達(dá)到隔離的目標(biāo)。

5. 未來展望

BitSail 希望數(shù)據(jù)暢通無阻地航行到有價(jià)值的地方，期待和大家共同合作，完善數(shù)據(jù)集成的功能和生態(tài)。同時(shí)未來我們將在三個(gè)方面繼續(xù)深化：

① 多引擎架構(gòu)：探索 Local Engine 落地，支持本地執(zhí)行，對(duì)簡(jiǎn)單場(chǎng)景和小數(shù)據(jù)量場(chǎng)景提高資源利用率；實(shí)現(xiàn)引擎智能選擇策略，針對(duì)簡(jiǎn)單場(chǎng)景使用 Local Engine；針對(duì)復(fù)雜場(chǎng)景復(fù)用大數(shù)據(jù)引擎的能力。

② 通用能力建設(shè)：推廣新接口，對(duì)用戶屏蔽引擎細(xì)節(jié)，降低 Connector 開發(fā)成本

探索 Connector 多語(yǔ)言方案。

③ 流式數(shù)據(jù)湖：統(tǒng)一 CDC 數(shù)據(jù)入湖解決方案，在性能上穩(wěn)定支撐千萬(wàn)級(jí) QPS

在數(shù)據(jù)湖平臺(tái)能力構(gòu)建方面，全面覆蓋批式、流式、增量使用場(chǎng)景。

??本文感謝 DataFun 志愿者鐘曉華整理?