ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

DataHub 的 Hive Metastore 3.x 多 Catalog 集成测试指南

DataHub 的 Hive Metastore 3.x 多 Catalog 集成测试指南 数据目录数据治理数据血缘后端前端数据工程数据集成【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址https://gitcode.com/GitHub_Trending/da/datahub点击查看免费下载为什么需要专门搭建 HMS 3.x 多 Catalog 测试环境随着 Hive 3.0 引入原生 multi-catalog 能力默认hivecatalog可扩展spark_catalog、iceberg_catalog等企业中同一套 Hive MetastoreHMS后端可能同时托管 Spark、Iceberg、Hive 等多种表格式的元数据。DataHub 的hive-metastore连接器需要验证能否正确识别多 catalog 命名空间、同名表在不同 catalog 下是否被正确隔离、URN 生成是否受 catalog 影响。本指南聚焦 DataHub 仓库中专门为 HMS 3.x 多 catalog 场景搭建的集成测试环境hms3 测试目录完整介绍其快速启动步骤、测试数据模型、两个关键配置项catalog_name与include_catalog_name_in_ids的用法与 URN 生成规则并深入源码级原理与测试用例帮助你在本地复现多 catalog 元数据摄取验证。读完本文你将掌握用 Docker 一键拉起 HMS 3.x、用脚本灌入多 catalog 测试数据、通过环境变量控制测试执行方式、理解 catalog 名称如何影响数据集 URN并能基于 golden file 机制对摄取结果做回归校验。HMS 3.x 测试环境快速启动前置条件Docker 与 Docker Compose用于拉起 HMS 3.x 容器Python 3 虚拟环境仓库推荐venv路径为metadata-ingestion/venvpymetastore与thriftPython 库测试与数据灌入脚本依赖已安装metadata-ingestion包pip install -e .或按 metadata-ingestion 开发文档 安装启动与运行全流程按官方文档整个流程分为四步# 1. 启动 HMS 3.x在 metadata-ingestion 目录下执行 cd tests/integration/hive-metastore docker compose -f docker-compose.hms3.yml up -d # 2. 等待 HMS 就绪约 60-90 秒然后灌入测试数据 cd ../../.. source venv/bin/activate python tests/integration/hive-metastore/hms3/setup-catalogs.py # 3. 运行集成测试HMS3_EXTERNAL1 跳过 docker-compose 启动HMS3_SKIP_SETUP1 跳过灌数脚本 HMS3_EXTERNAL1 HMS3_SKIP_SETUP1 pytest tests/integration/hive-metastore/test_hive_metastore_catalog.py -v # 4. 测试完成后清理 docker compose -f tests/integration/hive-metastore/docker-compose.hms3.yml down -v要点说明第 3 步的两个环境变量是短路开关HMS3_EXTERNAL1表示 HMS 已由你手动启动或已存在于外部环境测试不再执行docker compose upHMS3_SKIP_SETUP1表示测试数据已手动灌好测试跳过 setup 脚本。两者可以同时使用。第 4 步的-v会连带删除名为hms3-data的命名卷保证下次启动是全新环境。Docker Compose 环境构成docker-compose.hms3.yml 是这套测试环境的核心编排文件关键设计如下services: hive-metastore-hms3: image: apache/hive:3.1.3 # 官方 Apache Hive 3.1.3 镜像内嵌 Derby 元数据库 container_name: hive-metastore-hms3 environment: SERVICE_NAME: metastore # 以 metastore 模式启动 ports: - 9084:9083 # 宿主机 9084 - 容器 9083避开其他 HMS 实例 volumes: - hms3-data:/opt/hive/data - ./hms3/setup-catalogs.py:/opt/setup-catalogs.py:ro # 灌数脚本挂载进容器 healthcheck: test: [CMD-SHELL, nc -z localhost 9083 || exit 1] interval: 10s timeout: 5s retries: 30 start_period: 90s # 与约 60-90 秒就绪一致设计意图可从测试需求反推端口 9084HMS 原生 Thrift 端口是 9083测试特意映射到宿主机 9084避免与开发者本机已有的其他 HMS 实例冲突。命名卷hms3-data持久化/opt/hive/data含内嵌 Derby 数据库保证多轮测试数据可复用。健康检查容器内用nc探测 9083 端口start_period: 90s恰好对应 README 中连接被拒约 60-90 秒的提示——HMS 3.x 首次启动要初始化元数据库这是Connection refused问题的最常见原因。测试数据模型多 Catalog 与命名空间隔离setup-catalogs.py 通过 HMS 3.x Thrift API 灌入三层测试数据catalog → database → table。README 中的测试数据总览CatalogDatabaseTableshivetest_dbusers, eventsspark_catalogtest_dbusers (different schema)iceberg_catalogtest_dbtransactions其中刻意设计了一处陷阱users表同时存在于hive与spark_catalog且字段完全不同用于验证命名空间隔离。灌数脚本的核心逻辑脚本按顺序执行以下步骤对应run_setup函数setup-catalogs.py连接 HMSconnect_to_hms封装了带重试的连接逻辑MAX_RETRIES 30每次间隔 2 秒总计约 60 秒解决 HMS 启动慢的问题。探测 catalog 能力调用client.get_catalogs()列出已有 catalog验证 HMS 3.x 是否开启多 catalog。创建 catalog通过CreateCatalogRequest创建spark_catalog与iceberg_catalog。创建数据库在三个 catalog 中分别建库注意test_db在每个 catalog 中都有——这是命名空间隔离测试的关键。创建表hive.test_db.users四列id/name/email/created_athive.test_db.events四列 分区键event_datespark_catalog.test_db.users三列user_id/username/active与 hive 中的 users 字段完全不同表属性带spark.table.version: 2.0iceberg_catalog.test_db.transactions三列EXTERNAL_TABLEtable_type: ICEBERG验证遍历所有 catalog 打印库表清单确认数据就绪。脚本支持--host与--port参数默认localhost:9084既可在宿主机直接运行也被测试 fixture 以模块导入方式复用。HMS 3.x 的 Catalog 访问协议细节从 hive_thrift_client.py 可以看到连接器如何与多 catalog HMS 交互列出某 catalog 下的数据库使用{catalog_name}#模式调用get_databasesHMS 3.x 约定如spark_catalog#精确获取表使用get_table_req并携带catNamecatalog_name字段取某 catalog 内指定库的表使用{catalog_name}#{db_name}模式。这些 API 封装见HiveThriftClient的get_all_databases、get_table、get_fields等方法是连接器支持多 catalog 的底层基础与测试数据模型一一对应。配置项catalog_name 与 include_catalog_name_in_ids配置文件示例源自 READMEsource: type: hive-metastore config: host_port: localhost:9084 catalog_name: spark_catalog # 可选默认 hive include_catalog_name_in_ids: true # 是否把 catalog 名编入 URN两个配置项在源码中的定义在 hive_metastore_config.py 中配置项类型默认值作用域说明catalog_nameOptional[str]None仅connection_type: thriftHMS 3.x 多 catalog 部署时指定要读取的 catalog不设置则默认hiveinclude_catalog_name_in_idsboolFalse共享是否把 catalog 名加入数据集 URN默认不加入保持与单 catalog 时代 URN 兼容注意catalog_name的取值语义配置为spark_catalog时连接器只摄取该 catalog 下的库表未配置时回退到默认hivecatalog这一回退逻辑见 hive_metadata_processor.py 的_get_db_name优先级依次为catalog_name→metastore_db_name→database→ 兜底hive。catalog_name 在数据获取链路上的作用catalog_name并非只影响 URN它直接决定读哪些元数据。在 hive_thrift_fetcher.py 中_get_catalog_name()返回该配置值并被传入get_all_databases、iter_table_rows、iter_view_rows、iter_schema_rows、iter_table_properties_rows等全部数据获取方法每个方法再透传给HiveThriftClient中带 catalog 语义的 Thrift 调用。也就是说catalog_name在连接器 → Thrift 客户端 → HMS API整条链路上生效。URN 生成规则README 给出的两组 URN 对照不含 catalogurn:li:dataset:(urn:li:dataPlatform:hive,test_db.users,PROD)含 catalogurn:li:dataset:(urn:li:dataPlatform:hive,spark_catalog.test_db.users,PROD)include_catalog_name_in_ids还影响数据集标识符的解析。在 hive_metastore_source.py 的get_db_schema中开启时标识符按catalog.db.table三段解析取前两段分别作为 catalog 与 db关闭时标识符按db.table两段解析catalog 段被忽略。对应地hive_metadata_processor.py 在组装数据集平台实例等 aspect 时同样以该配置决定是否拼接 catalog 前缀。整体效果是开启后 catalog 成为数据集标识的一部分从而在 URN 层面把不同 catalog 中的同名表区分开。集成测试与 Golden File 校验测试文件概览test_hive_metastore_catalog.py 是本环境的集成测试入口包含三组场景默认 catalog 摄取test_ingest_default_catalog不配置catalog_name验证摄取hive.test_db的 users/eventsURN 不含 catalog 前缀。显式 catalog 摄取test_ingest_spark_catalogcatalog_name: spark_cataloginclude_catalog_name_in_ids: falseURN 仍为test_db.users。含 catalog 的 URN 摄取test_ingest_spark_catalog_with_catalog_idsinclude_catalog_name_in_ids: trueURN 变为spark_catalog.test_db.users。另有test_urn_without_catalog_name/test_urn_with_catalog_name两个纯 URN 断言测试直接检查输出 MCE 文件中是否包含或不包含spark_catalog.test_db.users字样。此外还有两个直接针对 Thrift API 的测试test_catalog_api_list_catalogs验证三个 catalog 都存在test_catalog_api_namespace_isolation用get_table_req分别取hive.test_db.users与spark_catalog.test_db.users断言二者列集合不同hive 版含emailspark 版含active从 API 层证明命名空间隔离真实生效。Golden File 机制三个摄取测试各自对应一份 golden 文件MCE 快照位于 hms3 目录hive_metastore_hms3_default_catalog_mces_golden.jsonhive_metastore_hms3_spark_catalog_mces_golden.jsonhive_metastore_hms3_spark_catalog_with_ids_mces_golden.json测试通过mce_helpers.check_golden_file将本次摄取结果与 golden 文件逐字段比对。由于时间戳、文件统计类属性每次运行都会变化测试定义了IGNORE_PATHS针对 old format 的transient_lastDdlTime、numfiles、totalsize、create_date与IGNORE_PATHS_V2对应 v2 路径的lastModified、created、COLUMN_STATS_ACCURATE等进行豁免。从 golden 文件可以看到摄取产物的形态容器级containerPropertiesname 为 catalog 名、customProperties 含 platform/env/database、dataPlatformInstance、subTypes等 aspect 依次 UPSERT且所有 MCE 的runId与测试名一一对应如hms3-spark-catalog-ids-test。这意味着新增表结构或调整配置后只要输出与 golden 不符测试即失败——这是对连接器行为的强回归保障。测试默认跳过机制该测试模块默认在 CI 中不执行pytestmark中设置了skipif仅当设置了HMS3_EXTERNAL1或RUN_HMS3_TESTS1才运行见 test_hive_metastore_catalog.py。原因是 HMS 3.x 的 Docker 环境存在平台兼容性问题部分架构下apache/hive:3.1.3镜像无法正常运行。本地复现时务必显式设置其中一个环境变量。测试还依赖两个 fixturehms3_runner通过docker_compose_runner启动 Compose 文件并用wait_for_port等待 9083 端口就绪超时 180 秒loaded_hms3以importlib动态加载setup-catalogs.py模块并调用run_setup(hostlocalhost, port9084)把灌数逻辑直接复用进测试生命周期若HMS3_SKIP_SETUP1则跳过。故障排查README 给出的排障表IssueSolutionConnection refusedHMS takes ~60-90s to startpymetastore not foundpip install pymetastore thrift结合源码可补充两点Connection refused 的等待策略setup-catalogs.py内置 30 次 × 2 秒的重试总等待约 60 秒通常足以覆盖 HMS 启动窗口若仍失败用docker compose -f tests/integration/hive-metastore/docker-compose.hms3.yml logs -f hive-metastore-hms3观察容器日志确认 metastore 是否完成初始化。依赖缺失pymetastore与thrift是灌数脚本与部分测试直接 import 的库建议在metadata-ingestion的虚拟环境中一并安装避免与系统 Python 冲突。将测试配置迁移到真实摄取场景理解了测试环境后可以很容易地把同样能力用于生产摄取。一个对照示例source: type: hive-metastore config: connection_type: thrift # 多 catalog 仅支持 thrift 连接 host_port: your-hms-host:9083 use_kerberos: false # 若启用 Kerberos参考 kerberos_service_name 等参数 catalog_name: spark_catalog # 只摄取 spark_catalog include_catalog_name_in_ids: true # 让同名表在 URN 层相互独立 database_pattern: allow: [^test_db$] # 与测试一致的正则过滤几点来自源码的注意事项catalog_name与include_catalog_name_in_ids均标注为仅 thrift 连接类型相关能力前者明确只对 thrift 生效SQL 直连模式connection_type: sql不提供多 catalog 支持。同时 validate_thrift_settings 规定 thrift 模式只能使用mode: hive。include_catalog_name_in_ids一旦开启现有 URN 会改变会对下游引用产生连锁影响从单 catalog 迁移到多 catalog 时建议先在测试环境验证 URN 变化再决定是否开启。结语HMS 3.x 多 catalog 是混合数据湖表格式场景下的关键能力。通过metadata-ingestion/tests/integration/hive-metastore这套可复现的测试环境你可以快速验证 DataHub 的hive-metastore连接器在多 catalog 下的元数据摄取正确性理解catalog_name与include_catalog_name_in_ids的完整语义并借助 golden file 机制保障行为回归。相关可深入研读的仓库文件hms3 README测试环境使用说明setup-catalogs.py多 catalog 测试数据灌入实现docker-compose.hms3.ymlHMS 3.x 容器编排test_hive_metastore_catalog.py集成测试与 URN 断言hive_metastore_config.py连接器全部配置项定义hive_thrift_client.py带 catalog 语义的 Thrift 调用封装赞分享数据目录数据治理数据血缘后端前端数据工程数据集成【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址https://gitcode.com/GitHub_Trending/da/datahub点击查看免费下载相关推荐DataHub 集成 Databricks 全指南Unity Catalog、Hive 与 Spark 元数据打通方案DataHub 集成 Databricks 全指南Unity Catalog、Hive 与 Spark 元数据打通方案 导读 本文基于当前开源仓库中 meta数据目录数据治理数据血缘后端前端数据工程数据集成Awesome BigData数据湖元数据Hive Metastore与AWS Glue Catalog终极指南Awesome BigData数据湖元数据Hive Metastore与AWS Glue Catalog终极指南 在大数据时代数据湖已成为企业存储和分析海量文档教程SeaTunnel Hive Source Connector 全面指南从 Hive Metastore 到多格式数据读取SeaTunnel Hive Source Connector 全面指南从 Hive Metastore 到多格式数据读取 SeaTunnel 的 Hive数据集成ETL大数据批处理流处理变更数据捕获创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表