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

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

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

本次討論將是在高層進行，雖然我自己不是一個軟件工程師，但是希望你能從下屬原則中獲取到戰略和領導價值。

軟件工程與數據工程：相似之處和區別

數據產品和軟件產品是有區別的，其利益相關者各不相同。

通常，軟件產品的構建涉及到高技術團隊之間的協作，需要將產品交付給不同的用戶群體，通常是商業用途的用戶群體。例如，銀行可能會為其客戶創建一個移動應用程序。

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

在閱讀這篇文章過程中，讀者將在數據空間中徜徉，可能無需強調二者區別的細節，讀者僅需要從業務的角度，來審視數據與軟件的不同。

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

軟件工程與數據工程的歷史

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

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

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

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

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

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

1.設置（較短的）生命周期

軟件或數據產品的生命周期包括規劃、構建、文檔化、測試、部署和維護在內的周期性過程。

敏捷軟件開發通過縮短開發生命周期來滿足需求，與此同時，繼續進行產品迭代和產品改進。

同樣地，可以（也應該）為數據管道實現一個快速的生命周期。

在整個組織中，對新數據產品的需求將迅速且頻繁地出現，應為生命周期工作流中的全部環節，做好充分的準備。

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

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

2.選擇正確的抽象層次

為確保數據生命周期更加緊湊，不要迷失在技術實現細節中，這一點非常重要，需要對技術具體實現細節進行抽象。

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

在軟件工程中，相關的抽象層次通常存在于代碼的內部。例如，函數或面向對象的編程語言是有用的工具，但它們并沒有揭示如何去執行這些細節。

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

• 數據產品和它們提供的業務用例之間相互關聯，這意味著需要用更“現實”的術語來談論數據。明確這一級別的抽象意味著需要建立一個通用語義層——并有助于避免在不同的BI工具和用戶組中出現多個相互沖突的語義層。
• 在數據涉眾中發現更廣泛的技術級別，這意味著談論一些技術性比較強的東西（比如代碼）時，并不是非常適用。

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

當談論使用 “捕獲”和“物化”這樣的術語時，無論是工程師還是業務用戶都需要將管道的語義價值統一起來（從系統X中獲取數據推送到系統Y，這樣便可以實現Z）。

3.創建聲明式數據產品

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

首先考慮將數據視為一個產品，這是當下流行的數據網格框架的一個核心準則。

數據即產品屬于公司內部的不同領域：擁有不同技能的團隊，共享數據的操作用例。數據即產品可以快速轉換為多種形式的可交付成果，這些成果全部是由用例來驅動的。換句話說：它們關乎“做什么”，而非“如何做”。

軟件工程與聲明式編程并行，聲明式編程關注的是程序可以“做什么”，這與命令式編程恰恰相反，命令式編程關乎任務應該“如何做”。

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

使管道具有可聲明性：首先在管道的功能基礎上進行構建，而非根據管道的機制進行構建，從而能夠更好地支持“數據即產品”的文化理念。

項目將從管道所要交付的產品開始，比如說，一個特定的實例化視圖，并在此基礎上設計管道，聲明式管道方法確保不會迷失在技術細節中，忽略了數據的業務價值。

4.預防失效

在軟件開發和數據管道中，失效不可避免。很多人都從失效中吸取過教訓：努力修復災難性的系統損壞，避免因中斷而失去進度或數據，或者避免將一個低級錯誤放大。

無論在軟件還是數據語境的應用中，都可以利用類似的預防性備份措施來預防失效的發生。

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

測試

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

除了在部署前進行全面的手動測試之外，還應該編寫自動化的單元測試，以密切關注量產中的管道。

如何編寫這些測試內容取決于平臺的種類以及如何與之交互。例如，如果需要在管道中使用Airflow，那么可以創建Python腳本來測試它們?；蛘撸赡芨蛴靡粋€更健壯的監控設置來捕獲潛在的問題。

根據經驗法則，數據管道應用的轉換越多，需要的測試就越多。

版本控制

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

如果使用的是來自供應商的產品，它可能會提供GitOps工作流，這意味著工程師可以使用Git在他們首選的開發環境中進行管道協作。然而，并不是所有人都這么做。

即使無法在數據基礎設施中使用Git，供應商也會啟用一些選項來備份管道，所以一定要充分利用該功能。

分布儲存及回填能力

云托管和存儲技術的出現降低了數據中斷和數據丟失的風險，但它并沒有完全消除這些風險。

數據基礎設施應該選用分布式的，也就是說，不同的組件應分布到不同的服務器上，從而使其能夠容錯。對風險的控制程度取決于云提供商及其所選定供應商。

始終迭代

軟件工程最佳實踐的最后一條策略是：當某些例程不工作時，就進行迭代。

現狀和最佳實踐總是在不斷的變化之中，這既適用于軟件工程，也適用于數據工程。

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

從上述這些原則開始，通過相互間的合作配合，適配數據團隊的系統和文化。始終關注那些積極的影響和需要改進的領域，并從那里開始行動。

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

衷心感謝 Ben Huberman的大力支持