共计 1148 个字符，预计需要花费 3 分钟才能阅读完成。
锁屏面试题百日百刷，每个工作日保持更新面试题。 请看到最初就能获取你想要的, 接下来的是今日的面试题：
1.Flink 中的 Window 呈现了数据歪斜，你有什么解决办法？**
window 产生数据歪斜指的是数据在不同的窗口内沉积的数据量相差过多。实质上产生这种状况的起因是数据源头发送的数据量速度不同导致的。呈现这种状况个别通过以下形式解决：
1、在数据进入窗口前做预聚合
2、从新设计窗口聚合的 key
3、应用再均衡算子 rebalance 等
2.Flink 中在应用聚合函数 GroupBy、Distinct、KeyBy 等函数时呈现数据热点该如何解决？**
数据歪斜和数据热点是所有大数据框架绕不过来的问题。解决这类问题次要从 3 个方面动手：
在业务上躲避这类问题
例如一个假如订单场景，北京和上海两个城市订单量增长几十倍，其余城市的数据量不变。这时候咱们在进行聚合的时候，北京和上海就会呈现数据沉积，咱们能够独自数据北京和上海的数据。
Key 的设计上
把热 key 进行拆分，比方上个例子中的北京和上海，能够把北京和上海依照地区进行拆分聚合。
参数设置
Flink 1.9.0 SQL(Blink Planner) 性能优化中一项重要的改良就是降级了微批模型，即 MiniBatch。原理是缓存肯定的数据后再触发解决，以缩小对 State 的拜访，从而晋升吞吐和缩小数据的输出量。
3.Flink 工作提早高，想解决这个问题，你会如何动手？**
在 Flink 的后台任务治理中，咱们能够看到 Flink 的哪个算子和 task 呈现了反压。最次要的伎俩是资源调优和算子调优。资源调优即是对作业中的 Operator 的并发数（parallelism）、CPU（core）、堆内存（heap_memory）等参数进行调优。作业参数调优包含：并行度的设置，State 的设置，checkpoint 的设置。
4.Flink 是如何解决反压的？**
Flink 外部是基于 producer-consumer 模型来进行消息传递的，Flink 的反压设计也是基于这个模型。Flink 应用了高效有界的分布式阻塞队列，就像 Java 通用的阻塞队列（BlockingQueue）一样。上游消费者生产变慢，上游就会受到阻塞。
5.Flink 的反压和 Strom 有哪些不同？**
Storm 是通过监控 Bolt 中的接管队列负载状况，如果超过高水位值就会将反压信息写到 Zookeeper，Zookeeper 上的 watch 会告诉该拓扑的所有 Worker 都进入反压状态，最初 Spout 进行发送 tuple。Flink 中的反压应用了高效有界的分布式阻塞队列，上游生产变慢会导致发送端阻塞。二者最大的区别是 Flink 是逐级反压，而 Storm 是间接从源头降速。
全部内容在 git 上, 理解更多请点我头像或到我的主页去取得，谢谢 **