Flink Forward Asia 2020 的收获和总结

前言

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

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

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

2. Flink + AI

Flink 本质是一个流式计算引擎，那么实时计算出的数据要发挥数据本身的价值，与 AI 结合，便是一个非常好的方向。

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

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

3. Flink 批流一体化

今年 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的成本，肯定是前者高。