10分鐘搞懂 Data Fabric 和 Data Mesh 的區(qū)別！
問題與挑戰(zhàn)
背景
大數(shù)據(jù)平臺(tái)建設(shè)有其天生的復(fù)雜性，每一年都在推陳出新，從WareHouse、DataLake到LakeHouse，各種各樣的Batch、Stream、MPP、Machine Learning、Neural Network計(jì)算引擎，對應(yīng)解決的場景和組合的方式非常個(gè)性化，建設(shè)過程會(huì)遇到包括技術(shù)層面、組織層面、方法論層面種種問題，包括存儲(chǔ)計(jì)算組件選型、離線實(shí)時(shí)湖倉架構(gòu)方案設(shè)計(jì)以及場景化的性能分析，隨著時(shí)間推進(jìn)也會(huì)出現(xiàn)持續(xù)的組織管理、數(shù)據(jù)和平臺(tái)運(yùn)營、擴(kuò)容、穩(wěn)定性優(yōu)化等問題，出現(xiàn)多個(gè)平臺(tái)共存，存儲(chǔ)和計(jì)算集群技術(shù)棧多樣化以及數(shù)據(jù)分散等常態(tài)化問題，面臨保留原架構(gòu)還是推倒重來遷移到新的平臺(tái)的困擾，有沒有一套Architecture FrameWork能夠屏蔽底層技術(shù)和開發(fā)細(xì)節(jié)，Data Fabric、Data Mesh似乎是為了解決這個(gè)問題而生，從技術(shù)和方法論的角度探討如何影響大數(shù)據(jù)平臺(tái)的建設(shè)、數(shù)據(jù)工程和架構(gòu)持續(xù)演進(jìn)。本文重點(diǎn)聚焦在相對比較容易混淆的Data Fabric和Data Mesh這兩個(gè)概念，嘗試說明這兩個(gè)概念要解決的問題、架構(gòu)特征以及可行的技術(shù)棧，距離成熟還有哪些不足，以及圍繞兩個(gè)技術(shù)領(lǐng)域跟我們做的大數(shù)據(jù)服務(wù)之間的關(guān)系。
大數(shù)據(jù)技術(shù)棧
大數(shù)據(jù)組件多樣化，底層存儲(chǔ)、數(shù)據(jù)格式、計(jì)算表達(dá)解析、計(jì)算引擎（MR、DAG、MPP等不同的邏輯計(jì)劃&物理計(jì)劃生成和優(yōu)化器）、調(diào)度、緩存、血緣、數(shù)據(jù)集成在對應(yīng)組件集合中可以看到很多選擇。大數(shù)據(jù)產(chǎn)品不存在銀彈，在滿足不同的場景通常需要將大數(shù)據(jù)的架構(gòu)像積木一樣靈活的組合。常見的技術(shù)組件如下：
系統(tǒng)平臺(tái) （Hadoop、CDH、HDP）
云平臺(tái) ? ?（AWS、GCP、Microsoft Azure）
監(jiān)控管理 （CM、Hue、Ambari、Dr.Elephant、Ganglia、Zabbix、Eagle、Prometheus）
文件系統(tǒng) （HDFS、GPFS、Ceph、GlusterFS、Swift 、BeeGFS、Alluxio、JindoFS）
資源調(diào)度 （K8S、YARN、Mesos、Standlone）
協(xié)調(diào)框架 （ZooKeeper 、Etcd、Consul）
數(shù)據(jù)存儲(chǔ) （HBase、Cassandra、ScyllaDB 、MongoDB、Accumulo、Redis 、Ignite、Geode、CouchDB、Kudu）
行列存儲(chǔ) （Parquet、ORC、Arrow、CarbonData、Avro）
數(shù)據(jù)湖 ? ?（IceBerg、Hudi、DeltaLake）
數(shù)據(jù)處理 （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）
數(shù)據(jù)采集 （Flume、Filebeat、Logstash、Chukwa）
數(shù)據(jù)交換 （Sqoop 、Kettle、DataX 、NiFi）
消息系統(tǒng) （Pulsar、Kafka、RocketMQ、ActiveMQ、RabbitMQ）
任務(wù)調(diào)度 （Azkaban、Oozie、Airflow、Contab、DolphinScheduler）
數(shù)據(jù)安全 （Ranger、Sentry、Atlas）
數(shù)據(jù)血緣 （OpenLineage、Egeria、Marquez、DataHub）
機(jī)器學(xué)習(xí) （Pai、Mahout、MADlib、Spark ML、TensorFlow、Keras、MxNet）
平臺(tái)建設(shè)過程中面臨大數(shù)據(jù)選型（誰更快更強(qiáng)）、組合（誰做存儲(chǔ)誰做計(jì)算）與組織管理等問題：比如選什么 who vs who？怎么搭配 who on who？迭代演進(jìn)還是推倒重來？數(shù)據(jù)分散是集中到一個(gè)團(tuán)隊(duì)分析還是自治，歷史原因可能多個(gè)組合共存。常見技術(shù)棧組合：開源常見技術(shù)棧組合：
Iceberg+S3+Starrocks+Flink
HDFS+Alluxio+Spark+Trino
HDFS+Hive+GreenPlum
Minio+LakeFS+Marquez+Trino
舉個(gè)具體的例子，在存儲(chǔ)和計(jì)算的組合上，根據(jù)研發(fā)的習(xí)慣可以采用Hive on Spark，也可以選擇Spark on hive（依賴hive metastore），表現(xiàn)為上層誰作為查詢語言的表達(dá)和解析優(yōu)化，誰作為執(zhí)行引擎或者catalog存儲(chǔ)，根據(jù)團(tuán)隊(duì)的使用習(xí)慣以及歷史發(fā)展甚至?xí)卸鄠€(gè)集群、多種版本共存，數(shù)據(jù)在平臺(tái)之間通過集成或者計(jì)算框架的Source/Sink IO直接讀寫，中間經(jīng)歷各種序列化、反序列化的過程。我們所服務(wù)的某互聯(lián)網(wǎng)搬歷史就遺留統(tǒng)計(jì)、算法、廣告三個(gè)集群，分別采用了Azkaban、Crontab、Oozie作為調(diào)度框架，多個(gè)集群數(shù)據(jù)的存儲(chǔ)和計(jì)算之間血緣隱含復(fù)雜的依賴關(guān)系，缺少統(tǒng)一的產(chǎn)品或者方法再繼續(xù)運(yùn)營，客戶最終選擇重構(gòu)并遷移到阿里大數(shù)據(jù)平臺(tái)架構(gòu)。
開源大數(shù)據(jù)架構(gòu)示例
阿里大數(shù)據(jù)架構(gòu)
從過去大數(shù)據(jù)服務(wù)過程我們看到各行業(yè)大數(shù)據(jù)平臺(tái)的現(xiàn)狀，大體量的客戶由于業(yè)務(wù)場景差異、組織變更、長期演進(jìn)導(dǎo)致的架構(gòu)不統(tǒng)一、數(shù)據(jù)標(biāo)準(zhǔn)不統(tǒng)一，多套架構(gòu)共存，數(shù)據(jù)分布存在成為常態(tài)。是否有更先進(jìn)的技術(shù)或者方法論提高數(shù)據(jù)分析的效率，是在當(dāng)前基礎(chǔ)上構(gòu)建統(tǒng)一的管控平臺(tái)還是推翻重建統(tǒng)一技術(shù)棧，也許沒有一個(gè)最終的答案。在這個(gè)背景下我們繼續(xù)討論data fabric與data mesh的概念，對于業(yè)務(wù)模式簡單、小體量、集中式單體數(shù)據(jù)平臺(tái)能解決的場景不在討論范圍內(nèi)。
Data Fabric/Data Mesh解決的問題
技術(shù)問題：大數(shù)據(jù)建設(shè)架構(gòu)層出不窮，一直有“Next-Generation”的新產(chǎn)品與組件出現(xiàn)，持續(xù)建設(shè)導(dǎo)致技術(shù)架構(gòu)多樣化，數(shù)據(jù)存算分散成為常態(tài)。（比如某運(yùn)營商客戶同時(shí)運(yùn)維N個(gè)小的業(yè)務(wù)域集群，總部和各省區(qū)域集群，數(shù)據(jù)處理ETL過程冗長，管理運(yùn)維成本高）
組織問題：單一數(shù)據(jù)團(tuán)隊(duì)架構(gòu)帶來的數(shù)據(jù)工程需求壓力，持續(xù)積累汪洋大海一樣的數(shù)據(jù)目錄帶來高額的分析探查成本。缺少統(tǒng)一的血緣和業(yè)務(wù)知識(shí)導(dǎo)致的數(shù)據(jù)分析運(yùn)營困難。而數(shù)據(jù)價(jià)值的挖掘存在知識(shí)壁壘，數(shù)據(jù)分析需求由單一數(shù)據(jù)部門來響應(yīng)成為瓶頸，溝通成本高，表面在中臺(tái)內(nèi)開發(fā)但依然垂直建設(shè)煙囪的局面，未來面臨一次又一次的重構(gòu)。
“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”簡單說，二者都是為了解決跨技術(shù)棧和平臺(tái)的數(shù)據(jù)接入和分析問題，讓數(shù)據(jù)還保留在原來的地方，而不是集中到一個(gè)平臺(tái)或者領(lǐng)域。Data fabric是以技術(shù)為中心，data mesh聚焦于方法論、組織協(xié)同上的變化。
概念分析
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. ”
定位：解決分散的數(shù)據(jù)平臺(tái)，從技術(shù)和產(chǎn)品角度打造元數(shù)據(jù)驅(qū)動(dòng)的統(tǒng)一的Virtual Layer，屏蔽底層各種數(shù)據(jù)集成、湖、倉、MPP數(shù)據(jù)庫的差異。數(shù)據(jù)的讀寫和計(jì)算在各種底層的Warehouse中往來，在統(tǒng)一的自服務(wù)平臺(tái)中編排和計(jì)算。
技術(shù)要素：數(shù)據(jù)集成、服務(wù)集成、統(tǒng)一的語義（跨引擎）、主動(dòng)元數(shù)據(jù)、知識(shí)圖譜（元數(shù)據(jù)圖結(jié)構(gòu)）、智能數(shù)據(jù)目錄。主動(dòng)適配各種大數(shù)據(jù)產(chǎn)品，避免廢棄重建，增加了一個(gè)虛擬層。在虛擬層中自動(dòng)進(jìn)行必要的ETL、計(jì)算下推、數(shù)據(jù)目錄智能推薦、數(shù)據(jù)虛擬化、聯(lián)邦計(jì)算等過程，使開發(fā)人員和數(shù)據(jù)分析對于底層差異無感。
不涉及組織變化：數(shù)據(jù)分析可以由維護(hù)數(shù)據(jù)平臺(tái)的人來統(tǒng)一管理和保障也可以跨組織協(xié)同。對組織架構(gòu)無干涉。
Tech stack
Data Fabric Architecture
目前data fabric更多的是一種Architecture，并不是某一個(gè)產(chǎn)品，需要組合多種技術(shù)達(dá)到類似的效果，逐步統(tǒng)一各個(gè)技術(shù)要素，收集跨平臺(tái)的元數(shù)據(jù)、數(shù)據(jù)目錄并構(gòu)建統(tǒng)一的編排和語義層，基于統(tǒng)一的元數(shù)據(jù)和底層所納管的各個(gè)引擎的特點(diǎn)實(shí)現(xiàn)計(jì)算編排、下推，聯(lián)動(dòng)多個(gè)產(chǎn)品實(shí)現(xiàn)數(shù)據(jù)分析。目前市面上有也有類似的商業(yè)化產(chǎn)品，部分實(shí)現(xiàn)統(tǒng)一的catalog、storage、etl等能力，支持全域數(shù)據(jù)的即席訪問和聯(lián)合分析。
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目標(biāo)是在異構(gòu)分布式數(shù)據(jù)平臺(tái)基礎(chǔ)上建立單體統(tǒng)一的虛擬數(shù)據(jù)管理層，data mesh鼓勵(lì)分布式的組織去管理自己的數(shù)據(jù)，領(lǐng)域內(nèi)自閉環(huán)，基于data product對外提供服務(wù)。“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.”可以認(rèn)為Data Mesh就是數(shù)據(jù)分析領(lǐng)域的“微服務(wù)”，在應(yīng)用開發(fā)對應(yīng)微服務(wù)的ServiceMesh理念有共同點(diǎn)，解決單體應(yīng)用開發(fā)、部署、擴(kuò)容等問題，微服務(wù)也為不同的服務(wù)節(jié)點(diǎn)所選擇的語言提供一定的靈活性，應(yīng)用之間通過API來通信，實(shí)現(xiàn)Service Mesh服務(wù)編排需要的技術(shù)組件包括可選的Service Discovery、API Gateway、Spring Framework、Docker、SideCar等。Data Mesh也是一種分布式大數(shù)據(jù)分析方法論，避免開發(fā)復(fù)雜的ETL將數(shù)據(jù)全量同步到某個(gè)數(shù)據(jù)倉庫，而是根據(jù)需求選擇不同的self-serve大數(shù)據(jù)技術(shù)與其場景匹配。旨在提供更靈活的自治的數(shù)據(jù)分析能力，讓數(shù)據(jù)保留原始形態(tài)，提高分析實(shí)效性需求的響應(yīng)速率，在需要Cross-Domain分析的情況下將數(shù)據(jù)編排起來，最大化利用原Data Product的價(jià)值，基于聯(lián)合計(jì)算聯(lián)合分析，或者通過編排將數(shù)據(jù)在各個(gè)域的分析驅(qū)動(dòng)起來。分布式data mesh的四個(gè)主要特征:
面向領(lǐng)域的分布式數(shù)據(jù)權(quán)責(zé)劃分和架構(gòu)設(shè)計(jì)；
數(shù)據(jù)作為產(chǎn)品；Data as Product；
自服務(wù)的平臺(tái)技術(shù)架構(gòu)；
跨域聯(lián)合計(jì)算。
通過數(shù)據(jù)驅(qū)動(dòng)、領(lǐng)域驅(qū)動(dòng)，不同的數(shù)據(jù)分析團(tuán)隊(duì)聚焦在自身的Domain建設(shè)中，發(fā)布自己的數(shù)據(jù)產(chǎn)品，其建設(shè)過程可以選擇非單一架構(gòu)的數(shù)倉、MPP、數(shù)據(jù)湖或者數(shù)據(jù)庫引擎，數(shù)據(jù)以服務(wù)或者表的形式對外提供。對于Cross-Domain的數(shù)據(jù)分析依然依賴聯(lián)合查詢計(jì)算等技術(shù)。
治理級(jí)別
當(dāng)數(shù)據(jù)足夠復(fù)雜，系統(tǒng)中有幾十萬張表存在的時(shí)候，理想中的中臺(tái)架構(gòu)會(huì)面臨局限，沒有人能說清楚某個(gè)表的價(jià)值和口徑的準(zhǔn)確性，為了數(shù)據(jù)的準(zhǔn)確性不得不從基礎(chǔ)數(shù)據(jù)以煙囪的形式重新計(jì)算的案例比比皆是，比如某客戶出現(xiàn)過新中間層大規(guī)模重構(gòu)過程，老中間層占用大量存儲(chǔ)計(jì)算資源，但由于人員離職業(yè)務(wù)口徑和文檔準(zhǔn)確性問題導(dǎo)致中間層已經(jīng)錯(cuò)綜復(fù)雜無法繼續(xù)維護(hù)。在真實(shí)世界里，當(dāng)復(fù)雜的體系到達(dá)一定規(guī)模局部會(huì)出現(xiàn)小世界模型，小世界通過主干進(jìn)行連接，可以形象的類比Data mesh的每個(gè)Domain都是一個(gè)關(guān)聯(lián)度很高的小世界模型，大部分的數(shù)據(jù)保留在自己的領(lǐng)域中，對于數(shù)據(jù)的理解、探查更直接。Data mesh的概念是為了減少業(yè)務(wù)知識(shí)的壁壘，理論上生產(chǎn)數(shù)據(jù)業(yè)務(wù)相關(guān)的開發(fā)人員對于自己的需求和數(shù)據(jù)理解的更準(zhǔn)確，將數(shù)據(jù)通過復(fù)雜的ETL集中到中央存儲(chǔ)，將元數(shù)據(jù)知識(shí)傳遞給數(shù)據(jù)工程技術(shù)人員，等待與不那么可靠的數(shù)倉CDM數(shù)據(jù)聯(lián)合進(jìn)行分析和反饋，不管是從數(shù)據(jù)鏈路還是溝通鏈路都不夠效率。通過data mesh將數(shù)據(jù)分析權(quán)責(zé)像微服務(wù)一樣分配到不同的團(tuán)隊(duì)，自主分析減少業(yè)務(wù)知識(shí)傳遞的壁壘，同時(shí)提高技術(shù)選型的靈活度，比如一個(gè)團(tuán)隊(duì)用湖倉、一個(gè)用MPP，或者直接用的就是某個(gè)Data Fabric單體平臺(tái)。各個(gè)團(tuán)隊(duì)或者Domain不一定達(dá)到同樣的Level，data mesh的領(lǐng)域分析級(jí)別分級(jí)如下：
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可以根據(jù)需求自由組合，也可以選擇某種Data Fabric的產(chǎn)品，常見的自服務(wù)大數(shù)據(jù)技術(shù)棧舉例：
DataWorks and MaxCompute
AWS S3 and Athena
Azure Synapse Analytics
dbt and Snowflake
Databricks
MinIO and Trino and LakeFS
總結(jié)
二者的相同與不同
共同：Self-Serve Data Platform, No ETL，立足于解決數(shù)據(jù)現(xiàn)狀分散的問題。是一種架構(gòu)框架，而不是某款產(chǎn)品。
不同：Mesh偏向方法論，分布式的敏捷數(shù)據(jù)開發(fā)，類比微服務(wù)的Service Mesh。Fabric偏向構(gòu)建虛擬的單體技術(shù)架構(gòu)。
Data Mesh 是微服務(wù)與單體架構(gòu)的區(qū)別，從方法論層面DataMesh與數(shù)據(jù)中臺(tái)的對比，治理過程是自下而上，在方法論層面與數(shù)據(jù)中臺(tái)可以互補(bǔ)?！?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等技術(shù)類似的概念，可以認(rèn)為是第X代的DataPlatform，一種新的magic。Data Fabric側(cè)重技術(shù)，通過各種組件構(gòu)建統(tǒng)一元數(shù)據(jù)、聯(lián)邦計(jì)算引擎、智能的數(shù)據(jù)編排消費(fèi)探查工具實(shí)現(xiàn)面向業(yè)務(wù)人員的統(tǒng)一開發(fā)和管控平臺(tái)，數(shù)據(jù)也是分散在各個(gè)存儲(chǔ)計(jì)算引擎，從技術(shù)上也可以作為支撐Data Mesh的一種Self serve數(shù)據(jù)平臺(tái)底座。兩者并不沖突，體現(xiàn)方法論和技術(shù)的結(jié)合。
Data Fabric&Mesh 組合Data Mesh可以建設(shè)在Fabric單體虛擬層之上，底座在技術(shù)上解決元數(shù)據(jù)、數(shù)據(jù)目錄、聯(lián)邦計(jì)算、湖倉等一體化開發(fā)運(yùn)營能力，上層基于方法論實(shí)現(xiàn)數(shù)據(jù)的服務(wù)化、跨域的編排與分析，在沒有比較完美的Data Fabric數(shù)據(jù)產(chǎn)品之前，可以通過現(xiàn)有的數(shù)據(jù)平臺(tái)組合實(shí)現(xiàn)Mesh架構(gòu)落地效果，這種情況下Data Mesh也需要額外建設(shè)跨域的全鏈路大數(shù)據(jù)的觀測、元數(shù)據(jù)采集、統(tǒng)一服務(wù)目錄、DataProduct的消費(fèi)管理能力以及跨域聯(lián)合計(jì)算的技術(shù)能力，但主要的業(yè)務(wù)數(shù)據(jù)分析計(jì)算過程不需要侵入到每個(gè)Domain的數(shù)據(jù)平臺(tái)之中，數(shù)據(jù)依然主要在自己的Self-Serve Data Platform計(jì)算，各領(lǐng)域保持自治，上層進(jìn)行相對輕量級(jí)的聚合分析。
什么情況應(yīng)該避免用DataMesh
小團(tuán)隊(duì)，數(shù)據(jù)規(guī)模和數(shù)據(jù)域都比較少
高內(nèi)聚的單體平臺(tái)（比如SAP、DataPhin）滿足需求
實(shí)效性要求高（網(wǎng)格化的數(shù)據(jù)通過CDC類實(shí)時(shí)的集成和計(jì)算也可以保證低延時(shí)）
Gartner怎么看
“Data mesh is obsolete before plateau，data fabric 還有5-10年才能成熟”二者依賴的基礎(chǔ)技術(shù)需要幾年時(shí)間才能成熟，相比起來Data Mesh出現(xiàn)時(shí)間較短，業(yè)界也有出現(xiàn)Data Mesh碰瓷Data Fabric的說法，二者的理念不同也會(huì)造成一些沖突，我們能認(rèn)為二者可以在技術(shù)和方法論層面進(jìn)行互補(bǔ)。
技術(shù)分析
至此二者的概念已經(jīng)比較明確，我們從技術(shù)上分析下實(shí)現(xiàn)Fabirc或者M(jìn)esh的落地還需要哪些能力。相對于架構(gòu)概念和方法論，實(shí)際的支撐的數(shù)據(jù)產(chǎn)品和技術(shù)實(shí)現(xiàn)更重要，對于微服務(wù)而言，Spring、Docker容器技術(shù)已經(jīng)成為Java微服務(wù)框架的事實(shí)標(biāo)準(zhǔn)，而在大數(shù)據(jù)領(lǐng)域完美的實(shí)現(xiàn)Data fabric 理論上還比較遙遠(yuǎn)。
還需要哪些輪子
Data Fabric架構(gòu)旨在異構(gòu)的平臺(tái)之上提供相對統(tǒng)一的數(shù)據(jù)分析能力，要實(shí)現(xiàn)這個(gè)目標(biāo)需要將各種大數(shù)據(jù)分析過程中的關(guān)鍵要素進(jìn)行適配和統(tǒng)一，屏蔽掉底層引擎的各種細(xì)節(jié)，我們將實(shí)現(xiàn)統(tǒng)一的Virtual Layer的技術(shù)要素羅列如下：
統(tǒng)一的數(shù)據(jù)集成、服務(wù)集成
統(tǒng)一的語義表達(dá)
主動(dòng)元數(shù)據(jù)+知識(shí)圖譜（元數(shù)據(jù)圖結(jié)構(gòu)、血緣），基于元數(shù)據(jù)的推薦等擴(kuò)展能力
統(tǒng)一數(shù)據(jù)目錄、統(tǒng)一的Table行列存儲(chǔ)結(jié)構(gòu)、統(tǒng)一緩存
跨域聯(lián)邦計(jì)算、自動(dòng)計(jì)算下推。
實(shí)現(xiàn)以上技術(shù)要素打造統(tǒng)一的虛擬層，為用戶提供元數(shù)據(jù)驅(qū)動(dòng)的數(shù)據(jù)推薦、計(jì)算下推和分散在各個(gè)存算引擎的數(shù)據(jù)資產(chǎn)的管理能力，讓數(shù)據(jù)分析和架構(gòu)設(shè)計(jì)更靈活，把復(fù)雜留給自己，簡單留給用戶。本文我們選擇Catalogue、Data Format、Cache、DataLineage、統(tǒng)一開發(fā)和語義幾個(gè)方面看下當(dāng)前大數(shù)據(jù)領(lǐng)域技術(shù)方案現(xiàn)狀，要實(shí)現(xiàn)完美的“統(tǒng)一”還差哪些工作。
Catalogue
在大數(shù)據(jù)產(chǎn)品中，數(shù)據(jù)目錄的組織通常分為三成，這里用比較通用的Catalog-Database-Table進(jìn)行展示，類比到MaxCompute（Project-Schema-Table)，不同計(jì)算引擎內(nèi)部的定義不一樣，比如Hive 沒有Catalog這一層，只有Database(Schema)-Table兩級(jí)，實(shí)現(xiàn)統(tǒng)一的Catalogue，需要有一個(gè)標(biāo)準(zhǔn)層將個(gè)性化數(shù)據(jù)目錄的結(jié)構(gòu)進(jìn)行轉(zhuǎn)換，轉(zhuǎn)換成某個(gè)標(biāo)準(zhǔn)化的統(tǒng)一的Catalogue Virtual Layer，通常三層數(shù)據(jù)目錄架構(gòu)的實(shí)現(xiàn)包括以下細(xì)節(jié)：
Catalog實(shí)現(xiàn)抽象通常每個(gè)引擎內(nèi)部都有自己的Catalog實(shí)現(xiàn)比如Spark有自己的SparkCatalog，StarRocks有自己的StarRocksCatalog，支撐其計(jì)算引擎的邏輯計(jì)劃、物理計(jì)劃生成和優(yōu)化，其數(shù)據(jù)結(jié)構(gòu)的細(xì)節(jié)會(huì)有差異。通常包括以下配置:
Impl：具體Catalog的實(shí)現(xiàn)類，影響URL和IO的配置
Url: Catalog的存儲(chǔ)地址，可以是S3、HDFS，根據(jù)Impl的定義有差異
IO: Catalog具體的IO讀寫實(shí)現(xiàn)，比如S3的Catalog存儲(chǔ)既可以選擇用Hadoop-S3去讀寫，也可以直接使用S3FileIO Client讀寫，或者通過Restful API
Warehouse：實(shí)際數(shù)據(jù)的存儲(chǔ)地址，可以是HDFS、S3或其他分布式存儲(chǔ)
如果要實(shí)現(xiàn)跨引擎的Catalog通用，比如讓Spark識(shí)別Hive MetaStore里邊的元數(shù)據(jù)，需要在Spark的運(yùn)行時(shí)加載HiveCatalog的實(shí)現(xiàn)遠(yuǎn)程讀寫HMS并轉(zhuǎn)換成Spark內(nèi)部的計(jì)算引擎可以使用的元數(shù)據(jù)，我們以目前比較流行的Data Lake舉例，Iceberg對各個(gè)引擎的適配比較好，統(tǒng)一Table Schema與Catalog的讀寫屏蔽一些引擎的差異，下圖展示我們常見的一些數(shù)倉、數(shù)據(jù)湖產(chǎn)品元數(shù)據(jù)目錄的實(shí)現(xiàn)，簡單示意Iceberg是怎么實(shí)現(xiàn)的。
一些湖倉產(chǎn)品Catalog聯(lián)動(dòng)關(guān)系Iceberg已經(jīng)實(shí)現(xiàn)了多種Catalog存儲(chǔ)的兼容，支持多種計(jì)算引擎使用Iceberg的Catalog來建立External Table，這個(gè)過程需要定制化將Iceberg的Catalog轉(zhuǎn)換成其引擎內(nèi)部支持的Catalog的具體Implement，也就是上圖所依賴的iceberg-spark-runtime-3.3_2.12:1.1.0.jar，后邊的一串?dāng)?shù)字3.3_2.12:1.1.0 表示適配基于Scala 2.12編譯的Spark 3.3版本，冒號(hào)后邊的1.1.0代表IceBerg的版本，不同版本的計(jì)算引擎、湖之間的適配不夸張的說是個(gè)笛卡爾積的過程，每發(fā)行一個(gè)新的runtime要適配各種引擎的各種版本，不小心用錯(cuò)了3.2版本的Spark的runtime jar，有可能在3.3集群上就會(huì)出各種Class Not Found的錯(cuò)誤。
@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里邊的一個(gè)方法舉例來說要想實(shí)現(xiàn)StarRocks與IceBerg的聯(lián)通，依賴個(gè)性化的適配邏輯導(dǎo)致適配本身是個(gè)點(diǎn)對點(diǎn)的過程。StarRocks目前支持HiveMetaStore以及Custom MetaData。IcebergHiveCatalog支持StartRocks讀取HMS里邊的Database&Table信息并轉(zhuǎn)換為StartRocks Catalog的過程，以getDB為例，hms client讀取db信息并convertToSRDatabase，適配的這個(gè)Class需要耦合源端、目標(biāo)端的Catalog的轉(zhuǎn)換邏輯，根據(jù)具體Catalog的存儲(chǔ)的IO的讀寫過程，相當(dāng)于一個(gè)三方的樞紐，而每種引擎的集成都類似，需要定制化一個(gè)IcebergXxxxCatalog，包括Flink、Spark、Hive等等引擎，涉及到Catalog的轉(zhuǎn)換與其物理存儲(chǔ)的讀寫，在大量的適配過程中元數(shù)據(jù)、存儲(chǔ)、計(jì)算形成了一種錯(cuò)綜復(fù)雜的網(wǎng)絡(luò)，且當(dāng)某個(gè)引擎增加了新的特性適配層沒有跟上也會(huì)影響整體大數(shù)據(jù)架構(gòu)的升級(jí)，統(tǒng)一和效率之間就存在了矛盾。Iceberg以及各個(gè)引擎的合作已經(jīng)實(shí)現(xiàn)了非常多的引擎和Catalog存儲(chǔ)之間點(diǎn)對點(diǎn)的適配，也是在其自身價(jià)值得到證實(shí)的情況下持續(xù)迭代、開源社區(qū)推廣運(yùn)營的結(jié)果。要實(shí)現(xiàn)Data Fabric需要獨(dú)立實(shí)現(xiàn)一個(gè)更上層的統(tǒng)一的Catalogue層，兼容IceBerg、Hudi、DeltaLake等不同的數(shù)據(jù)湖格式，僅僅是Catalog的適配就需要很大的工作量，且很有可能更新跟不上各個(gè)引擎或者存儲(chǔ)百花齊放的演進(jìn)速度。實(shí)現(xiàn)統(tǒng)一的Virtual Layer，本質(zhì)上是執(zhí)行效率、學(xué)習(xí)成本和通用性的沖突和平衡。如何找到一個(gè)演進(jìn)的動(dòng)態(tài)平衡點(diǎn)，而目前可行的存算都是點(diǎn)對點(diǎn)集成方式，統(tǒng)一集成對于虛擬層來說成本高，新Feature兼容壓力大，需要找到一個(gè)演進(jìn)的平衡點(diǎn)。
Data Format
除Catalog外，Data Fabric實(shí)現(xiàn)所需要的每個(gè)技術(shù)要素都需要類似的架構(gòu)出現(xiàn)，以下例子從簡，從圖中所展示的連接關(guān)系可以發(fā)現(xiàn)類似的規(guī)律，比如Apache Arrow作為一種Columnar memory format 支持不同的引擎比如spark、impala里邊的dataframe計(jì)算抽象，提高計(jì)算效率，優(yōu)化數(shù)據(jù)在不同的計(jì)算引擎中抽象和轉(zhuǎn)換的計(jì)算效率，統(tǒng)一數(shù)據(jù)格式，優(yōu)化切換引擎中間結(jié)果落盤過程中序列化和反序列化的處理效率。
Unity Columnar Format構(gòu)建Data Fabric的數(shù)據(jù)平臺(tái)同樣需要有一種數(shù)據(jù)格式抽象解決存算分離架構(gòu)下數(shù)據(jù)的存儲(chǔ)格式問題，當(dāng)?shù)讓右嬗蠵arquet、CarbonData等不同的文件格式，上層構(gòu)建的聯(lián)合計(jì)算引擎需要能夠兼容不同的文件格式，Data Format這一層的抽象必不可少，在跨引擎的計(jì)算過程中減少不必要的序列化。
Data Lineage | Data Discovery
數(shù)據(jù)血緣是大數(shù)據(jù)分析的必備組件，大多數(shù)的計(jì)算引擎都有其內(nèi)部的元數(shù)據(jù)和DAG管理能力，當(dāng)數(shù)據(jù)鏈路存在跨引擎或者平臺(tái)的依賴，需要將上下游的血緣聚合到統(tǒng)一的血緣中心，形成完整的數(shù)據(jù)鏈路全景，提高問題溯源分析和影響分析。有些大數(shù)據(jù)組件的的元數(shù)據(jù)和血緣集成在自身Catalog能力，有些大數(shù)據(jù)產(chǎn)品只支持基礎(chǔ)的數(shù)據(jù)目錄和Table Schema，還有一些支持到Table Lineage&Column Lineage。構(gòu)建跨平臺(tái)的數(shù)據(jù)血緣我們需要有一個(gè)第三方的組件建立血緣標(biāo)準(zhǔn)，支持將數(shù)據(jù)的血緣從其自身的元數(shù)據(jù)存儲(chǔ)、任務(wù)提交和運(yùn)行的過程匯總，轉(zhuǎn)換成通用的血緣Model，并將跨平臺(tái)的血緣信息整合為血緣全景，支持跨引擎的代碼提示或者計(jì)算優(yōu)化。
Data Lineage Architecture數(shù)據(jù)血緣目前有非常多的第三方組件，在構(gòu)建大數(shù)據(jù)平臺(tái)過程中選擇較多，也會(huì)造成點(diǎn)對點(diǎn)集成的情況，我們可以選擇其一作為統(tǒng)一的后端，依賴各種采集、解析和標(biāo)準(zhǔn)化技術(shù)將分散在引擎和元數(shù)據(jù)中的任務(wù)、表和字段之間的關(guān)系固化到統(tǒng)一的后端服務(wù)，我們以O(shè)pen Lineage和DataHub為例，OpenLineage通過Wrapper、Proxy或者javaagent將運(yùn)行時(shí)提交任務(wù)過程的事件信息采集到統(tǒng)一的血緣中心，實(shí)現(xiàn)表、任務(wù)之間的血緣存儲(chǔ)和展示，目前已經(jīng)開始支持Column LIneage。元數(shù)據(jù)信息的收集和血緣的分析通常有這幾種方式：
Cli Wrapper：對于Python開發(fā)的客戶端，代碼可以重新封裝，替換原默認(rèn)的命令行腳本，在提交過程解析任務(wù)執(zhí)行的代碼，分析血緣并轉(zhuǎn)發(fā)給后端；
java agent：適用于Java開發(fā)的submit job 過程，侵入Jvm加載字節(jié)碼的過程，分析代碼中的血緣并轉(zhuǎn)發(fā)給LIneage Backend遠(yuǎn)程地址；
event listener：對于支持Extra Listener擴(kuò)展的計(jì)算框架，提供定制化的Listener配置，運(yùn)行時(shí)過程中手機(jī)元數(shù)據(jù)信息轉(zhuǎn)發(fā)給后端；
第三代的元數(shù)據(jù)中心DataHub支持流式的元數(shù)據(jù)日志協(xié)議，類似于CDC的MCP（Metadata Change Proposal）協(xié)議，通過source插件ingest并extract到內(nèi)部的元數(shù)據(jù)存儲(chǔ)，根據(jù)元數(shù)據(jù)來源的特點(diǎn)也可以支持column-lineage以及自定義的元數(shù)據(jù)分析能力，比如基于databrick的unity catalog從元數(shù)據(jù)中獲取血緣，對于不支持血緣的比如hive就只能查詢到table、column的schema信息以及數(shù)據(jù)統(tǒng)計(jì)信息。類似于open lineage作為一個(gè)后端去存儲(chǔ)各種元數(shù)據(jù)，DataHub兼容的源端種類更多，2022年8月份的新Feature開始支持Column LIneage，支持pull-based/push-bashed元數(shù)據(jù)集成方式，做為大數(shù)據(jù)平臺(tái)之外的第三方元數(shù)據(jù)中心，通過實(shí)時(shí)的流式的元數(shù)據(jù)變更以及元數(shù)據(jù)聯(lián)邦查詢能力，訂閱源端元數(shù)據(jù)的變更事件提高元數(shù)據(jù)的實(shí)效性，保障實(shí)時(shí)可用，下游應(yīng)用也可以訂閱DataHub元數(shù)據(jù)的變更來進(jìn)行比如查詢優(yōu)化、鏈路監(jiān)測的能力。
統(tǒng)一的開發(fā)IDE與語義
以DBT為例，上文提到過Data Mesh可以通過dbt+snowflake的形式構(gòu)建，dbt作為統(tǒng)一的開發(fā)管理層，實(shí)現(xiàn)類似軟件開發(fā)過程中的software enginerring、package management、macros、hooks 以及通過incremental materialization實(shí)現(xiàn)的 DAG level optimization能力。目標(biāo)是提高代碼模塊的復(fù)用性，通過select語義以及ref 引用構(gòu)建module的定義和關(guān)聯(lián)關(guān)系，compile生成目標(biāo)warehouse sql提交給引擎運(yùn)行，但dbt開發(fā)moddular data model使用的SQL并不是一種統(tǒng)一的表達(dá)形式，而是所選擇的warehouse自身的dialect，數(shù)據(jù)的處理不會(huì)離開sql運(yùn)行的存算引擎。dbt sn't actually Magic. your data is not processed outside of your warehouse.dbt實(shí)現(xiàn)了snowflake、redshift、bigquery等平臺(tái)的adapter，作用于macros和compile的過程，數(shù)據(jù)的計(jì)算完全在底層引擎內(nèi)執(zhí)行，dbt控制代碼的復(fù)用、執(zhí)行過程。而支持聯(lián)合計(jì)算的比如trino或者StarRocks提供了統(tǒng)一的SQL支持跨多種數(shù)據(jù)源和計(jì)算引擎的查詢，但Trino實(shí)現(xiàn)的是各種數(shù)據(jù)源的connector，數(shù)據(jù)會(huì)離開原來的位置在上層引擎進(jìn)行，二者有很大的區(qū)別。
還有Semantics、Orchestration、Active MetaData、FederatedCompute等等
通過上文的catalog、format、lineage、sql的表達(dá)幾種技術(shù)要素方案的討論，可以看到這些圖長得都差不多，中間有一層抽象成統(tǒng)一的XX，實(shí)現(xiàn)Fabric的架構(gòu)前提要把所有的點(diǎn)對點(diǎn)的集成都屏蔽掉，可以依賴以上的一些產(chǎn)品進(jìn)行組合、擴(kuò)展集成，拼裝成一層虛擬的Virtual Layer。而目前各種適配和統(tǒng)一還只存在于技術(shù)要素局部，宏觀上大數(shù)據(jù)產(chǎn)品的異構(gòu)還是常態(tài)，為了追求計(jì)算效率計(jì)算引擎通常與存儲(chǔ)會(huì)避免通過中間層的額外做一層轉(zhuǎn)換。更可行的是在某個(gè)引擎作為基準(zhǔn)來擴(kuò)展支持更廣泛的數(shù)據(jù)源、數(shù)據(jù)格式和元數(shù)據(jù)，屏蔽底層其他種類的WareHouse或者數(shù)據(jù)湖的差異，現(xiàn)在比較流行的湖倉一體概念，可以看做是輕量化的Fabric實(shí)現(xiàn)，實(shí)現(xiàn)Catalog層面的統(tǒng)一，比如MaxCompute可以直接通過DLF或者對Hive MS的適配實(shí)現(xiàn)對外部數(shù)據(jù)湖、數(shù)倉的聯(lián)合計(jì)算。Data Fabric目標(biāo)是打造一個(gè)完整的虛擬層，創(chuàng)造一種新的魔法，基于同一的各種抽象開展數(shù)據(jù)工程，但這些統(tǒng)一的適配工作需要大量的工作，目前還沒有統(tǒng)一的語義的抽象能夠兼容所有的引擎，一些比較個(gè)性化的優(yōu)化器、hint、存儲(chǔ)格式和壓縮算法、物化與虛擬化的技術(shù)都會(huì)導(dǎo)致通用表達(dá)無法下推到底層的引擎，專業(yè)性與通用性一定是沖突的，需要進(jìn)行兩層抽象，過度抽象可能會(huì)導(dǎo)致輪子以低功率運(yùn)行，無法發(fā)揮底層引擎的優(yōu)勢。從可行性角度，F(xiàn)abric可以在有限的存、算、調(diào)度組件上可行，聯(lián)合Data Mesh實(shí)現(xiàn)最終的架構(gòu)效果，Trino 2022 Summit也提到“Elevating Data Fabric to Data Mesh: solving data needs in hybrid data lakes”，通過trino跨引擎、跨實(shí)例組合出Fabric的架構(gòu)特點(diǎn)，并向Data Mesh的演進(jìn)，未來支撐Fabric的組件也會(huì)持續(xù)出現(xiàn)。當(dāng)前階段各數(shù)據(jù)平臺(tái)更多聚焦打造自己的核心能力，并兼顧對于外部優(yōu)秀的元數(shù)據(jù)、調(diào)度、存儲(chǔ)等系統(tǒng)的適配，體現(xiàn)存算分離的基礎(chǔ)上讓自己的生存空間更大，同時(shí)標(biāo)準(zhǔn)化自己的擴(kuò)展能力，開放Adapter的邏輯給社區(qū)，持續(xù)豐富其對外的各種適配。實(shí)現(xiàn)Data Mesh相對來說要更靈活一些，不強(qiáng)求在統(tǒng)一的技術(shù)棧進(jìn)行數(shù)據(jù)工程開發(fā)，數(shù)據(jù)在原地的同時(shí)，技術(shù)棧以及開發(fā)的習(xí)慣可以保持自治，二者組合在跨數(shù)據(jù)湖的集群實(shí)例上增加新的相對獨(dú)立的統(tǒng)一元數(shù)據(jù)中心和聯(lián)邦計(jì)算能力，讓DataProduct之間以類似微服務(wù)的API的形式流轉(zhuǎn)起來，支撐跨域的數(shù)據(jù)應(yīng)用。
與大數(shù)據(jù)技術(shù)服務(wù)的關(guān)系
最后簡單說下這兩個(gè)概念對我們大數(shù)據(jù)技術(shù)服務(wù)的影響，回顧以上的概念和技術(shù)分析，Data Fabric和Data Mesh從框架理念上解決數(shù)據(jù)和組件分散的問題，在企業(yè)信息化轉(zhuǎn)型中我們通常會(huì)遇到一些并非是從零開始構(gòu)建大數(shù)據(jù)平臺(tái)的客戶，希望能夠上到公共云或者混合云阿里側(cè)的大數(shù)據(jù)產(chǎn)品，構(gòu)建一套新的大數(shù)據(jù)平臺(tái)的同時(shí)要考慮現(xiàn)有的數(shù)據(jù)和任務(wù)如何平滑快速的遷移，在進(jìn)行擴(kuò)容和升級(jí)的時(shí)候，如何規(guī)劃架構(gòu)的設(shè)計(jì)實(shí)現(xiàn)平滑的演進(jìn)，多種架構(gòu)如何共存，以及客戶已有的數(shù)據(jù)如何快速敏捷的支撐上層的應(yīng)用建設(shè)，將數(shù)據(jù)匯聚到單體中臺(tái)還是靈活的Data Mesh結(jié)構(gòu)。核心就是解決大數(shù)據(jù)平臺(tái)從A到B、AB共存以及長期的數(shù)據(jù)生產(chǎn)運(yùn)營問題。
大數(shù)據(jù)技術(shù)服務(wù)為了支持異構(gòu)大數(shù)據(jù)組件之間的轉(zhuǎn)換和架構(gòu)演進(jìn)設(shè)計(jì)，我們在服務(wù)的過程中會(huì)參考DataFabric的技術(shù)思想沉淀技術(shù)組件和各種adapter，彌補(bǔ)平臺(tái)與平臺(tái)、平臺(tái)與用戶之間的GAP，持續(xù)打造標(biāo)準(zhǔn)的元數(shù)據(jù)、調(diào)度、集成抽象以及全鏈路的大數(shù)據(jù)可觀測的標(biāo)準(zhǔn)抽象，在此基礎(chǔ)上進(jìn)行架構(gòu)演進(jìn)和數(shù)據(jù)生產(chǎn)運(yùn)營，在Data Fabric的一些技術(shù)要素點(diǎn)上進(jìn)行增強(qiáng)，也結(jié)合data mesh的方法論結(jié)合業(yè)務(wù)場景做一些架構(gòu)設(shè)計(jì)：
大數(shù)據(jù)異構(gòu)平臺(tái)的遷移（解決從A到B的問題）：幫助客戶實(shí)現(xiàn)快速低成本數(shù)據(jù)、任務(wù)和調(diào)度統(tǒng)一遷移到云上阿里云大數(shù)據(jù)產(chǎn)品。搬站服務(wù)和工具的一些設(shè)計(jì)與輕量級(jí)的Data fabric關(guān)聯(lián)較大，比如數(shù)據(jù)遷移依賴MaxCompute的湖倉一體（Inside Hadoop方案）加速客戶的數(shù)據(jù)遷移過程。內(nèi)部抽象統(tǒng)一的血緣分析和調(diào)度的標(biāo)準(zhǔn)化轉(zhuǎn)換屏蔽了客戶各種Script、調(diào)度DAG的差異。
湖倉、流批架構(gòu)規(guī)劃服務(wù)（解決A與B共存演進(jìn)問題）：部分客戶提到希望可以提供持續(xù)演進(jìn)的規(guī)劃，中間態(tài)多產(chǎn)品共存，比如通過擴(kuò)展MaxCompute的標(biāo)準(zhǔn)插件實(shí)現(xiàn)與開源大數(shù)據(jù)引擎的聯(lián)合分析，或者基于HDFS聯(lián)邦新老集群共存，在在某些架構(gòu)咨詢項(xiàng)目，設(shè)計(jì)統(tǒng)一的數(shù)據(jù)湖元數(shù)據(jù)中心組件實(shí)現(xiàn)存儲(chǔ)計(jì)算結(jié)構(gòu)平滑擴(kuò)容。
數(shù)據(jù)生產(chǎn)運(yùn)營優(yōu)化（數(shù)據(jù)價(jià)值與生產(chǎn)平衡問題）：結(jié)合data fabric架構(gòu)思想設(shè)計(jì)統(tǒng)一的全鏈路的數(shù)據(jù)血緣幫助客戶做全面的存儲(chǔ)、槽位、Quota等資源分析和優(yōu)化。對于客戶當(dāng)前已經(jīng)有多平臺(tái)共存、云邊端協(xié)同等場景的大數(shù)據(jù)架構(gòu)設(shè)計(jì)場景，基于data mesh的理論框架，實(shí)現(xiàn)數(shù)據(jù)敏捷分析、快速體現(xiàn)數(shù)據(jù)業(yè)務(wù)化價(jià)值。
搬站工作臺(tái)
大數(shù)據(jù)搬站工作臺(tái)
大數(shù)據(jù)生產(chǎn)運(yùn)營優(yōu)化
大數(shù)據(jù)平臺(tái)運(yùn)營過程中客戶的存儲(chǔ)和計(jì)算水位長期處于高位，數(shù)據(jù)集成等任務(wù)出現(xiàn)堆積，通過對大數(shù)據(jù)平臺(tái)的元數(shù)據(jù)、數(shù)據(jù)血緣、存儲(chǔ)的分布進(jìn)行綜合分析，實(shí)現(xiàn)全鏈路的生產(chǎn)經(jīng)營優(yōu)化。結(jié)合Data Fabric架構(gòu)設(shè)計(jì)伴生大數(shù)據(jù)平臺(tái)的獨(dú)立的第三方運(yùn)營工具，抽象統(tǒng)一的元數(shù)據(jù)采集、圖譜關(guān)系構(gòu)建，上下游影響分析，為運(yùn)營優(yōu)化技術(shù)服務(wù)提供數(shù)據(jù)與決策支撐。
數(shù)據(jù)生產(chǎn)運(yùn)營優(yōu)化從業(yè)務(wù)場景我們在能源與制造一些領(lǐng)域探索Data Mesh的方法論，生產(chǎn)數(shù)據(jù)的過程中通常在多個(gè)業(yè)務(wù)域都有自己的采集、處理和分析的需求，內(nèi)部通常也有小規(guī)模的開源或者自建的大數(shù)據(jù)產(chǎn)品，同時(shí)各領(lǐng)域的數(shù)據(jù)需要協(xié)同計(jì)算，算法團(tuán)隊(duì)依賴工控的數(shù)據(jù)進(jìn)行模型訓(xùn)練，預(yù)測的結(jié)果以服務(wù)的形式對管控提供服務(wù)，結(jié)合Data Mesh的架構(gòu)設(shè)計(jì)，將不同領(lǐng)域數(shù)據(jù)的生產(chǎn)過程的輸入輸出聯(lián)動(dòng)起來，合理設(shè)計(jì)生產(chǎn)數(shù)據(jù)和分析數(shù)據(jù)的處理鏈路的邊界，數(shù)據(jù)的生產(chǎn)、基礎(chǔ)的計(jì)算分析和服務(wù)化保留在多個(gè)Domain中，通過MaxCompute與OSS外表結(jié)合簡化各個(gè)業(yè)務(wù)輸出數(shù)據(jù)之間的聯(lián)合分析，通過數(shù)據(jù)湖共享各個(gè)分析系統(tǒng)的數(shù)據(jù)產(chǎn)品，中間層設(shè)計(jì)相對簡化，減少由于鏈路長帶來的數(shù)據(jù)一致性和數(shù)據(jù)權(quán)責(zé)問題。
