Flink基础概念

1、keyby、partitionCustom 区别

（1）KeyBy

    DataStream → KeyedStream: 通过制定字段，将流转化成带key的流，之后相同key的数据，分发到相同的算子上。属于逻辑上的分区。

  dataStream.keyBy("someKey") // 通过 "someKey"进行分组
  dataStream.keyBy(0) // 通过Tuple的第一个元素进行分组

  （2）物理分区 

    （1）Custom partitioning
    DataStream → DataStream
    描述： 使用用户自定义的分区来为每一个元素选择具体的task.
    dataStream.partitionCustom(partitioner, "someKey")
    dataStream.partitionCustom(partitioner, 0)
    （2）Rebalancing (Round-robin partitioning)
    DataStream → DataStream
    描述： 循环的为元素分区，为每一个分区创建相等的负载，这在数据倾斜的优化上是非常有用的:
    dataStream.rebalance()
    （3）Rescaling
    DataStream → DataStream
    描述：重复的分区元素到下游操作的子集中. 如果你想将一个source的并行实例
    拆分到多个mapper操作的子集中来进行分布式加载，
    而又不希望调用rebalance()产生的全量重分区的话，
    这个方法是很有用的。
    这个函数只会根据其他配置参数如TaskManagers的slot数，
    来进行本地的数据传输而不是在网络中进行传输.

2、window

   1）window的类型，及应用场景。

• 滚动窗口
• 滑动窗口
• 会话窗口

   2）window、windowall的区别。
    Window是无限数据流处理的核心，Window将一个无限的stream拆分成有限大小的”buckets”桶，我们可以在这些桶上做计算操作。分组的stream调用keyBy(…)和window(…)，而非分组的stream中window()换成了windowAll(…）。

3、slot 槽位、并行度、链chain

    Flink 通过 Task Slots 来定义执行资源。每个 TaskManager 有一到多个 task slot，每个 task slot 可以运行一条由多个并行 task 组成的流水线。
    Flink 内部通过 SlotSharingGroup 和 CoLocationGroup 来定义哪些 task 可以共享一个 slot， 哪些 task 必须严格放到同一个 slot。

    链式的原则，也即是什么情况下才会对task进行链式操作呢？简单梗概一下：

    上下游的并行度一致
    下游节点的入度为1 （也就是说下游节点没有来自其他节点的输入）
    上下游节点都在同一个 slot group 中（下面会解释 slot group）
    下游节点的 chain 策略为 ALWAYS（可以与上下游链接，map、flatmap、filter等默认是ALWAYS）
    上游节点的 chain 策略为 ALWAYS 或 HEAD（只能与下游链接，不能与上游链接，Source默认是HEAD）
    两个节点间数据分区方式是 forward（参考理解数据流的分区）
    用户没有禁用 chain
    --------------------------------------------------
    slot和parallelism总结
    1.slot是静态的概念，是指taskmanager具有的并发执行能力
    2.parallelism是动态的概念，是指程序运行时实际使用的并发能力
    3.设置合适的parallelism能提高运算效率，太多了和太少了都不行
    4.设置parallelism有多中方式，优先级为api>env>p>file

4、time、watermark

（1）event time
injection time
process time
（2）watermark
Watermark是Apache Flink为了处理EventTime 窗口计算提出的一种机制,本质上也是一种时间戳。watermark是用于处理乱序事件或延迟数据的，这通常用watermark机制结合window来实现（Watermarks用来触发window窗口计算）。
比如对于late element，我们不能无限期的等下去，必须要有个机制来保证一个特定的时间后，必须触发window去进行计算了。这个特别的机制，就是watermark。 可以把Watermark看作是一种告诉Flink一个消息延迟多少的方式。定义了什么时候不再等待更早的数据。
watermark原理
Watermark是一种衡量Event Time进展的机制，它是数据本身的一个隐藏属性。通常一条记录中某个字段就代表了该记录的发生时间。例如基于Event Time的数据，自身都包含一个类型为timestamp的字段rowtime，例如1543903383（2018-12-04 14:03:03），定义一个基于rowtime列，策略为偏移3s的watermark，这条数据的水印时间戳则是：
1543903383-3000 = 1543900383（2018-12-04 14:03:00）
该条数据的水印时间含义：timestamp小于1543900383（2018-12-04 14:03:00）的数据，都已经到达了。

 

5、状态

如何理解flink中state(状态)
state泛指
state泛指：flink中有状态函数和运算符在各个元素(element)/事件(event)的处理过程中存储的数据（注意：状态数据可以修改和查询，可以自己维护，根据自己的业务场景，保存历史数据或者中间结果到状态(state)中）；
使用状态计算的例子：
当应用程序搜索某些事件模式时，状态将存储到目前为止遇到的事件序列。
在每分钟/小时/天聚合事件时，状态保存待处理的聚合。
当在数据点流上训练机器学习模型时，状态保持模型参数的当前版本。
当需要管理历史数据时，状态允许有效访问过去发生的事件。
案例理解state
以例子理解flink的状态(state)
无状态计算指的是数据进入Flink后经过算子时只需要对当前数据进行处理就能得到想要的结果；有状态计算就是需要和历史的一些状态或进行相关操作，才能计算出正确的结果；
无状态计算的例子：
    比如：我们只是进行一个字符串拼接，输入 a，输出 a_666,输入b，输出 b_666输出的结果跟之前的状态没关系，符合幂等性。
    幂等性：就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用；
有状态计算的例子：
    以wordcount中计算pv/uv为例：
    输出的结果跟之前的状态有关系，不符合幂等性，访问多次，pv会增加；

6、checkpoint

  （1）存储位置：内存，rocksdb，hdfs。
  （2）如何设置增量checkpoint
      在集群配置那儿加上state_backend=rocksdb
      state_backend_incremental=true
  （3）checkpoint慢，一般考虑数据倾斜。

7、执行流程，graph。

Flink 中的执行图可以分成四层：StreamGraph -> JobGraph -> ExecutionGraph -> 物理执行图。
（1）StreamGraph：是根据用户通过 Stream API 编写的代码生成的最初的图。用来表示程序的拓扑结构。
（2）JobGraph：StreamGraph经过优化后生成了 JobGraph，提交给 JobManager 的数据结构。主要的优化为，将多个符合条件的节点 chain 在一起作为一个节点，这样可以减少数据在节点之间流动所需要的序列化/反序列化/传输消耗。
（3）ExecutionGraph：JobManager 根据 JobGraph 生成的分布式执行图，是调度层最核心的数据结构。
（4）物理执行图：JobManager 根据 ExecutionGraph 对 Job 进行调度后，在各个TaskManager 上部署 Task 后形成的“图”，并不是一个具体的数据结构。