Data mesh 是ThoughtWorks提出的一种数据治理和协作的模式： link: https://martinfowler.com/articles/data-monolith-to-mesh.html

当前企业数据平台的架构

中心化，单体化，领域无感的数据湖。

架构演进:

第一代：私有数据仓库+BI，大量无法维护的ETL job

第二代：数据湖的思路。复杂的大数据系统生态+极度专业化的数据工程师（理解是一个数据工程师维护一套系统?）。

第三代（当前）特征：

  1. 采用Kappa形式的流数据架构，实时的数据可用性。
  2. 批流一体
  3. 基于云服务

失败模式

中心化和单体化

中心化的目标：

  1. 从公司各个团队中摄入数据。
  2. 清洗、丰富、转化原始数据，满足一批消费者需求。
  3. 将数据交付给不同需求的业务团队。

单体化的数据平台可以拥有属于各种「领域」的数据。

问题：

  1. 数据源和数据增长。将数据存储在一处的假设会限制数据团队对数据源增长的响应能力。
  2. 公司关注点的演化和数据消费需求的增长。对数据的消费存在快速迭代的需求，因此，对数据的清洗丰富和转化的个性化需求也在不断增长，响应时间过长会导致组织摩擦。

分解耦合流水线（Coupled pipeline decomposition)

名词：结构量子（architectural quanta），高内聚的可独立部署组件。分解结构量子的原因是希望能够将团队分解成可以独立操作结构量子的小团队。小团队可以并发工作，提高组织的扩展性和速度。

根据数据处理阶段的流水线的不同阶段，数据平台可以分成独立的：

摄入、准备、处理、服务

等若干种结构量子。

问题：

这些阶段看似相互独立，但是其实服务于同一目的。流水线的各个阶段是高耦合的。分解后会不可避免的降低交付速度。是一种与变更轴正交(orthogonally to the axis of change)的分解。

实现一个新的功能不可避免的要对所有的结构量子协同。从这个角度看，单体平台才是结构量子。这样的分解是无效的。

隔离且所有权高度特化

高度特化的数据工程师与数据隔离。数据工程师按照技能分组，而不接触领域知识。

数据平台工程师需要:

  • 消费缺乏提供有效、正确信息动机的团队提供的数据。
  • 缺乏数据产生源头的领域知识
  • 在这种条件下，提供数据，满足各种各样的需求。

造成的情况：

  • 数据源的团队毫不关心数据。
  • 过载或者过大(over-streched)的数据平台团队
  • 疲倦的消费团队，为数据平台团队的排期大打出手。

Data Mesh

数据与：

  • 分布式领域驱动架构
  • 自服务平台设计
  • 产品思维

的融合。

数据与分布式领域驱动架构融合

考虑数据的局部性和所有权。

数据湖模式：领域数据流向中心化的数据平台。 新模式：领域自己保存数据，提供数据服务。(host and serve)

主要是所有权区别，即便一类数据技术上是存储在一个中心化的服务中，他的所有权也应当属于原先的领域。

面向领域的数据平台中，结构量子是领域而非流水线。

面向数据源的领域数据

源领域数据集代表业务的 事实 (facts)，与真实系统中产生的数据紧密对应。

例如：“用户与系统交互”会产生用户点击流。

理想情况下，线上系统和它的团队，不仅应该提供业务能力，也应该提供业务领域的事实。

同时，领域概念和数据源，并非总是一对一关系，有可能需要将多个数据源层面的数据集，转换为一个聚合的领域层面的数据集。

源数据领域应该提供：

  1. 领域事件流。
  2. 以一定时间范围聚合的历史快照。

源领域数据集和源领域系统的数据集应完全隔离。源领域数据集的数据量要远远大于系统的数据，而且更少会发生变更。因此应该与线上系统的存储完全隔离，采用面向大数据的存储。

源领域数据集期望能永久保存。

面向消费者的领域数据。

一部分领域与消费紧密对齐: 例如社交推荐领域，消费社交关系数据，创建对应的数据集。

这类数据集也可能有多种用处，比如：社交关系数据也可以用来作为「一同听歌的人」的推荐。

与源数据集不同的地方：

变更更多，适应某种特殊的访问模式。

面向领域的数据平台应该能够提供能力，从源头重新生成这类数据集。

采用分布式流水线作为领域内部实现

数据的流水线：清洗、准备、聚合、服务等等。

将流水线作为领域内部的实现细节。

领域数据集应该提供SLO，例如时效，错误率等等。

数据和产品思维结合

把领域数据看作产品持续对外提供，而非一次性交付。

对领域数据产品的几个要求：

  • 可发现。数据产品应该能够被简单的发现。例如实现中心化的目录。
  • 可寻址。应能够被软件简单的接入。需要有通用的规范，例如Kafka格式等等。
  • 可信任。制定相关的SLO。
  • 自描述语义和格式。
  • 统一标准，数据可互操作。
  • 统一权限控制。
  • 配置有数据产品owner和对应的数据工程师。数据产品owner应该负责数据产品的演化，满足Consumer的需求，持续衡量和提高数据质量，对数据的生命周期负责。团队也必须包括数据工程师来建设和运营团队内部的数据管线。领域数据工程师是软件工程和数据工程师的交集。

数据和自服务平台设计结合

为避免各团队对基础设施的重复建设，应组建公共的数据基础设施平台，维护领域无关的基础设施。

例如：

  • 可扩展的大数据存储
  • 静态和动态数据加密
  • 数据产品版本化能力
  • 数据产品结构定义
  • 数据产品去个人信息化。
  • 数据权限控制
  • 数据流水线实现和编排能力
  • 数据产品发现，目录注册和发布能力
  • 数据治理和标准化
  • 数据产品血缘
  • 数据产品监控、日志和报警能力
  • 数据产品质量指标
  • 内存缓存
  • 联合权限管理
  • 计算和数据本地性

自服务平台的指标是：创建新产品能力的前置时间。

总结

当前数据平台架构:

中心、单体、高度偶尔的流水线架构，由高度特化的数据工程师运营。

转换为data mesh：

分布式的数据产品，有独立的包含数据owner和数据工程师的全功能团队分别运营，使用共同的基础组件。

数据湖和数据仓库成为data mesh中的节点。

主要转变：领域数据产品成为第一关注点，数据湖的工具转为实现细节。

Refs

Data Catalog Platform: https://cloud.google.com/data-catalog/