Flink Forward Asia 2020 的收获和总结

前言

Flink Forward Asia 2020 三天的分享结束了,在这次分享上,自己也收获了很多。这里写一篇文章来记录下自己这次的收获和总结,从个人的视角和理解,和大家一起分享下,当然,如果有理解错误的地方,也欢迎大家指出。

1. Apache Flink 已经实时计算事实标准

我相信很多公司实时计算的发展都是从 Strom 到 Spark Streaming ,然后再到 Flink 这样一个发展的历程。从引擎本身来讲,Flink 支持更低的实时计算时延,以及对于任务状态的支持。目前从国内各大公司使用来看,Flink 已经成为了各个公司在实时计算方面的首选,同时 Flink 社区也非常的活跃,Flink 所支持功能也在不断的完善。Apache Flink 已经成为各行业实时计算方面的事实标准。

2. Flink + AI

Flink 本质是一个流式计算引擎,那么实时计算出的数据要发挥数据本身的价值,与 AI 结合,便是一个非常好的方向。阿里在 19 年开源了基于 Flink 的算法平台 Alink,Alink 旨在统一 Flink 在机器学习方面的算法库。虽然我目前还没有用过 Alink,不过未来如果业务方在算法方面有需求,我应该会推荐他们来使用的。

Alink 今年新增数十个开源算法,同时在算法工作流方面,开源了 Flink AI Flow ,可以看到 Flink 在机器学习方面,功能迭代的速度也很快,希望未来我们能够使用 Flink 机器学习方面的能力,去更好的解决业务的需求。

我们内部算法在 Flink 方面,目前感觉应用相对较少,不像字节,光在算法特征实时处理方面,就有上千加实时任务,所以我思考明年能不能和算法同学,在实时方面,能够有更多的合作。当然,这个合作的前提,是我们的实时平台,在 Flink SQL 方面,能够更加的方便好用,功能完善。

3. 批流一体化

今年 FFA 大会上听到最多的一个词,批流一体化,那么是否所有的企业都要去做批流一体呢,我觉得具体还是要看业务方的诉求和痛点。也就是说,是否需要批流一体,是业务方自己决定的,每个公司肯定都有自己的需求和痛点,所以也并不是一定要去做批流一体。

关于 Flink 批流一体,我觉得下面这个总结挺好的,Flink 批流一体化,并不是说去代替 Spark ,而是在实时业务场景中,业务方有一些批处理方面的需求,对于这方面批处理的需求,用 Flink 来满足。所以批流一体的需求,最初是来源于实时业务方。

这次也听了黄晓峰老师从批流一体化业务实践的分享,我觉得总结挺好的。先来说批流一体化的的优势:

  1. 任务搭建效率更快。传统的 Lamda 架构需要两套引擎,两套代码,同时如果离线数据需要输出到线上业务 DB,离线还需要一个同步任务,而流式任务可以直接写入。批流一体只需要一套代码,代码能够在离线与实时任务之间复用(业务逻辑层代码统一)。原来的开发流程需要你去离线开发平台开发一套,同时再去实时平台再开发一套,现在只需要在一个平台开发一套。
  2. 计算语义一致。离线任务数据加工链路和实时任务加工链路不一致,所以在最终结果计算方面,你的代码和UDF 逻辑和离线都一模一样,但是结果就是不一致。有可能你的离线任务使用的是以前其他同学的离线表,中间过程中做了很多加工逻辑。
  3. 任务运维更方便。在一个平台开发,同时在一个平台运维,不需要在两个平台之间跳来跳去,同时由于代码一致,方便管理。

上面是我对于的批流一体的理解,从我个人来看,目前 Flink 批处理能力与 Spark 对比,肯定还是稍逊一筹的,毕竟 Spark 已经非常成熟了,同时也在离线方面做了很多优化。不过随着 Flink 在批处理方面的能力优化,未来如果批处理方面的性能与 Spark 相差不大时,同时上面的痛点越来越大,那么业务方就可以去考虑批流一体。是否批流一体,是业务方自己决定,我们会基于 Flink 提供这样的能力,至于是否使用,取决于业务方。

4. 实时任务智能诊断

这次分享也看到很多公司在做实时任务智能诊断功能,实时任务智能诊断就是从不同角度去检测用户的实时任务,是否有异常情况,以及什么地方异常等,让用户根据智能诊断的结果,优化实时任务。打个比方,假设现在检测到用户的实时任务 Full GC 比较多,同时反压情况比较严重,智能诊断就能够提示用户调整内存,同时告诉用户具体是那个算子反压,智能化给出异常结果,更好的帮助用户专注于实时业务逻辑的开发,而不是实时任务优化方面。

这次谢亚东老师也带来了《基于 Monitoring REST API 的 Flink 轻量级作业诊断》的分享,整体使用 Flink Rest API 的一些指标查询接口,对于 Flink 作业进行诊断,主要从运行状态、数据处理、状态稳定三个方面对实时任务进行诊断,整体上还是很有参考意义的。

目前这个功能在阿里内部已经开始使用,问了一下,未来这个功能会贡献给社区。我觉得如果你们公司没有做实时任务智能诊断的话,可以参考这个思路来设计开发一个,当实时任务有异常情况时,也能借助于这个工具,快速定位到具体原因和解决,尽可能减少对于线上业务的使用的影响。

目前我是打算做一个实时任务诊断工具,会结合 Flink Rest API Monitor 相关接口,然后针对公司内部的实时任务可能出现的异常情况(会按照异常情况的危险级)排序,以及公司内部实时任务的一般特性,针对性的来做,这样也能帮助业务方更好的优化实时任务。

5. Flink on k8s 功能

目前主流的实时任务计算资源有两类:Yarn 和 K8s ,其中 Yarn 的比例居多。很多公司已经开始打算把 Flink on Yarn 往 Flink on k8s 上迁移,至于为什么 Flink 要往 K8s 上面迁移,社区同学给出了见解:

我们公司目前 Flink Jar 任务已经全部容器化了,对于我们,容器化的好处有三点:

  1. 降低实时集群大促期间弹性扩缩容成本。以前我们 Yarn 以及 HDFS 是一起部署到物理机上面的,物理机在大促扩容以及大促完缩容时,需要投入一定的物力以及人力成本,而 K8s 扩缩容会更加的弹性。
  2. 能够与离线混部,提升资源使用率。离线计算白天资源利用率比较低,同时凌晨的机器负载非常高,而实时任务的资源使用率比较均衡,白天负载比凌晨资源相对较高,所以如果实时 k8S 集群和离线 HDFS 集群混部,离线的计算资源能够从外部自动弹性扩容进来,比如凌晨从其他组件加入计算资源,白天再还回去,那么离线的机器资源使用将会更加弹性,离线方面的机器成本也会更低。
  3. 统一运维。目前公司其他系统都是使用 K8s 资源,实时计算如果使用 k8s ,那么公司在运维层面,能做到统一运维,减少了运维成本。

如果你们公司想上 K8s,对于比较低的 Flink 版本,比如 1.7 ,1.8 的话,可以尝试 Flink Operator 的方案来实践。如果版本比较新的话,比如 1.10 以上,那么我觉得完全可以将版本升级到 1.12,然后直接使用 1.12 的 k8s 社区功能。最保底的方案就是自己对于 Flink 任务打镜像,然后创建任务的 Deployment 以及 Service 等,不过这种方式使用门槛较高,同时还需要考虑 Flink on k8s 非云原生的问题,这里还是推荐去使用社区的 K8s 功能。

6. Flink on 数据湖

最后一个非常火的概念,数据湖。那么到底什么是数据湖呢,我个人的理解,首先数据湖是一种数据架构,它不仅能够存储结构化数据,也能够存储半结构化以及非结构化的数据,旨在对于企业数据进行统一的存储。目前在数据湖方面,比较火的有 Iceberg 以及 Hudi:

Iceberg 目前还不支持数据 Upsert(社区在做),但是底层抽象度很好,同时不和任何计算引擎绑定,目前国内大厂几乎都是选择 Iceberg 来进行功能扩展。当然,现在 Hudi 也在尽可能减少对于 Spark 的耦合,现在也已经在重构底层的代码。未来到底是 Hudi 还是 Iceberg,让我们拭目以待。

目前社区已经在做 Flink Iceberg Sink Connector,已经可以使用,在1.12 版本,不过不支持 Upsert 功能,iceberg 社区正在做这块,主要是胡争大佬,哈哈,大家有问题可以问他。Flink Hudi Sink Connector 也在开发中,未来具体使用哪个,业务方可以根据公司内部情况,来决定使用那个。

目前我们内部在数据湖方面,主要还是偏调研性质,同时也在评估引入数据湖技术所带来的收益以及我们的投入成本,整体还是观望状态,等到数据湖技术成熟以及业务方的相关痛点和需求之后,我们应该也会引入。至少在实时 BI 看板方面,我觉得 Flink + 数据湖 + Presto(或者其他) 能够进行统一掉,我们之前使用的是 Flink + kafka + Druid,Kafka 和 Druid 的成本,相对于 HDFS + Presto的成本,肯定是前者高。

稀土掘金
我还没有学会写个人说明!
上一篇

脑洞:如何用一个整数来表示一个列表?

下一篇

博文推荐|消息系统的发展趋势:云原生是未来

你也可能喜欢

评论已经被关闭。

插入图片