Flink

大数据平台的Flink流处理领域模型梳理，架构设计梳理，包含实际工作中的经验积累，没达到百分百完美 不喜勿喷。

FLINK

• 流处理领域知识
  • 流处理需要解决的问题？
    • 如何使用数据流进行历史事件处 理并实现“时间旅行”？
    • 如何基于乱序事件产生精确结果？
  • 流处理基础
    • 流处理核心概念
      • 时间语义（ time semantics ）
      • 状态管理（ state management）
    • 流处理的关键特性
      • 低延迟
    • DataFlow图
      • Dataflow程序描述了数据如何在不同操作之间流动。Dataflow程序通常表示为有向图。
      • 逻辑图
        • 表达了高层视角下的计算 逻辑。
        • 图中顶点(圆圈)称为算子，表示计算；边表示表示依赖关系(箭头线)
        • 算子
          • 算子是 Dataflow 程序的基本功能单元 ，它们从输入获取数据，对其进行计算， 然后产生数据并发往输出以供后续处理。
        • 数据源
          • 没有输入端的算子称为数据源。
        • 数据汇
          • 没有输出端的算子称为数据汇。
        • 一个 Dataflow 图至少要有一个数据源和一个数据汇。
      • 物理图
        • 指定程序的执行细节。 例如 ： 当我们使用分布式处理引擎时 ，每个算子 可能会在不同物理机器上运行多个并行任务。
        • 在逻辑Dataflow 图中，顶点代表算子； 在物理Dataflow图中，顶点代表任务。
          • “抽取主题标签”和“计数”算子都包含两 个并行算子任务，每个任务负责计算一部分输入数据 。
      • 并行性
        • 数据并行(data paralelism)
          • 将输入数据分组，让同一操作的多个任务并行执行在不同数据子集上，这种井行称为 数据井行(data paralelism)。 数据并行非常有用，因为它能够将计算负载分配到多个节点上从而允许处理大规模的数据。
        • 任务并行(task parallelism)
          • 让不同算子的任务（基于相同或不同的数据）并行计算，这种并行称为任务井行（ task parallelism ）。 通过任务并行，可以更好地利用集群的计算资掘。
      • 数据交换策略
        • 数据交换策略定义了如何将数据项分配给物理 Dataflow 图中的不同任务。这 些策略可以由执行引擎根据算子的语义自动选择，也可以由 Dataflow 编程人 员显式指定。
        • 转发（forwards trategy）
          • 转发策略（forwards trategy）在发送端任务和接收端任务之 间一对一地进 行数据传输。如果两端任务运行在同一物理机器上（通常 由任务调度器决 定），该交换策略可以避免网络通信。
        • 广播（ broadcast strategy ）
          • 广播策略（ broadcast strategy ）会把每个数据项发往下游算子的全部并行 任务。 该策略会把数据复制多份且涉及网络通信，因此代价十分昂贵。
        • 基于键值（key-based strategy）
          • 基于键值的策略（key-based strategy）根据某一键值属性对数据分区，并保证键值相同的数据项会交由同一任务处理。图 2-2 中， “抽取主题标签” 算子的输出就是按照键值（主题标签）划分的，因此下游的计数算子可以 正确计算出每个主题标签的出现次数。
        • 随机（random strategy）
          • 随机策略（random strategy）会将数据均匀分配至算子的所有任务，以实 现计算任务的负载均衡。
    • 数据流的定义
      • 数据流是一个可能无限的事件序列。 数据流中的事件可以表示监控数据、传感器测量值、信用卡交易、气象站观 观测数据、在线用户交互，以及网络搜索等。
    • 并行流处理
      • 性能评测指标
        • 尽可能快地计算结果
        • 事件接入速率
      • 延迟
        • 延迟表示处理一个事件所需的时间。本质上，它是从接收事件到在输出中观 察到事件处理效果的时间间隔。 在流处理中，延迟是以时间片（例如毫秒）为单位测量的。
        • 平均延迟
          • 例如：平均延迟为 10 毫秒表示平均每条数据会在 10 毫秒 内处理；而第 95 百分位延迟在 10 毫 秒意味着 95% 的事件会在 10 毫秒内处理 。平均值会掩盖处理延迟的真实分布， 从而导致难以发现问题。
        • 最大延迟
        • 延迟的百分位数值
      • 吞吐
        • 吞吐是用来衡量系统处理能力（处理速率）的指标，它告诉我们系统每单位 时间可以处理多少事件。 吞吐的衡量方式是计算每个单位时间的事件或操作数。 但要注意，处理速率 取决于数据到来速率，因此吞吐低不一定意味着性能差。
        • 背压（ backpressure)
          • 如果系统持续以力不能及的高速率接收数据，那么缓冲区可能 会用尽，继而可能导致数据丢失。这种情形通常被称为背压（ backpressure)
      • 延迟和吞吐如何相互影响
        • 首先
          • 空负载的情况下延迟会达到最优
            • 高峰时段，顾客必须要排队，此
            • 时延迟将增加。
        • 高峰时段，顾客必须要排队，此时延迟将增加。
        • 降低延迟实际上可以提高吞吐。
        • 显然，系统执行操作越快，相同时间内执行的操作数目就会越多 。 事实上，这就是在流处理管道中利用井行实现的效果。通过井行处理多条数据流，可以在处理更多事件的同时降低延迟。
    • 流式操作
      • 状态化流处理
      • 错误场景
      • 一致性
      • 操作类型
        • 无状态(stateless)
          • 无状态的操作不会维持内部状态，即处理事件时无需依赖己处理过的事件，也 不保存历史数据。 事件处理互不影响且与事件到来的时间无关，无状态 的操作很容易并行化。 此外，如果发生故障，无状态的算子可以很容易地重启， 并从中断处继续工作 。
        • 有状态(stateful)
          • 有状态算子可能需要维护之前接收的事件信息 。 它们的状态会根据传入的事件更新，并用于未来事件的处理逻辑中。有状态 的流处理应用在并行化和容错方面会更具挑战性，因为它们需要对状态进行 高效划分，并且在出错时需进行可靠的故障恢复。
      • 数据接入
        • 数据接入操 作是从外部数据惊获取原始数据并将其转换成适合后续处理的格式。 数据接入操 作是从外部数据惊获取原始数据并将其转换成适合后续处理的格式。
      • 数据输出
        • 数据接入操 作是从外部数据惊获取原始数据并将其转换成适合后续处理的格式。
      • 概要
        • 数据接入和数据输出操作允许流处理引擎和外部系统进行通信。
      • 转换操作
        • 转换操作是一类“只过一次”的操作，它们会分别处理每个事件。这些操作 逐个读取事件，对其应用某些转换并产生一条新的输出流。 转换操作是一类“只过一次”的操作，它们会分别处理每个事件。这些操作 逐个读取事件，对其应用某些转换并产生一条新的输出流。 算子既可以同时接收多个输入流或产生多条输出流，也可以通过单流分割或 合并多条流来改变 Dataflow 图的结构。
        • 子主题
      • 滚动聚合
        • 滚动聚合 （如求和、求最小值和求最大值 ） 会根据每个到来的事件持续更新 结果。 聚合操作都是有状态的，它们通过将新到来的事件合并到 已有状态来 生成更新后的聚合值。
        • 注意
          • 注意，为了更有效地合并事件和当前状态并生成单个结果， 聚合函数必须满足可结合（ associative ）及可交换（ commutative ）的条件， 否则算子就需要存储整个流的历史记录。
          • 聚合函数
            • 必须满足
              • 可结合（ associative ） 及 可交换（ commutative ） 的条件，否则算子就需要存储整个流的历史记录。
      • 窗口操作
        • 能做什么
          • 产生单个有用的结果
          • 在数据流上完成一些具有切实语义价值的查询。
        • 原理
          • 窗口操作
            • 持续创建
              • 桶
                • 有限事件集合
                • 事件
                  • 根据其时间或其他数据属性
                    • 分配
                      • 到不同桶中。
        • 准确定义窗口算子语义要素
          • 决定事件如何分配到桶中
          • 窗口用怎样的频率产生结果
        • 窗口的行为
          • 由一系列策略定义
        • 窗口策略 (定义窗口行为策略)
          • 决定了
            • 什么时间创建桶
            • 事件如何分配到桶中
            • 桶内数据什么时间参与计算。
              • 参与计算的决策会根据触发条件判定 当触发条件满足时， 桶内数据会发送给一个计算函数（evaluation function）， 由它来对桶 中 的元素应用计算逻辑。
        • 策略
          • 指定
            • 基于时间（例如最近 5 秒钟接收 的事件）
            • 基于数量 （例如最新 100 个事件）
            • 基于其他数据属性
        • 窗口类型的语义
          • 滚动窗 口（ tu mb l i n g w i ndow ）
            • 将事件分配到长度固定且互不重叠的桶中 。在 窗口边界通过后，所有事件会发送给计算函数进行处理。
            • 基于数量的（countbased）滚动窗口
              • 基于数量的（ countb ased ）该动窗 口定义了 在触发计算前需要集齐多少条事件。
            • 基于时间的(time-based）滚动窗口
              • 基于时间的 ( t ime - based ）滚动窗口定义 了在桶中缓冲数据的时间间隔。
            • 概要
              • 特点
                • 桶长度固定
                • 桶互不重叠
          • 滑动窗口（ sliding w indow ）
            • 滑动窗口（ sliding w indow ）将事件分配到大小固定且允许相互重叠的桶中， 这意味着每个事件可能会同时属于多个桶 。 我们通过指定长度和滑动间隔来 定义滑动窗口。滑动间隔决定每隔多久生成一个新的桶。
            • 概要
              • 特点
                • 桶大小固定
                • 允许桶相互重叠
          • 会话窗口（ session window ）
            • 在一些常见的真实场景中非常有用，这些场景既不适合用攘动窗口也不适合用滑动窗口。 会话窗口根据会话间隔（session gap）将事件分为不 同的会话，该间隔值定义了会i舌在关闭前的非活动时间长度。
            • 假设
              • 在线分析 用户行为
                • 有一个应用要在线分析用户行为，在该应用中我们要把事件按照用户的同 一活动或会话来源进行分组。 会店由发生在相邻时间内的一系列事件外加一段非活动时间组成。
            • 会话组成
              • 会店由发生在相邻时间内的一系列事件外加一段非活动时间组成。
              • 相邻时间内的一系列事件
                • • 一段非活动时间组成
            • 概要
              • 特点
                • 长度并非预先定义，和实际数据有关
      • 数据接入
        • 转换操作
          • 窗口操作
            • 滚动聚合
              • 数据输出
    • 时间语义
      • 流处理场景下 一分钟的含义
      • 处理时间（ processing time ）
        • 处理时间是当前流处理算子所在机器上的本地时钟时 间。 基于处理时间的窗口会包含那些恰好在一段时间内到达窗口算子的事件， 这里的时间段是按照机器时间测量的 。
        • 适用场景
          • 一种情况，处理时间窗口能够将延迟降至最低。
          • 另一种情况，你需要周期性地实时报告结果而 无论其准确性如何。
            • 常见示例应用是实时监控仪表盘，它会接收井展示事件 聚合结果。
          • 最后，处理时间窗口能够表示数据流自身的真实情况，这可能会在某 些用例中派上用场。
            • 例如，你可能想观察数据流的接入情况，通过计算每秒事件 数来检测数据中断。
          • 总而言之，虽然处理时间提供了很低的延迟， 但它的结果依赖处理速度，具有不确定性。
      • 事件时间（ eve nt time ）
        • 事件时间是数据流中事件实际发生的时间，它以附加在数据流中事件的时间 戳为依据。这些时间戳通常在事件数据进入流处理管道之前就存在（例如事 件的生成时间）。 基于事件时间 的操作是可预测的， 其结果具有确定性。无论数据流的处理速度如何、事件到达算子的顺序怎样， 基于事件时间的窗口都会生成同样的结果。 普遍存在的无序问题也可以借此解决。
        • 将
          • 处理速度
          • 结果内容
          • 彻底解偶
        • 挑战之一
          • 如何处理延迟事件。
            • 由于无需考虑、迟到或乱序的事件，窗口只需简单地缓冲事件，然后在达到 特定时间后立即触发窗口计算即可。因此对于那些更重视处理速度而非准确度的 应用，处理时间就会派上用场。
        • 且结合 可重放的数据流，时间戳所带来的确定性允许你对历史数据“快进”。
          • 这意味着你可以通过重放数据流来分析历史数据，就如同它们是实时产生的一样。 此外，你可以把计算“快进”到现在，这样一旦你的程序赶上了当前事件产 生的进度，它能够以完全相同的程序逻辑作为实时应用继续运行 。
        • 事件时间窗口
          • 怎样决定事件时间窗口的触发时机？
            • 换言之 ，我们需要等多久才能确 定已经收到了所有发生在某个特定时间点之前的事件？
          • 此外，我们如何得知数据会产生延迟？
          • 鉴于分布式系统现实的不确定性以及外部组件可能引发任 意延迟，这两个问题都没有完美的答案。
          • 水位线
            • 水位线是一个全局进度指标 ，表示我们确信不会再有延迟事件到来的某个时间点。 本质上，水位线提供了一个逻辑时钟，用来通知系统当前的事件时间。 当一个算子接收到时间为 T 的水位线，就可以认为不会再收到任何时间戳小 于或等于 T 的事件了。水位钱无论对于事件时间窗口还是处理乱序事件的算 子都很关键。算子一且收到某个水位线，就相当于接到信号：某个特定时间 区间的时间戳已经到齐，可以触发窗口计算或对接收的数据进行排序了。 在很多现实应用中，系统无战获取足够多的信息来完美地确定水位线。
            • 允许我们在结果的准确性和延迟之间做出取舍。
            • 激进的水位线策略
              • 该情况下 ，延迟事件可能会在水位 线之后到来，我们必须额外加一些代码来处理它们。
              • 保证了低延迟，但随之而来的是低可信度。
            • 水位线过于保守策略
              • 虽然可信度得以保证，但可能会无谓地增加处理延迟。
            • “拖后腿”的任务
              • 无论水位线是由用户定义还是自 动生成，只要存在“拖后腿”的任务，追踪分布式系统中的全局进度就可能 出现问题，因此简单地依赖水位线并不总是可以高枕无忧 。
            • 流处理系统很关键的一点
              • 流处理系统很关键的一点是能提供某些机制来处理那些可能晚于水位线的迟到事件。根据 应用需求的不同，你可能想直接忽略这些事件，将它们写入日志或利用它们 去修正之前的结果。
        • 场景
          • 能保证结果的准确性，并允许你处理延迟甚至无序的事件，可以保证数据乱序的情况下结果依然正确。
    • 状态
      • 状态在数据处理中无处不在，任何一个稍复杂的计算者R要用它。 为了生成结果，函数会在一段时间或基于一定个数的事件来累积状态（例如计算聚合或检测某个模式）。 有状态算子同时使用传入的事件和内部状态来计算输出。 在持续运行的流式作业中，每次处理事件所用到的状态都是持久化的
      • 避免内部状态无限增长
        • 为了限制状态大小
          • 算子通常都会只保留到目前为止所见
            • 事件的摘要或概览
              • 数量值
              • 一个数量值
              • 一个累加值
              • 一个对至今为止全部事件的抽样
              • 一个窗口缓冲
              • 一个保留了应用运行过程中某些有价值信息的自定义数据结构。
      • 状态管理
        • 系统需要高效地管理状态并保证它们不受并发更新的影响。
      • 状态划分
        • 由于结果需要同时依赖状态和到来的事件，所以状态并行化会变得异常复 杂。幸运的是，在很多情况下可以把状态按照键值划分，井独立管理每一 部分。举例而言，如果你要处理从一组传感器得到的测量值数据流，则可 以用分区算子状态、（ partitioned operator state ）来单独维护每个传感器的 状态。
      • 状态恢复
        • 最后一个也是最大的挑战在于，有状态算子需要保证状态、可以恢复，并且 即使出现故障也要确保结果正确。
    • 一致性模型
      • 应用状态一致性
      • 保证输出的一致性
      • 不是一回事
    • 任务故障
      • 对于输入流中的每个事件，任务都需要执行以下步骤： ①接收事件井将它们 存在本地缓冲区；②选择性地更新内部状态、；①产生输出记录。上述任何一 个步骤都可能发生故障，而系统必须在故障情况下明确定义其行为 。 如果故 障发生在第一步，事件是否会丢失？如果在更新内部状态后发生故障，系统 恢复后是否会重复更新？在上述情况下，结果是否确定？
    • 结果保障
      • “结果保障”，我们指的是 流处理引擎内部状态的一致性。也就是说，我们关注故障恢复后应用代码能 够看到的状态值。请注意，保证应用状态的一致性和保证输出的一致性并不 是一 回事儿。一旦数据从数据汇中写出，除非目标系统支持事务，否则结果 的正确性将难以保证。
      • 至多一次
        • 任务发生故障时最简单的措施就是既不恢复丢失的状态，也不重放丢失的事 件。至多一次是一种最简单的情况，它保证每个事件至多被处理一次。换句 话说，事件可以随意丢弃，没有任何机制来保证结果的正确性。这类保障也 被称作“没有保障”，因为即便系统丢掉所有事件也能满足其条件。无论如何， 没有保障听上去都是个不靠谱的主意。但如果你能接受近似结果并且仅关注 怎样降低延迟，这种保障似乎也可以接受。
        • 被称作“没有保障”
      • 至少一次
        • 对大多数现实应用而言，用户期望是不丢事件，这类保障称为至少一次。它 意味着所有事件最终都会处理，虽然有些可能会处理多次。如果正确性仅依 赖、信息的完整度，那重复处理或许可以接受 。 例如，确定某个事件是否在输入流中出现过，就可以利用至少一次保障正确地实现。 它最坏的情况也无非就是多几次定位到目标事件。 但如果要计算某个事件在输入流中出现的次数，至少一次保障可能就会返回错误的结果。
        • 确保至少一次结果 语义的正确性方法
          • 想办法从源头或缓冲区中重放事件。持久化事件日志会将所有事件写入永久存储，这样在任务故障时就可以重放它们 。
          • 采用记录确认（recordacknowledgments）
            • 该方法会将所有事件存在缓冲区中，直到处理管道中所 有任务都确认某个事件已经处理完毕才会将事件丢弃。
      • 精确一次
        • 精确一次是最严格， 也是最难实现的一类保障， 它表示不但没有事件丢失，而且每个事件对于内部状态的更新都只有一次。 本质上，精确一次保障意味着应用总会提供正确的结果，就如同故障从未发生过一般。
        • 最严格，最难实现的一类保障
        • 以至少一次保障为前提
          • 需要数据重放机制。
          • 流处理引 擎需要确保内部状态 的一致性
            • 流处理引擎需要确保内部状态的一致性，即在故障恢复后，引擎需要 知道某个事件对应的更新是否已经反映到状态上。
        • 实现方法
          • 事务性更新
            • 缺点
              • 可能会带来极大的性能开销。
          • 轻量级检查点机制
            • Flink 采用了轻量级检查点机制来实现精确一次结果保障。
      • 流处理引擎自身的应用状态
      • 端到端的精确一次
        • 端到端的保障指的是在整个数据处理管道上结果都是正确的。 在每个组件都提供自身的保障情况下，整个处理管道上端到端的保障会受制于保障最弱的那个组件。
        • 注意
          • 有时候你可以通过弱保障来实现强语义。
            • 一个常见情况就是某个任务执行一些诸如求最大值或最小值的幕等操作。 该情况下，你可以用至少一次保障来实现精确一次的语义。
        • 数据来源组件和一个数据终 点组件
• 内存分配
  • JVM堆内存
    • 占用堆内内存
      • 主进程
        • 主进程主要管理计算资源(ResourceManager ）和协调应用（ JobManager ）执行。 通常，主进程对于内存的要求并不苛刻，它默认的 JVM 堆内存数量只有 lGB a 但如果主进程需要管理 多个应用 或某个应用具有很多算子，你可能需 要利用 jobmanager.heap.size 配置项来增加 JVM 堆的容量。
        • 配置项
          • jobmanager.heap.size
      • 工作进程
        • 而工作进程要负责繁 重的工作以及处理潜在规模庞大的数据。
        • 配置项
          • taskmanager.heap.size
        • 使用的对象
          • TaskManager 运行时
          • 应用的算子
          • 应用的函数
          • 处理中的数据
          • 应用中基于内存或文件系统后端的状态
          • 应用jar包(用户代码类)
            • 如果你运行的应用有很多依赖，贝 IJ JVM 的堆外内存也会增长 比较严重，因为它需要存储所有 TaskMan ager 和用户代码类。
    • 占用堆外内存
      • Flink的网络栈
        • Flink的网络技基于 Netty 库，它会从本地（堆外） 内存分配网络缓冲区。为了顺利将记录在工作进程之间传输， Flink 需要足够 数量的网络缓冲区
        • 配置项
          • taskmanager.network.memory.fraction(设置整体的网络栈内存大小)
            • 它的值决定了 JVM 为网络缓冲区分配的内存比例， 默认配置是使用 JVM 堆内存的10%
          • taskmanager.mem ory.segment-size(配置网络缓冲区)
            • 配置单个网络缓冲区的大小，其默认值是 32KB 降低单个网络缓冲区的大小可以增加其数量，但会降低网络枝 整体的工作效率
          • taskmanager.network.memory.min(网络缓冲区的最小值)
            • Flink默认值是 64MB
          • taskmanager.network.memory.max(网络缓冲区的最小值)
            • Flink默认值是lGB
        • 分配计算策略
          • 其数目取决于算子任务之间的网络连接总数。对于通过 分区或广播策略连接的两个算子，其网络缓冲区的需求量取决于发送和接收 算子并行度的乘积。而对于包含多次分区的应用，这种乘积依赖关系会迅速 导致网络传输占用大量内存。
          • 其数目取决于算子任务之间的网络连接总数
          • 分区或广播策略连接的两个算子
            • 网络缓冲区的需求量=发送算子并行度*接收算子并行度
      • RocksDB （如果选它作为状态后端）
        • 遗憾的是它 的内存占用量没有什么直观的计算方法，因为具体值取会决于应用中键值分 区状态的数量。
  • 注意
    • 单个任务可能会耗尽其所在 JVM 的所有内存， Flin k 无法实现按任务或处理槽分配堆内存。
  • 注 :
    • 也可以将算子分配到不同的处理糟共享纽（ slot-sharing group ），从而实现将其任务分配到不同处理糟土 。
  • 隔离资源配置
    • 将每个 TaskManager配置成只有单个处理槽可以更好地隔离资惊，防止行为不当的应用对其他无关应用的干扰。
• 磁盘存储
  • Flink的工作进程需要在 本地文件系统上存储数据
    • 包括
      • 接收应用的JAR包
      • 写日志
      • 配置了RocksDB 状态后端时维护状态
    • 配置项
      • io.tmp.dirs(大部分都会默认用此目录)
        • io.tmp.dirs 参数值路径会默认用于Flink大多数有本地存储需求的组件。但 这些组件各自的路径也可以分别设置。 可以指定一个或多个目录（英文冒号分割）用 以在本地文件系统上存储数据。 默认情况下，数据会写入默认临时目录（由 Java 系统变量 java . io.tmpdir 决定，或 Linux 及 Mac OS 下的 ／ tmp 目录） 。
      • blob.storage.directory(Blob服务器的本地存储目录)
        • blob.storage.directory 参数项用于配置Blob服务器的本地存储目录，该目录常用于大文件（例如应用 JAR 包）交换。
      • env.log.dir(TaskManager 的日志文件目录)
        • env.log.dir 参数用于配置TaskManager 的日志文件目录（默认值是Flink安装位置 的斤./log目录）。
      • state.backend.rocksdb.localdir(RocksDB 状态后端)
        • RocksDB 状态后端会将应用状态维护在本地文件系统中。其维护目录可以利用 state.backend.rocksdb.localdir 参数来设置。如果没有显式指定该配置参数，默认 RocksDB 会使用io.tmp.dirs 的值。
      • state.checkpoints.dir(检查点)
      • state.savepoints.dir(保存点)
      • taskmanager.state.local.root-dirs(本地状态副本的存储位置）
      • high-availability.storageDir
      • jobmanager.archive.fs.dir
      • historyserver.archive.fs.dir
• 算子
  • Map
    • map可以理解为映射，对每个元素进行一定的变换后，映射为另一个元素。
    • map可以理解为映射，对每个元素进行一定的变换后，映射为另一个元素。
  • flatmap
    • flatmap可以理解为将元素摊平，每个元素可以变为0个、1个、或者多个元素。
    • flatmap可以理解为将元素摊平，每个元素可以变为0个、1个、或者多个元素。
  • filter
    • filter是进行筛选。
    • filter是进行筛选。
  • keyBy
    • 逻辑上将Stream根据指定的Key进行分区，是根据key的散列值进行分区的。
    • 逻辑上将Stream根据指定的Key进行分区，是根据key的散列值进行分区的。
  • reduce
    • reduce是归并操作，它可以将KeyedStream 转变为 DataStream。
    • reduce是归并操作，它可以将KeyedStream 转变为 DataStream。
  • fold
    • 给定一个初始值，将各个元素逐个归并计算。它将KeyedStream转变为DataStream。
    • 给定一个初始值，将各个元素逐个归并计算。它将KeyedStream转变为DataStream。
  • union
    • union可以将多个流合并到一个流中，以便对合并的流进行统一处理。是对多个流的水平拼接。 参与合并的流必须是同一种类型。
    • union可以将多个流合并到一个流中，以便对合并的流进行统一处理。是对多个流的水平拼接。参与合并的流必须是同一种类型。
  • join
    • 根据指定的Key将两个流进行关联。
  • coGroup
    • 关联两个流，关联不上的也保留下来。
    • 关联两个流，关联不上的也保留下来。
  • connect
    • 将两个流纵向地连接起来。DataStream的connect操作创建的是ConnectedStreams或BroadcastConnectedStream，它用了两个泛型，即不要求两个dataStream的element是同一类型。
    • 将两个流纵向地连接起来。DataStream的connect操作创建的是ConnectedStreams或BroadcastConnectedStream，它用了两个泛型，即不要求两个dataStream的element是同一类型。
  • split
    • 将一个流拆分为多个流。
    • 将一个流拆分为多个流。
• 领域词汇
  • DataStream API
  • JobManager（又称为 JobMaster）
    • 协调 Task 的分布式执行，包括调度 Task、协调创 Checkpoint 以及当 Job failover 时协调各个 Task 从 Checkpoint 恢复等。
  • TaskManager（又称为 Worker）
    • 执行 Dataflow 中的 Tasks，包括内存 Buffer 的分配、Data Stream 的传递等。
    • 包含0~*
      • Task Slot
        • Task Slot 是一个 TaskManager 中的最小资源分配单位
        • 包含0~*
          • Operator
            • 操作
  • Chain
    • 链
    • ResourceManager
  • processes
  • JobGraph
    • JobGraph
  • 主进程
    • 主进程主要管理计算资源 (ResourceManager ）和协调应用（ JobManager ）执行
  • 工作进程
    • 而工作进程要负责繁 重的工作以及处理潜在规模庞大的数据。
  • Flink的网络栈
    • 1~*
      • 网络缓冲区
        • 降低单个网络缓冲区的大小可以增加其数量，但会降低网络枝 整体的工作效率
  • JVM堆内存
    • 堆内内存
    • 堆外内存
    • 两者关系：JVM堆内存总数=堆内内存+堆外内存
  • 策略
  • 保存点
    • 组成
      • 所有任务状态数据文件的子目录
      • 一个包含了全部数据文件绝对路径的二进制元数据 文件组成
        • 由于元数据文件中存储的是绝对路径，所以将保存点移动到其他 路径会使其失效。
    • 整体目录结构
      • ＃保存点根路径) /savepoints/
        • ＃ 某一具体保存点的路径 /savepoint-:shortjobid-:savepointid/
          • ＃ 存储的算子状态 /:xxx
          • ＃ 某一保存点的二进制元数据文件 /_metadata
  • 检查点
  • RocksDB状态后端
  • 实时应用
  • 整体聚合（holisticaggregate）
  • 算子语义
  • 数据流
  • 逻辑流
  • 并行窗口
  • 离线分析
  • 时间旅行式分析（time travelanalyse ）
  • 流数据
    • 特点
      • 会有所延迟
      • 或以乱序到达
• 资料链接
  • 中文社区
    • https://flink-learning.org.cn/
      • Flink 1.13，面向流批一体的运行时与 DataStream API 优化
        • https://flink-learning.org.cn/article/detail/5376f5ef1a9c46f0e6fdeb91ec82756f
  • link on Yarn的两种模式
    • https://blog.csdn.net/young_0609/article/details/107302506
  • flink官网最新文档
    • https://nightlies.apache.org/flink/flink-docs-release-1.14/zh/docs/connectors/datastream/elasticsearch/
  • Java API提交任务
    • Flink通过flink-yarn远程提交任务到yarn集群
      • https://blog.csdn.net/clearlxj/article/details/120560130
    • link on yarn 使用Java API提交任务
      • https://blog.csdn.net/u013933879/article/details/90081969
    • java API 远程SSH 调用flink任务运行
      • https://blog.csdn.net/qq_31866793/article/details/120906498
    • https://www.jianshu.com/p/85f2b32186cb
    • https://blog.csdn.net/weixin_43704599/article/details/116785355
    • https://www.pianshen.com/article/49691903255/
    • https://blog.csdn.net/Sunzhongwei1988/article/details/105691069/
    • https://blog.csdn.net/clearlxj/article/details/120560174?utm_medium=distribute.pc_aggpage_search_result.none-task-blog-2~aggregatepage~first_rank_ecpm_v1~rank_v31_ecpm-7-120560174.pc_agg_new_rank&utm_term=flink%E6%8F%90%E4%BA%A4jar%E5%8C%85%E8%BF%90%E8%A1%8C%E6%98%BE%E7%A4%BA%E4%B8%BB%E7%B1%BB%E6%89%BE%E4%B8%8D%E5%88%B0&spm=1000.2123.3001.4430
  • 基于水位线和窗口的处理
    • https://mp.weixin.qq.com/s/m8deN8tRoUm_-L30WSI6mw
• 提交作业
  • 1.Session Mode 这个不用多说，也就是起一个 session，然后会有多个程序提交到这一个 session 中。 好处：集群资源仅分配一次，充分利用资源，程序App 启动较快 坏处：可能会连锁式的重启，jobManager 负载大 2.Per-Job Mode 使用的比较多，一个 application 一个 flink cluster 好处： 资源隔离，粒度更细，方便管理单个 job 坏处：当某个机器上有多个 client 时，会有较高的网络负载( 下载 jar 、传输 jar )以及消费大量的 CPU 来执行 main方法 3.Application Mode Application Mode 与 Per-Job Mode 类似，主要是为了解决 Per-Job Mode 的不足，通过 yarn.provided.lib.dirs 另外 client 是在 JobManager 上执行的，可以避免 带宽、CPU 的热点问题。 并且相比于 Per-Job Mode 来说，更强大，可以提交多个 job 4.总结 Application Mode 与 Per-Job Mode 类似，它主要是为了解决 Per-Job Mode 中由于 client 端导致的 带宽、CPU 问题 Session Mode 5.参考 https://ci.apache.org/projects/flink/flink-docs-release-1.12/deployment/#application-mode https://ci.apache.org/projects/flink/flink-docs-stable/deployment/resource-providers/yarn.html
  • Flink实战（三）开发过程中将程序提交到集群中执行
    • https://blog.csdn.net/u013076044/article/details/101163447?utm_medium=distribute.pc_relevant.none-task-blog-2~default~baidujs_title~default-0.no_search_link&spm=1001.2101.3001.4242.1