中国风网站模板html,山西建设工程协会网站,网络广告策略有哪些,陈欧做聚美优品网站自 Google Dataflow 模型被提出以来#xff0c;流批一体就成为分布式计算引擎最为主流的发展趋势。流批一体意味着计算引擎同时具备流计算的低延迟和批计算的高吞吐高稳定性#xff0c;提供统一编程接口开发两种场景的应用并保证它们的底层执行逻辑是一致的。对用户来说流批一…自 Google Dataflow 模型被提出以来流批一体就成为分布式计算引擎最为主流的发展趋势。流批一体意味着计算引擎同时具备流计算的低延迟和批计算的高吞吐高稳定性提供统一编程接口开发两种场景的应用并保证它们的底层执行逻辑是一致的。对用户来说流批一体很大程度上减少了开发维护的成本但同时这对计算引擎来说是一个很大的挑战。
作为 Dataflow 模型的最早采用者之一Apache Flink 在流批一体特性的完成度上在开源项目中是十分领先的。本文将基于社区资料和笔者的经验介绍 Flink 目前1.10流批一体的现状以及未来的发展规划。
概况
相信不少读者都知道Flink 遵循 Dataflow 模型的理念: 批处理是流处理的特例。不过出于批处理场景的执行效率、资源需求和复杂度各方面的考虑在 Flink 设计之初流处理应用和批处理应用尽管底层都是流处理但在编程 API 上是分开的。这允许 Flink 在执行层面仍沿用批处理的优化技术并简化掉架构移除掉不需要的 watermark、checkpoint 等特性。 图1. Flink 经典架构
在 Flink 架构上负责物理执行环境的 Runtime 层是统一的流处理上面分别有独立的 DataStream 和 DataSet 两个 API两者基于不同的任务类型Stream Task/Batch Task和 UDF 接口Transformation/Operator。而更上层基于关系代数的 Table API 和 SQL API 虽然表面上是统一的但实际上编程入口Environment是分开的且内部将流批作业分别翻译到 DataStream API 和 DataSet API 的逻辑也是不一致的。
因此要实现真正的流批一体Flink 需完成 Table/SQL API 的和 DataStream/DataSet API 两层的改造将批处理完全移植到流处理之上并且需要兼顾作为批处理立身之本的效率和稳定性。目前流批一体也是 Flink 长期目标中很重要一点流批一体的完成将标志着 Flink 进入 2.x 的新大版本时代。
流批一体完成以后理想的架构如下: 图2. Flink 未来架构
其中 Planner 从 Table/SQL API 层独立出来变为可插拔的模块而原先的 DataStream/DataSet 层则会简化为只有 DataStream图 2 中的 StreamTransformation 和 Stream Operator 是 Stream DAG 的主要内容分别表示 UDF 和执行 UDF 的算子DataSet API 将被废弃。
Table/SQL API 的改进
Table/SQL API 的改造开始得比较早截止 1.10 版本发布已经达到阶段性的流批一体目标。然而在 1.7 版本时Table API 只是作为基于 DataStream/DataSet API 的 lib并没有得到社区的重点关注。
而当时阿里的 Blink 已经在 Table/SQL 上做了大量的优化为了合并 Blink 的先进特性到 Flink阿里的工程师推进社区重构了 Table 模块的架构[5]并将 Table/SQL API 提升为主要编程 API。
自此 Table 层中负责将 SQL/Table API 翻译为 DataStream/DataSet API 的代码被抽象为可插拔的 Table Planner 模块而 Blink 也将主要的特性以 Blink Planner 的形式贡献给社区于是有了目前两个 Planner 共存的状态。 图3. Flink 目前过渡架构
Flink 默认的 Legacy Planner 会将 SQL/Table 程序翻译为 DataStream 或 DataSet 程序而新的 Blink Planner 则统一翻译为 DataStream 程序。也就是说通过 Blink PlannerFlink Table API 事实上已经实现了流批一体的计算。要了解 Blink Planner 是如何做到的首先要对 Planner 的工作原理有一定的了解。
Legacy Planner 对于用户逻辑的表示在 Flink 架构中不同层的演变过程如下: 图4. Legacy Planner 架构
用基于 Calcite 的 SQL parser 解析用户提交的 SQL将不同类型的 SQL 解析为不同 Operation比如 DDL 对应 CreateTableOperationDSL 对应 QueryOperation并将 AST 以关系代数 Calcite RelNode 的形式表示。根据用户指定 TableEnvironment 的不同分别使用不同的翻译途径将逻辑关系代数节点 RelNode 翻译为 Stream 的 Transformation 或者 Batch 的 Operator Tree。调用 DataStream 和 DataSet 对应环境的方法将 Transformation 或 Operator Tree 翻译为包含执行环境配置的作业表示即 StreamGraph 或 Plan。优化 StreamGraph 和 Plan并包装为可序列化的 JobGraph。
因为 Batch SQL 与 Streaming SQL 在大部分语法及语义上是一致的不同点在于 Streaming SQL 另有拓展语法的来支持 Watermark、Time Characteristic 等流处理领域的特性因此 SQL parser 是 Batch/Stream 共用的。关键点在于对于关系代数 RelNode 的翻译上。 图5. Legacy Planner RelNode
Flink 基于 Calcite RelNode 拓展了自己的 FlinkRelNodeFlinkRelNode 有三个子类 FlinkLogicalRel、DataSetRel 和 DataStreamRel。FlinkLogicalRel 表示逻辑的关系代数节点比如常见的 Map 函数对应的 FlinkLogicalRel 是 DataStreamCalc。DataSetRel 和 DataStreamRel 则分别表示 FlinkLogicalRel 在批处理和流处理下各自的物理执行计算。
在 SQL 优化过程中根据编程入口的不同 FlinkLogicalRel 被转化为 DataSetRel 或 DataStreamRel。BatchTableEnvironment 使用 BatchOptimizer 基于 Calcite Rule 的优化而 StreamTableEnvironment 使用 StreamOptimizer 进行优化。比如 TableScan 这样一个 RelNode在 Batch 环境下被翻译为 BatchTableSourceScan在 Stream 环境下被翻译为 StreamTableSourceScan而这两类物理关系代数节点将可以直接映射到 DataSet 的 Operator 或 DataStream 的 Transformation 上。
上述的方式最大的问题在于 Calcite 的优化规则无法复用比如对数据源进行过滤器下推的优化那么需要给 DateSetRel 和 DataStreamRel 分别做一套而且 DataSet 和 DataStream 层的算子也要分别进行相应的修改开发维护成本很高而这也是 Blink Planner 推动流批一体的主要动力。
如上文所说Blink Planner 做的最重要的一点就是废弃了 DataSet 相关的翻译途径将 DateSetRel 也移植到 DataStream 之上那么前提当然是 DataStream 要可以表达 DataSet 的语义。熟悉批处理的同学可能会有疑问: 批处理特有的排序等算子在 DataStream 中是没有的这将如何表达
事实上 Table Planner 广泛采用了动态代码生成可以绕过 DataStream API 直接翻译至底层的 Transformation 和 StreamOperator 上并不一定需要 DataStream 有现成的算子因此使用 Blink Planner 的 Table API 与 DataStream API 的关系更多是并列的关系。这也是 FLIP-32[5] 所提到的解耦 Table API 和 DataStream/DataSet API 的意思: Decouple table programs from DataStream/DataSet API Allow table programs to be self-contained. No need for a Stream/ExecutionEnvironment entrypoint anymore. A table program definition is just API that reads and writes to catalog tables. Table 改造完成后整个 API 架构如下这也是目前 1.10 版本已经实现的架构: 图6. Blink Planner 架构
事实上早前版本的 DataStream 对批作业的支持并不是太好为了支持 Blink Planner 的 Batch on StreamDataStream 方面也先做了不少的优化。这些优化是对于 Table API 是必要的因此在 Blink Planner 合并到 Flink master 的前置工作这将和 DataStream 还未完成的改进一起放在下文分析。
另外虽然 Blink Planner 在计算上是流批一体的但 Flink Table API 的 TableSource 和 TableSink 仍是流批分离的这意味着目前绝大数批处理场景的基于 BatchTableSource/BatchTableSink 的 Table 无法很好地跟流批一体的计算合作这将在 FLIP-95[9] 中处理。
DataStream API 的改进
在 DataStream API 方面虽然目前的 DataStream API 已经可以支持有界数据流但这个支持并不完整且效率上比起 DataSet API 仍有差距。为了实现完全的流批一体Flink 社区准备在 DataStream 引入 BoundedStream 的概念来表示有界的数据流完全从各种意义上代替 DataSet。
BoundedStream 将是 DataStream 的特例同样使用 Transformation 和 StreamOperator且同时需要继承 DataSet 的批处理优化。这些优化可以分为 Task 线程模式、调度策略及容错和计算模型及算法这几部分。
Task 线程模型
批处理业务场景通常更重视高吞吐出于这点考虑Batch Task 是 pull-based 的方便 Task 批量拉取数据。Task 启动后会主动通过 DataSet 的 Source API InputFormat 来读取外部数据源每个 Task 同时只读取和处理一个 Split。
相比之下一般流处理业务场景则更注重延迟因此 Stream Task 是 push-based 的。
DataStream 的 Source API SourceFunction 会被独立的 Source Thread 执行并一直读取外部数据源源不断地将数据 push 给 Stream Task。每个 Source Thread 可以并发读取一个到多个 Split/Partition/Shard。 图7. Stream/Batch 线程模型图来源 Flink Forward
为了解决 Task 线程模型上的差异Flink 社区计划重构 Source API 来统一不同外部存储和业务场景下的 Task 线程模型。总体的思路是新增一套新的 Source API可以支持多种线程模型覆盖流批两种业务需求具体可见 FLIP-27[6] 或笔者早前的一篇博客[7]。目前 FLIP-27 仍处于初步的开发阶段。
调度策略及容错
众所周知批处理作业和流处理作业在 Task 调度上是很不同的。批处理作业的多个 Task 并不需要同时在线可以根据依赖关系先调度一批 Task等它们结束后再运行另一批。
相反地流作业的所有 Task 需要在作业启动的时候就全部被调度然后才可以开始处理数据。前一种调度策略通常称为懒调度Lazy Scheduling后一种通常称为激进调度Eager Scheduling。为了实现流批一体Flink 需要在 StreamGraph 中同时支持这两种调度模式也就是说新增懒调度。
随调度而来的问题还有容错这并不难理解因为 Task 出现错误后需要重新调度来恢复。而懒调度的一大特点是Task 计算的中间结果需要保存在某个高可用的存储中然后下个 Task 启动后才能去获取。
而在 1.9 版本以前Flink 并没有持久化中间结果。这就导致了如果该 TaskManager 崩溃中间结果会丢失整个作业需要从头读取数据或者从 checkpoint 来恢复。这对于实时流处理来说是很正常的然而批处理作业并没有 checkpoint 这个概念批处理通常依赖中间结果的持久化来减小需要重算的 Task 范围因此 Flink 社区引入了可插拔的 Shuffle Service 来提供 Suffle 数据的持久化以支持细粒度的容错恢复具体可见 FLIP-31[8]。
计算模型及算法
与 Table API 相似同一种计算在流处理和批处理中的算法可能是不同的。典型的一个例子是 Join: 它在流处理中表现为两个流的元素的持续关联任何一方的有新的输入都需要跟另外一方的全部元素进行关联操作也就是最基础的 Nested-Loop Join而在批处理中Flink 可以将它优化为 Hash Join即先读取一方的全部数据构建 Hash Table再读取另外一方进行和 Hash Table 进行关联见图8。 图8. Join 批处理优化
这种差异性本质是算子在数据集有界的情况下的优化。拓展来看数据集是否有界是 Flink 在判断算子如何执行时的一种优化参数这也印证了批处理是流处理的特例的理念。因此从编程接口上看BoundedStream 作为 DataStream 的子类基于输入的有界性可以提供如下优化
提供只可以应用于有界数据流的算子比如 sort。对某些算子可以进行算法上的优化比如 join。
此外批处理还有个特点是不需要在计算时输出中间结果只要在结束时输出最终结果这很大程度上避免了处理多个中间结果的复杂性。因此BoundedStream 还会支持非增量non-incremental执行模式。这主要会作用于与 Time Charateritic 相关的算子:
Processing Time Timer 将被屏蔽。Watermark 的提取算法不再生效Watermark 直接从开始时的 -∞ 跳到结束时的 ∞。
总 结
基于批处理是流处理的特例的理念用流处理表达批处理在语义上是完全可行的而流批一体的难点在于批处理场景作为特殊场景的优化。对 Flink 而言难点主要体现批处理作业在 Task 线程模型、调度策略和计算模型及算法的差异性上。目前 Flink 已经在偏声明式的 Table/SQL API 上实现了流批一体而更底层偏过程式的 DataStream API 也将在 Flink 2.0 实现流批一体。
Tips原版文章及详细参考资料请见下方原文链接
原文链接
http://www.whitewood.me/2020/03/30/Flink-流批一体的实践与探索/
作者介绍
林小铂网易游戏高级开发工程师负责游戏数据中心实时平台的开发及运维工作目前专注于 Apache Flink 的开发及应用。探究问题本来就是一种乐趣。 # 社区活动推荐 # 普惠全球开发者这一次格外与众不同首个 Apache 顶级项目在线会议 Flink Forward 全球直播中文精华版来啦聚焦 Alibaba、Google、AWS、Uber、Netflix、新浪微博等海内外一线厂商经典 Flink 应用场景最新功能、未来规划一览无余。点击下方链接可了解更多大会详情https://developer.aliyun.com/live/2594?spma2c6h.14242504.J_6074706160.2.3fca361f4cYyQx
原文链接 本文为云栖社区原创内容未经允许不得转载。
