面向数据仓库团队的轻量数据资产目录

表在哪、 字段什么意思、 口径从哪来。

DAP 把这些元数据集中到一个可搜索、可维护的界面里。内网、离线、一台机器也能跑。

打开在线演示 在 GitHub 查看

01 / 现状

这几件事，做过数仓的人都经历过。

文案草稿 · 待确认

  1. 1

    新人上手慢。一张表能不能用，要先去问人。

  2. 2

    同一指标两份口径。两张报表的「下单用户数」对不上，没人说得清谁对。

  3. 3

    人一走，知识就丢。字段含义和加工逻辑，留在离职同事的脑子里。

  4. 4

    业务问数答不准。同一个问题，换个人查，数就变了。

02 / 问资产

问资产，
不是问数。

DAP 不直接回答数字。它用可追溯的方式找出对的资产：哪张表、哪个字段、口径写在哪、数据从哪来。再通过 API 把检索和可信数据能力，交给问数等上层应用使用。

  • 只展示真实执行步骤：检索词、检索轮次、命中资产、证据来源。
  • 不展示模型内部推理。
  • AI 问答默认关闭，是可选能力。

证据链样本

一次问资产的完整执行过程

示意数据
  1. 1 / 检索词

    近 30 天下单用户数的口径是什么、从哪张表出？

    拆出的检索词

    下单用户数30天口径
  2. 2 / 检索轮次

    R1exact“下单用户数” → 命中 1

    R2keyword“下单 用户 30天” → 命中 3

    R3hybrid“下单用户 去重 口径” → 命中 1

  3. 3 / 命中的资产
    指标
    order_user_cnt_30d
    表
    dws.trade_user_stat_d
    字段
    dws.trade_user_stat_d.order_user_cnt
  4. 4 / 证据来源
    指标口径定义
    order_user_cnt_30d
    字段注释
    order_user_cnt
    血缘快照（导入于 [日期]）
    dwd.trade_order_d → dws.trade_user_stat_d

检索方式名称与接口返回字段以实际实现为准 [待核对]。表名为虚构零售演示数据。

对外 API 返回（节选）

示意数据 
{
  "question": "近30天下单用户数的口径是什么、从哪张表出？",
  "rounds": [
    { "n": 1, "mode": "exact",   "query": "下单用户数",        "hits": 1 },
    { "n": 2, "mode": "keyword", "query": "下单 用户 30天",     "hits": 3 },
    { "n": 3, "mode": "hybrid",  "query": "下单用户 去重 口径", "hits": 1 }
  ],
  "assets": [
    { "type": "metric", "id": "order_user_cnt_30d" },
    { "type": "table",  "id": "dws.trade_user_stat_d" },
    { "type": "field",  "id": "dws.trade_user_stat_d.order_user_cnt" }
  ],
  "evidence": [
    { "asset": "order_user_cnt_30d", "source": "metric_definition",
      "text": "近30天内成功下单的去重用户数" },
    { "asset": "dws.trade_user_stat_d.order_user_cnt", "source": "field_comment" },
    { "asset": "dws.trade_user_stat_d", "source": "lineage_snapshot",
      "path": "dwd.trade_order_d -> dws.trade_user_stat_d",
      "imported_at": "[日期]" }
  ]
}

上层应用拿到的，不是一句答案

而是一组带出处的资产：每一项都能回到口径定义、字段注释或血缘快照。问数应用可以据此生成查询，也可以据此拒绝回答。

接口路径与鉴权方式：[待补]

03 / 资产就绪度

用着用着，
就把资产补全了。

每个模块里有多少资产说得清楚、口径有出处，用一个百分比提示。它只是提示，用最小的代价让人知道哪里还缺。

各模块就绪度

示意数据
  • 表资产82%

    计入：有负责人和表说明

  • 字段含义64%

    计入：已填写中文含义

  • 指标口径71%

    计入：有口径文本和出数表

  • 码值90%

    计入：有码值说明

  • 报表与 API55%

    计入：已关联到具体资产 待补

  • 血缘快照38%

    计入：已导入快照的表占比 待补

百分比 = 满足条件的资产数 ÷ 该模块资产总数；低于 60% 标「待补」。以上百分比与阈值均为示意数据 [口径待确认]。

04 / 边界

它明确
不做什么

DAP 只做数仓资产目录这一件事，并且尽量让它能在内网的一台机器上跑起来。下面四件事，它不做，也不打算做。

不做 01

数据采集与调度

不负责真实数据采集、任务编排或文件推送执行。由外部系统整理好元数据后，通过 Metadata Contract 导入。

不做 02

扫描与解析

不主动发现数据：不扫描数据库，不解析 SQL。

不做 03

血缘计算

只浏览已导入的血缘快照，不做自动解析。

不做 04

质量与治理工作流

不提供数据质量检测、Profiling 和治理审批流程。资产就绪度只是提示，不带审批、工单或流转。

如果你需要这些能力，OpenMetadata 或 DataHub 可能更合适。这是定位差异，不是能力高低。

05 / 部署与信任

一台机器，
装在内网里，数据不出门。

部署
内网、离线、单机
外部依赖
不依赖消息中间件，不依赖独立搜索引擎
权限与审计
权限控制与操作日志
[角色模型待补]
安全披露
有披露流程
[SECURITY 链接 / 联系邮箱待补]
许可证
Apache-2.0
最低配置
[CPU / 内存 / 磁盘 待补]
落地周期
[从安装到首批元数据可搜索的实测时间 待补]

数据库兼容，分两档说清楚

Verified：有可复现的自动化测试覆盖。Compatible：只有静态或离线验证。

数据库档位依据
PostgreSQLVerified真实 PG 16 实例的 CI 验证
MySQL 8.0Verified真实 MySQL 8 实例的 CI 验证
SQLiteVerified本地开发与 Demo 使用，不是生产目标
GaussDB / DWSCompatible仅离线静态验证，暂无在线 CI 实例

06 / 接入方式

采集在外面，
DAP 只管接收和展示。

采集由外部系统负责。DAP 负责接收、校验、归一化、幂等、持久化、审计和展示。

  1. 外部系统

    采集平台、调度、脚本

  2. 整理好的元数据

    表、字段、指标、口径、血缘快照

  3. Metadata Contract

    导入格式的约定

    [Schema 链接待补]

  4. Metadata API

    接收导入请求

    [接口文档待补]

  5. DAP

    校验 · 归一化 · 幂等
    持久化 · 审计 · 展示

Contract 样例（节选）

示意数据 
{
  "contract_version": "[版本]",
  "source_system": "etl-demo",
  "tables": [
    {
      "name": "dws.trade_user_stat_d",
      "comment": "用户交易日汇总",
      "columns": [
        { "name": "order_user_cnt", "type": "bigint",
          "comment": "当日下单用户数" }
      ]
    }
  ]
}

字段名以 Contract 文档为准 [待核对]。

外部系统负责

采集、调度、解析，以及产出符合 Contract 的元数据。

DAP 负责

接收、校验、归一化、幂等、持久化、审计和展示。

07 / 开源与入口

Apache-2.0，代码和演示都是公开的。

GitHub github.com/0verme/data-asset-portal-community 在线演示 data.overme.cn（虚构零售演示数据） 文档 …/data-asset-portal-community/tree/main/docs
讨论区 [Discussions 链接待补]