赞
踩
参考答案:
所有的数据都天然带有时间的概念,必然发生在某一个时间点。把事件按照时间顺序排列起来,就形成了一个事件流,也叫作数据流。
无界数据是持续产生的数据,所以必须持续地处理无界数据流。
有界数据就是在一个确定的时间范围内的数据流,有开始有结束,一旦确定了就不会再改变。
参考答案:
(1)集群级容错
集群管理器集成(Hadoop YARN、Mesos或Kubernetes)
高可用性设置(HA模式基于ApacheZooKeeper)
(2)应用级容错( Checkpoint)
一致性(其本身支持Exactly-Once 语义)
轻量级(检查点的执行异步和增量检查点)
参考答案:
(1)基于状态后端
(2)基于HyperLogLog:不是精准的去重
(3)基于布隆过滤器(BloomFilter)
快速判断一个key是否存在于某容器,不存在就直接返回。
(4)基于BitMap
用一个bit位来标记某个元素对应的Value,而Key即是该元素。由于采用了Bit为单位来存储数据,因此可以大大节省存储空间。
(5)基于外部数据库
选择使用Redis或者HBase存储数据,我们只需要设计好存储的Key即可,不需要关心Flink任务重启造成的状态丢失问题。
参考答案:
(1)在 Flink 的后台任务管理中,可以看到 Flink 的哪个算子和 task 出现了反压;
(2)资源调优和算子调优:资源调优即对作业中的 Operator 并发数(Parallelism)、CPU(Core)、堆内存(Heap_memory)等参数进行调优;
(3)作业参数调优:并行度的设置、State 的设置、Checkpoint 的设置。
参考答案:
上游算子在 web ui 显示有反压时,一般为下游算子存在性能问题。可以继续往下游排查,如果 FlatMap 也显示有反压,大概率是 Sink 算子存在性能问题;如果 FlatMap 没有显示有反压,大概率是 FlatMap 算子存在性能问题。
参考答案:
(1)任务处理性能出现瓶颈:以消费 Kafka 为例,大概率会出现消费 Kafka Lag。
(2)Checkpoint 时间长或者失败:因为某些反压会导致 barrier 需要花很长时间才能对齐,任务稳定性差。
(3)整个任务完全卡住。比如在 TUMBLE 窗口算子的任务中,反压后可能会导致下游算子的 input pool 和上游算子的 output pool 满了,这时候如果下游窗口的 watermark 一直对不齐,窗口触发不了计算的话,下游算子就永远无法触发窗口计算了。整个任务卡住。
参考答案:
算子的 sub-task 需要处理的数据量 > 能够处理的数据量。一般会实际中会有以下两种问题会导致反压。
(1)数据倾斜:当前算子的每个 sub-task 只能处理 1w qps 的数据,而由于数据倾斜,这个算子的其中一些 sub-task 平均算下来 1s 需要处理 2w 条数据,但是实际只能处理 1w 条,从而反压。比如有时候 keyby 的 key 设置的不合理。
(2)算子性能问题:下游整个整个算子 sub-task 的处理性能差,输入是 1w qps,当前算子的 sub-task 算下来平均只能处理 1k qps,因此就有反压的情况。比如算子需要访问外部接口,访问外部接口耗时长。
参考答案:
Flink 中的watermark机制是用来处理乱序的,flink的时间必须是event time ,有一个简单的例子就是,假如窗口是5秒,watermark是2秒,那么 总共就是7秒,这个时候什么时候会触发计算呢,假设数据初始时间是1000,那么等到6999的时候会触发5999窗口的计算,那么下一个就是13999的时候触发10999的窗口。其实这个就是watermark的机制,在多并行度中,例如在kafka中会所有的分区都达到才会触发窗口。
参考答案:
topn 无论是在离线还是在实时计算中都是比较常见的功能,不同于离线计算中的topn,实时数据是持续不断的,这样就给topn的计算带来很大的困难,因为要持续在内存中维持一个topn的数据结构,当有新数据来的时候,更新这个数据结构。
参考答案:
Flink有三种数据消费语义:
(1)At Most Once 最多消费一次 发生故障有可能丢失
(2)At Least Once 最少一次 发生故障有可能重复
(3)Exactly-Once 精确一次 如果产生故障,也能保证数据不丢失不重复。
flink 新版本已经不提供 At-Most-Once 语义。
参考答案:
Flink 的watermark是一种延迟触发的机制。
一般watermark是和window结合来进行处理乱序数据的,Watermark最根本就是一个时间机制,例如我设置最大乱序时间为2s,窗口时间为5秒,那么就是当事件时间大于7s的时候会触发窗口。当然假如有数据分区的情况下,例如kafka中接入watermake的话,那么watermake是会流动的,取的是所有分区中最小的watermake进行流动,因为只有最小的能够保证,之前的数据都已经来到了,可以触发计算了。
参考答案:
默认情况下,如果设置了Checkpoint选项,Flink只保留最近成功生成的1个Checkpoint。当Flink程序失败时,可以从最近的这个Checkpoint来进行恢复。但是,如果我们希望保留多个Checkpoint,并能够根据实际需要选择其中一个进行恢复,这样会更加灵活。Flink支持保留多个Checkpoint,需要在Flink的配置文件conf/flink-conf.yaml中,添加如下配置指定最多需要保存Checkpoint的个数。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。