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

本次数据中台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），通过中台工具降低建模门槛，能更快落地“存好、管好、用好”数据的目标。 本文基于小编当前实践经验整理，数据仓库领域发展迅速，数据湖等新概念也不断涌现，但分层管理的核心思路始终未变。龙石数据长期专注于数据管理能力的输出，目前我们正在将多年实战经验整理成书，未来也会在书中更系统地介绍数据仓库相关内容，希望能更好地助力大家的数据治理工作。

在数字经济时代，数据已成为关键生产要素。然而，许多企业在推进数据驱动转型的过程中，普遍面临着“数据孤岛”的困境——数据分散在各个系统中，业务人员不知道有哪些数据、不知道数据在哪里、更不知道如何获取数据。数据资源目录的出现，正是为了解决这一核心痛点，它不仅是数据的“导航系统”，更是实现数据价值释放的重...

在企业的数据管理实践中，一个普遍存在的误区是：将未经加工或简单堆砌的原始数据直接提供给业务方使用。这无异于将未经清洗、切割和烹饪的生鲜食材直接端上顾客的餐桌，不仅难以消化，更潜藏着安全风险。数据中台所扮演的角色，正是一个现代化、标准化的“中央厨房”，它的核心价值在于，通过对数据的统一采购、清洗、加工...

在数字化转型深入发展的2025年，传统数据中台在数据消费端面临的核心矛盾日益凸显：业务人员迫切需要数据驱动决策，但“人找数”的复杂流程构成了难以逾越的技术鸿沟。尽管数据中台在数据集成、治理和管理方面取得了显著进展，但最终用户访问数据仍需经过复杂的报表定制、SQL编写或仪表盘配置等专业技术环节。这种“...

在数字政府建设迈向深水区的今天，“数据孤岛”依然是横亘在政府高效治理与公共服务优化面前的巨大挑战。各部门、各层级的数据系统如同一个个独立的“信息烟囱”，数据无法顺畅流动，其潜在价值难以被有效挖掘。在此背景下，政务数据共享交换平台不再是一个可有可无的技术工具，而是成为了驱动政府数字化转型的核心基础设施...

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