摘录-小红书flink数据集成成本优化
主要是flink的成本优化, 看起来也是做了不少工程能力改造, 都是各种折腾搞出来的工作量.
两个方面:
- 尽量使用批处理任务
- 离混线混部, 与在线对外提供的实时任务混合到一起
Flink 数据集成服务在小红书的降本增效实践
https://mp.weixin.qq.com/s/GwUr-GZbhWWfo32CrJpU5Q
flink切换到批处理能力
从资源角度对比一下 Flink 的流模式和批模式。
Flink 的流模式引擎运行的时候没有阶段的概念，数据以 pipeline 的方式进行流转。这就要求所有的算子和并发的资源都要实时准备就绪，程序才能正常运行。而对于批模式引擎来说，任务被划分到几个阶段，上一个阶段运行结束后才能运行下一个阶段，且只需要部分算子和并发获取到资源就可以运行了。
从另外一个角度来看，部分聚合类型的批任务，在流模式运行的时候，会不可避免地引入 State 和 Watermark，这就需要更多的CPU和内存资源。而在批模式引擎下不需要 State 和 Watermark，仅需要 Shuffle 中间数据，这对磁盘的要求也很高，但磁盘相对于 CPU 和内存来说更加便宜。
这就是资源视角下流模式和批模式的对比，也是我们将批任务从流模式切换到批模式来运行的一些考虑。
fink离混现混部
首先来看看什么是在离线混部。一般公司都会有两种类型的服务。一种是在线服务，它的特点就是运行时间长，服务流量和资源利用率具有潮汐性。也就是在白天使用人数多的时候，资源利用率就会高，流量也会高，而到了晚上使用人群数量降下来之后，资源利用率也会降下去。另外一种是离线作业。它只会运行一段时间，运行期间资源利用率非常高，一般也是时延不敏感的，只要在一个时间点之前运行结束之后资源就会空闲下来。
所谓在离线混部就是指将在线服务空闲的资源匀给离线作业使用，提升资源的整体利用率。对离线业务来说，能极大降低这资源的使用成本。在离线任务混跑期间，需要保护在线服务，可能会对离线业务的运行进行资源压制等操作。
哪些任务适合迁移过去，主要的考虑的特点有以下三个：
- 第一个是迁移过去的任务必须是非延时敏感的，因为在离线混部集群会压缩离线资源，离线任务运行的时间可能会更长。
- 第二个是任务要具有潮汐的特性，需要选择刚好在资源空闲时大量运行的离线任务迁移过去。一般来说，在线服务在晚上资源比较空闲，而离线任务都是集中在晚上运行比较多，这一点比较契合。
- 第三个是具有容错能力，因为在离线混部可能会压缩离线任务的资源，并对 Pod 进行驱逐，所以需要任务具有一定容错能力。
