简介： 聚焦比较容易混淆的Data Fabric和Data Mesh这两个概念，尝试说明这两个概念要解决的问题、架构特征以及可行的技术栈，距离成熟还有哪些不足，以及围绕两个技术领域跟我们做的大数据技术服务之间的关系。

作者 | 王磊(汐衍)

来源 | 阿里开发者公众号

问题与挑战

背景

大数据平台建设有其天生的复杂性，每一年都在推陈出新，从WareHouse、DataLake到LakeHouse，各种各样的Batch、Stream、MPP、Machine Learning、Neural Network计算引擎，对应解决的场景和组合的方式非常个性化，建设过程会遇到包括技术层面、组织层面、方法论层面种种问题，【我爱线报网】包括存储计算组件选型、离线实时湖仓架构方案设计以及场景化的性能分析，随着时间推进也会出现持续的组织管理、数据和平台运营、扩容、稳定性优化等问题，出现多个平台共存，存储和计算集群技术栈多样化以及数据分散等常态化问题，面临保留原架构还是推倒重来迁移到新的平台的困扰，有没有一套Architecture FrameWork能够屏蔽底层技术和开发细节，Data Fabric、Data Mesh似乎是为了解决这个问题而生，从技术和方法论的角度探讨如何影响大数据平台的建设、数据工程和架构持续演进。

本文重点聚焦在相对比较容易混淆的Data Fabric和Data Mesh这两个概念，尝试说明这两个概念要解决的【我爱线报网】问题、架构特征以及可行的技术栈，距离成熟还有哪些不足，以及围绕两个技术领域跟我们做的大数据服务之间的关系。

大数据技术栈

大数据组件多样化，底层存储、数据格式、计算表达解析、计算引擎（MR、DAG、MPP等不同的逻辑计划&物理计划生成和优化器）、调度、缓存、血缘、数据集成在对应组件集合中可以看到很多选择。大数据产品不存在银弹，在满足不同的场景通常需要将大数据的架构像积木一样灵活的组合。

常见的技术组件如下：

系统平台 （Hadoop、CDH、HDP）云平台 （AWS、GCP、Microsoft Azure）监控管理 （CM、Hue、Ambari、Dr.Elephant、Ganglia、Zabbix、E【我爱线报网】agle、Prometheus）文件系统 （HDFS、GPFS、Ceph、GlusterFS、Swift 、BeeGFS、Alluxio、JindoFS）资源调度 （K8S、YARN、Mesos、Standlone）协调框架 （ZooKeeper 、Etcd、Consul）数据存储 （HBase、Cassandra、ScyllaDB 、MongoDB、Accumulo、Redis 、Ignite、Geode、CouchDB、Kudu）行列存储 （Parquet、ORC、Arrow、CarbonData、Avro）数据湖 （IceBerg、Hudi、DeltaLake）数据处理 （MaxComp【我爱线报网】ute、Hive、MapReduce、Spark、Flink、Storm、Tez、Samza、Apex、Beam、Heron）OLAP （Hologres、StarRocks、GreenPlum、Trino/Presto、Kylin、Impala、Druid、ElasticSearch、HAWQ、Lucene、Solr、 Phoenix）数据采集 （Flume、Filebeat、Logstash、Chukwa）数据交换 （Sqoop 、Kettle、DataX 、NiFi）消息系统 （Pulsar、Kafka、RocketMQ、ActiveMQ、RabbitMQ）任务调度 （Azkaban、O【我爱线报网】ozie、Airflow、Contab、DolphinScheduler）数据安全 （Ranger、Sentry、Atlas）数据血缘 （OpenLineage、Egeria、Marquez、DataHub）机器学习 （Pai、Mahout、MADlib、Spark ML、TensorFlow、Keras、MxNet）

平台建设过程中面临大数据选型（谁更快更强）、组合（谁做存储谁做计算）与组织管理等问题：比如选什么 who vs who？怎么搭配 who on who？迭代演进还是推倒重来？数据分散是集中到一个团队分析还是自治，历史原因可能多个组合共存。常见技术栈组合：

开源常见技术栈组合：

Ice【我爱线报网】berg+S3+Starrocks+FlinkHDFS+Alluxio+Spark+TrinoHDFS+Hive+GreenPlumMinio+LakeFS+Marquez+Trino

举个具体的例子，在存储和计算的组合上，根据研发的习惯可以采用Hive on Spark，也可以选择Spark on hive（依赖hive metastore），表现为上层谁作为查询语言的表达和解析优化，谁作为执行引擎或者catalog存储，根据团队的使用习惯以及历史发展甚至会有多个集群、多种版本共存，数据在平台之间通过集成或者计算框架的Source/Sink IO直接读写，中间经历各种序列化、反序列化的过程。我【我爱线报网】们所服务的某互联网搬历史就遗留统计、算法、广告三个集群，分别采用了Azkaban、Crontab、Oozie作为调度框架，多个集群数据的存储和计算之间血缘隐含复杂的依赖关系，缺少统一的产品或者方法再继续运营，客户最终选择重构并迁移到阿里大数据平台架构。

从过去大数据服务过程我们看到各行业大数据平台的现状，大体量的客户由于业务场景差异、组织变更、长期演进导致的架构不统一、数据标准不统一，多套架构共存，数据分布存在成为常态。是否有更先进的技术或者方法论提高数据分析的效率，是在当前基础上构建统一的管控平台还是推翻重建统一技术栈，也许没有一个最终的答案。在这个背景下我们继【我爱线报网】续讨论data fabric与data mesh的概念，对于业务模式简单、小体量、集中式单体数据平台能解决的场景不在讨论范围内。

Data Fabric/Data Mesh解决的问题

技术问题：大数据建设架构层出不穷，一直有“Next-Generation”的新产品与组件出现，持续建设导致技术架构多样化，数据存算分散成为常态。（比如某运营商客户同时运维N个小的业务域集群，总部和各省区域集群，数据处理ETL过程冗长，管理运维成本高）组织问题：单一数据团队架构带来的数据工程需求压力，持续积累汪洋大海一样的数据目录带来高额的分析探查成本。缺少统一的血缘和业务知识导致的数据分析运营困难。而数据价值的挖掘存【我爱线报网】在知识壁垒，数据分析需求由单一数据部门来响应成为瓶颈，沟通成本高，表面在中台内开发但依然垂直建设烟囱的局面，未来面临一次又一次的重构，

“A data fabric and a data mesh both provide an architecture to access data across multiple technologies and platforms, but a data fabric is technology-centric, while a data mesh focuses on organizational change”

简单说，二者都是为了解决跨技术栈和平台的数据【我爱线报网】接入和分析问题，让数据还保留在原来的地方，而不是集中到一个平台或者领域。Data fabric是以技术为中心，data mesh聚焦于方法论、组织协同上的变化。

概念分析

Data Fabric

概念

“Conceptually, a big data fabric is essentially a metadata-driven way of connecting a disparate collection of data tools that address key pain points in big data projects in a cohesive and self-service m【我爱线报网】anner. Specifically, data fabric solutions deliver capabilities in the areas of data access, discovery, transformation, integration, security, governance, lineage, and orchestration. ”

定位：解决分散的数据平台，从技术和产品角度打造元数据驱动的统一的Virtual Layer，屏蔽底层各种数据集成、湖、仓、MPP数据库的差异。数据的读写和计算在各种底层的Warehouse中往来，在统一的自服务平台中编排和计算。技术【我爱线报网】要素：数据集成、服务集成、统一的语义（跨引擎）、主动元数据、知识图谱（元数据图结构）、智能数据目录。主动适配各种大数据产品，避免废弃重建，增加了一个虚拟层。在虚拟层中自动进行必要的ETL、计算下推、数据目录智能推荐、数据虚拟化、联邦计算等过程，使开发人员和数据分析对于底层差异无感。不涉及组织变化：数据分析可以由维护数据平台的人来统一管理和保障也可以跨组织协同。对组织架构无干涉。

Tech stack

目前data fabric更多的是一种Architecture，并不是某一个产品，需要组合多种技术达到类似的效果，逐步统一各个技术要素，收集跨平台的元数据、数据目录并构建统一的编排和语义层，基于统一的【我爱线报网】元数据和底层所纳管的各个引擎的特点实现计算编排、下推，联动多个产品实现数据分析。目前市面上有也有类似的商业化产品，部分实现统一的catalog、storage、etl等能力，支持全域数据的即席访问和联合分析。

Data Mesh

概念

“In short, while the data fabric seeks to build a single, virtual management layer atop distributed data, the data mesh encourages distributed groups of teams to manage data as they see【我爱线报网】 fit, albeit with some common governance provisions.”

Data fabric目标是在异构分布式数据平台基础上建立单体统一的虚拟数据管理层，data mesh鼓励分布式的组织去管理自己的数据，领域内自闭环，基于data product对外提供服务。

“So instead of building a complex set of ETL pipelines to move and transform data to specialized repositories where the various communities can analyze【我爱线报网】 it, the data is retained in roughly its original form, and a series of domain-specific teams take ownership of that data as they shape the data into a product.”

可以认为Data Mesh就是数据分析领域的“微服务”，在应用开发对应微服务的ServiceMesh理念有共同点，解决单体应用开发、部署、扩容等问题，微服务也为不同的服务节点所选择的语言提供一定的灵活性，应用之间通过API来通信，实现Service Mesh服务编排需要的技术组【我爱线报网】件包括可选的Service Discovery、API Gateway、Spring Framework、Docker、SideCar等。Data Mesh也是一种分布式大数据分析方法论，避免开发复杂的ETL将数据全量同步到某个数据仓库，而是根据需求选择不同的self-serve大数据技术与其场景匹配。旨在提供更灵活的自治的数据分析能力，让数据保留原始形态，提高分析实效性需求的响应速率，在需要Cross-Domain分析的情况下将数据编排起来，最大化利用原Data Product的价值，基于联合计算联合分析，或者通过编排将数据在各个域的分析驱动起来。

分布式data mesh的四个主要特征:

面向【我爱线报网】领域的分布式数据权责划分和架构设计；数据作为产品；Data as Product；自服务的平台技术架构；跨域联合计算。

通过数据驱动、领域驱动，不同的数据分析团队聚焦在自身的Domain建设中，发布自己的数据产品，其建设过程可以选择非单一架构的数仓、MPP、数据湖或者数据库引擎，数据以服务或者表的形式对外提供。对于Cross-Domain的数据分析依然依赖联合查询计算等技术。

治理级别

当数据足够复杂，系统中有几十万张表存在的时候，理想中的中台架构会面临局限，没有人能说清楚某个表的价值和口径的准确性，为了数据的准确性不得不从基础数据以烟囱的形式重新计算的案例比比皆是，比如某客户出现过新中间层大规模重【我爱线报网】构过程，老中间层占用大量存储计算资源，但由于人员离职业务口径和文档准确性问题导致中间层已经错综复杂无法继续维护。在真实世界里，当复杂的体系到达一定规模局部会出现小世界模型，小世界通过主干进行连接，可以形象的类比Data mesh的每个Domain都是一个关联度很高的小世界模型，大部分的数据保留在自己的领域中，对于数据的理解、探查更直接。

Data mesh的概念是为了减少业务知识的壁垒，理论上生产数据业务相关的开发人员对于自己的需求和数据理解的更准确，将数据通过复杂的ETL集中到中央存储，将元数据知识传递给数据工程技术人员，等待与不那么可靠的数仓CDM数据联合进行分析和反馈，不管是从数据链路还是【我爱线报网】沟通链路都不够效率。通过data mesh将数据分析权责像微服务一样分配到不同的团队，自主分析减少业务知识传递的壁垒，同时提高技术选型的灵活度，比如一个团队用湖仓、一个用MPP，或者直接用的就是某个Data Fabric单体平台。

各个团队或者Domain不一定达到同样的Level，data mesh的领域分析级别分级如下：

Level 0: No Data AnalyticsLevel 1: Operational Database QueriesLevel 2: Analyze Own DataLevel 3: Analyze Cross-domain DataLevel 4: Publish【我爱线报网】 Data as a Product

Tech stack

底层所依赖的Self-serve Data Platform可以根据需求自由组合，也可以选择某种Data Fabric的产品，常见的自服务大数据技术栈举例：

DataWorks and MaxComputeAWS S3 and AthenaAzure Synapse Analyticsdbt and SnowflakeDatabricksMinIO and Trino and LakeFS

总结

二者的相同与不同

共同：Self-Serve Data Platform, No ETL，立足于解决数据现状分散的问题。是一种架构框架，而不是某款产品。【我爱线报网】不同：Mesh偏向方法论，分布式的敏捷数据开发，类比微服务的Service Mesh。Fabric偏向构建虚拟的单体技术架构。

Data Mesh 是微服务与单体架构的区别，从方法论层面DataMesh与数据中台的对比，治理过程是自下而上，在方法论层面与数据中台可以互补。“ top-down style of management that organizations have tried to impose on data lakes has been a failure. The data mesh tries to re-imagine that ownership structure i【我爱线报网】n a bottoms-up manner”

Data Fabric是与WareHouse、DataLake、LakeHouse等技术类似的概念，可以认为是第X代的DataPlatform，一种新的magic。Data Fabric侧重技术，通过各种组件构建统一元数据、联邦计算引擎、智能的数据编排消费探查工具实现面向业务人员的统一开发和管控平台，数据也是分散在各个存储计算引擎，从技术上也可以作为支撑Data Mesh的一种Self serve数据平台底座。两者并不冲突，体现方法论和技术的结合。

Data Mesh可以建设在Fabric单体虚拟层之上，底座在技术上解决元数据、数据目录、联邦计算、湖仓【我爱线报网】等一体化开发运营能力，上层基于方法论实现数据的服务化、跨域的编排与分析，在没有比较完美的Data Fabric数据产品之前，可以通过现有的数据平台组合实现Mesh架构落地效果，这种情况下Data Mesh也需要额外建设跨域的全链路大数据的观测、元数据采集、统一服务目录、DataProduct的消费管理能力以及跨域联合计算的技术能力，但主要的业务数据分析计算过程不需要侵入到每个Domain的数据平台之中，数据依然主要在自己的Self-Serve Data Platform计算，各领域保持自治，上层进行相对轻量级的聚合分析。

点击查看原文，获取更多福利！

https://developer.aliyu【我爱线报网】n.com/article/1160104?utm_content=g_1000368495

版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

给力项目：线报网会员可免费下载 加入会员
友情提醒： 请尽量登录购买，防止付款了不发货！
QQ交流群：226333560 站长微信：qgzmt2

温馨提示：本站提供的一切软件、教程和内容信息都来自网络收集整理，仅限用于学习和研究目的；不得将上述内容用于商业或者非法用途，否则，一切后果请用户自负，版权争议与本站无关。用户必须在下载后的24个小时之内，从您的电脑或手机中彻底删除上述内容。如果您喜欢该程序和内容，请支持正版，购买注册，得到更好的正版服务。我们非常重视版权问题，如有侵权请邮件与我们联系处理。敬请谅解！