减少传统数据湖带来的混乱，Intuit 如何构建数据网格策略？

 Intuit 的使命是“促进全球繁荣”。Intuit 实现这一使命的策略是成为一个“AI驱动的专家平台”。我在 Intuit 的数据平台团队中工作，我们团队在提供实现这一目标所需的解决方案方面发挥着关键作用。我们团队的内部客户包括多个 Intuit 团队，他们负责构建各种产品和服务，以促进 Intuit 的消费者、小型企业和自由职业者的事业发展。

我的同事，数据平台 Intuit 副总裁 Mammad Zadeh 最近发表了一篇文章，介绍了我们过去两年来的工作。我们已经从基于集中管理的分析数据集和数据基础架构工具的本地架构，迁移到了完全云原生且功能更丰富的数据和工具集，使 Intuit 团队能够构建更为丰富的流、机器学习，以及分析处理负载。Intuit 的客户正在从这种新架构中受益，我为我们所取得的成就感到自豪。

但就目前而言，这项工作尚未完成，存在很多改进的机会。

我们调查了我们的解决方案中存在的问题，并研究了与我们规模和业务范围相似的公司给出的解决方案。Zhamak Dehghani 对“数据网格”的描述吸引了我们的兴趣，它倾向于将数据所有权和责任推给业务边缘的本地域团队。开头的“架构失败模式”部分令人惊叹地准确提炼了当前困扰我们的状况。Zhamak 倡导领域驱动设计，其重心放在了专注单点、面向问题域的团队的所有权和责任上；作为解决这些问题的策略核心，他的理念引起了广泛共鸣。我们已经看到，这种方法对于我们的“屋前”部分，也就是微服务架构和 Intuit 核心交易服务的开发工作非常有效。因此我们有信心将这一策略应用于我们的“屋后”数据系统，认为它在那里同样可以取得成功。

本文接下来将带你全面了解我们的愿景、内在挑战以及在 Intuit 构建更好的数据驱动系统的策略。你可以将其视为通过 Intuit 视角形成的数据网格。如果你曾体验过典型的数据湖，并且有过这样的疑问：“我们如何才能减少混乱并提高生产力，把重心拉回到让客户满意的业务上”，那就继续读下去吧。

愿景

Intuit 需要数据驱动的系统来实现更智能的产品体验，并让更多 Intuit 团队更轻松地创建这些体验。这里涉及到多种数据工作者：

• 一位服务工程师构建一个服务，该服务在签发账单时发布一个事件。

• 一位 UX 开发人员构建一个登录页，在用户访问时发布一个事件。

• 一位业务分析师构建一个报告，显示 QuickBooks 每小时的新订阅计数。

• 一位数据科学家构建一个模型，在批准付款之前预测欺诈行为。

• 数据工程师或分析师可综合来自我们的客户标识和 Intuit 后台系统的数据来建立识别新用户和回头用户的管道。

挑战

为了了解如何推动这些系统，实现更简单、快速的开发，我们首先必须找到是什么在阻碍那些试图构建这些系统的数据工作者。我们对数据系统的 245 位当前用户进行了调查，以了解他们在日常活动中正受困于哪些问题。在业务分析师、数据工程师、数据科学家和机器学习工程师等角色中，下面这些问题是被提到最多的：

数据可发现性

• 在哪里可以找到关于特定事物（客户、公司等）的数据？

• 在哪里可以找到来自特定产品或服务的数据？

数据可理解性

• 谁可以批准我的访问权限，以便我可以查看数据样本？

• 数据的模式是什么？

• 数据的业务含义和上下文是什么？

• 这些数据是否与其他概念相关？它可以加入其他数据吗？数据间的关系有什么意义？

数据信任

• 哪个系统生成这些数据，延迟多大？

• 还有哪些其他系统使用这些数据？

• 这些数据的质量如何？

• 如果数据出问题，哪个团队会提供支持？

数据消费

• 这个表/主题如何分区？

• 谁可以批准我的生产系统访问它？

• 如果模式发生更改，我会收到警报吗？

数据发布

• 我如何描述我的数据，以便其他人理解它的含义并明白该如何使用它？

• 我在哪里托管我的数据，以便其他系统可以访问它？

• 数据系统很复杂；我该如何构建和运维一套系统？

• 我的流程/数据投入生产后，我有哪些运维职责？

• 我如何满足处理、存储和发布数据的合规性要求？

• 我是否在复制已经存在的处理/数据？

策略

有了对用户体验的新洞察，我们定义了一种策略，能使更多的数据工作者可以轻松创建和拥有高质量的数据驱动系统；这样就能为 Intuit 客户提供更智能的产品。该策略使数据工作者能够设计、开发、全面描述并积极支持他们自己的数据驱动系统，从而让其他人可以轻松发现、理解、信任和消费数据。这增强了数据生产和消费的网络效应，从而提高了所有数据工作人员的生产效率，带来了 Intuit 所需的多种高质量数据驱动系统。

数据系统的发现、理解、信任、消费和发布通过三种方式得到支持：

1. 一种组织人员、代码和数据的系统方法，将解决方案映射到业务问题及其所有者。

2. 确保所有团队理解并负责构建和管理解决方案的一组明确职责；包括遵守一组已定义的最佳实践，以确保生成高质量的数据。

3. 一套丰富的产品套件，使团队可以更轻松地创作、部署和支持自己的解决方案，并遵循最佳实践。

组织人员、代码和数据

为了更准确地描述可以共同解决业务问题的一组相关代码和数据，我们引入了一种组织它们的系统方法：数据产品（Data Product）。

数据产品是一组内部流程和数据，这些内部流程和数据产生了一组外部消费数据，所有这些数据都围绕业务领域中的同一问题。它是由一个能够共同理解业务问题以及解决该问题的内部流程和数据实现细节的团队共同创建和管理的。

相比之下，现在的团队是围绕技术打造的，迫使同一逻辑业务的问题被随意分配给几个不同的团队。这会导致沟通和协调效率低下，导致了团队今天遇到的许多问题。一个团队可能由一个或多个精通解决方案中所使用技术的数据工作者、一个精通业务问题的产品经理以及负责及时有效地执行为业务问题提供解决方案的项目的领导者组成。

这里的重点在于开发用于组织这些资产的系统，这样我们才能将所有权概念置于最顶层。如果不能准确指出哪些人负责哪些代码和数据，就无法让任何人对公司的价值负责，也就不存在合理的方法来走出更合理的路径。

我们先来观察一下 Intuit 的数据湖环境，对于其中包含的成千上万个表格中的成千上万个字段，绝大多数字段的用途我们都还没完全理解。由于无法找到数据或数据的所有者无法解释数据的含义，数据工作者在数据湖中的时间被浪费了将近一半。

所有权

在这种组织系统的基础上，所有权汇集了三个重要概念：

1. 一个掌握所有权的团队，

2. 所有权适用的范围，以及

3. 在该范围内要履行的一系列职责。

只要是有数据产品的地方，我们都需要明确声明以下内容：“团队 A（也就是掌握所有权的团队）负责 A 数据产品的制作、详细说明、治理、质量和运维状况（即责任），该产品由这些流程和数据（即范围）组成。”

本文前面的数据产品定义中已经涵盖了团队和范围。职责定义如下：

• 制作：团队设计解决方案、编写代码，并安排实现该解决方案的系统

• 说明：团队详细描述系统，以便其他团队能够发现、理解和使用数据 API。

• 治理：团队负责解决方案，并遵守所有适用的法规和安全性要求。

• 质量：团队负责保证解决方案的质量，并以承诺的正确性和延迟交付其数据 API。

• 运维状况：团队负责维持数据产品的正常运行时间、性能和成本。

上述职责的隐含含义是我们要求团队出色履行职责。不良的数据产品（例如经常损坏、描述得不好且没人能找到所有者的数据产品）弊大于利。因此我们需要精心设计、描述丰富、管理有力、高质量和运维可靠的数据产品。

为了帮助团队理解这些期望，我们建立了一个框架，列举必须满足的、对要发布的业务有足够价值的条件。该框架描述了两个级别，以及满足这些级别所需的各种标准：

• BASIC（基本），描述了符合我们的组织和所有权责任制所必须满足的最低标准。

• BEST（最佳），超越了 BASIC，引入了合理化数据的概念，可确保数据产品产生的内容对生态系统具有全新的价值，并且不会与公司中已经建立并依赖的重要概念重复或抵触。这已经进入了数据管理的领域，从根本上以联邦所有权责任制的目标代替了集中式数据定义的目标（在 Intuit，我们如何优雅地、大规模地做到这一点将是另一篇文章的主题。）

BASIC 数据产品具有：

• 定义的直接上游依赖项

• 定义的合规规定

• 变更控制和访问控制流程到位

• 数据 API 与内部实现脱钩

• 定义和描述的数据 API 模式

• 根据规定的 SLA 监控的数据 API

• 分配了所有团队，对其负责并根据其职责进行衡量

BEST 数据产品具有：

• 所有 BASIC 内容，再加上

• 针对其他所有数据产品合理化并相关的数据

支持最佳实践的多种可组合功能

多种可组合的功能集为团队提供了自行设计、创作、部署和运维数据产品的工具。这种多样性可确保容纳数据工作者同样多样化的技能和观点，并确保每个人都可以高效地消费和生产数据产品。这些工具遵循最佳实践，确保了数据产品的构造和数据的生成方式能够提高而不是削弱 Intuit 利用我们所有数据的能力。功能集中的产品都要求其用户生产符合 BASIC（或更佳）发布要求的数据产品。

所有这些功能都与中央平台服务和标准集成在一起，确保以自助服务的方式实现安全性、身份验证、授访问控制策略管理、变更控制过程、模式注册和文档，从而使各个团队能够有效地履行他们的所有权责任。此外，质量、成本和性能指标的度量和报告方式也相同，因此各个团队以及整个组织都可以洞悉数据产品的运行状况。

数据工作者可以使用的所有产品的清单和简要说明如下。由于其中许多产品大而复杂，因此我只提供了简短的摘要。我会尽量提供 Intuit 发布的其他介绍文章的链接。

团队用来实现其数据产品的能力

InstrumentationServices

一种工具，用于按照 Intuit 的事件标准对用户面对的体验进行行为跟踪，使 UX 团队可以跟踪用户的交互，以便其他分析和 ML 团队可以从定义明确的位置使用这些事件，以进行进一步的分析和转换。

DomainEvent 服务

DomainEvent 描述了发送系统的变化状态。服务工程师在其事务微服务中利用 DomainEvent 服务，以向下游数据产品异步提供 DomainEvent。它旨在代替今天使用的原始 CDC 数据。

通用提取平台（UIP）

UIP 利用交易数据库系统（Oracle、MySql 等）广泛支持的 CDC 流和/或 jdbc 连接，将数据提取到数据湖中，以便大数据处理技术访问。服务工程师利用 UIP，仅在 DomainEvents 不可行时使原始数据可用于 DataLake。该平台由 Oracle GoldenGate、Debezium 和 DeltaLake 构建。

IntuitPersistenceServices（IPS）

使服务团队能够部署和管理数据库，以支持有状态业务逻辑。部署封装了所有 Intuit 最佳实践和标准，以实现高度可用和安全的系统。

流处理平台（SPP）

使服务团队或数据工程团队能够创建消费、处理和生成实时异步事件流的系统。

管道

使数据工程和分析团队能够创建 spark 和 hive 的批处理作业，并安排它们定期执行或在其他上游数据产品的结果可用时执行。

模式管理器

使 UX、服务、数据工程师和分析团队能够创建其数据产品生成的模式。模式管理器能够强制执行模式标准并推荐最佳实践，以及检测和预防来自不同团队的数据之间重复和冲突的定义。

实体生成器和实体解析器

使分析师和数据管理者能够定义用于管理和控制实体的逻辑，以便跨领域概念（例如客户、产品等）具有可在整个公司使用的一致定义。我们已经开始定义和构建它了；因此它很可能会成为更多博客文章的主题。

ML 平台特征工程

使数据科学家和 ML 工程师能够定义要在模型训练中使用的特征。

ML 平台训练服务

使数据科学家和 ML 工程师能够训练模型。

ML 平台模型执行服务

使数据科学家和 ML 工程师能够部署经过训练的模型，以实时或批量执行。

数据质量服务

在任何数据产品生成数据的地方都可用的功能。它对用户的数据提供基于上下文的质量检查。它支持在构建和测试阶段进行质量判断，以及在生产过程中进行质量观察和监视，确保在整个数据生命周期中都达到数据质量目标和数据 SLA。我们正在为它应用蒙特卡洛，并且还将通过我们自己的一些创新来改进它。

数据发现和探索（DDE）

一种工具，允许用户浏览可用数据集并启动一个查询浏览器或笔记本，以开始访问和操作数据集。在将数据产品构建和发布到生产环境之前，协助所有用户进行研发工作。

团队用于托管其数据产品的 DataAPI 的能力

数据湖

数据湖托管用于分析、机器学习和其他并行扫描和尽快处理大量数据的大规模负载所用的大批量数据。它利用了 HMS、parquet 和 S3 blob 存储。它建立了授权模型和工作流程，使消费者可以请求、生产者可以批准对数据集的访问，用于探索和生产访问目的。

EventBus

所有流事件数据的所在地。服务工程师和数据工程师直接利用它们来实现异步事件解决方案或创建流处理应用程序。当分析师、数据科学家和 ML 工程师利用 ML 平台特征管理和实体构建与解析器的实时处理功能时，会间接利用它们。

数据集市

用于驱动业务报告的数据所在地，主要由数据工程师和分析师使用。数据集市是针对业务的特定领域而优化的专用架构（例如“税务专家案例管理和效率分析”）。它们提供了驱动仪表板所需的数据集和查询引擎。

特征存储

驱动 ML 训练和预测用例所需的所有特征的所在地。它允许在联机和脱机位置上托管相同的特征，以便实时和批量访问，同时保持两者之间的等效性——这种等效性保证了训练模型所使用的数据与训练模型用于生成预测的数据之间的稳定性。用于数据科学家和 ML 工程师。

API 网关

所有服务托管其 REST API 的所在地，用于公开服务行为（如“POST/TaxService/FileTaxReturn/{id}”）和数据（如“GET/TaxService/TaxReturn/{id}”）。网关以标准化方式在整个企业中处理 authn/authz，从而确保在组织中的所有服务上始终如一地保持安全性。

案例

描述所有数据产品的所有元数据的集合被用于创建所有团队、系统、数据、实体及其之间的依赖项的通用元数据注册表（我们的数据库基于 Apache Atlas 构建）。它是回答有关数据产品所有权、范围、责任、技术依赖和数据含义等所有问题的基础。

下面列出了五个构想中的数据产品，包括它们的技术依赖（灰色线）及其合理化的数据定义和关系（蓝色线）的集合：

请注意，我们在本文开头提出并驱动我们策略的问题是可以回答的：

• 客户数据可在哪里使用？数据的架构是什么？

• 客户分析数据产品还从哪些其他数据产品获得数据？

• 哪个团队负责产品权利服务数据产品？那个团队中都有谁，我该如何与他们取得联系？

• Intuit 客户与 Intuit 产品有什么关系？

• 哪个团队可以批准我访问客户分析数据产品的数据湖表的请求？

下一步

Intuit 正处于数据网格之旅的开始阶段。考虑到这是一个相对较新的概念，因此还没有人开发出类似于数据网格标准之类的东西。尽管本文中介绍的许多功能都有某种形式的存在，但组织这些功能所需的系统才刚刚起步。

这篇文章中有很多关于“为什么”和“是什么”的内容，我希望我的下一篇文章能更详细地介绍“如何做”。我的期望是，本文及其后的文章可能会为其他想法类似的组织提供一个起点。随着这一概念的日趋成熟和蓬勃发展，我很想听听你对我们标准化其中一些方法的建议。齐心协力的努力可能会加快我们所有人的步伐。如果你是其中之一，请与我们取得联系。

原文链接：https://medium.com/intuit-engineering/intuits-data-mesh-strategy-778e3edaa017