Arctic:網易數帆開放式流批一體表服務 | BDTC 精彩回顧

語言: CN / TW / HK

在近日舉辦的 BDTC 2021 中國大資料技術大會上,網易副總裁、網易杭州研究院執行院長、網易數帆總經理汪源在主題演講中介紹了有數資料生產力平臺的底層核心技術——開放式流批一體架構,重點分享了 Arctic 流批一體表服務的設計特點和實現原理。以下為演講內容整理。

流批割裂的問題

我們目前在開發過程中會遇到一個很頭疼的問題,我們稱之為流批割裂的問題,也就是說我們的資料因為當前技術體系的限制,離線資料和實時資料是要走兩條鏈路的,離線資料我們通常通過 Hive 和 Spark 去做處理,實時鏈路我們主要通過 HBase、Kafka、Kudu 的技術去處理。

這兩套技術割裂就會導致我們的技術體系不統一,我們的研發體系也割裂,我們需要在兩個地方重複開發同樣的邏輯,而且我們在應用層還是要去手工做資料的合併,這對我們的應用開發也帶來了很大的成本。

有數開放式流批一體架構

怎麼去解決這個問題,在業界內有很多不同的解決手段,我們追求的是一個開放式架構下的解決方案。目前我們基於行業裡面開源的技術,已經形成了一個基於資料湖的開放架構,在這個架構裡面整個技術棧分成了五個層面,最底層的是檔案系統,第二層是檔案格式,第三層是表格式,第四層是表服務,最後一層是 SQL 層,以 SQL 的方式來提供統一的入口。

在這個架構裡面,每一層的技術都是開放的,開源的技術,我們在做技術方案設計的時候,會始終追求我們的技術能夠很好地跟開放性的技術無縫融合,因為這樣才能夠滿足企業客戶的需求。

我們基於這個開放式的架構進行增強和升級,提出了 Arctic 這樣的一種表服務,也引入了另外一個開源的產品,叫 Iceberg 來作為一個流批一體的表格式。這樣我們就形成了一個開放式的流批一體架構,它能夠解決流計算和批計算儲存層割裂的問題。

Arctic 主要特徵

簡要介紹一下 Arctic 作為一個流批一體表服務主要的特徵,以及它的實現原理。它的主要的特色之一,是我們實現了實時場景的支援:我們支援基於主鍵的更新,相當於可以把它視作一個 KV 資料庫,我們還提供了流表的實時訂閱的功能,也能夠支援實時的維表 join。

在引擎方面的,Arctic 實現了多引擎的支援:它支援像 Flink、Spark 等主流的計算引擎,也支援像 Presto 和 Impala 等主流的分析引擎,並且多個引擎之間可以進行併發讀寫,我們也能夠保障整個系統的 ACID 的限制。

Arctic 作為一個表服務,其實主要做的是三方面的事情,第一個是資料的寫入,實時的資料寫入到了 Change 資料裡面,批量的資料寫入到 Base 資料。第二個是資料的讀取,我們實現了 Merge-on-Read,也就是在讀的時候把 Base 資料和 Change 資料進行合併。第三個我們要做資料的整理,在需要的時候我們要進行 Compaction 或者是 Split,或者是通過 Key 去做排序,這樣能夠維持整個系統的高效能的狀態。

Arctic 核心原理

Arctic 實現的核心原理是一個多層次的 Arctic Tree 資料組織的結構。如圖所示,樹上的 B011 和 B111 是兩個 Base 資料,我們的 Change 資料可以在這棵樹上處在更高的層面,就是圖中的 C11。在這個結構裡面,Change 資料所對應的 Base 資料不只是一個,而是兩個。當然這只是一個圖示,但我們的 Change 資料有可能對應任意多個更低層面的 Base 資料。這樣的資料組織原理,是我們跟其它的類似開源專案最大的區別。使用這樣的組織原理有什麼好處呢?我通過一些過程來向大家解釋。

第一個是我們能夠很好地去做 Compaction 或者是 Split。舉一個例子,比如說我們如果發現 B011 這個檔案比較大,超過了 100MB,我們的 Change 資料也比較大了,這個時候我們就可以把 Change 資料進行合併,同時把 B011 這個資料 Split 成 B0011 和 B1011 兩個 Base 資料,這個時候 C11 還是可以停留在這棵樹的上一層——我們的 Base 資料雖然發生了變化,但並一定不需要把 Change 資料和 Base 資料做 merge,這可以根據效能的需求自由地決定。

第二個,我們可以做 Merge-on-Read。這邊也舉了一個例子,我們把 B0011、B1011 和 C11 之間做一層一層的合併,這是我們做 Merge-on-Read 的實現的原理和方式。

Arctic 技術特點

這樣的實現原理和方式,它能夠帶來什麼樣的優點呢?我們總結下來有三個方面。

第一個,我們在這個過程中不需要引入一個索引結構,這樣我們就可以不依賴於一些比較複雜的索引系統,不像有的類似專案依賴於 HBase 這樣的外部系統做一個索引的結構,這個設計使得我們的寫入效能會更快。

第二個,我們可以實現 Base 資料和 Change 資料之間多對多的靈活對映,這對我們在系統實現上提供了一個非常好的靈活性。

第三個,我們可以通過動態的分割槽去控制檔案的大小,我們既可以避免檔案過大,也可以避免產生大量的小檔案。

這樣的核心原理,最終就使得我們具備了寫入快,讀取快,寫放大降低這三個特點。

小結

最後我們小結一下,Arctic 解決了傳統的技術在流和批之間割裂的問題,實現了流批一體的架構。同時我們是在一個開放式的架構體系下實現的,跟現有的 Hadoop 整個開源大資料技術體系是完全無縫融合的。第三點,Arctic 是一個高效能的表服務。

InfoQ 相關專訪:

資料中臺與湖倉一體能碰出怎樣的火花?網易數帆實時資料湖Arctic的新探索

BDTC 分享整體回顧:

網易汪源:資料生產力統一技術目標,開放式流批一體支撐落地