當公司規模快速成長，數據工程面臨的最大挑戰通常不是技術工具，而是治理。英國數位銀行 Monzo 面臨的就是這種規模化痛點：超過 100 個獨立團隊共同維護一個擁有 12,000 個 dbt 模型的數據倉庫。
對於不熟悉 dbt 的工程師來說，dbt（data build tool）是一種將 SQL 查詢模組化、可複用的工具，它讓數據工程師能像寫程式碼一樣管理數據轉換流程（Data Pipeline），將原始數據轉化為結構化的數據集。但在極大規模的環境下，如果缺乏規範，這種分佈式開發會導致嚴重的重複計算、命名混亂以及數據品質下降，最終反映在雲端數據倉庫（Data Warehouse）昂貴的帳單上。
為了克服這個問題，Monzo 採取了一種稱為 Meshy 的治理方法，核心目標是將數據所有權分佈給各個團隊，但同時建立強制的自動化護欄。
數據層級的標準化定義
Monzo 意識到，如果每個人隨意定義數據模型，系統會迅速崩潰。因此他們將數據模型嚴格分為四個層級，明確定義每一層的職責：
第一層是自動化落地層（Automated Landing Models），負責將原始事件數據扁平化。 第二層是正規化模型層（Generated Normalized Models），用來代表具有完整歷史紀錄的實體（Entities）。 第三層是邏輯模型層（Logical Models），將不同實體結合，並在此層注入業務邏輯。 第四層是呈現模型層（Presentation Models），針對特定的下游應用或報表需求進行量身定制。
這種分層設計解決了數據重複定義的問題，確保同一項業務邏輯在整個組織中只有一個正確的來源。
將數據接口視為一等公民
在許多公司，團隊之間共享數據往往依賴於口頭溝通或維護困難的文檔。Monzo 採取了更激進的做法：將數據接口（Interface Models）正式化。
他們要求跨團隊依賴的數據必須透過明確宣告的接口模型來傳遞。這意味著數據接口被視為如同 API 一樣的程式碼，必須定義清楚、版本管理並經過驗證。這種做法將數據依賴關係透明化，避免了因為上游隨意修改欄位而導致下游報表崩潰的慘劇。
自動化護欄與 CI 驗證
為了確保 100 多個團隊在 AI 輔助編碼（如 GitHub Copilot）普及的時代仍能維持品質，Monzo 捨棄了耗時的人工審核，轉而依賴 CI（Continuous Integration，持續整合）自動化檢查。
他們開發了一個名為 Modelgen 的命令列工具，讓工程師能透過定義對象來自動生成 SQL 和 YAML 模型，從根源上消除命名不一致的問題。同時，所有提交到數據倉庫的模型必須通過 CI 驗證，滿足以下硬性指標： 必須定義唯一鍵（Unique Key）以確保數據不重複。 必須包含新鮮度測試（Freshness Tests）以監控數據是否及時更新。 預設必須使用增量更新（Incremental Run）以減少計算資源浪費。 必須明確宣告所屬團隊、提供文件並符合命名規範。
實務影響與成效
透過將數據治理直接寫入 CI 流程，Monzo 成功將數據治理從口頭承諾變成了強制執行。目前該計畫已完成約 30% 的遷移，初步成效非常顯著：部分領域的數據倉庫成本降低了約 40%，數據落地的速度提升了 25%。
這對工程實務的啟示在於，當數據規模達到一定程度時，單靠文檔和信任是不足夠的。唯有將數據標準轉化為自動化工具與 CI 檢查，才能在維持團隊開發自主性的同時，兼顧系統的穩定性與成本控制。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。