为您服务网站,电商详情页模板免费套用,wordpress文章不登录看不到,网站备案后可以改名吗摘要#xff1a;本文整理自实时引擎研发工程师袁奎#xff0c;在 Flink Forward Asia 2022 数据集成专场的分享。本篇内容主要分为四个部分#xff1a; 小红书实时服务降本增效背景Flink 与在离线混部实践实践过程中遇到的问题及解决方案未来展望 点击查看原文视频 演… 摘要本文整理自实时引擎研发工程师袁奎在 Flink Forward Asia 2022 数据集成专场的分享。本篇内容主要分为四个部分 小红书实时服务降本增效背景Flink 与在离线混部实践实践过程中遇到的问题及解决方案未来展望 点击查看原文视频 演讲PPT 一、小红书实时服务降本增效背景 1.1 小红书 Flink 使用场景特点 小红书的 Flink 特点包含以下三条 第一云原生复杂的多云、海内外架构。小红书从成立之初就将所有的技术体系全部搭建在公有云上是真正意义上云的原住民。 我们与多家云厂商都有合作比如 AWS腾讯云华为云阿里云等等。经过多年的发展业务数据也分布到了不同的云厂商下。云原生本身就会带来天然的好处比如资源隔离和扩展都非常容易。 第二数据集成链路较长作业存在高峰期资源互相抢占的现象。以数据集成为例在多云体系架构下数据要经常进行跨云的传输所以数据集成任务是重要且不可或缺的。我们在过去搭建了 Flink 的数据集成的独占集群但随着数据集成任务的增多出现了越来越多资源抢占的现象。 因为 Flink 集成任务都是批任务大部分会在凌晨同时集中运行就会出现一部分任务因抢占不到资源而失败的情况。同时整个资源池的整体利用率也比较低因为白天批任务运行的比较少这个时候资源是空闲的。 第三数据集成的高优、低优作业均以 Flink 流模式引擎运行。有一些历史原因一个是因为早期 Flink 版本的批模式引擎还不成熟另外一个是流模式比较简单它速度快且不用考虑中间数据落盘的问题。在资源比较宽裕的情况下它是更优的选择。 1.2 小红书 Flink 数据集成服务 小红书典型的数据集成类型有很多种比如 Hive to Clickhouse、Hive to Doris、Hive to MySQL、Mongo to Hive 等等。 上图右侧是是一张 Top 图一个数据源进行了一次 Mongo 的 Lookup Join分为两个流写入到下游这就是一个典型的 Flink 数据集成任务。 1.3 降本增效的大环境要求 随着小红书的发展基础设施越来越完善资源的使用也更加规范化。过去那种资源野蛮申请的时代已经结束现在逐渐重视集群的 CPU 利用率。 在这样的背景下我们来看 Flink 的资源集群。一方面我们现在的 Flink 资源集群主要采用独占模式部分小资源池任务比较少容易产生资源碎片存在资源浪费。另外一方面 Flink 集成任务的集群在晚上存在资源抢占的现象而在白天又因为资源空闲而利用不起来会造成整体的资源利用率不高。 针对以上两个问题有什么解决方法来提升整体资源的利用率呢可以分为如下两点 第一如何规避小规模集群。我们可以将小规模集群进行合并然后配合 K8s 的 Resource Quota 进行资源隔离。除此之外我们还有一个更好的解决方案即使用容器团队提供的在离线混部集群。将小规模集群的任务迁移到在离线混部集群中然后将小规模集群的资源释放掉。第二如何减少高峰时期的资源抢占。从平台的角度来考虑我们可以优化资源的调度细化任务的优先级。从 Flink 引擎的角度来考虑我们可以推广 Flink 的批模式引擎因为批模式引擎对资源的要求更低。但我们的切入点不太一样我们是从资源角度来考虑的。 1.4 降本增效视角下的 Flink 流模式/批模式对比 接下来我们从资源角度对比一下 Flink 的流模式和批模式。 Flink 的流模式引擎运行的时候没有阶段的概念数据以 pipeline 的方式进行流转。这就要求所有的算子和并发的资源都要实时准备就绪程序才能正常运行。而对于批模式引擎来说任务被划分到几个阶段上一个阶段运行结束后才能运行下一个阶段且只需要部分算子和并发获取到资源就可以运行了。 从另外一个角度来看部分聚合类型的批任务在流模式运行的时候会不可避免地引入 State 和 Watermark这就需要更多的CPU和内存资源。而在批模式引擎下不需要 State 和 Watermark仅需要 Shuffle 中间数据这对磁盘的要求也很高但磁盘相对于 CPU 和内存来说更加便宜。 这就是资源视角下流模式和批模式的对比也是我们将批任务从流模式切换到批模式来运行的一些考虑。 二、Flink 与在离线混部实践 2.1 在离线混部的 K8s 集群 首先来看看什么是在离线混部。一般公司都会有两种类型的服务。一种是在线服务它的特点就是运行时间长服务流量和资源利用率具有潮汐性。也就是在白天使用人数多的时候资源利用率就会高流量也会高而到了晚上使用人群数量降下来之后资源利用率也会降下去。另外一种是离线作业。它只会运行一段时间运行期间资源利用率非常高一般也是时延不敏感的只要在一个时间点之前运行结束之后资源就会空闲下来。 所谓在离线混部就是指将在线服务空闲的资源匀给离线作业使用提升资源的整体利用率。对离线业务来说能极大降低这资源的使用成本。在离线任务混跑期间需要保护在线服务可能会对离线业务的运行进行资源压制等操作。 上图是在离线混部集群的示意图。容器团队将各个在线服务集群的空闲资源收集起来组成一个资源集群。从用户角度只能看到一些虚拟节点但实际上每个虚拟节点背后都对应着一到多个真正的资源节点。对用户来说虚拟集群的使用和真正独占集群是一样的唯一不一样的是虚拟节点的资源可能在不断变化。容器团队提供了在离线混部集群而我们正好有离线任务且有资源利用率的压力算是一拍即合。 2.2 适合在离线混部的离线任务特点 哪些任务适合迁移过去主要的考虑的特点有以下三个 第一个是迁移过去的任务必须是非延时敏感的因为在离线混部集群会压缩离线资源离线任务运行的时间可能会更长。 第二个是任务要具有潮汐的特性需要选择刚好在资源空闲时大量运行的离线任务迁移过去。一般来说在线服务在晚上资源比较空闲而离线任务都是集中在晚上运行比较多这一点比较契合。 第三个是具有容错能力因为在离线混部可能会压缩离线任务的资源并对 Pod 进行驱逐所以需要任务具有一定容错能力。 2.3 适合在离线混部的 Flink 任务 对批任务来说由于 Pod 可能被驱逐掉当被驱逐的时候在其他节点上拉起就有可能重新消费数据造成数据的重复所以我们要选择 Sink 端支持幂等插入或不在意重复数据的批任务迁移。对批模式引擎我们要尽可能让所有算子 chain 到一起选择这一部分的任务迁移。因为算子如果不 chain 到一起就会进行中间数据的落盘这样就会对资源节点的要求更高。尽量选择在夜间大量运行的批任务迁移因为在离线混部集群在晚上资源比较空闲。一般在离线混部集群不适合上流任务但因为它在白天会有一些空闲资源能够支持一部分的流任务运行所以我们也选择迁移一部分低优的流任务且这部分流任务需要能够容忍 Fail Over允许一段时间的延迟。 2.4 Flink 与在离线共建 首先我们会部署一个 Flink 的独占集群它上面没有独占的节点然后容器团队将虚拟节点部署到我们的独占集群中。虚拟节点背后对应着一个 controller 和真正的资源节点当我们提交任务时只需要将任务提交给虚拟节点deployment 就会在虚拟节点上拉起 JobManager 的 Pod。最后这个创建过程会被虚拟节点的 controller 下发到背后真正的资源节点上执行。 我们采用的是 Flink Native K8s 的方式所以 TaskManager 由 JobManager 拉起。这个创建过程和 deployment 的创建过程一样也会被虚拟节点下发到真正的资源节点去执行。也就是说最终 JobManager 和 TaskManager 的 Pod 都运行在背后的资源节点上在虚拟节点上只有 Pod 的一份镜像。对于 Configmaps、Service、Ingress 等 K8s 资源它的源数据都存在 ETCD 中只需要同步一部分过去就可以了。 通过这种方式我们可以在 Flink 独占集群正常提交任务且能正常通过 kubectl 命令操作 Pod对我们来说使用在离线的虚拟集群就和使用一个普通的 flink 独占集群是一样的。当然实现过程中有一些问题比如 JobManager 和 TaskManager 分属于两个集群他们之间如何进行通信日志和监控指标如何采集等等这些都是一些工程实现上的问题这里就不再赘述了。 三、实践过程中遇到的问题及解决方案 最后一部分就是我们在实践过程中遇到的一些问题作为云的原住民这里问题也聚焦于我们在云原生上遇到的一些问题和解决方案。 3.1 避免宿主机上临时数据文件的残存 第一个问题如何避免宿主机上临时数据文件的残存。使用过 K8s 容器技术的人都会遇到这样的问题默认情况下启动一个容器容器中的临时数据文件都存在 docker 盘中。如果临时数据文件过大就会影响 docker 的运行稳定性这个时候我们可以在容器中挂载另外一块数据盘让临时数据文件写到这块数据盘中这样就不会影响 docker 的运行稳定性了。 在 K8s 里挂载数据盘一般都通过 hostPath volume 的挂载方式这种方式的好处是可以指定一个宿主机的挂载目录挂载方式简单但 hostPath 挂载方式依赖程序本身临时文件的清理逻辑。如果 Pod 异常退出比如遇到了 OOM 被 K8s Kill 掉了此时临时数据文件的清理逻辑还没来得及执行 Pod 已经结束掉了那么这个临时数据文件就会残存在宿主机上。当残存的文件越来越多占满了整个数据盘就会影响任务运行的稳定性。那么我们是如何解决的呢 K8s 有一种挂载方式叫 emptyDir它与 Pod 同生命周期。所以无论 Pod 是正常结束还是异常结束只要结束之后 emptyDir 挂载目录中的临时数据文件都会被清理掉这就降低了对程序清理逻辑的依赖。 这里有一点需要要注意emptyDir 不能指定挂载目录默认使用 kubelet 工作目录存储。一般这个目录在系统盘里如果不做任何处理临时文件写入系统盘就有可能会影响系统运行的稳定性所以一般我们要在开机的时候更换 kubelet 的工作目录到另外一块数据盘。 3.2 批模式在云原生场景下的 OOM 问题 第二个问题批模式在云原生场景下的 OOM 问题。这个任务在流模式引擎运行的非常顺畅但转换到批模式引擎运行之后就会频繁出现 OOM 问题。 这个任务在 chain 之后依然有两个算子也就是说中间会进行一次数据的 ShuffleOOM 就发生在写 Shuffle 数据的这个阶段。从上图右上角的监控图可以明显看到两个阶段第一个阶段是写 Shuffle 数据的阶段有一些 work-set 飙升的情况一旦超过容器限制就会触发 OOM Kill。 出现这种情况首先我们首先从 Flink 的 webui 上观察堆内存使用情况目前看堆内存的使用是正常的从 GC 监控界面也可以看到 GC 情况是正常的。那么我们怀疑可能是堆外内存出现了泄漏于是我们进入 Pod 里面通过 pmap 命令查看 RSS 的使用情况。也就是右下角的这张图可以看到 RSS 也是正常的且 RSS 只有 7G 左右没有达到 20G 的限制也就可以说明不是堆外内存泄露导致的。 到这里答案其实已经呼之欲出了。work-set 指标可以简单理解为 RSSPage CacheRSS 是正常的work-set 又出现飙升的情况所以我们就可以怀疑是 Page Cache 造成的 OOM。 顺着这个思路我们登录到机器节点上去查看机器日志。如上图所示我们找到了一个调用栈可以看到是由于申请 Page Cache 造成的 OOM。实际上就是云盘的性能不足在 Shuffle 数据时瞬间大量写 Page Cache不能及时将数据刷到磁盘导致内存超用触发 OOM Kill。 我们有一个临时的解决方案。增加 Pod 数量减少单个 Pod 处理的数据量然后尽量让 Pod 分布到不同的机器节点上降低机器节点的压力。或者升级机器内核通过调整内核参数进行限流。除此之外我们还可以从 Flink 引擎本身着手在 Shuffle 数据阶段直接进行限流。 四、未来展望 未来小红书将要探索的方向主要包含以下三部分。 第一批模式应用深入挖掘。我们希望能够深入用户挖掘更多的批模式引擎的使用场景真正推广 Flink 的流批一体。第二配合使用 K8s 的 Resource Quota 功能将业务方的多个小集群进行合并减少机器的资源碎片问题。第三Serverless 是批模式引擎在云原生环境下部署的一个重要目标但是强行部署为 serverless 意味着如果 pod 被 Kill 掉中间数据就会被清理会影响任务的故障恢复这个时候 remote Shuffle Service 的价值就体现出来了使用 Remote Shuffle Service 可以有效减少对本地磁盘的部分依赖提升资源利用率助力云原生架构。 点击查看原文视频 演讲PPT
