Apache Flink 在同程艺龙实时计算平台的研发与应用实践

  • 时间:
  • 浏览:2
  • 来源:uu快3新平台_uu快3诀窍_讨论群

另一累积业务方主要是数据开发&挖掘,大伙的业务场景更繁复,业务需求变化及应用迭代很频繁,更关注实时应用的性能,大伙喜欢用编程语言如:Java,scala 来开发实时应用。

前面介绍了大伙在实时计算平台易用性方面如:SQL,监控,日志,血缘,保存点等功能点上做的开发工作,删改都是要是除了平台功能开发之外还有更多的工作内容是用户没有感知到的。如何障实时应用运行稳定性,在这方面大伙积累了没有来过多实践经验,与此一块儿大伙也在 Github 上建立了 Tongcheng-Elong 组织,并将修复后的源代码贡献到 Apache 社区。其中有 十多少 patch 肯能被社区接收合并。接下来分享一些大伙遇到的稳定性问题报告 报告 和提供的出理 方案。

删改都是要是大伙提供了通用的实时计算平台,但会 一些用户想使用 Flink,除此之外还时需在平台上增加些更符合其业务特点的功能,对此大伙也开放了大伙实时计算平台的 API 接口给到业务方,让业务根据其自身场景特点来加速实时应用的变现和落地。

目前实时计算平台已支撑近千个实时任务运行,服务公司的市场、机票、火车票、酒店、金服、国旅、研发等各个业务条线。下面主要结合实时计算平台来分享下大伙在 Flink 落地过程中的一些实践经验及思考。

首届 Apache Flink 极客挑战赛重磅开启,聚焦机器学习与性能优化两大热门领域,5万奖金等你拿,加入挑战请点击:

▼ Apache Flink 社区推荐 ▼

支持维表关联

Apache Flink 及大数据领域顶级盛会 Flink Forward Asia 2019 重磅开启,目前正在征集议题,限量早鸟票优惠ing。了解 Flink Forward Asia 2019 的更多信息,请查看:

梳理清楚逻辑前一天,大伙发现社区也没有修复你四种 问题报告 报告 。同样,大伙也积极向社区进行提交PR修复6[8]。修复你四种 问题报告 报告 ,时需通过 3 个 PR,逐步进行完善,详情见 FLINK-12246、FLINK-12219、FLINK-12247。

使用 Calcite 对上述 validator 阶段获取的可执行 SQL 进行解析,将 SQL 解析出另一个多 语法树,通过迭代的方式,搜索到对应的维表,并结合上述 validator 阶段获取的维表信息实例化对应的 SideOperator 对象,前一天通过 RichAsyncFunction 算子生成新的 DataStream,最后重新注册表并执行一些 SQL,大伙一块儿支持账号密码直连和公司研发提供的 DAL 方式。

通过对比现有的指标分类整理系统,包括 InfluxDB、StatsD、Datadog 等系统再结合公司的指标分类分类整理系统,大伙最终决定采用 Prometheus 作为指标系统。但会 在开发过程中大伙发现 Flink 只支持 Prometheus 的拉模式分类分类整理数据,此模式时需提前知道集群的运行主机以及端口等信息,适合于单集群模式。

为了更好的为两类用户提供支持,实时计算平台一块儿支持四种 类型的任务:FlinkSQL 和 FlinkStream。平台整体架构如图所示:

Flink 采用了 Chandy-Lamport 的快照算法来保证一致性和容错性,在实时任务的运行期间是通过 Checkpoint [1]机制来保障的。肯能升级tcp连接,重启tcp连接,任务的运行周期现在开始,window 内的具体情况或使用 mapstate 的带具体情况算子(Operator)所保存的数据就会丢失了,为了出理 你四种 问题报告 报告 ,给用户提供平滑升级tcp连接方案从而保障数据准确出理 ,大伙实时计算平台提供了从内部人员触发 Savepoint 功能,在用户手动重启任务的前一天,可不还能否选折 最近一段时间内执行成功的保存点来恢复此人 的tcp连接。平台从保存点恢复任务操作如图所示。

提升平台易用性还有另一个多 重要的地方要是日志,日志分为操作日志,启动日志,业务日志,运行历史等日志信息。其中比较难出理 的要是用户代码中打印的业务日志。肯能 Flink 任务是分布式执行的,不同的 TaskManager 的出理 节点一定会有一份日志,业务看日志要分别打开多个 TaskManager 的日志页面。

在 2015 年初,为了可不还能否分类整理到用户在 PC,APP 等平台上的行为轨迹,大伙现在开始开发实时应用。那时可选的技术架构还是比较少的,实时计算框架这块,当时比较主流的有 Storm 和 Spark-streaming。综合考虑实时性,接入难度,大伙最终选折 使用基于 Storm 构建了第另一个多 版本的用户行为轨迹分类整理框架。后续随删改都是要是时业务的增多,大伙发现 Storm 肯能远远必须满足大伙对数据端到端出理 准确一次(Exactly-Once)语义的需求,但会 对于流量高峰来临时要是能平滑的背压(BackPressure),在大规模集群的支持上 Storm 要是足报告 报告 。经过充分的调研后,大伙在 2018 年初选折 基于 Flink 开发同程艺龙新一代实时计算平台。

这里主要是根据上述 validator 阶段获取的 Source 配置信息,根据指定参数实例化出该对象,但会 调用 registerTableSource 方式将 TableSource 注册到 environment,从而完成了源表的注册。

根本愿因是 Flink 底层采用 Curator 的 LeaderLatch 做分布式锁服务,在 Curator-2.x 的版本中对于网络瞬断没有容忍性,当肯能网络抖动、机器繁忙、zk集群短暂无响应一定会愿因 curator 将具体情况置为 suspended,正是你四种 suspended 具体情况愿因了所有任务的重启。

Flink Table 输出 Operator 基类是 TableSink,大伙这里继承的是 AppendStreamTableSink,根据上述 validator 阶段获取的 Sink 配置信息,根据指定参数实例化出该对象,但会 调用 registerTableSink 方式将 TableSink 注册到 environment。

validator:从 SqlNode 中提取执行的 SQL 和 Source、Sink、维表对应的配置信息

executor:利用 validator 获取的信息借助 - Flink 的 API 得到对应的JobGraph

通过 Yarn Client 提交构建好的 Flink 任务,提交成功返回 ApplicationID

如下图所示,可不还能否方便地在实时计算平台上 FlinkSQL 编辑器内完成 FlinkSQL 任务的开发,目前线上运行有 1150+ 的 FlinkSQL 任务在运行。

除了 FlinkSQL 外,平台上还有一半的实时任务是一些业务场景更繁复,通过代码来编写开发的任务。对此大伙提供了 RTC-FlinkStream 模块来让用户上传此人 本地打包后的 FAT-JAR,通过资源管理平台来让用户对 JAR 做版本管理控制,方便用户选折 运行指定的任务版本,FlinkStream 任务开发界面如图所示。

以 Flink 任务运行的指标(Metrics)监控来说,当 Flink tcp连接提交至集群前一天,大伙时需的是分类分类整理任务的实时运行 Metrics 数据,通过你四种 数据可不还能否实时监控任务的运行具体情况,相似于,算子的 CPU 耗时、JVM 内存、tcp连接数等。你四种 实时 Metrics 指标对任务的运维、调优等有着至关重要的作用,方便及时发现报警,进行调整。

在开发实时计算平台前,大伙有过大量实时应用业务的经验,大伙发现使用实时计算的业务方主要有两类:

大伙的存储组件比较多,在使用 Flink-Connector 来读写相关存储组件的如:RocketMQ、HDFS、Kudu、Elasticsearch 也发现过你四种 Connector 的 Source/Sink 不足报告 报告 ,大伙在修复前一天也提交了 PR 反馈到社区:

继承 ScalarFunction 肯能继承 TableFunction,时需从用户提交的 SQL 中获取要使用的自定义函数类名, 前一天通过反射获取实例,判断自定义 Function 属于上述哪种类型,但会 调用 TableEnvironment.registerFunction 即可完成了 UDF 的注册,最后用户就可不还能否在 SQL中使用自定义的 UDF。

在完成 Flink Pushgateway 的相关工作后,为了方便用户查看此人 Flink 任务的吞吐量,出理 延迟等重要监控信息,大伙为用户配置了监控页面,方便用户在实时计算平台上快速定位出任务性能问题报告 报告 ,如通过大伙实时平台监控页面提供的图表,具体指标为 flink_taskmanager_job_task_buffers_outPoolUsage 来快速判断实时任务的 Operator 算是发生反压具体情况[2]。

而作为企业用户,更多的是将 Flink 任务部署在 YARN 等集群上,此时,Flink 的 JobManager、TaskManager 的运行是由 YARN 统一调度,主机以及是端口一定会动态的,而 Flink 只支持的拉模式难以满足大伙需求。没有来过多大伙通过增加 Prometheus 的 Pushgateway 来进行指标的分类分类整理,此模式属于推模式,架构如图所示。一块儿,大伙也积极的向社区贡献了你四种 新形状[4] ,目前 PR 肯能被合并,详情见 FLINK-9187。

作者:同城艺龙数据中心 Flink 小分队(谢磊、周生乾、李苏兴)

Reference:[1]https://www.ververica.com/blog/differences-between-savepoints-and-checkpoints-in-flink

肯能在 Flink 在 1.8 版本前一天社区方向主要集中在 Flink Stream 出理 这块,大伙也主要应用 Flink 的流计算来替换 storm 及 spark streaming。但会 随着近期 Flink 1.9 的发布,Blink 分支合并进入 Flink 主分支,大伙也打算在 Flink Batch 这块尝试一些应用来落地。

https://developer.aliyun.com/special/ffa2019

大伙在集群运维过程中发现,在偶发的具体情况下,Flink 任务会在 YARN 集群上空跑。此时,在 YARN 层面的问题报告 报告 是任务发生 RUNNING 具体情况,但会 进入到 Flink WebUI,会发现此时所有的 TaskManager 删改退出,并没有任务在运行。你四种 具体情况下,会造成的 YARN 资源的浪费,一块儿也给运维人员带来困扰,为你四种 TaskManager 都退出了,JobManager 不退出呢?甚至给平台监控任务运行具体情况带来误判,认为任务还在运行,但实际任务早挂了。

此外根据其提供的 API 接口编写 TableSource 和 TableSink 异常繁琐,不仅要了解 Flink 各种 Operator 的 API,时需对各个组件的相关接入和调用方式有一定了解(比如 Kafka、RocketMQ、Elasticsearch、HBase、HDFS 等),但会 对于只熟悉 SQL 进行数据分析的人员直接编写 FlinkSQL 任务时需较大的学习成本。

鉴于以上愿因,大伙构建了实时计算平台的 RTC-FlinkSQL 开发模块并对 FlinkSQL 进行扩展,让这累积用户在使用 FlinkSQL 的前一天只时需关心做你四种 ,而不时需关心为什在么在做。不时需没有来过多的关心tcp连接的实现,要是专注于业务逻辑。

对于该问题报告 报告 的临时出理 方案是在使用 Elasticsearch 6.x 的 RestHighLevelClient 的前一天暂时停止使用 setBulkFlushInterval 配置, 要是通过 Flink 自身的 checkpoint 机制来触发数据定时 Flush 到 ElasticSearch Server 端。真正彻底出理 方式是构建单独的tcp连接池提供给 ReryHandler 来使用。要是大伙也向 Elasticsearch 社区提交了 issue 及 PR 来修复你四种 问题报告 报告 [10]。在你四种 过程中发现也顺便修复了 Flink 在任务重试前一天 transport client tcp连接泄露[11]等问题报告 报告 详情见 FLINK-11235。

在使用过程中大伙也发现了 Flink Metrics 中衡量端到端的 Opertor Latency 的指标发生漂移,愿因监控不准确问题报告 报告 。大伙也修复了该问题报告 报告 [5]并反馈给了社区,详情见FLINK-11887。

但会 Flink任务是属于长运行的任务,用户代码中打印的日志是打印在 Flink WebUI 上。此一定会面临另一个多 问题报告 报告 ,当任务运行的时间越长,日志量会没有来过多,原生自带的日志页面将无法打开。为了方便用户查看日志,出理 用户无法获取到实时任务的日志信息,一块儿也为了方便用户根据关键词进行历史日志的检索,大伙在实时计算平台为用户提供了一套实时日志系统功能,开发人员可不还能否实时地搜索任务的日志。

你四种 问题报告 报告 比较难定位,首先发生你四种 具体情况没有来过多,但会 一旦经常出先影响很大。其次,没有异常堆栈信息,无法定位到具体的根本愿因。大伙的出理 方式是通过修改源码,在多个肯能的地方增加日志分类整理,以观察并了解任务退出时 JobManager 所执行的出理 逻辑。最终大伙定位到当任务失败时,在默认的重试策略前一天,会将信息归档到 HDFS 上。肯能是串行执行,没有来过多肯能在归档过程中发生异常,则会中断正常出理 逻辑从而愿因通知 JobManager 的过程必须成功执行。具体的执行逻辑见下图。

平台开发难度相对低,难的是如何提升平台的易用性,肯能开源组件如 Apache Flink 核心关注数据的出理 流程,对于易用性这累积稍显不足,没有来过多在实时平台功能开发过程中要修改 Flink 组件的源码来提升其易用性。

大伙的出理 方式是先升级 Curator 版本到 4.x[12],但会 在提升版本后再用 CuratorFrameworkFactory 来构造 CuratorFramework 时,通过使用 ConnectionStateErrorPolicy 将 StandardConnectionStateErrorPolicy 替换为 SessionConnectionStateErrorPolicy,前者将 suspended 和 lost 都作为 error,后者要是将 lost 作为 error,而必须发生 error 的前一天才会撤回 leadership,没有来过多在经过修改前一天,在进入 suspended 具体情况时,不再发生 leadership 的撤回 和重新选举。大伙把你四种 问题报告 报告 和大伙的出理 方式也反馈给了社区,详情见 FLINK-115052。

大伙也遇到了 Flink 与 ZK 网络问题报告 报告 ,当 Jobmanager 与 ZK 的连接中断前一天,会将正在运行的任务立即停止。当集群中任务没有来过多时,肯能肯能网络抖动等愿因瞬断时,会愿因任务的重启。而在大伙集群上有上千的 Flink 应用,一旦经常出先网络抖动,会使得大量 Flink 任务重启,你四种 问题报告 报告 对集群和任务的稳定性影响比较大。

本文大致介绍了 Flink 在同程艺龙实时计算平台实践过程中的一些工作和踩过的坑。对于大数据基础设施来说平台是基础,除此之外还时需投入没有来过多精力来提高 Flink 集群的易用性和稳定性,你四种 过程中要紧跟开源社区,肯能随着同程艺龙在大数据这块应用场景没有来过多,会遇到没有来过多其它公司没有遇到甚至没有发现的问题报告 报告 ,你四种 前一天基础设施团队要有能力主动出理 你四种 影响稳定性的风险点,而一定会被动的在等待社区来提供 patch。

但会 系统采用无侵入式架构,架构图见下图,在用户tcp连接无感知的具体情况下,实时分类整理日志,并同步到 Elasticsearch 中,当业务时需检索日志时,可通过 Elasticsearch 语法进行检索。

这累积任务一些对资源使用需求比较大,大伙提供了任务容器配置的参数来让用户灵活的配置其 Task 并发,但会 提供了自定义时间周期触发保存点(savepoint)的功能。

为了出理 你四种 问题报告 报告 ,大伙修改了 Flink Client 提交过程,在 CliFrontend 中增加另一个多 notify 环节,通过 ContextClassLoader 和反射在 Flink 任务提交阶段将 Flink 生成的 StreamGraph 内的各个 StreamNode 抽取出来,要是 就可不还能否在提交前一天获取出用户编写的 Flink 任务代码中关键数据源等配置信息,从而为后续的 Flink 数据血缘管理提供支持。其关键代码如下:

本文主要介绍 Apache Flink 在同程艺龙的应用实践,从当前同程艺龙实时计算平台现状、建设过程、易用性提升、稳定性优化四方面分享了同城艺龙实时计算平台的建设经验,供大伙参考。

计算组件往往发生大数据的上边位置,上游承接 MQ 等实时数据源,下游对接 HDFS、HBase 等大数据存储,通过 Flink 你四种 实时组件将数据源和数据目标串联在一块儿。为了出理 混乱,你四种 过程往往时需通过数据血缘来做管理。然而常见的数据血缘管理的开源项目如 Apache Atlas 等并未提供对 Flink 的支持,而 Flink 自身也没有提供相应的 Hook 来抽取用户代码的中的数据源等信息。

https://tianchi.aliyun.com/markets/tianchi/flink2019

上图的后端 RTC-FlinkSQL 模块即是用来执行提交 FlinkSQL 任务的服务,SQL 属于声明式语言,经过 150、40 年的发展,具有很高的易用性、灵活性和表达性。删改都是要是 Flink 提供了 Table & SQL API,但会 大伙当时基于的 Flink 1.4 及 1.6 版本四种 语法要是支持像 Create Table 要是 的 DDL 语法,但会 在时需关联到内部人员数据源的前一天 Flink 也没有提供 SQL 相关的实现方式。