分享

58同城大数据开发复试面试经验分享(附答案)

本帖最后由 levycui 于 2022-5-10 10:49 编辑

问题导读:
1、Flink 如何解决作业资源随着需求的变化而动态调整的?
2、Flink kafka sink 插件如何设计?
3、推理过程中 若是任务突然中止,模型和数据丢失怎么办?
4、资源使用率过低的话,K8S 应该怎么处理?


今天为大家分享 58 同城大数据开发(流计算方向)社招二面、三面面经,附上答案。


二面平台负责人面

由于到了 大数据平台负责人 面试关节,所以不会过多的问一些基础问题,全程从项目的角度出发,通过项目来引发扩展问题,这里我主要分享 4 个通过项目扩展出的知识点。

1 面试官:在你们生产环境上,Flink 如何解决作业资源随着需求的变化而动态调整的?

考察 Flink 资源管理知识点

简答

    回答:公司目前一部分业务是将 Flink 任务运行在 K8S 容器上的,使用 Flink Reactive Mode 响应模式,将 Flink 集群部署到 K8S 容器中,通过 K8S 的 Pod 水平自动扩缩容组件来实现 Flink 作业资源 TaskManager 的动态改变。

    K8S 的 Pod 水平自动缩放组件会监控所有 TaskManager pods 的 CPU 负载来相应的调整副本因子(replication factor)。当 CPU 负载升高时,autoscaler 会增加 TaskManager 资源来平摊压力;当负载降低时,autoscaler 会减少 TaskManager 资源。

背后原理

首先,在 Flink 1.14.0 最新版本中依旧无法做到 Job 在运行时动态调整并行度 不经历重启 直接拉起新的 Task 实例运行,目前都是基于重启恢复机制来实现的,因为涉及到状态管理。

在资源管理中,资源的获取包含两种模式:

    Active 模式:主动式,Flink 可以主动申请、释放资源(通过与资源管理框架集成,如 Yarn、Mesos)。

    Reactive 模式:被动响应式,该模式由外部系统来分配,释放资源,Flink 只是简单地对可用资源进行响应。(这种模式对于基于容器环境相当有意义,如 K8S )

现在 Flink 的资源管理模式是 Active 模式,由用户明确指定 Job 需要的资源,JobMaster 会向 ResourceManager 去请求用户指定的全量资源,当 ResourceManager 无法满足 JobMaster 的申请需求时,该 job 将无法正常启动,它会陷入失败重启->再次尝试申请的循环。

为了能够同时支持 Active/Reactive 这两种模式,Flink 1.13.0 版本引入声明式资源管理设计。

该功能与原先最大差别在于:JobMaster 不再去逐个请求 Slot,而是声明需要的资源情况,对资源要求是弹性范围的,不是固定的。

弹性资源包含四件套:(min, target, max, rs),每个元素的含义如下:

  •     min : 执行 Job 的最小资源。
  •     target : JobMaster 期望获得的常规资源需求,它是可变的,这是扩缩容的主要触发机制。
  •     max : 最大资源期望。
  •     rs : resource spec(资源描述信息)。

详细设计原理可以参考如下链接:

https://www.bianchengquan.com/article/574992.html

2 面试官:Flink kafka sink 插件如何设计?

考察 Flink connector sink 知识点

    回答:在 Flink 1.14.0 版本,FlinkKafkaProducer 已经被已弃用,将在 Flink 1.15 中删除,新版本使用 KafkaSink 。

设计 Flink kafka sink 时,可以集成 KafkaSink 类,KafkaSink 允许将记录流写入一个或多个 Kafka 主题。

同时 Kafka sink 提供了一个构建器类来构造一个 KafkaSink 的实例。下面的代码片段展示了如何将字符串记录写入 Kafka 主题,并保证至少一次的交付。

  1. DataStream<String> stream = ...
  2.         
  3. KafkaSink<String> sink = KafkaSink.<String>builder()
  4.         .setBootstrapServers(brokers)
  5.         .setRecordSerializer(KafkaRecordSerializationSchema.builder()
  6.             .setTopic("topic-name")
  7.             .setValueSerializationSchema(new SimpleStringSchema())
  8.             .setDeliveryGuarantee(DeliveryGuarantee.AT_LEAST_ONCE)
  9.             .build()
  10.         )
  11.         .build();
  12.         
  13. stream.sinkTo(sink);
复制代码

KafkaSink 支持三种不同的 DeliveryGuarantees 语义。必须启用  DeliveryGuarantee.AT_LEAST_ONCE 和 DeliveryGuarantee.EXACTLY_ONCE  checkpoint 。默认情况下 KafkaSink 使用 DeliveryGuarantee.NONE.

3 面试官:模型推理过程中要是单个模型过大,如何发送到 kafka?

考察 kafka 单个消息体多大 知识点

    回答:在 kafka 中,默认单条消息最大为 1 M,当单条消息长度超过 1 M 时,就会出现发送到 broker 失败,从而导致消息在 producer 的队列中一直累积,直到撑爆生产者的内存。

    所以在实际生产环境中,由于我们的单个模型是 5 M 多,所以刚开始出现上述的 发送到 broker 失败问题。

    解决办法,只往 kafka 中发送消息体的 ID、 Location、Name,这样 消费者消费数据时,直接根据对应ID、Location 可以消费到模型。

4 面试官:推理过程中 若是任务突然中止,模型和数据丢失怎么办?

考察 Flink state、checkpoint 知识点

    为了支持 Flink 推理功能,防止模型丢失问题,使用 flink checkpoint 机制实现,让推理算子实现 CheckpointedFunction 接口,将 model 以 value state 写入状态后端。这样,当推理出现故障时,checkpoint 重新启动时,直接从状态后端中拿到模型的 value 值。

三面总监面

面试官:1 Flink 集群为什么要部署到 K8S 上面?上云的好处是什么?

考察 K8S 的优缺点

    回答:目前将 组件进行容器化已经成为当前的一个趋势,将 Flink 集群部署到 K8S 上 可以实现资源的合理利用,同时 k8s 是一个开源的容器集群管理系统,可以实现容器集群的 自动化部署、自动扩缩容、维护 等功能,具备很多特点:

1、故障迁移:当某一个 node 节点关机或挂掉后,node 节点上的服务会自动转移到另一个 node 节点上,这个过程所有服务不中断。这是 docker 或普通云主机是不能做到的

2、资源调度:当 node 节点上的 cpu、内存不够用的时候,可以扩充 node 节点,新建的 pod 就会被 kube-schedule 调度到新扩充的node节点上。

3、资源隔离:创建开发、运维、测试三个命名空间,切换上下文后,开发人员就只能看到开发命名空间的所有 pod,看不到运维命名空间的 pod,这样就不会造成影响,互不干扰。

面试官:2 Flink 任务部署到 K8S 和 部署到 yarn 上面的区别是什么?有哪些优点?


    Flink on k8s 相比 yarn 的优势
  •     更好的资源与网络的隔离性、安全性,更适合多租户
  •     更容易实现与online service的混合部署,提升集群利用率
  •     可以受益 K8S 丰富的生态系统,例如:ETCD,Prometheus.

    以后将 Flink 部署到 K8S 会成为一个趋势,K8S 可以更好的监控到集群资源使用率,从而动态实现扩缩容,降低资源成本。

面试官:3 Flink 集群的资源使用率是多少?资源使用率过低的话,K8S 应该怎么处理?

    回答:主要分离线作业资源使用率和流式作业资源使用率。根据具体公司的情况回复,比如:离线资源使用达到60%,流式作业资源使用达到40%。
    流式资源使用率过低,这时 K8S 会根据自动扩缩容机制,减少 Pod 节点,降低负载,降低 CPU,资源的利用率。

面试官:4 那负载降低时,有没有遇到什么问题?

    回答:我们是采用 Flink 的响应模式 (Reactive Mode),将 Flink 集群部署到 K8S 中的,然后 autoscaler 会监控 K8S 中 pods 的 CPU 负载。监控的指标主要有:
  •         对 kafka 消费延迟监控
  •         对 Flink 每秒吞吐量监控
  •         对每个 TaskManager 的 CPU 负载监控
  •         对 TaskManager 数量监控。

    在生产环境中,的确遇到过 资源负载降低时,导致 Flink 监控出现毛刺等现象。如:TaskManager 数量某些情况下并没有很好的追随吞吐量曲线的变化。导致我们浪费了大量配置的 TaskManager 资源。

原因分析:

在 Flink 中,JobManager 会定期发送心跳信息给 TaskManager 来确定 TaskManager 是否还存活。默认心跳的发送频率是 50s 一次。这个默认值看上去像是很高,但是在高负载情况下可能出现网络波动、gc 停滞或其他情况导致心跳数据发送延迟。

但是,50s 默认值在我们的生产环境带来了一些问题。

当 K8S autoscaler 监控到 CPU 负载降低时,会降低 TaskManager 数量,停止 TaskManager 实例。随之 Flink 会因为数据传输层(data transport layer)与这些 TaskManager 失联而立即停止数据处理,而且 JobMaster 将会等待 50s 后才会认定 TaskManager 真正被关闭了。

在 JobManager 等待期间,吞吐量会降到 0,数据也会因此积压在 Kafka 中(消费延迟看板出现毛刺的原因)。当 Flink 重新运行起来后会对积压数据进行消费,从而造成了 CPU 负载的升高。autoscaler 监控到负载变化后会分配更多的 TaskManager,因此造成了 TaskManager 的浪费。

我们观察发现这种情况只会发生在 缩容 的场景中,因为缩容更加容易引起不稳定的情况的发生相比于扩容。扩容时,TaskManager 资源增加,数据停止处理仅发生在任务重启阶段(重启动作很快,仅会造成 Kafka 少量数据积压);然而缩容时,数据停止处理的时间大约 50s。

我们通过调整 heartbeat.timeout = 8s 来缓解了以上问题的发生。

小伙伴面试完之后,58 集群总监就实时给他反馈了情况,3面技术面都通过~

以上就是 58 集团  2、3  面所问的重点问题,其中涉及到一些业务场景方面的问题,但回答的套路是可以总结的。

作者:在IT中穿梭旅行
来源:https://mp.weixin.qq.com/s/AnAGlk-1vsVArav0nuAl9w

最新经典文章,欢迎关注公众号


没找到任何评论,期待你打破沉寂

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

推荐上一条 /5 下一条