數(shù)據(jù)編排的現(xiàn)代時代：從數(shù)據(jù)碎片到協(xié)作第一部分

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

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

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

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

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

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

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

組件

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

食入

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

轉(zhuǎn)型

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

服務(wù)

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

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

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

工具

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

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

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

從編曲到作曲

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

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

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

開放標(biāo)準(zhǔn)

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

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

解構(gòu)堆棧

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

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

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

結(jié)論

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

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