DataHub 数据血缘与治理从一条 MySQL 表到全局血缘的完整链路【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub周五下午业务方问了一句那张营收表上周改过没有改了之后下游哪些报表受影响你只能在 MySQL、数仓、BI 平台之间来回翻四十分钟最后靠猜。DataHub 是一个元数据管理平台这类问题在它上面一分钟内就有答案搜到表、点开血缘、看影响面。它把分散在各平台的表、任务、报表登记成统一目录让你先找到数据、再确认数据。下面用最小配置把这条链路跑通。先跑起来一条命令的 DataHub 快速部署环境依赖与前置检查先别急着敲命令花两分钟确认环境依赖最低版本验证命令Docker20.10docker --versionDocker Composev2docker compose versionPython3.10python3 --version内存 / 磁盘8GB RAM / 13GB 磁盘free -h内存不足是后面 OpenSearch 起不来的头号原因这一步坑了不少人先确认到位。安装 CLI 并启动# 先升级基础打包工具避免老 pip 在装 CLI 时出错 python3 -m pip install --upgrade pip wheel setuptools # 安装 DataHub CLI 核心包数据源连接器可以按需后装 python3 -m pip install --upgrade acryl-datahub datahub version # 确认 CLI 可用 # 一条命令拉取全部服务MySQL、OpenSearch、Kafka、GMS、前端 datahub docker quickstart首次运行会把 compose 文件下载到~/.datahub/quickstart并依次拉起容器中途拉镜像比较耗时。常见两个变体# 锁定版本避免下次运行自动跟着新版走 datahub docker quickstart --version v1.6.0 # 端口被占用时把前端 / GMS 映射到空闲端口 DATAHUB_MAPPED_FRONTEND_PORT9003 DATAHUB_MAPPED_GMS_PORT8081 datahub docker quickstart验证成功看到✔ DataHub is now running即代表服务起来了。浏览器打开http://localhost:9002用默认账号datahub/datahub登录命令行侧验证 GMS 健康状态# 返回 HTTP 200 说明元数据服务已就绪 curl -I http://localhost:8080/health空库能看但没什么可看。先配置 CLI 再加载官方样本数据datahub init --username datahub --password datahub # 让 CLI 记住本地实例地址 datahub datapack load showcase-ecommerce # 加载约 1050 个实体的示例包样本包覆盖 Snowflake、Looker、PowerBI、Tableau自带血缘、标签和术语表后面演示全靠它。到此你拥有了一个可访问、有数据的 DataHub 实例。核心能力拆解按任务流走一遍DataHub 前端由实体注册表统一驱动认证、搜索、浏览、实体详情都挂在同一套实体模型上这也是它能跨平台串血缘的基础找到一张表搜索与高级查询你要在几百张表里定位到某张表时用搜索。搜索栏支持高级查询几个常用写法写法效果customer data精确匹配短语logging -snowflake包含 logging 但排除 snowflake/q name: *sales*表名包含 sales/q fieldPaths: customer_id按列名反查所在表(production AND (kafka OR postgres)) NOT test布尔组合过滤左侧边栏还能按平台、标签、业务术语、Owner 继续收窄。如果结果不符合预期检查摄入是否已经跑完——样本数据里没摄入的字段不会进索引。看它从哪来、到哪去血缘与影响分析要回答上游谁在写、下游谁在读时打开表的详情页切到Lineage标签。默认是 Explorer 视图逐个节点展开上下游切换 Impact Analysis 可以评估一次变更会波及多少下游资产。表里的列可以展开到列级血缘跨 Kafka、Spark、BigQuery 这类平台的链路也会画在同一张图上。如果图是空的大概率是摄入源没开血缘抽取——查一下该源的文档是否支持或在 UI 里手动补上游下游。确认数据靠不靠谱质量规则与治理你要证明这张表能放心用时靠质量断言。DataHub 的 assertion 可以来自 dbt 测试、Monte Carlo 等连接器也可以随 ODCS 数据契约一并同步进来。一条最小规则长这样挂在数据集上每次运行后页面上就有通过率和失败明细assertions: - check: NOT_NULL fieldPaths: - order_id message: 订单主键不允许为空 - check: FRESHNESS fieldPaths: - last_updated message: 数据应在 24 小时内更新接入你的数据源以 MySQL 为例编写数据源摄入配置在仓库的 metadata-ingestion/examples/recipes/ 目录里能找到各数据源的现成 recipe 参考。MySQL 的完整写法source: type: mysql config: host_port: mysql.example.com:3306 # 数据库地址必须是 DataHub 能访问的 database: sales username: reader password: secret include_tables: - orders.* # 只摄入订单库控制首次摄入规模 profiling: enabled: true # 顺手做采样 profiling空表能尽早暴露 limit: 1000 sink: type: datahub-rest config: server: http://localhost:8080 # 本地 quickstart 的 GMS 地址token 可先留空执行摄入与验证datahub ingest -c mysql_recipe.yaml --dry-run # 只跑抽取和校验不落库先验证连接 datahub ingest -c mysql_recipe.yaml # 正式摄入 datahub ingest -c mysql_recipe.yaml --resume # 中断后从检查点恢复避免整批重跑 datahub ingest report # 查看本次运行报告dry-run 报连接或权限错误时多半是账号权限不够或网络不通这时别急着进正式摄入。接入后的日常节奏每天跑一次即可表结构变动频繁的环境可以提到一天两次。看报告时盯三个指标指标阈值异常信号errors 条数0非 0 先读错误明细新表数与include_tables一致突降说明过滤条件变了运行时长环比不翻倍翻倍先查数据源侧少踩坑四个高频问题端口冲突最常见。9002 或 8080 被本机其他服务占了quickstart 起一半就失败用环境变量换端口重启即可DATAHUB_MAPPED_FRONTEND_PORT9003 DATAHUB_MAPPED_GMS_PORT8081 datahub docker quickstartOpenSearch 起不来或搜索转圈大概率是 Docker 分配的内存不够。把 Docker Desktop 的内存调到 8GB 以上再重启容器比改任何 DataHub 配置都有效。摄入卡在连接阶段日志里反复超时通常是网络问题而不是 DataHub 问题。先curl一下数据库地址确认连通再回头检查 recipe 里的host_port。摄入明明成功UI 却搜不到新表是搜索索引没跟上。一条命令从主库重建索引datahub docker quickstart --restore-indices另外升级 CLI 前如果版本跨得远先datahub docker quickstart --backup导出备份再用--restore恢复。生产环境至少把认证打开并配每日备份其余参考官方文档的部署章节。你现在可以做的事把第二个真实数据源加进来把摄入任务挂到 CI 里定时跑或者按角色给团队成员开权限。【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考