[数据管理] 数据编织（Data Fabric）

0 序

  • 核心结论：
  • 【数据编织】是“跨源逻辑统一 + 主动元数据 + 语义 + 治理”的架构范式；
  • 【本体建模】是语义底座；
  • 【数据湖仓】是集中式/近集中式的存储计算平台
    三者不是替代关系，而是“湖仓做体力、本体做语义、编织做调度与发现”。

image

image

1 概述： 数据编织（Data Fabric）

数据编织（Data Fabric）是什么、解决什么问题

  • 日前，Gartner发布的2022年重要战略技术趋势，Data Fabric（数据编织）赫然在列。自2019年起，Gartner连续数年将数据编织（Data Fabric）列为年度数据和分析技术领域的十大趋势之一。

根据全球行业分析师报告，全球数据编织市场从2020年的11亿美元，到2026年将增长超过3倍，达到37亿美元。这些统计数据，表明了这一领域的强劲需求。
在Data Fabric出来之前，数据架构的设计主要部署成【静态基础设施】，而在未来将需要采用更动态的数据网格方法全面重新设计。

  • Data Fabric 是一种通过共享元数据、知识图谱、语义、AI/ML 与集成层，把分布在不同系统/云/边缘的数据“编织”成统一可发现、可治理、可消费视图的架构设计模式；

Gartner 认为数据编织是一种跨平台的数据整合方式，它不仅可以集合所有业务用户的信息，还具有灵活且弹性的特点，使得人们可以随时随地使用任何数据。
【Data Fabric】不是一个产品而是一种设计理念；它不要求把所有数据物理集中。

  • 主要解决：
  • 多源异构、跨云/本地/边缘，数据找不到、对不齐、不敢用
  • 传统 ETL 集中搬运成本高、时效差、口径易漂移
  • 元数据静态、血缘不全、治理靠人肉
  • 业务术语（“客户/收入/活跃”）与物理字段（user_id/revenue/gmv）语义不一致
  • AI/分析取数链路太长，数据产品难复用
  • IBM 对 Data Fabric 的核心能力归纳为：数据目录、数据集成、治理与安全、自助访问、统一生命周期；
  • 技术支柱含主动元数据、知识图谱、语义、AI/ML、数据虚拟化。
  • Gartner 口径强调: 主动元数据 + 知识图谱 + 语义 + ML 来增强集成设计与交付，SnapLogic 也把它定义为“设计模式而非单品”。

image

典型分层

  • 数据源：ERP/CRM/主数据/湖仓/对象存储/IoT/文件/外部数据
  • 采集与集成：批/流/CDC/API/ETL/ELT/虚拟化/联邦查询
  • 主动元数据与治理：技术/业务/操作元数据、血缘、质量、分类、权限、策略
  • 语义层：本体/分类法/指标词典/业务术语→物理映射
  • 知识图谱：实体—关系—资产网络，支撑发现与推理
  • 编排与服务：虚拟化、联邦、自动映射、策略下发、数据产品交付
  • 消费：BI、数据科学、LLM/Agent、业务自助、运营系统

数据编织、本体建模、数据湖仓

本体建模: 在其中的位置（容易混淆）

  • 本体建模（Ontology）用形式化方式定义业务实体、属性、关系、约束、规则、动作

例如“客户”包含个人/企业子类，“订单”关联“客户/产品/渠道/金额/币种”，“收入”有确认口径、税、退货冲减规则。它回答“这个词到底指什么、和别的词什么关系”。

  • 与知识图谱的区别（工程口径）：
  • 本体＝模式/语义契约（类、属性、关系、公理），相对稳定，人工+业务确认为主
  • 知识图谱＝本体实例化+元数据关联，存“A 客户=CRM ID+核心系统账号+图谱节点+血缘”，可自动发现边
  • 主动元数据＝物理层事实（表、字段、任务、质量、访问日志），被本体/图谱解释

低权实践材料把 Data Fabric 支柱补成“本体+主动元数据+知识图谱+AI”四层，强调没有【业务本体】，仅靠字段级元数据解决不了深层语义冲突；
语义知识图谱厂商也强调标准化模型/分类法做跨源语义调和。

数据湖仓（Lakehouse）: 是什么、与数据编织的边界

  • Lakehouse＝在低成本对象存储/数据湖之上，用开放表格式（Delta/Iceberg/Hudi）提供数据仓库能力：ACID、schema enforcement/evolution、时间旅行、版本、元数据层、统一目录，支撑 SQL BI 与 ML 共用一份存储。
  • 典型层：摄取→存储（S3/ADLS/GCS+Parquet/ORC）→表格式/元数据（Delta/Iceberg/Hudi+Metastore/Catalog）→查询/计算（Spark/Trino/StarRocks/引擎解耦）→消费（BI/DS/ML）。Medallion 可拆 Bronze/Silver/Gold。
  • 它的强项是“把数据集中/近集中存好、算好、管出质量”；弱项是天然不解决跨多个独立平台、遗留系统、外部云、边缘的语义发现与联邦治理——这正是 Data Fabric 的补层。

关系总表

维度 本体建模 Ontology/Semantic Model 数据湖仓 Lakehouse 数据编织 Data Fabric
本质 语义/业务模型层（模式与规则） 存储+表格式+计算治理平台 跨源逻辑统一架构/设计模式
核心对象 实体、属性、关系、口径、约束、指标定义 表、分区、文件、事务、元数据、物化层 元数据、图谱、语义映射、集成策略、数据产品
是否搬数据 不搬，只定义映射与规则 通常集中/近集中落地存储 可搬可不搬；优先虚拟化/联邦，必要时物化
主要价值 统一业务语言，消除“同词异义/异词同义” 低成本存全量+仓级事务/性能/一致性 跨系统发现、对齐、治理、自助与自动交付
关键技术 OWL/SHACL/JSON-LD/词汇表/指标层/分类法 对象存储、Iceberg/Delta/Hudi、Metastore、Spark/Trino 主动元数据、知识图谱、语义层、虚拟化、AI推荐、数据目录
治理方式 语义规则、命名/口径/主数据约束 平台内集中：质量、权限、schema、血缘、ACID 跨平台联邦治理：策略随数据位置执行、自动打标/告警
适用痛点 业务术语混乱、跨域指标不对齐 海量结构化/半结构化分析、BI+ML 一体、替代湖+仓双写 多平台/多云/遗留系统、数据分散、发现慢、合规跨域
不适用/注意 只建本体不接元数据=空中楼阁 纯边缘/强隔离/不许集中时难做唯一真源 元数据与本体空白时硬上=把混乱“编织”得更隐蔽

本质区别

  • 湖仓回答“数据放哪、怎么存成可靠表、怎么高效算”；
  • 本体回答“业务概念到底是什么、跨系统怎么对齐”；
  • 编织回答“分散在各处的数据如何不搬家也能被发现、懂语义、受治理、按需供给”。

用集合说：Lakehouse 是 Fabric 的“候选节点之一”；本体是 Fabric 语义子层；Fabric 可把多个湖仓、数仓、ERP、数据产品连起来。

总体协同架构

flowchart TB subgraph SRC[数据源/平台] ERP[ERP/CRM/主数据] DWH[传统数仓] LH[数据湖仓<br/>S3+Icerberg/Delta] OBJ[对象存储/文件/非结构] EDGE[IoT/边缘/外部API] end subgraph FABRIC[Data Fabric 控制面] ING[采集/集成<br/>批/流/CDC/API/ETL-ELT] ACTM[主动元数据<br/>技术/业务/操作/血缘/质量/使用日志] ONTO[本体/语义层<br/>实体-属性-关系-指标口径-分类法] KG[知识图谱<br/>实例映射+资产关系+同义解析] GOV[治理与安全<br/>分类/权限/策略/合规/质量规则] ORCH[编排与虚拟化<br/>联邦查询/数据虚拟化/自动映射/数据产品] CAT[数据目录/市场<br/>业务术语搜索/自助申请] end ACTM --> ONTO --> KG --> ORCH ING --> ACTM GOV --> ACTM GOV --> ORCH ORCH --> CAT subgraph CONS[消费] BI[BI/报表] DS[数据科学/特征] AGENT[LLM/Agent/自然语言取数] OPS[运营系统/实时服务] end SRC --> ING SRC -.元数据/虚拟化.-> FABRIC CAT --> CONS ORCH --> CONS

要点：湖仓在左侧当“高质量物理节点”；本体+KG在中间把物理字段翻译成业务语义；编排层决定“虚拟化直查”还是“落地湖仓物化”，并把治理策略推到各源。

数据流动与“搬不搬”的决策

flowchart LR A[新请求: 跨域客户利润分析] --> B{数据是否已在同一湖仓且口径一致?} B -- 是 --> C[湖仓内Gold/语义指标直接查] B -- 否 --> D{是否涉及不允许集中/低延迟/临时候查?} D -- 是 --> E[Fabric虚拟化+联邦+本体映射+行级权限] D -- 否 --> F{是否高频/性能敏感/需稳定口径?} F -- 是 --> G[ETL/ELT落地湖仓Silver-Gold+注册本体指标] F -- 否 --> E C --> H[目录发布为数据产品] G --> H E --> H

避免一个误区：【Fabric】 不是“绝不搬数据”，而是“按治理、性能、合规、成本决定搬不搬”；【湖仓】负责高频可靠物化，虚拟化负责长尾临时候查。

与数据仓库/数据湖/数据网格的扩展对比

架构 数据放置 语义能力 治理 适合作为Fabric的什么
数仓 集中 强但封闭、按仓内模型 集中强 可作为被编织的分析节点
数据湖 集中原始文件 弱，schema-on-read 靠外围补 编织前先补目录/质量
湖仓 近集中、开放表格式 中—强（可接语义层） 平台内强、跨平台弱 Fabric 首选物理底座
数据网格 领域分布式 各领域自定+全局标准 联邦计算治理 与Fabric互补：网格管组织，Fabric管技术协调
数据虚拟化 不搬、逻辑视图 取决于目录/语义层 静态规则居多 Fabric子集能力，不等于整体Fabric

IBM 对三者定位：Lakehouse 偏技术平台演进，Data Mesh 偏运营模型/文化变革，Data Fabric 偏用现有资产渐进整合。

落地建议：什么时候建哪个、怎么组合

  • 只有1–2个主要分析平台、要BI+ML统一：先湖仓（Iceberg/Delta）+ 元数据/目录+指标语义层；别急着全量 Fabric。
  • 多套湖仓/数仓/遗留核心/多云、找数据靠人问：上 Fabric 控制面——主动元数据+目录+虚拟化+知识图谱；本体只先做核心实体（客户/产品/组织/合同/订单）。
  • 指标口径争议大、AI问答总答错：本体/语义层必须先于“智能 agent”；把同义词、主数据映射、指标公式写进本体与指标词典，再接 KG 与 Fabric。
  • 强监管/数据出境/核心不出库：Fabric 虚拟化+就地治理，湖仓只存非敏感或脱敏区。
  • 组织按领域拆分、要数据产品制：网格+湖仓+Fabric 混合——网格定所有权，湖仓做平台，Fabric做跨域发现与策略。

建设顺序（精简）

  1. 盘点【数据源】与【元数据】成熟度，先建主动元数据/血统（无元数据别谈 Fabric）
  2. 选【核心本体】：客户、产品、组织、地点、时间、订单、资产等，绑定【主数据】
  3. 数据湖仓落 Bronze/Silver/Gold，开放表格式+统一catalog
  4. 知识图谱关联“业务术语—本体—物理表—任务—质量事件”
  5. 虚拟化/联邦覆盖遗留与不常搬数据，高频场景物化到湖仓
  6. 目录市场化、策略自动化、再接 BI/ML/Agent

开源项目情况

  • 数据编织很少有一个“纯开源一体机”直接对标 IBM/Informatica/Denodo；业界更常见的是用主动元数据目录 + 联邦查询/虚拟化 + 知识图谱/本体 + 数据合约/网格控制面拼出来。

企业 DENODO SL 是一家专注于数据虚拟化技术的数据管理企业，成立于1999年，总部位于美国硅谷。该公司提供基于逻辑方法的数据集成、管理和交付平台，核心业务涵盖自助式商业智能、数据科学、混合/多云数据集成及企业数据服务。2023年完成B轮融资3.36亿美元，投资方为TPG Growth[2-3]。 Denodo最初成立于西班牙拉科鲁尼亚，2006年将总部迁至硅谷。
下面按可落地组件列，并附公开案例 URL。

image

“数据编织”颠覆传统：5大理由告诉你数据虚拟化如何赋能自助式商业智能 - CSDN

image

开源/可自研的“数据编织能力栈”

编织子能力 代表开源项目 定位与特点 适合补足 Fabric 的哪一块
主动元数据/数据目录 DataHub（LinkedIn 开源） Kafka 事件驱动、ES/Neo4j、字段级血缘、RBAC、Action 自动化；大中厂治理首选 元数据总线、实时血缘、策略触发
主动元数据/目录（开箱即用） OpenMetadata MySQL/PG+ES，130+ 连接器，血缘/质量/术语表/语义上下文图，支持 RDF/OWL/DCAT，带 MCP/AI SDK 业务术语+指标口径+AI Agent 上下文
Hadoop 生态元数据 Apache Atlas HBase/Solr/JanusGraph，分类打标、Ranger 集成；但 UI 旧、社区慢 已有 Cloudera/Hive 的老平台治理
轻量发现目录 Amundsen（Lyft） Neo4j+ES，类 Google 搜索；血缘弱、治理弱 自助找表、快速试点
湖仓统一元数据中心 Apache Gravitino 多引擎 catalog，管理 Spark/Flink/Hive/Trino/Iceberg 等元数据，偏湖仓一体化 多引擎元数据统一、湖仓编目
联邦SQL/数据虚拟化 Trino（原 PrestoSQL） 分布式 SQL，广连接器（PG/MySQL/Kafka/S3/Iceberg/Delta/数仓），下推、跨源 JOIN 不搬数据跨源查询核心引擎
联邦SQL Presto / Starburst（商业） 与 Trino 同源分支，交互式跨源分析 同 Trino，Starburst 补企业安全
查询框架/优化器 Apache Calcite 可嵌入的 SQL 规划/优化/适配器框架 自研虚拟化、语义重写层
传统数据抽象/联邦 Teiid、Apache Drill Teiid 虚拟库跨关系源；Drill schema-on-read，查 JSON/Parquet/多源 关系抽象 / 半结构即查
Rust 联邦/嵌入式 DataFusion、Spice.ai OSS DataFusion 可嵌 Rust 引擎做下推；Spice 偏应用/AI 联邦加速 自研引擎、Edge/AI 取数
国产跨源OLAP Apache Doris（multi-catalog）、StarRocks 外部表 Doris 兼容 Trino 语义、查 Hive/Iceberg/ES/JDBC；StarRocks 外表明细/聚合下推 国内替代 Trino 做湖仓联邦
虚拟知识图谱/本体 Ontop 用 SPARQL 查关系库，R2RML/OBDA 把表映射成虚拟 RDF/OWL 知识图 本体层不物理落地、语义联邦
图本体/语义工具 Apache Jena、RDF4J、Neosemantics、GraphDB（社区版） RDF/OWL/SHACL、SPARQL、规则推理 业务本体、术语对齐、推理
数据网格/合约控制面 Open Data Mesh Initiative（ODM Platform、DPDS、SAS 规范） 数据产品描述、数据合约、schema annotation、产品市场/访问管理 编织+网格混合的组织/合约层

经验：纯 GitHub 搜 “data-fabric” 会冒出很多小项目（graviola、fabriq、CANDIL helm、agentic fabric 等），多为某一层原型，不建议作为企业主栈；生产用上表“目录+联邦+本体+网格规范”组合更稳。

一个“开源拼装版 Data Fabric”的参考架构

flowchart LR SRC[(ERP/CRM/湖仓/对象存储/OLTP/IoT)] -->|采集钩子/CDC/连接器| CAT[DataHub/OpenMetadata/Gravitino<br/>技术+业务元数据/血缘/术语] CAT --> ONTO[Ontop/Jena/自建OWL<br/>业务本体+指标口径+同义映射] ONTO --> KG[(知识图谱/语义上下文)] SRC -->|虚拟化查询| FED[Trino/Doris/StarRocks/Calcite<br/>联邦SQL/下推] CAT --> POLICY[治理策略:分类/权限/质量/合约 ODM-DPDS] POLICY --> FED KG --> FED FED --> SVC[目录自助/BI/ML/Agent MCP] CAT --> SVC

要点：【元数据】是控制面，【联邦引擎】是执行面，【本体/OG】是语义面，【ODM/数据合约】是组织面。

数据编制在国内实践是不是相对较少？

  • 结论：直接叫“Data Fabric/数据编织”的纯开源落地少，但政企/运营商/金融的“【智能数据编织、主动元数据、可信数据空间、湖仓一体】”实践不少；只是国内材料常换词，不换词就搜不到。

  • 运营商/多模态：广东移动“面向多模态数据的智能数据编织管理体系”、河北移动“基于数据编织+AI 的网络域数据资产管理”，亚信承建，治理效率提升近70%、安全风险降约90%

  • 政务/数据要素：贵州大数据集团“基于数据编织和可信数据空间的双空间数据授权运营”、以及“贵企”基于本体的 AI 用数赋能普惠金融 ；华为云 Stack 可信数据空间（知识图谱自动生成、跨域数据胶囊、TEE/TICS）含贵州公共数据、南通家纺等案例

  • 湖仓+AI 底座（常作为编织物理层）：科杰 KeenData Lakehouse 中石化 1.2PB/3727 标准项、中信银行实时风控与信贷、城市政府“1+4+N”可信数据空间

  • 自研开源栈：国内很多用 DataHub/OpenMetadata 做目录 + Trino/Doris/StarRocks 做联邦 + Jena/Neo4j 做本体，不买商业 Data Fabric；但对外多写“【元数据平台/湖仓/数据资产目录】”，很少写“开源数据编织产品”。

所以判断“少不少”要看口径：

  • 少＝少商业一体机、少纯开源 Fabric 发行版；
  • 不多＝少在公开可复现代码；
  • 实际多＝在央企/运营商/政务里以项目制落地，术语分散。

可访问案例 URL

开源项目

可以按“国产化替代+不买商业 Fabric”做选型，例如“DataHub/OpenMetadata 二选一 + Trino/Doris/StarRocks 二选一 + Jena/Ontop 本体层 + ODM 合约”给出一套最小可运行架构模式。

Y 推荐文献

X 参考文献

posted @ 2026-09-08 10:21  千千寰宇  阅读(29)  评论(0)    收藏  举报