数据中台（数据治理平台）

本次数据中台V3.8.4版本聚焦实时数据流转与用户操作体验，覆盖数据集成，数据治理、监控预警等多个模块，让数据管理更高效、更稳定、更易用。 一、数据集成 1 数据归集 - 新增心跳测试机制 我们发现在实时数据归集功能中，若来源库长时间无新数据产生，来源库的数据库日志会被定期清理，后续有新数据接入时，任务因缺失同步节点会导致归集任务出错 此次升级，增加心跳测试功能，通过定期推送任务最新日志，避免因来源表长时间不更新、日志删除导致的游标缺失报错问题，保障数据实时流转稳定性。 心跳检测是通过网络周期性发送的状态监测信号，主要用于判断机器、存储器节点的在线状态与运行健康度。其核心原理是通过定期发送微小数据包（心跳包）来确认通信双方或集群节点的可用性。 主要作用： · 连接维持：防止网络中间设备（如路由器、防火墙）因长时间无数据流而关闭连接。 · 故障探测：快速发现宕机节点，提升分布式系统的可靠性。 2 数据源接入 - 优化文件管理体验 新增单个/批量下载文件，数据获取更灵活。 优化重名文件上传逻辑：上传重名文件时，支持用户自主选择“覆盖原文件”或“保留原文件”，操作更可控。 二、数据治理｜数据质量模块 1 模式重构 - 简化流程，聚焦核心需求 数据质量模块由“派发模式”改为“不派发模式“，去除冗余流转环节。 精简功能菜单：删除「问题数据管理」、「按来源部门 / 责任人自动派发」、「手工派发」、「问题派发日志」、「退回问题设置」、「数据异议管理」、「数据质量评测报告」、「规则质量分析」等 8 项非核心菜单。 新增「问题数据查看」模块：仅保留“待修复”、“已关闭”两种状态的问题数据；“待修复”为评测出的问题数据；“已关闭”为源头修复后系统自动核销的记录。 2 评测模型管理 - 优化配置逻辑 数据源选择：仅显示质量模块支持的数据源类型，并优化为多层级选择样式。 主题创建：取消组织机构关联要求，无需下拉选择部门，简化创建流程。 评测对象管理：新增评测对象时，取消物理表来源部门的校验，无需关联来源部门即可完成添加。 规则管理：隐藏更新频率规则和规则库，简化配置项。 3 评测任务管理 - 新增实用功能 操作优化：新增“立即执行“按钮，支持规则一键全选/取消功能，操作更高效； 执行策略升级：优化为4种执行策略（手工触发、重复执行、定时一次、Cron表达式），适配更多场景。 三、 评测任务管理 - 新增实用功能 数据质量洞察升级 数据治理分析模块新增2大核心功能：「问题数据统计」、「时效性分析报告」模块，助力全面洞察数据质量状况，为决策提供数据支撑。 四、 运维监控 新增「质量评测任务监控」功能，实现核心任务全流程监控。 扩展预警渠道：在数据归集监控、数据清洗监控、数据共享监控模块中，增加企业群消息预警功能，实现异常信息及时同步。 五、基础配置 消息通知配置：新增企业微信群消息配置。 安全强化：对AgentID、密钥、Webhook地址、邮箱密码等敏感信息采用脱敏显示，提升系统信息安全性。 龙石新书｜欢迎共创 龙石数据编写的书籍《数据治理实战指南—“理采存管用”落地方法、步骤与模版》已在官网连载了前7章内容，供大家参考交流。这不是一本晦涩的理论著作。对于实施人员，这是一本手把手帮带的指导书。对于管理人员，这是一本提升成效的检查单。更特别的是，本书采用了开放式共创的编撰模式，诚邀大家审阅、研讨、共创和交流。 点击图片进入共创空间，与作者直连、获电子版书稿

本次龙石数据中台V3.8.3版本升级的重点聚焦于数据共享、数据集成与数据应用三大核心模块，重点提升数据流转效率、接入能力与协作安全性，助力各组织实现更高效、更可控的数据管理。 一、数据共享｜API共享模块 1 新增「数据处理任务」组件 在API 管理模块的 API 编排流程中，新增“数据处理任务“组件，支持在流程中直接触发批量归集、数据清洗、数据编排等任务。此前，数据集成、清洗等模块相互独立，数据传输后需手动跨模块发起任务，操作繁琐且流转耗时。新增组件后，用户可通过API触发数据处理任务。 2 优化鉴权指引 在中台下载的API文档中，补充“鉴权模式“说明，提供3种鉴权模式的详细说明，帮助用户快速理解并掌握鉴权配置方法。 二、数据集成 1 数据源接入扩展 新增2种数据库类型支持本次升级进一步丰富数据源适配类型，新增海量数据库G100、华为GaussDB两种数据库的接入支持。 2 任务日志体验优化 新增任务分组查询批量归集/清洗/编排任务日志可按分组筛选，支持筛选分组下各任务的执行情况。 规范术语 将列表页及详情页中的“最近执行状态”统一更名为“执行状态”，表述更精准。 扩充查询维度 新增“执行状态“、“执行日期”查询维度，支持用户快速筛选目标任务日志。 三、数据应用｜数据可视化模块 1 新增报表“赋权”功能 支持工作空间管理员针对当前空间内的报表资源，向其他用户精准授予报表查看权限。既保障了报表数据的访问安全，又提升了多角色协作下的数据资源共享效率。 龙石新书｜欢迎共创 龙石数据编写的书籍《数据治理实战指南—“理采存管用”落地方法、步骤与模版》已在官网连载了前7章内容，供大家参考交流。这不是一本晦涩的理论著作。对于实施人员，这是一本手把手帮带的指导书。对于管理人员，这是一本提升成效的检查单。更特别的是，本书采用了开放式共创的编撰模式，诚邀大家审阅、研讨、共创和交流。 点击图片进入共创空间，与作者直连、获电子版书稿

引言 今年的AI领域，堪称“神仙打架”。两周前，Google突然发布Gemini3，其基准测试成绩断档领先，迅速引爆科技圈，公司股价也应声大涨。 此前Gemini系列—直低调，风头被ChatGPT和Claude占据；而Gemini3的横空出世，让业界重新审视这位AI“老大哥”——无论是Vibe Coding的准确度与审美，还是Nano Banana Pro的精度，都展现出“六边形战士”般的全面能力。 AI浪潮已不可避免地席卷数据行业。最近几周，我们收到不少客户咨询，希望搭建“ AI 数据中台” ，并构建多个 AI 用数场景。然而深入沟通后我们发现，很多企业的基础数据状况并不乐观：信息化系统零散、缺乏统—数据底座……在这样的基础上推进AI，注定困难重重。 类似情况在行业中十分普遍。不少企业过去几年投入大量预算做AI POC（概念验证），却始终难以规模化落地。问题往往不在模型本身，而在于数据治理的根基尚未夯实。无论是AI应用、智能分析，还是行业模型微调，都离不开工业级、可复用、可信赖的数据底座——而这，正是数据治理工作的核心目标。 本文将从数据广度、数据质量、业务理解三个维度，阐述为什么“要做AI，先做数据治理”。 一、如果跳过数据治理，AI的致命缺陷 1.1 数据孤岛 AI=数据+算法+算力， AI应用必须先获取数据才能做场景化处理。真正有价值的AI，需要全方位的数据，而非零散的“单—视角 ”。 大多数企业的信息化建设是离散进行的。客户数据存储在CRM系统中，用户行为数据散落在各类日志中，财务数据则位于ERP系统内。这些数据天然形成隔离，导致唯—标识难以建立，模型无法准确关联用户在跨业务场景中的行为轨迹。 AI模型只能基于单—系统的碎片化数据进行训练，无法关联用户的跨业务行为。 这就是缺少数据治理工作支撑的典型问题：数据广度和深度不足，AI无法形成对业务的全面认知。而系统化的数据治理，正是通过“数据归集+统—建模”，为AI提供全景数据支撑： 数据归集：通过数据集成平台实现跨源数据的汇聚。 数仓规划：基于数仓规划和主题域设计，构建宽而全的数据。 龙石数据中台提供多源异构数据集成、实时与批量同步、低代码可视化配置、多协议转换、高可靠容错及信创适配能力，全面支撑高效、安全、灵活的数据集成需求，打通数据孤岛。 1.2 垃圾进、垃圾出 “垃圾进、垃圾出”由来已久，在AI时代被进—步放大，输入数据的质量，直接决定模型输出的价值。劣质数据喂给再先进的大模型，也只能产出—本正经的“高科技垃圾”。 有些企业认为： “不做数据治理，用开源ETL工具把数据抽出来不就行了？ ” 这是—个典型误区： 数据归集 ≠ 数据治理 。 某零售企业曾试图跳过数据治理，用AI助手统计销售额。由于底层数据中存在大量未剔除的测试订单，且金额单位（元/万元）混乱不统— ，AI输出了严重虚高的业绩，误导了管理层决策。 真正的数据治理除了实现数据汇聚，更关键的是构建全链路的数据治理体系，从源头保障数据质量，为AI项目规避“垃圾进、垃圾出” 的风险。 数据治理：数据标准管理、质量校验、数据血缘。 资产沉淀：指标中心、标签中心、清洗/加工流程标准化。 龙石数据中台-数据治理模块，基于智能化数据探查与大数据旁路监测技术，提供可视化规则配置、自动化质量评测（支持百亿级数据5分钟内完成千万级评测）、问题闭环管理及多维度精细化质量报告，构建不侵入原系统的统—、高效、智能的数据质量管理体系，从源头减少 “垃圾数据”的产生。 1.3 AI不懂业务 无论是中台、 BI还是AI，技术的终极目标都是服务业务。脱离业务理解的AI，即便技术指标再优秀，也难以创造实际价值。数据治理的关键作用之—，就是完成企业业务知识的数字化沉淀，为AI提供“业务认知”基础。 当业务人员用自然语言向AI提问时，使用的是业务术语；而AI底层运行依赖的是技术语言。 例如，电商运营人员问 AI ：“神仙水上周的销量是多少？ ” “神仙水”是消费者端的俗称，实际产品名是“SK-II 护肤精华露”。 如果数据中台未建立业务术语与产品之间的映射关系，AI 在底层就找不到“神仙水”这—字段，自然无法返回准确销量。 有效的数据治理不仅是提供一个技术平台，更是助力企业沉淀业务知识，构建“业务语义层”的管理工程： 业务驱动建模：模型结构与业务流程对齐。 指标/标签体系沉淀：让模型直接使用业务语义。 数据 + 业务知识的双重监督：减少“黑盒错误”。 龙石数据中台-AI用数智能体，通过汇聚多源异构数据并进行清洗、转换与集成，确保数据准确—致；同时依托元数据增强技术构建企业级知识图谱，实现数据语义标注与业务含义补全，让系统更懂业务、更准查询，为智能分析与决策提供高质量、可理解的数据基础。 二、总结 梳理下来，我们可以清晰地看到： AI与数据治理并非“替代关系”，而是 “协同共生”的关系。 AI=数据+算法+算力，数据提供 AI 学习的基础信息；算法决定加工数据的步骤，以及以产生智能的决策；算力支撑算法高效地处理海量数据。 跳过数据治理做AI的代价是惨痛的，短期看似乎节省了数据治理的成本，但长期看，每个AI项目都将陷入重复的数据清洗泥潭，架构越来越乱，维护成本呈指数级上升，最终沦为烂尾工程。 本文仅基于当前小编的行业实践和观察整理，期盼与大家一起深入探讨。龙石数据长期专注于数据管理能力的输出，我们正在将多年实战经验整理成书，新书内容即将在各大平台分享，希望能更好地助力大家的数据治理工作。

引言 在本系列前面的文章中，我们分别介绍了《什么是数据中台》和《为什么数据治理是持续性的？》 也为大家介绍了龙石数据“理采存管用”的数据治理方法论。 不少读者反馈，对“数据仓库”这个词还不太清楚：它和数据中台到底是什么关系？数据中台既然覆盖“理采存管用”，那数据仓库又在其中扮演什么角色？ 在深入探讨“理”（梳理）和“采”（采集）之前，我们可以先把“存”（存储）这个环节讨论一下。 数据中台和数据仓库的区别与联系 数据仓库为什么需要分层 业界常用的分层思路有哪些 龙石数据在实战中总结的分层模型是怎样的 一、数据中台 vs 数据仓库 数据中台：是一个承载“理采存管用”全流程的“工具与管理平台” ，核心是让数据能力可复用、可服务化。 数据仓库：是中台体系中负责 “存”的 “数据地基”。 它们的关系是： 数据经过中台的治理（理）和采集（采）后，存入数据仓库；再通过中台的调度和管理（管），最终以服务形式（用）支撑业务应用。 通俗来讲，数据中台操作数据，负责把数据治好。数据仓库存储数据，负责把数据存好。 二、数据仓库为什么一定要分层？ 数据仓库的命名源于“仓库”的概念，其设计核心在于解决数据管理中的混乱与低效问题。若将原始数据、加工数据及应用数据混杂存储于单一存储层，将导致数据定位困难、管理复杂、查询性能低下。数据仓库分层设计正是为应对这一挑战，通过结构化组织实现数据的高效治理与利用，数据仓库有以下优点： 结构清晰：像“俄罗斯套娃”一样，采用分层架构（如ODS、DWD、DWS、ADS），每层职责单一，将复杂数据流程简化为可管理的模块化处理，复杂问题简单化。 数据复用：沉淀公共指标和宽表，避免“重复造轮子”，极大提升下游开发效率。 任务解耦：复杂任务拆成多个步骤，便于运维和重跑，一层失败不影响全局。 查询加速：空间换时间，通过预处理和汇总，让上层应用（AI用数、BI、大屏）查询更快。 水平扩展：多数数仓基于分布式架构支持弹性扩容，无缝适配数据量增长场景，确保系统在高负载下保持高性能与高可用性。 三、业界主流的分层思路 3.1 经典两大流派 Inmon（自顶向下）： 主张先建企业级数据仓库（EDW），再建数据集市。 Kimball（自底向上） 主张先围绕业务过程建数据集市，再通过一致性维度整合成企业视图。 Inmon（自顶向下）就像先建一个巨型中央仓库，把所有货物标准化后，再分发给各部门小店； 而Kimball（自底向上）则像先为各部门开专业零售店，但使用统一的商品编码和会员体系，让这些店能轻松连锁成一个大超市。 前者强调整合与统一，后者追求速度与实用。现代数据平台通常结合两者思想。 3.2 当前共识：五层模型 融合了经典思想，互联网和大厂普遍采用五层结构： ODS（贴源层） 贴源层顾名思义是从源头粘贴数据，同城使用数据集成工具（ETL），将源头业务系统数据进行归集，保持数据的原貌，不做任何修改，隔离源头业务系统，不影响原系统的运行。 DWD（明细层） 当原始业务数据进入ODS层时，会对数据进行标准、治理的检查，将问题数据进行清洗、转换、去重、标准化等动作，实现数据的自优化。 DWS（服务层） DWS服务层，更多地贴近业务场景，在DWD明细层的基础上进行汇总加工和聚合计算，例如将事实表中的聚合度量值和维度表中的数据进行汇总聚合，借助DIM公共维度层的不同维度，计算分析出多维度的业务信息。 ADS（应用层） ADS层为数据产品、报表和分析服务提供可直接使用的数据，支撑业务决策的数据应用和报表分析。 DIM（维度层） DIM贯穿于ODS、DWD、DWS、ADS，确保各层数据计算中维度的一致性和准确性。提供通用的维度属性，常见的维度包括，时间维度：年、季度、月、日、时等；空间维度：物理位置、网络地址等。 五层结构相互独立又协同工作，形成高效的数据处理与分析体系，支持智能化的业务应用。 数据流向：ODS → DWD → DWS → ADS DIM 贯穿所有层次，确保维度一致性 这种架构兼顾高内聚、低耦合的数据仓库建设思路，但对团队建模能力要求较高，不少中小企业在落地时感到吃力。 四、龙石数据的实战分层模型 如果说 3.2 的五层模型是学院派，龙石数据的数仓分层就是实战派。龙石数据中台目前支持多种常见数仓，也对信创数据库（如达梦、人大金仓）做了良好适配。无论底层选Doris、StarRocks还是PostgreSQL，都将分层思想内嵌到平台中，提出一套更实战、易用、低门槛的分层模型： SRC（来源层） → ODS（贴源层） → DW（治理层） → ADS（应用层） → DS（共享层） 4.1 设计思路：让数据好管好用 1. 可行性与易用性 架构不是为了“炫技”，而是为了更快更好地实施和使用。考虑到数据工作未来会引入更多业务人员，以及“中国式速度”的要求，我们的模型必须“开箱即懂”。 2. 强化“理采”与“用”的映射： 将「SRC-来源层」纳入： 明确映射“理采存管用”中的“理”和“采”的起点，方便从源头理解数据。 将「DS-共享层」纳入： 明确映射“用”的出口，让数据提供者和消费者清晰知道“数据成品”在哪。 3. 降低“存”与“管”的门槛： 弱化DW细化分层： 将业界DWD（明细）和DWS（汇总）合并简化为「DW-治理层」。 解耦DIM维度层： 将「DIM-维度」的管理从数仓ETL中剥离，交由龙石中台的“数据标准、数据清洗”模块进行维护。 让实施人员无需精通复杂的Kimball建模，大幅降低数据工作的门槛。 4. 确保规范（前提）： 简化不等于随意。没有规范的敏捷是“灾难”。龙石模型通过中台工具将规范（如标准、质量等）“嵌入”到数据的归集、清洗、共享流程中，确保“简化”后的数据质量。 4.2 龙石五层模型详解 第 0 层：SRC（来源层） 逻辑层，不存实际数据。作用是梳理数据资产，比如“CRM系统-客户表”，这是数据治理的起点。 第 1 层：ODS（贴源层） 物理层，把源系统数据原样同步过来，只做轻微格式处理，不做业务加工。作用是可回溯、解耦业务库压力。 第 2 层：DW（治理层） 核心层，融合了明细和汇总功能。在这里执行数据清洗、标准化、关联和轻度汇总，产出可信、可复用的数据。 第 3 层：ADS（应用层） 面向具体业务场景做深度加工，比如大屏数据、报表数据、算法样本等。DW 层保持稳定，ADS 层灵活响应需求。 第 4 层：DS（共享层） 逻辑层，将 ADS 的数据包装成 API 或数据目录，供业务系统或人员直接调用。使用者无需关心数据存在哪里。 五、龙石数据的实战分层模型 数据中台是平台，数据仓库是地基。分层是为了让数据更清晰、可复用、易治理。 业界有 Inmon、Kimball 等经典思路，也有通用的五层模型，但对实施能力要求高。龙石数据在此基础上，提出更注重实战的五层模型（SRC/ODS/DW/ADS/DS），通过中台工具降低建模门槛，能更快落地“存好、管好、用好”数据的目标。 本文基于小编当前实践经验整理，数据仓库领域发展迅速，数据湖等新概念也不断涌现，但分层管理的核心思路始终未变。龙石数据长期专注于数据管理能力的输出，目前我们正在将多年实战经验整理成书，未来也会在书中更系统地介绍数据仓库相关内容，希望能更好地助力大家的数据治理工作。

在之前的文章中，我们探讨了什么是数据中台。数据中台本质上是实现数据“汇聚整合”与“服务化输出”的核心载体。

传统的数据应用场景中，业务人员想要获取数据，尤其是想要获取一些加工后的数据，往往需要掌握复杂的SQL语法或依赖IT部门进行数据查询；这种模式不仅门槛高、周期长，还严重制约了数据价值的快速释放。 本次V3.8.2版本推出的 AI 用数智能体，旨在通过自然语言交互，让业务人员像与同事对话一样轻松获取数据洞察，实现“即问即得、即见即用”的智能化数据服务体验。 一、自然语言交互，数据查询大提速 1 零门槛数据查询，自然语言实现数据洞察 用户只需用自然语言描述数据需求（如"查询2024年各地区的生产总值"、"分析本季度销售趋势"等），AI用数智能体即可自动理解用户意图，将自然语言转换为标准SQL查询语句，调用数据仓库获取查询结果。 系统支持多轮对话，帮助用户逐步细化需求，精准定位所需数据，告别复杂的SQL编写和漫长的需求排期。 二、多样化数据展示 针对数据查询的返回结果，系统自动选择最适合的图表类型来展示数据。（饼图适合展示占比关系，柱状图适合对比不同维度的数据，折线图适合展示趋势变化） 同时，系统会对原始数据进行格式化处理，包括汇总、排序等，并用自然语言封装查询结果，以直观、可理解的方式为用户提供数据洞察。 三、知识库持续优化，更懂你的业务 1 元数据增强技术在现有数据仓库与元数据库基础上，通过元数据增强技术补充业务术语、数据关联等业务属性，帮助 AI 用数智能体精准理解业务场景，避免因技术与业务语言差异导致的需求误解。 2 智能体微调系统将用户操作中的负反馈样本纳入知识库，结合 prompt 技术、示例提示、多轮提示优化等手段，不断迭代优化模型提示策略，持续提升 AI 对复杂业务需求的理解能力与响应精准度。 四、构建AI问数智能体运营体系，准确率直逼100% 为保障数据查询的准确性，平台构建了一套完整的 AI 问数智能体运营体系。 当用户对查询结果存疑时，可随时提交工单反馈，技术部门将及时跟进补充数据或微调 AI 模型，并快速向用户反馈处理结果，形成 “用户反馈 - 模型优化 - 效果提升” 的持续迭代闭环。 运营体系的构建，推动AI用数准确率从95%向100%无限接近，每一次用户反馈都会让AI用数智能体变得越来越懂业务，越来越精准。 AI用数智能体的出现，让数据查询从技术门槛变成了业务能力。 业务人员不再需要学习复杂的技术，就能快速获取数据洞察，真正实现了"让数据为业务服务"的理念。无论是日常的业务监控，还是临时的数据分析需求，AI用数智能体都能快速响应，让数据价值得到最大化的释放。

结论很简单：场景驱动、路径正确，中台就有价值；否则，就是负担。

龙石数据中台 V3.8.1 升级详情速览

龙石数据中台 V3.7.1 升级详情速览

一、数据共享-API共享 1 支持所有API类型的3种鉴权模式 签名模式：需提供AppKey和SecretKey。 简易模式：仅需AppKey即可调用。 不鉴权：无需密钥。 2 自助API支持添加清洗转换规则 支持给返回参数的字段添加清洗转换规则，对API返回结果进行灵活处理。 二、基础配置-清洗转化规则 tips：清洗转换规则是一组预先定义的逻辑或函数，对原始数据进行处理，消除错误、冗余和不一致性。将原始数据转化为准确、统一、可用的高质量数据。 核心可概括为两大环节：1.数据清洗：识别并处理原始数据中的各类问题，消除 “脏数据”2.数据转换：优化数据格式、结构或值域，实现标准化与规范化。 例如：输入：带有缺失、格式混乱的原始数据表；输出：统一包含标准化数值、规范日期的干净数据。 1 新增40条清洗转换规则 API管理、数据归集、数据清洗以及数据共享等功能可直接使用转换规则。 三、数据集成-数据源接入 1 接入Oracle数据源时，支持两种连接方式 SID（System Identifier）：数据库实例的唯一标识符,用于区分同一数据库服务器上运行的多个数据库实例；服务名（Service Name）：数据库服务的标识符，是更灵活的云端或分布式环境连接方式。 2 新增数据源扩展属性配置 在数据源连接参数中新增扩展属性配置选项，允许用户根据数据库连接信息自助填写属性名及其值。 四、数据集成-多表归集管理 1 新增数据缓存大小配置 新增手动调节缓存条数字段，解决表输入和表输出速度不一致导致的内存压力问题。 2 资源组下拉框 原“集群”功能统一改为“资源组”，任务执行时默认选择当前模块下的资源组。 3 新增保存并立即执行按钮和功能 多表映射配置后可直接执行任务，无需额外配置任务监控（任务需处于启用状态）。 4 新增建表日志和建表进度提示 启动自动建表流程后可随机关闭页面，建表进度和状态可以在建表日志中查看。 5 批量设置常量功能，新增共性字段类型下拉选择框 支持为字符型、整型、浮点型、日期时间型、时间戳型设置常量。 6 【修复】数据源接入信息被更改后，多表归集任务同步生效 当用户在数据源配置界面修改了数据源信息，无需进入关联的多表归集任务或流程中重新编辑和保存再运行，在多表归集任务或流程中直接点击运行，这些数据就会自动同步过去。