不曉得大家有沒有遇過一種情況：下游 Dashboard 的指標出現錯誤。從 Dashboard 的業務同仁反映起，依序經過 BI Team 對商業邏輯的確認，再回報給 Data Team 針對資料匯入 (extraction) 的正確性檢查仍然沒有發現問題，最後回報給資料來源的後端工程師，盤查後發現是工程師對後端微服務 (microservice) 進行更改所致。
對於後端工程師來說，這是一個小 bug，可以在 5 分鐘內修改完成。對於資料團隊來說，這可能需要好幾個工作天才能發現。雖然 Dashboard 順利修復了，但團隊之間的信賴感能否順利修復，是一個問號。
雖然 Day 22 我們曾經介紹 Schema Registry 和 AVRO 這些可以幫助資料格式管理的工具。但是最根本的問題仍然是，隨著企業規模擴張帶來的資料量級提升及團隊人數擴大，不得不進行專業職能分工。分工後雖然讓特定職能的人員能夠發揮自己的優勢技能，但切割後的小團隊彼此溝通的屏障也變高了，降低溝通成本和提升小團隊之間的信賴感變成新世代課題。
Bryan Offutt 在 2021 年的文章提到一個資料團隊和軟體團隊最大的差異：認同 (buy in)，更直白的說法叫做買單。
好比技術債這個詞，對於軟體開發人員甚至非工程人員大多都能理解，也認同它對軟體應用產出的成效長期以來會減緩。資料世界裡也有對應的技術債，例如 Day 24 提的資料品質，包含屬性資料不齊全、歷史資料未回補、同一指標在不同 pipeline 定義不統合等。但因為資料需求者對於資料加值應用的期待感高，無法耐心接受資料團隊提出的中長期計畫，包含系統可擴張性 (scalability) 與效率提升 (efficiency)。
這種急切感蓋過了對資料工程技術債的理解，往往讓資料交付時程被壓縮，導致資料系統穩定性被犧牲，長期下來對於需求的反映速度大幅減緩，無法在期待的時間內滿足需求的情況就演變成彼此的信賴感下滑。
這是一種很常見的資料團隊組建模式，我所待過的資料團隊也大部分是這樣。例如在行銷媒合平台，Data Team 要介接的資料源就有媒合產品本身、廣告主客戶管理端、社群行銷端等；在電商平台就有顧客、金流、物流、訂單、倉儲等多元性質的資料。
雖然掌握資料工程的技術與架構，例如 Day 23 基礎建設篇裡面提過的資料處理技術，就具備搭建衍生資料系統的一定能力了。但是這些來自不同微服務的資料所蘊含的領域知識，資料團隊真的可以完全不瞭解嗎？若要瞭解，要捨棄多少的技術開發時間呢？
圖／產品發展曲線。Source: https://dri.es/optimizing-your-product-strategy-for-the-short-and-long-term
在商業發展的初期，還沒找到產品與市場配適 (product-market fit) 時，可能根本沒有機會組建資料團隊，縱使高層意識到使用資料的好處時，資料團隊的規模也大不起來，就由少數幾個資料專業職能的人一條龍式的扛起所有資料任務。
企業發展到了一個層級，這種集中式模式會讓資料團隊持續在「多打一」的情況下疲於奔命，無法有充足的時間讓衍生資料系統更穩定，光是處理資料需求和資料品質就應接不暇了。
Data Mesh 是一種去中心化的資料團隊組建模式，將資料的所有權和責任分散到各個業務團隊。這些業務團隊不僅負責他們所產生的資料，也需要確保資料品質、可用性和共享性。這種架構鼓勵如 Day 25 所提的資料即產品 (DaaP) 理念，每個團隊都有自己的 Data Product Owner。
要排除集中式團隊帶來的困擾，有兩個關鍵因子需要納入模式：
在集中式資料團隊模式下，業務團隊要理解到技術債不只對軟體團隊有長遠影響，對資料團隊亦同。重新排序需求，讓過去總是「即刻滿足」的資料需求開始有優先級，讓資料團隊能有一定時間做系統穩定性的提升。
資料團隊的組建模式和企業發展階段息息相關。隨著企業組織日漸複雜，資料團隊可以著手準備自助式工具的推廣以及資料接口標準協議的制定，讓「資料思維」能夠漸漸深入各業務團隊，讓業務部門不再只是把資料需求變成一種跨部門的「索求」。
iThome鐵人賽
看影片追技術