前言
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 来满足。所以批流一体的需求，最初是来源于实时业务方。
这次也听了黄晓峰老师从批流一体化业务实践的分享，我觉得总结挺好的。先来说批流一体化的的优势：
- 任务搭建效率更快。传统的 Lamda 架构需要两套引擎，两套代码，同时如果离线数据需要输出到线上业务 DB，离线还需要一个同步任务，而流式任务可以直接写入。批流一体只需要一套代码，代码能够在离线与实时任务之间复用（业务逻辑层代码统一）。原来的开发流程需要你去离线开发平台开发一套，同时再去实时平台再开发一套，现在只需要在一个平台开发一套。
- 计算语义一致。离线任务数据加工链路和实时任务加工链路不一致，所以在最终结果计算方面，你的代码和UDF 逻辑和离线都一模一样，但是结果就是不一致。有可能你的离线任务使用的是以前其他同学的离线表，中间过程中做了很多加工逻辑。
- 任务运维更方便。在一个平台开发，同时在一个平台运维，不需要在两个平台之间跳来跳去，同时由于代码一致，方便管理。
上面是我对于的批流一体的理解，从我个人来看，目前 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 任务已经全部容器化了，对于我们，容器化的好处有三点：
- 降低实时集群大促期间弹性扩缩容成本。以前我们 Yarn 以及 HDFS 是一起部署到物理机上面的，物理机在大促扩容以及大促完缩容时，需要投入一定的物力以及人力成本，而 K8s 扩缩容会更加的弹性。
- 能够与离线混部，提升资源使用率。离线计算白天资源利用率比较低，同时凌晨的机器负载非常高，而实时任务的资源使用率比较均衡，白天负载比凌晨资源相对较高，所以如果实时 k8S 集群和离线 HDFS 集群混部，离线的计算资源能够从外部自动弹性扩容进来，比如凌晨从其他组件加入计算资源，白天再还回去，那么离线的机器资源使用将会更加弹性，离线方面的机器成本也会更低。
- 统一运维。目前公司其他系统都是使用 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的成本，肯定是前者高。
