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

數(shù)據(jù)編排的現(xiàn)狀

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

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

· 數(shù)據(jù)產(chǎn)品的許多目的地、利益相關者和用例

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

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

組件

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

食入

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

轉型

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

服務

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

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

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

工具

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

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

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

從編曲到作曲

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

可組合數(shù)據(jù)系統(tǒng)

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

開放標準

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

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

解構堆棧

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

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

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

結論

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

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