批处理流处理大数据【免费下载链接】beamApache Beam is a unified programming model for Batch and Streaming data processing.项目地址https://gitcode.com/gh_mirrors/beam15/beam点击查看免费下载导读本文以 Apache Beam 官方《Dependencies Guide》为核心系统讲解 Beam 社区如何维护海量第三方依赖、如何识别与升级过期的依赖、如何在多组件共用依赖的场景下规避钻石依赖问题并给出可落地的 Java / Python SDK 依赖管理机制与升级操作流程。读完本文你将理解 Beam 顶层依赖定义BeamModulePlugin.groovy与 Python setup.py 分组依赖的设计思路掌握 Jenkins 周报 Dependabot 自动化、Vendoring封装/重打包机制以及依赖升级时的向后兼容性审查要求并能直接照抄其中的检查命令与升级脚本。一、为什么 Beam 如此重视依赖管理Beam 是统一的批流数据处理编程模型其仓库包含大量 RunnerFlink、Spark、Samza、Dataflow 等、IO 连接器Kafka、Pub/Sub、BigQuery、JDBC 等与各类扩展模块。这些组件共享大量第三方库而大多数用户并非只依赖 Beam 运行他们会把 Beam 与其他库打包进同一部署环境。此时用户环境中的其他依赖可能拉入与 Beam 不兼容的版本导致管线以未定义行为运行甚至直接崩溃更严重时用户可能完全无法在同一个部署中同时使用 Beam 与其他依赖。这种冲突并非 Beam 独有业内称之为Diamond Dependency Problem钻石依赖问题又称 Dependency Hell两个组件分别依赖同一个公共库的不同版本而这两个版本互不兼容。在 Beam 的场景里它具体表现为三种形态组件间覆盖版本冲突若组件 X 将依赖 D 从版本 a 覆盖为 b而组件 Y 与版本 b 不兼容同时使用 X 与 Y 的用户部署必然处于损坏状态传递依赖冲突Beam 的两个依赖共同依赖某个库却使用了该库的不兼容版本与外部库冲突用户同时使用 Beam 与其他库双方共享某个依赖却采用不兼容版本。此外运行时还可能进一步恶化Runner 特有的代码可能与某些模块引入的依赖不兼容一旦这些依赖泄漏到运行时管线同样会处于损坏状态。这正是后面要讲的 Vendoring封装政策存在的根本原因。二、Java SDK顶层统一声明依赖版本Beam Java SDK 的 Gradle 构建在 buildSrc/src/main/groovy/org/apache/beam/gradle/BeamModulePlugin.groovy 中定义了一组顶层依赖版本各种组件Runner、IO 连接器等可以选用这些依赖。源码注释明确说明了设计意图These versions are defined here because they represent a dependency version which should match across multiple Maven artifacts.这些版本在此定义是因为它们代表需要在多个 Maven 构件之间保持一致性的依赖版本。具体实现上BeamModulePlugin 通过project.ext.library导出按语言分组、按名称索引的依赖映射见 BeamModulePlugin.groovy// A map of maps containing common libraries used per language. To use: // dependencies { // compile library.java.slf4j_api // } project.ext.library [ java : [ activemq_amqp : org.apache.activemq:activemq-amqp:$activemq_version, avro : org.apache.avro:avro:1.11.3, aws_java_sdk_s3: com.amazonaws:aws-java-sdk-s3:$aws_java_sdk_version, grpc : io.grpc:grpc:$grpc_version, guava : com.google.guava:guava:$guava_version, // ... 数百个依赖条目 ] ]每个版本号在文件顶部以def xxx_version x.y.z形式集中声明例如def guava_version 33.1.0-jre、def grpc_version 1.62.2、def protobuf_version 3.25.3见 BeamModulePlugin.groovy并通过注释标注其来源如// [bomupgrader] determined by: com.google.api:gax, consistent with: google_cloud_platform_libraries_bom def gax_version 2.48.0其中被[bomupgrader]标注的版本由 GCP BOMlibraries-bom决定详见后文 GCP-BOM 升级一节。组件通常直接使用顶层版本但允许覆盖。不过官方政策见原文档明确要求组件应尽量在顶层声明依赖及版本覆盖属于罕见例外且必须附带解释性注释。因为一旦某个组件覆盖了版本就可能触发第一节所述的第一类冲突——这正是 Beam 希望极力避免的。三、Python SDKsetup.py 单文件分组依赖Python SDK 的依赖管理方式与 Java 不同所有依赖集中在 sdks/python/setup.py 中声明并按用途分组install_requires必装依赖见 setup.py。典型条目如dill0.3.1.1,0.3.2、cloudpickle~2.2.1、numpy1.14.3,1.27.0、protobuf3.20.3,4.26.0等其中多数带紧上界原因在注释中写得很清楚——序列化类依赖dill、cloudpickle、protobuf在任务提交端与运行端必须版本一致否则可能导致反序列化失败extras_require可选特性分组见 setup.py包括gcpGoogle Cloud 相关google-cloud-pubsub2.1.0,3、google-cloud-bigquery2.0.0,4等awsboto31.9,2azureAzure Storage 相关三件套interactive交互式分析ipython、ipykernel、ipywidgets等dataframe、dask、yaml、test、docs、ml_test等。关键差异在于Python SDK 的所有模块必须使用 setup.py 中定义的依赖版本且对大多数依赖允许自动升级到下一个主版本之前即a,b这类区间约束。由于版本来源单一、约束统一Python SDK 目前不会出现组件间版本覆盖冲突但第一节描述的另外两类依赖冲突传递依赖冲突、与外部库的冲突仍可能发生。值得注意的细节setup.py 注释还提到动态依赖必须单独列出否则 Dependabot 无法解析主列表这类依赖将收不到自动更新见 setup.py。四、识别过期依赖Jenkins 周报与手动排查保持依赖更新的一大半工作是发现问题。Beam 采用两条互补路径4.1 自动化的 Jenkins 周报Beam 目前通过一个每周执行的 Jenkins 任务尝试识别各 SDK 的过期依赖并生成一份每周报告分享到 Beam dev 邮件列表。原文档对报告内容给出明确要求Human readable reports on status of Beam dependencies are generated weekly by an automated Jenkins job and shared with the Beam community through the dev list. These reports should be concise and should highlight the cases where the community has to act on.关于 Beam 依赖状态的易读报告由自动化 Jenkins 任务每周生成并通过 dev 列表分享给社区。报告应当简洁并高亮需要社区采取行动的事项。仓库侧的证据是 buildSrc/src/main/groovy/org/apache/beam/gradle/BeamJenkinsPlugin.groovy该插件用于检测构建是否运行在 Jenkins 服务器上并据此切换构建行为如测试报告格式。4.2 手动识别紧急升级某些紧急依赖更新不会自动进入周报需要社区成员人工发现并尽早行动典型场景包括安全漏洞驱动某个依赖的 minor 版本修复了高危安全漏洞冲突触发Beam 某依赖的 minor 版本发布引发了新的依赖冲突这不适用于 Java SDK——Java SDK 依赖精确的 minor 版本见原文档。这类紧急升级可能几个月内都不会被 Jenkins 任务自动捕获因此社区必须主动识别并提前升级。五、Dependabot 自动化让升级以 PR 形式流转为了跟踪依赖升级过程Beam 仓库配置了 Dependabot自动为过期的依赖发起升级 PR。仓库根目录的 .github/dependabot.yml 给出了完整的配置实证覆盖四个生态version: 2 updates: - package-ecosystem: gomod directory: /sdks # Go SDK 模块清单 schedule: { interval: daily } - package-ecosystem: pip directory: /sdks/python # Python SDK setup.py schedule: { interval: daily } - package-ecosystem: gradle directory: / # Gradle 根构建 schedule: { interval: daily } ignore: # 忽略 GCP 相关依赖由 GCP-BOM 统一管理 - dependency-name: com.google.cloud:* - dependency-name: io.grpc:grpc-* - dependency-name: com.google.guava:* ... - package-ecosystem: github-actions directory: / schedule: { interval: daily } allow: - dependency-name: actions/* # 其他 github-actions 需 INFRA 审批配置中ignore列表的用意与前文呼应GCP 相关依赖由 libraries-bom 统一管理见第七节Guava、gRPC、protobuf 等被 vendored 的库则避免 Dependabot 盲目升级——这与原文档组件应在顶层定义依赖版本、重大升级需谨慎的政策一致。六、升级政策四条铁律识别出过期依赖后社区按以下政策执行升级。这些内容全部来自原文档是依赖治理的核心操作准则政策 1依赖及版本应在顶层声明。组件Runner、IO 连接器等等级声明只允许出现在罕见场景且必须附带注释解释覆盖原因。例如只被某个 Runner 使用、其他组件几乎不会引用的依赖可以在 Runner 层定义。政策 2明显过期的依赖必须升级为发布阻断项。无论是人工发现还是 Jenkins 周报识别显著过期的依赖都应产出一个blocker issue作为下个版本发布的阻断条件发布经理有权将该 blocker 推迟到后续版本或将其降级。该 blocker 适用于 Beam 的下一个major 和 minor 版本发布。对于人工识别的关键依赖更新社区成员应创建阻断下个发布的 Issue必要时还可触发patch 版本发布让关键修复尽快触达用户。政策 3周报必须简洁、聚焦行动项。见 4.1 节政策 4Java SDK 组件中可能泄漏并影响其他组件的依赖应当被 vendored。Vendoring 即复制第三方依赖的副本配合重打包repackaging使用可以让 Beam 组件依赖第三方库而不与其他组件产生冲突。Vendoring 需要逐案评估因为它会增加用户部署环境中依赖的总数。关于 blocker 机制在发布流程中的实际操作可参考仓库中的 contributor-docs/release-guide.md发布经理在构建 RC 之前会 triage 所有 release-blocking issues判断该问题是否为当前版本与已发布版本之间的回归且无简单规避方案并决定阻断或推迟到下一版本。七、Vendoring 机制源码级解读Vendoring 政策在仓库中有完整实现插件 buildSrc/src/main/groovy/org/apache/beam/gradle/VendorJavaPlugin.groovy 基于 shadow 插件完成重打包其头部注释明确了三条强制约定vendored artifactId 中嵌入的版本必须与被 vendored 库的版本完全一致包重定位前缀必须是org.apache.beam.vendor.canonical_library_name.version_identifier.升级被 vendored 库的版本必须同步触发 artifact 名称变更。例如 Guava 的 vendored 命名空间是org.apache.beam.vendor.guava.v32_1_2_jregRPC 的 vendored 版本工具类为 buildSrc/src/main/groovy/org/apache/beam/gradle/GrpcVendoring_1_60_1.groovy其中同样遵循版本号嵌入类名与命名空间的规则。插件还提供了validateVendoring任务依赖 shadowJar校验 vendored jar 不会暴露org.apache.beam命名空间之外的类一旦发现超出允许范围即抛出异常见 VendorJavaPlugin.groovy。这从构建层面保证了泄漏即失败。具体到 gRPC 的升级流程GrpcVendoring_1_60_1.groovy 给出三步操作先确定要包含的io.grpc库集合通常是上一版本的超集再用mvn dependency:tree梳理依赖树、判断可选依赖如 conscrypt是否需要最后通过 linkage 工具校验构建产物并跑 PR 中的单元与集成测试。八、依赖升级与向后兼容审查红线Beam 的 releases 遵循语义化版本Semantic Versioning规则版本号形如x.y.z其中x为主版本major可能向后不兼容且应很少发生、y为次版本minor应向后兼容、z为补丁版本patch同样应向后兼容。但在实践中重要修复尤其是安全补丁常以 minor 或 patch 形式发布因此 Beam 依赖较新的 minor 版本是健康的做法。在此前提下社区成员在更新依赖时需遵守以下审查红线minor 版本更新在大多数情况下应向后兼容但仍需逐一验证PR 审查者与 committer 必须在合并前检测可能引入向后不兼容 API 或功能变更的依赖更新且升级依赖的 PR 必须以 PR 评论形式附上这一验证声明对非实验性功能造成向后不兼容变更的依赖升级必须推迟到下一个 major 版本发布唯一例外是极端场景例如现有依赖存在安全漏洞、且只有更高主版本才修复且必须先在 Beam dev 邮件列表讨论对实验性功能的向后不兼容变更允许在 minor 版本中引入。为了把检测不兼容落到实处仓库提供了完整的工具链见 contributor-docs/java-dependency-upgrades.md推荐做法如下。8.1 找出受影响的 Gradle 子项目执行以下命令为每个项目生成依赖报告文本文件./gradlew dependencyReport然后在所有依赖报告中按 Maven artifact 标识搜索目标库grep -l guava find ./ -name dependencies.txt8.2 用 Linkage Checker 做前后对比分析升级 PR 必须附上升级前后的 linkage 分析结果以确保不引入新的 linkage errors。可直接使用仓库自带脚本 sdks/java/build-tools/beam-linkage-check.sh它会在当前工作区和 HEAD 上分别运行对比/bin/bash sdks/java/build-tools/beam-linkage-check.sh origin/master your branch name artifactId1,artifactId2,...脚本内部默认检查四个最容易出现依赖冲突的构件beam-linkage-check.shbeam-sdks-java-core beam-sdks-java-io-google-cloud-platform beam-runners-google-cloud-dataflow-java beam-sdks-java-io-hadoop-format其执行逻辑是先 checkout 基线分支生成 baseline 文件-PjavaLinkageWriteBaseline...再 checkout 提案分支读取 baseline 进行校验-PjavaLinkageReadBaseline...最终以退出码报告有无新增 linkage errors见 beam-linkage-check.sh。也可以手动单跑./gradlew -Ppublishing -PjavaLinkageArtifactIdsartifactId1,artifactId2,... :checkJavaLinkage典型输出形如Class org.brotli.dec.BrotliInputStream is not found; referenced by 1 class file org.apache.beam.repackaged.core.org.apache.commons.compress.compressors.brotli.BrotliCompressorInputStream (beam-sdks-java-core-...jar) Class org.apache.beam.vendor.bytebuddy.v1_9_3.net.bytebuddy.jar.asm.commons.ModuleHashesAttribute is not found; referenced by 1 class file ...分析完成后删除本地安装的 Beam SNAPSHOT 构件再继续rm -rf ~/.m2/repository/org/apache/beam最后在 PR 中提供需要运行的 Jenkins 测试套件清单相关 Jenkins 任务配置位于.test-infra/jenkins目录请 reviewer 运行相应测试。九、GCP-BOM 依赖升级一键脚本与手动诊断Beam 使用 Google Cloud 的libraries-bomGCP-BOM统一管理 Google Cloud 相关依赖并为此提供了升级脚本 scripts/tools/bomupgrader.py。其用法是python scripts/tools/bomupgrader.py latest_bom_version脚本会就地修改相关文件执行四步操作脚本 docstring 与原文档一致见 bomupgrader.py预处理 BeamModulePlugin.groovy确定需要同步的依赖生成一个空的 Maven 工程拉取需要变更的确切目标版本将结果写回 BeamModulePlugin.groovy即第一节看到的[bomupgrader]注释来源更新sdks/java/container/license_scripts/dep_urls_java.yaml中的 libraries-bom 版本。脚本内置的KNOWN_DEPS映射见 bomupgrader.py展示了从 BOM 反查 Beam 版本的关键路径例如grpc→io.grpc:grpc-netty用 grpc-netty 以挑选正确的 netty 版本、protobuf→com.google.protobuf:protobuf-java、arrow→org.apache.arrow:arrow-memory-core。当需要排查或修改脚本本身时也可用 Maven 命令手动核对一致的依赖覆盖版本export BOM_VERSION26.22.0 ; \ cd /tmp; \ wget https://repo1.maven.org/maven2/com/google/cloud/libraries-bom/$BOM_VERSION/libraries-bom-$BOM_VERSION.pom -O base.pom \ mvn help:effective-pom -f base.pom -Doutputeffective.pom cat effective.pom | \ grep -v dependencyManagement cleanup.pom \ mvn dependency:tree -f cleanup.pom十、总结Beam 依赖治理的闭环把原文档的政策与仓库实现拼在一起可以勾勒出 Beam 依赖管理的完整闭环声明Java 在 BeamModulePlugin.groovy 顶层集中声明版本GCP 相关由 libraries-bom 驱动Python 在 setup.py 按必装/可选分组声明区间约束发现Jenkins 每周自动生成过期依赖报告分享到 dev 列表Dependabot 按 .github/dependabot.yml 自动开升级 PR社区成员人工捕获安全漏洞等紧急升级决策显著过期的依赖升级成为下个版本的 blocker issue发布经理按 contributor-docs/release-guide.md 的规则 triage可能泄漏的依赖按 VendorJavaPlugin.groovy 的约定 vendored验证升级 PR 必须用 beam-linkage-check.sh 提供前后 linkage 对比并声明向后兼容性验证结果引入非实验性功能不兼容变更的升级一律推迟到下一主版本。这套机制的最终目标是让 Beam 在自身组件繁多、与用户环境深度共存的现实下把依赖地狱造成的管线损坏概率降到最低——对任何维护大型多组件开源项目或企业级统一数据平台的团队而言都具有直接的借鉴价值。附注本文依据仓库 website/www/site/content/en/contribute/dependencies.md 撰写并交叉验证了上述源码、脚本与配置文件。文中所引版本号如 guava 33.1.0-jre、grpc 1.62.2 等均以当前仓库实际内容为准未来版本更新请以仓库为准。赞分享批处理流处理大数据【免费下载链接】beamApache Beam is a unified programming model for Batch and Streaming data processing.项目地址https://gitcode.com/gh_mirrors/beam15/beam点击查看免费下载相关推荐Apache Beam 依赖治理与升级指南从依赖冲突到版本管理的工程实践Apache Beam 依赖治理与升级指南从依赖冲突到版本管理的工程实践 本文以 Apache Beam 仓库中的 Dependencies Guide ht大数据批处理流处理数据工程Apache SeaTunnel 第三方依赖 License 合规实践从 ASF 政策到依赖检查脚本的完整指南Apache SeaTunnel 第三方依赖 License 合规实践从 ASF 政策到依赖检查脚本的完整指南 本文是一份面向 SeaTunnelApach数据工程大数据批处理流处理Gradle 依赖管理实战指南从仓库配置、本地依赖到依赖冲突治理Gradle 依赖管理实战指南从仓库配置、本地依赖到依赖冲突治理 本文基于 YCBlogs 仓库中 Gradle学习笔记三管理依赖.md https://教程技术博客文档上一篇Wasmtime内存映射技术突破传统内存瓶颈实现10倍大数据处理性能飞跃下一篇D2R多开神器真的能让你告别重复登录的烦恼吗创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考