DataMesh 在蚂蚁数据的实践

摘要：架构指的是系统的组织方式，包含组件、关系和原则。架构有多种形式，如组织架构、数据架构和企业架构等。蚂蚁对数据架构的定义是数据系统的组织方式，包括数据组件（如数据单元、数据应用、数据域）及其关系，以及各种数据架构原则。

导读本文将分享蚂蚁在数据架构方面的实践。

主要内容包括以下几大部分：

1. 数据架构介绍

2. 蚂蚁数据架构分析

3. 蚂蚁数据架构升级方案

4. 数据架构展望

分享嘉宾｜王高航蚂蚁集团高级技术专家

编辑整理｜王甲君

内容校对｜李瑶

出品社区｜DataFun

数据架构介绍

首先介绍一些数据架构相关的理论知识。

架构指的是系统的组织方式，包含组件、关系和原则。架构有多种形式，如组织架构、数据架构和企业架构等。蚂蚁对数据架构的定义是数据系统的组织方式，包括数据组件（如数据单元、数据应用、数据域）及其关系，以及各种数据架构原则。

在讲数据架构时，有两个需要注意的点。第一，区分数据的技术架构和内容架构，技术架构是数据领域中各种技术组件之间的关系（如 Lambda 架构），数据内容架构是指数据资产内容（如表、指标）的组织方式，本文主要讨论的是内容架构。第二，架构与框架的关系，架构关注结构，偏宏观和抽象；框架则注重规范，偏微观和实现。例如，DBT 中的目录结构属于框架，常见的三层架构（ODS/CDM/ADS）也偏向框架。

那么，数据架构到底有什么作用呢？我的理解是，数据架构的核心是应对数据系统不断增长的复杂性。数据系统从最初几个节点，逐渐发展成一个庞大复杂的网络，最终可能变得难以维护。架构的作用在于通过组件和关系的约束，隔离复杂网络，限制交互，从而降低系统的认知负荷和协作成本。简而言之，就是“分而治之”。这个理念在各行各业都有应用，关键在于如何合理地划分，后面会进一步探讨。

架构还需要有一个演进观，即随着业务的变化，架构也需要进行相应的演进。架构无法一蹴而就，一方面是因为我们的能力有限，无法预见五年、十年后业务的发展；另一方面是资源有限，即便有当下看起来理想的架构，完全实现也存在巨大的困难。

同时，当业务发展到一定阶段，架构需要及时跟进。业务变化包括商业模式、外部环境、新技术的变化，以及内部逐步累积的量变引起的质变。跟进方式主要有渐进式迭代演化和彻底重构，通常会采用渐进式方式。例如，我们在线应用的架构从支付宝一代演进到四代，蚂蚁的内容架构也在持续演进中。

常见的数据架构有几种模式。第一种是“烟囱模式”，主要面向各个 BI 或 AI 场景，每个业务线单独建立数据集市，每个数据集市从源头开始开发，导致重复开发。这种模式非常常见，虽然有时候大家不愿意承认，但确实普遍存在。它的优点是门槛低，能快速启动，支持业务场景高效运行。但不足之处也很明显：一是口径难以统一，不同场景的数据常常重复定义；二是重复开发带来的成本浪费较大，无论是计算还是存储。这种模式的适用场景包括快速试错、小规模可控的系统，或者对数据质量要求不高的业务。

第二种模式是大中台模式，源自阿里巴巴提出的“OneData”架构，核心基于维度建模，构建高品质、高可复用的数据公共层，包含明细和汇总数据，统一支持各业务。这套模式非常有效，长期支撑了阿里集团的多个业务。它的优点包括：第一，基于核心中间层的专家团队，能够构建可控的数据质量；第二，核心资产的复用提高了成本效率。

然而，随着时间推移，问题也显现出来：第一，在组织上，需要一个强大的中间层数据团队，这个团队容易成为资源瓶颈，尤其在业务快速发展的情况下，敏捷性不足；第二，中间层和应用层的边界不明确，尤其是轻度汇总与应用层之间，这种模糊的边界可能导致应用层出现烟囱开发，这也是蚂蚁曾经面临的问题。

另一个架构模式是领域驱动模式，国外通常称之为“DataMesh”，微软也推崇这种方式。其核心理念是通过领域驱动进行架构划分，每个领域以产品思维设计和实现数据服务，领域间通过数据合约协作，整体通过联邦式数据治理。该模式有几个优点：第一，领域边界清晰，有助于系统间协作；第二，领域内部相对稳定，有利于数据持续优化；第三，在保障对外服务的同时，可以灵活权衡内部需求，具备较高的敏捷性。

然而，这种方式也有不足，可能会导致领域间的数据存在一定的冗余，更大的挑战是需要在思维和文化上进行转变，因为数据要以产品方式提供服务，这是一种较大的模式转变。

蚂蚁数据架构分析

下面来介绍蚂蚁的数据架构。我们进行架构升级的背景是蚂蚁的数据系统熵增失控。举个例子，我们有一个业务场景，其内部包含 138 张表。当我们展开这 138 张表的上游，有近 4 万个节点，最长的链路有 52 层，平均链路长度为 16 层。在这样复杂的链路中，通过任务或链路进行长效管理几乎是不可能的。传统的数据管理，通过基线进行保障，显然在这种情况下是行不通的。因为链路过于复杂，让人无法判断每个环节是否合理，甚至都难以知道下游有哪些部分。

基于这种复杂网络，出现了几个典型问题。

不同业务资源相互抢占，“大锅饭”模式导致公地悲剧。各业务的计算资源复用，业务间相互抢占，若资源足够还好，一旦不足，便会互相争抢，最终可能导致整个系统无法正常运行。不同领域划分了各自的架构域，彼此割裂甚至冲突。由于网络复杂，要进行专项治理（如质量、成本、效率等），通常会组建治理小组。然而，质量、成本和效率目标之间往往存在冲突，质量提升往往带来成本增加，两个目标难以平衡。如果各领域各自治理，这种冲突的权衡就变得更加困难，决策需要上升到更高层级，效率低下。任务间随意依赖，导致链路冗长，影响数据准确性和时效性。因为链路复杂，优化变得极其困难。

针对这些问题，我们进行了分析。首先，根本原因在于数据架构中的很多概念不清晰，基础概念之间的关系也不合理，导致了问题的产生。左侧是我们之前梳理的架构相关的概念和关系，这里有几个问题：

域的定义不清晰，划分职责模糊，导致不同场景下各自为政，缺乏协同，保鲜困难。这里研发视角拆分了板块、主题域、单元等。质量、成本、合规的治理同学又各自划分了各自视角的业务域，只为各自的单词治理目标负责。基础概念命名不够简洁明了，导致不同岗位理解不一，难以达成共识。例如，“板块”、“主题”与“单元”这些概念，离线数据研发团队理解相对容易，但在线研发、算法等岗位对这些概念的理解成本较高。基于模糊的概念进行实践，最终会带来各种问题。逻辑架构与物理资源的关系不协调，即一个物理计算资源对应多个逻辑架构域，导致资源争抢，出现“大锅饭”现象，影响系统效率和稳定性。

第二个原因是大中台模式带来的弊端。这种模式曾经高效，但随着业务的发展，问题逐渐显现：

随着数据系统复杂度的增加，此架构的一些问题愈发严重。中间层和应用层的边界不清晰，天然存在一些协作问题，会导致应用层的“小烟囱”越来越多，中间层反而越来越薄，违背了这个架构的初衷。之前架构未对应用层进行规范和管理。大家普遍认为应用层只是简单复用，中间层稍作加工。但结果是应用层不断膨胀，且没有有效管理，导致层级混乱、无序，熵增严重。在组织层面，集团层对中台的支持逐步削弱，数据公共层的组织保障不足，导致这个架构模式在实际运作中面临挑战。

蚂蚁数据架构升级方案

基于前述问题，我们设计了一个数据架构的升级方案。首先，在概念和关系上进行了重新梳理。顶层统一采用“域”这一概念，避免了多个概念的交织，使其适用于各类业务场景。域基于业务本质对数据进行抽象，分为 1/2/3 三层。例如，支付宝用户运营是一个三层域，每个域都有一个统一的权责机构，由架构师作为总负责人，下面设有效率、成本、质量的子负责人。在架构师的领导下，各项工作按照指标进行权衡取舍。

域下设为数据应用，针对特定业务场景研发的代码及部署环境。域与数据应用有独立的资源配额，可能存在多个配额关系，且是一对多的关系。数据应用下有数据单元，是数据应用内部的子模块。数据单元的代码组织依赖于框架，如分层框架或业界常见的 DBT 框架。数据单元下是代码库，包含具体的目录结构。

此外，域需要基于领域驱动设计。每个域都有其核心概念模型，这些模型决定了域的本质。因此，提倡在域内进行数据建模，从概念建模到逻辑建模，再到物理建模，这些模型共同构建了域的信息模型。

新架构的核心思想仍是分而治之。如何分？采用领域驱动的方式进行架构拆分。如何治？领域拆分后，按权责对等实现联邦自治，而非依赖一个大中台进行统一治理。基本原则包括：

单一职责原则：根据业务本质划分架构域，使架构更加稳定、易理解且便于优化。需要强调的是，复用并不是首要原则，而是单一职责原则下的自然结果。单纯追求复用会导致混乱，因为复用是一个模糊的概念，各种方式都可以实现复用，且在一个复杂系统里，过度追求复用容易导致耦合过深，带来更严重的问题。责任制原则：每个架构域应有一个权责机构，负责域内指标的权衡和持续改进。资源隔离原则：不仅在逻辑上分离，还要在物理层面进行资源隔离，避免公地悲剧，确保各域能独立运行。

基于上述原则，具体如何实施拆分呢？关键在于架构域和数据应用的拆分。架构域应从业务本质出发，与业务和在线架构同学共同讨论，确定哪些是独立域，每个域的职责是什么。这样可以保持架构的稳定性。理论上，架构域应与在线架构域映射，但映射本身不是目的，而是架构师对业务领域模型达成共识的结果。

一个常见的检验方法是：能否用一句话清晰描述一个域的核心职责。之后，拆分数据应用时需要考虑几个优先级因素：

业务模块：按照领域驱动的思路，优先按业务模块进行拆分；组织结构：遵循康威定理，不同组织之间的协作难度较大，因此组织架构需要纳入考量；层级：考虑不同业务层级如 CDM/ADM 等，岗位工种分为数据、算法、BI 等，或保障机构分为高保基线任务和普通任务。

此外，建议单个数据应用的协作人数不超过 20 人。我们发现，许多大数据应用的团队人数竟达到上千，实际上，一个人无法有效管理这么大规模的团队，20 人已是极限。超过这个人数，管理往往变得流于形式，无法实施有效的管理。

在新架构实施过程中，各个角色都会有明确的职责。比如，域架构师负责统筹整个架构的运作，数据应用负责人、质量负责人、成本负责人则负责各自的工作领域。

在架构实施中，除了明确的角色关系，还需要制定架构规约以确保权责对等。规约分为三级：

公司级规约：由公司架构和治理小组讨论制定，分为强制类和建议类。强制类包括编码约束、容量管理、质量管理和合规管理；建议类则允许下级根据需要进行重写和覆盖，如编码规范和研发流程。架构域级规约：由各架构师根据实际情况制定，包含个性化的编码规范和研发流程。数据应用级规约：主要关注个性化的研发流程，提供一定的自由度。

刚才讲的是宏观层面的内容，接下来是微观层面的一些架构实践。在新数据架构下，我们提倡模块化研发和数据责任制。模块化研发的核心在于每个模块是一个独立的子域，各模块之间有清晰的边界和隔离。模块内部逻辑应对外不可见，但对外需有开放层，明确服务接口，这与数据产品化中的数据服务延伸一致。

数据产品化要求明确服务接口，定义清晰的服务承诺，以实现高内聚、低耦合。为了保障这些承诺，我们提出了 SLO 协议。在每个模块对外提供服务时，需要明确服务内容和服务等级，通过协议确保生产者与消费者之间的责任对接，从而让权责更加清晰。

我们的产品提供了模块解耦工具，以实现模块内外的隔离，每个数据表都可以设置访问级别：

私有级别（Private）：仅数据单元内使用，通常是临时表或内部的 adm 表。受保护级别（Protected）：仅限本数据应用内部使用，或以白名单方式开放给有限的数据应用，主要是 mid 表或部分 adm 表。公开级别（Public）：这是对外开放接口层，为其他所有域提供服务，是架构域的核心资产，一般是中间层表或少部分的 adm 表。就算是 adm 表，只要能达到其 SLO 承诺的保障级别，也可以视为优质资产，资产的质量与其命名前缀无关，因为现实中很多 cdm 表也是从 adm 演化而来，不必过于纠结命名。

SLO 签约有专门的产品化页面，针对不同的过程进行承诺，如 DQC 覆盖、应急处理以及结果相关的承诺，如时效和质量，所有这些都可以进行在线签约。

在领域驱动设计中，数据域和模块之间有几种协作关系：

共享内核（Shared Kernel）：各域共享并共同维护公共数据，实现充分复用，最理想的情况如全局一致性维度表。客户-供应商模式（Customer-Supplier）：上下游之间有清晰边界和明确定义的交互接口，双方需达成合作意愿。顺从者关系（Conformist）：下游依赖上游，但上游不承诺责任，形成盲从的局面。防腐层（Anticorruption Layer）：为了稳定，建立防腐层保护自己，即使上游没有承诺。

现实中，理想的共享内核较难实现，大多数情况下依赖顺从者模式。这种模式容易导致各种扯皮。我们希望能够尽可能实现客户-供应商模式，如果无法实现，则通过防腐层来保护自己，减少顺从者关系的情况。

在这个架构下，治理模式是联邦自治，即在统一规范下治理权责下放。每个架构师制定并推动本域架构规约的落地，架构指标负责人和数据应用团队持续优化应用内各项指标和横向比较。如果希望参与考核评价，对于平台产品而言，关键是做好自动化和智能化治理，能够清晰了解各域情况，提供优化建议，并实现自动化治理，这是整个治理模式的核心。

数据架构展望

上一章节中讨论了架构实践的方法，下面来看一下数据架构的前景，尤其是从网络科学的角度来看待数据架构。在许多方面，数据系统可以被看作是一个复杂网络，首先是“复杂”，其次是“网络”。复杂性指的是局部和整体之间的非线性关系，也就是不能从局部去推测整体，这就是一个系统的复杂性。而网络则是由点和线组成的，因此复杂网络就是由大量节点和连接他们的边组成的网络，具有复杂性。例如，社交网络，蛋白质相互作用的网络，以及离线的数据调用，都可以被看作是复杂网络。上图最右边是一个实际的例子，蚂蚁离线数据应用调用网络关系就是一个复杂网络。

那么具体是什么样的复杂网络呢？其中一种常见的类型是无标度网络。无标度网络的数学定义较为复杂，核心在于其度的分布，即每个节点与其它节点连接的边的数量。如果度分布是幂律分布，我们就称之为无标度网络。简单来说，无标度网络有两个典型特点：一是拥有许多枢纽节点，即网络中部分节点连接非常多，像一些数据节点可能有成千上万的下游；二是具有超小世界性质，由于枢纽节点的存在，任意两点之间的连接可以非常短。这与现实中的“六度分隔理论”相似，后者也是超小世界性质的一种体现。无标度网络在现实中非常常见，比如互联网、蛋白质相互作用网络、电子邮件网络，以及论文引文网络，都是无标度网络。

通过测算，我们发现蚂蚁的数据系统正是一个无标度网络。上图中可以看到蚂蚁数据系统的度分布，无论是出度分布还是入度分布，都具备典型的无标度网络特征。

作为一个无标度网络意味着什么呢？我们先来看一下无标度网络是如何形成的。从网络动力学的角度来看，主要有两个原因：一是生长，即网络是一个不断增长的过程，节点持续增加；二是偏好连接，即新节点倾向于和链接数高的节点相连。正是这两个因素，推动了网络演化，最终形成了无标度网络的结构。

无标度网络有如下几个重要性质：

良好的鲁棒性，即对随机故障具有较强的抵抗力。如果随机删除网络中的一个节点，整个网络的连通性破坏较小。这是因为枢纽节点虽然连接多，但被随机删除的概率较小，枢纽节点的存在有助于维持网络的完整性。脆弱性，对攻击不耐受。如果针对枢纽节点进行有针对性的攻击，网络则会迅速瘫痪。例如，互联网在遭遇随机故障时，需删除 92% 的节点才能断开，但如果针对枢纽节点攻击，仅需删除 16% 的枢纽节点，网络就会崩溃。低传播阈值。在无标度网络中，即使病毒传播率很低，由于枢纽节点的存在，它依然能够在整个网络中传播开来。高临界免疫率。临界免疫率指的是要阻止病毒传播，需要免疫系统中节点的比例。当免疫节点占比超过某个阈值，病毒传播就会被有效阻止。在无标度网络中，必须覆盖大量枢纽节点，才能确保阻止病毒传播。

这些无标度网络的性质在我们的数据系统中有什么作用呢？结论是，从无标度网络的特性来看，我们的数据系统是一个脆弱的网络系统。这种脆弱性体现在：

数据系统对攻击不耐受，这是无标度网络的特性，但在公司内部，这种情况影响较小，因为通常不会存在有针对性的攻击。无标度网络具有低传播阈值和高临界免疫率的特性，同样适用于我们的数据系统。这意味着数据异常，比如内容出错或延迟等，很容易在整个网络中传播，而要阻断这种传播，需要达到很高的免疫率。数据系统具有低鲁棒性，这与无标度网络的高鲁棒性恰恰相反。无标度网络的高鲁棒性是因为网络中的节点分支是冗余的，但在我们的数据系统中，每个节点都是唯一的，并处于有状态的运行中。这意味着，只要有任何一个节点失败，下游都将无法继续运行，因为没有其他路线可以替代，从而导致整个系统的中断。因此，我们的数据系统具有很低的鲁棒性，是一个非常脆弱的系统。

这种脆弱性为我们带来了一些启示：

做好系统中枢纽节点的免疫保护非常重要。在数据系统中，这些枢纽节点往往是我们称为精品资产或核心资产。如果我们能够保护好这些枢纽节点，将会提高整个系统的传播阈值。但是，免疫阈值和传播阈值之间是非线性关系，我们需要对网络中大于某个度的节点进行保护，才能显著提高传播阈值。因此我们需要有耐心，逐步做好对核心资产的保护。对于整个架构的变动，我们可以尝试通过网络建模仿真来预测其长期影响。例如，我们可以模拟规约变动和结构变动对整个网络参数的影响，通过模型预测它们的长期效果。巴拉巴⻄-阿尔伯特演化⽹络模型就是一种经典的模型。面对复杂的网络系统，我们需要从传统的思维转向复杂性思维。我们不能仅仅依赖一种确定性的控制方法，而应该从复杂性的角度去理解和管理网络。虽然我们还没有特别多的产出，但我们正努力探索这个方向。