NOAH · 数据演进
↓ 滚动 / 方向键翻页
诺亚集团 · 数据体系 · 2026 年 6 月

从数据流转 到数据服务

诺亚数据体系建设的五次关键演进 —— 一部把「业务距离」逐步缩减至零的进化史

诺亚数据体系的建设现状、当前能力与演进方向。

5
关键演进
14
核心业务域
71
白名单视图
1/3
全员日活渗透
诺亚集团 · 数据体系建设现状与演进能力 · 统计口径截至 2026-06-16
诺亚业务与数据复杂度

我们承接的,是怎样一摊业务?

诺亚是横跨多产品、多区域、多前台的全球财富与资产管理集团。把复杂业务系统与流程抽象成四层 —— 每一层都在持续产出数据,也意味着如果没有统一底座,后续分析很容易各算各的。

前台客户与触点个人/机构客户理财师开户 App/iCRMKYC 审核客户服务/陪访会员权益
业务产品与服务财富(公募·二级私募·一级股权·结构化·定存)资管(募集·净值·托管)保险(国内·港·新·美)信托/家族传承身份规划/移民
支撑经营中后台营销运营(活动·线索商机·触达)交易结算(收单·签约·清算)资金账户(统一账户·对账·现金宝)风控合规(反洗钱·监控)组织 HR
平台技术中台业务网关消息/搜索/营销/公募/存续中台全球电子合同平台数据体系

部署横跨 国内 + 香港 · 新加坡 · 美国 多区域;每个系统都是一个数据源。

这么宽、这么碎的业务,全部沉淀为数据 —— 抽象成 14 大核心业务域,正是数据体系要统一采集、建模、服务的对象。这,就是「让数据离业务越来越近」要跨越的距离。
当前数据体系总体架构

当前数据仓库架构:一仓多引擎

业务沉淀的数据,落在以 MaxCompute 为核心的数仓上 —— DataWorks 开发调度、分层加工,再经 ADB / Hologres 回流到 DataATM 和 Tableau 等消费入口。下一阶段,DataATM 还会通过受控 API 在 ADB 创建专用编辑表,让业务反馈也进入同一条可治理链路。

源数据源交易系统RDS MySQL埋点主数据/维表API/文件国内 + 海外(HK·SG)
采集采集接入DataX 离线同步企微智能表调度触发
引擎计算引擎(核心)MaxCompute / ODPS按 ODS / DW / ADS 分层组织国内区域部署
加工分层 + 开发调度ODS→DWD→DWS·DIM→ADSDataWorks开发 / 生产环境隔离
服务回流、组合与交互ADB / Hologres / CRM 回流ADB 可写业务物理表(ATM 接口建表 / 写表)查询时表关联:数仓宽表 + 业务录入表小诺看板:运行时取数 · 受控编辑(建设中)
引擎 MaxCompute / ODPS  ·  分层 ODS→DWD→DWS/DIM→ADS  ·  调度 DataWorks  ·  回流 Hologres / ADB  ·  区域 cn-shanghai
一张图看全貌

从业务数据到 AI 消费的端到端链路

外部看诺亚数据体系,最重要的是先看清五层:业务与数据源、采集与治理入口、数仓建模底座、数据服务层、AI 与业务入口。现在不只有数据向外服务,业务在小诺里补充的判断也将通过受控写入回到数据服务层。

1业务与数据源
客户触点
交易系统
产品系统
营销运营
组织 HR
低代码表单
企微智能表
文件 · API
海外业务系统
2采集与治理入口
离线同步
手工数据标准化入湖
调度接入
数据质量校验
权限与审计
3数仓建模底座
贴源层 ODS
明细层 DWD
汇总 · 维度层 DWS/DIM
应用层 ADS
横切:统一口径 · 主题宽表 · 元数据 · 血缘
4数据服务与 BI 消费层
ADB / Hologres 回流承载
BI 入口一:Hologres → Tableau
BI 入口二:DataATM
DataATM 底座
数据源 · 模型 · 视图 · 权限
查询时表关联两张物理源表即时 Join · 不落结果表
业务 API运行时查询 · 受控写入(建设中)
DataATM MCP取数 + 权限裁决
DataATM Plugin对 Claude 封装
推送服务企微群 / 邮件 / 大图
5AI 与使用入口
链路 1 · 问数
Claude 企业版 / 个人版
DataATM Plugin
自然语言问数
链路 2 · 小诺看板
Skills 生成页面
运行时直连 DataATM
同屏查看 + 编辑回写可写闭环建设中
治理闭环读写权限统一口径血缘追溯质量校验软删与审计发布门禁
架构正在从单向消费升级为 数据流、服务流、治理流、业务反馈流 四流闭环:数仓宽表与可写业务表都是真实数据资产;ATM 在查询时即时 Join,但不再生成第三张关联结果物理表。
先约定几个词

一分钟术语速查

后面会反复出现这些词,先一句话讲清,非数据背景也能跟上。最关键只要记住三件事:视图是业务看到的数据入口,口径保证同一个数,血缘负责追根因。

数仓分层ODS→DWD→DWS/DIM→ADS:源始数据逐层清洗加工,到可直接用的指标。
宽表把多张表融合成「一行覆盖一个主题」的大表,一次建设、多次复用。
视图 viewDataATM 上对外开放的一张可查询表,数据门户、看板和问数直接用它。
回流把数仓算好的表同步到 ADB/Hologres,供 DataATM、Tableau 等消费入口使用。
血缘一个数从哪张源表、经哪段加工算出来的全链路,可追溯。
口径一个指标的统一定义(算法/过滤),保证「同一个词、同一个数」。
MaxCompute阿里云的大数据计算引擎(ODPS),国内数仓的主引擎。
DataATM自研统一数据服务底座:数据源、模型、视图、表关联、数据准备、权限、业务 API、看板、问数与推送都在这。
Agent用自然语言完成任务的 AI 助手(这里指问数、运维)。
plugin把团队经验/规则打包给 Agent 用的能力包。
双云布局 · 按区域分置

国内 阿里云,海外 AWS

Noah 的数据底座按区域采用双云布局:国内(大中华区)运行在阿里云,海外(新加坡)按 AWS 目标架构建设,并通过 dbt + Dagster PoC 验证建模与编排链路。两地独立部署,但分层、治理和服务方法论保持一致。

维度
国内 · 阿里云
存储 / 计算
MaxCompute / ODPS + ADB / Hologres 回流
开发 / 建模
DataWorks
分层
ODS → DWD → DWS · DIM → ADS
调度
DataWorks 调度
环境 / 状态
schema-suffix _dev/_prod
对外服务
BI 双入口:Tableau + DataATM(数据门户/看板/问数/推送)
区域 / 合规
国内区域部署
国内 cn-shanghai · MaxCompute + Hologres/ADB + DataWorks  ·  海外 ap-southeast-1 · S3 + Redshift Serverless/Spectrum + Glue Catalog + dbt + Dagster
海外侧已在 DuckDB PoC 跑通 dbt ODS→DW 建模与 Dagster 资产调度;生产化的下一步是切换 Redshift adapter,并将 Sling/DataX→S3→Redshift 接入链路纳入统一编排。
Tech Spec

一页技术规格

给技术读者的速查:引擎、分层、调度、回流、服务接口、治理,一表看清诺亚数据体系的技术底座。阅读时抓三点:算在哪里、服务给谁、如何保证可信。

计算引擎
国内 MaxCompute / ODPS(cn-shanghai)· 海外 S3 + Redshift Serverless / Spectrum + Glue Catalog(ap-southeast-1)
数仓分层
国内 ODS → DWD → DWS / DIM → ADS· 海外 PoC ODS → DW,AWS 目标 ods → dwd → ads → marts
开发调度
国内 DataWorks · 海外 dbt + Dagster(建模与资产编排,DuckDB PoC 已验证,Redshift 生产适配中)
回流 / 承载
Hologres / ADB / CRM;Hologres 直接支撑 Tableau
服务平台
DataATM:数据源 → 模型 → 视图 → 表关联 / 数据准备 → 权限 → 看板 → 推送
读取接口
DataATM MCP(13 个只读 Level-2 工具,OAuth)+ DataATM Plugin(Claude 问数)· DataATM API(小诺看板运行时查询)
业务写接口
Writable Dataset(建设中):受控 schema → ADB 专用表 → ATM 元数据注册 → 权限 / CRUD / 软删 / 审计;不允许前端传任意 SQL
开放视图
71 张白名单视图(集中登记于 view-registry)
血缘 / 口径
全链路血缘 view → 模型 → 回流表 → ODPS · 口径单点定义
治理
行列级权限(系统层裁决)· 质量校验(DQC)· 发布门禁 · 环境隔离 · 审计
使用规模
日 PV ~1.6w · 日 UV ~600(约 1/3 员工)
统计口径
截至 2026-06-16,用于本次汇报材料口径说明
核心问题

如何让数据离业务越来越近?

过去几年只在回答这一个问题。答案不是一次技术升级,而是五次连续演进——从采集、宽表、推送、DataATM 到 AI,每一步都把数据与业务之间的距离压缩一截。

📥
数据采集
Manual → Auto
让有价值数据入湖
🧱
宽表建设
Warehouse as Product
14 域 · 663 字段
📨
数据推送
Data at Hands
数据→指标→洞察
🛰️
DataATM
统一服务平台
1.6w PV · 600 UV
🤖
AI 时代
问数 + 动态看板
获得结论 · 反馈回流建设中
这不是单纯的技术升级,而是从数据进入体系、结论走向业务,再到 业务反馈重新成为数据 的连续进化。
演进一 · 让多源业务数据进入统一体系

打破「唯系统论」的执念

如何让更多业务数据,而不只是「有系统的数据」,进入数据体系?

理想是所有数据自动入仓;现实是高价值数据散落在业务侧的 Excel、低代码表单、企微群里。核心矛盾是 业务敏捷性 与 数据规范性 的平衡。我们的解法是连续三次降低入湖门槛:

第一次
手工上传数据库
业务 Excel → 分析师建表 → 标准导入流程。临时数据设置生命周期,避免长期失控。
→
第二次
低代码平台
业务自建表单 · 低代码建模 · 落库即可分析,免分析师介入。
→
第三次
企微智能表打通
DataATM 在企业微信建智能表,业务直接手工录入 → 定时同步 ADB → 自动入仓。把「手工录入」变成一条标准入湖通道。
数据采集不是只让「有数据源的系统」进来,而是让 「有价值」的数据 都能低成本进入数据体系。
演进二 · 建设面向业务主题的数据资产

数据资产是「长」出来的,不是规划出来的

数据进来了,如何被高效、可信地使用?

沉淀 14 大核心业务域,统一在 DataWorks / MaxCompute 上按 ODS → DWD → DWS / DIM → ADS 分层建模:

客户 主档·持仓·关系
交易 确认·净申赎
创收 理财师业绩
员工 主档·3R
产品 私募主档
积分 诺贝
过程 服务覆盖
正行 ZX
Olive 资管全球
国内 ARK
香港/新加坡 Office
在线财管
Glory 信托·保险·身份规划
美元全委
真实样例 · 一张宽表怎么长出来

客户基础信息主题宽表

粒度:一行一个客户。把客户主档、标签、会员、KYC、资产持仓等多类维表和明细融合成一张主题宽表。
一张表覆盖会员等级、客户分层、城市、归属团队、适当性、资产规模、开户时点等信息,回答 80%+ 客户类基础问数。

14
核心业务域
663
最大宽表字段
80%+
单域覆盖的分析需求
统计口径截至 2026-06-16
口径统一(CRM/Finance/HR 一套)+ 线上线下统一 + 质量校验。最大挑战是 字段生命周期管理:元数据体系 + 使用监控,让宽表持续生长又不失控。
演进三 · 从被动看数到主动推送

克服数据消费的最大障碍 —— 「习惯」

数据资产有了,但业务真的在使用吗?
第一阶段

业务主动查看

建看板、等业务来看。被动,依赖使用者自觉。

第二阶段

主动推送体系

把数据送到业务每天已在用的渠道:企业微信群 / 邮件 / 看板大图 / 管理驾驶舱。从「人找数据」变「数据找人」。

推送价值的三级跃迁

数据
原始数值
→
指标变化
同环比、趋势、异动
→
业务洞察
该做什么决策

支撑:DataWorks DQC 质量规则(唯一性/空值/行数)+ 企业微信机器人告警订阅,异动自动触达责任人。

最好的数据平台,不一定是最强大的,而是 业务已经在使用的平台。数据不被使用,就没有价值。
演进四 · DataATM 统一数据服务平台

从数据服务中枢,继续进化为业务交互底座

ADB / Hologres 承接数仓回流,DataATM 把数据组织成可治理的数据源、模型和视图。小诺本期补齐可写数据集,并用查询时表关联读取人工反馈;数据准备继续服务复杂、周期性的物化加工,不进入逐条保存链路。

🗂️

数据资产

数据源 · 模型 · 视图 · 模板

🔄

数据同步

ADB · Hologres 回流

🧩

表关联 / 数据准备

查询时 Join / 周期性物化加工,按场景分工

📊

门户 / 小诺看板

同口径展示,运行时直连 ATM

📨

数据推送

企业微信群 · 邮件 · 看板大图

🔐

权限与审计

读写权限 · 行列治理 · 操作留痕

🔌

读取接口

MCP / Plugin / 业务查询 API

✍️
建设中

可写数据集

受控建表 · CRUD · 自动注册数据资产

承载 9 大 BU 看板同口径运营:Olive 资管全球 · 正行 ZX · 国内 ARK · 香港 Office · 新加坡 Office · 在线财管 · Glory(信托/保险/身份规划)· 集团创收。

1.6w
日 PV 稳定
600
日 UV(约 1/3 员工)
71
白名单视图
统计口径截至 2026-06-16
当前 数据源 → 模型 → 视图 → 权限 → 查询  ·  在建 受控 schema → ADB 专用表 → 元数据注册 → 查询时表关联 → 编辑回写
DataATM 的下一步不是再做一个孤立入口,而是把 权威数据、人工反馈和 AI 交互 放进同一个可治理底座。
演进五 · AI 时代的数据服务升级
厘清 AI 时代的边界

Agent 是新交互,DataATM 是真底座

误区

「有了 Agent,就不需要数据平台了」—— 以为自然语言能直接替代建模、权限和口径。

真相

Agent / Skills 只是交互与生成入口:负责听懂需求、生成页面、组织结论;权威数据、业务写入与治理必须由底座承载。

底座的四件事 —— Agent 替代不了

🔐

权限

行列级权限按用户身份实时裁决:同一个问题,不同人能看到的客户/字段不同。Agent 不能自行放权,必须回底座问「这个人能看什么」。

📐

指标口径

标准创收、净申赎、服务覆盖率… 每个指标只有一套权威算法。Agent 取底座固定口径,不自己拼 SQL 重算,避免一人一个数。

🔗

血缘

view → 模型 → 回流表 → ODPS → 上游 全链路可追溯。数对不上时能定位断在哪层。Agent 本身没有血缘记忆。

✅

治理

质量校验、发布审批、版本隔离,以及专用编辑表的字段校验、软删和审计 —— 读写都必须可信。

Agent / Skills / 小诺 交互层 — 听懂需求 · 生成页面 · 展示结论 · 提交业务反馈可演进
↕   MCP = 只读问数 · DataATM API = 查询 / 受控业务写   ↕
DataATM 能力层 — 权威数据 + 读写权限 + 口径 + 表关联 / 数据准备 + 血缘 + 审计真底座
边界必须清楚:Agent 和前端都不直写 SQL、不修改数仓宽表;业务录入只经登录态和权限校验写入 ADB 专用编辑表,再由 DataATM 组合与发布。
演进五 · AI 能力如何组织
MCP · 连接　Skills · 能力　Agent · 执行

AI 系统之三层结构

Agent 负责理解目标与执行任务,Skills 把复杂经验封装成可复用能力,MCP 在权限边界内连接数据库、接口、工具和企业系统。

A
Agent 决策和执行
负责决策和执行
自动拆任务 · 调用能力
自动任务
调用能力
完成目标
↓
S
Skills 能力封装
负责能力封装
把复杂能力变成可复用模块
包装
模块化
重用
↓
M
MCP 连接世界
负责连接外部世界
包括数据库 · 接口 · 工具 · 系统
数据库
接口
工具
系统
🗄️外部系统数据库
🔌外部系统API 接口
🛠️外部系统工具
🏢外部世界企业系统
MCP 是连接,   Skills 是能力,   Agent 是执行
演进五 · 企业数据 Agent 中台
A 端统一运行栈 · 共享模型与数据底座 · 权限与审计贯穿

数据 Agent 总体架构

当前体系聚焦 A 端内部员工与各 BU。真实 Agent 从统一应用入口进入、由 Engine 执行;未来通过 Skill Hub 统一管理各 BU 自有 Skills 与公共 Skills,再经 Shared AI Core 和 DataATM / MCP Gateway 访问模型与数据。

A 端 · 内部员工 / BU宽权限 · 深度推理 · 内部 VPC
① AI 应用与真实 Agent已在用能力优先呈现
小诺问数Glory · Olive · 正行 · 在线财管 · HR · 营销
Claude 企业应用DataATM Plugin · 标准口径问数
AI 驾驶舱Skill 生成 · ATM 取数 · 可写回填建设中
数据平台运维 AgentDataWorks Ops · DataATM Ops · DQC / 权限
专题分析 / 建模客户 · 持仓 · 交易 · 收入 · 血缘
② Skill Hub · 各 BU Skill 管理平台未来能力 · 建设中
各 BU Skills 专区
公共 Skills 货架
注册 / 发布 / 版本 / 质量
每个 BU 维护自己的领域 Skills 与 Owner;共性能力沉淀为公共 Skills。Agent 按 BU 身份加载本 BU Skills + 获准的公共 Skills
③ Agent Engine · 接入调用层统一执行框架
业务接入
能力封装
计划 / 路由 / 执行
④ Shared AI Core · 模型与上下文共享核心员工 / BU 按身份、权限、脱敏与审计隔离
LLM 统一调用
模型路由 / 故障降级
上下文记忆 / 敏感信息保护
预算控制 / 日志审计
⑤ DataATM / MCP Gateway · 数据统一通道统一身份鉴权 + 行列权限 + 全链路 Trace
A 端鉴权区 · 员工 / BU 身份DataATM 表与行列权限 · MCP / API 按授权可见 · 高风险写操作受门禁
统一鉴权框架 · 链路熔断 · 调用限额 · MCP Tool Audit · DataATM Query Replay
⑥ 商用大模型 · LLM Providers统一网关接入
Claude 企业版DeepSeekGemini通义 Qwen
MCP 数据源 · Data & Enterprise Resources国内 / 香港 / 新加坡分区部署
DataATM标准视图 · 指标 · API
DataWorks / MaxCompute国内数仓 · 调度 · DQC
海外数仓dbt + Dagster · AWS 新加坡
ADB / Hologres查询服务 · 可写业务表
知识库 RAG制度 · 业务知识 · 口径
企业系统CRM · ERP · 交易 / 产品
A 端请求 / 执行链模型调用链数据 / MCP 调用链
这一页只呈现当前 A 端企业 Agent 架构:谁在使用哪些 Agent、能力如何被管理和执行、模型与数据从哪里接入。运行观测与持续改进在下一页独立展开。
演进五 · 一次任务如何完成
六大角色协同 · 20 步拆解

AI Agent 运行全流程 · 20 步拆解

从用户提问到结果返回 · 六大角色协同:用户 · Agent · Skills · LLM · MCP · 工具。请求逐层下行,结果沿同一条链路回传。

用户
智能体 (Agent)
Agent Skills
大模型 (LLM)
MCP
工具
1用户提问 (Query)
2Agent 接收请求
3历史对话 / 记忆检索
4LLM 意图识别与任务拆解
5生成执行计划
6Agent 接收执行计划
7判断是否需调用 Skills / 工具
8路由到匹配 Skill
9Skill 读取上下文与能力配置
10Skill 组织调用策略与参数草案
11LLM 补全具体调用参数
12Agent 通过 Skill 发起调用
13MCP 工具发现与选择
14MCP 调用具体工具 API
15工具执行具体任务
16MCP 接收工具执行结果
17Skill 解析 / 校验 / 格式化
18Agent 整合结果与上下文
19LLM 生成最终回答
20Agent 向用户返回结果
请求下行结果回传顺序以步骤编号为准
演进五 · Agent 运行观测与持续改进
Langfuse · MCP Audit · DataATM Replay

从运行观测到受控持续进化

Agent 做完任务只是起点。Langfuse 负责 LLM 运行 Trace,MCP 审计补全工具与数据访问路径,DataATM 查询日志支持结果回放;三类证据共同驱动评估、样本沉淀和下一版受控发布。

1已在用

生产运行

用户 → Agent → Skills / MCP → 工具 → 结果

2已在用

Trace 观测

输入输出 · 工具调用 · 模型 · 延迟 · Token / 成本 · 错误

3建设中

质量评估

任务成功 · 工具选择 · 事实一致 · 安全合规

4部分已用

失败归因

错误模式 · 根因定位 · 成本异常 · 质量漂移

520 条起步

样本沉淀

Golden Dataset v1 已有 20 条;失败 Trace 自动回流与 Annotation 待补

6建设中

改进与门禁

Prompt · Skill · Recipe · 规则改进;回归通过后受控发布

Langfuse · Agent 运行证据中心
Tracing 已在用 · Golden Dataset v1 已有 20 条 · Scores / 自动评估待补
Langfuse Trace / GenerationMCP Tool AuditDataATM Query Replay
运行健康调用量 · ERROR observation · P50/P95 延迟 · Token / 成本 · 模型分布
过程质量选择了什么 Skill / Tool / View · 参数是否正确 · 卡在哪一步
业务结果是否回答问题 · 是否有事实依据 · 是否安全 · 用户是否纠正或复用

小诺 Langfuse · 近 7 天观测样本

116Traces
8Agent modes
17用户
0Scores

2026-07-04 18:00—07-11 18:00 · Asia/Shanghai。8 为 mode tag,不等于 8 个独立服务;Score=0 暴露出“能看见、尚未形成统一质量闭环”的缺口。

统一 Trace Contract · 建设中　agent / skill / prompt / model version · trace_id / session · data view · tool spans · output · latency / token / cost / error · user feedback
这里描述的是 Agent 运行观测与持续改进闭环,不是额外建设一个独立平台。所谓进化也不是 Agent 在线自行改写自己,而是失败样本驱动、人工校准、回归评估和发布门禁后的受控升级。
演进五 · 两类业务入口

从「获得数据」彻底跨越到「获得结论」

问数路径被整条压平:过去要排队找人写 SQL,现在 Claude 企业版/个人版通过 DataATM Plugin 获得自然语言问数能力;真正取数由 DataATM MCP 执行,并继承 DataATM 的表权限和行列权限。交互变简单,底层治理不放松。

过去
自助问数 → 找数据团队
人工统计 / 对账
写 SQL → 交付结论(按天)
现在
Claude → DataATM Plugin → 自然语言问数
DataATM MCP → 权限裁决 → 标准口径取数 → 结论(按秒)
宽表 = Agent 理解业务的语义层

底层:DataATM MCP 封装查询、维度拆解、排名、周期对比等能力;DataATM Plugin 提供给 Claude 企业版/个人版使用,表权限和行列权限由 DataATM MCP 按 DataATM 底座统一裁决。

把 「数据查询引擎」升级为「业务分析服务」:宽表正式成为 Agent 理解业务的基础语义层。
演进五 · 第二类业务入口
V1 / V2 已完成 · V3 建设中

小诺看板:从 Skills 生成到动态可编辑

这不是再做一张看板,而是同一个看板连续三次进化:AI 先生成页面,页面再运行时直连 DataATM,下一步让需要人工录入的业务数据也留在同一入口,并与数仓宽表即时关联。

✨
V1 · 已完成

AI → Skill → 看板

AI 按业务需求生成 Skill,再由 Skill 生成页面结构、指标卡和交互。

🔌
V2 · 已完成

看板运行时直连 ATM

AI+业务样例直接查询 DataATM 视图 3953,筛选、排序和分页都走 ATM。

✍️
V3 · 建设中

同屏查看 + 编辑回写

ATM 接口在 ADB 创建并写入通用业务表;看板查询时再与数仓宽表即时关联。

当前示例 · AI+业务服务记录

现有页面已经有同屏「服务记录」编辑器,但保存仍停留在浏览器内存,尚未接入 ADB 持久化、查询时表关联和回读链路。因此直连读取版已可用,动态可写闭环仍在建设。

小诺正在从「只能看」的消费端,升级为 看结论 → 补判断 → 沉淀行动 → 继续分析 的业务闭环入口。
演进五 · 第三类业务入口
从响应式问数到主动式洞察

异动洞察:让数据主动找到人

问数解决“我想知道什么”,动态驾驶舱解决“我如何查看并补充判断”;异动洞察再向前一步,由每个 BU 定义自己的监控规则 Skill,系统持续看数,只有命中异常时才主动提醒并给出解释。

自助问数 · 人找数用户提出问题 → DataATM 即时取数 → 返回结论
动态驾驶舱 · 人看数查看结果 → 补充业务判断 → 回写并继续分析
异动洞察 · 数据找人定时巡检 → 命中规则 → 解释原因 → 主动提醒
定义 BU 规则 Skill指标、基准周期、阈值、归因维度、行动规则和通知对象。
AI 结构化规则把自然语言整理为组合条件,由业务用户确认后再执行。
DataATM 权限取数按员工 / BU 身份读取最新数据与对比期,继承行列权限。
AutoInsights 检测趋势检验、变点检测、离群分析和维度归因。
LLM 归因与建议结合业务知识解释原因,判断风险等级并生成行动建议。
试跑与历史回放查看触发频率、结果准确性和通知预览,再确认启用。
定时启用与通知数据就绪后运行;仅命中时通过企业微信 / 站内消息触达。

每个 BU 拥有自己的 Skills BU OWNED

BU 负责业务语义:监控哪张视图、哪个指标、用什么基准和阈值、沿哪些维度归因、命中后采取什么行动以及通知谁。

平台提供共享能力 SHARED CAPABILITY

公共能力统一复用:Skill Hub 注册与版本、DataATM 权限取数、AutoInsights 统计算法、模型调用、调度通知、执行记录与审计。

原型已具备小诺已有异动洞察入口与任务交互;AutoInsights 真实统计算法引擎已经存在。
生产闭环建设中真实 DataATM 数据接入、LLM 归因、调度执行、消息投递和运行审计尚需打通。
这是从“回答问题”到“持续关注问题”的升级:Agent 不只在用户提问时工作,还会按 BU 规则长期巡检,在真正需要关注时主动出现。
演进五 · 第三类业务入口演示
小诺 Finance Alert Demo

异动洞察 Demo:从监控命中到主动提醒

这页用于把“数据主动找人”的概念落到实际交互:系统持续监控指标变化,命中规则后生成提醒、解释原因,再把用户带回小诺处理现场。

监控对象围绕金融业务指标设置巡检规则,由系统定时识别异常变化。
触发方式不依赖用户主动提问;只有达到阈值或命中异动逻辑时才推送。
处理闭环提醒不是终点,后续还要进入解释、追问、归因和行动记录。
定位:这是异动洞察的交互原型,后续生产闭环需要继续接入 DataATM 真实取数、规则配置、调度执行和审计记录。
这类 Demo 的价值是把 Agent 从“问答入口”拉到“运营入口”:系统主动发现变化,人只在需要判断和行动时介入。
演进五 · 看板的第三阶段
通用升级概念 · 不为单一场景写死

看板再进化:从「只读展示」到可写、可关联

升级的核心不是增加一张“服务记录表”,而是让 ATM 具备通用可写数据表能力。以后由 Skills 生成的看板,既能读取数仓数据,也能承接业务人工录入,并在查询时把两类数据组合起来。

✨
生成

Skills 定义交互

AI 生成看板结构;用户确认展示样式、业务主键以及需要人工编辑的字段。

✍️
写入

ATM 通用可写业务表

ATM 根据受控 schema 在 ADB 创建物理表、注册数据资产,并通过统一接口持续写入。

🔗
关联

查询时即时组合

数仓宽表与可写业务表即时 Join;只返回查询结果,不落第三张物理表,不触发数据准备全量重写。

举例 · AI+业务服务记录

保存服务记录时写入集团号和服务时间;列表查询时再按集团号关联客户宽表,用最近一次服务时间补充客户状态。这是通用能力的首个示例,不是产品能力的边界。

可复用: 客户跟进问卷回收人工标签活动报名业务备注补充审批信息
看板由“AI 生成的数据消费页”升级为 AI 生成、业务参与、数据持续回流 的动态工作入口。
当前能力 + 正在建设

同一个底座,从「能看」走向能看、能问、能反馈

一个 DataATM 底座承载六类能力 —— 看与录、问、组、推、管、追治。Tableau 仍作为 BI 入口直连 Hologres;小诺则继续向动态业务入口演进。

📊

看与录

DataATM 门户 + 9 大 BU 看板 + 小诺;直连读取已用,同屏编辑回写建设中

💬

Claude 问数

Claude 企业版/个人版使用 DataATM Plugin;DataATM MCP 负责取数与权限裁决

🧩

表关联 / 数据准备

小诺用查询时 Left Join;复杂、周期性的清洗加工再使用数据准备

📨

推送

企业微信群、邮件、看板大图发送:数据 → 指标变化 → 业务洞察

🔐

权限与审计

读取按行列裁决;业务写入按表和字段授权,记录创建人、修改人和时间

🔗

血缘与治理

口径统一、质量校验、视图到源表可追;新增业务反馈也有来源和责任人

已具备:门户 / 看板读取、Claude 问数、表关联、数据准备、推送、权限、血缘治理。建设中:ATM 通用可写数据表 + 小诺同屏编辑闭环。

同一个底座既服务「机器算好的数」,也开始承接「人补充的判断」 —— 一次建设,多个业务场景复用。
对业务的价值

对业务,意味着什么

数据体系的价值不在技术本身,而在它能否让结论进入行动、让行动结果重新进入数据。

⚡

效率

从「排队等取数」到「秒级自助拿结论」,问数路径整条压平

📐

口径

全公司同一套口径,不再「一人一个数」,对账成本大降

🛡️

风险控制

行列权限 + 血缘可追 + 质量校验,数据可信、可控、可审计

🔁

决策闭环

在同一看板看结论、补判断、记行动;反馈再与宽表组合,继续分析

一句话:让对的人,在对的时间,拿到可信的数,并把业务判断沉淀成下一轮可复用的数据。
未来方向

从数据平台,走向智能数据服务

下一步不是让 AI 多生成几张静态页面,而是把「页面生成—实时取数—人工反馈—数据再组合」沉淀成可复制的产品能力。

现在
AI 生成 + 实时读取
Skill 生成小诺页面;看板运行时直接查询 DataATM
→
进行中
ATM 通用可写数据表
样式 / schema 确认 → 自动建表 → 权限审计 → 查询时表关联
→
未来
动态业务闭环
AI 给结论、业务补判断、系统沉淀行动并持续复用
小诺不再只是看板链接,而会成为 数据与业务双向流动的工作入口 —— 这才是智能数据服务的下一站。
终局

无限逼近的「零距离」

0
❄️ 冰冷的
数据流转
— 距离 →
🔥 火热的
业务决策

我们过去几年做的所有事情,本质上只在一个维度上努力:缩短数据与业务之间的距离。
而今天,AI 让这段距离趋近于零。

诺亚数据体系 · Data · Insight · Value
Appendix Navigator

附录可以按问题直接跳转

主线讲完后,可按问数、排查、数仓建设、ATM 资产上线、血缘、权限等问题直接跳转。附录重点回答“真实怎么做、边界在哪里”。

🧭
入口

四类数据管家

先用一页讲清“谁用什么能力、边界在哪里”。

 💬
① 问数

自然语言问数

解释 DataATM Plugin 如何把视图、权限和口径封装给 Agent。

 🔍
②a 排查

只读查询排查

当问数答不够时,分析师如何继续查明细和追血缘。

 🏗️
②b 建设

受控仓库建设

建表、发布、补数、回流为什么必须走门禁流程。

 🚀
ATM 交付

DataATM 运维上线

数据源、模型、视图、权限如何从配置变成可复现交付链。

 🔗
共享底座

全链路血缘

从用户看到的视图一路追到数仓加工表和源系统。

 🛡️
技术底座

读写分工与护栏

把 AI 接到底座,同时确保生产写变更仍然受控。

 🔐
权限

角色权限模型

解释不同角色能装哪些能力、为什么不能越权。

 🏁
总结

核心领悟

回到结论:前四次演进构成 AI 时代的数据基础设施。
使用方式:主讲时不用逐页讲附录,根据现场问题直接点对应卡片。
附录 · 四类数据管家能力

沉淀专家经验,打造专属「数据管家」

「数据管家」不是一个万能机器人,而是把数据团队的经验拆成四类可控能力:问数、排查、数仓建设和 ATM 产品上线。越靠近写操作,环境、权限、差异和回滚门禁越严格。

💬
业务问数

业务同事用

自然语言查已开放视图;权限、口径和行列裁决回到 DataATM 底座。

🔍
分析排查

分析师用

下钻明细、查口径、追血缘;只读排查,不直接改生产数据。

🏗️
仓库建设

数仓工程师用

探源、建表、发布、补数、回流走 DataWorks 受控流程。

🚀
ATM 交付

平台管理员用

通过 Admin API 交付数据源、模型、视图、权限和查询验收。

一句话

把“谁能看、谁能查、谁能改、怎么追根因”做成可执行规则,而不是靠人记。

共同底座

四类能力都共享同一套权限、口径和血缘,所以问数、看板、排查不会各算各的。

安全边界

问数和排查默认只读;ATM 资产写经 dry-run 和回读;数仓生产写仍经审批与质量门禁。

附录 · ① 问数(实现)

DataATM Plugin:自然语言问数的语义层

把 71 张白名单视图的业务口径沉淀成可复用的能力体系。Agent 自然语言进、权威口径出 —— 口径、权限、路由和取数统一受控。

输出输出层报告生成图表生成分析结论 → 看板/文档
编排编排层跨视图归因多指标组合分析
领域领域能力层收入客户主档/持仓交易服务过程国内业务香港/新加坡业务在线财管资管信托/保险/身份规划
底座执行底座问题路由工具选择日期策略错误恢复
只读数据服务能力
模型查询业务域查询产品查询模板查询指标查询维度拆解排名分析周期对比口径解释视图目录受控导出
机器可读 · 唯一事实源
视图目录业务域权限规则指标口径库语义映射
真实案例 · 一次问数

用户问「按区域看今年收入排名」→ 系统识别业务域、指标和维度 → 自动匹配白名单视图与标准口径 → 秒级返回各区域收入排名,口径与看板完全一致。

同一批视图,既供前台人工用、也供 Agent 调用。口径、权限、取数统一收口 —— 这就是「数据查询引擎升级为业务分析服务」的落地形态。
附录 · ②a 查询排查(实现)

查询排查 Plugin:数据团队的只读探针

面向有明细数据读权的分析师:标准查询、血缘追溯、稳定导出。只读访问,不执行生产写变更 —— 是 ① 问数答不出时往下钻根因的兜底层。

底座查询排查底座只读硬边界工具优先级路由错误恢复
查数标准查询导出明细查询小样本验证受控导出
血缘血缘追溯任务与表关系搜索加工逻辑反查追根因 → 回填底座
工具稳定性优先级

正式导出、小样本验证、口径查询和备选查询工具按稳定性分层使用,避免分析过程依赖单一入口。

只读纪律

仅允许只读查询;临时数据设置生命周期;涉及建表、发布、补数等写动作必须转入受控建设通道。

真实案例 · 一次排查

业务反馈「某类收入指标对不上」→ 查询标准明细与口径链路 → 追溯上游数据加工过程 → 定位根因在源数据缺失、映射规则或加工链路中的具体环节。排查通道只给结论,不直接改数。

排查过程中沉淀出的表关系、字段来源和口径解释会回填共享底座 —— ②a 是持续补全血缘和语义资产的增量补充力量。
附录 · 数仓受控执行 · 当前 v0.6.27

DataWorks Ops:从脚本集合进化为数仓工程中台

能力已经不只是“建表、发布、补数”:它连起统一探源、批量入仓、多目标回流、DEV-first 版本核验、精确补跑、DQC 告警与临时对象收口。

6Agent 诊断编排告警→实例→日志根因定位方案生成跨项目检索
5MCP 读 / 脚本写只读探查优先高危写受控DDL / Deploy / Backfill 分阶段授权
4质量与收口DQC 实体 + 规则告警订阅发布后 Gate临时 DDL / DI 冻结审计
3建表 / 发布 / 补跑ODS→DWD→DWS→ADSDEV-firstDeployment + FileVersion + 实例版本单实例精确补跑
2入仓 / 回流 / 服务关系库→ODSODPS→ADB / Holo / MySQLADB→ODPS目标端结构联动
1统一 Schema 探源MySQL / PolarDBOracle / PostgreSQLADB / HologresMaxCompute
探源入仓Schema → ODS
DEV-first 发布三重版本核验
精确补跑Instance / DagId
DQC 与告警配置 + 实跑
回流与收口目标端 + 临时节点

发布包:0.6.27+codex.20260710161828282059 · 正在继续加固:冻结后实例硬校验、异常路径强制收口、精确 FileId / DagId、生产授权拆分与 guard 失败关闭。

闭环示例:源表探字段 → ODS / DI 生成 → 版本反查 → 绑定 DagId 补跑 → 分区核验 → 临时节点冻结审计。再配合包完整性校验和安装后回归,形成 可安装、可升级、可拦截、可审计 的工程能力。
附录 · DataATM 资产上线交付 · 本地 v0.1.0

DataATM Ops:把数据资产上线做成受控交付链

DataWorks 把物理表和调度准备好之后,DataATM Ops 继续通过 Admin / Web API 完成数据源、模型、视图、查询入口、权限与验收,让“表已存在”真正变成“用户可使用”。

DATASOURCE数据源

SQL 与参数配置
字段解析 · 行数检查

MODEL数据模型

维度 / 度量 · 口径
标签 · 敏感级别

VIEW数据视图

字段展示 · 默认筛选
行列规则 · 上下线

TEMPLATE查询模板 / 入口

templateUid 反查
submitQuery → shortUrl

ACCESS权限交付

角色 / 用户 · 字段 / 行
下载 · 模板 / 看板

VERIFY验收与审计

详情回读 · 查询冒烟
Query Log · MCP Audit

5 类运维 Skills
Admin / Web 双后端
写操作默认 Dry-run
执行后必须回读
上线交付门禁

写之前明确环境、对象 ID、payload diff、影响用户和回滚方案;写之后用详情、权限和真实查询结果复核,不把“API 返回成功”当成交付完成。

当前边界

v0.1.0 已经把对象、接口、门禁和复核 SOP 标准化;但尚未将六步收敛为单个幂等编排命令,也尚未统一上架 Marketplace。

DataWorks Ops 交付“可靠的表与调度”,DataATM Ops 交付“可用的数据产品与权限”。下一步把现有 Skills 编排成一条可幂等、可失败恢复的快速上线流水线。
附录 · 共享底座
数据管家的内核

一个共享底座,把血缘整条接通

血缘 = 一个数,从用户看到的视图,一路追到源表和加工逻辑。动态看板还会多一条业务反馈支线:人工录入来自谁、何时修改、与哪张宽表组合,同样需要可追。↓ 从上往下读:

用户看到的视图 —— 问数 / 看板直接查的那张表这条链的起点 · 例:客户主从关系视图① 问数
这张视图怎么拼出来的 —— DataATM 查询时关联两张物理源表数仓宽表 + ADB 可写业务表 · 即时 Join · 不落关联结果表ATM 组合
↓ 数仓支线追到源系统 · 业务反馈支线追到创建人 / 修改人 / 审计记录 ↓
数据从数仓回流过来 —— 同步到 Holo/ADB 的服务表面向 DataATM 查询与看板服务②b 记录
数仓里的加工表 —— 对应的主题明细或汇总表承接清洗、关联、聚合后的标准数据②b 记录
最上游的源系统表 —— 数据最初产生的业务系统交易、客户、产品、组织等源系统数据②b 记录
每个数的算法口径 —— 统一从底座术语表取,不各写各的如「标准创收」「净申赎」只定义一次共享底座
71
白名单视图登记
22
表级血缘记录
327
真实上游血缘边
9
口径单点定义
统计口径截至 2026-06-16
好处很直接:任何一个数对不上,都能顺着这条链一路追到根因;而且像「标准创收」「服务覆盖率」这种算法口径只在底座定义一次,全公司用同一个,不会一人一个数。
附录 · 技术底座与落地状态

把 AI 和动态看板接到底座,靠的是五类受控通道

问数读取、业务写入、ATM 资产发布和数仓工程变更必须分开:每一类通道都有自己的身份、授权、审计和执行后验证。

🔌
DataATM MCP / Plugin

Claude 只读问数

13 个只读 Level-2 工具 + OAuth;权限、口径、行列裁决回到底座统一执行。

✍️
DataATM API · 建设中

小诺查询 / 业务写入

结构化 schema 建表、登录态鉴权、参数化 CRUD、软删与审计;只写 ADB 专用表。

🚀
DataATM Ops · v0.1.0

数据资产上线

数据源、模型、视图、模板链接和权限通过 Admin / Web API 受控交付。

🧰
DataWorks MCP-first

运维只读接口

连通性、找文件、拉 SQL、节点依赖、调度配置、元数据血缘等读动作优先走内置 MCP,减少人工翻控制台和脚本散用。

🛡️
受控流程 / 系统拦截

高危写护栏

发布、补数据、改表、质量规则生效等写动作保留在受控通道;系统会拦截直接写生产的动作,并要求先备份、再校验、再人工确认。

读:Claude 问数、小诺查视图、查配置 / 血缘 / 调度 / 实例MCP / API
业务写:服务记录、人工标签等授权字段专用表 + 审计
资产写:数据源、模型、视图、权限和上下线Admin API + Dry-run
数仓写:建表、发布、补跑、DQC、目标端结构变更受控脚本 + 审批
验:对象回读、真实查询、版本/实例核验、质量 Gate 与日志审计闭环记录

边界结论:业务数据只写授权专用表 · ATM 资产只经管理 API · 数仓生产写仍由独立门禁锁住。

附录 · 权限模型
谁能看什么 · 谁能写什么

入口可以越来越智能,权限边界不能变模糊

Plugin 决定用户能进入哪类能力,DataATM 决定用户能读写哪些数据。可写数据集上线后,写权限会与读取权限分开授权,不会因为能看一张宽表就能修改它。

全员 / 业务无 MaxCompute 自然语言问已开放的数据;如获业务写权限,只能编辑指定专用表字段,不能改数仓宽表 问数查询排查仓库建设DataATM 建模
数据分析师有 MaxCompute 读权 再加:自己写 SQL 查明细、追血缘、导出 问数查询排查仓库建设DataATM 建模
仓库建设者数仓团队 · 仓库侧 再加:建表 / 发布 / 补数 / 回流(动生产,受红线门禁) 问数查询排查仓库建设DataATM 建模
ATM 建模者数仓团队 · ATM 侧 再加:组合数据源、建模型、开新视图,配置专用编辑表及其字段 / 写入权限 问数查询排查仓库建设DataATM 建模
关键就一句:看数权限、业务录入权限、生产建设权限是三件事。普通用户即使能在小诺录入服务记录,也碰不到数仓宽表和生产工程变更。
附录 · 核心领悟

前四次演进,构筑了 AI 时代最坚实的基础设施

AI 时代 · 问数 + 动态看板,结论与反馈闭环
DataATM · 统一数据服务中枢
数据推送 · 让数据找到人
宽表建设 · 一次建设,多次复用
数据采集 · 让有价值的数据都入湖
这几年建立的规范、治理、口径、血缘,不仅没有被 AI 取代;当业务反馈也按权限和审计进入体系后,底座会从「供 AI 读取」继续进化为 支撑人机共同工作的黄金底座。