作者 | 蔡芳芳
采访嘉宾 | 白发川

Data Mesh 的潜力既令人兴奋又令人生畏，就像从前的微服务架构一样。

自 2010 年左右兴起到现在，微服务（Microservices）已经成为事实上的软件架构范式，被企业广泛采用，并引发了围绕面向领域设计模式优缺点的激烈讨论。如今，这股浪潮开始席卷数据领域。

Data Mesh 是一种基于领域驱动和自服务的数据架构设计新模式，借鉴了微服务和 Service Mesh 的分布式架构思想，最初源于 ThoughtWorks 首席技术顾问 Zhamak Dehghani 发表在 MartinFowler 官网上的两篇文章《How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh》和《Data Mesh Principles and Logical Architecture》。

ThoughtWorks 在 2020 年 10 月发布的技术雷达中，将 Data Mesh 从“评估”调升到了“试验”（ThoughtWorks 对“试验”阶段的技术的建议是：“值得一试。了解为何要构建这一能力是很重要的。企业应当在风险可控的前提下在项目中尝试应用此项技术。”），这意味着 Data Mesh 已经通过可行性验证，转而进入建议采纳阶段。据了解，包括 Zalando、Intuit、Netflix、JPMorgan Chase 等公司都已经在尝试实践 Data Mesh 这个概念。

但对于国内开发者来说，很多人听过 Service Mesh，甚至有不少人已经在实践 Service Mesh 了，对 Data Mesh 却知之甚少。围绕 Data Mesh 的理念和架构设计、它能解决现有数据架构的哪些问题、现在是不是采用 Data Mesh 的好时机等话题，InfoQ 记者在 2021 ThoughtWorks 技术雷达峰会现场采访了 ThoughtWorks 数据智能团队技术负责⼈白发川，一探 Data Mesh 究竟。

1从微服务的视角看数据架构

没有一个概念是无缘无故凭空冒出来的，Data Mesh 的诞生也是基于对企业数据平台架构现状和弊端的反思而提出来的。

企业数据平台的演进大致可以分为三个重要阶段：

• 第一阶段，专有的企业数据仓库和商业智能平台；
• 第二阶段，以数据湖为代表的大数据生态系统；
• 第三阶段，云上数据平台，也是当前主流的混合实践模式，包含实时数据流处理架构、整合批处理与流处理的框架，以及完全采用基于云的存储托管服务、数据流水线执行引擎和机器学习平台。

而这些数据平台架构存在一些共性的挑战：

1. 难以启动：缺少用例支持，无法获得业务支持；长时间的数据湖设计与技术评估；需要统一组织内多个业务或技术部门；

2. 数据源难以规模化：缺少手段对错综复杂的源数据系统进行疏浚与管理；难以跟上不断增长的数据源系统规模；

3. 数据消费难以规模化：数据平台项目跟不上企业创新要求；用例过窄，难以满足规模化需求；平台能力跟不上错综复杂的用例需求；

4. 数据难以商业化：极高的开发和运营成本；难以将数据平台真正转化为商业竞争力；难以形成创新文化。

这背后的根本原因在于，从业务的视角来看，企业数据平台架构从第一到第三阶段的演进其实一直延续着黑盒、集中式、单体架构的核心模式，由独立且专业化的数据工程师团队维护，业务方的可操控性非常弱，数据团队很容易成为响应的瓶颈。

实际上，当前数据架构面临的挑战，与微服务架构之前的单体软件所面临的挑战非常类似：

• 基础设施⽆法响应业务弹性需求：单体数据架构下，基础设施资源所有业务共享，进⾏集中式的管理和维护，⽆法基于业务需求灵活进⾏资源调整；

• 数据商业化成本⾼：加⼯数据以⾮产品思路对数据进⾏处理，因此⼤部分数据处理结果集⽆法以商品的形式度量其业务价值；

• 数据处理流⽔线复⽤成本⾼：每⼀个数据流⽔线为独⽴的数据⼯作空间上下⽂，跨流⽔线的 数据结果或者中间结果需要进⾏复⽤时成本较⾼，难度较⼤；

• 数据处理成本较⾼：单体数据架构模式下，⼤部分的数据处理⼯作进⾏集中统⼀管理，在涉及更多业务场景⽀持、更多团队协作下，数据处理的成本较⾼。

Data Mesh 试图基于微服务的架构思想设计数据架构，来解决上述问题。

2 Data Mesh 核心思路和架构逻辑

Data Mesh 实际上是一组数据平台架构原则，融合了分布式领域驱动的架构（Distributed Domain Driven Architecture）、自助平台设计（Self-serve Platform Design）以及将数据视为产品（Thinking Data as a Product）的思维。

有别于数据仓库 / 数据湖的集中式单体架构，Data Mesh 是高度分散的数据架构。

对于 Data Mesh 的核心设计思路，白发川将其总结为以下几点：

• 从业务域视角出发，将业务解耦之后映射到数据视角，再将数据解耦，减少数据冗余度；

• 将数据作为产品，使数据服务端到端完备，就像一个微服务一样，可以被直接访问和调用；

• 自服务的基础设施，微服务的成功很大程度上归功于它有非常成熟的基础设施，比如 Spring Cloud、K8s 等，而数据的基础设施相对于微服务的成熟架构还有所缺失，这也是未来需要持续发力的地方；

• 生态治理，站在消费者使用数据的业务链调用看数据是怎么被消费的，制定数据治理规范，让数据更为透明和易于使用；

• 通过网格编排的思想设计数据走向，使数据产品能够支持不同模块、不同域的衔接。

在 Data Mesh 架构下，治理的始终是具有业务价值的数据服务，而不是一个个的原始数据文件。Data Mesh 的架构逻辑如上图：底层需要可自服务的数据基础设施，至少具备稳定性和可伸缩性两项能力；基础设施之上，面向域构建一个个端到端的数据消费服务提供给上层业务，可以认为每一个服务对应的就是一个数据产品，比如某个数据仓库可能抽象成 Data Mesh 中的一个 Data Service，每一个 Data Service 会包含算力、存储和服务这三项。不同的数据服务之间会有一个数据服务注册和调度中心，可以让不同的 Data Service 形成业务所需要的一系列数据服务编排。另外，围绕数据服务中心会形成数据授信访问申请、元数据管理、数据服务管理等一系列能力。

如果从软件架构的视角来理解 Data Mesh，则微服务映射过来就是 Data Service，基于微服务编排设计出来的 Application 映射过来就是 Data Product，基于很多 Application 编排生成的网格 Service Mesh 映射过来就是 Data Mesh。

Data Mesh 目前有两种落地形态，一种是闭环服务，也就是一个平台提供工具的同时还提供结果管理服务，并且只能在平台内部完成全生命周期的管理，即 Data as a Service；另一种形态则是平台提供数据和工具能力，但是工具能力为可选项，业务可以使用自己的工具，也可以使用平台的工具，即 Data Platform as a Service。

3 会改变数据团队的工作吗？

同为大数据领域近几年诞生的新概念，Data Mesh、数据中台、湖仓一体可能会让很多人感到困惑：这三者有什么本质区别呢？

针对 Data Mesh 和数据中台的区别，白发川认为，数据中台是一个概念而非架构形态，它更多强调的是站在业务视角思考企业数据消费的形态，在通过数据中台理念梳理完数据的消费模式、业务场景之后，最终还需要用一个架构来承载和实现。而 Data Mesh 可以作为数据中台的一种实践形态。

针对 Data Mesh 和湖仓一体的区别，白发川则表示，湖仓一体主要是基于数据仓库、数据湖这样的成熟架构做整合，从体验和交互上来说减少了做一件事情需要完成的步骤，属于优化式架构，但它解决的问题只在于技术维度，解决不了业务团队瓶颈问题，也解决不了基础设施和业务解耦的问题。而 Data Mesh 首先从基础设施层面对架构做了一些调整，同时还定义了在这个架构下的团队分工协作。从架构层面来看，数据湖、数据仓库、湖仓一体跟 Data Mesh 实际上是可以并存的，而非对立或替代关系，在 Data Mesh 架构中，数据湖、数仓可能被包含在一个个 Data Service 中。

从另一个维度来看，数据湖、数据仓库或者湖仓一体架构的主要受众是企业的数据团队，只有数据团队需要关注这些架构。但 Data Mesh 的受众是数据团队和业务团队，他们都需要关心这个架构，这也是一个明显的差别。

Data Mesh 将数据所有权上移给了负责某一项功能的业务团队，他们可以按照自己更便于使用的方式去创建、接触元数据，对数据进行分类和存储。对应 Data Mesh 的架构来看，业务团队负责创建自己需要的 Data Service，而数据团队的工作更聚焦于底层数据基础设施，包括为 Data Service 初始化工作空间、将云厂商的组件和企业自己的底层平台能力组合包装成业务可用的方式（可以理解为迷你版的云）、Data Service 之间的调用能力封装等等。

这是否意味着 Data Mesh 改变了企业数据团队原有的工作内容呢？

白发川对此给出了否定答案，他认为，现在很多行业都在谈数字化转型，但当企业说数字化转型的时候，通常发生改变的只有数据团队，而业务团队却不受影响，这是有问题的。数字化并不等于数字团队，Data Mesh 实际上更好地定义了，当企业需要数据能力的时候，业务团队应该做什么样的改变。原来大家会笼统地认为凡是数据相关的都由数据团队做，导致整个数据团队从基础设施到业务完全耦合在一起。Data Mesh 其实是把数据团队和业务团队的职责边界做了更清晰的划分，使数据团队的职责更加聚焦和精简，从技术角度看对数据团队当前的工作不会有特别大的影响。不过过程中可能会涉及到一些人员的调整，比如原来数据团队中负责业务相关数据分析工作的人员会直接划到业务团队去，而关注业务无关的基础设施的人员则继续留在数据团队中。

4 现在是采用 Data Mesh 的好时机吗？

前文提到，包括 Zalando、Intuit、Netflix、JPMorgan Chase 等公司都已经在尝试实践 Data Mesh，但 Data Mesh 还不是一个适合所有企业广泛采纳的架构模式。尽管 ThoughtWorks 推荐“采纳”Data Mesh，但这一推荐有一个重要前提，即“风险可控”。

白发川表示，当下企业落地 Data Mesh 主要的难点和风险可以从两个角度来看：一是规划视角，需要评估对数据架构做改造的投入产出比；二是技术视角，过去从数据仓库到数据湖的转变可以认为是替代式架构（不是从数据仓库演进到数据湖，而是造一个全新的），而 Data Mesh 属于演进式架构，改造的模式和设计的思维方式都与从前不同，目前行业内在大数据演进式架构改造的人才和经验方面相对都是有缺失的。

其中，性价比是企业在考虑是否采用 Data Mesh 时首先要考虑的。不管是微服务也好，Data Mesh 也好，都存在一个最基本的底线成本。回顾前文提过的 Data Mesh 架构，它需要基于底层弹性基础设施来打造，可以认为云是做 Data Mesh 的起点，如果企业当前的数据架构不是基于云来做的，那从当前架构迭代到 Data Mesh 架构的过程中就需要更多改造步骤，比如要先做弹性化改造，这样初步投入的成本就会变高。此外，构建 Data Mesh 需要的投资还包括构建自服务的数据平台、支持对领域进行组织结构变更以长期维护其数据产品，以及一个激励机制，来奖励将数据作为产品提供和使用的领域团队等等。如果企业衡量改造的投入产出比之后，发现收益无法超过成本，可能 Data Mesh 就不适合。

除了考虑性价比问题，白发川建议企业基于三个维度来评估自己是否应该采用 Data Mesh，分别是规模化、常态化和高门槛。其中，规模化指的是企业存在大量的领域且数据接入、数据消费规模都非常庞大，比如有大量产生数据的系统和团队，或者多种数据驱动的用户场景和访问模式；常态化指的是数据的使用频率很高，而不是一次性的；高门槛指的是企业需要非常精通大数据的技术人员来驾驭自己的数据架构。如果这三点都符合，就意味着企业需要考虑数据团队和业务团队之间的分工问题了，Data Mesh 可能是一个解决办法。同时企业也需要结合自身的业务现状来评估，如果企业已经做了数据仓库、做了数据湖，但在前述三个维度下业务仍然出现了明显的不可工作或协作瓶颈导致数据平台跟不上业务发展节奏，那这可能就是一个考虑采用 Data Mesh 的比较好的时机点；反之，如果业务本身毫无问题，也就没有改造的必要了。

据白发川介绍，目前国内外有很多企业都已经在尝试实践 Data Mesh 的架构理念，尤其是一些数据规模特别庞大的企业，他们已经碰到集中式单体数据架构的瓶颈，开始探索向面向域的分布式数据架构转变以解决问题，只是他们可能没有将这个概念抽象总结成 Data Mesh。

当提及 Data Mesh 未来应用推广道路上可能遇到的挑战时，白发川特别强调了组织架构方面可能存在挑战。如前文所述，Data Mesh 并不仅针对数据团队，也不是数据团队单独就能做好的，它其实对应探讨的是在企业的业务上下文里面一种比较好的协作方式是什么样子的，需要几个团队承担什么职责才能做好这件事，并延伸到现有的团队需要做什么样的调整，以及在这样的调整下需要一套什么样的基础设施或软件来支持他们的工作。在白发川看来，数据中台、Data Mesh 都属于所谓的“CXO 工程”，Data Mesh 也需要企业自顶向下达成共识、形成决策并通过组织结构调整提供支持，否则可能也会遭遇类似于中台战略无法在企业顺利落地的窘境。

Data Mesh 标志着大规模数据分析架构和组织范式的转变，但要加速 Data Mesh 的实现，在开源或商业工具上仍存在巨大的缺口。对比微服务有 K8s，Service Mesh 有 Istio、Linkerd，目前还没有一款合适的工具可以帮助企业快速应用 Data Mesh。虽然使用现有技术作为基本构建块也是可行的，但在成熟的基础设施工具出现之前，很多企业可能还是会选择继续观望。

延伸阅读：
https://martinfowler.com/articles/data-monolith-to-mesh.html
https://martinfowler.com/articles/data-mesh-principles.html