让每一条数据都有来龙去脉：我们的列级数据血缘平台功能全景

上一篇文章《从 0 设计一个列级数据血缘模型》聊了底层设计（还没看的同学可以补课），这篇换一个视角：不讲代码，讲产品。作为一个已经支撑真实业务的数据血缘平台，它到底能帮你做什么？哪些功能是"演示级"，哪些是"生产级"？一文说清。

一、先看三个真实痛点

如果你在数仓团队或数据平台团队，下面这些场景大概率似曾相识：

场景 1：周五下午，有人要改表结构 "我要把 orders.amount 从 INT 改成 DECIMAL，会影响下游什么东西？" 没人答得上来。下游有 30 张表、200 个任务，只能挨个翻代码。

场景 2：报表数字不对，排查像破案 一个汇总指标异常，数据经过了 7 层加工：ODS → DWD → DWS → ADS。到底是哪一层出的错？工程师打开层层嵌套的 SQL，人肉画出依赖关系，半小时过去了。

场景 3：同一个指标，三个团队三个口径 "活跃用户"到底算不算小程序端？口径定义散落在无数 SQL 和文档里，没人说得清哪个是最新的。

这三个痛点的共同根源：数据之间依赖关系不可见。数据血缘平台要解决的，就是把每一条数据（精确到列）的来龙去脉变成一张可查询、可追溯、可协作的图。

二、产品能力全景

先上一张功能地图：

objectivec 复制代码

┌─────────────────────────────────────────────────────┐
│                   Esther 数据血缘平台                  │
├──────────┬──────────┬──────────┬───────────────────┤
│ SQL 解析  │ 血缘可视化 │ 元数据目录 │  协作与治理        │
│ 28 种方言 │ 列级血缘图 │ 全类型资产 │  团队/任务/动态    │
│ 自动识别  │ 影响分析  │ 术语表    │  RBAC 权限/审计    │
│ 存储过程  │ 口径展示  │ 标签/属性  │  快照/策略/质量    │
├──────────┴──────────┴──────────┼───────────────────┤
│  元数据采集（直连数据库抽取）      │  多端接入           │
│  12+ 元素类型 · 27+ 数据源       │  Web / API / CLI   │
└─────────────────────────────────┴───────────────────┘

下面逐个展开。

三、核心能力：一条 SQL 进去，一张血缘图出来

3.1 解析能力是地基：28 种方言

数据血缘产品最常见的翻车点：客户的 SQL 跑不起来。真实世界的 SQL 五花八门------Oracle 的 PL/SQL 块、T-SQL 的 GO 批分隔符、Hive 的 LATERAL VIEW、ClickHouse 的 ARRAY JOIN......

我们支持 28 种 SQL 方言，几个设计点：

自动方言识别 ：不确定 SQL 是哪种方言？粘贴进来选 auto，平台通过关键词指纹 + 多方言试解析自动判断；
存储过程支持：不只是 SQL 语句，Oracle PL/SQL、T-SQL、PL/pgSQL、MySQL 存储过程体内的 SQL 也能提取血缘，动态 SQL 会被标记出来；
复杂语法全覆盖：窗口函数、递归 CTE、关联子查询、CASE 表达式、复杂 JOIN 这些"解析器杀手"，都在自动化回归测试的覆盖之下（数千个测试用例持续守护）。

3.2 列级血缘图：精确到每一列

表级血缘告诉你"这两张表有关系"，列级血缘 告诉你"dws_order.amount_cny 这一列，是由 orders.amount 乘上 exchange_rate.rate 算出来的"。

在 Web 界面上，血缘以"表卡片"的形式呈现------每张表/CTE 一个卡片，卡片内列出涉及的列，列与列之间的连线就是数据流：

几个值得说的交互细节：

点击追踪：点击任意列，自动高亮它的全部上游和下游链路（BFS 遍历），一眼看清"这列的数据从哪来、到哪去"；
口径徽标 ：经过表达式加工的列（如 a.amount * b.rate）带一个 ƒ 徽标，悬停即可查看加工表达式，点击还会在 SQL 编辑器里高亮对应片段；
SQL 双向联动：左侧是 CodeMirror SQL 编辑器，右侧是血缘图。选中 SQL 里的某个表达式，图中对应节点同步高亮，反之亦然------图和代码永远对得上。

3.3 影响分析与溯源

血缘图的工程价值在"查"，两个高频动作：

影响分析（下游追踪）：改这张表这列之前，先查它会影响哪些下游表、哪些报表字段。图数据库（默认内嵌 Kuzu，可选 Neo4j）支持变长路径查询，N 层依赖一次拉通；
问题溯源（上游追踪）：指标异常时，从结果列一路回溯到源表，每一跳的加工表达式都摆在边上，哪层算错一目了然。

四、元数据目录：血缘的"户口本"

血缘回答"数据怎么流动"，元数据目录回答"数据是什么"。平台内置资产目录，收录 15+ 种资产类型：表、列、视图、物化视图、存储过程、函数、包、触发器、同义词、序列、索引、约束（含外键关系，可生成 ER 图）、分区、UDT......

每个资产都支持：

全限定名（FQN）标识 ：跨库不混淆，Oracle 的 ID 和 PostgreSQL 的 id 能正确对齐（各方言大小写折叠策略内置）；
标签与自定义属性 ：业务团队可以给资产打标（比如 PII、核心表），配合自定义属性扩展业务语义；
术语表（Glossary）：把"活跃用户"、"GMV"这些业务口径挂到具体列上------场景 3 的解药。

五、元数据采集：不用手填，直连数据库抽取

目录里的数据从哪来？平台的元数据采集（Ingestion）框架直连业务库批量抽取：

27+ 种数据源：MySQL、PostgreSQL、Oracle、SQL Server、ClickHouse、Snowflake、BigQuery、DuckDB 等，连接先测通再同步；
12+ 种对象类型：库、Schema、表、列、视图、存储过程、函数、触发器、索引、约束、分区、序列、同义词、包、UDT 一次抽全；
灵活过滤 ：支持按对象类型 + glob 模式两级过滤（比如"只抽 dwd 层、排除 tmp_* 表"）；
流式处理：抽取全部走 iterator，大库不爆内存；
多落地目标：一次采集可同时写入平台存储和 JSON 文件，方便二次加工。

数据源密码全程加密存储。敏感库可以走"导出 JSON 再导入"的离线模式，网络隔离环境也能用。

六、协作与治理：血缘不是一个人的事

数据血缘的价值要靠团队协作放大，这部分常被同类工具忽略，我们做全了：

账号与权限：JWT 登录 + 三级角色（管理员/编辑者/查看者）+ 细粒度资产权限，审计日志全程留痕；
团队空间：按团队组织资产与分析结果；
任务与动态流：认领治理任务（比如"补齐这张表的元数据"）、关注资产动态（谁改了这张表、谁新分析了这段 SQL）；
讨论区：直接在资产/血缘图旁边讨论口径问题，上下文不丢失；
快照与流水线：血缘结果可存快照、可编排流水线定期跑批，持续监控血缘变化。

七、多端接入：UI 之外，还有 API 和 CLI

不同角色用不同的入口：

入口	适合谁	典型用法
Web UI	数据工程师/分析师	粘贴 SQL 看血缘图、查影响面、逛资产目录
REST API	平台工程师	把血缘能力嵌进自己的 CI/CD------上线前自动分析变更 SQL 的影响范围
CLI	自动化脚本/流水线	`esther analyze --dialect auto --file query.sql` 直接出结果

全部能力走同一套 REST API（Swagger 文档内置），前端和 CLI 没有任何特权后门------你在界面上看到的一切，API 都能拿到。

八、为私有化而生

很多企业数据不出内网，SaaS 血缘工具直接出局。平台原生支持私有化部署：

交付物是编译后的原生可执行文件（Windows / Linux），不依赖客户环境装 Python；
内置离线授权机制（机器指纹绑定 + 授权文件），支持试用期管控；
全部数据落客户自己的环境，不依赖任何外部服务。

九、一个彩蛋：AI 加持

平台里埋了 LLM 能力的实验场：SQL 智能提取（从混杂脚本中抽取 SQL）和双 LLM 血缘交叉验证------用两个不同的大模型互相校验血缘解析结果，把 AI 的不确定性也纳入质量体系。这块还在快速迭代，后续单独开一篇讲。

十、总结：它在数据平台版图里的位置

一句话定位：Esther 是数据平台的"关系层"------元数据采集告诉你"有什么"，血缘分析告诉你"怎么连"，目录与协作让这些知识沉淀下来、流转起来。

markdown 复制代码

业务库 ──采集──→ 元数据目录 ──→ 血缘分析 ──→ 影响分析/溯源/治理
                     ↑                            │
                     └────── 协作·任务·术语·快照 ←──┘

如果你正被"改表不敢改、排障靠翻代码、口径说不清"折磨，欢迎交流试用。