问题与挑战
背景
大数据平台建设有其天生的复杂性，每一年都在推陈出新，从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、Eagle、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）
- 数据处理 （MaxCompute、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、Oozie、Airflow、Contab、DolphinScheduler）
- 数据安全 （Ranger、Sentry、Atlas）
- 数据血缘 （OpenLineage、Egeria、Marquez、DataHub）
- 机器学习 （Pai、Mahout、MADlib、Spark ML、TensorFlow、Keras、MxNet）
平台建设过程中面临大数据选型（谁更快更强）、组合（谁做存储谁做计算）与组织管理等问题：比如选什么 who vs who？怎么搭配 who on who？迭代演进还是推倒重来？数据分散是集中到一个团队分析还是自治，历史原因可能多个组合共存。常见技术栈组合：
开源常见技术栈组合：
- Iceberg+S3+Starrocks+Flink
- HDFS+Alluxio+Spark+Trino
- HDFS+Hive+GreenPlum
- Minio+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 manner. 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 Analytics
- Level 1: Operational Database Queries
- Level 2: Analyze Own Data
- Level 3: Analyze Cross-domain Data
- Level 4: Publish Data as a Product
Tech stack
底层所依赖的Self-serve Data Platform可以根据需求自由组合，也可以选择某种Data Fabric的产品，常见的自服务大数据技术栈举例：
- DataWorks and MaxCompute
- AWS S3 and Athena
- Azure Synapse Analytics
- dbt and Snowflake
- Databricks
- MinIO 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 in 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计算，各领域保持自治，上层进行相对轻量级的聚合分析。
什么情况应该避免用DataMesh
- 小团队，数据规模和数据域都比较少
- 高内聚的单体平台（比如SAP、DataPhin）满足需求
- 实效性要求高（网格化的数据通过CDC类实时的集成和计算也可以保证低延时）
Gartner怎么看
“Data mesh is obsolete before plateau，data fabric 还有5-10年才能成熟”
二者依赖的基础技术需要几年时间才能成熟，相比起来Data Mesh出现时间较短，业界也有出现Data Mesh碰瓷Data Fabric的说法，二者的理念不同也会造成一些冲突，我们能认为二者可以在技术和方法论层面进行互补。
技术分析
至此二者的概念已经比较明确，我们从技术上分析下实现Fabirc或者Mesh的落地还需要哪些能力。相对于架构概念和方法论，实际的支撑的数据产品和技术实现更重要，对于微服务而言，Spring、Docker容器技术已经成为Java微服务框架的事实标准，而在大数据领域完美的实现Data fabric 理论上还比较遥远。
还需要哪些轮子
Data Fabric架构旨在异构的平台之上提供相对统一的数据分析能力，要实现这个目标需要将各种大数据分析过程中的关键要素进行适配和统一，屏蔽掉底层引擎的各种细节，我们将实现统一的Virtual Layer的技术要素罗列如下：
- 统一的数据集成、服务集成
- 统一的语义表达
- 主动元数据+知识图谱（元数据图结构、血缘），基于元数据的推荐等扩展能力
- 统一数据目录、统一的Table行列存储结构、统一缓存
- 跨域联邦计算、自动计算下推。
实现以上技术要素打造统一的虚拟层，为用户提供元数据驱动的数据推荐、计算下推和分散在各个存算引擎的数据资产的管理能力，让数据分析和架构设计更灵活，把复杂留给自己，简单留给用户。本文我们选择Catalogue、Data Format、Cache、DataLineage、统一开发和语义几个方面看下当前大数据领域技术方案现状，要实现完美的“统一”还差哪些工作。
Catalogue
在大数据产品中，数据目录的组织通常分为三成，这里用比较通用的Catalog-Database-Table进行展示，类比到MaxCompute（Project-Schema-Table)，不同计算引擎内部的定义不一样，比如Hive 没有Catalog这一层，只有Database(Schema)-Table两级，实现统一的Catalogue，需要有一个标准层将个性化数据目录的结构进行转换，转换成某个标准化的统一的Catalogue Virtual Layer，通常三层数据目录架构的实现包括以下细节：
通常每个引擎内部都有自己的Catalog实现比如Spark有自己的SparkCatalog，StarRocks有自己的StarRocksCatalog，支撑其计算引擎的逻辑计划、物理计划生成和优化，其数据结构的细节会有差异。通常包括以下配置:
- Impl：具体Catalog的实现类，影响URL和IO的配置
- Url: Catalog的存储地址，可以是S3、HDFS，根据Impl的定义有差异
- IO: Catalog具体的IO读写实现，比如S3的Catalog存储既可以选择用Hadoop-S3去读写，也可以直接使用S3FileIO Client读写，或者通过Restful API
- Warehouse：实际数据的存储地址，可以是HDFS、S3或其他分布式存储
如果要实现跨引擎的Catalog通用，比如让Spark识别Hive MetaStore里边的元数据，需要在Spark的运行时加载HiveCatalog的实现远程读写HMS并转换成Spark内部的计算引擎可以使用的元数据，我们以目前比较流行的Data Lake举例，Iceberg对各个引擎的适配比较好，统一Table Schema与Catalog的读写屏蔽一些引擎的差异，下图展示我们常见的一些数仓、数据湖产品元数据目录的实现，简单示意Iceberg是怎么实现的。。
Iceberg已经实现了多种Catalog存储的兼容，支持多种计算引擎使用Iceberg的Catalog来建立External Table，这个过程需要定制化将Iceberg的Catalog转换成其引擎内部支持的Catalog的具体Implement，也就是上图所依赖的iceberg-spark-runtime-3.3_2.12:1.1.0.jar，后边的一串数字3.3_2.12:1.1.0 表示适配基于Scala 2.12编译的Spark 3.3版本，冒号后边的1.1.0代表IceBerg的版本，不同版本的计算引擎、湖之间的适配不夸张的说是个笛卡尔积的过程，每发行一个新的runtime要适配各种引擎的各种版本，不小心用错了3.2版本的Spark的runtime jar，有可能在3.3集群上就会出各种Class Not Found的错误。
@Override
public Database getDB(String dbName) throws InterruptedException, TException {
org.apache.hadoop.hive.metastore.api.Database db = clients.run(client -> client.getDatabase(dbName));
if (db == null || db.getName() == null) {
throw new TException("Hive db " + dbName + " doesn't exist");
}
return convertToSRDatabase(dbName);
}
以IcebergHiveCatalog里边的一个方法举例来说要想实现StarRocks与IceBerg的联通，依赖个性化的适配逻辑导致适配本身是个点对点的过程。StarRocks目前支持HiveMetaStore以及Custom MetaData。IcebergHiveCatalog支持StartRocks读取HMS里边的Database&Table信息并转换为StartRocks Catalog的过程，以getDB为例，hms client读取db信息并convertToSRDatabase，适配的这个Class需要耦合源端、目标端的Catalog的转换逻辑，根据具体Catalog的存储的IO的读写过程，相当于一个三方的枢纽，而每种引擎的集成都类似，需要定制化一个IcebergXxxxCatalog，包括Flink、Spark、Hive等等引擎，涉及到Catalog的转换与其物理存储的读写，在大量的适配过程中元数据、存储、计算形成了一种错综复杂的网络，且当某个引擎增加了新的特性适配层没有跟上也会影响整体大数据架构的升级，统一和效率之间就存在了矛盾。
Iceberg以及各个引擎的合作已经实现了非常多的引擎和Catalog存储之间点对点的适配，也是在其自身价值得到证实的情况下持续迭代、开源社区推广运营的结果。要实现Data Fabric需要独立实现一个更上层的统一的Catalogue层，兼容IceBerg、Hudi、DeltaLake等不同的数据湖格式，仅仅是Catalog的适配就需要很大的工作量，且很有可能更新跟不上各个引擎或者存储百花齐放的演进速度。
实现统一的Virtual Layer，本质上是执行效率、学习成本和通用性的冲突和平衡。如何找到一个演进的动态平衡点，而目前可行的存算都是点对点集成方式，统一集成对于虚拟层来说成本高，新Feature兼容压力大，需要找到一个演进的平衡点。
Data Format
除Catalog外，Data Fabric实现所需要的每个技术要素都需要类似的架构出现，以下例子从简，从图中所展示的连接关系可以发现类似的规律，比如Apache Arrow作为一种Columnar memory format 支持不同的引擎比如spark、impala里边的dataframe计算抽象，提高计算效率，优化数据在不同的计算引擎中抽象和转换的计算效率，统一数据格式，优化切换引擎中间结果落盘过程中序列化和反序列化的处理效率。
构建Data Fabric的数据平台同样需要有一种数据格式抽象解决存算分离架构下数据的存储格式问题，当底层引擎有Parquet、CarbonData等不同的文件格式，上层构建的联合计算引擎需要能够兼容不同的文件格式，Data Format这一层的抽象必不可少，在跨引擎的计算过程中减少不必要的序列化。
Data Lineage | Data Discovery
数据血缘是大数据分析的必备组件，大多数的计算引擎都有其内部的元数据和DAG管理能力，当数据链路存在跨引擎或者平台的依赖，需要将上下游的血缘聚合到统一的血缘中心，形成完整的数据链路全景，提高问题溯源分析和影响分析。有些大数据组件的的元数据和血缘集成在自身Catalog能力，有些大数据产品只支持基础的数据目录和Table Schema，还有一些支持到Table Lineage&Column Lineage。构建跨平台的数据血缘我们需要有一个第三方的组件建立血缘标准，支持将数据的血缘从其自身的元数据存储、任务提交和运行的过程汇总，转换成通用的血缘Model，并将跨平台的血缘信息整合为血缘全景，支持跨引擎的代码提示或者计算优化。
数据血缘目前有非常多的第三方组件，在构建大数据平台过程中选择较多，也会造成点对点集成的情况，我们可以选择其一作为统一的后端，依赖各种采集、解析和标准化技术将分散在引擎和元数据中的任务、表和字段之间的关系固化到统一的后端服务，我们以Open Lineage和DataHub为例，OpenLineage通过Wrapper、Proxy或者javaagent将运行时提交任务过程的事件信息采集到统一的血缘中心，实现表、任务之间的血缘存储和展示，目前已经开始支持Column LIneage。
元数据信息的收集和血缘的分析通常有这几种方式：
- Cli Wrapper：对于Python开发的客户端，代码可以重新封装，替换原默认的命令行脚本，在提交过程解析任务执行的代码，分析血缘并转发给后端
- java agent：适用于Java开发的submit job 过程，侵入Jvm加载字节码的过程，分析代码中的血缘并转发给LIneage Backend远程地址；
- event listener：对于支持Extra Listener扩展的计算框架，提供定制化的Listener配置，运行时过程中手机元数据信息转发给后端
第三代的元数据中心DataHub支持流式的元数据日志协议，类似于CDC的MCP（Metadata Change Proposal）协议，通过source插件ingest并extract到内部的元数据存储，根据元数据来源的特点也可以支持column-lineage以及自定义的元数据分析能力，比如基于databrick的unity catalog从元数据中获取血缘，对于不支持血缘的比如hive就只能查询到table、column的schema信息以及数据统计信息。类似于open lineage作为一个后端去存储各种元数据，DataHub兼容的源端种类更多，2022年8月份的新Feature开始支持Column LIneage，支持pull-based/push-bashed元数据集成方式，做为大数据平台之外的第三方元数据中心，通过实时的流式的元数据变更以及元数据联邦查询能力，订阅源端元数据的变更事件提高元数据的实效性，保障实时可用，下游应用也可以订阅DataHub元数据的变更来进行比如查询优化、链路监测的能力。
统一的开发IDE与语义
以DBT为例，上文提到过Data Mesh可以通过dbt+snowflake的形式构建，dbt作为统一的开发管理层，实现类似软件开发过程中的software enginerring、package management、macros、hooks 以及通过incremental materialization实现的 DAG level optimization能力。目标是提高代码模块的复用性，通过select语义以及ref 引用构建module的定义和关联关系，compile生成目标warehouse sql提交给引擎运行，但dbt开发moddular data model使用的SQL并不是一种统一的表达形式，而是所选择的warehouse自身的dialect，数据的处理不会离开sql运行的存算引擎。
dbt sn't actually Magic. your data is not processed outside of your warehouse.
dbt实现了snowflake、redshift、bigquery等平台的adapter，作用于macros和compile的过程，数据的计算完全在底层引擎内执行，dbt控制代码的复用、执行过程。而支持联合计算的比如trino或者StarRocks提供了统一的SQL支持跨多种数据源和计算引擎的查询，但Trino实现的是各种数据源的connector，数据会离开原来的位置在上层引擎进行，二者有很大的区别。
还有Semantics、Orchestration、Active MetaData、FederatedCompute等等
通过上文的catalog、format、lineage、sql的表达几种技术要素方案的讨论，可以看到这些图长得都差不多，中间有一层抽象成统一的XX，实现Fabric的架构前提要把所有的点对点的集成都屏蔽掉，可以依赖以上的一些产品进行组合、扩展集成，拼装成一层虚拟的Virtual Layer。而目前各种适配和统一还只存在于技术要素局部，宏观上大数据产品的异构还是常态，为了追求计算效率计算引擎通常与存储会避免通过中间层的额外做一层转换。更可行的是在某个引擎作为基准来扩展支持更广泛的数据源、数据格式和元数据，屏蔽底层其他种类的WareHouse或者数据湖的差异，现在比较流行的湖仓一体概念，可以看做是轻量化的Fabric实现，实现Catalog层面的统一，比如MaxCompute可以直接通过DLF或者对Hive MS的适配实现对外部数据湖、数仓的联合计算。
Data Fabric目标是打造一个完整的虚拟层，创造一种新的魔法，基于同一的各种抽象开展数据工程，但这些统一的适配工作需要大量的工作，目前还没有统一的语义的抽象能够兼容所有的引擎，一些比较个性化的优化器、hint、存储格式和压缩算法、物化与虚拟化的技术都会导致通用表达无法下推到底层的引擎，专业性与通用性一定是冲突的，需要进行两层抽象，过度抽象可能会导致轮子以低功率运行，无法发挥底层引擎的优势。
从可行性角度，Fabric可以在有限的存、算、调度组件上可行，联合Data Mesh实现最终的架构效果，Trino 2022 Summit也提到“Elevating Data Fabric to Data Mesh: solving data needs in hybrid data lakes”，通过trino跨引擎、跨实例组合出Fabric的架构特点，并向Data Mesh的演进，未来支撑Fabric的组件也会持续出现。当前阶段各数据平台更多聚焦打造自己的核心能力，并兼顾对于外部优秀的元数据、调度、存储等系统的适配，体现存算分离的基础上让自己的生存空间更大，同时标准化自己的扩展能力，开放Adapter的逻辑给社区，持续丰富其对外的各种适配。
实现Data Mesh相对来说要更灵活一些，不强求在统一的技术栈进行数据工程开发，数据在原地的同时，技术栈以及开发的习惯可以保持自治，二者组合在跨数据湖的集群实例上增加新的相对独立的统一元数据中心和联邦计算能力，让DataProduct之间以类似微服务的API的形式流转起来，支撑跨域的数据应用。
与大数据技术服务的关系
最后简单说下这两个概念对我们大数据技术服务的影响，回顾以上的概念和技术分析，Data Fabric和Data Mesh从框架理念上解决数据和组件分散的问题，在企业信息化转型中我们通常会遇到一些并非是从零开始构建大数据平台的客户，希望能够上到公共云或者混合云阿里侧的大数据产品，构建一套新的大数据平台的同时要考虑现有的数据和任务如何平滑快速的迁移，在进行扩容和升级的时候，如何规划架构的设计实现平滑的演进，多种架构如何共存，以及客户已有的数据如何快速敏捷的支撑上层的应用建设，将数据汇聚到单体中台还是灵活的Data Mesh结构。核心就是解决大数据平台从A到B、AB共存以及长期的数据生产运营问题。
为了支持异构大数据组件之间的转换和架构演进设计，我们在服务的过程中会参考DataFabric的技术思想沉淀技术组件和各种adapter，弥补平台与平台、平台与用户之间的GAP，持续打造标准的元数据、调度、集成抽象以及全链路的大数据可观测的标准抽象，在此基础上进行架构演进和数据生产运营，在Data Fabric的一些技术要素点上进行增强，也结合data mesh的方法论结合业务场景做一些架构设计：
- 大数据异构平台的迁移（解决从A到B的问题）：帮助客户实现快速低成本数据、任务和调度统一迁移到云上阿里云大数据产品。搬站服务和工具的一些设计与轻量级的Data fabric关联较大，比如数据迁移依赖MaxCompute的湖仓一体（Inside Hadoop方案）加速客户的数据迁移过程。内部抽象统一的血缘分析和调度的标准化转换屏蔽了客户各种Script、调度DAG的差异。
- 湖仓、流批架构规划服务（解决A与B共存演进问题）：部分客户提到希望可以提供持续演进的规划，中间态多产品共存，比如通过扩展MaxCompute的标准插件实现与开源大数据引擎的联合分析，或者基于HDFS联邦新老集群共存，在在某些架构咨询项目，设计统一的数据湖元数据中心组件实现存储计算结构平滑扩容。
- 数据生产运营优化（数据价值与生产平衡问题）：结合data fabric架构思想设计统一的全链路的数据血缘帮助客户做全面的存储、槽位、Quota等资源分析和优化。对于客户当前已经有多平台共存、云边端协同等场景的大数据架构设计场景，基于data mesh的理论框架，实现数据敏捷分析、快速体现数据业务化价值。
搬站工作台
大数据生产运营优化
大数据平台运营过程中客户的存储和计算水位长期处于高位，数据集成等任务出现堆积，通过对大数据平台的元数据、数据血缘、存储的分布进行综合分析，实现全链路的生产经营优化。结合Data Fabric架构设计伴生大数据平台的独立的第三方运营工具，抽象统一的元数据采集、图谱关系构建，上下游影响分析，为运营优化技术服务提供数据与决策支撑。
从业务场景我们在能源与制造一些领域探索Data Mesh的方法论，生产数据的过程中通常在多个业务域都有自己的采集、处理和分析的需求，内部通常也有小规模的开源或者自建的大数据产品，同时各领域的数据需要协同计算，算法团队依赖工控的数据进行模型训练，预测的结果以服务的形式对管控提供服务，结合Data Mesh的架构设计，将不同领域数据的生产过程的输入输出联动起来，合理设计生产数据和分析数据的处理链路的边界，数据的生产、基础的计算分析和服务化保留在多个Domain中，通过MaxCompute与OSS外表结合简化各个业务输出数据之间的联合分析，通过数据湖共享各个分析系统的数据产品，中间层设计相对简化，减少由于链路长带来的数据一致性和数据权责问题。
参考资料
https://www.datamesh-architecture.com/
https://www.datanami.com/2021/10/25/data-mesh-vs-data-fabric-understanding-the-differences/
https://www.gartner.com/doc/reprints?id=1-2B6AXOGW&ct=220920&st=sb
