实时作业转离线作业的几种场景及方案

经常听到人抱怨：所在公司太小，业务不稳定，学不到东西。不可否认，的确是这么回事，假如无法改变现状，何不换个角度来看呢？往往小公司和摇摆不定的公司才能锻炼能力和出现“英雄”般的人物，才能分离出常人和非常人，比如乔布斯 如果不是 二次被 邀请回来 拯救了苹果公司，谁又知道这个人呢？雷军能够在金山坚持20多年，从一线程序员到总经理，然后创办小米，并且把小米从低谷重新拉回巅峰，走出了漂亮的深“V”走势，没有这样一股韧性和坚持，又怎么能到达今日的辉煌？类似的还有董明珠女士。在我党早期的“创业”历史中，如果没有第5次反围剿的失败和在全党面临全军覆没的情形下，其他人又怎么会承认毛泽东的正确意见和才能呢？所谓乱世出人才就是这个道理，大平台是集体的能力而不是个人能力，和平时期也难现真英雄，好好利用当下不那么优越的条件，即使做不到伟人，一个才华出众的，能力全面，受人敬重的公司元老也不错。

将Flink流式计算引擎作为实时计算作业的标配带来的重大挑战之一是资源占用问题，因为大量的Flink作业一旦启动，将一直占用分配的CPU和内存资源，而不会自动释放（除非是批处理模式），并且不会随着处理负载自动伸缩。本文探讨如何在计算资源有限的情况下，如何最大化利用计算资源。基本思路是将流式计算任务中基于时间触发的子过程转化为离线定时调度计算任务。下面列举几种常见的场景，权且当做验证。

一、Kafka数据入湖（仓）作业

比如这样一个kafka topic数据导入示例，将拉取的数据不加处理地写入到Iceberg表：

如果对拉取的频率要求不高，这种情况是可以转换为定时拉取，比如1分钟拉取一批，写入到iceberg，但是需要自己实现拉取的并发控制、状态保存、提交Iceberg的事务性、消费负载均衡等功能。

二、S3对象通知事件处理作业

基于S3对象存储，用户能够实时监听对象的CREATE、PUT、Remove、Expiration或者Replication等事件通知，通过使用形如下面的流程可以省去基于Flink FileSystem 加载数据的过程。下图是基于SQS和Lambda 函数的一种架构案例，实际上 SQS和Lambda 都可以替换为自定义的处理程序，因为每个事件处理都是小处理单元，可以短时间快速完成，这时候事件通知很适合直接对接基于事件触发的调度系统（如Celery），而不需要启动一个实时Flink作业，但因为S3事件通知只投递一次，用户程序需要保证消息处理的服务等级。