運維和分析用例都面臨著同樣的問題：它們無法可靠地訪問整個組織中相關、完整和可信賴的資料。相反，每個用例往往都需要自己拼湊一些資料訪問方式。ETL 管道可能為資料分析用例的資料訪問需求提供一部分解決方案，而 REST API 可能為運維用例提供一些臨時資料訪問請求。

但是，每個獨立的解決方案都需要自己的實現和維護，從而導致重複工作、過高的成本以及很多很接近又略有不同的資料集。

有一種方法可以讓需要資料的人員和系統更好地使用資料，無論他們是將資料用於運維、分析還是介於兩者之間的目的。使用這種方法意味著重新思考那些過時但仍常用的 ETL 模式、昂貴且緩慢的多跳資料處理架構以及資料訪問責任分配中普遍存在的“人人為己”的心態。這不僅是一種思維轉變，而且是我們對資料處理位置、資料使用者以及具體實現的轉變。簡而言之，這是一種左移，將你已經在做（或將要做）的下游工作向左移（到上游），以便所有人都能從中受益。

但我們從哪裡向左移呢？

資料湖通常是一種 多跳架構，其中資料經過多次處理和複製，最終達到某種水平的質量和組織度，可以為特定業務用例提供支援。資料從左到右流動，從某種形式的 ETL 開始，從源系統進入資料湖或資料倉庫。

多跳架構已經存在了幾十年，一直是彌合運維與分析鴻溝的架構之一。然而，它們本質上就是效率低下、速度慢、成本高昂且難以複用的。

獎牌架構（medallion architecture） 是當今最流行的多跳架構形式。根據奧運獎牌標準，它分為三種獎牌或層：銅牌、銀牌和金牌。每一層都代表著更高的質量、可靠性和保證：銅牌最弱，金牌最強。

獎牌架構以及所有多跳架構都存在一些嚴重問題。我們來看看具體情況：

多跳獎牌模型以一個拉取系統為前提。下游資料處理者必須首先建立一個 ETL 作業，將資料拉入獎牌架構。接下來，他們必須對其進行重新建模、清理，並將其轉換為可用形式，然後才能開始實際工作。這是一種被動且站不住腳的立場，因為消費者承擔著保持資料可用和執行的全部責任，而對源模型沒有所有權，甚至沒有影響力。

此外，這裡的 ETL 與源資料模型耦合，帶來了非常緊密且脆弱的耦合關係。對上游系統（例如資料庫架構）所做的任何更改都可能導致管道中斷。

填充銅牌層需要大量的資料複製和處理能力。然後，我們要立即再次處理和複製這些資料，以使其達到銀牌層質量。每個步驟都會產生成本——載入資料、網路傳輸、將副本寫回磁碟和計算資源——這些成本很快就會累積成一大筆費用。它的構建和維護成本本身就很高，並且會導致大量資源浪費。

再考慮以消費者為中心的資料訪問責任時，上述成本可能會進一步膨脹。不清楚可以使用或不能使用哪些資料的消費者傾向於從源頭構建自己的管道，從而增加計算和人力資源的總成本。結果可能是金牌層專案無法提供足夠的投資回報，僅僅因為這種模式產生的成本太高了。

假設你成功地將資料從系統中 ETL 到資料湖中了。現在，你需要對其進行非規範化、重構、標準化、重塑，並使其有意義，並且不能犯任何錯誤。

美國曾經流行的電視節目《犯罪現場調查員》（CSI）給觀眾帶來了一種對恢復資料的結構和形式這一操作的不切實際的印象。在一個場景中，一名調查員告訴另一名調查員“增強”計算機螢幕上的影像，於是另一名調查員把影像放大了很多倍，從嫌疑人的太陽鏡上反射出來的模糊的畫素化影像突然變成了清晰的線索。實際上，我們只會得到一些非常塊狀畫素的特寫，無論多少“增強”都無法修復它。

這是一個警示故事。銅牌層的建立者不是源域模型的專家，但他們要負責重建精確、完美的資料。為了實現這一目標，他們所做的任何工作都是非常有挑戰性的，儘管他們可能重建出和源資料模型所代表的內容很接近的結果，但它可能並不完全正確。這就是下一個問題所在。

在更實際的場景中，考慮一個人輸入的三個地址：123 Fake Street、123 Fake st. 和 123 FAKE STR。哪一個是正確的地址？資料的獨立消費者會將其標準化為哪一個？雖然這種非標準化格式的每個消費者都會盡力做出明智而理性的處理決策，但這些相對平凡的資料清理步驟可能會造成嚴重破壞。一個系統可能會將它們合併為一個地址，而另一個系統可能不會，從而導致不同的結果和相互矛盾的報告。

從源頭獲取正確的高保真資料，儘可能清晰明瞭、保持最佳結構，這一工作是無可替代的。如果你做得沒問題，就能將其複用於你的所有用例——運維、分析以及介於兩者之間的一切。

銅牌層是從上游系統中提取的所有資料的垃圾場。它承擔著過多的責任，並且在源系統資料和（據稱）更值得信賴的銀牌層資料之間建立了複雜的對映。它是一個複雜的紙牌屋，依賴 ETL 和資料清理作業的編排，同時又容易因上游輸入資料的任何更改而中斷。

結果是銅牌層經常以某種方式被破壞，需要重新處理資料並進行事後分析，從而導致報告、儀表板和分析不一致。如果你足夠幸運地注意到問題的存在，並且沒有收到非常憤怒的客戶抱怨，那就會發生這種情況。

信任在業務中至關重要。我工作過的所有資料組織都有這樣一句話，可以歸結為：“信任難以建立，又容易崩塌”。

糟糕的資料會讓你的客戶失去對你的信任。想象一下，在儀表板上向他們顯示一個值，但在賬單中向他們收取另一個金額，看看他們有多高興吧。相似但不同的資料集在獎牌架構中很常見，因為標準化資料的所有工作都是消費者負責的。無論你和你的團隊多麼勤奮、善意或警覺，都很容易犯錯誤。

推送到分析端點的資料大部分（通常只）停留在分析空間中，所有清理、標準化、模式化和轉換工作也是如此。它通常由定期批處理作業處理，這些作業對於運維用例來說往往太慢了。

相反，運維負載會開發自己的技術和工具來訪問它們需要的資料，進一步擴大了運維和分析空間之間的鴻溝。

左移是對我們如何在組織內傳遞資料的一種新的理念。從本質上講，它是讓你將已經在做的（或計劃做的）工作向左移動，以便每個人都能從中受益。左移消除了重複的管道，降低了不良資料的風險和影響，並讓你利用高質量的資料來源處理運營和分析用例。左移是迭代和模組化的——你可以只將一個數據集向左移動，也可以移動多個數據集。這完全取決於你的具體需求。

左移之所以有效，是因為你只是在做你已經在做或將要做的工作，只是把它們推到上游了。例如，你已經：

資料產品 提供了定義明確、高質量、可互運維且受支援的資料，其他團隊、人員和系統可以根據需要使用這些資料。資料產品可以幫助輕鬆訪問資料，而無需消費者自行尋找訪問方式（缺陷 #1）。可將資料產品視為一等資料公民，其釋出內容具有與你或你的企業建立的任何其他產品相同的保證和質量。

之前將原始銅牌資料轉換為結構良好的銀牌資料的所有邏輯都被移出資料湖，並放入資料產品的邊界中。清理、重構和架構實現會盡可能靠近源頭來執行，以便你在流程早期就獲得乾淨且定義明確的資料模型。這樣一來，我們就無需清理和標準化資料來源（缺陷 3），而且只需標準化和清理一次，而不是在多個下游系統中多次清理，從而降低清理成本（缺陷 2）。

我們稍後會進一步討論正式的資料產品定義，但首先，我們先將注意力轉向資料產品客戶（人員、團隊和系統）如何訪問資料這個話題。

資料產品可以透過多種方式提供資料——也稱為模式。例如，透過流（通常是 Apache Kafka 主題）和表（通常是某種基於 Parquet 的結構）提供資料。

分析用例傳統上依賴於定期批處理作業和表格資料。然而，現代用例往往需要低延遲流來完成許多分析任務，例如支援客戶儀表板、預測和塑造使用者參與度以及監控業務的即時健康狀況，等等。

但流也可以驅動運維用例，這很好地解決了我們的缺陷 #5。簡而言之，你用於標準化和構造表模式資料的那些邏輯非常適合生成流模式。你只需對流 / 表資料產品投資一次，即可同時支援運維和分析用例。

Apache Iceberg 是從事件流中提供物化表的主要方法之一，因此你可以將其插入所需的任何分析處理引擎，而無需額外複製資料。你可以節省大量時間和精力（缺陷 #1 和 #3）和金錢（缺陷 #2），同時減少誤解、重複管道，還能大大抑制相似但不同的資料集的增加（缺陷 #4）。

你可以使用 Apache Kafka 聯結器建立代表事件流的 Iceberg 表。一些服務提供商還提供自己的第一方選項，以進一步降低複雜性，例如 Confluent 的 Tableflow 功能可將任何 Kafka 主題直接轉換為 Iceberg 表。

你可能會問，“但是如何保持流和表的一致性？”

最簡單的方法之一是使用直寫方法 – 首先將資料寫入流，然後從流中物化表。你可以使用聯結器來生成表，也可以編寫一些自定義程式碼將流物化為一個表來表示。

從一開始就寫入流可以解決整個組織的所有事件驅動用例。派生物化表作為資料產品的一部分，可實現很多基於表的用例，例如批次載入資料、基於批處理的查詢以及為不需要流資料的系統提供支援。

在結束之前還有一些事情需要介紹。現在我們來更深入地瞭解資料產品本身。

資料產品主要是對你已經完成或需要完成的工作進行形式化，以使資料在整個組織中可用。你建立和管理資料產品的嚴謹程度將取決於你的公司文化、業務需求和資料問題。

當你有許多重要的資料集分佈在多個系統、域和團隊中時，通常需要採用嚴格而正式的方法。簡而言之，依賴資料的人越多，你構建、管理和監控資料產品就應該越嚴格。

構建成功資料產品的常見實踐包括：

資料合約為所有使用者（包括流和表模式）提供了資料產品及其 API 的形式和功能的正式協議。資料合約還在內部和外部資料模型之間提供了一道屏障，為資料產品使用者提供了穩定且可演進的 API 以及對其他業務領域明確定義的邊界。

資料合約的常見要點包括：

建立資料合同時需要潛在消費者的意見，尤其是那些依賴原始不可靠資料的消費者。是什麼讓他們感到痛苦？他們想要修復什麼？他們需要哪些保證來避免由未知更改導致的故障？

然後，這些潛在消費者與資料產品所有者及其支援團隊成員一起敲定資料產品的角色、職責、資料定義和變更管理框架。

也許最常見的問題之一是左移方法的左移程度。答案會根據幾個因素而有所不同，但通常會遵循三種主要模式之一。

第一種模式是完全向左移動。資料產品是在源系統的應用程式程式碼中建立的，資料以格式良好的事件形式原生地傳送到事件流。資料產品所有者是應用程式團隊的成員，資料合同與應用程式的所有其他 API 一起管理。應用程式團隊完全願意並能夠構建和管理資料產品。

但並非所有系統都允許這種級別的整合。例如，遺留應用程式可能會限制那些安全性不足的進一步更改。社會技術因素也可能是另一個因素，比如源應用程式團隊拒絕提供更深層次的應用程式整合。在這種情況下，你必須在源應用程式之外構建資料產品，並且你還需要搞清楚源應用程式團隊願意提供什麼級別的支援。

雖然社會技術因素可能會阻礙向左移動，但現實情況是資料清理和標準化仍然需要由某個地方的某個人來完成。一種不太理想但仍然可行的方法是任命一個團隊來管理源應用程式之外的資料產品。這種型別 2 模式如下所示，它利用變更資料捕獲聯結器從資料庫獲取資料並進行轉換（例如標準化某些欄位），然後將其寫入輸出帳戶主題。

這一整合級別的缺點是，對資料庫表的更改可能會破壞資料產品。但這可能是一種更可接受的模式，因為應用程式團隊不再需要處理那些自己的管道已被破壞的團隊和系統的投訴。相反，他們可以簡單地與資料產品所有者打交道，減輕自己的壓力，併為他們未來的進一步合作開啟大門。

這兩種模式都假設你可以從單個數據庫中獲取所需的所有資料。但如果你需要來自多個系統的資料怎麼辦？這就引出了型別 3 整合，我們使用完全外部的流處理器將來自多個流的資料整合到一個數據產品中。

第三種類型往往出現在組織隨著左移而成熟時，並可能產生飛輪效應。隨著越來越多的源系統提供資料，訪問資料變得更加容易——對易於混合和匹配的資料的需求不斷增加，你也不用再構建和管理自己的資料管道並自己完成所有工作。

在此示例中，我們看到 Flink SQL 被用於建立豐富的訂單主題，它將三個不同源系統提供的帳戶資訊、訂單資訊和產品資訊結合在一起。

左移為組織中所有需要它的人提供了乾淨、可靠且可訪問的資料。它最終會減少複雜性、開銷和故障修復工作，並讓你和你的同事騰出時間去處理其他更有價值的問題。資料產品是左移策略的支柱，是整個組織健康資料通訊的基礎。

左移的重點在於重新協商工作完成的位置以及負責確保工作正確完成的人員。雖然看起來我們是在增加工作量，但我們只是把在銅牌層中要做的工作（例如清理、標準化和模式化）轉移到上游。這種型別的工作最容易左移，因為它將澄清資料含義的責任放在最瞭解資料的人們身上——也就是最初建立資料的團隊、人員和系統。

你可以選擇使用流來執行更高階的模式——例如複雜的基於時間的聚合、特定於業務的應用程式邏輯或其他型別的處理工作。然而，左移的關鍵只是建立對高質量資料產品的輕鬆訪問能力，以取代通常在銅牌層中完成的工作，使所有人而不是少數人受益。

Adam Bellemare 是 Confluent 技術戰略組的首席技術專家。他是 O'Reilly 的《構建事件驅動的微服務》（2020 年）和《構建事件驅動的資料網格》（2023 年）的作者。他的工作重點是事件驅動架構理論與實踐、事件驅動的微服務和事件流設計原則。在加入 Confluent 之前，Adam 曾在多家電子商務公司擔任大資料平臺工程師，專注於使用 Apache Spark、HDFS 和早期 S3 構建批處理解決方案，之後將注意力轉向事件驅動架構。從那時起，他主要專注於使用 Apache Kafka 構建微（和常規）服務，並宣傳將有用的業務事實發布為通用資料訪問層的好處。