Flink基础

一、需求目的

实时统计票数

二、技术架构

主要计算框架：Flink（Flink SQL)+Kafka
用到的数据存储：Mysql、HBASE（Mysql主要是存储维度表、Hbase主要用来持久化结果数据）

三、Flink基础概念

参考文档：https://jishuin.proginn.com/p/763bfbd2b5a6
架构模型：Jobmanager、Taskmanager和Slot
状态、Checkpoint、Excatly-once ：Checkpoint 负责定时制作分布式快照、对程序中的状态进行备份；State 用来存储计算过程中的中间状态
容错机制：两阶段提交协议(预提交、正式提交)+状态保存
三种状态存储方式：MemoryStateBackend、FsStateBackend、RocksDBStateBackend
三种时间：事件时间（Event Time）、摄入时间（Ingestion Time）、处理时间（Processing Time），同时也支持 watermark 机制来处理滞后数据

Flink的8种分区策略：
GlobalPartitioner 数据会被分发到下游算子的第一个实例中进行处理。
ShufflePartitioner 数据会被随机分发到下游算子的每一个实例中进行处理。
RebalancePartitioner 数据会被循环发送到下游的每一个实例中进行处理。
RescalePartitioner 这种分区器会根据上下游算子的并行度，循环的方式输出到下游算子的每个实例。这里有点难以理解，假设上游并行度为2，编号为A和B。下游并行度为4，编号为1，2，3，4。那么A则把数据循环发送给1和2，B则把数据循环发送给3和4。假设上游并行度为4，编号为A，B，C，D。下游并行度为2，编号为1，2。那么A和B则把数据发送给1，C和D则把数据发送给2。
BroadcastPartitioner 广播分区会将上游数据输出到下游算子的每个实例中。适合于大数据集和小数据集做Jion的场景。
ForwardPartitioner ForwardPartitioner 用于将记录输出到下游本地的算子实例。它要求上下游算子并行度一样。简单的说，ForwardPartitioner用来做数据的控制台打印。
KeyGroupStreamPartitioner Hash分区器。会将数据按 Key 的 Hash 值输出到下游算子实例中。
CustomPartitionerWrapper 用户自定义分区器。需要用户自己实现Partitioner接口，来定义自己的分区逻辑。例如：
Flink的Slot和parallelism有什么区别
Flink有没有重启策略？说说有哪几种
固定延迟重启策略（Fixed Delay Restart Strategy）
故障率重启策略（Failure Rate Restart Strategy）
没有重启策略（No Restart Strategy）
Fallback重启策略（Fallback Restart Strategy）
Flink中的广播变量

九、 Flink中的Window出现了数据倾斜，你有什么解决办法？
window产生数据倾斜指的是数据在不同的窗口内堆积的数据量相差过多。本质上产生这种情况的原因是数据源头发送的数据量速度不同导致的。出现这种情况一般通过两种方式来解决：
在数据进入窗口前做预聚合
重新设计窗口聚合的key

十、 Flink中在使用聚合函数 GroupBy、Distinct、KeyBy 等函数时出现数据热点该如何解决？
数据倾斜和数据热点是所有大数据框架绕不过去的问题。处理这类问题主要从3个方面入手：
在业务上规避这类问题
例如一个假设订单场景，北京和上海两个城市订单量增长几十倍，其余城市的数据量不变。这时候我们在进行聚合的时候，北京和上海就会出现数据堆积，我们可以单独数据北京和上海的数据。
Key的设计上
把热key进行拆分，比如上个例子中的北京和上海，可以把北京和上海按照地区进行拆分聚合。
参数设置
Flink 1.9.0 SQL(Blink Planner) 性能优化中一项重要的改进就是升级了微批模型，即 MiniBatch。原理是缓存一定的数据后再触发处理，以减少对State的访问，从而提升吞吐和减少数据的输出量。
十一、Flink任务延迟高，想解决这个问题，你会如何入手？
在Flink的后台任务管理中，我们可以看到Flink的哪个算子和task出现了反压。最主要的手段是资源调优和算子调优。资源调优即是对作业中的Operator的并发数（parallelism）、CPU（core）、堆内存（heap_memory）等参数进行调优。作业参数调优包括：并行度的设置，State的设置，checkpoint的设置。
十二、Flink是如何处理反压的？
Flink 内部是基于 producer-consumer 模型来进行消息传递的，Flink的反压设计也是基于这个模型。Flink 使用了高效有界的分布式阻塞队列，就像 Java 通用的阻塞队列（BlockingQueue）一样。下游消费者消费变慢，上游就会受到阻塞。
十三、Flink的反压和Strom有哪些不同？
Storm 是通过监控 Bolt 中的接收队列负载情况，如果超过高水位值就会将反压信息写到 Zookeeper ，Zookeeper 上的 watch 会通知该拓扑的所有 Worker 都进入反压状态，最后 Spout 停止发送 tuple。
Flink中的反压使用了高效有界的分布式阻塞队列，下游消费变慢会导致发送端阻塞。
二者最大的区别是Flink是逐级反压，而Storm是直接从源头降速。
十四、 Operator Chains（算子链）这个概念你了解吗？
为了更高效地分布式执行，Flink会尽可能地将operator的subtask链接（chain）在一起形成task。每个task在一个线程中执行。将operators链接成task是非常有效的优化：它能减少线程之间的切换，减少消息的序列化/反序列化，减少数据在缓冲区的交换，减少了延迟的同时提高整体的吞吐量。这就是我们所说的算子链。

三、有感

离线和实时的根本区别

其实相比较于离线，flink实现的实时都是基于事件驱动的，即一次事件即能触发整个计算流程，不像离线需要一个调度系统定时调起计算流程。

不同需求的实现思路

1、如果是计算固定时间段数据，如每天，每天的某些时刻，使用group by字句就可以进行简单统计
2、如果是固定时间窗口统计数据，如每五分钟、每十分钟，这种需求就需要用到滑动窗口去实现，还涉及到rowtime时间语义+watermark，相对来说会比较复杂

flink sql里面用的比较不爽的就是join

参考资料：
flink的几种join：https://www.cnblogs.com/zhaowei121/p/12091858.html
flinkjoin维表：https://jiamaoxiang.top/2020/06/05/%E5%AE%9E%E6%97%B6%E6%95%B0%E4%BB%93-Flink-SQL%E4%B9%8B%E7%BB%B4%E8%A1%A8join/

Regular Join：等于离线中的join，一般只用做有界数据流的 Join，一般在实时中没法使用
Time-Windowed Join： 利用窗口给两个输入表设定一个 Join 的时间界限，超出时间范围的数据则对 JOIN 不可见并可以被清理掉。适用于双流join。

虽然 Timed-Windowed Join 解决了资源问题，但也限制了使用场景: Join 两个输入流都必须有时间下界，超过之后则不可访问。这对于很多 Join 维表的业务来说是不适用的，因为很多情况下维表并没有时间界限，所以就有了下面Temporal Table Join和直接join维表的方式：
Temporal Table Join：如果需要追溯到流表事件发生时维表的状态，就需要维表有历史版本可追溯，这个时候需要定义临时表来保存维表在每个时刻的快照

直接join维表：如果只要获取计算发生时维表的最新状态，使用FOR SYSTEM_TIME AS OF table1.proctime表示当左边表的记录与右边的维表join时，只匹配当前处理时间维表所对应的的快照数据。此时有一下几个注意点
仅支持Blink planner
仅支持SQL，目前不支持Table API
目前不支持基于事件时间(event time)的temporal table join
维表可能会不断变化，JOIN行为发生后，维表中的数据发生了变化（新增、更新或删除），则已关联的维表数据不会被同步变化
维表和维表不能进行JOIN
维表必须指定主键。维表JOIN时，ON的条件必须包含所有主键的等值条件
目前，仅支持INNER JOIN与LEFT JOIN

Flink的调优

为什么要进行flink调优
flink是一条流数据，在每个阶段的处理能力是不一样的，这样就容易出现前一个节点计算逻辑简单在单位时间内向下一个节点推送了大量的数据，但下一个节点计算逻辑复杂计算不过来的现象，会造成下一个节点数据积压处理延迟
常用的调优
参考资料：https://blog.csdn.net/LS_ice/article/details/100132560
https://ones.lizhi.fm/wiki/#/team/6XRfASKf/space/1vxrsTKK/page/KvmM3nST

Kafka的管理

常用Kafka Eagle进行管理

Hbase

最好是映射到hive，便于对Hbase里的数据进行查询

四、注意

如果输入流有两条的时候，最好从输入开始合流，而且根据不同的业务需求，选择不同的join方式，下列以interval join为例：
1、如果两条流有任何一条流有新记录就计算，就使用full join
2、如果两条流中有指定一条流有新记录才计算，就使用left join或者right join
3、如果两条流中必须同时有新记录才计算，就使用inner join