博主为了构建统一的flink学习笔记
https://ci.apache.org/projects/flink/flink-docs-release-1.13
https://ci.apache.org/projects/flink/flink-docs-release-1.12
Flink 算子之间可以通过一对一（直传）模式或重新分发模式传输数据：
一对一模式（例如上图中的 Source 和 map() 算子之间）可以保留元素的分区和顺序信息。这意味着 map() 算子的 subtask[1] 输入的数据以及其顺序与 Source 算子的 subtask[1] 输出的数据和顺序完全相同，
即同一分区的数据只会进入到下游算子的同一分区。
重新分发模式（例如上图中的 map() 和 keyBy/window 之间，以及 keyBy/window 和 Sink 之间）则会更改数据所在的流分区。当你在程序中选择使用不同的 transformation，
每个算子子任务也会根据不同的 transformation 将数据发送到不同的目标子任务。例如以下这几种 transformation 和其对应分发数据的模式：
keyBy()（通过散列键重新分区）、broadcast()（广播）或 rebalance()（随机重新分发）。在重新分发数据的过程中，
元素只有在每对输出和输入子任务之间才能保留其之间的顺序信息（例如，keyBy/window 的 subtask[2] 接收到的 map() 的 subtask[1] 中的元素都是有序的）
。因此，上图所示的 keyBy/window 和 Sink 算子之间数据的重新分发时，不同键（key）的聚合结果到达 Sink 的顺序是不确定的。
当使用基于堆的 state backend 保存状态时，访问和更新涉及在堆上读写对象。但是对于保存在 RocksDBStateBackend 中的对象，访问和更新涉及序列化和反序列化，所以会有更大的开销。
但 RocksDB 的状态量仅受本地磁盘大小的限制。还要注意，只有 RocksDBStateBackend 能够进行增量快照，这对于具有大量变化缓慢状态的应用程序来说是大有裨益的。
所有这些 state backends 都能够异步执行快照，这意味着它们可以在不妨碍正在进行的流处理的情况下执行快照。
BILIBILI架构
流式机器学习所谓的样本生成，其实就是多个数据流按照相同的 key 做一个拼接。比如说，我们有三个数据流，数据清洗后的结果存储为 <k , v>, k 是聚合的 key，v 是样本中需要的值。
数据 union 后做 KeyBy 聚合，聚合后将数据存储在内存区域 value state 中。如下图所示：
如果 k1 不存在，则注册 timer，再存到 state 中。
如果 k1 存在，就从 state 中把它给拿出来，更新之后再存进去。到最后它的 timer 到期之后，就会将这条数据输出，并且从 state 中清除掉。
BAIXINYINHANG
