Data Mesh: Decentralized Data Analytics for Software Engineers
原文地址
Kimi 总结归纳
数据网格是一种新兴的数据架构方法，它为软件工程师提供了一种新的、去中心化的方式来进行数据分析。这种方法的核心在于将数据分析的责任和能力下放到更接近业务和用户行为数据的领域团队。通过这种方式，数据网格使组织能够更快速地做出基于数据的决策，并促进了数据驱动的创新。
数据网格的关键原则
- 领域所有权：领域团队负责管理和分析与他们领域相关的数据。这种所有权模式确保了数据在有界上下文中的清晰定义和最佳理解。
- 数据即产品：数据被视为产品，领域团队负责将数据清洗、转换并提供给其他团队使用。这要求数据具有高质量、易于访问和理解的特性。
- 自助服务平台：领域团队可以使用自助服务平台来获取、清洗和分析数据，而不需要依赖中央数据团队。这种平台提供了必要的工具和接口，使领域团队能够独立地进行数据分析。
- 联邦治理：在数据网格中，治理是跨领域的协作过程。领域团队共同定义和遵守全局政策，以确保数据的互操作性、安全性和合规性。
数据网格对软件工程师的意义
- 提高数据可访问性：软件工程师可以直接访问与他们的领域相关的数据，而不需要通过中央数据团队。这大大提高了数据处理的速度和效率。
- 增强数据质量：由于领域团队最了解自己的数据，他们可以更有效地清洗和维护数据，从而提高数据质量。
- 促进跨领域合作：数据网格鼓励领域团队之间的协作，共享数据和见解，从而推动整个组织的创新和增长。
- 提升决策质量：软件工程师可以利用领域数据进行更深入的分析，从而做出更明智的技术和业务决策。
实施数据网格的挑战
- 文化和组织变革：数据网格要求组织文化和结构进行相应的调整，以支持去中心化的数据管理和协作。
- 技术和工具的选择：领域团队需要选择合适的技术和工具来管理和分析数据，这可能需要额外的培训和支持。
- 数据安全和隐私：在去中心化的数据环境中，确保数据安全和隐私的挑战更大，需要制定严格的安全策略和控制措施。
通过实施数据网格架构，软件工程师可以更好地利用数据资源，提高业务效率和竞争力。同时，也需要认识到这一转变带来的挑战，并采取相应的措施来克服。
运营IT系统的数据中包含有价值的信息。这些信息可以让我们推断用户行为，并帮助我们更好地理解软件系统。然而，软件开发人员经常在他们的项目中忽视数据分析。对于许多项目经理和产品所有者来说，数据在评估特性和用户故事时处于次要地位，主要是因为数据很少以分析准备好的形式提供。
传统上，数据由数据团队在数据仓库系统和数据湖中收集和分析。然而，在评估这些数据时，重点通常在于企业管理和营销，而不是开发新特性的团队。此外，这些评估的结果通常令人失望。这往往是由于连接的源系统中数据质量不足，以及由中央组织的数据团队缺乏解释这些数据的专业知识。此外，这样的集中式系统和团队在不断增长的数据分析需求面前无法快速扩展。
数据网格是一种相对较新的、去中心化的数据架构方法，旨在使开发团队能够独立地进行跨领域数据分析，以更好地理解他们的用户和系统的行为。通过向其他团队提供精选数据，创建了一个有价值的去中心化数据网络。
数据架构中的模块化
近年来，软件开发取得了重大进展。战略性领域驱动设计（DDD）有助于组织和描述系统中的技术功能。可以通过上下文映射等方式确定各个领域的明确责任，并识别和描述社会技术关系和接口。
组织结构中的自治产品团队负责一个明确的领域，并作为回报，他们拥有高度的自由度，从编程语言的选择到团队人员配置。因此，这些团队构建的软件系统反映了他们有界上下文的技术范围。为此，他们使用模块化软件架构方法，如微服务（按照Sam Newman在2015年已经制定的意义）或自包含系统，以避免单体系统，并最好地实现可靠性和可维护性等质量目标。与其他领域的交互通过明确定义的接口进行，尽可能异步作为领域事件，例如通过Apache Kafka或HTTP feed。
根据数据网格原则，现在也可以将单体结构拆分为单独的技术领域。前提是基于领域边界对团队进行划分。而不是由数据团队管理的中央数据仓库汇集所有数据，领域团队为自己的特定领域进行分析评估，并通过明确定义的接口访问其他领域的数据集。
数据网格的原则
“数据网格”一词由Zhamak Dehghani在2019年的文章“如何从单体数据湖走向分布式数据网格”中创造。定义通常包括以下四个原则：
- 领域所有权
- 数据即产品
- 自助服务平台
- 联邦治理
领域所有权意味着负责操作系统的团队也提供他们的分析数据。这背后的核心思想是，数据只有在其有界的上下文中才有明确的定义，各自团队最了解自己的数据。因此，每个团队独立决定哪些数据重要以及如何为分析目的准备它们。每个团队对其数据负全部责任。
数据即产品的原则是，分析相关的数据应该以便于其他团队轻松访问的方式进行管理和存储。数据在团队内经过通常的开发过程，从产品所有者描述用户故事和关于数据访问和各个字段重要性的可理解文档，到包括监控在内的运营责任。凭借其数据，团队为其他团队提供了宝贵的贡献。
自助服务平台描述了一个数据平台，团队用它来提供分析数据、数据评估和可视化，以及轻松访问其他领域的数据。重点是自助服务特性：所有活动都应该在不需要另一个团队介入的情况下进行。
联邦治理指的是跨领域的协议，它规定了如何设计有效的交互以及如何长期保证数据领域的质量。为此，领域的代表共同定义了必要的全局策略（比较宏观架构指南），这些策略对于互操作性和安全性至关重要。在更高层次的扩展中，平台也可以自动确保遵守这些规则。
这些原则适用于描述去中心化数据架构中的责任。但对于领域团队中的软件开发人员来说，它们意味着什么呢？
面向整体结果的领域特定数据分析
首先，领域团队特别关注的是自助服务平台。到目前为止，操作系统的开发者通常不进行数据分析，因为它们通常不能在操作数据库上高效执行，并且会影响生产应用的性能。然而，现在提供了一个易于使用的数据平台，使团队能够独立地准备数据进行分析。
数据网格架构（图2）。
数据网格架构（图2）。
数据平台通常由专门的数据平台团队管理，包括存储、数据摄取、处理、分析、可视化以及元数据和权限的管理。使用数据目录来定位和记录数据产品——通常是数据、AI模型和结果展示的组合——并遵守约定的指导方针。
通过所描述的数据平台，团队现在能够为分析目的提供数据。一旦数据被传输到平台上，它们仍然需要被准备和清洗。为此，建议首先将数据以源格式（例如JSON）导入到CLOB（字符大对象）字段中，这样数据库模式就不必考虑。接下来，开发人员应将数据转换为结构化的SQL表格式，去重，并在必要时缓解结构变化和空值。鉴于数据保护要求，他们还应尽早删除或至少匿名敏感信息（个人数据、信用卡信息），最好在将其存储在平台之前。这种清洗可以由了解自己运营数据的领域团队比缺乏技术上下文的中央数据团队更有效地完成。这种有针对性的数据准备有助于提高数据质量。
有了清洗后的数据，团队可以自己进行分析。最初，这些通常是简单的SQL查询。使用JOIN操作，可以合并和整合来自不同源系统（例如不同的微服务）的数据记录，并使用聚合函数。窗口函数对于执行分区的多行评估特别有帮助。可视化有助于识别趋势和异常。领域团队可以使用自己的数据来解释过去的系统性能并跟踪用户行为。当涉及到从发现中推导新特性并早期评估用户故事的好处时，这特别有帮助，而不是仅仅基于直觉进行优先级排序。识别系统错误也更容易，例如总是在特定事件发生后不久发生的那些错误。有了数据网格，领域团队可以独立进行评估，并将洞察力更快地纳入运营改进。
仍然缺少的是对整体结果的概述，例如网页商店首页UI更改对后续购买的影响。另一个电子商务的例子可能与转化率有关。衡量实际购买的数量是有趣的，但最初被忽视的问题是，客户是否退回了订购的商品。这是不同领域数据联网的地方：如果购买完成领域将一次会话的结果和产品退货领域将退回的物品作为数据记录在平台上可用，相关性——甚至使用A/B测试等有意义的因果关系——可以立即被识别。这种方法符合数据网格的数据即产品原则。一个领域以可访问和有文档记录的形式提供某些相关的数据集。因此，跨领域数据的使用和链接导致越来越有意义的分析。
然而，在跨领域链接数据时，会出现一个问题，即一个领域的数据和术语仅在其有界上下文中有效。这是领域驱动设计中的上下文映射方法有助于描述领域模型之间的关系的地方。例如，遵循开放主机服务模式的数据集必须比作为双边客户/供应商协议结果创建的数据集描述得更精确。
共同协议有助于确保技术和语义互操作性，例如通过所有相关方同意格式（SQL、JSON等）、语言（德语、英语等）以及领域密钥的名称和形式。领域团队和平台团队的代表共同达成必要的协议，并将它们记录为全局策略。
数据产品除了实际的数据集外，还包括元数据。像API一样，数据产品也持续进行监控（图3）。
数据即产品更进一步：如果一个数据集对其他团队可用，它可以与生产API进行比较。因此，团队还必须持续确保数据的可用性和质量。所有数据集都必须有清晰的文档并可查找。然而，现在对数据模型的更改要困难得多。需要监控，以监督数据的可用性、质量和完整性。分析数据因此加入了一个领域的接口——类似于UI和API。
产品所有者负责确保从领域和商业角度来看，数据的提供仍然具有经济可行性。由于通常不将所有领域数据作为数据产品提供给其他团队并不是有效的（即使使用数据的团队可能希望这样做），必须做出明确的决定：哪些内部数据仅用于内部分析目的，哪些应该作为数据产品提供给其他团队？例如，经常引用的领域事件和主数据通常也应该提供给其他领域团队。如果有疑虑，团队必须相互协商并就所需的数据产品达成一致。
实践中的数据网格
数据网格最适合作为自下而上的方法，但如何实际实施呢？理想情况下，它是由一个或（最好）多个表示对数据分析感兴趣的团队开始的。他们就一个数据平台达成一致——如今常见的云服务，如Google BigQuery、AWS S3、Azure Synapse Analytics或Snowflake。然而，为了入门，一个PostgreSQL数据库结合像Metabase或Redash这样的可视化工具也足够了。每个团队在其自己的区域（项目/账户/工作区等）中独立创建资源，如数据库和表格。逻辑结构定义了应该位于不同类型分析数据的区域（见图4）。
数据网格中逻辑信息架构的示例（图4
）
接下来，团队将运营系统的数据输入到数据平台中。这些数据通常以原始形式杂乱无章地出现在一个原始区域。可以使用Kafka Connect等集成进行此操作，或者团队实现自己的消费者调用各自平台的流式摄取API。通常，领域事件（如果有的话）非常适合作为主要的分析数据基础，因为它们代表业务流程的事实。另一方面，应尽可能避免使用ETL批次导出数据库，以便实现实时分析，而不暴露操作数据库模式。
然后对数据进行清洗，例如作为原始数据的SQL查询。这些数据被创建为视图，如下所示的列表。去重并将JSON映射到各个字段。公共表表达式非常适合结构化。
WITH inventory_deduplicated AS (
SELECT *
EXCEPT (row_number)
FROM (
SELECT *,
ROW_NUMBER() OVER (PARTITION BY id ORDER BY time DESC) row_number
FROM `datameshexample-fulfillment.raw.inventory`)
WHERE row_number = 1
),
-- Step 2: Parse JSON to columns
inventory_parsed AS (
SELECT
json_value(data, "$.sku") AS sku,
json_value(data, "$.location") AS location,
CAST(json_value(data, "$.available") AS int64) AS available,
CAST(json_value(data, "$.updated_at") AS timestamp) AS updated_at,
FROM inventory_deduplicated
)
-- Step 3: Actual Query
SELECT sku, location, available, updated_at
FROM inventory_parsed
ORDER BY sku, location, updated_at
清洗后的数据集为团队的内部数据分析提供了基础。通常需要区分不变的事件和随时间变化的主数据实体。使用SQL查询，团队现在可以分析这些数据。Jupyter Notebook通常用于建立和记录探索性发现。
推荐使用Jupyter Notebook进行探索性数据分析（图5）。
可视化有助于使数据更易于人们理解。数据平台应该为此提供适当的工具——图6以Google Data Studio为例。可视化的前提是访问表格或相应的查询。另一方面，数据的聚合也可以直接在工具中控制。
Google Data Studio条形图的示例（图6）
最后，数据也应该作为数据产品提供给其他团队。建议在这里使用视图，以确保即使底层数据集发生变化，数据的外部视图也保持一致。这样的迁移可以在视图的查询中进行跟踪。现在授予其他团队对此视图的权限，并通过SQL查询访问它。此外，必须根据约定的程序记录数据集。在最简单的情况下，可以在wiki或Git存储库中完成。然而，在更高级的发展阶段，应该使用提供有关数据集的元信息以及质量的数据目录，并精确记录各个字段（见图7）。
数据产品可以在数据目录中记录，例如（图7）
随着时间的推移，这将创建一个不同领域数据产品网格，可以在整个组织中使用。理想情况下，数据网格鼓励其他团队也使用提供的数据平台，并最终自己提供分析数据。
这里描述的方法对软件开发人员来说是实用的，因为可以使用SQL——大多数IT专家应该熟悉的工具。另一方面，数据的可视化处理以及统计方法可能需要重新学习。更复杂的数据准备工具，如Apache Spark、Apache Beam或NumPy，在最初阶段并不绝对必要。
数据网格作为新领域的创新驱动器
数据网格主要是关于领域团队能够自己进行数据分析。但是，在许多组织中已经存在的中央数据团队会发生什么变化呢？
由于其知识，数据团队注定要运营和管理上述数据平台，因为在使用自助云服务时仍需要设置权限并控制成本。该团队还可以作为使能者和大使，鼓励并帮助其他领域团队使用数据平台。通过为常见用例提供模板和最佳实践，他们使平台具有吸引力。专家还可以以顾问身份进入领域团队一段时间，以建立必要的技能。
必须继续提供现有的数据产品，例如用于企业管理的报告。这项任务最初仍然由现有的数据工程师承担。然而，他们的工作变得更加容易：如果领域团队以清晰约定的格式和一贯的高质量提供清洗后的数据集，那么繁琐的数据提取和准备步骤就被消除了。还应考虑为数据密集型领域建立单独的领域团队，例如用于企业管理或营销的团队。数据科学团队也可以为基于数据评估和机器学习模型的运营和分析服务提供客户画像或销售预测等专业领域，这些团队基于数据评估和机器学习模型提供运营和分析服务。