在過去 30 年中，敏捷開發方法在世界正在經歷的數位轉型中發揮了重要作用。此方法的基礎是能夠使用從構思到使用者回饋的盡可能短的回饋循環來快速迭代產品功能。這個簡短的回饋循環使我們能夠開發正確的軟體解決方案來滿足用戶的需求。
允許這種短反饋循環的工程基礎
設施基於來源版本控制，從而實現協作和可測試性。除了確保在整個過程中維護高品質軟體的測試平台之外，它還可以整合到允許CI/CD （寫入-審核-發布）的自動化伺服器。程式碼版本控制的另一個關鍵部分是在出現品質問題時回滾生產程式碼的能力，這可以大大降低錯誤成本以及對最終用戶的潛在影響。
資料管道的通用工具堆疊
但是當我們的應用程式是資料密集型時會發生什麼？我們可以將這種方法和工具堆疊用於我們的資料管道嗎？我們是否想要應用已被有 俄羅斯 WhatsApp 號碼數據 效證明適用於應用程式開發的相同最佳實踐？如果是這樣，我們該怎麼做？
我相信我們確實需要遵循這些最佳實踐
因為透過這樣做，我們將獲得快速行動和低錯誤成本的相同優勢。
為什麼數據工程落後於工程最佳實務？
我們都非常希望生活在一個更新資料管道並繼續下一個任務的世界，因為我們知道一切都會順利進行。
事實上，這始終是一場消防演習。
資料管道已準備就緒
顯然，這不是資料工程師本身的原因，而是有一些深刻的歷史原因。
讓我們回到過去。
最初有關係資料庫，生活 印度的數位行銷市場預計將達 相當簡單，因為資料很小且事物變化相當緩慢。
收集更多數據的更大組織將資料倉儲推向世界。這些仍然是關係資料庫，但更好，並且適應商業智慧用例。
但數據不斷增長，對分散式系
統來處理數據的需求變得迫在眉睫。我們必須改變基礎技術來應對資料量，這就是 Hadoop 生態系統的創建方式。
資料工程與分散式基礎設施緊密
結合，這與使用資料庫完全不同。
因此，當軟體開發正在建構 CI/CD 和品質保 迴聲資料庫 證工具時，資料工程卻在與資料規模作鬥爭，試圖改造基礎設施以交付資料。
由於數據規模龐大和現有基礎設
施的性質，向組織引入高品質數據成為一項挑戰。
我們花了大約 10 年的時間才真正馴服了Hadoop這頭猛獸，並實現了一個可擴展的、可管理的 Spark，它可以在任何組織中工作（謝謝Databricks！），或者使用分散式資料庫技術（謝謝你。如今，三大雲
端供應商為我們提供了開箱即
用的託管Spark，以及Presto和本土分散式資料庫（如 Snowflake 或BigQuery）。
現在我們已經達到了這種穩定性，我們正在展望未來，我們希望資料架構的基礎設施能夠允許資料可變性、規模、版本控制、可測試性和監控。這使我們資料工程師最終能夠達到與軟體工程師同事相同的目標：回饋循環短、品質高、開發速度快、錯誤成本低。