SoundCloud用六项原则的数据治理取代了100个无文档的ETL

到2019年年中，SoundCloud的数据仓库已是六年决策的产物，其中许多决策已不再合理：一个规模很小的团队在Amazon Redshift上拥有100多条ETL管道，其中大多数几乎没有文档，且彼此之间存在不一致，导致业务和产品团队无法可靠地自助获取数据。一份迁移到Google BigQuery的合同给了团队重新开始的理由，但早在2018年初的一次“直接迁移”尝试此前已被中止过一次。

新的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视为一个持续演进的项目，并明确预期当前设计最终会像迁移前的仓库一样显得过时，同时保留同样的原则作为决定何时更改的常设框架。