weixin_43923463的博客

Flink 本身是批流统一的处理框架，所以 Table API 和 SQL，就是批流统一的上层处理 API。目前功能尚未完善，处于活跃的开发阶段。Table API 是一套内嵌在 Java 和 Scala 语言中的查询 API，它允许我们以非常直观的方式，组合来自一些关系运算符的查询（比如 select、filter 和 join）。而对于 Flink SQL，就是直接可以在代码中写 SQL，来实现一些查询（Query）操作。Flink 的 SQL 支持，基于实现了 SQL 标准的 Apache Calci

一个或多个由简单事件构成的事件流通过一定的规则匹配，然后输出用户想得到的数据，满足规则的复杂事件。特征有如下几点：如下图中，将输入流中的元素，按照连续两个事件，且第一个元素为正方形，第二个元素为三角形进行过滤：CEP用于分析低延迟、频繁产生的不同来源的事件流。CEP可以帮助在复杂的、不相关的事件流中找出有意义的模式和复杂的关系，以接近实时或准实时的获得通知并阻止一些行为。CEP支持在流上进行模式匹配，根据模式的条件不同，分为连续的条件或不连续的条件；模式的条件允许有时间的限制，当在条件范围内没有达到满足的条

此程序有一个隐患：现将所有数据keyBy到了同一条流，每一个小时取一次uv，添加到hashSet去重，如果程序的用户向很大，如1亿个独立访客，一个用户的用户id为100个字符，那么一个窗口中的独立访客就要占用10G的内存。想要优化这种使用了增量聚合与全窗口聚合的程序，就需要使用一种新的数据结构 – 布隆过滤器。本质上布隆过滤器是一种数据结构，是一种比较巧妙的概率型数据结构（probabilistic datastructure），特点是高效地插入和查询，可以用来告诉你“某样东西一定不存在或者可能存在”。相比

事务写入 sink 连接器需要和 Flink 的检查点机制集成，因为只有在检查点成功完成以后，事务写入 sink 连接器才会向外部系统 commit 数据。为了简化事务性 sink 的实现，Flink 提供了两个模版用来实现自定义 sink 运算符。这两个模版都实现了 CheckpointListener 接口。CheckpointListener 接口将会从作业管理器接收到检查点完成的通知。GenericWriteAheadSink 模版会收集检查点之前的所有的数据，并将数据存储到 sink任务的运算符状

当在分布式系统中引入状态时，自然也引入了一致性问题。一致性实际上是"正确性级别"的另一种说法，也就是说在成功处理故障并恢复之后得到的结果，与没有发生任何故障时得到的结果相比，前者到底有多正确？举例来说，假设要对最近一小时登录的用户计数。在系统经历故障之后，计数结果是多少？如果有偏差，是有漏掉的计数还是重复计数？特点总结如下：在流处理中，一致性可以分为3个级别：曾经，at-least-once非常流行。第一代流处理器(如Storm和Samza)刚问世时只保证at-least-once，原因有二。最先保证ex

当接收到一个分界线2和数据4，数据4不能和数据8进行累加，分界线2之后的所有数据都不能进行累加，都需要缓存到sum even算子中，而橘色的检查点2之前的数据，都需要和数据8进行累加，这就是上面两句话的意思，同时也是检查点分界线名称的由来，其将数据流分隔开了。JobManager 会向 Source 任务针对每一个并行任务，都发送一条带有新检查点ID 消息的检查点分界线（三角形，当前检查点分界线id=2，此处的2与数据无关），通过这种方式让检查点分界线跟随着数据向下游流动，达到来启动检查点的目的。

Flink内置的很多算子，数据源source，数据存储sink都是有状态的，流中的数据都是buffer records，会保存一定的元素或者元数据。这种检查点的保存和恢复机制可以为应用程序内部状态提供“精确一次”（exactly-once，每一个数据只会被计算一次，遇到回退现象，需要将加上的数字再减去）的一致性，因为所有算子都会保存检查点并恢复其所有状态，这样一来所有的输入流就都会被重置到检查点完成时的位置。旧的流处理系统并不支持有状态的计算，而新一代的流处理系统则将状态及其正确性视为重中之重。

- ProcessFunction：只能处理单条流DateStream，由于处理的是没有经过分流的流，所以自然没有办法注册定时器和状态变量，目前使用到的所有状态变量都是针对key所独有的，所以在对一条流进行keyBy以后，可以使用KeyedProcessFunction。- KeyedProcessFunction：使用key对数据做了逻辑分区（分流、分组），使用KeyedProcessFunction，配合字典状态MapState + 定时器可以模拟出完整的ProcessWindowFunction功能

由于存在迟到的元素，所以已经计算出的窗口结果是不准确和不完全的。我们可以使用迟到元素更新已经计算完的窗口结果。如果我们要求一个 operator 支持重新计算和更新已经发出的结果，就需要在第一次发出结果以后也要保存之前所有的状态。但显然我们不能一直保存所有的状态，肯定会在某一个时间点将状态清空，而一旦状态被清空，结果就再也不能重新计算或者更新了。而迟到的元素只能被抛弃或者发送到旁路输出流。window operator API 提供了方法来明确声明我们要等待迟到元素。当使用 event-timewi

Flink 认为时间戳小于水位线的事件都已到达。水位线是一种逻辑时钟。水位线由程序员编程插入到数据流中。水位线是一种特殊的事件。在事件时间的世界里，水位线就是时间。水位线 = 观察到的最大时间戳 - 最大延迟时间 - 1 毫秒。水位线超过窗口结束时间，窗口闭合，默认情况下，迟到元素被抛弃。Flink 会在流的最开始插入一个时间戳为负无穷大的水位线。Flink 会在流的最末尾插入一个时间戳为正无穷大的水位线。

当Flink接收到数据时，会按照一定的规则去生成Watermark，这条Watermark就等于当前所有到达数据中的maxEventTime - 最大延迟时长 -1ms，也就是说，Watermark是基于数据携带的时间戳生成的，一旦Watermark比当前未触发的窗口的停止时间要晚，那么就会触发相应窗口的执行。的-4001ms的水位线，其不能够跳过这个算子向前传送。它通常由事件中的时间戳描述，例如采集的日志数据中，每一条日志都会记录自己的生成时间，Flink通过时间戳分配器访问事件时间戳。

streaming流式计算是一种被设计用于处理无限数据集的数据处理引擎，而无限数据集是指一种不断增长的本质上无限的数据集，而window是一种切割无限数据为有限块进行处理的手段。Window是无限数据流处理的核心，Window将一个无限的stream拆分成有限大小的”buckets”桶，我们可以在这些桶上做计算操作。ProcessFunction：不分流直接聚合，不可以使用定时器和状态变量，因为其没有经过keyBy，定时器和状态变量都是针对key的，只有processElement。

在实际环境这种经常会有这样的需求：在函数处理数据之前，需要做一些初始化的工作；或者需要在处理数据时可以获得函数执行上下文的一些信息，如数据库的连接；以及在处理完数据时做一些清理工作。而 DataStream API 就提供了这样的机制。DataStream API 提供的所有转换操作函数，都拥有它们的富版本，并且在使用常规函数或者匿名函数的地方来使用富函数。下面就是富函数的一些例子，可以看出，只需要在常规函数的前面加上 Rich 前缀就是富函数了。当使用富函数时，可以实现两个额外的方法：另外，getRunt

针对每一个输入事件，算子将会更新保存的聚合结果，并发送一个带有更新后的值的事件到下游算子。那么使用递归又带来了一个问题，递归的栈会超过内存，造成内存溢出Stack Overflow，那么伪递归用新来的栈去覆盖原有的栈，栈的深度不变，所以可以使用伪递归来模拟循环，伪递归当中有累加器的存在。总结：滚动聚合的要点在于每一个Key都有自己的累加器（状态变量），一条数据来到处理完成之后就丢弃了，向下游发送的数据是累加器中的数据，这样就不需要将所有的数据都保存下来，节省内存空间，性能高于批处理。

Flink中每一个worker(TaskManager)都是一个**JVM**进程，它可能会在独立的线程上执行一个或多个subtask。为了控制一个worker能接收多少个task，worker通过task slot来进行控制（一个worker至少有一个task slot）。每个task slot表示TaskManager拥有资源的**一个固定大小的子集**。假如一个TaskManager有三个slot，那么它会将其管理的内存分成三份给各个slot。资源slot化意味着一个subtask将不需要跟来自其

在编写程序时需要注意：Flink程序支持java和scala两种语言。在引入包中，有java和scala两种包时注意要使用对应语言的包。总结：数据流的来源是DataStreamSource，执行map操作之后，变为单输出流的算子SingleOutputStreamOperator，经过shuffle操作之后，变为一个键控流（按照key进行逻辑分区的流）KeyedStream，分组之后的流再聚合完成之后，发送给下游，流又变成单输出流SingleOutp

批处理的特点是有界、持久、大量，非常适合需要访问全套记录才能完成的计算工作，一般用于离线统计。流处理的特点是无界、实时, 无需针对整个数据集执行操，而是对通过系统传输的每个数据项执行操作，一般用于实时统计。在Spark/SparkStreaming 的世界观中，一切都是由批次组成的，离线数据是一个大批次，而实时数据是由一个一个无限的小批次组成的，没有认识到无界流的本质，但不影响其大量使用，只是在特定场景下，其不如Flink。。而在flink的世界观中，一切都是由流组成的，离线