企业数据建设二十年反思（下）：事实与事理，企业数据建设的终极命题
展望未来，AI Agent时代的到来正在重新定义数据平台的边界。光有一个湖仓让Agent“查数”已经不够，Agent还得能“办事”——写工单、改库存、下单、回滚、持久化记忆，这些全是源端系统（TP）的工作。传统的TP/AP分离架构正在被推倒，这将是下一轮对企业数据使用价值更本质的重构。Databricks 在 Data+AI Summit 2025 提出了一个新词 LTAP（Lake Transactional/Analytical Processing），对应传统 HTAP 但语境换了——不是冲着银行核心账务去的，而是冲着 AI Agent 工作负载去的。当前主流的智能体场景（主动智能、多模态、外部编织、仿真推演）全是“数据→洞察→?”，“?”这一段传统是“人去执行”——人收到预警去改采购单、去调价、去派工单。Agent 时代“?”变成“Agent 直接写回业务系统”，这就必须碰源端系统（TP）：所以 LTAP/HTAP 不是“又一个性能升级”，而是把“决策→执行”的断裂缝合了——从“人找数”到“数据找人”，再下一步必须是“数据（Agent）直接办事”，否则 Agent 停在“顾问”阶段，进不了“员工”阶段。当 TP/AP 的墙被推倒，当 Agent 能直接读写数据，决定数据价值上限的不再是查询速度或事务能力，而是“AI 是否真正理解业务语义”。本体层（Ontology）正是这个“理解”的基石。没有它，LTAP 再快、Agent 再勤快，也只是在“数字的海洋里高速乱撞”。为什么本体层是 LTAP 时代的“灵魂” LTAP 让 Agent 既能查又能写，但如果 Agent 不理解“对公客户”和“对私客户”是两个不同的实体、“退货率”和“退款率”是不同的指标，它就会：写错字段（把退货原因写到备注里）问错问题（“本月客户退货率”实际上想查的是“本月个人客户退货率”）做出错误决策（因为误解了“活跃用户”的定义）本体层的作用：为机器提供一份企业共识的业务知识图谱——明确定义实体、属性、关系、约束、业务规则。例如：实体：供应商（Supplier）→ 属性：名称、税号、等级、状态关系：Supplier → provides → Product（一个供应商提供多种产品）规则：同一税号视为同一供应商；供应商状态为“冻结”时不能新增采购订单这份本体不是数据字典，而是业务逻辑的形式化表达。它让大模型和 Agent 在调用数据时，能“读懂”数据的业务含义，而不是仅仅匹配字符串。 本体层与大模型的协同：从“语料”到“语义” 当前 RAG 的局限在于：它只检索文本片段，不理解文本背后的业务结构。例如，一段文档写着“供应商等级分为 A、B、C 三级，A 级享有优先付款权”，RAG 能把它摘出来，但不会自动关联到“供应商”实体的“等级”属性上，更不会在执行“查询 A 级供应商”时自动应用这个规则。本体层+大模型的协同模式应是：本体作为结构化知识注入 Prompt：在 Agent 每次执行前，将相关领域的本体片段（实体定义、关系、规则）作为上下文注入，让 LLM 的推理锚定在业务事实上。本体引导大模型生成精确查询：当用户问“上月 A 级供应商的准时交货率”，系统先通过本体识别“A 级供应商”是 Supplier 实体上 status='active' 且 level='A' 的子集，再映射到对应的 MPP 查询。大模型辅助本体维护：LLM 可以从非结构化文档（会议纪要、邮件、政策文件）中提取新的业务规则，推荐给本体管理者审核采纳，形成持续演进的“业务知识飞轮”。这样，大模型不再是“黑盒猜谜”，而是在本体提供的“业务地图”上导航——准确率、可解释性、可信度都会大幅提升。企业数据建设最终交付的不是一个平台，而是一套“事实+事理”的有机体 1. 事实层：可信的数据资产事实就是经过治理的、可追溯的、确定性的数据记录。例如：“供应商 A 的统一社会信用代码是 91110000MA12345678。”“2025 年 6 月，SKU X 的销售额为 1,234,567 元。”“客户 B 的注册时间是 2024-03-15。”事实的质量取决于数据治理的水平——完整性、准确性、一致性、及时性。“供应商十套系统”问题，就是事实层没有做好。事实层是地基，地基不稳，上层建筑必然坍塌。2. 事理层：业务逻辑与规则事理是关于事实如何组织、如何关联、如何推导的规则和知识。它包括：实体关系：“供应商”与“采购订单”是一对多关系；“客户”与“合同”是一对多关系。业务规则：“VIP 客户的定义是累计消费超过 10 万元且近 3 个月有交易。”推导逻辑：“净利润 = 收入 - 成本 - 税费。”约束条件：“供应商状态为‘冻结’时，不能发起新的采购流程。”事理层就是本体——它描述了世界的运行规律。事理层是大脑，决定了如何解读和使用事实。3. 两者的关系：事实是肌肉，事理是神经没有事理，事实只是一堆散乱的数字；没有事实，事理只是空洞的逻辑游戏。只有两者结合，才能构成完整的“企业认知智能”。例如，当业务问“上个月 VIP 客户的流失情况如何？”：事理层先理解：“VIP 客户”的定义是什么？“流失”是指连续 N 天未登录还是合同到期未续约？事实层再提供：根据定义，从数据库中查出符合条件的客户名单及其最近活动记录。事理层再计算：将这些客户的状态与历史对比，得出流失率。整个过程，事理层负责“理解问题、拆解步骤、解释结果”，事实层负责“提供原材料”。 当前行业缺失的是什么？事实层：经过二十年的数据治理运动，大多数企业已经有一定基础，尽管参差不齐。事理层：几乎没有系统性建设。企业有业务规则（藏在制度文档、Excel、老员工的脑子里），但没有形式化、可机器执行的事理表示。这就是为什么大模型在企业里总是“一本正经地胡说八道”——它缺乏事理层的约束。未来的突破口就在事理层：如何低成本地将企业的业务规则、领域知识、逻辑约束提取出来，转化为机器可读、可推理的格式（例如知识图谱、规则引擎、甚至结构化的 Prompt 模板），并与大模型/Agent 深度集成。一个务实的推进路径对于传统企业，不需要一步到位建一个庞大的“企业本体”，可以从小处着手：1.选择一个高价值、规则清晰的业务域（例如供应商管理、客户分级、合同审批）。2.梳理该域的“事理”：画出实体关系图、列出核心业务规则、定义关键指标口径。3.将事理嵌入现有系统：可以是简单的规则配置文件、低代码决策表，也可以是轻量级知识图谱。4.用大模型验证：让业务/大模型基于这套事理回答问题，观察准确率和业务满意度。5.逐步扩展：从一个域到多个域，从简单规则到复杂推理。这样，企业就在不知不觉中构建起了自己的“事理层”，而无需等待一个宏大的“知识中台”项目。 结语企业数据建设的终极目标，不是建一个更快的平台，而是构建一套可信的事实层（数据治理的成果）和一套可机器执行的事理层（业务知识与规则的形式化表达），二者共同构成企业数字世界的心智模型。这才是数据使用价值的终极形态——不是更快地查数，而是让机器真正懂业务、能办事、会学习。
查看详情
企业数据建设二十年反思（中）：技术救不了的局
上一期回顾了大数据平台从Hadoop到MPP的曲折历程，这一期将目光转向一个更根本、也更棘手的问题：数据治理。大数据平台无论多么强大，其核心职责始终是“存、算、查”，而不是“辨、清、融”。 大数据平台 MPP/Snowflake 的职责是“存、算、查”，不是“辨、清、融” MPP 不负责实体对齐：它不知道“北京数语科技有限公司”和“Datablau”是不是同一家。MPP 不负责去重规则：它不会自动判断应该按“统一社会信用代码”合并，还是按“名称模糊匹配”合并。MPP 不负责数据溯源仲裁：当 A 系统说“供应商状态=正常”，B 系统说“供应商状态=冻结”，MPP 不知道该信谁。源端数据质量不解决，MPP 再强也是白搭。甚至可以说，MPP 的速度越快，反而让错误数据传播得越快、影响面越大——错误可能在晨会上直接被 CEO 看到并做出错误决策。数据治理解决了“能不能用”的问题，没有治理，数据的使用就是灾难 权限混乱：销售能看到薪酬数据，合规风险直接爆雷。口径不一：同一个“活跃用户”，市场部定义是“30天内登录”，运营部定义是“7天内下单”，报表打架，业务不信数据。质量低下：空值、重复、脏数据导致分析结果不可信，业务用两次就不用了。这些问题的解决，靠的是数据目录、血缘、质量监控、权限模型、指标标准化——这些全是数据治理的范畴。没有这些，哪怕用上 Snowflake，业务也不敢用、不能用。真正数据可信，需要的是：数据标准：强制所有源系统在接入 ODS 前，按照统一的编码规范、名称规范、地址规范进行转换。数据质量规则：在ODS 入口处设置校验规则（如“税号必填且符合格式”、“名称不能为空”），不符合的直接驳回或进入异常队列人工处理。数据血缘与溯源：当业务看到一个供应商信息时，能追溯到它来自哪个源系统、经过哪些清洗逻辑，知道“这个字段该信谁”。这些工作，没有一个 MPP 能替你完成。它们是组织流程、管理制度、甚至是跨部门政治博弈的结果，不是技术选型能解决的。现代数据平台的价值到底是什么？它是一个“放大器”：如果数据治理做得好（数据干净、口径统一、权限清晰），MPP 会让数据价值放大 10 倍——更多人、更快、更灵活地使用数据。如果数据治理做得差（比如十套供应商数据各说各话），MPP 会让混乱放大 10 倍——错误数据以前只在一个系统里局部传播，现在通过联邦查询和报表共享，全局扩散。它不是银弹，而是一面镜子。它能让人看清数据家底到底有多好或多烂——而且看得比以前快得多、清楚得多。关键始终是数据质量、数据可信。任何跳过数据治理去谈数据平台升级的行为，都是在沙滩上建城堡。现代数据平台的真正价值，或许就在于：它让这座城堡是建在沙滩上还是岩石上，变得一目了然，再也无法自欺欺人。数据治理平台过去十几年的发展历程第一阶段：2000-2010 年——奢侈品（手工+制度）典型特征：数据治理是“专家艺术”，高度依赖人工和流程。元数据管理：Word 文档 + Excel 表格，由 DBA 或数据架构师手动维护。业务口径变更后，文档更新滞后数月。数据质量：靠定时脚本跑检查，发现问题后发邮件给源系统负责人，人工确认、人工修复，周期以周计。主数据管理：企业主数据（客户、产品、供应商）由专门的MDM 团队或系统维护，通常是集中式、强管控，但上线周期长、变更僵化。血缘分析：人工维护不动，数据流向基本是个黑盒。本质：这个阶段的治理是“精英治理”——只有少数专家能看懂全貌，业务部门是被动接受者。治理是 IT 部门的“成本中心”，业务感知弱，推动靠行政命令。第二阶段：2010-2020 年——平民化尝试（工具+平台）典型特征：越来越多的业务部门配备BA人员，用数需求暴增，治理开始工具化和平台化。元数据管理：元数据采集开始自动化，但血缘解析仍依赖手动梳理，难以维护。数据质量：质量检查可以写成代码、集成到CI/CD 管道中，但规则编写和维护仍需要数据工程师。主数据管理：部分企业开始采用轻量级MDM，核心是数据认责。数据目录：开始出现企业级数据目录产品，试图让业务人员也能“搜索”数据。本质：这个阶段的治理开始“下沉”——工具降低了门槛，但核心工作（规则定义、冲突仲裁、标准制定）仍然依赖人。治理从“精英艺术”变成了“工匠手艺”：需要懂业务又懂技术的复合型人才，而这种人才极度稀缺。 第三阶段：2020 至今——智能化萌芽（AI+自动化）典型特征：LLM 和 AI 开始介入治理流程，试图解决“人力瓶颈”。元数据管理：LLM 可以自动补全元数据，生成技术定义；可以辅助识别“同名不同义”或“同义不同名”的字段，推荐合并建议。数据质量：AI 可以自动发现异常模式（如某个字段突然出现大量空值），而不需要预先编写规则；可以基于历史数据生成质量基线，自动告警偏离。数据目录：NL2SQL 和 RAG 技术让业务人员可以用自然语言提问，系统自动检索相关数据资产并给出解释。本质：这个阶段的目标是将治理从“工匠手艺”推向“自动化工厂”。AI 承担了“发现”和“建议”的角色，但“决策”和“仲裁”仍然需要人。最大的变化是：治理的瓶颈从“人力不足”变成了“AI 建议的可信度和可解释性”。总结一下，过去十年，数据技术（MPP/湖仓）提供了“加速度”，数据治理框架提供了“方向盘和刹车”。过去，国内企业往往只关注油门（买更快的引擎），忽略了方向盘和刹车的重要性。数据治理的推广，正是在补上这一课——让企业意识到：数据建设的终点不是“更快地查到数据”，而是“更可信地用好数据”。数据治理的本质没有变——它始终是在解决“人”的问题（权责、流程、标准），而不是“技术”的问题。技术只是让这个过程变得更高效、更透明、更可量化，但它无法替代“业务部门愿意为自己的数据质量负责”这个组织前提。所以，当看到一家企业上了最先进的 MPP 平台、用了最酷的 AI 治理工具，但供应商信息仍然是“十套数据十个样”时，问题大概率不在技术，而在没有人真正为“供应商数据”的准确性负责。这才是数据治理二十年未解的“本质性困境”。
查看详情
企业数据建设二十年反思（上）
自2006年Apache Hadoop第一个版本发布已经过去了20年。大数据、数据中台这些曾经炙手可热的词汇，如今已经越来越少人提起。过去十年，不少传统企业在数据架构上经历了一次代价高昂的“绕路”。 当年，互联网大厂拥抱 Hadoop 生态的动机很朴素：便宜、能存、能算。Teradata 太贵，Oracle 撑不住 PB 级，HDFS+Hive 几乎零成本起步。于是互联网大厂率先把核心系统数据库迁到了 Hadoop 上。但很快发现了几个残酷现实：运维成本爆炸：Hadoop 生态组件太多，一个集群出问题要排查 HDFS、YARN、Hive、Spark、Zookeeper……小团队根本扛不住。SQL 体验倒退：Hive 的 SQL 支持残缺，性能不稳定，一个简单的 JOIN 可能跑半小时。实时性为零：MapReduce 天生批处理，想做实时报表还得引入 Storm/Kafka/Flink，复杂度再次飙升。很多传统企业认为互联网大厂先进，将核心报表、ETL 甚至部分交易分析迁到了 Hadoop 上。折腾三五年后，发现花了不比 Teradata 少的钱（人力+硬件），得到了更差的体验。这时候看到 Doris、ClickHouse 这类 MPP 产品，自然会觉得：“这不就是当年 Teradata 那套吗？绕了一大圈又回来了。”欧美同样走了 Hadoop 弯路，而且踩得更早。Hadoop 本来就是欧美的产物：Google 的 GFS/MapReduce 论文（2003）→ Yahoo 养出 Hadoop 项目（2006）→ Facebook 搞出 Hive（2008）→ Cloudera/Hortonworks 两家上市（2010s 初）。欧美企业（零售、保险、银行、制药）当年砸的钱不比中国少：某大型零售企业数千万美元建 Hadoop 集群，三年后只用来跑月度销售报表，实时库存、个性化推荐因数据质量和链路问题落不了地。一家保险 PBM 公司 2700 万会员的 Teradata 还没来得及换，中间也被忽悠上了 Hadoop 做“数据湖”，后来才直奔 Snowflake。Cloudera 2019 年停更 CDH 逼用户迁 CDP 被骂“割韭菜”，2021 年被 PE 收购私有化退市——这标志着 Hadoop 商业化全球崩盘，并非中国独有的问题。所以，“以为 Hadoop 能替代 EDW，结果发现运维炸、SQL 慢、业务用不起来”这个坑，欧美企业先踩的。但中国的“弯度”确实更大，原因有三 ：同样是踩 Hadoop，欧美退出来的比中国快，路径差异如下：关键差异：欧美从 Hadoop 退下来时，Snowflake 已经在那里等着了——纯 SaaS、零管理、按秒计费，企业直接“弃 Teradata + 弃 Hadoop”一步到位。中国当时（2018-2021）公有云在传统行业推不动（合规、数据主权、预算模式），所以退不回云，只能退到“另一个开源 MPP”继续私有化跑。但是，Cloudera/Hortonworks 国内中台化继承者们把 Hadoop 动物园（HDFS/Hive/Spark/YARN/ZK）包成一个“数据中台产品”卖给传统企业，再加一套“全域数据资产、标签画像、数据服务 API”的叙事。实际走的是欧美已经弃用的路径。互联网大厂的角色：放大器，不是起源 Hadoop 热本身不是中国大厂掀起的——Google/Yahoo/Facebook 才是源头，Cloudera/Hortonworks 才是商业化推手，欧美银行业/零售业才是第一批买单的。但中国互联网大厂确实放大了“弯路感”：阿里 2016 年前后推“数据中台”概念，把 Hadoop 生态（HDFS/Hive/Spark）+ 调度 + 治理打包成一个“你必须有的中台”，影响了大量传统企业 IT 选型。互联网大厂又推了自家开源（Doris、ClickHouse 国内推广、Pulsar 等），让传统企业觉得“互联网大厂都这么干，我也得这么干”。更大的放大器是人才流动：Hadoop/Spark committer 中国人比例很高，大厂出来的人去传统行业做 CTO，自然把那套栈带过去——这套叙事在欧美也有（FB/Google/LinkedIn 的人出来搞了 Confluent、Cloudera、Databricks），但欧美传统企业 IT 更敢直接买 Snowflake SaaS，不肯养 Hadoop 团队，所以放大效应没中国强。中国多叠了一层“互联网中台叙事”的坑。阿里的中台叙事 + 传统企业 IT 对互联网大厂的模仿心理 + 公有云渗透率低，三者叠加。Snowflake 是从 EDW 侧“降维替代”，Databricks 是从数据湖侧“升级重生”Snowflake 成立（2012）公测（2014）那年，业界所有人都在搞“Hadoop 上加 SQL”（Hive/Impala/Presto），Cloudera 喊的是“Replace EDW with Hadoop”。Snowflake 创始人（原 Oracle 团队）偏偏选了反向：不碰 Hadoop 栈，直接给云做一个 Shared-Data 的“新式数仓”。所以，Snowflake 接的不只是 Hadoop 逃兵，更多是 Teradata/Oracle 老用户想“云化降级”。Snowflake 的杀手锏是“简单到不需要 DBA”——某零售企业 Hadoop 集群养 6 个工程师，Snowflake 那边 1 个数据工程师 + SQL 就能跑。这对欧美传统企业（银行/零售/保险）杀伤力极大，因为他们本来就被 Teradata 贵怕了，又被 Hadoop 复杂怕了，Snowflake 一出现就是“两边都不用受”。Snowflake 和 Databricks 都不是来“继承 Hadoop”的，而是来“给被 Hadoop 搞烦的人另一条路”的：Snowflake 接的是“我想换掉 Teradata，但又不想跳进 Hadoop 坑”的那批（EDW → 云数仓）。Databricks 接的是“我已经在 Hadoop/Spark 上了，但 YARN/ZooKeeper 快把我逼疯”的那批（数据湖 → Lakehouse）。中国用户把欧美降成本的解决方案理解成了“更先进”。中国用户本质上是被“先进”驱动的，而不是成本效率驱动的。另一边，欧美继续降成本的解决方案就是云数仓。两条路都要求企业愿意把数据栈交给云 SaaS。中国传统企业这一步迈不出去，所以“接住”这事在中国没发生，变成了 MPP 这种“开源+私服”的折中方案——技术上是回归 MPP，商业上是无奈。现状就是国内企业想“假装自己在用 Snowflake”，私服里凑一套类 Lakehouse。国内传统企业这一波湖仓一体，本质是用开源组件（MPP + Iceberg/Paimon + 对象存储）拼出一个“看起来像 Snowflake”的架构，但 Snowflake 真正值钱的那几样东西（Serverless 自动优化、零运维、统一治理）其实没接住。总结一下，过去十年，企业数据建设的真正进步，不是发明了新类型的数据库，而是转了一大圈把 OLAP 的成本降到了原来的十分之一。当前欧美传统企业（银行、保险、零售、制造）他们把 Teradata 时代设计好的 EDW 模型（总线矩阵、一致性维度、星型/雪花型 schema）整体迁移到 Snowflake/BigQuery 上，存储从专用硬件换成了对象存储（S3/GCS），计算从专用 MPP 换成了云原生虚拟仓库，运维从原厂保姆变成了 SaaS 零管理。核心收益就是“省成本、省运维”，业务抽象层几乎原封不动。
查看详情
Gartner：2026年数据与分析顶级趋势
Gartner发布的2026年数据与分析顶级趋势报告显示，AI智能体、语义层进步以及数据与分析平台的融合，将成为引领未来发展的三大核心趋势。对于希望识别关键业务和技术主题的数据与分析（D&A）领导者而言，这些领域是实现高性价比价值、更快成为AI FIRST企业的关键。 概览机遇与挑战AI FIRST企业能够通过战略性方法最大化AI在D&A中的收益，从而超越同行，取得更好的业务成果。阻碍这一愿景规模化落地的因素包括：组织内部碎片化、复杂的IT系统、互不关联的数据孤岛泛滥，以及分析技术。智能体驱动的数据与分析利用AI智能体加速实时数据的操作闭环，带来更敏捷的运营、精简的数据管理、更高质量的决策和更快的业务价值。但D&A领导者必须克服风险，通过实施决策治理来确保在使用生成式AI（GenAI）并扩展AI工程实践时，获得透明且合乎伦理的结果。将语义置于核心可提升AI的理解力。复合语义层和图检索增强生成（GraphRAG）等策略为改善AI智能体的响应质量、一致性和可靠性提供了必要的上下文。上下文工程是一项新兴实践。挑战在于许多组织面临架构碎片化、数据分散在互不通信的系统之间，这阻碍了AI智能体充分发挥潜力。D&A平台化用融合的数据管理和AI治理平台取代零散的单用途解决方案，通过一致的策略部署建立信任。以往的技术整合涉及繁琐的迁移，给本地化控制带来了额外挑战。这些因素进一步增加了对灵活且合理化的平台工程的需求，以简化D&A运营。 您需要了解的内容AI FIRST企业通过将智能体、语义和平台融入其D&A战略而胜过竞争对手。成功的组织将利用统一平台，通过AI FIRST举措推动业务成功。· 智能体驱动的数据与分析通过将AI智能体与实时数据流集成到运营中，加速数据到影响的闭环。这使得工作流程更加敏捷、自动化，但需要强有力的决策治理来降低GenAI风险并确保安全结果。· 语义核心化对AI的准确性和可靠性至关重要，通过复合语义层和GraphRAG提供上下文含义，消除碎片化架构。采用这些策略的组织可提高AI智能体响应的准确性。· 统一的D&A平台可以将数据管理、分析、治理和智能体能力整合到一个更简单的融合环境中，从而创造所需的清晰度以建立信任。这种整合减少了复杂性和冗余，使组织在应对各国日益涌现的往往相互冲突的主权AI战略时，具备所需的灵活性以实现AI FIRST。 战略规划假设· 到2030年，超过十分之一的企业将成为AI FIRST企业，通过采用智能体、语义和融合的D&A平台超越竞争对手。· 到2029年，20%的D&A领导者将拥抱智能体驱动的数据与分析，由AI智能体自动完成数据管理和数据流处理，以及用于安全的决策治理。· 到2028年，采用复合语义策略结合GraphRAG以降低推理成本的组织，将使其智能体AI的响应能力和可靠性提升50%。· 到2030年，超过50%的企业将利用一个融合数据、分析、治理和智能体功能的单一平台，推进其AI FIRST战略。 专家洞察AI FIRST企业由D&A平台、智能体和语义核心化赋能根据Gartner 2026年首席数据和分析官议程调查¹，越来越多的D&A领导者现在是“以AI为中心”而非“以技术为导向”。要获得一项明确利用AI的战略承诺，利用这种自我改进和自适应的技术做出更好的决策、采取行动并大规模创造新型价值。成本压力不会阻止AI，但在语义和工具孤岛上偷工减料会阻止AI价值的实现。您应从这些顶级趋势中获得的关键教训是：在2026年，在迈向AI FIRST企业的过程中，需要聚焦于这些主题。立即选择您的首要趋势，并使用演示材料、图表、预测、证据点、真实案例、建议和事实依据来展示远见和思想领导力。 行动概述“AI FIRST”是一种指导企业及其部门最大化AI收益的战略方法。AI FIRST企业是指整个组织承诺采用AI FIRST战略的企业，即在核心决策和投资中始终将AI与其他选项一并考虑，并在最合理的时候使用AI，以此最大化AI的收益。本研究的执行层面洞见是：2026年的D&A趋势由三大主题驱动： 智能体驱动的数据与分析、语义核心化和D&A平台化，如图1所示。 图1. 2026年数据与分析顶级趋势 智能体、语义和平台塑造了2026年AI FIRST企业的趋势，包括智能体驱动的数据管理、复合语义层和AI治理平台。这些主题的结合推动了上下文感知分析和稳健数据管理的进步。关于AI FIRST企业的更多详情，请参阅《AI FIRST解读：含义、重要性及行动时机》和《IT 2030：用AI重塑IT以实现长期成功》。 研究亮点智能化D&A来自：Ramke Ramakrishnan智能体驱动的数据与分析是一种AI FIRST的战略和运营模式，它推进AI智能体在D&A运营中的有效部署，并为其性能建立信任基础。企业采用智能体驱动的数据与分析，以便组织资源和AI无缝协作，适应并优化数据驱动的决策和结果。智能体驱动的数据与分析是构建真正AI FIRST企业的基础。通过部署AI智能体来管理完整的数据到行动的闭环（通过智能体数据管理），利用智能体数据流实现实时数据流动，并强制执行稳健的决策治理，组织可以实现灵活性、可扩展性和信任。智能体驱动的数据与分析涉及受治理的数据和分析端到端自动化。它将D&A的功能演变为对AI智能体比对人类更有用。它优先考虑机器消费，即AI赋能的非人类参与者访问服务并代表人类团队、客户或组织行事。参见《AI智能体采纳如何改变数据与分析战略和运营》。智能体驱动的数据与分析是优化数据到执行闭环的下一个浪潮。通过在资源稀缺的地方集成AI智能体，组织通过敏捷的D&A运营最大化业务价值。 智能化D&A赋能AI FIRST企业智能体驱动的数据与分析通过使用AI智能体驱动智能体数据管理和智能体数据流，并辅以稳健的决策治理，为AI FIRST企业奠定基础。将AI智能体集成到数据管理工作流程中，可以对整个数据生命周期进行自主和自适应监督。它还通过智能体数据流促进实时数据流动和响应能力，确保高速、近乎实时的数据无缝到达下游分析和AI系统。此外，由于应用了决策治理，每项决策仍然可解释、可问责、透明且合规。证据点：· 根据2025年Gartner软件工程AI调查²，对AI智能体的评估主要通过三个指标：任务执行质量、用户反馈和整体用户体验。· 根据2024年Gartner探索数据、分析与软件开发交集调查³，使用共享数据服务构建AI智能体的组织比不使用共享服务的组织使用了更多样化的技术组合，包括事件流（41%）和事件流处理（25%）。· 随着AI智能体承担更多的决策自动化，人类监督的必要性显而易见。基于2024年Gartner决策智能调查⁴，76%的IT和商业领袖已将决策监控和治理评为对其组织决策智能“始终重要”，这凸显了这一趋势是安全和可扩展的智能体驱动的数据与分析运营的必要保障。真实案例：· 智能体数据管理可自动化和强化关键功能，包括资源缩放、实时错误修正、元数据管理、数据隐私、工作流调整以及跨银行业与金融服务、医疗保健和制造业等。· 智能体数据流广泛应用于欺诈检测与风险管理、决策智能、数字孪生以及自动化工厂和物流。· 组织依赖决策治理来提高透明度，确保每个数据驱动决策的可问责性，并通过明确的所有权、血缘追踪和质量评分优先考虑高价值、低风险的AI项目⁵。新兴实践：AI工程AI工程是一门设计、开发、交付、运营和管理使用、部署和应用AI以提供商业价值的技术系统的学科。该学科统一了DataOps、MLOps、ModelOps和DevOps流水线，为基于AI的系统创建了一个连贯的开发、部署（混合、多云、边缘）和运营框架。这一新兴实践放大了智能体驱动的数据与分析与D&A平台化主题交汇的趋势。建议：· 通过智能体驱动的数据与分析进行创新，以实现长期愿景：通过智能体数据管理简化数据运营，通过智能体数据流加速实时洞察，通过决策治理降低GenAI风险。· 将AI智能体集成到现有的数据管理工作流程中，赋能数据管理团队变得自适应、自我学习，并提供可操作的建议。· 从业务驱动的延迟评估开始，明确需求。如果准实时数据则使用“微批处理”。将智能体数据流保留给真正需要毫秒级响应能力的场景，如欺诈预防或数字孪生。· 采用决策治理，创建决策的记录系统。确保AI增强的选择透明、可追溯且可问责。通过为AI智能体提供所需的受治理逻辑和护栏，在向智能体驱动的数据与分析迈进的过程中加强决策质量并降低GenAI风险。用智能体数据管理简化运营智能体数据管理指的是自适应、自学习的系统，利用AI驱动的自动化来优化和简化整个数据到影响闭环，这需要安全保障、控制和信任。它使组织能够加速关键数据管理流程，让数据运营团队专注于战略重点并推动更好的业务成果，使其成为当今数据管理的首要趋势。 语义核心化来自：Christopher Long语义核心化是一项战略原则，要求数据的上下文含义成为D&A运营模式的基石，确保跨平台建立标准化的语义定义和业务逻辑。这一基础确保了人类和AI智能体分析消费的成功。语义核心化通过建立标准化、上下文化的根基来连接碎片化的分析孤岛，从而赋能AI FIRST企业。这为AI智能体规模化并驱动最佳业务成果创造了可靠的结构。D&A领导者必须通过战略性地重新构想语义层为多层复合架构，并利用GraphRAG进一步对数据进行上下文化，来优化AI ready的D&A架构。语义核心化必须作为现代D&A运营模式的战略要务加以采纳，将语义从事后考虑转变为构建健壮、可互操作、可靠且可扩展的AI系统的关键基础。语义核心化赋能AI FIRST企业语义核心化通过将数据的上下文含义确立为D&A运营模式的核心要素，保证业务逻辑和标准化定义在所有平台上保持一致，从而赋能AI FIRST企业。这一原则是AI READY分析的战略优先级，因为可靠、可扩展的AI系统——特别是智能体AI和大语言模型（LLM）驱动的应用程序——需要经过治理和认证的上下文才能可靠且一致地工作。通过优先建立这一语义基础，组织为AI智能体提供了必要的根基，很可能大幅提升智能体AI的准确性和价值。此外，“语义核心化”原则旨在对抗目前阻碍AI FIRST企业能力部署的普遍语义碎片化和分析孤岛。通过规定指标一次定义、处处一致使用，语义核心化推动了复合语义层和语义互操作性标准等AI READY架构方案的采用。这使得AI智能体能够以编程方式跨分布式环境访问可移植、可信赖的指标，将碎片化数据转化为统一的、可信赖的数据，从而驱动可编程的AI FIRST企业。证据点：· 许多组织在多个平台上重复分析工作，通常是由于集成不足和缺乏分析交付规划。他们在指标层上也难以实现一致性。在这些碎片化的D&A架构中，企业无法充分利用AI智能体。根据2025年Gartner AI READY数据状态调查⁶，采用语义建模实践的组织更有可能在用于支持AI用例的数据工程实践中实现高效。· 企业AI应用要求高水平的准确性和可靠性。根据2023年data.world团队的生成式AI基准测试⁷，标准的检索增强生成（RAG）方法往往难以达到要求。这表明有必要探索GraphRAG等新兴趋势，因为它克服了标准RAG的这些局限性。真实案例：· 丰田汽车欧洲公司的“盒中自由”框架跨领域联合了语义开发和所有权，展示了实用的复合语义层。“盒中自由”计划允许业务领域独立创建自己的特定数据产品和分析模型（“自由”），而不是强制推行单一的通用标准。通过将这些分布式工件包裹在严格的治理和认证协议（“盒子”）中，丰田有效地协调了这些多样的语义对象，促进了整个架构的一致性和凝聚力⁸。· Microchip Technology的客服团队因无法直接访问订单或生产数据而面临延误，只能依赖工程和运营团队。为解决这一问题，他们构建了一个基于GraphRAG的聊天机器人和私有LLM，通过检索结构化的实时运营洞察来回答特定领域的问题，克服了传统RAG的局限。客服人员获得了对复杂数据的即时访问，而技术团队则从常规查询中解放出来⁹。 新兴实践：上下文工程上下文工程是一门在设计、管理和优化推理时提供给GenAI模型的信息的学科，以提高性能、准确性、相关性并优化成本。它代表了在AI应用程序工作流的每一步精确地用足够的相关信息填充LLM上下文窗口的艺术和科学。这一新兴实践放大了智能体驱动的数据与分析与语义核心化主题交汇的趋势。建议：· 以语义核心化为基础建立AI FIRST企业：采用可互操作的复合语义层，统一所有环境中的业务逻辑。利用GraphRAG处理更复杂的用例，将模型扎根于本体论上下文中，从而最小化AI偏见和幻觉。· 认识到实施复合语义层是一个复杂的集成和工程挑战，而非即插即用的解决方案。这不是一种免干预的集成；需要积极审计逻辑当前所在的位置——无论是在数据管理平台、语义层、SQL、代码还是分析和商业智能平台中。· 从内部数据的最小知识图谱开始，然后扩展并对比标准RAG对GraphRAG进行基准测试，以获得可衡量的增益和改进。使复合语义层可互操作复合语义层协调D&A架构中多样化的语义对象——如数据产品、知识图谱和BI模型。由于“单一通用层”往往难以定义，这种模式至关重要。它通过战略性地对齐工件来提高可重用性并减少重复。这种方法弥合了上下文差距，减少了数据孤岛，并在整个组织中强制执行一致的业务逻辑。D&A平台化来自：Robert ThanarajD&A平台化是一个技术合理化过程，用融合平台取代互不关联的单用途数据和分析工具，以简化架构、标准化运营，并减少跨团队和系统的技术交接。D&A平台化是迈向构建AI FIRST企业的战略步骤。它统一了碎片化的系统和技术，以获得持续优势。D&A领导者可以通过用融合平台取代零散的单用途工具，来精简架构并标准化交付流程。融合的数据、分析和AI平台简化了传统上拖慢D&A团队的复杂运营，使他们更容易更快地实现AI FIRST。D&A平台化赋能AI FIRST企业成为AI FIRST企业对于领先并赢得竞争至关重要。但由于互不关联技术的泛滥、组织碎片化和过于复杂的系统，大规模实现这一愿景充满挑战。为此，许多D&A供应商正在拓宽其产品组合，导致数据、分析、决策、治理和AI能力的大规模融合。融合平台消除了孤岛，简化了AI READY的D&A架构，并为组织提供了在全公司范围内扩展AI能力所需的集成基础。这一趋势意味着大多数企业将采用融合平台作为其智能体驱动的数据与分析战略和运营模式的关键组成部分。其中一些融合平台在以下Gartner研究中详述：· 《数据管理平台市场指南》· 《AI治理平台市场指南》· 《决策智能平台魔力象限》通过用统一平台取代零散的单用途工具，将关键能力和标准化流程整合在一起，D&A领导者可以精简架构，减少跨团队和系统的不必要技术交接。例如，一个团队可能用一种技术构建数据管道，另一个团队用不同的系统管理数据质量，还有一个团队用第三种工具创建分析报告。使用多个重叠的工具效率低下，而融合平台则帮助企业更快地实现AI FIRST。参见《预测2026：智能体数据管理对智能体AI成功不可或缺》。证据点：· 根据2024-2025年间Gartner客户互动中的证据，组织平均部署了十多种数据管理解决方案，却难以大规模实现AI目标。· 一半的首席数据和分析官认为优化技术格局是其首要职责¹。· 使用AI治理平台的组织在AI治理实践中实现高成效的可能性是不使用平台的三倍以上⁶。· 根据2025年Gartner云最终用户购买行为调查¹⁰，60%的受访组织预计会增加对区域解决方案的依赖。真实案例：· BDO¹¹、丰田⁸和WPP¹²等组织使用数据管理平台，通过市场将数据作为产品提供，通过自然语言查询简化数据访问，应用治理以确保质量和投资回报率，并支持RAG服务、GenAI应用和LLM集成。· AI治理平台用于缓解影子AI风险、强制执行运行时护栏，并确保针对全球AI法规（如欧盟AI法案、AI风险框架和NIST AI风险管理框架）的审计准备。· 各国正通过关税和贸易政策、对私营实体的投资、政府资金、针对性的监管/放松管制、行业倡议以及公私交易来加速主权AI。新兴实践：平台工程面向D&A的平台工程是一门设计、构建和扩展自助服务平台，为在整个组织中采用D&A实践提供有主见的、安全且治理良好的方式的学科。它旨在改善D&A开发者体验、加速D&A交付、最大化投资回报率并支持负责任的AI生命周期。这一新兴实践建立在围绕平台化和语义的关键趋势之上。更多信息请参见《实现平台工程成功的五项原则》。建议：· 平衡D&A平台化的压力：通过数据管理平台整合解决方案，通过AI治理平台建立信任，同时将D&A控制权交给最需要的团队。随着主权AI的不断出现，它可能根据具体的AI用例推动组织走向更多平台化或进一步分化。· 通过使用数据管理平台审查和合理化当前数据管理技术格局，消除冗余、未充分利用的技术。停止引入更多的数据管理点解决方案。· 优先采用AI治理平台以提高AI治理的有效性。严格评估供应商平台的能力，以选择满足当前和可预见AI治理需求的平台。· 通过现代化D&A路线规划和D&A平台化来应对主权AI带来的商业机会和未公开的威胁。这也将加速AI FIRST企业的举措，将AI用例从单纯利用推进到创造决定性优势。
查看详情
开放语义模型：构建企业级数据语义层
近年以来，大模型、智能问答、智能体等AI应用快速发展，很多企业都在积极探索如何将AI能力融入业务场景。那么，在AI时代，数据治理和数据仓库如何顺应时代发展呢？过去二十年，企业围绕数据建设逐步形成了一套成熟的方法体系，形成了数据仓库（中台），通过BI和报表进行业务赋能。然而，在智能化时代，这些是远远不够的，现在的数据治理体系并不足以让AI真正理解企业业务。换句话说，不能被AI通过消耗Token方式消费的数据平台，是没有未来的。从管理数据到管理知识：企业语义探索之路企业在过去很多年里一直在探索如何让数据承载更多业务知识。最早，人们通过数据资产目录、元数据管理等方式，对数据进行分类、标注和管理，希望让数据更容易被发现和理解。近年来，随着大模型和生成式AI的发展，RAG（Retrieval-Augmented Generation）知识库成为热门方向。很多企业尝试将制度文档、业务手册、指标说明等内容导入知识库，希望AI能够通过检索增强的方式回答业务问题。与此同时，本体模型（Ontology）也受到越来越多关注，数语科技也推出了DOM本体系统，它通过定义概念、关系和规则，构建企业知识网络，为知识推理和智能分析提供基础。这些探索虽然路径不同，也各有优缺点，但本质上都在解决同一个问题：如何让企业知识能够被机器理解和使用。本文介绍另一种受到广泛关注的知识管理的方法，就是（逻辑）语义模型。什么是语义模型？语义模型（Semantic Model）并不是一个新概念，但是在AI时代变得更加重要。早在数据仓库和商业智能（BI）发展的过程中，人们就开始尝试在底层数据结构与业务应用之间建立一层统一的业务语义，用来解决不同系统、不同报表之间口径不一致、理解不一致的问题。随着企业数据规模不断扩大，以及云计算、数据中台和AI技术的发展，语义模型的价值被重新认识。近年来，国际上出现了OSI（Open Semantic Interchange）等开放语义理念，希望建立跨平台、跨系统共享的统一语义标准，让语义能够像数据一样被交换、共享和复用。从内容上看，语义模型主要用于统一描述企业的业务知识，包括业务实体、业务术语、指标口径、业务规则以及实体之间的关系等内容，并将这些定义沉淀为统一的语义资产。语义模型（Open Santic Model）开放语义模型（Open Semantic Model），简称OSM，是数语科技制定的企业级语义模型标准，并由其数据建模工具DDM提供设计、管理和落地支持。OSM借鉴了近年来国际上开放语义领域的发展成果，同时结合数语在数据模型和本体模型的数十年的积累，希望建立一种开放的本体化、标准化的语义描述方式，使企业能够将数据模型升级到业务语义模型，实现跨平台共享、跨系统复用以及面向AI的统一消费。本体化语义模型主要包含以下内容：指标与度量（Metrics）：定义业务指标及其计算逻辑，以及与业务实体之间的关系。业务实体（Business Entities）：定义业务口径中的实体。如客户、产品、订单、合同、设备、组织等核心业务实体。属性（Attributes）：描述业务对象的关键属性及业务含义。关系（Relationships）：定义对象之间的业务关系，如隶属、拥有、参与、依赖、影响等。映射（Mapping）：定义业务实体与物理表（或视图）之间的映射关系，用来做数据查询引擎。业务规则（Business Rules）：沉淀企业运营规则、约束条件和业务逻辑。在规范方面，本体化语义模型通常遵循国际知识表示与语义建模标准，包括：OSI（Open Semantic Intercharge, yaml) : 开放语义交互协议的yaml格式。RDF（Resource Description Framework）：资源描述框架，用于统一表达实体及其关系。OWL（Web Ontology Language）：用于构建企业本体模型和复杂业务规则。 《DDM中的语义模型》数语基于OSM，还提供通用数据查询系统，将企业统一语义层与自然语言交互能力深度融合，实现统一问数与数据探索分析。当前市场上不少方案采用Text2SQL、Text2DSL再转换为SQL等技术路线，虽然能够实现自然语言到查询语句的转换，但往往缺乏统一、完整的企业语义模型支撑，对业务概念、指标口径、规则关系和跨系统数据关联的理解能力有限，容易出现语义歧义、查询结果不一致以及复杂业务场景适配困难等问题。实践证明，无论采用哪个toSQL的路线，最后的瓶颈都是语义上下文的缺失。因此通过OSM实现的问数从准确率到开放性能力都要上一个台阶。《基于语义模型的数据查询系统》如何从数据模型走向语义模型对于很多国内企业来说，数据模型建设并不陌生。过去十多年，企业围绕数据资产建设，逐步形成了从业务系统到数据仓库、从数据标准到指标体系的完整方法论。尤其是在数据治理领域，很多企业已经建立了较为成熟的五级数据架构体系，通过概念模型、逻辑模型、物理模型以及数据标准等方式，实现了数据资产的规范化管理。这些建设成果并不会因为AI时代的到来而失去价值，企业过去积累的数据模型和治理成果，正在成为构建智能化能力最重要的基础。对于DDM而言，我们认为企业级语义模型建设可以分阶段推进。第一步，基于现有数据模型、数据标准和指标体系，建立统一的业务术语和语义定义；第二步，将业务实体、指标口径、业务规则等内容纳入统一管理，形成企业级语义资产库；第三步，通过开放标准实现语义共享与复用，支撑跨系统、跨平台的数据协同；第四步，将语义模型与AI应用结合，为智能问答、智能分析、智能体等场景提供统一知识底座；最终，逐步构建覆盖数据、语义和知识的企业级智能数据架构。从数据模型走向语义模型，并不是一次技术替换，而是一次数据资产价值的延伸。将过去建设的数据底座，升级为企业需要建设的知识底座。写在最后AI不会取代数据治理，也不会取代数据仓库。但AI的出现，正在重新定义它们的价值。从数据到语义，从资产到知识，这不仅是技术架构的演进方向，也是数据治理和数据仓库在AI时代最重要的发展方向。
查看详情
2026年数据安全“第一课”，分类分级如何从“合规必答题”变为“发展必选项”？
2026年，金融信息服务领域迎来数据安全治理的关键节点。随着国家互联网信息办公室《金融信息服务数据分类分级指南（征求意见稿）》（下称《指南》）的发布，“核心数据、重要数据、敏感一般数据、常规一般数据” 的四级框架正式确立。这标志着，金融行业数据安全，已从过去笼统的“数据盘点”，迈入精细化分类、精准化定级、动态化报送的新阶段。作为国内领先的数据治理专业服务商，数语科技基于对《指南》的深度研读与行业实践，为您梳理合规落地的核心逻辑与实施路径。一、 监管风向标：2026年分类分级呈现“精细化”与“强制化”双特征四级分层，颗粒度更细： 新规明确将数据从高到低划分为核心数据、重要数据、敏感一般数据、常规一般数据四个级别。企业不能再笼统地谈“重要”与“一般”，必须建立精细化的四级标签体系。三级分类，覆盖度更全： 在分类维度上，指南提出了“业务数据、用户数据、企业数据”的一级分类框架，并细化出多达66个三级分类。这意味着，企业的每一张表、每一个字段都需要找到准确的“户口”。处罚力度空前： 监管层明确将按照“发现一批、整改一批、通报一批、处罚一批”的思路推进工作。未按要求开展识别备案、未落实差异化保护的，将面临严肃处理。监管的“颗粒度”越细，对企业的数据资产盘点能力要求就越高，自动化、智能化的分类分级工具成为刚需。二、 痛点直击：为什么你的分类分级总是“交不了差”？《指南》给出了标准，但企业从“看懂”到“做到”仍有距离。结合数语科技的服务经验，挑战主要集中在以下方面：挑战1：分级要素复杂，人工判断极易出错《指南》第5.2条明确，分级需综合考虑覆盖度、时间跨度、精度、公开状态、地域五大要素。例如，“10年的基金成交量数据”与“1日的实时行情数据”级别可能截然不同。人工识别不仅效率低，且标准难以统一。挑战2：影响对象多维，量化评估困难数据安全风险可能影响国家安全、经济运行、社会秩序、公共利益、组织权益、个人权益六大对象。如何将“特别严重危害”“严重危害”“一般危害”三个等级，转化为可执行的字段级判断逻辑？这是许多企业面临的共性难题。挑战3：动态更新要求高，静态台账难以为继《指南》第5.6条明确要求，数据分级完成后应定期检查复核，并在内容、规模、场景、融合方式等发生变化时及时更新。特别是当核心数据、重要数据条目数量或存储总量变化超过30% 时，需重新报送。这意味着，一次性的分类分级远远不够，持续动态管理才是关键。三、 数语科技智能化解决方案：全生命周期数据安全治理针对上述挑战，数语科技基于AI大模型技术与行业规则引擎，推出的Datablau智能化数据安全管理平台，可对标《指南》要求，覆盖“数据资产盘点—分类—分级—清单报送—动态更新”全流程。智能数据资产盘点：构建数据资产目录，自动发现敏感数据，精准摸清资产家底统一数据资产目录：所有盘点结果形成企业级数据资产目录，提供一站式的数据资产全景视图。数据管理者可清晰查看全域数据资产的分布状况、分类分级状态及敏感数据访问热度；数据使用者则可通过目录快速检索所需数据，直观了解数据的安全级别与使用限制，实现“找得到、看得懂、用得了”。智能数据识别：依托智能数据识别技术，综合运用关键词匹配、同义词扩展、正则表达式等多种识别方式，自动完成全域敏感数据的扫描与发现，精准定位个人信息、金融交易、商业秘密等敏感字段，为后续分类分级提供高质量的数据基础。持续动态盘点：支持周期性自动盘点与触发式增量盘点双模式。当新增数据源、新增数据表或既有数据内容发生变更时，系统能够自动触发增量盘点，实时更新敏感数据清单，确保数据资产“家底”始终与真实环境保持一致，为动态合规与精准防护提供可靠依据。对应《指南》要求：第6.a条“数据资源梳理”——形成包含数据库表、数据项智能数据资产分类分级：让分级“自动、精准、可解释”平台内置金融信息服务行业分类分级规则库，严格对标《指南》附录A的66类三级分类与第5条的四级分级体系，实现自动化分类分级。自动分类归目：根据数据所描述的对象、业务领域、数据主体，自动将数据归入业务数据/用户数据/企业数据的一级分类，并逐级细化至三级分类。智能定级评估：综合分析数据的覆盖度、时间跨度、精度、公开状态、地域等分级要素，结合对国家安全、经济运行、社会秩序等六大影响对象的潜在危害程度，按照“就高从严”原则自动输出核心数据、重要数据、敏感一般数据、常规一般数据四级结果。动态更新管理：依托数据血缘追踪与变更感知能力，平台可定期自动复核数据资源与分类分级结果。当数据内容、规模、使用场景或融合方式发生变化时，分级结果将同步更新，确保企业的数据安全治理始终与监管要求同频。敏感数据分区与脱敏策略关联：完成分级后，平台自动将不同级别的数据映射至相应的存储分区与脱敏策略，实现“分级即管控”。对应《指南》要求：第6.b条“数据分类”、第6.c条“数据分级”、第6.d条“形成数据分类分级清单”。动态脱敏：场景自适应，安全不牺牲效率平台通过数据安全网关构建动态脱敏引擎，在不改变底层数据存储的前提下，根据访问场景实时进行脱敏处理，实现安全与效能的平衡。场景感知脱敏：识别数据查询、数据服务调用、报表导出、API接口等不同访问场景，自动匹配相应的脱敏规则。例如，运维人员查看日志时显示脱敏后的手机号，而业务分析人员在授权后可查看完整信息。多种脱敏算法：支持遮盖、替换、哈希、加密、保留格式脱敏（FPE）等多种算法，满足不同安全等级与业务可用性的双重需求。高性能低延迟：动态脱敏引擎采用内存计算与策略缓存技术，对查询响应延迟影响控制在毫秒级，保障业务连续性。对应《指南》要求：第5.1条“数据分级框架”下，对不同级别数据实施差异化安全保护措施的内在要求。智能访问权限设置：基于角色与分级结果的动态管控平台建立精细化的数据访问控制与脱敏标准体系，确保“合适的人、在合适的场景、访问合适的数据”。分级权限矩阵：根据数据级别（核心/重要/敏感一般/常规一般）与数据类别，自动生成差异化的访问权限策略。数据申请清单机制：用户可通过平台提交数据访问申请，明确使用场景、访问时长、数据范围；审批流程线上化、可追溯，所有访问记录留存审计日志。权限跟踪溯源：每一次数据访问行为均可关联至具体申请人、审批人、访问时间、操作内容，满足事后审计与风险追溯要求。对应《指南》要求：第5.5条“综合确定级别”后的差异化保护逻辑，以及数据安全事件可追溯的管理要求。四、合规之外：分类分级的深层价值监管的浪潮不会退去，只会越来越高。2026年，企业竞争的关键已不再是“谁拥有更多数据”，而是 “谁能更安全、更合规地用好数据” 在这一进程中，AI大模型与数据安全正在形成相互赋能、双向奔赴的紧密关系。一方面，AI大模型正成为数据安全分类分级的核心驱动力。传统的人工梳理与规则匹配方式，难以应对海量数据、动态变化和复杂场景的挑战。数语科技将AI大模型能力深度融入数据安全管理平台——通过智能算法，自动识别数据中的敏感信息；通过智能推理与分级要素分析，自动判定数据的安全级别；通过持续学习与反馈优化，让分类分级策略随业务演进动态进化。另一方面，数据安全同样是AI大模型行稳致远的生命线。大模型的训练、调优、推理全过程都高度依赖海量数据，其中不乏敏感信息和重要数据。若缺乏有效的分类分级与访问管控，模型训练数据中的隐私泄露、数据投毒、合规风险将成为巨大隐患。只有筑牢数据安全底座，才能让AI大模型在合规轨道上释放真正价值。没有数据安全，就没有可信的AI；没有可信的AI，就没有可持续的智能化未来。立即行动，联系数语科技，让数据分类分级从“合规必答题”变为“发展加分题”！
查看详情
数据智能体（二）：数据仓库建模与分析
在企业数据仓库建设中，业务复杂、数据源多，使建模周期长且容易出错。需求常分散、模糊，团队需花大量时间梳理指标口径、字段定义和业务规则，同时还面临命名不统一、口径多版本、规则难落地的问题，模型复用性低，治理成本高。DDM Dora 9.0 的建模智能体可整合现有标准和业务知识，辅助团队快速理解业务逻辑、规范字段与指标，实现高质量模型标准化。通过减少手动查找和重复工作，它缩短建模周期、提高模型复用率，并增强治理可控性，使复杂业务场景下的数据仓库建设更高效可靠01需求分析在数据仓库建设中，需求分析往往最耗时，也最容易出错。业务提出指标或分析需求时，开发人员需要反复确认来源系统、历史口径、计算逻辑和数据可靠性，传统模式下高度依赖经验、文档和口头传递。智能探源：让数据“自己讲清楚来龙去脉”在 Dora 9.0 中，建模智能体将智能探源作为需求分析起点。通过整合数据仓库模型、元数据与血缘、指标定义，以及历史设计文档、评审材料和制度文件等非结构化资料，构建可被智能体理解的知识库。建模人员只需用自然语言描述分析目标，智能体即可：自动定位相关主题域与核心事实表识别并复用已有指标口径追溯指标源系统与加工路径提示潜在的数据质量或口径差异风险数据仓库需求分析因此从“人工翻资料、找人确认”，转变为基于模型与知识的智能探源流程，大幅提高效率与准确性。02数据建模在模型设计过程中，建模人员无需频繁切换系统、查找文档或手工对照标准，只需基于具体使用场景，以自然语言描述建模意图，并可明确指定：当前模型当前实体当前字段或指标建模智能体将结合当前模型上下文，通过大模型的规划能力与工具执行能力，自动完成一系列复杂但高度规范化的工作：知识库与文件的语义检索智能体从企业知识库中检索相关规则、口径与历史实践，理解业务语义后，辅助生成符合业务要求的实体与属性。标准优先引用机制在创建字段时，智能体将优先匹配并引用企业已有的数据标准与代码。一旦确认引用，字段的命名、数据类型、精度与约束将自动继承标准定义，并直接写入模型。中英文命名自动转换对已存在标准词汇，严格按照标准进行中英文映射；对于暂无标准覆盖的字段，大模型将基于语义进行合理翻译与命名建议。整个过程无需人工反复查表、翻文档，建模人员只需聚焦于业务意图本身。03SQL生成在完成需求澄清与智能探源后，生成式 SQL 才真正落地。在 Dora 9.0 中，SQL 生成严格基于已确认的数据仓库模型、选定的事实表与维度关系，以及引用的指标口径。建模人员只需描述加工或分析意图，智能体即可：根据事实与维度关系生成标准化 SQL自动继承指标口径中的计算逻辑与过滤条件遵循企业 SQL 规范与命名规则结合自动测试闭环验证 SQL 可执行性与口径一致性生成的 SQL 不仅“能跑”，更语义清晰、口径可解释、可长期维护，为数据仓库的高质量交付提供保障。 04编排与调度在模型与 SQL 定义完成后，平台可基于模型血缘与依赖关系，自动参与到数据加工流程的编排与调度中：明确数据对象之间的依赖关系支持标准化的数据加工与指标计算流程为后续的数据质量校验与运行监控提供基础调度不再只是“跑任务”，而是对数据逻辑的持续执行与验证。05价值体现建模智能体在数据仓库全流程中发挥作用：建模环节：通过知识驱动和智能探源，快速梳理业务逻辑、标准化字段与指标，降低对经验丰富建模人员的依赖，让新手也能高效产出高质量模型。开发环节：生成式 SQL 自动继承指标口径、遵循企业规范，并结合自动测试闭环验证可执行性与口径一致性，大幅减少手动编码和重复工作。治理环节：统一口径、可追溯的模型和 SQL 使标准自然落地，增强模型复用性和数据资产可控性，提升整体数据治理水平。通过覆盖建模、开发、治理全流程，建模智能体不仅降低团队门槛，还显著提高效率和可靠性，使数据仓库建设更可控、可持续。
查看详情
数据的语义基础：数据模型与本体论
在数字化转型的深水区，企业数据团队面临的核心挑战不再是简单的数据存储或处理速度，而是数据的“理解”问题。不同系统、不同部门、不同业务线对同一个“客户”、同一个“订单”、同一个“产品”的定义可能千差万别。如何打破语义隔阂，让数据真正“说同一种语言”？数据模型（Data Models）和本体论（Ontology）作为两大语义基础工具，常常被提及，却也常被混淆或对立。今天，我们就来深入探讨它们的本质、差异，以及如何协同构建企业坚实的语义基础。你是否曾注意到，公司内部不同的团队对“客户”或“产品”这样的基本术语有着不同的定义？销售部门的“客户”可能指任何潜在联系人，而财务部门可能只将已付款的实体视为“客户”。这种看似微小的语义差异，正是导致数据孤岛、报告不一致和沟通障碍的根源。数据模型：务实派，聚焦“储存与结构”数据模型的核心目标是实用性和效率。它定义了数据在特定系统或应用（如数据库、应用程序）中应如何结构化和存储。关注点： “如何”存储和访问数据以支持具体操作。核心组件：实体（如“客户表”）、属性（如“姓名”、“ID”）、关系（如“客户ID”关联“订单表”）。特点：技术紧密耦合：设计深受数据库类型（SQL vs. NoSQL）和具体应用需求影响。范围特定：通常服务于单一或一组有限的应用场景。侧重结构：主要确保数据结构能支持高效的查询和事务处理。局限性：不同的系统可能为同一业务概念（如“客户”）创建完全不同的数据模型，从而导致系统集成时出现语义不匹配，形成数据孤岛。本体论：思想者，聚焦含义与共识本体论源自哲学，在信息科学中，它关注的是定义一个领域内概念和关系的精确含义。其目标是达成共识，建立一个共享的词汇表和概念框架。关注点： 事物“是什么”以及它们之间“为何”关联。它描述的是含义本身。核心组件：类/概念（如“客户”）、属性（如“姓名”）、关系（如“购买”）、公理/规则（如“企业客户是客户的一个子类”）。特点：语义核心：明确概念的内涵（定义）和外延（范围），力求无歧义。领域共识：旨在被领域专家广泛接受，作为沟通的通用语言。支持推理：通过定义的规则，可以推导出新知识（例如：如果A“是”B的一部分，且B“位于”C，那么可以推断A也“位于”C）。技术中立：独立于任何特定的实现技术。价值：提供统一的语义框架，是实现跨系统、跨组织数据互操作性和深度数据分析（如知识图谱）的基石。关键区别与互补关系数据模型和本体论并非非此即彼，而是互补的，处于不同的抽象层级，简单来说：-数据模型问：“我该如何设计这个数据库表来高效支持我的应用？”-本体论问：“我们所有人都同意的‘客户’一词的准确定义是什么？它与‘订单’之间的本质关系是怎样的？”1.本体论提供顶层语义蓝图：它定义了业务领域的概念地图，回答了“是什么”和“为什么”。这是达成业务共识的基础。2.数据模型基于蓝图进行具体实施：它在特定技术项目中，将本体论中的概念映射为具体的数据库表、字段和索引，回答了“怎么做”。理想的工作流程是：首先，业务专家和数据架构师合作，为核心领域（如客户、产品）定义或采用一个轻量级的本体论，建立共享语义。然后，数据工程师和开发人员以此本体论为指导，对接现有的数据模型，或设计具体应用的数据模型，确保不同系统的底层实现与统一的业务含义对齐。案例：汽车行业本体层： 明确定义车辆、车型、零部件、供应商、生产工厂等核心概念及其关系（如车辆由零部件组成，零部件由供应商供应）。数据模型层： 供应链系统、生产管理系统、销售系统等，各自基于这个本体设计其内部的数据结构（表、字段、关联）。即使内部结构不同，但核心概念的含义和关系保持一致。价值： 实现从零部件采购到整车销售的全链条数据追溯和一致性分析。 为什么这很重要？投资于语义基础（尤其是本体论思维）能带来巨大回报：无缝集成： 当系统共享相同的语义理解时，数据集成变得简单可靠。提升数据质量：明确的定义减少了数据不一致和错误。赋能高级分析：为机器学习和人工智能提供了丰富、关联且含义清晰的上下文数据。降低沟通成本：业务、技术和数据团队使用同一套语言，减少误解。如何开始？从关键领域入手： 选择语义混乱最严重或业务价值最高的领域（例如“客户主数据”）。促进对话：召集业务专家、数据架构师和工程师，共同在白板上梳理核心概念及其关系。利用现有标准：探索是否有行业标准本体（如用于电商的schema.org）可以复用或借鉴。选择工具：根据复杂度，可选用专业本体编辑工具（如Datablau Ontology Modeler）辅助语义梳理。迭代开发：从一个小的、定义明确的核心本体开始，在实践中应用并不断完善指导建模： 要求新的数据模型项目必须参考并符合已定义的本体语义。结论在数据驱动的时代，语义是数据的灵魂。数据模型解决了数据“怎么存”的问题，本体论则解决了数据“是什么”和“为什么这样关联”的问题。将两者有机结合，构建坚实的语义基础，是企业从“拥有数据”迈向“理解数据”和“驾驭数据”的必经之路。别再让语义鸿沟阻碍你的数字化转型，从今天开始，重视并构建你的企业语义基石吧！
查看详情
Datablau数据血缘成功落地中控技术——助力工业AI平台实现全链路数据治理升级
中控技术作为工业AI领域的标杆企业，三十余年来深耕流程工业智能化赛道，构建了覆盖全球50多个国家和地区、服务3.5万多家客户的产业生态。在推进第三代数仓建设的关键阶段，中控技术面临多代技术架构迁移与全链路数据管理的双重挑战，Datablau凭借SQLink数据血缘服务平台的专业能力，双方携手完成数据治理攻坚，为工业级数据治理提供了可落地的实践范本。多代架构迁移合并下的核心数据治理挑战中控的数仓建设历经三次重要迭代，从一代Oracle架构，到二代Hadoop大数据平台，当前正推进向第三代StarRocks流批一体架构的全面升级。此次升级的核心目标是完成ETL任务、数仓表及5000余张FineReport报表的迁移，实现底层表向StarRocks的替换，并构建完善的数据血缘管理能力，以支撑工业AI场景下的数据全生命周期管理需求。在项目推进过程中，一系列数据治理瓶颈逐渐显现：全链路血缘覆盖不足，现有自研数据资产管理平台仅能支持数仓内部血缘管理，无法串联“数据源→ETL→数仓表（ODS/DWD/DWS/ADS）→报表（FineReport/BI）→业务应用”的完整链路，导致数据来源与流向追溯困难，影响数据可信度。 数仓迁移风险管控难度大，从Oracle到StarRocks的技术栈切换过程中，由于缺乏对ETL任务、数据表与报表间依赖关系的清晰梳理，迁移影响范围难以精准评估，业务连续性保障面临挑战。 报表与底层数据表映射关系模糊，5000余张FineReport报表对应的底层数据支撑关系未明确界定，导致迁移范围难以精准划定，人工排查效率低且易出现遗漏。 自研平台功能存在局限，针对多层级表血缘解析等复杂场景的支撑能力不足，无法满足数据开发、业务分析等实际工作对数据血缘深度查询的需求。SQLink解决方案构建全链路数据治理能力针对中控的业务需求与治理痛点，Datablau基于SQLink数据血缘服务平台，提供了覆盖全场景、适配多架构的专业化解决方案，通过四大核心能力实现精准破局：全链路血缘覆盖，打通数据流转关键节点SQLink平台实现了对多技术架构的全面兼容，涵盖Oracle传统数仓、Hadoop大数据平台、StarRocks流批一体架构及报表工具（FineReport、BI），构建起“数据源→ETL→数仓→报表→业务应用”的端到端血缘可视化链路，彻底解决了数据链路断裂问题。迁移合并影响精准评估，降低架构升级风险通过自动解析ETL任务、数仓表（ADS/DWD等层级）与报表间的依赖关系，生成可视化影响范围图谱，快速定位“迁移对象→关联对象”的关联路径，为迁移方案制定提供数据支撑，有效避免了依赖关系遗漏导致的业务中断风险，保障了多代数据仓库的平滑过渡。极致性能支撑，适配复杂业务场景平台具备强大的血缘解析性能，且可支持50层级以上血缘关系查询，8秒内即可完成全链路展示；针对2GB级别的FineReport压缩包，能够高效解析报表内置SQL语句，精准输出报表内部血缘链路及与数据库表的映射关系，大幅提升报表迁移效率。同时，平台解析性能达到0.5小时成功解析10000个脚本的水平，充分满足大规模数据场景下的治理需求。灵活集成部署，适配企业现有IT架构SQLink平台与中控技术自研数据资产管理平台实现无缝集成，将原有平台的血缘管理能力从“数仓内部”升级为“全链路覆盖”，无需重构现有系统即可完成功能增强；同时支持与企业单点登录系统对接，实现全企业用户的无缝访问。部署模式上，平台以8台服务器集群弹性扩展。数据治理升级带来的多维度价值落地随着Datablau SQLink数据血缘平台的成功部署，中控在数据治理与业务支撑方面实现了显著提升，价值成果体现在多个维度：实现全企业数据资产可视化管理平台完整呈现了企业20万+表、300万+字段、7万+SQL文件（含脚本、存储过程、视图等）、5000个Kettle任务文件及5000+报表的全链路血缘关系，覆盖数据流转各层级，彻底解决了“数据来源不清、流向不明”的问题，为数据资产化管理奠定了坚实基础，支撑数据全生命周期可追溯。保障数仓迁移项目高效推进通过清晰界定ETL任务、数仓表与报表的迁移范围及依赖关系，有效降低了迁移过程中的风险隐患，确保一代、二代数仓向StarRocks架构的平滑过渡，缩短了项目周期，提升了迁移工作的整体效率与质量。提升数据资产平台核心能力与自研平台的深度集成，使原有数据资产管理平台实现了功能升级，从单一的数仓内部血缘管理，拓展为全链路血缘查看能力，满足了工业AI场景下数据资产化管理的核心需求，为后续数据治理工作的深化开展提供了有力支撑。高效支撑复杂业务场景运转针对50层级的核心表，平台8秒内即可完成全链路血缘展示，远超业务预期；在工程费用报表迁移等实际场景中，能够穿透报表指标展示层、数据集语义层、数据源物理层，直达数据仓库底层表，为业务分析与数据验证提供了高效支持。构建全员参与的数据治理生态数据开发人员可通过平台快速定位ETL依赖关系，大幅减少问题排查时间；业务分析人员能够精准追溯报表数据来源，提升分析结果的可信度；在敏感数据的内部追踪等场景中，快速的数据溯源能力确保了合规要求的有效落地，实现了数据治理与业务工作的深度融合。工业数据治理的实践启示与未来展望中控与Datablau的成功合作，为大型工业企业在多代技术架构迭代背景下的数据治理提供了宝贵经验。此次实践表明，专业的数据血缘工具不仅能够解决技术层面的链路管理问题，更能通过数据资产的规范化管理，为业务决策、风险管控与合规管理提供核心支撑，是企业数字化转型向纵深推进的重要保障。Datablau始终聚焦数据治理领域的技术创新与实践落地，凭借SQLink数据血缘服务平台的全链路覆盖、高精度解析、高性能支撑与灵活适配能力，已为多个行业的标杆企业提供了专业解决方案。未来，Datablau将持续深化与工业、金融、能源等领域企业的合作，不断优化产品功能与服务体系，以更贴合业务需求的数据治理方案，助力企业释放数据价值，为数字化转型注入持久动力。
查看详情
建模智能体，AI 时代的数据治理新范式
1数据治理是上一代信息化的体系性问题过去十多年，企业在数据治理上的投入并不算少。沿着数据治理方法论，我们有主数据、元数据、数据标准、数据质量、数据资产目录、数据开发与分析、安全分级分类……几乎每一个治理要素，都有成熟的治理体系和产品形态。然而，在大量企业的真实的实践中，数据治理始终呈现出一种制度优先、事后介入的状态：标准需要被记住规范需要被遵守治理依赖人工评审和协调系统只能记录结果，而无法影响过程等等的诸多问题，核心问题是：过去的数据治理是一种制度优先的离散工作，成为一个多部门，多链条，长周期的复杂工程，在熵增理论的本质之下，数据组织和系统必然有着天然的走向无序的惰性。过去我们的企业以严格管理之精神，对抗着我们自身在数据与流程中有意和无意的造成的数据腐化。最终，数据治理演变为“治人”，而不是“治数据”。这，正是上一代数据治理方法与系统的根本局限，虽然我们都知道其本质，但是在上一代的企业架构之下，并没有什么好的解决办法。2生成时代的信息架构革命这一轮技术变革中，真正改变企业 IT 架构形态的，并不是某一个 AI 工具，而是系统的生成方式发生了改变。以 vibe coding 为代表的新范式，正在将系统构建从人工逐行实现模式，提升到意图设计驱动与自动生成，正在重塑软件系统的构建逻辑。这种变化的本质，是将大量原本依赖个人经验与即时判断的决策，转移给可推理、可复用的智能系统。这直接影响了长期困扰 IT 系统及其数据质量的熵增问题。首先被优化的，是对人工规范执行的高度依赖。在传统模式下，数据标准与规范和治理规则必须通过文档宣贯、人工培训和评审流程才能被落实，其执行效果高度依赖个体经验、自觉性和时间成本。而在以代码生成机制为基础的体系中，规范不再依赖人工记忆，而是直接嵌入生成逻辑之中，成为系统在建模和开发瞬间必须遵循的前置条件。其次被缓解的，是数据与开发之间的时间错位问题。传统数据治理大多发生在设计完成、系统上线，甚至运行之后，以评审、盘点和整改的方式介入。这种事后治理天然滞后，往往在问题已经形成之后，才付出更高成本进行修复。数据智能体的引入，使治理前移到数据结构生成的实时过程中，将原本需要事后纠偏的问题，转化为事前约束和即时校验。第三个被根本性改善的，是知识不可复制带来的问题。过去，数据的一致性、指标口径的稳定性，往往依赖少数资深人员的经验判断。一旦人员变动，系统理解能力随之流失，数据体系迅速走向分化和漂移。智能体将这些隐性经验转化为可推理、可复用的规则与上下文，使数据治理能力第一次摆脱对个人的依赖，成为组织层面的持续能力。同时被削弱的，还有系统割裂带来的治理盲区。在传统架构中，各个系统平台彼此分离，治理信息难以贯通，导致资产孤岛和口径不可追溯。基于智能体的体系通过对多类数据系统的统一理解与连接，使数据结果处于同一认知框架之下，治理不再依赖跨系统对账，而是由统一的语义和推理能力自然支撑。3数据智能综合体在业界对数据智能体的诸多探索中，我们（Datablau）推出了新一代的数据建模智能体，之所以选择以数据智能体作为整体能力的切入点，并非偶然，而是源于对 AI 时代数据问题本质变化的判断。相比从分析、问答或治理功能入手，这一路径在语义一致性、系统设计以及跨域连接能力上，具备天然且难以替代的优势。首先，在AI 时代，数据治理的重心正在转向“知识与语义治理”，而数据模型是语义治理最关键、也是最佳可落地的核心输出物。诸如指标口径、业务术语、实体关系、事实与维度的划分，本质上都是语义问题，而这些语义最终通过数据模型这种结构化形式被固定下来。脱离数据建模的语义治理，只能停留在概念层面；而以数据建模智能体为核心，则可以将业务语义、指标定义和治理规则直接沉淀为可执行、可推理的数据结构。今天本体建模也受到了广泛关注，我们必须认识到，本体建模与数据建模在业务语义和规则的继承性，我会另写文章来说明。其次，AI 时代的开发工程正在重新分工，设计的重要性显著上升，而具体 Coding 本身正在被大模型高度商品化。今天的代码自动生成工具，已经证明大模型在实现层面具备极强能力。真正稀缺的，不再是怎么写代码，而是应该如何需求分析和设计。数据模型正是这一设计层的集中体现，它承载的是业务抽象、分析视角和长期演进逻辑。以数据智能体切入，意味着把智能用在最具长期价值、最难被简单替代的设计层，而不是在实现层反复叠加自动化能力。第三，数据模型天然处于需求分析，应用开发、数据分析等工作的交汇点，是整个数据体系的核心中枢。向上，它连接业务需求和分析目标，决定指标口径和分析视角；向下，它约束数据仓库结构、数据服务接口以及应用系统的数据使用方式；横向，它关联数据资产、血缘关系和治理规则。这种中枢位置，使数据建模智能体能够在不同场景中切换角色，而不丢失上下文。相比从单一使用场景切入的智能体方案，这种能力具有天然的扩展性和不可替代性。基于上述判断，我们构建了一个类似Cursor 形态的数据建模智能体。它可以接入大模型能力，同时融合基础数据模型、指标体系、业务术语知识库和企业级数据规范，在统一语义上下文中扮演数据建模、数据分析、数据资产盘点等多重智能角色。由此，数据治理不再依赖外部制度和事后检查，而是在数据结构生成的过程中自然发生。 当然，在这一体系下，原有的数据治理系统并未消失，而是回归为治理过程与结果的记录系统；真正决定数据质量、一致性与可演进性的核心能力，已经前移到以数据智能体为中心的设计与生成阶段。这也正是我们认为，数据智能综合体，将是AI 时代数据治理的正确打开方式。体验Datablau DDM Dora智能体，请联系小助理：datablauxzs
查看详情
