譯者 | 李睿

審校 | 重樓

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

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

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

與傳統的多跳方法相比，左移方法為創建、訪問和使用數據提供了一種更簡單、更具成本效益的方法。

多跳和獎章數據架構

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

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

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

多跳架構的問題

首先，多跳架構的速度很慢，因為它們通常是通過周期性觸發的批處理進程實現的。在下一跳開始之前，數據必須從源傳輸到銅層。

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

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

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

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

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

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

左移以實現無頭數據架構

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

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

使用數據產品構建無頭數據架構

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

下圖顯示了從源系統創建的流/表數據產品。首先將數據寫入流。然后，可以選擇轉換流中的數據，最終將其具體化到Iceberg表中。

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

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

數據產品創建邏輯在很大程度上依賴于源系統。例如：

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

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

選擇左移的數據集

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

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

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

（3）創建一個與現有ETL管道并行的源到流工作流。你可能需要使用Kafka連接器(例如CDC)來將數據庫數據轉換為事件流。或者，你可以選擇直接向流生成事件；只需確保編寫了完整的數據集，使其與源數據庫保持一致。

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

（5）將表插入到現有的數據湖中，與銀層中的數據放在一起。現在可以驗證新的Iceberg

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

其他的無頭數據架構注意事項

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

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

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

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

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

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