随着数字化时代的到来，近几年数据领域的新技术概念不断涌现，无论是数据湖、湖仓一体、流批一体、存算一体、数据编织抑或数据网格，很多还爬上了Gartner曲线，其中数据网格备受关注，数据网格从字面意思来看挺抽象的，会劝退很多人，但当你深入去理解这个概念时，才发现奥妙无穷。

一、数据平台架构演进历史

要理解数据网格，先得回顾下数据平台的发展历史，它们的典型代表分别是数据仓库、数据湖及湖仓一体。

第一代：数据仓库

1980年代中后期，为解决数据库面对数据分析的不足，孕育出新一类产品数据仓库。让我们先来看下数据仓库的定义，数据仓库（Data Warehouse）是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策和信息的全局共享。

数据仓库对于数据的处理可分为数据集成（装载）、数据加工（ETL）、数据汇聚、数据展示及挖掘。数据经过这一过程，被抽取到数据仓库中，并严格按照预先定义的模式被装载进来，经过多层加工形成数据集市，并最终提供给终端应用或进一步供挖掘使用，主要场景包括编制报表、发布下游数据集市(Data Marts)，以及支持自助式商业智能等。

第二代：数据湖

随着数据规模扩大，对数据承载能力（容量、算力）的要求也不断增大，数仓架构的扩展能力面临考验，规模的扩展会面临大量资源的投入，但硬件资源缺乏弹性，会导致高峰时资源不足，低谷时资源闲置浪费问题。针对数据类型，也不再局限于结构化数据，更多半结构化、非结构化数据需要被利用起来，传统的数据仓库架构面临诸多的挑战。

相比于数据仓库，数据湖是一种不断演进中、可扩展的大数据存储、处理、分析的基础设施。它就像一个大型仓库，可以存储任何形式（包括结构化和非结构化）和任何格式（包括文本、音频、视频和图像）的原始数据，数据湖通常更大，存储成本也更为廉价。结合先进的数据科学与机器学习技术，能提供预测分析、推荐模型等能力。

数据湖与数据仓库核心区别在于：数据仓库中，数据存储的结构与其定义的schema是强匹配的，也就是先建模再使用，简单点说，数据仓库就像是一个大型图书馆，里面的数据需要按照规范放好，你可以按照类别找到想要的信息，存储在仓库中都是结构化数据，可以直接消费。

而数据湖存储其中的数据不需要满足特定的schema，数据湖也不会尝试去将特定的schema施行其上，任何格式的数据都可以扔进数据湖。数据使用通常会在读取数据的时候解析schema（schema-on-read），当处理相应的数据时，将转换施加其上，也就是说，数据湖对于入湖的数据不做任何规范，只有在于使用时才定义存储格式以便分析使用。

第三代：湖仓一体

可以看到，数据湖和数据仓库都有各自的优势和不足，但不难发现，二者在某些层面是非常互补的，于是乎，2020年，大数据DataBricks公司首次提出了湖仓一体（Data Lakehouse）概念，希望将数据湖和数据仓库技术合而为一，依据DataBricks公司对Lakehouse 的定义，湖仓一体是一种结合了数据湖和数据仓库优势的新范式，在用于数据湖的低成本存储上，实现与数据仓库中类似的数据结构和数据管理功能。

湖仓一体是一种更开放的新型架构，有人把它做了一个比喻，就类似于在湖边搭建了很多小房子，有的负责数据分析，有的运转机器学习，有的来检索音视频等，至于那些数据源流，都可以从数据湖里轻松获取。

二、数据平台遵循集中化的范式

但无论是数据仓库，数据湖还是湖仓一体，它们都有一个共同的范式，就是以数据物理集中化为原则的、中心式，单体式的架构。

这种集中化的架构有三个特点，如下所示：

第一、统一采集企业的所有数据到一个数据平台。

第二、统一对数据进行清洗、转化、处理及分析。

第三、统一对外提供数据服务，包括数据集、API等等。

虽然为了适应业务灵活分析的需要会产生各种数据集市，但这些数据集市的数据都是基于集中化的数据平台打造的，本质上仍然是集中化架构的延续。

为什么数据一定要集中到一起呢？

因为大家对于数据分析有一个根深蒂固的认知，即数据具有网络效应，多维度的数据只有融合分析才能产生发挥出数据的最大价值，而要实现融合分析的前提是数据要进行集中化的管理，如果数据以物理隔离的形式存在，以现有的技术手段不足以实现数据的融合分析，打破数据孤岛也是数据治理领域最为重要的课题。

三、集中化数据平台面临的挑战

数字化时代的使得使得集中化数据平台面临体系架构、技术架构、组织架构等多方面的巨大挑战。

第一、无处不在的数据使得集中化数据平台对各类数据进行采集的响应能力变弱，企业拥有越多来源的数据，集中化管理的压力就越大，比如某些企业大数据平台建设了很久，但新增的数据寥寥无几，并不是说没有新数据，主要在于根本没有能力去实时感知数据源和数据的变化。

第二、集中化的数据平台意味着要进行大量的数据搬迁，传统的批处理方式很容易造成数据延迟、不一致的现象，这影响到了下游应用的准确性。

第三、数据应用需求的大幅增加使得集中化平台对各类数据进行处理和分析的响应速度变慢，大量的领域需求被耽搁或拒绝，各个领域想尽办法另起炉灶。

第四、数据工程师原来以创建最大的整体（即大数据平台）而自豪，现在却处于业务孤立的境地，因为企业将面向领域的数据所有权转移到了集中化平台上的数据工程师，集中化平台上的数据工程师对各领域的来源数据缺乏了解，也缺乏领域专业知识，越来越难以满足各领域的数据消费需求。

四、领域驱动设计的启示

OLTP领域总是变革的先行者，Devops首先在OLTP大行其道，然后敏捷的春风刮到OLAP领域，导致了DataOps的出现，同样的情形估计又要发生一遍。

埃里克·埃文斯（Eric Evans）的著作《领域驱动设计》（Domain-Driven Design）对现代架构思想以及组织建模产生了深远的影响。它通过将系统分解为围绕业务领域功能构建的分布式服务来影响微服务体系结构，从根本上改变了团队的组成方式，从而使团队可以独立自主地拥有领域能力。尽管在OLTP引入了定向领域分解和所有权，但在OLAP却忽略了领域的概念，DDD提倡的领域绑定上下文是一种强大的工具，实际可以用来设计数据集的所有权。

设想一下阿里这个庞大的数据帝国的推荐引擎设计，如果在优酷上需要基于淘宝商品的交易数据进行推荐，与其将淘宝、优酷的数据统一采集到中央数据中台然后打造推荐模型以供优酷调用，还不如淘宝这边提供交易数据的服务接口由优酷来统一调用来得方便，当然物理存储啥的肯定可以采用诸如阿里云之类的中心式架构，我不知道阿里具体是怎么干的，但在业务规模和数据规模巨大的企业，领域驱动的数据服务实践也许早就存在，因为没有一个数据团队能同时搞定多个领域的业务。

下面这张图是个示例，对于“推荐领域”图数据集来说，如果还有其它领域（例如“新艺术家发现领域”）对其有用，则可以选择提取和访问该领域，这要求我们从传统ETL模式转移到跨所有域的服务调用。

五、数据网格的定义和原则

针对传统集中化数据平台的困境，Zhamak Dehghani 于 2019 年 5 月撰写了一篇论文，提出了数据网格的概念。在这篇文章中，Thoughtworks 顾问描述了集中式、单体式和与域无关的数据平台的局限性。

这些平台通常采用专有企业数据仓库的形式或复杂的数据湖，其中包含“数千个无法维护的 ETL 作业、表格和报告，只有一小部分专业人员才能理解，从而导致对业务的积极影响未充分实现”，根据 Dehghani 的说法，这些数据“由一个由超专业数据工程师组成的中央团队运营，这些工程师充其量只能支持一些研发分析”。数据网格旨在通过专注于领域驱动的设计来解决这些问题，并引导领导者走向“现代数据堆栈”，以实现元数据和数据管理的集中化和分散化之间的平衡。

Thoughtworks认为，数据网格是一种面向分析和机器学习的技术方法，以去中心化的组织和技术方式分享、访问和管理数据。数据网格希望创建一种社会技术方法，旨在规模化的获取数据中的价值。从本质上讲，它创建了一个可靠的数据共享模式，与组织同步发展并持续拥抱变化。

IBM认为，数据网格是一种去中心化的数据体系结构，按特定业务领域（例如营销、销售、客户服务等）来组织数据，为给定数据集的生产者提供更多所有权。 生产者对领域数据的理解使他们能够设定专注于文档、质量和访问的数据治理策略。反过来，这可以在整个组织中实现自助服务。虽然这种联合方法消除了与集中式单体系统相关的许多操作瓶颈，但并不一定意味着您不能使用传统的存储系统，如数据湖或数据仓库。这只是意味着它们的使用已经从单一的集中式数据平台转变为多个去中心化的数据存储库。

为了实现数据网格的目标，Dehghani提出了数据网格的四个原则，包括按领域对数据的所有权和架构去中心化、数据即产品、自助式数据基础设施及联邦式计算治理。

1、按领域对数据的所有权和架构去中心化

数据网格的核心是去中心化的，并将权力下放，将其分配给最接近数据的人，从而能够支持持续的变更和扩张，它比数据湖具有更好的扩展性，因为新的数据源或新的数据消费者只意味着添加一个新的域（数据产品），而不是重新访问整个数据湖。

为了实现这个目标，我们需要构建一个按域划分的数据架构。在此架构中，领域与组织其他部分的接口不仅包括交易操作能力，还包括对域所服务的分析数据的访问。以下示例演示了面向领域的数据所有权原则，每个域可以公开一个或多个操作型 API，以及一个或多个数据API：

这种去中心化的组织架构有点像华为数据之道中提到的业务负责制的数据管理责任体系，华为按分层分级原则任命数据Owner，在公司层面设置公司数据Owner，在各业务领域设置领域数据Owner，这样既能确保公司数据工作统筹规划，也能同时兼顾各业务领域灵活多变的特征。

各领域数据Owner在公司数据Owner的统筹下负责所辖领域的数据管理体系的建设和优化。各业务部门是执行规则、保证数据质量，进而推动规则优化的关键环节。通过主管结构正式任命各数据主题域和业务对象的数据Owner和数据管理，数据Owner的职责包括数据管理体系建设、信息架构建设、数据质量管理、数据入湖和数据服务建设等等。

大家肯定很困惑，领域拥有数据的所有权似乎是天然的，怎么能说是进步的理念呢？现在数据集中化的目的不就是为了剥夺这种权力以便让其它领域也可以访问到领域的数据吗？

问题的关键在于原来的领域虽然拥有数据的权力，但并没有承担分享的义务，这引发了数据集中化管理的变革，但传统集中化的数据平台做过了头，在各领域数据支撑上力不从心，数据网格希望采用分布式的架构来解决集约化和灵活性的矛盾，让数据所有权回归领域，但需要承担对外数据服务的义务。

2、数据即产品

传统对集中化数据的访问通常需要先进行多次沟通，提交工单等待批准，数据网格希望减少生产者交付高质量数据的阻力，同时使消费者能快速地探索、理解和使用数据。

在过去的十年中，OLTP致力于用产品思维提升对外服务能力，包括打造丰富的 API（应用程序接口）体系、提供优秀的开发体验（可发现且易于理解的 API 文档，API 测试箱及密切跟踪质量的关键绩效指标）等等。

为了使分布式数据平台获得成功，领域数据团队也必须将产品思维应用于他们提供的数据集，将数据视为独立的产品，承担起提升数据质量的责任，包括准确性、一致性等，确保数据可供发现、检索、理解、值得信赖并有安全性的保障，领域数据产品需要具有以下基本特征：

（1）可发现的

数据产品必须易于发现。常见的实现方式是对所有可用的数据产品及其元信息（例如其所有者，来源，样本数据集等）编写目录。此中心式可发现性服务使组织里的数据消费者，工程师和科学家能够轻松找到他们需要的数据集。每个领域数据产品都必须在此中心式数据目录中注册以方便查询。请注意，这里的观点转变是从单一平台提取数据，到以可发现的方式将其数据作为产品提供到每个领域。

（2）可寻址的

在分布式体系架构中要制定通用的标准，确保数据产品有一个唯一的访问地址，不同领域存储和提供数据集的格式不同，事件可通过 Kafka 进行存储和访问，而数据集可使用 CSV 文件或序列化 Parquet 文件的 AWS S3 进行存储和访问。

（3）可信赖且真实的

没有人会使用他们不信任的产品。在传统集中化数据平台中，采集的原始数据质量往往参差不齐，需要花费大量时间进行清洗和转化。为了实现根本性的提升，领域数据产品的所有者要从源头解决数据质量问题，并通过元数据服务（比如血缘分析）来提升信任度和使用体验。

（4）自描述的语义和语法

优质的产品往往所见即所得。为了降低数据工程师和数据科学家使用数据集产品的门槛，需要对数据集的含义进行充分描述，最好以样本数据集作为示例，数据schemas 即域元数据是提供自助服务的起点。

（5）可互操作并受全球标准约束

分布式领域数据体系结构需要具备对跨领域的数据进行连接、过滤、整合的能力，其中的关键是遵循统一的标准和规则，这种标准化工作的共同关注点包括字段类型格式化，跨不同领域识别多义词，数据集地址约定，通用元数据字段，事件格式（例如 CloudEvents）等，互操作性和标准化是构建分布式系统的基础支柱之一。

（6）安全并受全局访问控制

无论架构是否中心化都必须确保产品数据集的安全性。在分布式的面向领域的数据产品中，对每个领域数据产品都要进行精细的访问控制，访问控制策略可以被集中定义但也可以应用到每个单独的数据集产品上。使用企业身份管理系统（SSO）和基于角色的访问控制策略是实现产品数据集访问控制的便捷方法。

（7）领域数据跨职能团队

领域需要增加数据产品经理和数据工程师。数据产品经理要围绕数据产品的愿景和路线图做出决策，要关注消费者的满意度，不断衡量和改进其领域拥有和生产的数据的质量和丰富性，要负责域数据集的生命周期管理，在域数据消费者的需求之间取得平衡，要为数据产品成功定义关键绩效指标 (KPI)，比如数据产品实现周期。

为了对域内数据进行优化改造，领域必须拥有数据工程师，从而与软件工程师形成互补，数据工程师虽然拥有数据开发和建模技能，但在构建数据资产时缺乏软件工程标准实践，比如持续交付和自动化测试，同样，软件工程师通常也没有使用数据工程工具集的经验，消除技能孤岛有助于创建更大的数据工程技能库。在这方面，我们已经观察到DevOps运动产生的授粉效应，比如SRE新型工程师的产生。

数据产品涉及数据、代码资产（包括生成它的代码和交付它的代码）、元数据和相关策略。数据产品可以作为 API、报表、表或数据集在数据湖中传递，数据产品应由相同的组件构成，具体包括：

（1）数据

不同数据库、数仓以及数据湖内的运营、分析和交互数据，按照产品所有者各自负责的域进行组织。

（2）数据事件

定义和描述与数据产品相关的所有状态变化、命令或数据传输；这类事件可能由多种来源触发，包括数据产品 API（每个请求都可以是一个事件），数据变更捕获（数据中的每个变化都是一个事件），以及数据目录变更（元数据的变更事件只会向订阅者发布）。

（3）数据产品 API

使数据产品内的数据可以按照统一、一致、符合行业标准规范的约定进行访问，比如 OpenAPI 或 GraphQL、MQQT、gRPC 等机制。

（4）数据产品目录

描述位于数据产品中的数据，同时提供用户界面和 API 接口，方便用户和机器消费数据产品；数据产品目录整合在企业数据目录中，对所有数据产品提供统一的企业视图。

（5）数据产品变更捕获

捕获数据产品中所有的数据变化，并将这些变化通知订阅用户，从而简化数据产品元素在组织内和更大范围间的传播，例如公司内需要保证分析和运营数据库的一致、例如，“账户”域就有可能触发对单个“客户”域内的数据变更。

（6）数据产品变更/审计日志

跟踪和记录数据产品的所有变化，以支持联邦治理和审计要求。

3、作为平台的自助数据基础设施

将数据所有权分配给领域的主要问题之一是可能存在重复工作。幸运的是，将通用基础架构构建为平台已经是众所周知的问题，将领域不可知的基础架构功能收集和提取到数据基础架构平台中，使数据域能够自行生成其数据产品。他们需要能够使用与用户相关的工具和流程来定义其数据产品，而无需对中央平台或中心平台团队具有很强的依赖性。

在数据网格中，你拥有自主团队开发和管理自治产品，你不能有需要专业知识才能操作的专用工具是基于网格的平台的核心基础。自助数据基础架构的成功标准是减少“创建新数据产品的时间”，这将引导“数据产品”功能所需的自动化。

将数据基础架构构建为平台的关键是（a）不包含任何特定于领域的概念或业务逻辑，使其保持领域不可知性（b）确保平台隐藏了所有潜在的复杂性和提供了数据基础架构组件自助服务的方式。自助数据基础架构作为平台向用户（领域的数据工程师）提供的功能种类繁多，比如：

可扩展的多语言大数据存储

加密静态和动态数据

数据产品版本控制

数据产品架构

统一的数据访问控制和记录

数据管道的实现和编排

数据产品发现，目录注册和发布

数据治理与标准化

数据产品监控/报警/日志

数据产品质量指标（收集和共享）

内存中数据缓存

联合身份管理

4、联邦式计算治理

如前所述，数据网格遵循分布式系统架构，包括一组具有独立生命周期的独立数据产品，由可能的独立团队构建和部署。然而，对于大多数用例而言，为了以高阶数据集、洞察力或机器智能的形式获得价值，这些独立的数据产品需要互操作，能够关联它们、创建联合及查找交点等等。

为了使任何这些操作成为可能，数据网格实现需要一个治理模型，该模型包含去中心化和域自主权、全局标准化的互操作性、基于动态拓扑的平台自动执行决策。由域数据产品所有者和数据平台产品所有者联合领导的决策模型，具有自治和域本地决策权，同时创建并遵守一组全局规则——适用于所有数据产品及其接口的规则——以确保健康和可互操作的生态系统。

这是一项艰巨的工作，要思考如何保持中心化和去中心化之间的平衡，哪些决策需要本地化到每个域，哪些决策应该针对所有域全局进行，最终，全局决策只有一个目的，即通过数据产品的发现和组合创造互操作性和复合网络效应。

六、总结

数据网格是一种架构和组织范式，它挑战了我们的传统观念 , 即必须将大量的可分析数据集中起来才能使用，将数据放在一起或让专门的数据团队来维护。数据网格认为，为了推动大数据创新，领域必须是数据的所有者并将数据作为产品以提供服务（在自助数据平台的支持下，抽象数据产品服务所涉及的技术复杂性），还必须通过自动化的方式实现一种新的联合治理形式，以支持面向领域的数据产品间的互操作性、去中心化、互操作性以及数据消费者体验，这是数据创新民主化的关键。

如果组织拥有大量的领域，包括大量产生数据的系统和团队，或者多种数据驱动的用户场景和访问模式，那么数据网格也许是一种很好的选择。