SoundCloud 以六項原則的資料治理，取代 100 條沒有文件記錄的 ETL

到了 2019 年中，SoundCloud 的資料倉儲已累積了六年的決策，而這些決策早已不再合理：一個小型團隊獨自掌管 Amazon Redshift 上超過 100 條 ETL 管線，其中多數幾乎沒有文件記錄，彼此之間也不一致，導致業務與產品團隊無法可靠地自助取用資料。一份遷移到 Google BigQuery 的合約，給了團隊重新來過的契機，但早在 2018 年初的一次「直接搬遷」（lift and shift）遷移嘗試，就已經被中止過一次。

新的 Data Corpus 團隊在重建資料表之前，先寫下了一份使命宣言與六項治理原則：品質、合規、時效、易用、效率、可維護性，改編自一項 ISO 標準。品質指的是有一套工具，能將新版 ETL 與已部署版本進行比對，讓只有預期的變更顯現出來。時效指的是繪製每一條 ETL 及其相依項目的落地時間；將一張必要的資料表與另一張不相關、速度較慢的資料表解耦，讓整條管線縮短了四小時。可維護性指的是一項「80% 原則」：為大多數請求而建，而非為邊緣案例而建。

重建是分階段進行的：2019 年 12 月的中間版 Corpus 發布時仍從舊倉儲讀取資料；2020 年 4 月的 Corpus Alpha 是第一個完全獨立於舊倉儲的版本；2020 年 7 月的 Corpus 1.0 則是第一個滿足全部六項原則的版本。到了 2021 年 4 月的 Corpus 2.2，最終的 BigQuery 專案所使用的儲存空間，比它所讀取的原始資料少了約 90%，而具備基本 SQL 能力的利害關係人，也能透過有文件記錄、有說明的資料表，自助解答大多數問題。

在寫下第一張資料表之前，先寫下治理原則

自動化的版本比對，把「這次變更是否破壞了下游的某些東西」從一個程式碼審查的判斷問題，變成每次 ETL 更新都會執行的一項機械化檢查。

80% 原則讓團隊在範圍蔓延的爭論中有一個固定的答案，因此資料表得以保持簡單，讓非專家也能查詢，而不會累積邊緣案例的複雜度。

繪製 ETL 相依關係與落地時間，把含糊的「資料有時會延遲」抱怨，轉化為具體的修正：將兩張資料表解耦，並測得四小時的改善。

在大約 18 個月內分階段發布版本，每個版本都以同樣的六項原則來評判，讓團隊能在做出最難逆轉的設計決策之前，先學會 BigQuery 的各項功能。

當你要遷移一個在缺乏文件記錄的情況下成長起來的系統時，先寫下能防止新系統以同樣方式腐化的原則，然後把每一項原則變成自動化檢查，而不是無人執行的指導方針。

SoundCloud 在 2.2 之後持續發布更多 Corpus 版本，隨著產品演進擴充資料表的涵蓋範圍，而不是把治理模型當成一次性的遷移交付項目。團隊將 Corpus 定位為一個持續演進的專案，並明確預期目前的設計終究會看起來和遷移前的倉儲一樣過時，同時保留同樣的原則，作為決定何時該改變的常設框架。