wr_java的博客

Flink之所以如此受到青睐，除了其提供高吞吐、低延迟和Exactly-once一致性语义支持外，更重要的是它能以流数据的处理方式来处理批数据，可以真正意义上实现批流处理的统一。比如， 一个TaskManager有3个槽，会将其管理的1/3的内存分给每个槽位。为方便执行，Flink将不同算子的子任务（subtask）链接到一个任务里，每一个任务在一个线程中执行。Dispatcher：提供应用程序提交的REST接口，对每一个提交的作业启动JobMaster，并运行Flink WebUI提供作业执行的信息。

在重新分发数据的过程中，元素只有在每对输出和输入子任务之间才能保留其之间的顺序信息（例如，keyBy/window 的 subtask[2] 接收到的 map() 的 subtask[1] 中的元素都是有序的）。这意味着 map() 算子的 subtask[1] 输入的数据以及其顺序与 Source 算子的 subtask[1] 输出的数据和顺序完全相同，即同一分区的数据只会进入到下游算子的同一分区。顾名思义，无界数据流就是指有始无终的数据，数据一旦开始生成就会持续不断的产生新的数据，即数据没有时间边界。

事件时间与处理时间是最常用的两个时间概念。事件时间能将处理速度与结果解耦，使结果不受实时数据乱序的影响。处理时间则主要用于更重视速度而非准确性的场景以及周期性的实时监控场景。在实时处理应用创建会用到的执行环境类StreamExecutionEnvironment中，默认使用的是处理时间。在流处理场景中，处理的是持续到达且可能是无穷的事件流，时间在这样的应用中是最核心的要素。

在进行窗口处理时，不可能无限期的等待延迟数据到达，当到达特定watermark时,认为在watermark之前的数据已经全部达到(即使后面还有延迟的数据), 可以触发窗口计算，这个机制就是 Watermark(水位线)，具体如下图所示。如果水位线设置的过于宽松，好处是计算时能保证近可能多的数据被收集到，但由于此时的水位线远落后于处理记录的时间戳，导致产生的数据结果延迟较大。如果设置的水位线过于紧迫，数据结果的时效性当然会更好，但由于水位线大于部分记录的时间戳，数据的完整性就会打折扣。3.2 水位线分配器。

触发器决定了一个窗口何时可以被窗口函数处理，每一个窗口分配器都有一个默认的触发器，如果默认的触发器不能满足你的需要，你可以通过调用trigger(...)来指定一个自定义的触发器。否则，由于全局窗口没有一个自然的结尾，无法执行元素的聚合，将不会有计算被执行。从滑动窗口的使用来看，滚动窗口其实是滑动窗口的一个特例，但窗口大小和滑动间隔相等的时候，滑动窗口就是一个滚动窗口。基于计数的窗口是根据事件的个数来对窗口进行划分的，概念跟基于时间的滚动窗口差不多，只不过窗口大小的划分，有时间变成了事件的个数。

FsStateBackend将运行时状态保存在TaskManager内存中，CheckPoint时，会将状态快照保存在指定的文件系统目录中，只会将少量元数据保存在JobManager，而高可用模式下，会将元数据保存在CheckPoint元数据文件中。Kafka连接器是在Flink中使用算子状态的一个很好的例子。由于存储空间的限制，以及当作业重启时状态会丢失，所以，MemoryStateBackend更适合本地开发与调试，或者状态较小并且作业重启时对状态丢失不敏感的场景，不太适合普遍意义上的生产场景中使用。

当一个算子接收到第一个输入流的快照barrier n时，它不能继续处理该流的其他数据，而是需要等待接收到最后一个流的barrier n，才可以生成算子的状态快照和发送挂起的输出记录，然后发送快照barrier n。savepoint是使用检查点机制创建的，作业执行状态的全局镜像，可用于flink的停止与恢复，升级等。由于有些算子是有状态的，有些算子是无状态的，实际上只要给有状态的算子添加算子ID就可以，但很多人并不太清楚哪些算子是有状态的，哪些是无状态的，所以，实际操作中，尽量给每个算子手动配置算子ID。

相同的场景，上游生产的速率为2，下游消费的速率为1，这样InputChannel中的内存很快就会耗尽，通信过程中就会返回credit=0给ResultSubPartition告知上游，下游已经没有空间了，上游也就不再继续发送数据给netty，直到下游消费给InputChannel腾出空间了，数据才会继续发送。值得注意的是，反压的根源节点并不一定会在反压监控面板体现出高反压，因为反压面板监控的是发送端，如果某个节点是性能瓶颈并不会导致它本身出现高反压，而是导致它的上游出现高反压。上面几项并不是全部场景。

本文从Flink的时间语义开始说起，详细介绍了三种时间语义的概念、特点及使用方式，接着对Flink处理乱序数据的一种机制---水位线进行详细说明，主要描述了水位线的基本概念，传播方式、生成方式，并对其中的细节部分进行了图解，可以加深对水位线的理解。最后，简单说明了一下Flink对于迟到数据的处理方式。

Flink TableAPI&SQL中的基于时间的操作(如window)，需要指定时间语义，表可以根据指定的时间戳提供一个逻辑时间属性。时间属性是表schama的一部分，当使用DDL创建表时、DataStream转为表时或者使用TableSource时，会定义时间属性。一旦时间属性被定义完成，该时间属性可以看做是一个字段的引用，从而在基于时间的操作中使用该字段。

Apache Flink提供了两种顶层的关系型API，分别为Table API和SQL，Flink通过Table API&SQL实现了批流统一。其中Table API是用于Scala和Java的语言集成查询API，它允许以非常直观的方式组合关系运算符（例如select，where和join）的查询。Flink SQL基于实现了标准的SQL，用户可以使用标准的SQL处理数据集。

继承关系图如下：从上面的继承关系中可以看出，都实现了RichFunction接口，所以支持使用open()close()等方法的调用。从名字上可以看出，这些函数都有不同的适用场景，但是基本的功能是类似的，下面会以KeyedProcessFunction为例来讨论这些函数的通用功能。本文首先介绍了Flink提供的几种底层Process Function API，这些API可以访问时间戳和水位线，同时支持注册一个计时器，进行调用回调函数onTimer()。

本文首先实现了自定义MySQL Source，然后基于MySql 的Source进行了一系列的算子操作，并对常见的算子操作进行详细剖析，最后实现了一个自定义MySQL Sink，并对RichFunction进行了解释。代码地址作者：大数据技术与数仓链接：https://juejin.cn/post/6857499033612845063来源：稀土掘金著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

/ 将tuple类型的数据写入关系型数据库// 创建并配置OutputFormat)").finish()复制代码。

本文主要介绍 Flink Runtime 的作业执行的核心机制。首先介绍 Flink Runtime 的整体架构以及 Job 的基本执行流程，然后介绍Flink 的Standalone运行架构，最后对Flink on YARN的两种模式进行了详细剖析。

摘要：数据接入与传输作为打通数据系统与业务系统的一道桥梁，是数据系统与架构中不可或缺的一个重要部分。数据传输系统稳定性和准确性，直接影响整个数据系统服务的 SLA 和质量。此外如何提升系统的易用性，保证监控服务并降低系统维护成本，优雅应对灾难等问题也十分重要。本文介绍了汽车之家实时计算团队利用 Flink 和 Flink 实时平台构建数据传输 SDK 和传输平台并不断完善的实践经验与总结。内容包括： 背景与需求 技术选型与设计 —— Why Flink? 数据传输系统的设计架构