
DataHub 实践指南15 分钟完成快速部署与完整摄入配置【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub你的 Snowflake 仓库里有 300 张表下游仪表盘挂掉时没人说得清是哪张上游表断了同一个月活用户口径在五个地方定义不同想找到官方版只能去问老人。这两类状况背后是同一个原因描述数据的元数据散落在各个系统里没有一个统一、可追溯的入口。DataHub 是一个开源的元数据平台数据目录它把数据仓库、BI 工具和编排引擎里的表结构、血缘、使用统计采集进一张可搜索的元数据图谱在数据栈中占据数据描述层的位置。本文将带你本地部署 DataHub、用一个 Recipe 接入真实数据源一直走到生产部署。 全景先行元数据变更如何从摄入流向搜索DataHub 的运行骨架可以拆成一条写路径和一条读路径。写路径各类连接器按 Recipe 从数据源提取元数据经 REST 或 Kafka 写入元数据服务服务层将其存入 MySQL 做版本化存储同时同步到 Elasticsearch 建立搜索索引读路径Web UI 和 GraphQL API 都直接查询元数据服务。一句话概括数据只从摄入进来从GMS出去UI 和 API 只是它上面的两个窗口。要读得懂后续内容记住下面四个抽象就够了概念白话定义示例值实体 Entity元数据资产的基本单元每类数据对象一个dataset、dashboard、corpUser切面 Aspect挂在实体上的一组属性各切面独立更新Ownership、SchemaMetadataURN实体的全局唯一标识图谱中的主键urn:li:dataset:(urn:li:dataPlatform:snowflake,analytics.customer,PROD)血缘 Lineage实体之间谁产出谁的有向边dataset → dashboard实体是资产切面是它的面URN 是引用它的把手血缘是连接它们的箭头——这套心智模型能覆盖 DataHub 里几乎所有文档。 15 分钟本地快速启动从零到能登录的 DataHub前置条件Docker Engine Docker Compose v2给 Docker 分配至少 2 vCPU、8GB 内存、约 13GB 磁盘Python 3.10CLI 依赖能拉取公开镜像的网络整个过程只有四条命令python3 -m pip install --upgrade acryl-datahub # 安装 DataHub CLI datahub docker quickstart # 用 Compose 拉起完整栈GMS、UI、MySQL、Elasticsearch、Kafka datahub init --username datahub --password datahub # 把本地实例凭据写入 CLI 配置 datahub datapack load showcase-ecommerce # 加载约 1000 个示例实体方便上手体验datahub docker quickstart会把 compose 文件下载到~/.datahub/quickstart拉取镜像并一次性启动全部容器终端出现 DataHub is now running 即部署完成。验证成功的检查点打开 http://localhost:9002用默认凭据datahub/datahub登录搜索任意数据集实体页应显示 schema、血缘与所有者终端执行datahub docker check确认各容器健康如需改源码的参与者可以克隆仓库 https://gitcode.com/GitHub_Trending/da/datahub 用scripts/dev/datahub-dev.sh start从源码启动端口定制、版本锁定等选项见 快速启动官方文档。部署完成后一块空画布就位接下来把真实数据源接进来。 接入 Snowflake一份 Recipe 搞定过滤、打标与归属以把 ANALYTICS_DB 库接入 DataHub给含敏感数据的表打上 PII 标签并指定技术负责人为例一份 Recipe 就能覆盖全过程。保存为snowflake_recipe.ymlsource: type: snowflake config: account_id: abc12345 warehouse: COMPUTE_WH username: ${SNOWFLAKE_USER} password: ${SNOWFLAKE_PASSWORD} role: DATAHUB_ROLE database_pattern: allow: - ^ANALYTICS_DB$ transformers: - type: simple_add_dataset_tags config: tag_urns: - urn:li:tag:PII - type: simple_add_dataset_ownership config: owner_urns: - urn:li:corpuser:aliceexample.com ownership_type: DEVELOPER sink: type: datahub-rest config: server: http://localhost:8080关键配置项逐项说明account_id/warehouse/role连接坐标。role 建议建一个专用只读角色不要给管理员权限${SNOWFLAKE_USER}占位符运行时从环境变量解析凭据不会落进配置文件database_pattern.allow正则白名单只摄入匹配的库可分批扩大覆盖范围transformerssource 之后按顺序执行的变换这里用simple_add_dataset_tags批量打 PII 标签、simple_add_dataset_ownership追加负责人sink指向 GMS 的 REST 端口本地是 8080生产环境换成对应服务地址一次运行的数据流如下CLI 从 Snowflake 读取元数据经过 transformer 增补一次性写入 GMS 并落到两个存储执行并验证摄入是否落库export SNOWFLAKE_USER${SNOWFLAKE_USER} SNOWFLAKE_PASSWORD${SNOWFLAKE_PASSWORD} datahub ingest -c snowflake_recipe.yml datahub search customer --filter platformsnowflake datahub get --urn urn:li:dataset:(urn:li:dataPlatform:snowflake,ANALYTICS_DB.CUSTOMER.PROFILE,PROD)再到 UI 打开对应数据集核对标签列表里出现 PII所有者区域显示 alice表列带类型与描述。至此摄入闭环完成。内置 transformer 还有按表名模式打不同标签、把标签转成业务属性等更多模块在摄入框架的 transformers 文档里都能找到对应配置。 进阶两个方向自定义 Aspect 与域级权限策略数据进来之后通常还有两件事不满足内置模型的字段装不下你的治理需求Admin/Editor/Reader 三档内置角色粒度太粗。用 PDL 扩展元数据模型场景想给数据集记录数据质量评分但内置切面里没有这个字段。用 PDLDataHub 元数据模型的建模语言定义一个自定义切面namespace com.acme.metadata Aspect { name: dataQualityScore } record DataQualityScore { score: double lastEvaluated: time }再把它注册到 dataset 实体上entities: - name: dataset aspects: - dataQualityScore推荐做法是把模型文件放在独立的 custom model 仓库、构建成包安装到摄入环境不必 fork 主仓库升级主版本时冲突面最小若走 fork 主仓库路线则需要重新构建并部署 GMS。字段需要被搜索到就追加Searchable注解完整写法见 元数据模型扩展指南。前端通过 Entity Registry 这一层统一决定每种实体如何被搜索、浏览与渲染扩展模型相当于在这层多插一个插槽这也是 DataHub 元数据模型可扩展的原因用 Policy 做域级权限场景analysts 团队默认是 Reader但希望analysts组能编辑某个域下的元数据。在 Roles 之上追加一条策略即可{ policyName: analysts-domain-editors, description: Allow analysts to edit metadata in the reports domain, principals: [urn:li:corpGroup:analysts], privileges: [EDIT_DESCRIPTION, EDIT_TAGS], resources: [ { resourceType: ENTITY, resourceSpec: { domain: urn:li:domain:analyst_reports } } ] }策略对角色是增量关系只能加权限、不能减权限资源范围可以精确到域或单个实体。内置三档角色的完整权限清单存放在metadata-service/war/src/main/resources/boot/policies.json写策略前对照它选 privilege 名称。这两个方向底层是同一套机制权限作用在实体 特权上模型扩展决定了实体长什么样如果希望自定义切面自动在 UI 页面出成选项卡还可以在Aspect注解里声明autoRender省掉前端代码。 生产部署与常见问题速查从 quickstart 走向生产前先明确一点定位quickstart 面向开发默认凭据、端口全暴露生产不可接受。推荐形态是 Kubernetes 集群加官方 Helm chart。常见问题速查表症状根因解法command not found: datahubPATH 未包含 pip 安装目录用python3 -m datahub或把~/.local/bin加入 PATHbind: address already in use3306/9200/9002 等端口被占用--mysql-port等参数或DATAHUB_MAPPED_GMS_PORT换端口登录报Table datahub.metadata_aspect doesnt exist元数据库未完成初始化向 mysql 容器手动导入docker/mysql/init.sqlno matching manifest for linux/arm64Apple Silicon 架构未识别datahub docker quickstart --arch m1数据已摄入但搜索无结果索引与主存储不同步datahub docker quickstart --restore-indices重建索引生产关键配置清单基础设施Kubernetes 集群至少 3 节点MySQL 主从部署Elasticsearch 独立 3 节点且内存不低于 16GB安全开启 GMS API 认证并替换全部默认凭据用 OIDC/SAML 接入企业 SSO数据源凭据存入 DataHub secrets 或外部 Vault性能大库用database_pattern分批增量摄入Kafka 主题保留策略不低于 7 天MySQL 每日全量备份排查路径可以压缩成这棵决策树更多启动层面的异常可逐条对照 故障排查指南。回顾与下一步Docker quickstart 本地拉起全栈用 UI 登录与docker check验证一份 snowflake Recipe 跑通真实摄入模式过滤、transformer 打标加归属、写入 GMS自定义 Aspect 扩展元数据模型不 fork 主仓库Policy 在内置角色之上做域级权限控制生产形态Kubernetes Helm存储搜索分离安全配置全量审计深入方向按 metadata-ingestion 的 pull/push 框架为一个内部平台写自定义摄入连接器基于 GraphQL 与 OpenAPI 做程序化集成例如 schema 变更影响面分析用 Actions 框架监听元数据变更自动触发通知或下游同步接下来你可以挑一个自己熟悉的数据源把上面的 Recipe 复制一份、替换连接坐标一天之内让第一批数据集进入目录。【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考