譯者 | 李睿

審校 | 重樓

無頭（Headless）數(shù)據(jù)架構是組織中心數(shù)據(jù)訪問層的形式化。它包含流和表，為操作用例和分析用例提供一致的數(shù)據(jù)訪問。流提供了低延遲的功能，以支持對事件的及時響應，而表提供了更高延遲但非常高效的批量查詢功能。用戶只需選擇與其需求最相關的處理頭，并將其插入數(shù)據(jù)中即可。

構建無頭數(shù)據(jù)架構需要識別在數(shù)據(jù)分析平臺內部深處已經(jīng)開展的工作，并將其向左移動，將用戶已經(jīng)在下游進行的工作（例如數(shù)據(jù)清理、結構化和模式化）向上游推送到源系統(tǒng)中。數(shù)據(jù)消費者可以依賴通過流和表提供的一組標準化數(shù)據(jù)來支持他們的操作、分析和所有中間環(huán)節(jié)。

通過左移方法創(chuàng)建無頭數(shù)據(jù)架構。下面的圖表強調了總體思路。通過將工作左移，顯著降低了下游成本。

與傳統(tǒng)的多跳方法相比，左移方法為創(chuàng)建、訪問和使用數(shù)據(jù)提供了一種更簡單、更具成本效益的方法。

多跳和獎章數(shù)據(jù)架構

如果你像絕大多數(shù)組織一樣，那么可能建立了一些提取-轉換-加載（ETL）數(shù)據(jù)管道、數(shù)據(jù)湖、數(shù)據(jù)倉庫和/或數(shù)據(jù)湖。分析平臺的數(shù)據(jù)分析師需要不同于操作平臺軟件開發(fā)人員所使用的專門工具。這種通用的“左移數(shù)據(jù)”結構通常被稱為多跳數(shù)據(jù)架構。

獎章架構可能是多跳架構中最流行的形式。它有三個級別的數(shù)據(jù)質量，采用奧運獎牌的顏色（銅、銀和金）來表示。銅層作為著陸區(qū)，銀層作為清理和定義明確的數(shù)據(jù)層(第二階段)，金層作為業(yè)務級聚合數(shù)據(jù)集(第三階段)。

進入第一階段的數(shù)據(jù)通常是原始的非結構化數(shù)據(jù)。然后對其進行清理、圖式化和標準化，然后寫入第二階段。從這里開始，它可以進一步聚合、分組、非規(guī)范化和處理，以在第三階段中創(chuàng)建特定于業(yè)務的數(shù)據(jù)集，這些數(shù)據(jù)集將繼續(xù)為儀表板、報告提供動力，并為人工智能和機器學習模型提供訓練數(shù)據(jù)。

多跳架構的問題

首先，多跳架構的速度很慢，因為它們通常是通過周期性觸發(fā)的批處理進程實現(xiàn)的。在下一跳開始之前，數(shù)據(jù)必須從源傳輸?shù)姐~層。

例如，如果每隔15分鐘將數(shù)據(jù)拉入銅層，那么隨后的每一跳也只能每隔15分鐘進行一次，因為數(shù)據(jù)只能以最慢部分的速度從一個階段移動到另一個階段。即使將每一跳的間隔時間縮短到1分鐘，那么在金層中仍然需要至少3分鐘才能獲得這些數(shù)據(jù)(不包括處理時間)。

其次，多跳架構開銷很大，因為每一跳都是數(shù)據(jù)的另一個副本，這需要處理能力來加載、處理數(shù)據(jù)，并將其寫入下一跳階段。這很快就會累積起來。

第三，多跳架構往往很脆弱，因為工作流的不同階段、源數(shù)據(jù)庫和最終用例通常由不同的人負責。為了防止中斷，需要非常強的協(xié)調。但在實踐中，這往往很難擴大規(guī)模。

第四，通過讓數(shù)據(jù)分析師有責任獲取他們自己的數(shù)據(jù)，最終可能會得到相似但又不同的數(shù)據(jù)管道。每個團隊都可以構建自己的自定義管道，以避免分布式所有權問題，但這可能導致相似但不同的管道的蔓延。公司的規(guī)模越大，相似但又不同的管道和數(shù)據(jù)集就越常見。找到所有可用的數(shù)據(jù)集可能會變得很有挑戰(zhàn)性。

但這導致了出現(xiàn)第五個問題，即相似但不同的數(shù)據(jù)集。為什么會有多個數(shù)據(jù)集？應該使用哪一個？這個數(shù)據(jù)集是否還在維護中，或者它是一個僵尸數(shù)據(jù)集，雖然還在定期更新，但有沒有人監(jiān)督？當依賴本應相同但實際上并不相同的數(shù)據(jù)集進行重要計算，而這些計算結果又相互矛盾時，問題就出現(xiàn)了。向客戶提供相互矛盾的報告、儀表板或指標會導致信任喪失，在最壞的情況下，還會導致業(yè)務損失甚至法律訴訟。

即使解決了所有這些問題—減少延遲、降低成本、刪除重復的管道和數(shù)據(jù)集以及消除故障修復工作，仍然沒有提供任何操作可以使用的程序。它們仍然是獨立的，在ETL的上游，因為所有的清理、結構、重構和分發(fā)工作只對數(shù)據(jù)分析領域的人真正有用。

左移以實現(xiàn)無頭數(shù)據(jù)架構

構建無頭數(shù)據(jù)架構需要重新思考如何在組織中循環(huán)、共享和管理數(shù)據(jù)——這是一種向左的轉變。從下游提取ETL->銅牌層->銀牌層，并將其放在數(shù)據(jù)產(chǎn)品的上游，更接近數(shù)據(jù)源。

“流優(yōu)先”的方法為數(shù)據(jù)產(chǎn)品提供了亞秒級的數(shù)據(jù)新鮮度，這與ETL生成的周期性數(shù)據(jù)集形成了鮮明對比，這些數(shù)據(jù)集最多只有幾分鐘的歷史并且過時。通過左移，可以讓公司各部門的數(shù)據(jù)訪問成本更低、更便捷、更快速。

使用數(shù)據(jù)產(chǎn)品構建無頭數(shù)據(jù)架構

在無頭數(shù)據(jù)架構中，數(shù)據(jù)的邏輯頂層是數(shù)據(jù)產(chǎn)品，你可能已經(jīng)通過數(shù)據(jù)網(wǎng)格方法對它有所了解。在無頭數(shù)據(jù)架構中，數(shù)據(jù)產(chǎn)品由流(由Apache Kafka提供支持)和相關表(由Apache Iceberg提供支持)組成。寫入流的數(shù)據(jù)也會自動附加到表中，這樣你就可以作為Kafka主題或Iceberg訪問數(shù)據(jù)。

下圖顯示了從源系統(tǒng)創(chuàng)建的流/表數(shù)據(jù)產(chǎn)品。首先將數(shù)據(jù)寫入流。然后，可以選擇轉換流中的數(shù)據(jù)，最終將其具體化到Iceberg表中。

可以使用流（Kafka主題）來支持低延遲的業(yè)務操作，例如訂單管理、車輛調度和金融交易。與此同時，也可以將批量查詢頭插入到Iceberg表中，以計算更高延遲的工作負載，例如日常報告、客戶分析和定期人工智能訓練。

數(shù)據(jù)產(chǎn)品是一種值得信賴的數(shù)據(jù)集，專門用于與其他團隊和服務共享和重用。它是職責、技術和流程的規(guī)范化，以簡化獲取你和你的服務所需的數(shù)據(jù)。你可能還聽說過將數(shù)據(jù)產(chǎn)品稱為可重用數(shù)據(jù)資產(chǎn)，盡管其本質是相同的——可共享、可重用、標準化和可信賴的數(shù)據(jù)。

數(shù)據(jù)產(chǎn)品創(chuàng)建邏輯在很大程度上依賴于源系統(tǒng)。例如：

• 事件驅動的應用程序將其輸出直接寫入Kafka主題，這可以很容易地具體化到Iceberg表。數(shù)據(jù)產(chǎn)品創(chuàng)建邏輯可能非常簡單，例如，屏蔽機密字段或完全刪除它們。
• 傳統(tǒng)的請求/響應應用程序使用更改數(shù)據(jù)捕獲(CDC)從底層數(shù)據(jù)庫中提取數(shù)據(jù)，將其轉換為事件，并將其寫入Kafka主題。更改數(shù)據(jù)捕獲(CDC)事件包含一個基于源表的定義良好的模式，你可以使用連接器本身或更強大的工具(例如FlinkSQL)對數(shù)據(jù)執(zhí)行進一步的轉換。
• SaaS應用程序可能需要使用Kafka Connect對端點進行周期性輪詢以寫入流。

流優(yōu)先數(shù)據(jù)產(chǎn)品的優(yōu)雅之處在于，你只需將其寫入流即可。你不必管理分布式事務來同時向流和表寫入數(shù)據(jù)(這很難正確完成，而且速度相對較慢)。相反，你可以通過Kafka Connect或專有的SaaS流到表解決方案(例如Confluent的Tableflow)從流創(chuàng)建一個只能追加的Iceberg表。容錯和只寫一次可以幫助檢查數(shù)據(jù)完整性，無論從流還是從表中讀取，都可以得到相同的結果。

選擇左移的數(shù)據(jù)集

“左移”并不是非此即彼的。事實上，它是非常模塊化和漸進的。你可以有選擇地決定哪些負載需要左移，哪些保持不變。你可以設置一個并行的左移解決方案，對其進行驗證，一旦滿意，就可以將現(xiàn)有的作業(yè)切換到該解決方案上。這個過程大致如下：

（1）在分析平臺中選擇一個常用的數(shù)據(jù)集。越常用的數(shù)據(jù)集，越適合左移。幾乎沒有容錯余地的業(yè)務關鍵數(shù)據(jù)(如賬單信息)也是左移的理想選擇。

（2）識別操作平臺中的數(shù)據(jù)來源。這就是你需要用它來創(chuàng)建數(shù)據(jù)流的系統(tǒng)。需要注意的是，如果這個系統(tǒng)已經(jīng)是事件驅動的，那么你可能已經(jīng)有一個可用的流，可以跳到下面的步驟4。

（3）創(chuàng)建一個與現(xiàn)有ETL管道并行的源到流工作流。你可能需要使用Kafka連接器(例如CDC)來將數(shù)據(jù)庫數(shù)據(jù)轉換為事件流?；蛘撸憧梢赃x擇直接向流生成事件；只需確保編寫了完整的數(shù)據(jù)集，使其與源數(shù)據(jù)庫保持一致。

（4）從流中創(chuàng)建一個表。你可以使用Kafka Connect來生成Iceberg表，或者你可以依靠自動化的第三方專有服務來為你提供Iceberg表。完全披露：使用Kafka Connect會導致數(shù)據(jù)的副本被寫入Iceberg表。在不久的將來，預計期望看到第三方服務提供掃描Kafka主題作為Iceberg表的能力，而無需制作數(shù)據(jù)的第二份副本。

（5）將表插入到現(xiàn)有的數(shù)據(jù)湖中，與銀層中的數(shù)據(jù)放在一起?，F(xiàn)在可以驗證新的Iceberg

表是否與現(xiàn)有數(shù)據(jù)集中的數(shù)據(jù)一致。一旦滿意，就可以將數(shù)據(jù)分析作業(yè)從舊的批量創(chuàng)建的表中遷移出去，棄用它，然后在方便的時候將其刪除。

其他的無頭數(shù)據(jù)架構注意事項

你可以將Iceberg表插入任何兼容的分析端點，而無需復制數(shù)據(jù)。對于數(shù)據(jù)流來說，情況也是如此。在這兩種情況下，只需選擇處理頭，并根據(jù)需要將其插入表或流中。

左移還解鎖了典型的復制粘貼、多跳和獎章架構所沒有的一些強大功能。你可以從單個邏輯點一起管理流和表的演烴，驗證流演化不會破壞Iceberg表。

由于工作已從數(shù)據(jù)分析空間中轉移出來，你可以將數(shù)據(jù)驗證和測試集成到源應用程序部署管道中。這可以幫助防止在代碼進入生產(chǎn)環(huán)境之前發(fā)生的破壞，而不是在下游很久之后才檢測到它。

最后，由于表是從流派生出來的，因此只需要在一個地方修復它，無論你向流寫入什么內容，都會傳播到表中。流媒體應用程序將自動接收糾正的數(shù)據(jù)，并進行自我糾正。但是，需要識別并重新運行使用該表的定期批處理作業(yè)。但無論如何，這與在傳統(tǒng)的多跳架構中需要做的事情是相同的。

無頭數(shù)據(jù)架構可以在整個組織中解鎖前所未有的數(shù)據(jù)訪問，但它從左移開始。

原文標題：How to implement a headless data architecture，作者：Adam Bellemare