譯者 | 李睿

審校 | 重樓

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

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

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

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

多跳和獎?wù)聰?shù)據(jù)架構(gòu)

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

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

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

多跳架構(gòu)的問題

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

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

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

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

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

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

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

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

構(gòu)建無頭數(shù)據(jù)架構(gòu)需要重新思考如何在組織中循環(huán)、共享和管理數(shù)據(jù)——這是一種向左的轉(zhuǎn)變。從下游提取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)品構(gòu)建無頭數(shù)據(jù)架構(gòu)

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

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

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

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

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

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

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

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

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

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

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

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

（4）從流中創(chuàng)建一個表。你可以使用Kafka Connect來生成Iceberg表，或者你可以依靠自動化的第三方專有服務(wù)來為你提供Iceberg表。完全披露：使用Kafka Connect會導(dǎo)致數(shù)據(jù)的副本被寫入Iceberg表。在不久的將來，預(yù)計期望看到第三方服務(wù)提供掃描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)建的表中遷移出去，棄用它，然后在方便的時候?qū)⑵鋭h除。

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

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

左移還解鎖了典型的復(fù)制粘貼、多跳和獎?wù)录軜?gòu)所沒有的一些強大功能。你可以從單個邏輯點一起管理流和表的演烴，驗證流演化不會破壞Iceberg表。

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

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

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

原文標(biāo)題：How to implement a headless data architecture，作者：Adam Bellemare