Flink

Flink

文章目录

• • • 1.聚合函数 GroupBy、Distinct、KeyBy 等函数时 出现数据热点该如何解决
    • 2.Flink 任务延迟高如何解决
    • 3.Flink 是如何处理反压的
    • 4.Flink 的反压和 Strom 有哪些不同
    • 5.Operator Chains（算子链）
    • 6.什么情况下形成算子链
    • 7.Flink1.9 的新特性
    • 8.消费 kafka 数据的时候，如何处理脏数据

1.聚合函数 GroupBy、Distinct、KeyBy 等函数时 出现数据热点该如何解决

数据倾斜和热点数据是大数据不可绕过去的问题

1.在业务上规避这种问题
比如:北京和上海两个城市订单量增长几十倍，其余城市的数据量不变。这时候我们在进行聚合的时候，北京和上海就会出现数据堆积，我们可以单独数据北京和上海的数据。

2.Key上设计
将热点key拆分,然后聚合

3.参数设置
Flink 1.9.0 SQL 性能优化中升级了微批模型,MiniBatch,缓存一定的数据再处理,以减少state的访问,从而提升吞吐量减少数据的输出量

2.Flink 任务延迟高如何解决

flink的后台任务管理中,可以看到那个算子和task出现反压

手段为资源调优和算子调优

资源调优即是对作业中的 Operator 的并发数（parallelism）CPU, 堆内存,等参数调优

作业参数调优包括对并行度,state,checkpoint的设置调优

3.Flink 是如何处理反压的

Flink 内部是基于 producer-consumer 模型来进行消息传递的，Flink 的反压设计也是基于这个模型。Flink 使用了高效有界的分布式阻塞队列，就像 Java 通用的阻塞队列（BlockingQueue）一样。下游消费者消费变慢，上游就会受到阻塞。

4.Flink 的反压和 Strom 有哪些不同

Storm 是通过监控 Bolt 中的接收队列负载情况，如果超过高水位值就会将反压信息写到 Zookeeper ，Zookeeper 上的 watch 会通知该拓扑的所有 Worker 都进入反压状态，最后Spout 停止发送 tuple。Flink 中的反压使用了高效有界的分布式阻塞队列，下游消费变慢会导致发送端阻塞。二者最大的区别是 Flink 是逐级反压，而 Storm 是直接从源头降速。

5.Operator Chains（算子链）

为了更高效地分布式执行，Flink 会尽可能地将 operator 的 subtask 链接（chain）在一起形成 task。每个 task 在一个线程中执行。将 operators 链接成 task 是非常有效的优化：它能减少线程之间的切换，减少消息的序列化/反序列化，减少数据在缓冲区的交换，减少了延迟的同时提高整体的吞吐量。这就是我们所说的算子链。

6.什么情况下形成算子链

1上下游的并行度一致

2.下游节点的入度为 1

3.上下游节点都在同一个 slot group 中

4.下游节点的 chain 策略为 ALWAYS（可以与上下游链接，map、flatmap、filter 等默认是 ALWAYS）

5.上游节点的 chain 策略为 ALWAYS 或 HEAD（只能与下游链接，不能与上游链接，Source 默认是 HEAD）

6.两个节点间数据分区方式是 forward（参考理解数据流的分区）

7.没有禁用 chain

7.Flink1.9 的新特性

1.支持hive, 支持UDF

2.SQL TopN和GroupBy优化

3.Checkpoint 跟 savepoint 针对实际业务场景做了优化

8.消费 kafka 数据的时候，如何处理脏数据

在处理前加一个 fliter 算子，将不符合规则的数据过滤出去。