數(shù)據(jù)編排的現(xiàn)代時(shí)代:從數(shù)據(jù)碎片到協(xié)作第二部分
投資數(shù)據(jù)能力的主要目標(biāo)之一是統(tǒng)一整個(gè)企業(yè)的知識(shí)和理解。這樣做的價(jià)值可能是巨大的,但它涉及集成越來(lái)越多的系統(tǒng),而且復(fù)雜性往往越來(lái)越高。數(shù)據(jù)編排為構(gòu)建這些系統(tǒng)提供了一種原則性的方法,其復(fù)雜性來(lái)自于:
· 許多不同的數(shù)據(jù)源,每個(gè)都有自己的語(yǔ)義和限制
· 數(shù)據(jù)產(chǎn)品的許多目的地、利益相關(guān)者和用例
· 創(chuàng)建最終產(chǎn)品涉及的異構(gòu)工具和流程
典型數(shù)據(jù)堆棧中有多個(gè)組件可以幫助組織這些常見(jiàn)場(chǎng)景。
組件
數(shù)據(jù)工程的流行行業(yè)模式被稱(chēng)為提取、加載和轉(zhuǎn)換,或ELT。數(shù)據(jù) (E) 從上游源中提取,(L) 直接加載到數(shù)據(jù)倉(cāng)庫(kù)中,然后 (T) 轉(zhuǎn)換為各種特定于領(lǐng)域的表示形式。存在變體,例如ETL,它在加載到倉(cāng)庫(kù)之前執(zhí)行轉(zhuǎn)換。所有方法的共同點(diǎn)是三種高級(jí)功能:攝取、轉(zhuǎn)換和服務(wù)。這三個(gè)階段之間以及每個(gè)階段內(nèi)部都需要編排來(lái)協(xié)調(diào)。
食入
攝取是將數(shù)據(jù)從源系統(tǒng)(例如數(shù)據(jù)庫(kù))移動(dòng)到存儲(chǔ)系統(tǒng)中的過(guò)程,該存儲(chǔ)系統(tǒng)允許轉(zhuǎn)換階段更輕松地訪問(wèn)它。此階段的編排通常涉及安排任務(wù)在上游有新數(shù)據(jù)時(shí)運(yùn)行,或者在這些系統(tǒng)可用時(shí)主動(dòng)偵聽(tīng)來(lái)自這些系統(tǒng)的通知。
轉(zhuǎn)型
轉(zhuǎn)換的常見(jiàn)示例包括從原始結(jié)構(gòu)中解包和清理數(shù)據(jù),以及將其拆分或連接到與業(yè)務(wù)領(lǐng)域更緊密結(jié)合的模型中。 SQL 和 Python 是表達(dá)這些轉(zhuǎn)換的最常見(jiàn)方法,現(xiàn)代數(shù)據(jù)倉(cāng)庫(kù)為它們提供了極好的支持。此階段編排的作用是對(duì)轉(zhuǎn)換進(jìn)行排序,以便有效地生成利益相關(guān)者使用的模型。
服務(wù)
服務(wù)可以指非常廣泛的活動(dòng)。在某些情況下,最終用戶可以直接與倉(cāng)庫(kù)交互,這可能只涉及數(shù)據(jù)管理和訪問(wèn)控制。更常見(jiàn)的是,下游應(yīng)用程序需要訪問(wèn)數(shù)據(jù),這反過(guò)來(lái)又需要與倉(cāng)庫(kù)的模型同步。加載和同步是協(xié)調(diào)器在服務(wù)階段發(fā)揮作用的地方。
圖1。從源到數(shù)據(jù)倉(cāng)庫(kù),再到最終用戶應(yīng)用程序的典型數(shù)據(jù)流
攝取引入數(shù)據(jù),在倉(cāng)庫(kù)中進(jìn)行轉(zhuǎn)換,并將數(shù)據(jù)提供給下游應(yīng)用程序。
這三個(gè)階段構(gòu)成了用于分析系統(tǒng)的有用心理模型,但對(duì)業(yè)務(wù)來(lái)說(shuō)重要的是它們所支持的功能。數(shù)據(jù)編排有助于協(xié)調(diào)從源系統(tǒng)(可能是核心業(yè)務(wù)的一部分)獲取數(shù)據(jù)所需的流程,并將其轉(zhuǎn)化為數(shù)據(jù)產(chǎn)品。這些流程通常是異構(gòu)的,并且不一定是為了協(xié)同工作而構(gòu)建的。這可能會(huì)給協(xié)調(diào)器帶來(lái)很多責(zé)任,讓其負(fù)責(zé)制作副本、轉(zhuǎn)換格式和其他臨時(shí)活動(dòng)以將這些功能整合在一起。
工具
大多數(shù)數(shù)據(jù)系統(tǒng)的核心都依賴于一些調(diào)度功能。當(dāng)僅需要在可預(yù)測(cè)的基礎(chǔ)上管理有限數(shù)量的服務(wù)時(shí),常見(jiàn)的方法是使用簡(jiǎn)單的調(diào)度程序,例如cron.以這種方式協(xié)調(diào)的任務(wù)可以非常松散地耦合。在任務(wù)依賴性的情況下,可以直接安排一個(gè)任務(wù)在另一個(gè)任務(wù)預(yù)計(jì)完成后一段時(shí)間開(kāi)始,但結(jié)果可能對(duì)意外延遲和隱藏依賴性很敏感。
隨著流程變得越來(lái)越復(fù)雜,明確它們之間的依賴關(guān)系變得很有價(jià)值。這就是Apache Airflow等工作流引擎所提供的功能。 Airflow 和類(lèi)似的系統(tǒng)通常也被稱(chēng)為“編排器”,但正如我們將看到的,它們并不是唯一的編排方法。工作流引擎使數(shù)據(jù)工程師能夠指定任務(wù)之間的明確順序。它們支持運(yùn)行計(jì)劃任務(wù),并且還可以監(jiān)視應(yīng)觸發(fā)運(yùn)行的外部事件。除了使管道更加健壯之外,它們提供的依賴關(guān)系鳥(niǎo)瞰圖還可以提高可見(jiàn)性并實(shí)現(xiàn)更多治理控制。cron
有時(shí)“任務(wù)”的概念本身可能是有限制的。任務(wù)本質(zhì)上是對(duì)批量數(shù)據(jù)進(jìn)行操作,但流世界依賴于連續(xù)流動(dòng)的數(shù)據(jù)單元。許多現(xiàn)代流框架都是圍繞數(shù)據(jù)流模型構(gòu)建的——Apache Flink就是一個(gè)流行的例子。這種方法放棄了獨(dú)立任務(wù)的排序,有利于組合可以對(duì)任何大小的塊進(jìn)行操作的細(xì)粒度計(jì)算。
從編曲到作曲
這些系統(tǒng)之間的共同點(diǎn)是它們捕獲依賴關(guān)系,無(wú)論是隱式的還是顯式的、批處理的還是流式的。許多系統(tǒng)需要結(jié)合使用這些技術(shù),因此一致的數(shù)據(jù)編排模型應(yīng)該將它們?nèi)靠紤]在內(nèi)。這是由更廣泛的組合概念提供的,該概念捕獲了數(shù)據(jù)編排器今天所做的大部分工作,并擴(kuò)展了未來(lái)如何構(gòu)建這些系統(tǒng)的視野。
可組合數(shù)據(jù)系統(tǒng)
數(shù)據(jù)編排的未來(lái)正在轉(zhuǎn)向可組合的數(shù)據(jù)系統(tǒng)。編排器一直承擔(dān)著連接越來(lái)越多的系統(tǒng)的沉重負(fù)擔(dān),而這些系統(tǒng)從未被設(shè)計(jì)為相互交互。組織已經(jīng)建立了數(shù)量驚人的“粘合劑”來(lái)將這些流程粘合在一起。通過(guò)重新思考數(shù)據(jù)系統(tǒng)如何組合在一起的假設(shè),新方法可以大大簡(jiǎn)化其設(shè)計(jì)。
開(kāi)放標(biāo)準(zhǔn)
數(shù)據(jù)格式的開(kāi)放標(biāo)準(zhǔn)是可組合數(shù)據(jù)移動(dòng)的核心。Apache Parquet已成為列式數(shù)據(jù)事實(shí)上的文件格式,而Apache Arrow是其內(nèi)存中的對(duì)應(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ù)共享”,而無(wú)需所有粘合代碼。例如,攝取過(guò)程可能會(huì)將 Parquet 文件寫(xiě)入對(duì)象存儲(chǔ),然后簡(jiǎn)單地共享這些文件的路徑。然后,下游服務(wù)可以訪問(wèn)這些文件,而無(wú)需制作自己的內(nèi)部副本。如果工作負(fù)載需要與本地進(jìn)程或遠(yuǎn)程服務(wù)器共享數(shù)據(jù),它可以使用Arrow IPC或Arrow Flight,開(kāi)銷(xiāo)接近于零。
標(biāo)準(zhǔn)化正在堆棧的各個(gè)級(jí)別上進(jìn)行。Apache Iceberg和其他開(kāi)放表格式基于 Parquet 的成功,定義了用于組織文件的布局,以便將它們解釋為表。這為文件訪問(wèn)添加了微妙但重要的語(yǔ)義,可以將文件集合轉(zhuǎn)變?yōu)橛性瓌t的數(shù)據(jù)湖庫(kù)。加上一個(gè)目錄,比如最近孵化的Apache Polaris,組織擁有治理控制來(lái)構(gòu)建權(quán)威的事實(shí)來(lái)源,同時(shí)受益于底層格式支持的零拷貝共享。這種組合的力量怎么強(qiáng)調(diào)都不為過(guò)。當(dāng)業(yè)務(wù)的真實(shí)來(lái)源與生態(tài)系統(tǒng)的其他部分零復(fù)制兼容時(shí),只需共享數(shù)據(jù)即可實(shí)現(xiàn)很多編排,而不是構(gòu)建繁瑣的連接器流程。一旦數(shù)據(jù)以 Parquet 形式寫(xiě)入對(duì)象存儲(chǔ),無(wú)需任何轉(zhuǎn)換即可共享。
解構(gòu)堆棧
數(shù)據(jù)系統(tǒng)始終需要對(duì)文件、內(nèi)存和表格式做出假設(shè),但在大多數(shù)情況下,它們都隱藏在其實(shí)現(xiàn)的深處。用于與數(shù)據(jù)倉(cāng)庫(kù)或數(shù)據(jù)服務(wù)供應(yīng)商交互的狹窄 API 可以實(shí)現(xiàn)簡(jiǎn)潔的產(chǎn)品設(shè)計(jì),但它并不能最大化最終用戶可用的選擇??紤]圖 1 和圖 2,它們描述了旨在支持類(lèi)似業(yè)務(wù)功能的數(shù)據(jù)系統(tǒng)。
在封閉系統(tǒng)中,數(shù)據(jù)倉(cāng)庫(kù)內(nèi)部維護(hù)自己的表結(jié)構(gòu)和查詢引擎。這是一種一刀切的方法,可以輕松上手,但可能難以擴(kuò)展以滿足新的業(yè)務(wù)需求。鎖定可能很難避免,尤其是在涉及治理和其他訪問(wèn)數(shù)據(jù)的服務(wù)等功能時(shí)。云提供商在其生態(tài)系統(tǒng)內(nèi)提供無(wú)縫且高效的集成,因?yàn)樗鼈兊膬?nèi)部數(shù)據(jù)格式是一致的,但這可能會(huì)關(guān)閉在該環(huán)境之外采用更好產(chǎn)品的大門(mén)。相反,導(dǎo)出到外部提供商需要維護(hù)專(zhuān)為倉(cāng)庫(kù)專(zhuān)有 API 構(gòu)建的連接器,并且可能導(dǎo)致數(shù)據(jù)跨系統(tǒng)蔓延。
開(kāi)放的、解構(gòu)的系統(tǒng)標(biāo)準(zhǔn)化了其最低級(jí)別的細(xì)節(jié)。這使得企業(yè)能夠挑選最佳的服務(wù)供應(yīng)商,同時(shí)獲得以前只能在封閉的生態(tài)系統(tǒng)中才能實(shí)現(xiàn)的無(wú)縫體驗(yàn)。在實(shí)踐中,開(kāi)放數(shù)據(jù)系統(tǒng)的主要關(guān)注點(diǎn)是首先將源數(shù)據(jù)復(fù)制、轉(zhuǎn)換并轉(zhuǎn)化為開(kāi)放表格式。完成此操作后,可以通過(guò)共享對(duì)僅寫(xiě)入組織事實(shí)來(lái)源一次的數(shù)據(jù)的引用來(lái)實(shí)現(xiàn)許多編排。正是這種在各個(gè)層面共享數(shù)據(jù)的趨勢(shì),促使組織重新思考數(shù)據(jù)的編排方式并構(gòu)建未來(lái)的數(shù)據(jù)產(chǎn)品。
結(jié)論
編排是現(xiàn)代數(shù)據(jù)系統(tǒng)的支柱。在許多企業(yè)中,它是負(fù)責(zé)理清復(fù)雜且相互關(guān)聯(lián)的流程的核心技術(shù),但開(kāi)放標(biāo)準(zhǔn)的新趨勢(shì)為如何協(xié)調(diào)這些依賴關(guān)系提供了新的視角。系統(tǒng)不是從頭開(kāi)始構(gòu)建以協(xié)作共享數(shù)據(jù),而是將更大的復(fù)雜性推入編排層。云提供商一直在增加與這些標(biāo)準(zhǔn)的兼容性,這有助于為未來(lái)的最佳解決方案鋪平道路。通過(guò)采用可組合性,組織可以簡(jiǎn)化治理并從行業(yè)中發(fā)生的最偉大進(jìn)步中受益。