打工日常

Idea中执行任务时，没法看到JobManager的错误，以至于我以为是什么特殊的原因导致任务总是反复消费。在close方法中，增加日志，发现jdbc连接被关闭了。重新消费，jdbc连接又启动了。注意，在Flink的函数中，open和close方法只在任务启动和结束的时候执行一次。反之，可以推理出，如果close方法被执行了，那么说明任务挂了。在本地任务中增加本地Flink UI，很明显可以看到任务在不断的重启。JobManager中有明显的Exception，就是。

union算子和getsideoutput算子，都不能自定义算子名字。

【代码】flink redis connector需要防止包冲突。

com.mysql.cj.jdbc.exceptions.CommunicationsException: The last packet successfully received from the server was 1,199,914 milliseconds ago. The last packet sent successfully to the server was 1,199,917 milliseconds ago. is longer than the server configure

Flink中大量采用JAVA语言编写，JAVA语言的好处就是不用考虑底层，JVM会对代码进行深度优化，并对内存资源进行管理，自动回收内存。而缺点也在这里，自动就意味着不可控。基于JVM的大数据引擎，在处理海量数据时，如何在内存中储存大量的数据？...

Flink1.11支持了Native Kubernetes Setup Beta，但这种模式只支持将用户自定义的jar包打到自定义的镜像中，这种模式下，来一个用户就要打一个镜像的方式不符合需求。而且这种模式支持的Flink Kubernetes Session。意思是什么呢？先看看官网提交的方式：$ ./bin/kubernetes-session.sh \ -Dkubernetes.cluster-id=<ClusterId> \ -Dtaskmanager.memory.proce

KeyedStream Transformations(键控流转换算子)keyby分流算子, 流的类型改变了DataStream → KeyedStream黑色去一条流，剩下的去另一条流// 以数据的id为key分流stream.keyBy(r => r.id)// 以case class的word字段为key分流stream.keyBy("word")// 以Tuple的第0个元素为key分流stream.keyBy(0)val input: DataStream[(Int

map顾名思义，就是转换，将流中进去的每一个元素转成另外一种元素。我们需要实现接口MapFunction// T: the type of input elements// O: the type of output elementsMapFunction[T, O]map(T): O比如：val sensorIds: DataStream[String] = readings.map(new MyMapFunction)class MyMapFunction extends Ma

EnvironmentgetExecutionEnvironment创建一个执行环境，表示当前执行程序的上下文。如果程序是独立调用的，则此方法返回本地执行环境；如果从命令行客户端调用程序以提交到集群，则此方法返回此集群的执行环境，也就是说，getExecutionEnvironment会根据查询运行的方式决定返回什么样的运行环境，是最常用的一种创建执行环境的方式。// 获取执行环境val env: StreamExecutionEnvironment = StreamExecutionEnviro.

我们知道大多数流应用程序都是有状态的。许多算子会不断地读取和更新状态，例如在窗口中收集的数据、读取输入源的位置，或者像机器学习模型那样的用户定制化的算子状态。 Flink用同样的方式处理所有的状态，无论是内置的还是用户自定义的算子。本节我们将会讨论Flink支持的不同类型的状态，并解释“状态后端”是如何存储和维护状态的。一般来说，由一个任务维护，并且用来计算某个结果的所有数据，都属于这个任务的状态。你可以认为状态就是一个本地变量，可以被任务的业务逻辑访问。下图显示了任务与其状态之间的交互。任务会接收一

一致的检查点（Checkpoints）Flink的恢复机制的核心，就是应用状态的一致检查点。有状态流应用的一致检查点，其实就是所有任务状态在某个时间点的一份拷贝，而这个时间点应该是所有任务都恰好处理完一个相同的输入数据的时候。这个过程可以通过一致检查点的一个简单算法步骤来解释。这个算法的步骤是：暂停所有输入流的摄取，也就是不再接收新数据的输入。等待所有正在处理的数据计算完毕，这意味着结束时，所有任务都已经处理了所有输入数据。通过将每个任务的状态复制到远程持久存储，来得到一个检查点。所有任务完成拷贝

Flink为常见的事件时间处理操作提供了直观且易于使用的原语，同时暴露了表达性很强的API，用户可以使用自定义算子实现更高级的事件时间应用程序。很好地理解Flink的内部时间处理，对于实现这样的高级应用程序会有很大帮助，有时也是必需的。上一章介绍了Flink利用两个概念来支持事件时间语义：记录时间戳（timestamps）和水位线（watermarks）。接下来，我们将描述Flink如何在内部实现并处理时间戳和水位线，进而支持具有事件时间语义的流式应用程序。时间戳（Timestamps）由Flink事件

Flink是一个用于有状态的并行数据流处理的分布式系统。它由多个进程构成，这些进程一般会分布运行在不同的机器上。对于分布式系统来说，面对的常见问题有：集群中资源的分配和管理、进程协调调度、持久化和高可用的数据存储，以及故障恢复。对于这些分布式系统的经典问题，业内已有比较成熟的解决方案和服务。所以Flink并不会自己去处理所有的问题，而是利用了现有的集群架构和服务，这样它就可以把精力集中在核心工作——分布式数据流处理上了。Flink与一些集群资源管理工具有很好的集成，比如Apache Mesos、YARN和

任务调度原理Client为提交Job的客户端，可以运行在任何机器上(与JobManager环境连通即可)。提交Job后，Client可以结束进程(Streaming的任务)，也可以不结束并等待结果返回。JobManager主要负责调度Job并协调Task做Checkpoint。从Client处接收到Job和JAR包等资源后，会生成优化后的执行计划，并以Task为单元调度到各个TaskManager去执行。TaskManager在启动的时候就设置好了槽位数(Slot)，每个Slot能启动一个Task，T

Maven搭建使用Flink官方提供的flink-quickstart-scala原型来创建我们的工程，因为Flink官方提供的pom.xml经过了精心配置，可以打包出很小的Jar包。依赖包下载完毕后，会出现BUILD SUCCESSquickstart/├── pom.xml└── src└── main├── resources│ └── log4j.properties└── scala└── org└── example└── quickstart├──

任务失败流任务中的运算符状态是很宝贵的，也需要抵御任务失败带来的问题。如果在任务失败的情况下，状态丢失的话，在任务恢复以后计算的结果将是不正确的。流任务会连续不断的运行很长时间，而状态可能已经收集了几天甚至几个月。在失败的情况下，重新处理所有的输入并重新生成一个丢失的状态，将会很浪费时间，开销也很大。在之前的文章中，我们们看到如何将流的编程建模成数据流模型。在执行之前，流程序将会被翻译成物理层数据流图，物理层数据流图由连接的并行任务组成，而一个并行任务运行一些运算符逻辑，消费输入流数据，并为其他任务产生

在这一章节中，我们将介绍时间语义，并介绍流中不同的时间概念。我们将介绍流处理器在乱序事件流的情况下如何提供准确的计算结果，以及如何处理历史事件流，如何在流中进行时间旅行。在流处理中一分钟代表什么？在处理可能是无限的事件流（包含了连续到达的事件）的时候，时间成为流处理程序的核心方面。假设我们想要连续的计算结果，可能每分钟就要计算一次。在我们的流处理程序上下文中，一分钟代表的是什么意思呢？假设一个程序需要分析一款移动端的在线游戏的用户所产生的事件流。游戏中的用户分了组，而应用程序将收集每个小组的活动数据，

数据摄取是操作从外部源获取原始数据并将其转换为其他格式(ETL)。实现数据提取逻辑的运算符被称为数据源。执行数据出口的运算符称为数据接收器，包括文件，数据库，消息队列和监控接口。转换算子转换算子是一次处理算子，碰到一个事件处理一个事件。转换一次会消费一个事件，在消费的过程中对事件数据做一些转换，产生一个新的输出流。转换逻辑可以集成在 操作符中或由UDF函数提供，如上图，这样程序员编写实现自定义计算逻辑。操作符可以接受多个输入流并产生多个输出流。他们还可以通过修改数据流图的结构要么将流分成多个流，要么

流处理技术在大大小小的公司中越来越受欢迎，因为它为许多已建立的用例（如数据分析，ETL和事务应用程序）提供了很好的解决方案，同时发展了很多新的应用程序和商机。那么，为什么有状态流处理变得如此受欢迎？我们首先回顾传统的数据应用程序架构并指出它们的局限性。接下来，我们介绍基于状态流处理的应用程序设计 与传统方法相比，它具有许多有趣的特征，最后，我们简要讨论开源流处理器的发展。传统数据处理架构数十年来，数据和数据处理在企业中无处不在。多年来，数据的收集和使用一直在增长，公司已经设计并构建了基础架构来管理数据。

事件驱动型(Event-Driven)事件驱动型应用是一类具有状态的应用，它从一个或多个事件流提取数据，并根据到来的事件触发计算、状态更新或其他外部动作。比较典型的就是以Kafka为代表的消息队列几乎都是事件驱动型应用。与之不同的就是Spark Streaming微批次，如图：流与批的世界观批处理的特点是有界、持久、大量，非常适合需要访问全套记录才能完成的计算工作，一般用于离线统计。流处理的特点是无界、实时，无需针对整个数据集执行操作，而是对通过系统传输的每个数据项执行操作，一般用于实时统计。

Spark Streaming vs Flink两者最重要的区别(流和微批)(1). Micro Batching 模式(spark)Micro-Batching计算模式认为"流是批的特例"，流计算就是将连续不断的微批进行持续计算，如果批足够小那么就有足够小的延时，在一定程度上满足了99%的实时计算场景。那么那1%为啥做不到呢? 这就是架构的魅力，在Micro-Batching模式的架构实现上就有一个自然流数据流入系统进行攒批的过程，这在一定程度上就增加了延时。具体如下示意图：从上面可以看到是把输

简介Flink起源于Stratosphere项目，Stratosphere是在2010～2014年由3所地处柏林的大学和欧洲的一些其他的大学共同进行的研究项目，2014年4月Stratosphere的代码被复制并捐赠给了Apache软件基金会，参加这个孵化项目的初始成员是Stratosphere系统的核心开发人员，2014年12月，Flink一跃成为Apache软件基金会的顶级项目。在德语中，Flink一词表示快速和灵巧，项目采用一只松鼠的彩色图案作为logo，这不仅是因为松鼠具有快速和灵巧的特点，还因

代码如下使用scala书写import org.apache.flink.streaming.api.TimeCharacteristicimport org.apache.flink.streaming.api.functions.ProcessFunctionimport org.apache.flink.streaming.api.scala._import org.apache....

keyBy后滚动聚合（Rolling Aggregation）报错：org.apache.flink.api.common.InvalidProgramException: Specifying keys via field positions is only valid for tuple data types. Type: GenericType报错图如下Exception in threa...