摘要：
1、联合（Union） 最简单的合流操作，就是直接将多条流合在一起，叫作流的“联合”（union），如下图所示。联合操作要求必须流中的数据类型必须相同，合并之后的新流会包括所有流中的元素，数据类型不变。这种合流方式非常简单粗暴，就像公路上多个车道汇在一起一样 在代码中，只要基于DataStream直 阅读全文
摘要：
处理函数主要是定义数据流的转换操作，所以也可以把它归到转换算子中。在Flink中几乎所有转换算子都提供了对应的函数类接口，处理函数也不例外；它所对应的函数类，就叫作ProcessFunction。 1、处理函数的功能和使用 之前学习的转换算子，一般只是针对某种具体操作来定义的，能够拿到的信息比较有限 阅读全文
摘要：
有了事件时间、水位线和窗口的相关知识，现在就可以系统性地讨论一下怎样处理迟到数据了。所谓的“迟到数据”（late data），是指某个水位线之后到来的数据，它的时间戳其实是在水位线之前的。所以只有在事件时间语义下，讨论迟到数据的处理才是有意义的。事件时间里用来表示时钟进展的就是水位线（waterma 阅读全文
摘要：
增量聚合和全窗口函数的对比 已经了解了Window API中两类窗口函数的用法，下面先来做个简单的总结。增量聚合函数处理计算会更高效。举一个最简单的例子，对一组数据求和。大量的数据连续不断到来，全窗口函数只是把它们收集缓存起来，并没有处理；到了窗口要关闭、输出结果的时候，再遍历所有数据依次叠加，得到 阅读全文
摘要：
与增量聚合函数不同，全窗口函数需要先收集窗口中的数据，并在内部缓存起来，等到窗口要输出结果的时候再取出数据进行计算。很明显，这就是典型的批处理思路了——先攒数据，等一批都到齐了再正式启动处理流程。这样做毫无疑问是低效的：因为窗口全部的计算任务都积压在了要输出结果的那一瞬间，而在之前收集数据的漫长过程 阅读全文
摘要：
一般来说，Flink内置的水位线生成器就可以满足应用需求了。不过有时由于业务逻辑可能非常复杂，这时对水位线生成的逻辑也有更高的要求，开发人员就必须自定义实现水位线策略WatermarkStrategy了。在WatermarkStrategy中，时间戳分配器TimestampAssigner都是大同小 阅读全文
摘要：
实现 SourceFunction 大多数情况下，Flink自身支持的数据源已经能够满足需要。但是凡事总有例外，如果遇到特殊情况，想要读取的数据源来自某个外部系统，而flink既没有预实现的方法、也没有提供连接器，那就只好自定义实现SourceFunction了。接下来创建一个自定义的数据源，实现S 阅读全文
摘要：
定义了窗口分配器，只是知道了数据属于哪个窗口，可以将数据收集起来了；至于收集起来到底要做什么，其实还完全没有头绪。所以在窗口分配器之后，必须再接上一个定义窗口如何进行计算的操作，这就是所谓的“窗口函数”（window functions）。经窗口分配器处理之后，数据可以分配到对应的窗口中，而数据流经 阅读全文
摘要：
1、窗口API 1,1、按键分区（Keyed）和非按键分区（Non-Keyed） 在定义窗口操作之前，首先需要确定，到底是基于按键分区（Keyed）的数据流KeyedStream来开窗，还是直接在没有按键分区的DataStream上开窗。也就是说，在调用窗口算子之前，是否有keyBy操作。 按键分区 阅读全文
摘要：
Flink中事件时间和水位线是做基于时间的处理计算的基础。之前我们已经了解了Flink中基本的聚合操作。在流处理中，我们往往需要面对的是连续不断、无休无止的无界流，不可能等到所有所有数据都到齐了才开始处理。所以聚合计算其实只能针对当前已有的数据——之后再有数据到来，就需要继续叠加、再次输出结果。这样 阅读全文