DataHub Quickstart用 datahub CLI 一条命令拉起本地 DataHub 全栈实例【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub本文基于 DataHub 仓库的官方快速入门文档 docs/quickstart.md完整覆盖从安装 CLI、一条命令启动全栈 DataHub 环境、加载示例数据到停止、重置、升级、备份与恢复实例的全流程操作并结合 docker_cli.py 与 quickstart_version_mapping.yaml 等源码讲清每个命令背后的实际行为。读完本文你可以在本机 510 分钟内搭建出可交互的 DataHub 实例并具备对本地实例进行版本管理、数据备份与索引重建的运维能力。环境准备Prerequisitesquickstart 依赖 Docker 完成全部部署本地环境需满足以下前提安装 Docker 与 Docker Compose v2当前平台对应版本平台推荐应用WindowsDocker DesktopMacDocker DesktopLinuxDocker Engine 独立安装的 Docker Compose v2确保 Docker 引擎已启动通过命令行或桌面应用。Python 3.10已安装并配置到 PATH可用python3 --version检查。CLI 侧对 Compose 版本有硬性校验_docker_compose_v2() 会依次探测docker compose version与docker-compose version若检测到的是 1.x 版本会抛出DockerComposeVersionError提示必须升级到 Compose v2。:::note Docker 资源分配请为 Docker 引擎分配足够的硬件资源。仓库文档给出的已验证配置为2 CPU、8GB 内存、2GB Swap、13GB 磁盘空间。从 docker-compose.quickstart-profile.yml 的内存设置看GMS 容器配置为-Xms1g -Xmx1gKafka 与前端各约 512MBOpenSearch 约 1GBOPENSEARCH_JAVA_OPTS: -Xms768m -Xmx1024m上述资源配置与此相符。 :::安装 DataHub CLIDataHub CLI 提供了两条安装路径方式一Homebrewbrew install datahub-project/tap/datahub datahub versionHomebrew 会为datahub维护一个隔离的 Python 环境无需手动创建/激活 venv。该 formula 仅安装CLI 核心如需使用元数据采集连接器需额外安装到 brew 管理的环境中$(brew --prefix datahub)/libexec/bin/pip install acryl-datahub[snowflake,bigquery]方式二pippython3 -m pip install --upgrade pip wheel setuptools python3 -m pip install --upgrade acryl-datahub datahub version:::note 提示command not found时若安装后执行datahub报command not found可尝试用python3 -m datahub version形式调用。注意 DataHub CLI 不支持 Python 2.x。 :::启动 DataHubdatahub docker quickstart在终端执行datahub docker quickstart该命令通过 docker-compose 部署一个完整的 DataHub 实例。如果你好奇docker-compose.yml会被下载到用户主目录的~/.datahub/quickstart目录下。命令背后发生了什么从 docker_cli.py 的 quickstart 命令实现 可以还原出完整的执行链路拉取 compose 配置默认从仓库中定义的QUICKSTART_COMPOSE_FILE docker/quickstart/docker-compose.quickstart-profile.ymldocker_cli.py#L51对应的 GitHub 原始文件下载写入本地~/.datahub/quickstart/docker-compose.yml见 download_compose_files预检preflight checks通过 Docker client 检查本机环境升级兼容性检查_check_upgrade_and_show_instructions 会检测现有实例是否可用当前 CLI 直接升级不兼容时打印迁移/修复指引并退出解析版本执行计划依据--version参数与版本映射文件生成执行计划详见下节拉取镜像docker compose pull可用--no-pull-images跳过循环启动与健康检查执行docker compose up -d --remove-orphans每2 秒_QUICKSTART_STATUS_CHECK_INTERVAL检查一次容器健康状态单次 up 超时 100 秒_QUICKSTART_UP_TIMEOUT最长等待15 分钟_QUICKSTART_MAX_WAIT_TIME失败时可加--dump-logs-on-failure把 compose 日志直接打印到控制台。一切顺利时你会看到类似输出Fetching docker-compose file ... from GitHub Pulling docker images... Finished pulling docker images! Starting up DataHub... [] Running 14/14 ✔ Network datahub_network Created ✔ Volume datahub_broker Created ✔ Volume datahub_mysqldata Created ✔ Volume datahub_osdata Created ✔ Container datahub-mysql-1 Healthy ✔ Container datahub-opensearch-1 Healthy ✔ Container datahub-kafka-broker-1 Healthy ✔ Container datahub-system-update-quickstart-1 Exited ✔ Container datahub-datahub-gms-quickstart-1 Healthy ✔ Container datahub-frontend-quickstart-1 Started ✔ Container datahub-datahub-actions-quickstart-1 Started ✔ DataHub is now running Load sample data: run datahub init then datahub datapack load showcase-ecommerce, or head to http://localhost:9002 (username: datahub, password: datahub) to play around with the frontend.容器栈里到底跑了什么从 docker/quickstart/docker-compose.quickstart-profile.yml 可以确认quickstart profile 启动以下服务项目名固定为datahub网络为datahub_network服务镜像宿主机端口说明datahub-gms-quickstartacryldata/datahub-gms:${DATAHUB_VERSION}8080可用DATAHUB_MAPPED_GMS_PORT覆盖元数据服务主后端GMS健康检查探活http://datahub-gms:8080/healthfrontend-quickstartacryldata/datahub-frontend-react:${DATAHUB_VERSION}9002DATAHUB_MAPPED_FRONTEND_PORTReact 前端 UIkafka-brokerconfluentinc/cp-kafka:8.2.29092KRaft 单节点 broker已移除 Zookeeper 依赖外部监听EXTERNAL://localhost:9092mysqlmysql:8.23306主存储数据库库名datahubopensearchopensearchproject/opensearch:2.19.39200搜索/图索引存储GMS 侧GRAPH_SERVICE_IMPLelasticsearch兼容协议访问system-update-quickstartacryldata/datahub-upgrade:${DATAHUB_VERSION}无一次性初始化任务-u SystemUpdate负责建库建索引、预建 Kafka topic 等成功后才放行 GMS/前端启动datahub-actions-quickstartacryldata/datahub-actions:${DATAHUB_VERSION}-slim无元数据 Actions 执行器依赖 GMS 健康后启动依赖顺序由 compose 的depends_on显式声明存储三件套Kafka、MySQL、OpenSearch健康 →system-update成功退出 → GMS 健康 → Actions 启动前端在system-update完成后启动。数据持久化依赖三个命名卷datahub_brokerKafka 数据、datahub_mysqldataMySQL 数据、datahub_osdataOpenSearch 数据。版本选择quickstart_version_mapping.yaml 的映射机制--version参数不是简单透传镜像 tag而是经过 QuickstartVersionMappingConfig 解析。映射配置来自仓库中的 docker/quickstart/quickstart_version_mapping.yaml运行时从远端拉取并缓存到本地网络不通时回退本地文件再不通则用内置默认计划。当前仓库中的关键映射请求版本compose 文件来源git ref镜像 tag说明不传--versiondefaultmasterv1.7.0.1默认master 分支的 compose 已发布修复版镜像head/quickstartmasterquickstart使用 master 的协同开发构建compose 来自 master镜像打quickstart浮标 tagv1.7.0v1.7.0.1v1.7.0.1小版本别名自动重映射到最新 patchv1.6.0v1.6.0.2v1.6.0.2同上stable查询 GitHub 最新 release最新 release tag映射文件中未显式定义stable时CLI 会查询 GitHub releases API 动态解析其他行为规则来自映射文件头注与 quickstart_versioning.py 源码未映射的版本号如v1.2.0这类发布 tag会被当作 docker tag 与 compose git ref原样使用四段式热修复 tag如v1.5.0.6中镜像用该四段 tag而 compose 文件及其他非镜像设置回退到对应的三段短版本v1.5.0传入无法识别的--version比如拼写错误时CLI 会提示确认后再回退到默认 quickstart 配置省略--version则直接使用默认配置、不提示。脚本化场景可传--accept-version-default跳过交互提示低于最低支持版本会直接报错退出is_minimum_supported_version校验。常用启动示例# 默认版本启动 datahub docker quickstart # 指定某个发布版本 datahub docker quickstart --version v1.6.0 # 指定特定 commit 构建仅镜像仓库中存在不是 git tag datahub docker quickstart --version sha-short_sha可选固定签名密钥DataHub 首次启动时会为认证 token 生成随机签名密钥与 salt并在后续启动中复用值保存在~/.datahub/quickstart/.local-secrets.env。多数用户无需改动。从源码看_resolve_token_service_secrets 采用三级优先级解析DATAHUB_TOKEN_SERVICE_SIGNING_KEY与DATAHUB_TOKEN_SERVICE_SALTshell 环境变量最高优先级便于 CI/生产覆盖~/.datahub/quickstart/.local-secrets.env中已持久化的生成值均无则用secrets.token_bytes(32)的 base64 随机值并写入上述文件供下次复用。若希望 token 在多个环境间保持稳定请在首次运行datahub docker quickstart之前自行设定export DATAHUB_TOKEN_SERVICE_SIGNING_KEYvalue export DATAHUB_TOKEN_SERVICE_SALTvalue可用openssl rand -base64 32生成值。从 v1.5 之前的旧版 CLI 升级注意签名密钥由硬编码默认值改为随机生成升级前创建的 PAT个人访问令牌会失效需要重新生成。登录与加载示例数据登录Sign In启动完成后浏览器访问http://localhost:9002使用默认凭据登录username: datahub password: datahub如需修改该默认凭据参见 修改 quickstart 中的默认用户 datahub。加载示例数据Load Sample Data先配置 CLI 连接本地 DataHub 实例datahub init --username datahub --password datahub然后加载showcase-ecommerce数据包——一组横跨 Snowflake、Looker、PowerBI、Tableau 的约 1,050 个实体包含血缘、治理、业务术语表glossary、域domains与数据产品data productsdatahub datapack load showcase-ecommerce:::notedatahub datapack命令目前仍属实验性质——其命令接口与行为可能在后续版本中变化。 :::从 CLI 内置的数据包注册表 registry.json 可确认showcase-ecommerce包描述为 “Rich e-commerce demo with 1049 entities across Snowflake, Looker, PowerBI, Tableau...”体积约 2.7MB最低要求服务端版本 0.14.0另有默认bootstrap包约 100KB 的演示数据集、仪表板、用户与标签。到此你就可以在 UI 中自由体验 DataHub 了管理本地实例Managing Your Local Instance以下命令仅适用于本地 quickstart 部署生产运维请参见 docs/deploy/kubernetes.md。datahub docker quickstart完整参数表以下参数整理自 docker_cli.py 中 quickstart 命令的 click 选项定义参数默认值说明--versiondefault要部署的 DataHub 版本不指定时使用 quickstart compose 的默认值--pull-images/--no-pull-imagesTrue启动前是否从镜像仓库拉取容器镜像-f/--quickstart-compose-file空远端下载使用本地 docker-compose 文件替代从 GitHub 拉取可多次指定--dump-logs-on-failureFalse启动失败时把 compose 日志打印到控制台--mysql-portNone映射 3306本机已有 MySQL 占用 3306 时指定一个空闲端口避开冲突--kafka-broker-portNone映射 9092本机已有 Kafka 占用 9092 时指定空闲端口--elastic-portNone映射 9200本机已有 Elasticsearch 占用 9200 时指定空闲端口--stopFalse停止运行中的容器--backupFalse备份运行中的 quickstart 实例--backup-file~/.datahub/quickstart/backup.sql备份 SQL 文件输出路径--restoreFalse从备份恢复实例配合--backup使用--restore-file~/.datahub/quickstart/backup.sql指定自定义恢复文件--restore-indicesFalse恢复索引注意--restore默认会自动恢复索引除非显式传--no-restore-indices--no-restore-indicesFalse与--restore联用跳过索引重建--arch自动检测指定 quickstart 镜像架构x86、arm64 等默认自动识别 Apple Silicon--accept-version-defaultFalse未识别的--version直接采用建议配置不交互提示停止 DataHubStopdatahub docker quickstart --stop源码中 _attempt_stop 通过docker compose --profile quickstart -p datahub stop实现若未显式指定 compose 文件会回落到默认位置~/.datahub/quickstart/docker-compose.yml。重置 DataHubReset / Nuke需要清除 DataHub 全部状态例如在导入自有数据前时使用nuke命令datahub docker nuke从 nuke 命令实现 看它会按 compose 项目过滤器项目名datahub依次移除所有容器连带匿名卷、数据卷含旧版本遗留卷的过滤器与网络若加--keep-data则仅保留数据卷。升级 DataHubUpgrade如果本地一直在测试 DataHub、想体验新版本直接再次执行 quickstart 命令即可——它会拉取更新的镜像并重启实例且不丢失数据datahub docker quickstart默认安装最新发布版本也可以显式指定版本datahub docker quickstart --version v1.6.0可用版本即仓库的 releases见 quickstart_version_mapping.yaml 中已维护的映射。另外可指定head或quickstart作为版本值以获取来自master分支的最新协同开发镜像compose 来自master镜像 tag 为quickstart。特定 commit 构建可用sha-short_sha仅存在于镜像仓库不是 git tag。自定义安装Customize installation如需进一步定制可下载 CLI 实际使用的 docker-compose 文件按需修改后传入datahub docker quickstart --quickstart-compose-file compose文件路径该选项在源码中支持多次-f传入多个 compose 文件并校验文件存在且可读。备份 DataHubBack upquickstart 镜像不建议作为生产实例使用。但如果你需要为当前 quickstart 状态做备份例如公司演示前想留一份可日后恢复的数据副本可加--backup标志datahub docker quickstart --backup默认在~/.datahub/quickstart/目录生成backup.sql文件。可用--backup-file自定义路径datahub docker quickstart --backup --backup-file 备份文件路径从源码看备份实现是 _backup 中对 MySQL 容器执行mysqldump -u root -pdatahub datahub并重定向输出因此它本质是一份主数据库MySQL的全量 SQL 转储。:::cautionQuickstart 备份不包含任何时序数据数据集统计、数据画像等。若你删除全部索引后仅用该备份恢复这些信息将丢失。 :::恢复 DataHubRestore备份是可恢复的共有三种恢复模式1. 通用恢复General Restoring恢复主数据库与搜索索引datahub docker quickstart --restore该命令读取~/.datahub/quickstart下的backup.sql恢复主数据库并连带重建索引。指定自定义备份文件datahub docker quickstart --restore --restore-file /home/my_user/datahub_backups/quickstart_backup_2002_22_01.sql源码层面_restore恢复分两步先把 SQL 文件通过docker exec -i管道进 MySQL 容器执行再拉取acryldata/datahub-upgrade镜像、以-u RestoreIndices -a clean参数运行从主存储全量重建搜索/图索引。执行前 CLI 会用click.confirm展示将要进行的操作并要求确认。2. 仅恢复索引Restore Only Index索引损坏或缺少部分更新时可仅从主存储重新引导索引不同步主库datahub docker quickstart --restore-indices3. 仅恢复主库Restore Only Primary有时只想恢复 MySQL 主库状态而不重建索引需显式禁用索引恢复datahub docker quickstart --restore --no-restore-indices参数组合有校验valid_restore_options单独使用--no-restore-indices不带--restore是未定义用法会报错退出--restore与--restore-indices同时给出则提示前者已隐含后者并继续。从旧版本 CLI 升级Upgrading from an older CLI从 v1.2 之前的 CLI 升级v1.2 起datahub docker quickstart使用的 docker-compose 文件与更早 CLI 安装的 DataHub不兼容。若你已用旧 CLI 装过 DataHub请按以下步骤升级备份数据推荐datahub docker quickstart --backup若无需保留数据可跳过移除旧安装datahub docker nuke重新全新安装datahub docker quickstart。⚠️ 不做备份将丢失全部已有数据。跨版本的完整破坏性变更清单见 docs/how/updating-datahub.md。CLI 中这一检查是自动执行的docker_cli.py 内置了MIGRATION_REQUIRED_INSTRUCTIONS可迁移路径备份 → nuke → 重装 → restore与REPAIR_REQUIRED_INSTRUCTIONS不可修复的旧安装回退 CLI 到 1.1 修复后再迁移或放弃数据直接 nuke 重装两套指引启动前检测到不兼容实例时会自动打印。为什么 Quickstart 不适合生产环境官方文档明确Quickstart 并非为生产环境设计推荐生产部署采用 Kubernetes配套 Helm Charts 可快速拉起见 docs/deploy/kubernetes.md。不建议用于生产的理由有三点默认凭据quickstart 的 compose 配置中内置了 DataHub 自身及其底层存储如 MySQL的默认凭据且部分组件开箱即无认证。这是为降低开发门槛的设计取舍不是生产最佳实践。例如 compose 文件中MYSQL_ROOT_PASSWORD: datahub、GMS 的METADATA_SERVICE_AUTH_ENABLED: false均可在 docker-compose.quickstart-profile.yml 中直接看到。端口全部暴露DataHub 各服务与后端存储使用 Docker 默认行为绑定所有网络接口地址便于开发调试但不适合生产网络环境。性能与运维能力受限quickstart 受限于单机资源无法水平扩展新版本发布往往需要停机窗口配置大体预置、难以灵活管理且默认跟随最新构建会强制更新到最新含未发布的构建。下一步Next StepsQuickstart 故障排查指南通过 UI 摄入元数据通过 CLI 摄入元数据向 DataHub 添加用户配置 OIDC 认证配置 JaaS 认证配置 DataHub 后端的元数据服务认证修改 quickstart 中的默认用户 datahub重建搜索索引restore-indices 相关文档【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
DataHub Quickstart：用 datahub CLI 一条命令拉起本地 DataHub 全栈实例
DataHub Quickstart用 datahub CLI 一条命令拉起本地 DataHub 全栈实例【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub本文基于 DataHub 仓库的官方快速入门文档 docs/quickstart.md完整覆盖从安装 CLI、一条命令启动全栈 DataHub 环境、加载示例数据到停止、重置、升级、备份与恢复实例的全流程操作并结合 docker_cli.py 与 quickstart_version_mapping.yaml 等源码讲清每个命令背后的实际行为。读完本文你可以在本机 510 分钟内搭建出可交互的 DataHub 实例并具备对本地实例进行版本管理、数据备份与索引重建的运维能力。环境准备Prerequisitesquickstart 依赖 Docker 完成全部部署本地环境需满足以下前提安装 Docker 与 Docker Compose v2当前平台对应版本平台推荐应用WindowsDocker DesktopMacDocker DesktopLinuxDocker Engine 独立安装的 Docker Compose v2确保 Docker 引擎已启动通过命令行或桌面应用。Python 3.10已安装并配置到 PATH可用python3 --version检查。CLI 侧对 Compose 版本有硬性校验_docker_compose_v2() 会依次探测docker compose version与docker-compose version若检测到的是 1.x 版本会抛出DockerComposeVersionError提示必须升级到 Compose v2。:::note Docker 资源分配请为 Docker 引擎分配足够的硬件资源。仓库文档给出的已验证配置为2 CPU、8GB 内存、2GB Swap、13GB 磁盘空间。从 docker-compose.quickstart-profile.yml 的内存设置看GMS 容器配置为-Xms1g -Xmx1gKafka 与前端各约 512MBOpenSearch 约 1GBOPENSEARCH_JAVA_OPTS: -Xms768m -Xmx1024m上述资源配置与此相符。 :::安装 DataHub CLIDataHub CLI 提供了两条安装路径方式一Homebrewbrew install datahub-project/tap/datahub datahub versionHomebrew 会为datahub维护一个隔离的 Python 环境无需手动创建/激活 venv。该 formula 仅安装CLI 核心如需使用元数据采集连接器需额外安装到 brew 管理的环境中$(brew --prefix datahub)/libexec/bin/pip install acryl-datahub[snowflake,bigquery]方式二pippython3 -m pip install --upgrade pip wheel setuptools python3 -m pip install --upgrade acryl-datahub datahub version:::note 提示command not found时若安装后执行datahub报command not found可尝试用python3 -m datahub version形式调用。注意 DataHub CLI 不支持 Python 2.x。 :::启动 DataHubdatahub docker quickstart在终端执行datahub docker quickstart该命令通过 docker-compose 部署一个完整的 DataHub 实例。如果你好奇docker-compose.yml会被下载到用户主目录的~/.datahub/quickstart目录下。命令背后发生了什么从 docker_cli.py 的 quickstart 命令实现 可以还原出完整的执行链路拉取 compose 配置默认从仓库中定义的QUICKSTART_COMPOSE_FILE docker/quickstart/docker-compose.quickstart-profile.ymldocker_cli.py#L51对应的 GitHub 原始文件下载写入本地~/.datahub/quickstart/docker-compose.yml见 download_compose_files预检preflight checks通过 Docker client 检查本机环境升级兼容性检查_check_upgrade_and_show_instructions 会检测现有实例是否可用当前 CLI 直接升级不兼容时打印迁移/修复指引并退出解析版本执行计划依据--version参数与版本映射文件生成执行计划详见下节拉取镜像docker compose pull可用--no-pull-images跳过循环启动与健康检查执行docker compose up -d --remove-orphans每2 秒_QUICKSTART_STATUS_CHECK_INTERVAL检查一次容器健康状态单次 up 超时 100 秒_QUICKSTART_UP_TIMEOUT最长等待15 分钟_QUICKSTART_MAX_WAIT_TIME失败时可加--dump-logs-on-failure把 compose 日志直接打印到控制台。一切顺利时你会看到类似输出Fetching docker-compose file ... from GitHub Pulling docker images... Finished pulling docker images! Starting up DataHub... [] Running 14/14 ✔ Network datahub_network Created ✔ Volume datahub_broker Created ✔ Volume datahub_mysqldata Created ✔ Volume datahub_osdata Created ✔ Container datahub-mysql-1 Healthy ✔ Container datahub-opensearch-1 Healthy ✔ Container datahub-kafka-broker-1 Healthy ✔ Container datahub-system-update-quickstart-1 Exited ✔ Container datahub-datahub-gms-quickstart-1 Healthy ✔ Container datahub-frontend-quickstart-1 Started ✔ Container datahub-datahub-actions-quickstart-1 Started ✔ DataHub is now running Load sample data: run datahub init then datahub datapack load showcase-ecommerce, or head to http://localhost:9002 (username: datahub, password: datahub) to play around with the frontend.容器栈里到底跑了什么从 docker/quickstart/docker-compose.quickstart-profile.yml 可以确认quickstart profile 启动以下服务项目名固定为datahub网络为datahub_network服务镜像宿主机端口说明datahub-gms-quickstartacryldata/datahub-gms:${DATAHUB_VERSION}8080可用DATAHUB_MAPPED_GMS_PORT覆盖元数据服务主后端GMS健康检查探活http://datahub-gms:8080/healthfrontend-quickstartacryldata/datahub-frontend-react:${DATAHUB_VERSION}9002DATAHUB_MAPPED_FRONTEND_PORTReact 前端 UIkafka-brokerconfluentinc/cp-kafka:8.2.29092KRaft 单节点 broker已移除 Zookeeper 依赖外部监听EXTERNAL://localhost:9092mysqlmysql:8.23306主存储数据库库名datahubopensearchopensearchproject/opensearch:2.19.39200搜索/图索引存储GMS 侧GRAPH_SERVICE_IMPLelasticsearch兼容协议访问system-update-quickstartacryldata/datahub-upgrade:${DATAHUB_VERSION}无一次性初始化任务-u SystemUpdate负责建库建索引、预建 Kafka topic 等成功后才放行 GMS/前端启动datahub-actions-quickstartacryldata/datahub-actions:${DATAHUB_VERSION}-slim无元数据 Actions 执行器依赖 GMS 健康后启动依赖顺序由 compose 的depends_on显式声明存储三件套Kafka、MySQL、OpenSearch健康 →system-update成功退出 → GMS 健康 → Actions 启动前端在system-update完成后启动。数据持久化依赖三个命名卷datahub_brokerKafka 数据、datahub_mysqldataMySQL 数据、datahub_osdataOpenSearch 数据。版本选择quickstart_version_mapping.yaml 的映射机制--version参数不是简单透传镜像 tag而是经过 QuickstartVersionMappingConfig 解析。映射配置来自仓库中的 docker/quickstart/quickstart_version_mapping.yaml运行时从远端拉取并缓存到本地网络不通时回退本地文件再不通则用内置默认计划。当前仓库中的关键映射请求版本compose 文件来源git ref镜像 tag说明不传--versiondefaultmasterv1.7.0.1默认master 分支的 compose 已发布修复版镜像head/quickstartmasterquickstart使用 master 的协同开发构建compose 来自 master镜像打quickstart浮标 tagv1.7.0v1.7.0.1v1.7.0.1小版本别名自动重映射到最新 patchv1.6.0v1.6.0.2v1.6.0.2同上stable查询 GitHub 最新 release最新 release tag映射文件中未显式定义stable时CLI 会查询 GitHub releases API 动态解析其他行为规则来自映射文件头注与 quickstart_versioning.py 源码未映射的版本号如v1.2.0这类发布 tag会被当作 docker tag 与 compose git ref原样使用四段式热修复 tag如v1.5.0.6中镜像用该四段 tag而 compose 文件及其他非镜像设置回退到对应的三段短版本v1.5.0传入无法识别的--version比如拼写错误时CLI 会提示确认后再回退到默认 quickstart 配置省略--version则直接使用默认配置、不提示。脚本化场景可传--accept-version-default跳过交互提示低于最低支持版本会直接报错退出is_minimum_supported_version校验。常用启动示例# 默认版本启动 datahub docker quickstart # 指定某个发布版本 datahub docker quickstart --version v1.6.0 # 指定特定 commit 构建仅镜像仓库中存在不是 git tag datahub docker quickstart --version sha-short_sha可选固定签名密钥DataHub 首次启动时会为认证 token 生成随机签名密钥与 salt并在后续启动中复用值保存在~/.datahub/quickstart/.local-secrets.env。多数用户无需改动。从源码看_resolve_token_service_secrets 采用三级优先级解析DATAHUB_TOKEN_SERVICE_SIGNING_KEY与DATAHUB_TOKEN_SERVICE_SALTshell 环境变量最高优先级便于 CI/生产覆盖~/.datahub/quickstart/.local-secrets.env中已持久化的生成值均无则用secrets.token_bytes(32)的 base64 随机值并写入上述文件供下次复用。若希望 token 在多个环境间保持稳定请在首次运行datahub docker quickstart之前自行设定export DATAHUB_TOKEN_SERVICE_SIGNING_KEYvalue export DATAHUB_TOKEN_SERVICE_SALTvalue可用openssl rand -base64 32生成值。从 v1.5 之前的旧版 CLI 升级注意签名密钥由硬编码默认值改为随机生成升级前创建的 PAT个人访问令牌会失效需要重新生成。登录与加载示例数据登录Sign In启动完成后浏览器访问http://localhost:9002使用默认凭据登录username: datahub password: datahub如需修改该默认凭据参见 修改 quickstart 中的默认用户 datahub。加载示例数据Load Sample Data先配置 CLI 连接本地 DataHub 实例datahub init --username datahub --password datahub然后加载showcase-ecommerce数据包——一组横跨 Snowflake、Looker、PowerBI、Tableau 的约 1,050 个实体包含血缘、治理、业务术语表glossary、域domains与数据产品data productsdatahub datapack load showcase-ecommerce:::notedatahub datapack命令目前仍属实验性质——其命令接口与行为可能在后续版本中变化。 :::从 CLI 内置的数据包注册表 registry.json 可确认showcase-ecommerce包描述为 “Rich e-commerce demo with 1049 entities across Snowflake, Looker, PowerBI, Tableau...”体积约 2.7MB最低要求服务端版本 0.14.0另有默认bootstrap包约 100KB 的演示数据集、仪表板、用户与标签。到此你就可以在 UI 中自由体验 DataHub 了管理本地实例Managing Your Local Instance以下命令仅适用于本地 quickstart 部署生产运维请参见 docs/deploy/kubernetes.md。datahub docker quickstart完整参数表以下参数整理自 docker_cli.py 中 quickstart 命令的 click 选项定义参数默认值说明--versiondefault要部署的 DataHub 版本不指定时使用 quickstart compose 的默认值--pull-images/--no-pull-imagesTrue启动前是否从镜像仓库拉取容器镜像-f/--quickstart-compose-file空远端下载使用本地 docker-compose 文件替代从 GitHub 拉取可多次指定--dump-logs-on-failureFalse启动失败时把 compose 日志打印到控制台--mysql-portNone映射 3306本机已有 MySQL 占用 3306 时指定一个空闲端口避开冲突--kafka-broker-portNone映射 9092本机已有 Kafka 占用 9092 时指定空闲端口--elastic-portNone映射 9200本机已有 Elasticsearch 占用 9200 时指定空闲端口--stopFalse停止运行中的容器--backupFalse备份运行中的 quickstart 实例--backup-file~/.datahub/quickstart/backup.sql备份 SQL 文件输出路径--restoreFalse从备份恢复实例配合--backup使用--restore-file~/.datahub/quickstart/backup.sql指定自定义恢复文件--restore-indicesFalse恢复索引注意--restore默认会自动恢复索引除非显式传--no-restore-indices--no-restore-indicesFalse与--restore联用跳过索引重建--arch自动检测指定 quickstart 镜像架构x86、arm64 等默认自动识别 Apple Silicon--accept-version-defaultFalse未识别的--version直接采用建议配置不交互提示停止 DataHubStopdatahub docker quickstart --stop源码中 _attempt_stop 通过docker compose --profile quickstart -p datahub stop实现若未显式指定 compose 文件会回落到默认位置~/.datahub/quickstart/docker-compose.yml。重置 DataHubReset / Nuke需要清除 DataHub 全部状态例如在导入自有数据前时使用nuke命令datahub docker nuke从 nuke 命令实现 看它会按 compose 项目过滤器项目名datahub依次移除所有容器连带匿名卷、数据卷含旧版本遗留卷的过滤器与网络若加--keep-data则仅保留数据卷。升级 DataHubUpgrade如果本地一直在测试 DataHub、想体验新版本直接再次执行 quickstart 命令即可——它会拉取更新的镜像并重启实例且不丢失数据datahub docker quickstart默认安装最新发布版本也可以显式指定版本datahub docker quickstart --version v1.6.0可用版本即仓库的 releases见 quickstart_version_mapping.yaml 中已维护的映射。另外可指定head或quickstart作为版本值以获取来自master分支的最新协同开发镜像compose 来自master镜像 tag 为quickstart。特定 commit 构建可用sha-short_sha仅存在于镜像仓库不是 git tag。自定义安装Customize installation如需进一步定制可下载 CLI 实际使用的 docker-compose 文件按需修改后传入datahub docker quickstart --quickstart-compose-file compose文件路径该选项在源码中支持多次-f传入多个 compose 文件并校验文件存在且可读。备份 DataHubBack upquickstart 镜像不建议作为生产实例使用。但如果你需要为当前 quickstart 状态做备份例如公司演示前想留一份可日后恢复的数据副本可加--backup标志datahub docker quickstart --backup默认在~/.datahub/quickstart/目录生成backup.sql文件。可用--backup-file自定义路径datahub docker quickstart --backup --backup-file 备份文件路径从源码看备份实现是 _backup 中对 MySQL 容器执行mysqldump -u root -pdatahub datahub并重定向输出因此它本质是一份主数据库MySQL的全量 SQL 转储。:::cautionQuickstart 备份不包含任何时序数据数据集统计、数据画像等。若你删除全部索引后仅用该备份恢复这些信息将丢失。 :::恢复 DataHubRestore备份是可恢复的共有三种恢复模式1. 通用恢复General Restoring恢复主数据库与搜索索引datahub docker quickstart --restore该命令读取~/.datahub/quickstart下的backup.sql恢复主数据库并连带重建索引。指定自定义备份文件datahub docker quickstart --restore --restore-file /home/my_user/datahub_backups/quickstart_backup_2002_22_01.sql源码层面_restore恢复分两步先把 SQL 文件通过docker exec -i管道进 MySQL 容器执行再拉取acryldata/datahub-upgrade镜像、以-u RestoreIndices -a clean参数运行从主存储全量重建搜索/图索引。执行前 CLI 会用click.confirm展示将要进行的操作并要求确认。2. 仅恢复索引Restore Only Index索引损坏或缺少部分更新时可仅从主存储重新引导索引不同步主库datahub docker quickstart --restore-indices3. 仅恢复主库Restore Only Primary有时只想恢复 MySQL 主库状态而不重建索引需显式禁用索引恢复datahub docker quickstart --restore --no-restore-indices参数组合有校验valid_restore_options单独使用--no-restore-indices不带--restore是未定义用法会报错退出--restore与--restore-indices同时给出则提示前者已隐含后者并继续。从旧版本 CLI 升级Upgrading from an older CLI从 v1.2 之前的 CLI 升级v1.2 起datahub docker quickstart使用的 docker-compose 文件与更早 CLI 安装的 DataHub不兼容。若你已用旧 CLI 装过 DataHub请按以下步骤升级备份数据推荐datahub docker quickstart --backup若无需保留数据可跳过移除旧安装datahub docker nuke重新全新安装datahub docker quickstart。⚠️ 不做备份将丢失全部已有数据。跨版本的完整破坏性变更清单见 docs/how/updating-datahub.md。CLI 中这一检查是自动执行的docker_cli.py 内置了MIGRATION_REQUIRED_INSTRUCTIONS可迁移路径备份 → nuke → 重装 → restore与REPAIR_REQUIRED_INSTRUCTIONS不可修复的旧安装回退 CLI 到 1.1 修复后再迁移或放弃数据直接 nuke 重装两套指引启动前检测到不兼容实例时会自动打印。为什么 Quickstart 不适合生产环境官方文档明确Quickstart 并非为生产环境设计推荐生产部署采用 Kubernetes配套 Helm Charts 可快速拉起见 docs/deploy/kubernetes.md。不建议用于生产的理由有三点默认凭据quickstart 的 compose 配置中内置了 DataHub 自身及其底层存储如 MySQL的默认凭据且部分组件开箱即无认证。这是为降低开发门槛的设计取舍不是生产最佳实践。例如 compose 文件中MYSQL_ROOT_PASSWORD: datahub、GMS 的METADATA_SERVICE_AUTH_ENABLED: false均可在 docker-compose.quickstart-profile.yml 中直接看到。端口全部暴露DataHub 各服务与后端存储使用 Docker 默认行为绑定所有网络接口地址便于开发调试但不适合生产网络环境。性能与运维能力受限quickstart 受限于单机资源无法水平扩展新版本发布往往需要停机窗口配置大体预置、难以灵活管理且默认跟随最新构建会强制更新到最新含未发布的构建。下一步Next StepsQuickstart 故障排查指南通过 UI 摄入元数据通过 CLI 摄入元数据向 DataHub 添加用户配置 OIDC 认证配置 JaaS 认证配置 DataHub 后端的元数据服务认证修改 quickstart 中的默认用户 datahub重建搜索索引restore-indices 相关文档【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
