关键产出：Data Mesh逻辑架构
如同运营模式流和产品流一样，技术流同样有重要的输出资产，即Data Mesh逻辑架构，如前文所示。逻辑架构映射了整个Data Mesh各领域的数据产品，提供了以下内容的清晰概况：
- 哪个领域拥有和负责哪些数据产品
- 数据产品服务于哪些用例，包括不同数据产品如何结合起来以支持更多用例
- 各个数据产品的用户，以及这些用户如何利用多语言输出端口消费数据产品
- 如何消费数据产品，以及使用消费者导向的数据产品的洞见创造了哪些价值
- 作为数据来源的操作型系统或向数据产品输入数据的记录型系统
- 为Data Mesh模式提供基础的自助式平台的能力。
在整个技术探索流，我们尽可能详细地定义这些节点，并构建逻辑架构。
在我们技术流的探索过程中，数据工程师与新加入的领域合作，以了解其现有平台能力和任何已有数据产品的范围。这一步骤可以帮助数据工程师确定需要利用哪些新技术和架构来弥合Data Mesh的差距，以及从技术视角看，新数据产品应该是怎样的。
在我们与Roche一起实施的探索过程中，我们通过多种措施将团队和我们的计划行动与一系列架构实践和原则对齐。我们通过所述实践和原则帮助建立互操作性数据产品的一致生态系统，并在组织内建立推动Data Mesh演进的强大基础。
关键实践1：将数据产品作为架构量子处理
数据产品是构成Data Mesh的基本单元。每一个数据产品都有其生命周期，可独立地进行部署和维护。在我们的合作项目中，我们对各数据产品创建了单独的git仓库，包括：
- 用于接入、转换和发布到输出端口的代码
- 示例数据、单元测试和数据质量测试
- 基础设施即代码，用于提供数据流水线、CI/CD流水线和其他平台能力，如存储、计算、监测配置等
- 访问策略即代码，指定谁可以访问数据产品以及如何访问
每一个数据产品都是一个功能内聚的原子单元。在我们的示例中，数据产品通过一个或多个输出端口发布单个非标准化数据集。它可能需要额外的中间表作为其管道的实施细节，但最终都是通过其输出端口发布一个数据集。
可能有人会怀疑这个规则太过严格，以至于无法适用于所有消费者对齐的数据产品。许多此类数据产品必须从多个数据集进行读取才能实现其目标。但我们的经验证明，事实并非如此。如果我们发现需要通过输出端口发布多个数据集，这表明我们应该创建新的数据产品。
以数据产品作为架构量子（可独立部署的最小Data Mesh单元，具有高内聚性，包括实现Data Mesh功能所需的全部结构化元素）来构建Data Mesh，这是确保Data Mesh稳健性的关键。
在不影响整体系统的情况下可轻松替换或移除任何特定数据产品。必要时，它还有助于轻松地将数据产品重新分配给新的团队，帮助Data Mesh横向扩张和有机发展。
关键原则：把数据产品作为功能内聚的原子单元
数据产品是Data Mesh的架构量子。应将数据产品设计为Data Mesh的最小功能内聚单元，且每一个数据产品都有其独立的生命周期。这是Data Mesh架构的基本原理。
关键实践2：自助式数据平台设计
在Data Mesh中，数据平台有多个平面。许多组织经常会犯的错误是，在设计和建设平台时仅关注数据基础设施平面。但要想成功实施Data Mesh，团队需在以下两个更高的层面进行仔细评估并制定正确决策：数据产品开发者体验层面和Data Mesh监督层面。
下图来自Zhamak的原创文章，直观展示了各层面的组成部分。
关键实践3：创建流畅的开发者体验
消除数据产品创建和维护方面的阻碍是成功实施Data Mesh的关键。为了确保这个模式可以起作用，各个领域必须能够轻松创建自己的数据产品。因此，在建设平台架构和确定如何实施Data Mesh时，一项首要任务便是确保实现流畅和直观的开发者体验。
为便于操作，我们：
- 开发了受OAM启发的规范语言，帮助产品团队以声明方式指定他们的数据产品。
- 帮助领域利用这个领域特定的语言开发自己的产品。平台提供了读取数据产品规范并通过CI/CD流水线采取适当措施的框架和工具。
- 编制和维护了能力注册表，以帮助每个人了解他们可以获得的能力
如果操作得当，该平台可缩短创建新数据产品的准备时间，帮助各领域开发者专注创建和维护能增加业务价值的数据产品，而无需反复解决相同的数据工程问题。平台还有助于编制实现标准功能的蓝图和模式，从而提高数据产品的一致性和互操作性。
关键实践4：为数据产品建立一致的元模型
为确保所有数据产品可轻松搜索和跟踪，进而得到充分维护，我们还为数据产品建立了一个进入数据目录的流程。通过一个组织内所有成员均可访问的通用目录（在我们的示例中为Collibra）发布所有数据产品。我们为数据产品建立了一致的元模型，确保无论其归哪个领域所有，都有着相同的含义。这对确保数据产品之间的互操作性至关重要。
这个元模型针对数据产品强制使用某些必需属性，如
- 名称（在数据领域是唯一的）
- 数据产品的描述
- 负责人/管理人（数据产品的第一联系人、访问权限批准人）
- 数据共享协议
- “访问控制”或“访问权限审批”（由数据产品负责人授予）
- 公布的数据访问策略：规定谁有权/无权访问数据
- 数据分类（公共、内部、保密数据等）
- 分发权：消费者是否可向第三方分发已修改（聚合、过滤、合并）或未修改的数据
- SLO和SLI
- 端口（数据产品发布机制）
- 数据产品类型（数据源/消费者对齐）
- 归属的业务领域（业务职能部门）
为进一步改善开发者体验，我们开发并在内部开源了可利用符合前述定义的REST接口发布数据产品的客户端库。数据产品团队可通过声明性DSL（如前文所示）利用这些平台能力，通过其CI/CD流水线轻松发布数据产品。
关键原则：在整个组织内确保数据产品的定义一致性
在一个Data Mesh范围内，不同的团队有权以最符合自身需求的方式创建和管理他们自己的数据产品。但需要设置清晰的护栏并确保数据产品（元模型）定义的一致性，以确保整个组织内的互操作性。
关键实践5：自动化治理和访问控制策略
作为开发者体验的一部分，数据产品团队应能够以程序化方式规定人和机器用户的访问策略规定。对此，他们应能够部署基于角色的访问控制或基于属性的访问控制技术。
平台应支持数据共享工作流和这些策略的自动执行，同时确保无缝集成企业身份管理系统（角色的管理系统）和目标数据存储解决方案，以授予数据库模式和数据库表适当的权限。
已经有一些商业性工具承诺为多数据集存储提供这种功能。我们目前正在尝试一些此类工具，但尚未找到完全适用的工具。似乎还没有一种开箱即用的解决方案（无论是商业性的还是其他性质的）可以满足Data Mesh中数据产品编程策略编写、联邦所有权和多类型存储的需求。
我们了解过的大部分商业工具似乎都是后来才添加的编程访问接口（API）。这似乎是一个亟待创新的领域，我们近期将予以重点关注。扩展开放策略代理，通过其Rego DSL以程序化方式指定支持常见大数据存储解决方案的策略，似乎是符合Data Mesh精神的最有前景的发展方向。
如果您无需处理您整个组织内的多类型存储问题，这个问题就变得容易多了。例如，如果您的组织仅使用AWS原生服务，请查看本详细解决方案架构，了解如何利用AWS Lake Formation解决这个问题。
关键实践6：应用适应度函数来引导网格的演进
监督平面仪表板-监测数据产品的六个特征
在Data Mesh中，每一个团队都有权构建自己的数据产品。但随着各领域的团队不断创建自己的用例，如何在引导Data Mesh的演进同时确保随着Data Mesh的发展，其中的产品依然保持互操作性和价值？
为了帮助回答这个问题，我们借鉴了架构适应度函数这个概念。我们针对数据产品的六个特征构建了自动化测试，可对数据目录中的所有数据产品集中运行这些测试。这些测试确保了自治领域数据产品团队创建的数据产品达到组织要求的标准：
- 自描述性（Self-describable）：自动检查是否已经在数据目录中强制发布，提供了清楚的语义说明、产品描述和数据语法，最好附带示例数据集
- 可寻址性（Addressable）：检查表示数据产品拥有的数据集位置的惟一URI
- 可发现性（Discoverable）：自动检查，确保在目录和发现市场中发布且可搜索数据产品。
- 安全性（Secure）：检查默认情况下是否已阻止对数据产品的访问。检查PII信息是否已消除。
- 可信任性（Trustworthy）：检查SLO和SLI是否已在目录中发布。检查遵循特定SLO（如刷新率）的情况。
- 可互操作性（Interoperable）：自动检查，确保支持标准输出端口和标准文件格式。
这些测试并不全面，要使这些架构特征可见并促进团队遵循规定治理原则，这些测试只是一个起点。这些检查的结果已在全组织成员可轻松访问的仪表板中发布。这一重要举措旨在激励数据产品团队遵守规则，因为没有哪个团队希望看到他们的数据产品在仪表板中被标示成红色。
关键实践7：提供清晰的数据共享指引（或模式）
Data Mesh的联邦架构和整个Data Mesh内使用的多类型存储，使得在团队之间实现数据共享成为构建高价值Data Mesh时一个棘手而且更加微妙的挑战。尽管数据虚拟化方案日益改进，但这个技术尚未成熟，一直存在三个明显的问题：
- 虚拟表泄露了数据抽象。根据我们的经验，对于大部分重要用例，您仍然不得不考虑数据在数据源的表现形式。
- 大部分数据虚拟化方案速度依然很缓慢，查询性能受制于最慢的源的速度。
- 数据虚拟化方案并非专为编程应用而创建。创建、修改和管理虚拟表的工作流依然高度依赖UI，因此很难测试并驱动持续集成和持续交付。
尽管如此，数据虚拟化足以满足大部分报表需求。然而，如果数据本地化对您而言很重要（比如您正在利用大量数据集训练机器学习模型），那么虚拟化是行不通的。
在我们的项目实施中，我们利用以下指引和模式帮助确定组织内的数据共享形式：
- 数据产品可将虚拟DB显示为额外的输出端口。对于大部分简单报告类型用例，这已足够且不需要进一步能力。
- 对于更高级用例，当生产者和消费者位于相同存储平台时，应始终使用存储平台的潜在原生机制进行数据共享，如Redshift数据共享或原生snowflake原生数据共享能力。
- 如果您需要确保数据本地化且您的生产者和消费者位于不同存储平台，您可能不得不复制数据。这是最不可取的选择，应该尽可能避免。但如果您的确需要这样做，则消费者应该格外小心，确保时刻遵守治理和访问控制策略。
尽管数据虚拟化前景大好且本领域有很多值得期待的发展，但存在一种危险倾向，那就是将数据虚拟化等同于Data Mesh。导致这种情况的原因至少包括：在Data Mesh宣传信息满天飞的情况下，数据虚拟化平台趁机进行大肆营销，以期快速变现。
对于联邦架构中的具体问题，数据虚拟化是一种有趣的解决方案。这种技术尚在不断完善，我们认为Data Mesh的应用越来越广泛，将会加速推进数据虚拟化技术的进步。但要使其成为默认解决方案，还有一段路要走。
关键原则：确定和构建您自己的路线
在采用Data Mesh时需要注意的一个技术问题是，构建联邦数据架构所需的许多工具目前还未开发出来。随着Data Mesh的应用越来越广泛，将不断研发出新的工具和框架。但在那时之前，采用Data Mesh同样会将您带到一个新的领域，为您带来各种机会，帮助您确定您自己的发展路线，展现您的创新和思想领导力。
组织变革、产品思维和技术——成功实施Data Mesh的三大支柱
如果您有关注Thoughtworks，您会频繁听到Thoughtworks的这个观点——Data Mesh并不只是技术。当这个范式刚开始获得关注时，这个观点起到了一个重要的作用——防止人们将Data Mesh单纯视为另一种数据平台或架构。
如今，在大量实际实施经验的基础上，我们的思路也有了一些发展。Data Mesh的确是一种技术，但同时也包含很多其他内容。为了成功实现Data Mesh愿景，您需要推动组织变革，接受产品思维，制定正确的技术决策，并确保这三个支柱协调发展。
若要确保Data Mesh成功落地并实现其预期价值，最重要的是组织应首先确定他们想要达成的目标，以及通过构建什么平台来帮助达成相应目标。但仅确定目标和构建平台还不够。还需要各团队找到适当的度量标准来有效衡量他们的工作，以及完成它们需要进行的投注，，从而帮助团队定期修正努力方向，尝试找到实现目标的最佳路径。
通过对整个项目采用迭代的、基于价值的方法（一种应用EDGE运营模式的方法），团队可以从愿景开始反向研究他们所需的技术和架构。这种方法确保了无论组织的Data Mesh及其低层架构最终会是什么样子，他们所投入的努力最终都会带来想要的结果，并为多个领域带去重要价值。
这便是Thoughtworks采用的方法。正如我们在本系列文章中所探索的，这种方法是我们之所以能实现Data Mesh成功的根本所在。
实施Data Mesh的工作充满了挑战，但如果能正确落地，将会为组织带来巨大回报。如果实施得当，Data Mesh有望为领域赋能，提高数据利用率，支持未来增长，并帮助组织从数据中发掘新价值。
如果您对Data Mesh感兴趣并希望在Data Mesh的实施上获得专家指导，请立即联系我们。
