GoCardless 的 ETL 方法侧重于将数据视为 API，避开已经开始巩固的行业标准 ELT 现代数据仓库方法。
上游数据质量挑战
在上游遛弯时发现，工程师在修改服务时没有意识到像删除字段这样简单的事情可能会对下游的仪表板（或其他消费者）产生重大影响。
部分挑战是数据是事后才想到的，但部分挑战还在于我们最关键的数据是通过CDC，直接获取自我们服务的数据库。
在加载数据后投资于代码和工具来转换数据的问题在于，当数据表结构或数据Schema发生变化时，这些努力要么失去价值，要么需要重新设计。
所以有两个问题需要解决。在流程方面，数据需要在上游服务更新期间成为一等公民，包括主动下游通信。在技术方面，我们需要一种自助服务机制来提供容量并授权团队定义应如何摄取数据。
幸运的是，软件工程师很早就用API的概念解决了这个问题。这些本质上是带有文档和版本控制的合同，允许消费者依赖服务而不用担心它会在没有警告的情况下更改并对他们的工作产生负面影响。
在 GoCardless，我们相信数据合约可以达到这个目的，但与任何重大计划一样，首先从工程团队那里收集需求是很重要的（也许也有一些销售）。
与团队交谈
我们开始与公司的每个工程团队交谈。我们会解释什么是数据合约，赞美它们的好处，并征求对设计的反馈。
我们得到了一些很棒的、可操作的反馈。
例如，大多数团队不想使用 AVRO，所以我们决定使用 JSON 作为合同的交换格式，因为它是可扩展的。隐私和安全团队通过设计帮助我们建立隐私，特别是围绕数据处理和分类哪个实体拥有哪个数据资产。
我们还发现这些团队有广泛的用例，并希望确保工具足够灵活。事实上，他们真正想要的是自主权。
在我们之前的设置中，一旦数据从 CDC 进入数据仓库，数据工程师将拥有该数据以及支持下游服务所需的一切。当这些团队想要授予服务访问 BigQuery 或更改他们的数据时，他们需要通过我们。
这不仅是有用的反馈，而且成为数据合约模型的关键卖点。合同制定后，他们可以从一系列工具中进行选择，而不必遵循我们对数据结构的看法，并真正控制自己的命运。
数据合同过程完全是自助的。首先是数据团队使用Jsonnet来定义他们的模式、对数据进行分类并选择他们的服务需求。将 Json 文件合并到 Github 中后，会自动部署专用的BigQuery和PubSub资源，并通过 Kubernetes 集群填充请求的数据。
该过程旨在完全自动化和分散。这最大限度地减少了团队之间的依赖关系，因此如果一个服务需要增加一个服务的工作人员，它不会影响另一个团队的性能。
内部风险部门是最早使用新系统的团队之一。他们使用不同功能的数据来识别和降低潜在欺诈行为的风险。以前，他们利用生产数据库中的数据只是因为它在那里。现在，他们在 BigQuery 中拥有了可直接管理的更具可扩展性的环境。
在撰写本文时，我们已经进行了 6 个月的初步实施，并对势头和进展感到兴奋。已经部署了大约 30 种不同的数据合约，它们现在为大约 60% 的异步服务间通信事件提供动力。
我们与分析和数据科学团队等传统数据消费者合作取得了稳步进展，并计划在明年某个时候停用我们的 CDC 管道时帮助他们迁移到该系统。
最重要的是，我们的数据质量已经开始提高，我们看到了一些很好的例子，消费者和生成者一起工作来设定数据要求——这在以前很少发生。
学习到什么
那么，我们学到了什么？
- 数据合同一旦确定就不会有太多的修改。这类方法的一个担心是，会有大量的前期工作来定义模式，而这些模式无论如何都会改变。而ETL的好处是，数据可以被快速地重新安排和转换，以适应这些新的需求，而我们的方法需要更多的变化管理。然而，我们发现，在我们目前的用户群中，他们的需求并不经常变化。这是一个重要的发现，因为目前即使是一个模式的改变也需要一个新的合同，并提供一套新的基础设施，这就造成了选择绿地或迁移旧环境的问题。
- 让自我服务变得简单：旧的习惯是很难改变的，抗拒改变是人类的天性。即使你承诺提高数据质量，当涉及到数据，尤其是关键数据时，人们往往（可以理解为）厌恶风险。这就是我们使我们的自助服务流程尽可能简单和自动化的原因之一。它消除了瓶颈，并提供了另一种激励--自主权。
- 在变革时期引入数据合同。这可能是反直觉的，因为你可能认为组织一次只能消化这么多变化。但是，当团队需要新的数据流，而不是试图迁移已经在生产中的服务时，我们最好的采用方式是。数据合同对于分散的数据团队来说也是一个很好的系统，所以如果你的团队正在追求任何类型的数据网格化倡议，这是一个理想的时间，以确保数据合同是它的一部分。
- 路演的帮助。为客户着迷是如此重要，几乎是老生常谈。这对内部消费者来说也是如此。从其他数据工程团队获得反馈并了解他们的使用情况对于成功至关重要。另外，在他们开始与我们进行头脑风暴的那一刻，他们就已经接受了。
- 从一开始就进行分类和治理，但要开始行动。确保我们从一开始就有正确的数据所有权和分类，可以避免很多潜在的混乱的复杂情况。虽然将不同类别和类型的初始数据合同模板放在一起，一开始可能会令人生畏，但一旦我们开始进行路演，这就变成了一个相对简单的任务。
- Interservices是伟大的早期采用者，对迭代有帮助。拥有需要由其他服务驱动的服务的团队是我们最大的采用者。他们对数据的可靠性、及时性和高质量的需求最大。虽然分析和数据科学消费者的进展较慢，但我们已经建立了势头，并通过关注早期采用者来迭代这一过程。
- 拥有正确的基础设施。简单地说，这是在GoCardless签订数据合同的正确时机。我们已经完成了一项倡议，将所有必要的基础设施到位，我们的数据集中在BigQuery中。利用outbox模式和PubSub也很重要，可以确保我们的服务对服务的通信得到备份，并与生产数据库脱钩。
权衡
没有一种数据工程方法是不需要权衡的。在追求这个数据合同战略的过程中，我们做了几个深思熟虑的决定，包括。
- 速度与蔓延。我们正在密切关注这个系统的使用情况，但通过优先考虑速度和授权分散的团队提供他们自己的基础设施，有可能出现蔓延的情况。我们将根据需要减轻这种风险，但我们认为，与以前团队被迫使用经常变化的生产数据的状态相比，这是一个较小的罪恶。
- 承诺与变化。自助服务很容易，但数据合同流程和合同本身是为数据消费者设计的，以仔细考虑他们当前和未来的需求。改变合同的过程是有意为之的，以反映双方在维护该合同方面的投资和承诺。
- 将所有权推向上游和跨领域。我们正在消除自己作为数据生成者和数据消费者之间的瓶颈和中间人。这种方法并没有改变影响数据质量的核心事件集。实施服务仍然需要被修改，这些修改仍然会对下游产生影响。但是，改变的是这些合同已经把沟通和引导这些挑战的责任转移到了服务所有者身上，他们现在知道应该与哪些团队协调哪些数据资产。