门户网站建设软件,电商直播,展览设计网站推荐,手机app开发用的是什么语言Flink-Storm 是 Flink 官方提供的用于 Flink 兼容 Storm 程序 beta 工具#xff0c;并且在 Release 1.8 之后去掉相关代码。本文主要讲述 58 实时计算平台如何优化 Flink-Storm 以及基于 Flink-Storm 实现真实场景下大规模 Storm 任务平滑迁移 Flink。
背景
58 实时计算平台…Flink-Storm 是 Flink 官方提供的用于 Flink 兼容 Storm 程序 beta 工具并且在 Release 1.8 之后去掉相关代码。本文主要讲述 58 实时计算平台如何优化 Flink-Storm 以及基于 Flink-Storm 实现真实场景下大规模 Storm 任务平滑迁移 Flink。
背景
58 实时计算平台旨在为集团业务部门提供稳定高效实时计算服务主要基于 Storm 和 Spark Streaming 构建但在使用过程中也面临一些问题主要包括 Storm 在吞吐量不足以及多集群带来运维问题Spark Streaming 又无法满足低延迟的要求。Apache Flink 开源之后其在架构设计、计算性能和稳定性上体现出的优势使我们决定采用 Flink 作为新一代实时计算平台的计算引擎。同时基于 Flink 开发了一站式高性能实时计算平台 Wstream支持 Flink jarStream SqlFlink-Storm 等多样化任务构建方式。
在完善 Flink 平台建设的同时我们也启动 Storm 任务迁移 Flink 计划旨在提升实时计算平台整体效率减少机器成本和运维成本。
Storm vs Flink 尽管 Flink 作为高性能计算引擎可以很好兼容 Storm但在业务迁移过程中我们仍然遇到了一些问题
1 .用户对 Flink 的学习成本
重新基于 Flink 开发耗费工作量Stream-SQL 虽然可以满足快速开发减少学习成本和开发工作量但无法满足一些复杂场景。
因此我们决定采用 Flink 官方提供的 Flink-Storm 进行迁移在保障迁移稳定性同时无需用户修改 Storm 代码逻辑。
Flink-Storm 原理 通过 Storm 原生 TopologyBuilder 构建好 Storm topology。 FlinkTopology.createTopology(builder) 将 StormTopology 转换为 Flink 对应的 Streaming Dataflow。 SpoutWrapper 用于将 spout 转换为 RichParallelSourceFunctionspout 的OutputFields转换成 source 的T ypeInformation。 BoltWrapper 用于将 bolt 转换成对应的 operator其中 grouping 转换为对 spout 的 DataStream 的对应操作。 构建完 FlinkTopology 之后就可以通过 StreamExecutionEnvironment 生成 StreamGraph 获取 JobGraph之后将 JobGraph 提交到 Flink 运行时环境。
实践
Flink-Storm 作为官方提供 Flink 兼容 Storm 程序为我们实现无缝迁移提供了可行性但是作为 beta 版本在实际使用过程中存在很多无法满足现实场景的情况主要包括版本功能 bug复杂逻辑兼容无法支持 yarn 等下面将主要分为平台层面和用户层面讲述我们的使用和改进。 平台层面
1. 版本
当前线上使用 Apache Flink 1.6 版本Flink-Storm 模块基于 Storm 1.0 开发我们平台运行 Storm 版本为 0.9.5 和 1.2 。
1.1 对于 Storm 1.2 运行任务Storm 1.0 API 完全兼容 1.2 版本因此只需切换 Flink-Storm 模块依赖的 storm-core 到 1.2. 1.2 对于 Storm 0.9.5 任务由于 Storm 1.0 API 无法兼容 0.9.5需要修改依赖 storm-core 为 0.9.5同时修改 Flink-Storm 模块中所有与 Storm 相关的 API主要是切换 package 路径。 1.3 重新构建 flink-storm 包 mvn clean package -Dmaven.test.skiptrue -Dcheckstyle.skiptrue
2.功能
2.1 传递语义保证
Storm 使用 ACK 机制来实现传递语义保证我们没有将 Storm 的 ACK 机制移植到Flink-Storm。因此某些依赖 ACK 机制的功能会受到限制。比如Kafka spout 将消费状态存储在 ZK状态的更新需要依赖 ACK 机制tuple 树结束后spout 才会触发状态更新表示这条消息已经被完全处理从而实现 at least once 的传递保证。Storm 也提供了at most once 的支持spout 发送消息后无需等待 tuple 树结束直接触发状态更新。我们使用了 Storm 的实现 at most once 的方式在 Kafka spout 实现 at most once 的基础上通过实现 Flink Checkpoint 的状态机制实现了 Flink-storm 任务的 at least once。Storm 任务迁移到 Flink传递保证不变。 2.2 tick tuple 机制
Storm 使用 tick tuple 机制实现定时功能消息超时重发、Bolt 定时触发等功能都要依赖 tick tuple 机制。Storm 0.9.5 版本没有实现窗口功能用户可以使用 tick tuple 机制简单实现窗口功能。我们同样为 Flink-Storm 增加了 tick tuple 机制的支持使用方式也和 Storm 中使用方式一样配置 topology.tick.tuple. freq.secs 参数即开启了 tick tuple 功能。 2.3 多输入下 AllGrouping 支持
AllGrouping 分组方式对应于 Flink 是 Broadcast。如图bolt-1 有两个输入这种情况下原 flink-storm 的实现spout-2 到 bolt-1 的数据分区的表现形式和RebalanceFlink 术语一样而不是 Broadcast。我们优化了这种场景使其数据分组表现和 Storm 中是一样的。 3.Runtime
Flink-Storm 默认支持 local 和 standalong 模式任务提交无法将任务提交到 yarn 集群我们在建设 Flink 集群一开始就选择了 yarn 模式便于集群资源管理和统一实时计算平台因此需要自行实现支持 yarn 的 runtime 功能这里主要涉及 yarn client 端设计。
YARN Client 实现机制 整个模块主要分为四个部分其中 client 用于调用 Flink-Storm 程序转化接口得到 Flink jobGraph。配置参数用于初始化 Flink 及 yarn 相关配置构建运行时环境命令行工具主要用于更加灵活的管理。yarnClient 主要实现 ApplicationClientProtocol 接口完成与 ResourceManager 与 ApplicationMaster 的交互实现 Flink job 提交和监控。 4.任务部署
为便于任务提交和集成到 Wstream 平台提供类似 Flink 命令行提交方式 用户层面
1.maven 依赖
平台将编译好的包上传到公司 maven 私服供用户下载对应版本 Flink-Storm 依赖包 2.代码改动
用户需要将 Storm 提交任务的方式改成 Flink 提交其他无需变动。 总结
通过对 Fink-Storm 的优化和使用我们已经顺利完成多个 Storm 集群任务迁移和下线在保障实时性及吞吐量的基础上可以节约计算资源 40% 以上同时借助 yarn 统一管理实时计算平台无需维护多套 Storm 集群整体提升了平台资源利用率减轻平台运维工作量。
原文链接 本文为云栖社区原创内容未经允许不得转载。
