首先需要解決的重要的問題：數(shù)據(jù)工程和軟件工程之間有哪些不同之處？

二者非常相似，許多起源于軟件工程的最佳實踐對數(shù)據(jù)工程同樣有效，前提是需要正確地構(gòu)建它們。

在本文中，將詳細(xì)介紹幾個軟件工程的最佳實踐，以及如何更好地創(chuàng)建和維護(hù)數(shù)據(jù)管道。文中將特別關(guān)注管道，因為這是我們在Estuary關(guān)注的重點，這些原則同樣適用于大型數(shù)據(jù)堆棧。

本次討論將是在高層進(jìn)行，雖然我自己不是一個軟件工程師，但是希望你能從下屬原則中獲取到戰(zhàn)略和領(lǐng)導(dǎo)價值。

軟件工程與數(shù)據(jù)工程：相似之處和區(qū)別

數(shù)據(jù)產(chǎn)品和軟件產(chǎn)品是有區(qū)別的，其利益相關(guān)者各不相同。

通常，軟件產(chǎn)品的構(gòu)建涉及到高技術(shù)團(tuán)隊之間的協(xié)作，需要將產(chǎn)品交付給不同的用戶群體，通常是商業(yè)用途的用戶群體。例如，銀行可能會為其客戶創(chuàng)建一個移動應(yīng)用程序。

相比之下，數(shù)據(jù)產(chǎn)品往往駐留在企業(yè)的內(nèi)部，其利益相關(guān)者和參與者可以從高技術(shù)的工程師到需要利用數(shù)據(jù)來完成工作的非技術(shù)性專業(yè)人員。例如，同一家銀行可能為其客戶創(chuàng)建不同的財務(wù)和人口數(shù)據(jù)產(chǎn)品，以實現(xiàn)不同的安全、銷售和戰(zhàn)略功能。

在閱讀這篇文章過程中，讀者將在數(shù)據(jù)空間中徜徉，可能無需強(qiáng)調(diào)二者區(qū)別的細(xì)節(jié)，讀者僅需要從業(yè)務(wù)的角度，來審視數(shù)據(jù)與軟件的不同。

但是從本質(zhì)上來講，數(shù)據(jù)工程和軟件工程的實踐卻基本相同，比如可以編寫、維護(hù)和部署代碼來解決一個可重復(fù)的問題，正因如此，某些有價值的軟件工程最佳實踐可以轉(zhuǎn)換為數(shù)據(jù)工程最佳實踐，許多最新的數(shù)據(jù)趨勢——如數(shù)據(jù)網(wǎng)格和數(shù)據(jù)操作程序——以一種全新的方式實現(xiàn)了軟件工程實踐，并取得了良好的結(jié)果。

軟件工程與數(shù)據(jù)工程的歷史

通過查看歷史數(shù)據(jù)，理解為什么這些最佳數(shù)據(jù)實踐均來自于軟件工程，并了解為什么直到最近才將它們應(yīng)用到數(shù)據(jù)工程中的原因。

軟件工程學(xué)科在20世紀(jì)60年代首次得到認(rèn)可，當(dāng)時，“軟件創(chuàng)建是一種形式的工程”的想法是一種富有挑釁性的想法。事實上，選擇“軟件工程”這一詞的目的是鼓勵從業(yè)者停下來，將科學(xué)原理應(yīng)用到實際工作中去。在接下來的幾十年里，軟件工程師對科學(xué)和機(jī)械工程中的原理進(jìn)行了測試和改進(jìn)。

在20世紀(jì)90年代，隨著對軟件需求的日增，整個行業(yè)落后于日益增長的軟件需求，導(dǎo)致了所謂的“應(yīng)用程序開發(fā)危機(jī)”，這次危機(jī)促使軟件工程師采用敏捷開發(fā)和相關(guān)的實踐，它意味著需要優(yōu)先考慮快速的生命周期迭代，并對軟件背后的人文系統(tǒng)賦予價值。

眾所周知，數(shù)據(jù)工程是一個相對年輕的領(lǐng)域。雖然絕大多數(shù)人類歷史的數(shù)據(jù)都早已經(jīng)存在，但是關(guān)系型數(shù)據(jù)庫則是在20世紀(jì)70年代創(chuàng)建的。直到21世紀(jì)初，數(shù)據(jù)庫還只局限于小部分管理者，在IT領(lǐng)域，數(shù)據(jù)基礎(chǔ)設(shè)施通常作為一個具有許多組件的企業(yè)內(nèi)部資源，是一個相對較新的開發(fā)（毋庸諱言：是一個快速變化的開發(fā)）， “數(shù)據(jù)工程師”這個職位起源于二十一世紀(jì)一十年代。

總之，軟件工程師已經(jīng)工作了大約60年，他們今天仍然在做大致相似的工作，期間，他們解決了很多問題。數(shù)據(jù)工程領(lǐng)域可以利用軟件工程這一優(yōu)勢。

閑話少說，下文是一些可以（也應(yīng)該）應(yīng)用于數(shù)據(jù)管道的軟件工程最佳實踐。

1.設(shè)置（較短的）生命周期

軟件或數(shù)據(jù)產(chǎn)品的生命周期包括規(guī)劃、構(gòu)建、文檔化、測試、部署和維護(hù)在內(nèi)的周期性過程。

敏捷軟件開發(fā)通過縮短開發(fā)生命周期來滿足需求，與此同時，繼續(xù)進(jìn)行產(chǎn)品迭代和產(chǎn)品改進(jìn)。

同樣地，可以（也應(yīng)該）為數(shù)據(jù)管道實現(xiàn)一個快速的生命周期。

在整個組織中，對新數(shù)據(jù)產(chǎn)品的需求將迅速且頻繁地出現(xiàn)，應(yīng)為生命周期工作流中的全部環(huán)節(jié)，做好充分的準(zhǔn)備。

• 計劃：與利益相關(guān)者一起制定計劃，以確保管道能夠交付所需的產(chǎn)品。
• 構(gòu)建：構(gòu)建管道，根據(jù)不同的平臺和接口，編寫規(guī)范或創(chuàng)建DAG。
• 文檔化：記錄管道，包括模式、元數(shù)據(jù)或書面文檔（dbt docs 是一個不錯的例子，盡管在數(shù)據(jù)堆棧的不同部分有不同的dbt docs 文檔）。
• 測試：在部署之前測試管道——管道工具可能有內(nèi)置的測試，也可以編寫自己的測試。
• 部署：部署管道。
• 監(jiān)控：查看錯誤報警并進(jìn)行更新。
• 迭代：當(dāng)用例變更時快速迭代，繼續(xù)在先前的管道上構(gòu)建并回收組件。

將敏捷開發(fā)方法集成到數(shù)據(jù)中的概念是DataOps框架的一個重要組成部分，參看我關(guān)于這個主題的全文。

2.選擇正確的抽象層次

為確保數(shù)據(jù)生命周期更加緊湊，不要迷失在技術(shù)實現(xiàn)細(xì)節(jié)中，這一點非常重要，需要對技術(shù)具體實現(xiàn)細(xì)節(jié)進(jìn)行抽象。

軟件工程師對抽象的概念感覺良好，抽象是將信息簡化為更一般的對象或系統(tǒng)，也可以將其視為泛化或建模。

在軟件工程中，相關(guān)的抽象層次通常存在于代碼的內(nèi)部。例如，函數(shù)或面向?qū)ο蟮木幊陶Z言是有用的工具，但它們并沒有揭示如何去執(zhí)行這些細(xì)節(jié)。

在數(shù)據(jù)中，需要使用一個高于代碼的抽象層級，主要有以下兩個原因：

• 數(shù)據(jù)產(chǎn)品和它們提供的業(yè)務(wù)用例之間相互關(guān)聯(lián)，這意味著需要用更“現(xiàn)實”的術(shù)語來談?wù)摂?shù)據(jù)。明確這一級別的抽象意味著需要建立一個通用語義層——并有助于避免在不同的BI工具和用戶組中出現(xiàn)多個相互沖突的語義層。
• 在數(shù)據(jù)涉眾中發(fā)現(xiàn)更廣泛的技術(shù)級別，這意味著談?wù)撘恍┘夹g(shù)性比較強(qiáng)的東西（比如代碼）時，并不是非常適用。

對于數(shù)據(jù)管道來說，兩個相關(guān)的抽象是：從一個系統(tǒng)攝取數(shù)據(jù)并將其推送到另一個系統(tǒng)的行為（在Estuary中使用術(shù)語捕獲和物化，但二者語義會有所不同）。

當(dāng)談?wù)撌褂?“捕獲”和“物化”這樣的術(shù)語時，無論是工程師還是業(yè)務(wù)用戶都需要將管道的語義價值統(tǒng)一起來（從系統(tǒng)X中獲取數(shù)據(jù)推送到系統(tǒng)Y，這樣便可以實現(xiàn)Z）。

3.創(chuàng)建聲明式數(shù)據(jù)產(chǎn)品

理解上述意思之后，便抓住了重點，但這也僅僅是抽象討論的延續(xù)，下面進(jìn)行更多實質(zhì)性的討論。

首先考慮將數(shù)據(jù)視為一個產(chǎn)品，這是當(dāng)下流行的數(shù)據(jù)網(wǎng)格框架的一個核心準(zhǔn)則。

數(shù)據(jù)即產(chǎn)品屬于公司內(nèi)部的不同領(lǐng)域：擁有不同技能的團(tuán)隊，共享數(shù)據(jù)的操作用例。數(shù)據(jù)即產(chǎn)品可以快速轉(zhuǎn)換為多種形式的可交付成果，這些成果全部是由用例來驅(qū)動的。換句話說：它們關(guān)乎“做什么”，而非“如何做”。

軟件工程與聲明式編程并行，聲明式編程關(guān)注的是程序可以“做什么”，這與命令式編程恰恰相反，命令式編程關(guān)乎任務(wù)應(yīng)該“如何做”。

聲明式編程是建立在命令式編程之上的一種抽象程序：在運行時，程序經(jīng)過編譯之后，才能解決“如何做”的問題。聲明性編程允許在運行時具備更大的靈活性，從而節(jié)省了資源。此外，聲明性編程更容易控制，同時也更加容易實現(xiàn)。

使管道具有可聲明性：首先在管道的功能基礎(chǔ)上進(jìn)行構(gòu)建，而非根據(jù)管道的機(jī)制進(jìn)行構(gòu)建，從而能夠更好地支持“數(shù)據(jù)即產(chǎn)品”的文化理念。

項目將從管道所要交付的產(chǎn)品開始，比如說，一個特定的實例化視圖，并在此基礎(chǔ)上設(shè)計管道，聲明式管道方法確保不會迷失在技術(shù)細(xì)節(jié)中，忽略了數(shù)據(jù)的業(yè)務(wù)價值。

4.預(yù)防失效

在軟件開發(fā)和數(shù)據(jù)管道中，失效不可避免。很多人都從失效中吸取過教訓(xùn)：努力修復(fù)災(zāi)難性的系統(tǒng)損壞，避免因中斷而失去進(jìn)度或數(shù)據(jù)，或者避免將一個低級錯誤放大。

無論在軟件還是數(shù)據(jù)語境的應(yīng)用中，都可以利用類似的預(yù)防性備份措施來預(yù)防失效的發(fā)生。

為此需要添加一些重要的考量，管道供貨商會提供數(shù)據(jù)編排工具來實現(xiàn)這些功能。

測試

正如軟件工程一樣，測試是管道生命周期的一部分。

除了在部署前進(jìn)行全面的手動測試之外，還應(yīng)該編寫自動化的單元測試，以密切關(guān)注量產(chǎn)中的管道。

如何編寫這些測試內(nèi)容取決于平臺的種類以及如何與之交互。例如，如果需要在管道中使用Airflow，那么可以創(chuàng)建Python腳本來測試它們?；蛘?，可能更偏向用一個更健壯的監(jiān)控設(shè)置來捕獲潛在的問題。

根據(jù)經(jīng)驗法則，數(shù)據(jù)管道應(yīng)用的轉(zhuǎn)換越多，需要的測試就越多。

版本控制

軟件工程師使用版本控制，通常是用Git來協(xié)同工作，并保留將軟件回滾到先前版本的能力。

如果使用的是來自供應(yīng)商的產(chǎn)品，它可能會提供GitOps工作流，這意味著工程師可以使用Git在他們首選的開發(fā)環(huán)境中進(jìn)行管道協(xié)作。然而，并不是所有人都這么做。

即使無法在數(shù)據(jù)基礎(chǔ)設(shè)施中使用Git，供應(yīng)商也會啟用一些選項來備份管道，所以一定要充分利用該功能。

分布儲存及回填能力

云托管和存儲技術(shù)的出現(xiàn)降低了數(shù)據(jù)中斷和數(shù)據(jù)丟失的風(fēng)險，但它并沒有完全消除這些風(fēng)險。

數(shù)據(jù)基礎(chǔ)設(shè)施應(yīng)該選用分布式的，也就是說，不同的組件應(yīng)分布到不同的服務(wù)器上，從而使其能夠容錯。對風(fēng)險的控制程度取決于云提供商及其所選定供應(yīng)商。

始終迭代

軟件工程最佳實踐的最后一條策略是：當(dāng)某些例程不工作時，就進(jìn)行迭代。

現(xiàn)狀和最佳實踐總是在不斷的變化之中，這既適用于軟件工程，也適用于數(shù)據(jù)工程。

最好的方法總是要經(jīng)過深思熟慮，安全地引入變革，并得到所有利益相關(guān)者的支持。

從上述這些原則開始，通過相互間的合作配合，適配數(shù)據(jù)團(tuán)隊的系統(tǒng)和文化。始終關(guān)注那些積極的影響和需要改進(jìn)的領(lǐng)域，并從那里開始行動。

本文改編自Estuary的博客，可以通過 LinkedIn找到我們的團(tuán)隊，可以在GitHub上獲取到源代碼。

衷心感謝 Ben Huberman的大力支持