數據工程和軟件工程長期以來一直存在分歧，各自都有自己獨特的工具和最佳實踐。一個關鍵的區(qū)別是在構建數據產品時需要專門的編排。在本文中，我們將探討數據協調器所扮演的角色，以及行業(yè)的最新趨勢如何使這兩個學科比以往任何時候都更加緊密地結合在一起。

數據編排的現狀

投資數據能力的主要目標之一是統一整個企業(yè)的知識和理解。這樣做的價值可能是巨大的，但它涉及集成越來越多的系統，而且復雜性往往越來越高。數據編排為構建這些系統提供了一種原則性的方法，其復雜性來自于：

· 許多不同的數據源，每個都有自己的語義和限制

· 數據產品的許多目的地、利益相關者和用例

· 創(chuàng)建最終產品涉及的異構工具和流程

典型數據堆棧中有多個組件可以幫助組織這些常見場景。

組件

數據工程的流行行業(yè)模式被稱為提取、加載和轉換，或ELT。數據 (E) 從上游源中提取，(L) 直接加載到數據倉庫中，然后 (T) 轉換為各種特定于領域的表示形式。存在變體，例如ETL，它在加載到倉庫之前執(zhí)行轉換。所有方法的共同點是三種高級功能：攝取、轉換和服務。這三個階段之間以及每個階段內部都需要編排來協調。

食入

攝取是將數據從源系統(例如數據庫)移動到存儲系統中的過程，該存儲系統允許轉換階段更輕松地訪問它。此階段的編排通常涉及安排任務在上游有新數據時運行，或者在這些系統可用時主動偵聽來自這些系統的通知。

轉型

轉換的常見示例包括從原始結構中解包和清理數據，以及將其拆分或連接到與業(yè)務領域更緊密結合的模型中。 SQL 和 Python 是表達這些轉換的最常見方法，現代數據倉庫為它們提供了極好的支持。此階段編排的作用是對轉換進行排序，以便有效地生成利益相關者使用的模型。

服務

服務可以指非常廣泛的活動。在某些情況下，最終用戶可以直接與倉庫交互，這可能只涉及數據管理和訪問控制。更常見的是，下游應用程序需要訪問數據，這反過來又需要與倉庫的模型同步。加載和同步是協調器在服務階段發(fā)揮作用的地方。

從源到數據倉庫，再到最終用戶應用程序的典型數據流攝取引入數據，在倉庫中進行轉換，并將數據提供給下游應用程序。

這三個階段構成了用于分析系統的有用心理模型，但對業(yè)務來說重要的是它們所支持的功能。數據編排有助于協調從源系統(可能是核心業(yè)務的一部分)獲取數據所需的流程，并將其轉化為數據產品。這些流程通常是異構的，并且不一定是為了協同工作而構建的。這可能會給協調器帶來很多責任，讓其負責制作副本、轉換格式和其他臨時活動以將這些功能整合在一起。

工具

大多數數據系統的核心都依賴于一些調度功能。當僅需要在可預測的基礎上管理有限數量的服務時，常見的方法是使用簡單的調度程序，例如cron.以這種方式協調的任務可以非常松散地耦合。在任務依賴性的情況下，可以直接安排一個任務在另一個任務預計完成后一段時間開始，但結果可能對意外延遲和隱藏依賴性很敏感。

隨著流程變得越來越復雜，明確它們之間的依賴關系變得很有價值。這就是Apache Airflow等工作流引擎所提供的功能。 Airflow 和類似的系統通常也被稱為“編排器”，但正如我們將看到的，它們并不是唯一的編排方法。工作流引擎使數據工程師能夠指定任務之間的明確順序。它們支持運行計劃任務，并且還可以監(jiān)視應觸發(fā)運行的外部事件。除了使管道更加健壯之外，它們提供的依賴關系鳥瞰圖還可以提高可見性并實現更多治理控制。cron

有時“任務”的概念本身可能是有限制的。任務本質上是對批量數據進行操作，但流世界依賴于連續(xù)流動的數據單元。許多現代流框架都是圍繞數據流模型構建的——Apache Flink就是一個流行的例子。這種方法放棄了獨立任務的排序，有利于組合可以對任何大小的塊進行操作的細粒度計算。

從編曲到作曲

這些系統之間的共同點是它們捕獲依賴關系，無論是隱式的還是顯式的、批處理的還是流式的。許多系統需要結合使用這些技術，因此一致的數據編排模型應該將它們全部考慮在內。這是由更廣泛的組合概念提供的，該概念捕獲了數據編排器今天所做的大部分工作，并擴展了未來如何構建這些系統的視野。

可組合數據系統

數據編排的未來正在轉向可組合的數據系統。編排器一直承擔著連接越來越多的系統的沉重負擔，而這些系統從未被設計為相互交互。組織已經建立了數量驚人的“粘合劑”來將這些流程粘合在一起。通過重新思考數據系統如何組合在一起的假設，新方法可以大大簡化其設計。

開放標準

數據格式的開放標準是可組合數據移動的核心。Apache Parquet已成為列式數據事實上的文件格式，而Apache Arrow是其內存中的對應項。圍繞這些格式的標準化非常重要，因為它減少甚至消除了困擾許多數據管道的昂貴的復制、轉換和傳輸步驟。與本機支持這些格式的系統集成可以實現本機“數據共享”，而無需所有粘合代碼。例如，攝取過程可能會將 Parquet 文件寫入對象存儲，然后簡單地共享這些文件的路徑。然后，下游服務可以訪問這些文件，而無需制作自己的內部副本。如果工作負載需要與本地進程或遠程服務器共享數據，它可以使用Arrow IPC或Arrow Flight，開銷接近于零。

標準化正在堆棧的各個級別上進行。Apache Iceberg和其他開放表格式基于 Parquet 的成功，定義了用于組織文件的布局，以便將它們解釋為表。這為文件訪問添加了微妙但重要的語義，可以將文件集合轉變?yōu)橛性瓌t的數據湖庫。加上一個目錄，比如最近孵化的Apache Polaris，組織擁有治理控制來構建權威的事實來源，同時受益于底層格式支持的零拷貝共享。這種組合的力量怎么強調都不為過。當業(yè)務的真實來源與生態(tài)系統的其他部分零復制兼容時，只需共享數據即可實現很多編排，而不是構建繁瑣的連接器流程。一旦數據以 Parquet 形式寫入對象存儲，無需任何轉換即可共享。

解構堆棧

數據系統始終需要對文件、內存和表格式做出假設，但在大多數情況下，它們都隱藏在其實現的深處。用于與數據倉庫或數據服務供應商交互的狹窄 API 可以實現簡潔的產品設計，但它并不能最大化最終用戶可用的選擇。它們描述了旨在支持類似業(yè)務功能的數據系統。

在封閉系統中，數據倉庫內部維護自己的表結構和查詢引擎。這是一種一刀切的方法，可以輕松上手，但可能難以擴展以滿足新的業(yè)務需求。鎖定可能很難避免，尤其是在涉及治理和其他訪問數據的服務等功能時。云提供商在其生態(tài)系統內提供無縫且高效的集成，因為它們的內部數據格式是一致的，但這可能會關閉在該環(huán)境之外采用更好產品的大門。相反，導出到外部提供商需要維護專為倉庫專有 API 構建的連接器，并且可能導致數據跨系統蔓延。

開放的、解構的系統標準化了其最低級別的細節(jié)。這使得企業(yè)能夠挑選最佳的服務供應商，同時獲得以前只能在封閉的生態(tài)系統中才能實現的無縫體驗。在實踐中，開放數據系統的主要關注點是首先將源數據復制、轉換并轉化為開放表格式。完成此操作后，可以通過共享對僅寫入組織事實來源一次的數據的引用來實現許多編排。正是這種在各個層面共享數據的趨勢，促使組織重新思考數據的編排方式并構建未來的數據產品。

結論

編排是現代數據系統的支柱。在許多企業(yè)中，它是負責理清復雜且相互關聯的流程的核心技術，但開放標準的新趨勢為如何協調這些依賴關系提供了新的視角。系統不是從頭開始構建以協作共享數據，而是將更大的復雜性推入編排層。云提供商一直在增加與這些標準的兼容性，這有助于為未來的最佳解決方案鋪平道路。通過采用可組合性，組織可以簡化治理并從行業(yè)中發(fā)生的最偉大進步中受益。

數據工程和軟件工程長期以來一直存在分歧，各自都有自己獨特的工具和最佳實踐。一個關鍵的區(qū)別是在構建數據產品時需要專門的編排。在本文中，我們將探討數據協調器所扮演的角色，以及行業(yè)的最新趨勢如何使這兩個學科比以往任何時候都更加緊密地結合在一起。