导读 数据编织是分布式数据逻辑集成的关键，本次分享将对这种新型数据管理架构展开探讨，包括为什么我们需要数据编织，以及知语数据编织产品的相关研究和实践。
1. 背景知识简介
2. 知语数据编织
3. 场景实践案例
4. 总结与展望
分享嘉宾｜胡庆勇 北京知语清元科技有限公司 创始人
编辑整理｜杨倩
内容校对｜李瑶
出品社区｜DataFun
背景知识简介
为什么需要数据编织？回顾过去几十年，数据管理和知识管理是两条平行线，独立发展。现在到了认知人工智能时代，我们知道，数据原本就是分布式的，未来也将是分布式的。过去的数据管理方式和未来的数据管理方式如何与知识管理无缝衔接是当前需要思考的重要问题，数据编织正是在这样的背景下诞生的。
美国的数据编织技术已相对成熟，国内则需要我们一起努力推动数据编织的发展，应用先进的数据管理思想，以适应人工智能时代的需要。
问题之一：数据规模急剧扩大，数据处理速度远慢于数据增长速度，利用传统数据架构处理非结构化数据效率低。问题之二：在混合多云环境中，数据处理“高并发”，多重数据困境和复杂性增加。问题之三：数据高度分散，存在“数据孤岛”，烟囱式的封闭数据架构造成数据运用时的缺失与不便。重复数据：数据分层存储造成大量数据冗余。出现这一问题主要是为了解决性能问题，为了加速查询，不得不做一定的冗余，物化部分信息。其不仅意味着昂贵的存储空间价格；而且不够灵活，每次修改都需要对重复数据进行额外操作。非共享的元数据规范：不可共享的元数据规范降低了灵活性，难以管理，将会导致不一致的报告结果。灵活局限性：在商务智能系统中采用抽象化和封装的概念，对于提高自身的灵活性、更容易地实现改变和采纳新的工程技术非常重要。有局限的运营报告支持：从生产数据库中获取资源到报告中，数据需要多次复制到另一区域，在极短时间内完成不可能。大多数商务智能没有按照运营报告与运营数据关联的方式来设计。我们不得不简化结构来支持运营系统，最根本的是移除数据存储区和最少化复制步骤来简化结构。数据编织并非要取代数据仓库或数据湖，数仓和数据湖是物理集成的方式，而数据编织则是在逻辑层面上更好地管理数据，因此具有一些天然优势。
在数据编织 1.0 时代，Gartner 将数据编织定义为一种设计理念，充当数据和连接过程的集成层。当时只是定义了框架，并没有给出深入的实现方式。
2022 年，进入数据编织 2.0 时代，外部数据和边缘数据被更多地纳入中央数据范围，因此涉及如何将内部数据和外部数据做互联互通。
2024 年 3 月份，美军提出统一数据参考架构 UDRA，用数据编织的技术实现数据网格的架构，标志着数据编织已进入 3.0 时代。我们在做自己的信创产品时，可以直接基于 3.0 时代的架构。
在数据网格架构下，首先要把数据当作产品，还要明确所有数据的所有权，以及如何做自助服务和联合治理。数据编织 3.0 时代可以很好地支持数据网格的实现。
知语数据编织
知语数据编织智能体，旨在将数据编织引擎、大模型和知识管理全部网络化，构建虚拟数据网络。随着人工智能技术的推动，无论元数据还是数据，都在一套体系下进行数据编织，当然具体实现的技术引擎可能不同。我们不仅要解决单体模型的问题，还要解决主从模式部署、联邦式网络部署模式的问题，要实现与大模型之间的无缝整合。因此我们设计了如下图所示的智能体架构。
过去在做这种架构的时候，常常会把数据层做得很大。但是在数据编织体系下，重心回到了元数据的处理。元数据在整个数据编织网络体系下，是唯一的一个知识审核点，也就是说知识表示是通过元数据平台来表示的。我们所处理的数据还是分散在各处的，并不需要物理上全量集中，而元数据会被统一集中管理。包括技术元数据、管理元数据、业务元数据，都被统一管理，并且无论是结构化数据还是非结构化数据，所有的元数据模型都是统一的，甚至一些仪表盘、工作流程、机器学习模型的元数据也都统一在一个图模型的表示方法之下。
这里就会涉及如何自动提取这些元数据。知语主动元数据管理平台，通过推拉的方式，实现了全局的元数据服务。类似于京东淘宝，在可视化的产品平台上可以选择你所需要的数据产品。
知语数据联邦管理平台能够通过对物理位置分散的不同系统的数据进行联合查询、并行查询、水平集群扩展等方式，解决物理分布式数据的分析和洞察问题。我们并不需要从各处把数据物理集中起来，而是在逻辑层面访问和使用这些数据，并且与在任何应用客户端访问数据是没有差异的，这就是联邦的方式。
知语数据编织引擎现已支持 50 多种数据做数据联邦虚拟化，整体分成两类，一类是结构化数据，另一类是非结构化数据。通过图模型，把结构化和非结构化文件集成在一起，构建数据目录，以供查询。另外，为了更好地实现互联互通，还加入了语义增强的逻辑。
其它一些功能特点包括，支持各种类型用户角色，可并行已有数据平台部署，支持多云混合，以及支持分布式数据的统一访问。
目前支持的数据源包括：HDFS、关系型数据库、NoSQL 数据库、对象存储、云数据仓库，以及其它一些数据源，如 Kafka、Elasticsearch 等。
知语数据编织平台支持的第一种部署架构为单体模式。所有共享数据作为客户端，所有应用只知道数据编制平台提供的接口，并不知道数据源实际在哪。
第二种部署架构是主从模式，每个数据领域部署一套数据编织，如果需要其它领域的数据，则通过主平台来访问。
第三种部署架构是联邦模式，即数据网格模式，各领域部署了数据编织后，域之间联通，从任何点接入都可以访问全域数据。
目前推出了社区版、企业版和高级版三个版本，各有一些不同的能力，如下图所示：
场景实践案例
在第一个案例中，客户有 10 个采用不同技术构建的数据仓库，希望将其连接在一起。每天每个厂有超过 200G 的数据，如果将数据复制一遍，成本会非常大，因此采用了轻量级的数据编织的方式。
第二个案例中，旧的架构是将数据在物理上传到中心节点，时延高。为满足审计要求，需要实时查询、计算。针对这些需求，应用了数据编织技术。
总结与展望
在当今数据不断增长的情况下，可以通过物理和逻辑两种方式将数据整合并统一管理，物理上可以通过数据湖，而逻辑上就可以通过数据编织的方式。
现代数据架构如下图所示，原有数据中台依然保留，根据特定需要进行物理集成，而在此之上，加入数据编织，实现逻辑上的集成，并对外提供服务。
我们将数据编织能力成熟度定义了 L0~L4 五个级别，首先需要思维上的改变，并具备虚拟化的能力，在此基础上统一元数据，利用知识图谱，最终实现知识自动化。
数据编织是人工智能时代的数据基础设施。底层是各种物理数据源，中间建立数据编织层，在此基础上是各种模型，在模型之上是智能体应用。
本次分享中关于数据编织更多实践问题，请关注公众号”凯哥探数”。
教授级高工，清华大学毕业，清华大学创新领军工程博士。
研究方向:数据编织，知识图谱，大模型，数字孪生，数字交通。
北京知语清元科技有限公司创始人；
清华大学无锡应用技术研究院数字交通未来技术研究中心副主任；
清华大学校友总会 AI 大数据专委会理事；
工信部、科技部专家库成员；
河北、云南、广西公安厅交通大数据首席顾问；
主持编著了国内数据编织领域首部学术专著《数据编织》(清华大学出版社)，参编国内第一部交通大数据研究生教材《交通大数据分析与应用教程》(人民交通出版社)。作为第一发明人的专利 30+ 项，软件著作权 70+ 项。
