数据目录数据治理数据血缘后端前端数据工程数据集成【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址https://gitcode.com/GitHub_Trending/da/datahub点击查看免费下载导读本文以 DataHub 仓库中metadata-ingestion/tests/integration/db2/NOTES_ON_TESTING_DB2.md为核心骨架系统讲解 DataHub 的 Db2 元数据摄取ingestion模块在集成测试层面的完整方法论为什么自动化测试只针对 Db2 for LUW 运行、如何通过 Docker 在 CI 中拉起真实 Db2 实例并注入测试数据、测试场景矩阵如何覆盖视图限定符、大小写敏感、注释、存储过程等边界情况以及针对 Db2 for IBM iAS/400如何借助 PUB400.COM 公共服务器进行手工验证。读完本文你将掌握 DataHub Db2 集成测试的完整链路并理解测试背后的源码级原理。一、Db2 家族与测试变体选择的背景IBM Db2 并非单一数据库产品而是一个庞大的产品家族主流变体包括Db2 for LUWLinux/Unix/Windows面向通用服务器是唯一提供免费社区版Db2 Community Edition且能够在大多数开发者的个人电脑上运行的变体Db2 for IBM iAS/400运行在 IBM Power Systems 上的企业级数据库通常需要真实硬件或服务器环境没有免费可本地运行的版本Db2 for z/OS运行在大型机mainframe上的版本是企业关键业务的核心环境成本极高。正如 NOTES_ON_TESTING_DB2.md 开头所述these integration tests only run against Db2 for LUW, as that is the only variant of Db2 that is freely-available and runs on most users computers.这一选择直接决定了整个测试矩阵的边界自动化集成测试以 Db2 for LUW 为唯一目标而 IBM iAS/400与 z/OS 依赖外部真实环境走的是不同的验证路径。这一策略与 DataHub 的 Db2 摄取模块在 db2_pre.md 中声明支持三平台LUW 用SYSCAT.*、z/OS 用SYSIBM.*、IBM i 用QSYS2.*并不矛盾——支持范围与自动化测试范围是两回事后者还受限于测试资源可用性。二、自动化集成测试基础设施Docker 拉起真实 Db2Db2 集成测试的核心思路是在 CI 环境中用 Docker 启动一个真实、可连接的 Db2 for LUW 实例然后运行 DataHub 摄取流水线对真实数据做元数据提取。相关资源全部位于metadata-ingestion/tests/integration/db2/目录。2.1 docker-compose.yml容器定义与两个关键排障点docker-compose.yml 是测试环境的核心其要点如下services: testdb2: container_name: testdb2 hostname: db2 # Pinned: latest moves without notice, changing setup behavior under CI. image: icr.io/db2_community/db2:12.1.4.0 platform: linux/amd64 privileged: true entrypoint: - /bin/sh - -c - - echo export DB2_4K_DEVICE_SUPPORTON /etc/profile.d/db2_4k.sh exec /var/db2_setup/lib/setup_db2_instance.sh environment: DBNAME: testdb DB2INST1_PASSWORD: password LICENSE: accept # speed up start REPODB: false AUTOCONFIG: false ARCHIVE_LOGS: false ports: - 50000:50000 volumes: - db2data:/database volumes: db2data:配置中有几个值得注意的工程细节镜像版本固定注释明确指出latest moves without notice, changing setup behavior under CI因此固定到icr.io/db2_community/db2:12.1.4.0。这是保证 CI 结果可复现的关键实践。DB2_4K_DEVICE_SUPPORTON的注入方式Db2 默认按 512 字节对齐做直接 I/O而 CI 机器的存储往往是 4K 原生扇区此时pwrite会以EINVAL失败导致CREATE DATABASE以SQL0293N错误退出。由于容器启动脚本通过su - db2inst1切换用户会清空环境变量常规的environment:注入方式无效因此改为在 entrypoint 中先写入/etc/profile.d/db2_4k.sh再执行官方设置脚本。数据卷必须落在真实文件系统上注释明确指出数据库路径若位于 overlayfs 容器层上CREATE DATABASE可能因表空间容器访问问题失败SQL0293N所以通过命名卷db2data:/database挂载。加速启动的优化项REPODB: false、AUTOCONFIG: false、ARCHIVE_LOGS: false用于缩短实例初始化时间。2.2 测试驱动test_db2.py 的完整流水线test_db2.py 是集成测试的驱动主体其执行流程可以拆解为四个阶段阶段一等待数据库就绪且能识别假成功测试通过docker_compose_runner启动容器后调用wait_for_port(docker_services, testdb2, DB2_PORT, timeout600, checkeris_db2_up)等待localhost:50000端口可用。关键在于is_db2_up函数的设计test_db2.pyDb2 官方容器镜像的设置脚本是fail-open的——即使CREATE DATABASE失败它只打印警告(!) Failed to create ...或 SQL 错误并继续最终仍输出 Setup has completed.服务器会启动但数据库不存在。因此测试不能靠 grep 容器日志判断就绪而必须真实发起一次 SQLAlchemy 连接def _attempt_db2_connection() - bool: engine sqlalchemy.create_engine(DB2_URL) try: with engine.connect(): return True except Exception: return False finally: engine.dispose()此外连接尝试被放入一个 daemon 线程并以 30 秒硬超时兜底原因是轮询循环的整体超时只在两次 checker 调用之间计时若connect()内部握手卡死既不能阻塞轮询循环也不应阻塞解释器退出。同时测试会先扫描容器日志一旦发现(!) Failed to create或SQL0293N立即抛出带诊断信息的RuntimeErrortest_db2.py。诊断信息_db2_environment_diagnostics会输出文件系统类型df -T /database、挂载选项、内核异步 I/O 余量aio-nr/aio-max-nr、设备扇区大小以及db2diag.log中 Severe/Error 级日志——这些正是定位CREATE DATABASE失败的核心证据。阶段二按语句切分并执行 setup.sqlDb2 的 Docker 镜像没有内置启动时执行 SQL 脚本的能力因此 test_db2.py 用sqlglot以db2方言对setup.sql做分词切分语句以分号分隔但BEGIN/END块如存储过程定义必须保持为一个整体。实现通过统计BEGIN/CASE与END令牌的嵌套计数来决定分号是否作为语句边界。切分后的语句通过 SQLAlchemy 引擎在事务中依次执行连接串为DB2_URL fdb2ibm_db://db2inst1:passwordlocalhost:{DB2_PORT}/testdb阶段三运行摄取流水线并输出 MCE每个测试用例从对应的 YAML 配置读取type: db2与schema_pattern过滤规则然后动态注入host_port、database、username、password构造完整的 DataHubPipelineconfig_dict { source: source, sink: { type: file, config: {filename: output_path}, }, } pipeline Pipeline.create(config_dict) pipeline.run() pipeline.raise_from_status()输出为 MCEMetadata Change EventJSON 文件落到tmp_path下。阶段四与 golden 文件比对使用mce_helpers.check_golden_file将本次输出与仓库中预置的*_mces_golden.json对比并忽略时间戳类字段ignore_paths[ rroot\[\d\]\[aspect\]\[json\]\[lastUpdatedTimestamp\], rroot\[\d\]\[aspect\]\[json\].\[\d\]\[auditStamp\]\[time\], rroot\[\d\]\[proposedSnapshot\].\[aspects\].\[created\]\[time\], ]2.3 运行前提与平台限制测试通过pytestmark pytest.mark.integration_batch_4归入集成测试第 4 批次在 setup.cfg 中声明为mark tests to run in batch 4 of integration tests并且test_db2_ingest带有条件跳过标记pytest.mark.skipif( not (platform.machine() x86_64 or platform.system() Darwin), reasonibm_db is not available for Linux ARM, )这与摄取模块本身的限制一致Db2Source.__init__在非amd64/x86_64且非 macOS 的环境会直接抛出NotImplementedErrordb2.py因为ibm_db驱动在 Linux ARM 上不可安装。但注意 db2.py 特意将ibm_db_sa的导入推迟到patch_dialect中保证源模块在无驱动的架构上也能被导入用户能获得友好报错而非笼统的依赖缺失。三、测试场景矩阵五组用例与 setup.sql 的精心设计setup.sql 一次性创建了 5 个 schema每个 schema 对应一个独立的测试场景由 5 个 YAML 配置通过schema_pattern分别圈定。这种一份初始化脚本 多份过滤配置的结构是测试数据复用的高效组织方式。配置文件名schema_pattern 过滤测试关注点db2_basic.ymlbasic基础的表、视图摄取以及视图基于表的下游 lineagedb2_case_sensitivity.ymlcase_sensitive引号包裹的大小写敏感 schema/表/列名db2_comments.ymlcomments表、列、视图及其列的 COMMENT 提取db2_procedures.ymlprocedures存储过程的定义、注释与 lineagedb2_view_qualifier.ymlqualifier_.*视图体引用其他 schema 未限定名时的限定符解析每个用例都有对应的 golden 文件db2_basic_mces_golden.json、db2_case_sensitivity_mces_golden.json、db2_comments_mces_golden.json、db2_procedures_mces_golden.json、db2_view_qualifier_mces_golden.json。从 db2_basic_mces_golden.json 可以看到输出 MCE 的形态——例如数据库容器实体以urn:li:container:...表示携带containerPropertiescustomProperties 中包含platform: db2、env: PROD、database: TESTDB、status、dataPlatformInstanceurn:li:dataPlatform:db2与subTypes等 aspect这正是 DataHub 对数据库层级容器的标准建模。各场景对应的源码实现细节大小写敏感patch_dialectdb2.py将dialect.requires_name_normalize置为False并覆写_reflector.normalize_name/denormalize_name为恒等函数以规避ibm_db_sa无条件小写化导致无法区分大小写敏感表名的问题get_db_name则把数据库名统一upper()以匹配 Db2 不区分大小写的语义。视图限定符view qualifierDb2 的视图LUW 与 z/OS在解析未限定名时查找的是创建视图时会话所在的 schema而非视图自身所在 schema。get_view_default_db_schemadb2.py通过查询SYSCAT.VIEWS.QUALIFIERLUW或SYSIBM.SYSVIEWS.PATHSCHEMASz/OS获取隐式 schema并对其进行引号包裹以保证大小写敏感名能无损通过 sqlglot 行级 lineage 解析。setup.sql中的qualifier_test/qualifier_target两个 schema 正是为此构造视图qualifier_test.myview定义在 qualifier_test 中但引用的是 qualifier_target 下未限定名的mytable。存储过程get_procedures_for_schemadb2.py按平台分派——LUW 查SYSCAT.ROUTINES、z/OS 查SYSIBM.SYSROUTINES、IBM i 查QSYS2.SYSROUTINES——提取名称、语言、定义文本、注释与创建/修改时间并同样处理QUALIFIER过程创建时的默认 schema。setup.sql中procedures_target.source_table → target_table的插入语句即用于验证过程的 lineage 解析。四、针对 Db2 for IBM iAS/400的测试方法自动化测试不覆盖 IBM i是因为不存在免费可本地运行的 IBM i 环境。原文档给出的替代方案是使用公共测试服务器PUB400.COM并明确了以下操作路径注册账号在 PUB400.COM 注册新账户重置密码用 5250 telnet 客户端如tn5250连接服务器重置密码配置连接参数将PUB400.COM作为host_portdatabase传任意字符串IBM i 下连接不依赖具体数据库名执行摄取验证复用 DataHub 的 db2 源scheme 可按需使用db2pyodbc400如 db2_post.md 所述IBM i Access ODBC Driver 需单独安装。为什么没有 golden 文件原文档给出了明确原因PUB400.COM 为每个用户创建独立的 schema因此不同用户摄取生成的容器 URN 会不同无法用仓库内固定的 golden 文件做比对。这是对golden 文件对比这类确定性测试方法的边界认知——当数据面不可控时应退回到手工验证或结构性断言而不是强行固化期望值。另外注意NOTES_ON_TESTING_DB2.md 还强调不要对 PUB400.COM 跑自动化测试以免过度占用这一公共资源。这体现了开源项目对免费公共设施的审慎使用原则。五、Db2 for z/OS状态与开放问题对于 z/OS源码层面db2.py 中SYSIBM.SYSVIEWS、SYSIBM.SYSROUTINES分支以及_split_zos_pathschemas对PATHSCHEMAS的解析已具备支持逻辑且PATHSCHEMAS中会混入SYSFUN、SYSIBM、SYSIBMADM、SYSPROC等系统级 schema实现会先剔除它们若剩余多于一个 schema 则抛出NotImplementedError以显式暴露尚未支持的场景。但测试层面缺少免费可用的 z/OS 环境。原文档最后以开放的协作姿态写道If you find a freely available Db2 for z/OS server to test against, please update this note.也就是说z/OS 的自动化测试仍是一个待社区贡献者填补的空白任何发现免费 z/OS 测试资源的开发者都可以更新该文档为测试矩阵补上最后一块拼图。六、总结Db2 集成测试方法论要点回顾整个测试体系可以提炼出几条可迁移到其他数据源集成测试的方法论测试目标与资源现实对齐优先选择免费、可本地运行的平台变体LUW做自动化对无免费环境的变体IBM i、z/OS要么借助公共服务器做受控的手工验证要么显式标注为待填补空白。容器化真实实例 真实连接就绪判定不要依赖容器日志的Setup has completed而应以真实数据库连接成功为就绪标准并对fail-open设置脚本的失败模式做主动检测与诊断输出。一份初始化 SQL 多组 schema 过滤配置用schema_pattern将不同边界场景隔离既能复用同一份测试数据又让每个用例的期望输出保持小而清晰。golden 文件对比 忽略确定性噪声时间戳、runId等字段在比对时显式忽略使断言聚焦于实体结构、URN 与 metadata 内容本身。源码级排障注释DB2_4K_DEVICE_SUPPORT、overlayfs 卷、ibm_db_sa名称归一化等坑点都在配置与代码注释中留下了详实说明这些注释本身就是不可多得的实战排障文档。对于希望为 DataHub 贡献 Db2 相关改动或为其他 SQL 数据源搭建类似集成测试的开发者本文涉及的仓库路径可作为起点测试驱动 test_db2.py、环境编排 docker-compose.yml、测试数据 setup.sql、源实现 db2.py 以及平台能力说明 db2_pre.md 与 db2_post.md。赞分享数据目录数据治理数据血缘后端前端数据工程数据集成【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址https://gitcode.com/GitHub_Trending/da/datahub点击查看免费下载相关推荐DataHub Airflow Plugin Docker 测试指南用 tox Docker 快速跑通集成测试与 Golden File 更新DataHub Airflow Plugin Docker 测试指南用 tox Docker 快速跑通集成测试与 Golden File 更新 导读 本指数据目录数据治理数据血缘后端前端数据工程数据集成orchestrator与Docker Compose集成快速搭建测试环境orchestrator与Docker Compose集成快速搭建测试环境 在数据库运维工作中快速搭建可靠的测试环境是验证MySQL拓扑管理工具功能的关键步后端数据库DataHub Airflow 插件 Docker 测试环境实战基于 tox 与 Docker Compose 的隔离测试指南DataHub Airflow 插件 Docker 测试环境实战基于 tox 与 Docker Compose 的隔离测试指南 DataHub 的 Airfl数据目录数据治理数据血缘后端前端数据工程数据集成创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考