大数据批处理流处理数据工程【免费下载链接】beamApache Beam is a unified programming model for Batch and Streaming data processing.项目地址https://gitcode.com/gh_mirrors/beam4/beam点击查看免费下载Apache Beam 的 Python SDK 需要跟随 Python 年度发布节奏持续更新其支持版本矩阵。本文基于 Beam 官方贡献者文档 更新支持的 Python 版本指南系统讲解在 Apache Beam 仓库中新增一个 Python 版本如 3.15或移除一个 EOL 版本时需要改动的所有位置——从依赖升级、容器构建、tox 测试矩阵到 GitHub Actions 工作流、wheel 构建与发布校验脚本并结合当前仓库源码说明每一处改动的实际落点帮助维护者完整执行一次版本生命周期变更。一、背景为什么 Beam 需要持续管理 Python 版本Python 自 3.x 以来采用年度发布节奏每年 10 月发布新版本同时旧版本达到 EOLEnd-of-Life。这意味着在任意时间点Beam 最多需要同时支持五个不同的 Python 小版本。根据官方文档的定位移除 EOL 版本的优先级高于添加新版本因为 EOL 的 Python 版本在其上游依赖修复安全漏洞时自身可能无法获得相应的漏洞修复。当前仓库的版本支持现状从当前仓库的源码可以确认 Beam 现阶段的版本支持矩阵setup.py 中声明python_requires 3.10第 338 行这是pip install apache-beam时硬性约束用户解释器的下限apache_beam/init.py 第 7278 行实现了一个软警告机制当检测到运行解释器的sys.version_info.minor 9 or sys.version_info.minor 15时输出This version of Apache Beam has not been sufficiently tested on Python %s.%s的警告但允许导入继续非 Python 3 环境则直接抛出RuntimeError。这实际上把经验证支持区间当前为 3.103.14与物理下限3.0区分开来.github/actions/setup-default-test-properties/test-properties.json 集中定义了 CI 使用的版本矩阵ALL_SUPPORTED_VERSIONS为[3.10, 3.11, 3.12, 3.13, 3.14]LOWEST_SUPPORTED为[3.10]HIGHEST_SUPPORTED为[3.14]并单独列出ESSENTIAL_VERSIONS、各 Runner 交叉验证版本等。这一组文件正是后续新增/移除两个流程中所有改动的锚点。二、新增一个 Python 版本新增版本的目标是让 Beam 的 Python SDK 在新解释器上可安装、可构建、可通过全部单元与集成测试。整个流程可分为七个步骤。2.1 升级 Beam 的直接依赖首先要保证 Beam 的 direct dependencies 都有支持新 Python 版本的版本。复杂 C 扩展库如 pyarrow、numpy必须为新的 Python 版本提供预编译 wheel否则用户在新解释器上将无法安装。基础设施类库——Beam 构建依赖、cibuildwheel 及其他硬编码了 Python 版本范围的库——往往也需要一并升级。一个关键约束是部分依赖版本可能同时不支持 Beam 的最小和最大 Python 版本此时必须使用版本条件依赖environment markers。当前仓库中就有两个真实例子setup.py 第 522523 行google-apitools0.5.31,0.5.32; python_version 3.13, google-apitools0.5.35; python_version 3.13,pyproject.toml 第 2729 行为grpcio-tools按解释器版本给出三档 pingrpcio-tools1.62.1; python_version 3.12, grpcio-tools1.71.0; python_version 3.13 and python_version 3.14, grpcio-tools1.78.0; python_version 3.14,新增版本时这类带python_version标记的依赖清单是必须逐一检查的位置。2.2 添加新的 Beam Python 容器Beam 为每个支持的 Python 版本维护一个独立容器目录位于 sdks/python/container。当前仓库中已存在py310/、py311/、py312/、py313/、py314/五个子目录每个目录包含一个base_image_requirements.txt。以 py314/base_image_requirements.txt 为例文件头部注释说明了其生成方式# Autogenerated requirements file for Apache Beam py314 container image. # Run ./gradlew :sdks:python:container:generatePythonRequirementsAll to update. # Do not edit manually, adjust ../base_image_requirements_manual.txt or # Apache Beams setup.py instead, and regenerate the list.也就是说新版本的容器需求文件不是手工维护的修改 base_image_requirements_manual.txt 或 setup.py 后通过./gradlew :sdks:python:container:generatePythonRequirementsAll重新生成。该目录下的 common.gradle 负责容器镜像的公共构建逻辑新增py3XX/目录后由它统一接管。2.3 将新版本加入测试矩阵这是改动面最大的步骤之一涉及三类位置Tox 测试套件。tox.ini 的envlist与testenv段落按 Python 小版本枚举环境当前为envlist py310,py311,py312,py313,py314,py310-{cloud,cloudcoverage,dask},...,docs,lint,whitespacelint [testenv:py{310,311,312,313,314}] commands_pre python --version pip --version pip check bash {toxinidir}/scripts/run_tox_cleanup.sh deps numpy1.26.4 commands python apache_beam/examples/complete/autocomplete_test.py bash {toxinidir}/scripts/run_pytest.sh {envname} {posargs}每个解释器版本都有对应的py3XX-macos、py3XX-win、py3XX-cloud变体环境。新增版本时需要把这些花括号枚举{310,311,312,313,314}全部扩展为包含新的小版本号。Gradle 任务。各 Runner 测试矩阵通过 test-suites/gradle.properties 声明使用的 Python 版本例如dataflow_precommit_it_task_py_versions3.10,3.14 flink_validates_runner_precommit_py_versions3.14 spark_examples_postcommit_py_versions3.10,3.14 cross_language_validates_py_versions3.10,3.14该文件注释明确要求版本必须写成 major.minor 点分形式多个版本用逗号连接且不留空格。这些属性被 pre-commits、post-commits 等 Gradle 任务消费pre-commit 类任务通常落在最小支持版本3.10post-commit/validates 类任务则覆盖最小与最大版本。Runner 特有的版本检查。Dataflow、Flink、Spark、Prism 等 Runner 各自有独立的版本枚举位置gradle properties 之外还包括各 Runner 目录下的测试配置需要逐一确认。最后一步是修复在新版本上失败的测试。官方文档特别指出通常需要更新 Beam 的类型推断Type Inference代码。在源码中可以印证这一点apache_beam/typehints/opcodes.py 中散布着按解释器版本分叉的实现例如if sys.version_info (3, 11): ... if sys.version_info (3, 14): ... if (sys.version_info.major, sys.version_info.minor) (3, 12): ...这是因为 Beam 的类型推断大量依赖types、typing、opcode等标准库内部结构的反射而它们在每次 Python 小版本升级时都可能变化。新增版本时这些版本分叉处正是测试失败的高发区。2.4 添加 GitHub Actions 工作流新增版本后需要在 GitHub Actions 中为新版本创建测试工作流可参考 python_tests.yml 的结构。需要特别注意的是最小与最大 Python 版本被硬编码在大量工作流文件中此外还集中在 test-properties.json 中见第一节的LOWEST_SUPPORTED/HIGHEST_SUPPORTED字段。官方文档明确提示这一步可能产生数百处改动应当借助全局搜索与脚本化替换来降低遗漏风险。2.5 为新版本构建 wheel更新 .github/workflows/build_wheels.yml让 wheel 构建流程覆盖新 Python 版本。当前该工作流使用python-version: 3.11作为构建解释器用于运行构建工具链而 cibuildwheel 等组件负责矩阵化地为每个支持的解释器版本产出 wheel。2.6 更新__init__.py中的上限警告将 apache_beam/init.py 第 73 行的版本判断上限调整为下一个主版本if sys.version_info.major 3: if sys.version_info.minor 9 or sys.version_info.minor 15: warnings.warn( This version of Apache Beam has not been sufficiently tested on Python %s.%s. You may encounter bugs or missing features. % (sys.version_info.major, sys.version_info.minor))注意这里的语义minor 15表示 3.15 及更高版本尚未验证。新增 3.15 并验证通过后此值应上抬到 16使 3.15 落入已充分测试的区间。2.7 更新发布校验脚本最后把新版本加入发布release验证脚本。当前仓库中的对应实现是release/src/main/python-release/python_release_automation.sh第 22 行为for version in 3.10 3.11 3.12 3.13 3.14对每个版本执行发布前验证release/src/main/python-release/python_release_automation_utils.sh第 8593 行以if/elif链逐版本分发到对应的验证子任务python3.10至python3.14。新增版本时需在这两处同时补充分支。2.8 合并前提官方文档强调所有单元测试和集成测试必须全部通过后才能合并新版本支持若新增版本过程中出现新功能变更或回归应提交 issue 跟踪非 committer 提交 PR 后需要请求 committer 在 PR 上运行 seed job 以完整测试全部变更。文档给出的历史参考是 Python 3.12 支持相关的 PR 系列issue #29149、PR #30828 等可作为一次完整新增版本的改动清单模板。三、移除一个 Python 版本移除 EOL 版本的操作方向与新增相反但步骤同样细致。3.1 提升setup.py下限并更新警告将 setup.py 中python_requires从当前值3.10提升到下一个支持版本同步更新 apache_beam/init.py 中版本警告的下限判断如minor 9改为minor 10。这两个改动共同决定了用户在新旧版本上的安装行为与警告行为。3.2 移除不支持版本的测试套件需要处理的文件/目录包括迁移 GitHub Actions 工作流把旧版本专属的 workflow 迁移到下一个版本。注意有些 workflow 只在最小支持版本上运行如 lint、coverage 的 precommit这些环境可能使用了需要升级到新解释器才能运行的库迁移时要一并升级。官方建议在 Beam 主仓库中开分支直接落地这些改动以便运行新工作流做验证。从以下文件中移除该版本sdks/python/test-suites/gradle.properties各 Runner 的*_py_versions属性中出现的被移除版本例如dataflow_precommit_it_task_py_versions3.10,3.14中的3.10apache_beam/testing/tox目录把仅存在于最小版本目录下的 workflow 迁移到下一个最小版本目录apache_beam/testing/dataflow、apache_beam/testing/direct、apache_beam/testing/portable三个目录中对应版本的测试资产。从 Gradle 构建脚本中删除该版本的 task根目录 build.gradle.kts仓库根级与 settings.gradle.kts 中的版本相关 taskbuildSrc/src/main/groovy/org/apache/beam/gradle/BeamModulePlugin.groovy 中注册 Python 版本的插件逻辑。从 .github/workflows/build_wheels.yml 移除为旧版本构建 wheel 与 sdist 的支持从 sdks/python/tox.ini 中移除该版本的所有py3XX环境envlist与各个testenv:py{...}花括号枚举。3.3 删除旧版本的容器删除 sdks/python/container 下对应的py3XX/目录当前为py310/至py314/五个并确认generatePythonRequirementsAll等生成任务不再引用该版本。3.4 清理版本专属代码最后清扫只服务于被移除版本的代码典型位置有两类setup.py 中的版本条件依赖带python_version标记、且其版本区间只覆盖被移除版本的依赖行可以直接删除或合并区间参见第二节google-apitools的例子typehints 模块中的版本分叉opcodes.py、native_type_compatibility.py 等文件中sys.version_info (3, X)且 X 小于等于被移除版本下限的分支已成为死代码可以安全删除简化推断路径。四、总结Apache Beam 对 Python 版本的生命周期管理是一个横跨依赖、容器、测试矩阵、CI 工作流与发布脚本的系统工程改动域新增版本移除版本关键文件安装约束/警告上调__init__.py上限上调setup.py下限 警告下限setup.py、apache_beam/init.py依赖升级/增加版本条件依赖清理版本专属依赖setup.py、pyproject.toml容器新增py3XX/目录并重新生成 requirements删除py3XX/目录sdks/python/container测试矩阵扩展 tox envlist、gradle.properties收缩相应枚举tox.ini、test-suites/gradle.propertiesCI新增 workflow、更新版本矩阵迁移/删除 workflow.github/workflows、test-properties.jsonwheel 构建覆盖新解释器移除旧解释器build_wheels.yml发布校验补充版本分支删除版本分支python_release_automation.sh类型推断修复新解释器上的推断差异删除死版本分叉apache_beam/typehints/opcodes.py无论是新增还是移除底线要求一致全部单元测试与集成测试通过后才能合并且需要 committer 运行 seed job 做完整验证。掌握上述每个文件的具体位置与语义即可在仓库中独立完成一次 Python 支持版本的变更。赞分享大数据批处理流处理数据工程【免费下载链接】beamApache Beam is a unified programming model for Batch and Streaming data processing.项目地址https://gitcode.com/gh_mirrors/beam4/beam点击查看免费下载相关推荐Apache Airflow 支持版本全解析版本生命周期、Python/Kubernetes 支持策略与 EOL 管理Apache Airflow 支持版本全解析版本生命周期、Python/Kubernetes 支持策略与 EOL 管理 Apache Airflow 是一套用后端任务调度工作流自动化数据编排批处理数据工程流程编排Argilla Python SDK 完整安装指南pip extras、develop 分支与版本管理Argilla Python SDK 完整安装指南pip extras、develop 分支与版本管理 Argilla 是面向 AI 工程师与领域专家构建高质数据标注人工智能NLPMLOpsRAGApache Beam Python SDK 本地开发指南多版本 Python 环境、pytest/tox 测试体系与容器依赖更新Apache Beam Python SDK 本地开发指南多版本 Python 环境、pytest/tox 测试体系与容器依赖更新 本文基于 Apache B大数据批处理流处理数据工程上一篇如何使用LemurTLS证书管理的终极解决方案下一篇Qwopus3.5-9B-Coder-MTP开发者指南如何快速集成到你的AI应用系统创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考