网站开发跟app开发的差别,咸阳网站制作公司,flash网站模板源码,最好看的2018中文在线观看40 Kafka Streams与其他流处理平台的差异在哪里#xff1f;
什么是流处理平台#xff1f;
“Streaming Systems”一书是这么定义“流处理平台”的#xff1a;流处理平台#xff08;Streaming System#xff09;是处理无限数据集#xff08;Unbounded Dataset#xff09;…40 Kafka Streams与其他流处理平台的差异在哪里
什么是流处理平台
“Streaming Systems”一书是这么定义“流处理平台”的流处理平台Streaming System是处理无限数据集Unbounded Dataset的数据处理引擎而流处理是与批处理Batch Processing相对应的。
所谓的无限数据是指数据永远没有尽头。流处理平台是专门处理这种数据集的系统或框架。当然这并不是说批处理系统不能处理这种无限数据集只是通常情况下它更擅长处理有限数据集Bounded Dataset。
那流处理和批处理究竟该如何区分呢下面这张图应该能帮助你快速且直观地理解它们的区别。现在我来详细解释一下流处理和批处理的区别。
长期以来流处理给人的印象通常是低延时但是结果不准确。每来一条消息它就能计算一次结果但由于它处理的大多是无界数据可能永远也不会结束因此在流处理中我们很难精确描述结果何时是精确的。理论上流处理的计算结果会不断地逼近精确结果。
但是它的竞争对手批处理则正好相反。批处理能提供准确的计算结果但往往延时很高。
因此业界的大神们扬长避短将两者结合在一起使用。一方面利用流处理快速地给出不那么精确的结果另一方面依托于批处理最终实现数据一致性。这就是所谓的Lambda架构。
延时低是个很好的特性但如果计算结果不准确流处理是无法完全替代批处理的。所谓计算结果准确在教科书或文献中有个专属的名字叫正确性Correctness。可以这么说目前难以实现正确性是流处理取代批处理的最大障碍而实现正确性的基石是精确一次处理语义Exactly Once SemanticsEOS。
这里的精确一次是流处理平台能提供的一类一致性保障。常见的一致性保障有三类
至多一次At most once语义消息或事件对应用状态的影响最多只有一次。至少一次At least once语义消息或事件对应用状态的影响最少一次。精确一次Exactly once语义消息或事件对应用状态的影响有且只有一次。
注意我这里说的都是对应用状态的影响。对于很多有副作用Side Effect的操作而言实现精确一次语义几乎是不可能的。举个例子假设流处理中的某个步骤是发送邮件操作当邮件发送出去后倘若后面出现问题要回滚整个流处理流程已发送的邮件是没法追回的这就是所谓的副作用。当你的流处理逻辑中存在包含副作用的操作算子时该操作算子的执行是无法保证精确一次处理的。因此我们通常只是保证这类操作对应用状态的影响精确一次罢了。后面我们会重点讨论Kafka Streams是如何实现EOS的。
我们今天讨论的流处理既包含真正的实时流处理也包含微批化Microbatch的流处理。所谓的微批化其实就是重复地执行批处理引擎来实现对无限数据集的处理。典型的微批化实现平台就是Spark Streaming。
Kafka Streams的特色
相比于其他流处理平台Kafka Streams最大的特色就是它不是一个平台至少它不是一个具备完整功能的平台比如其他框架中自带的调度器和资源管理器就是Kafka Streams不提供的。
Kafka官网明确定义Kafka Streams是一个Java客户端库。你可以使用这个库来构建高伸缩性、高弹性、高容错性的分布式应用以及微服务。
使用Kafka Streams API构建的应用就是一个普通的Java应用程序。你可以选择任何熟悉的技术或框架对其进行编译、打包、部署和上线。
在我看来这是Kafka Streams与Storm、Spark Streaming或Flink最大的区别。
Java客户端库的定位既可以说是特色也可以说是一个缺陷。目前Kafka Streams在国内推广缓慢的一个重要原因也在于此。毕竟很多公司希望它是一个功能完备的平台既能提供流处理应用API也能提供集群资源管理域调度方面的能力。所以这个定位到底是特色还是缺陷仁者见仁、智者见智吧。
Kafka Streams与其他框架的差异
接下来我从应用部署、上下游数据源、协调方式和消息语义保障4个方面详细分析一下Kafka Streams与其他框架的差异。
应用部署
首先我们从流处理应用部署方式上对Kafka Streams及其他框架进行区分。
我们刚刚提到过Kafka Streams应用需要开发人员自行打包和部署你甚至可以将Kafka Streams应用嵌入到其他Java应用中。因此作为开发者的你除了要开发代码之外还要自行管理Kafka Streams应用的生命周期要么将其打包成独立的jar包单独运行要么将流处理逻辑嵌入到微服务中开放给其他服务调用。
但不论是哪种部署方式你需要自己处理不要指望Kafka Streams帮你做这些事情。
相反地其他流处理平台则提供了完整的部署方案。我以Apache Flink为例来解释一下。在Flink中流处理应用会被建模成单个的流处理计算逻辑并封装进Flink的作业中。类似地Spark中也有作业的概念而在Storm中则叫拓扑。作业的生命周期由框架来管理特别是在Flink中Flink框架自行负责管理作业包括作业的部署和更新等。这些都无需应用开发人员干预。
另外Flink这类框架都存在资源管理器的角色。一个作业所需的资源完全由框架层的资源管理器来支持。常见的资源管理器如YARN、Kubernetes、Mesos等比较新的流处理框架如Spark、Flink等都是支持的。像Spark和Flink这样的框架也支持Standalone集群的方式即不借助于任何已有的资源管理器完全由集群自己来管理资源。这些都是Kafka Streams无法提供的。
因此从应用部署方面来看Kafka Streams更倾向于将部署交给开发人员来做而不是依赖于框架自己实现。
上下游数据源
简单来说Kafka Streams目前只支持从Kafka读数据以及向Kafka写数据。在没有Kafka Connect组件的支持下Kafka Streams只能读取Kafka集群上的主题数据在完成流处理逻辑后也只能将结果写回到Kafka主题上。
反观Spark Streaming和Flink这类框架它们都集成了丰富的上下游数据源连接器Connector比如常见的连接器MySQL、ElasticSearch、HBase、HDFS、Kafka等。如果使用这些框架你可以很方便地集成这些外部框架无需二次开发。
当然由于开发Connector通常需要同时掌握流处理框架和外部框架因此在实际使用过程中Connector的质量参差不齐在具体使用的时候你可以多查查对应的jira官网看看有没有明显的“坑”然后再决定是否使用。
在这个方面我是有前车之鉴的。曾经我使用过一个Connector我发现它在读取Kafka消息向其他系统写入的时候似乎总是重复消费。费了很多周折之后我才发现这是一个已知的Bug而且早就被记录在jira官网上了。因此我推荐你多逛下jira也许能提前避开一些“坑”。
总之目前Kafka Streams只支持与Kafka集群进行交互它没有提供开箱即用的外部数据源连接器。
协调方式
在分布式协调方面Kafka Streams应用依赖于Kafka集群提供的协调功能来提供高容错性和高伸缩性。
Kafka Streams应用底层使用了消费者组机制来实现任意的流处理扩缩容。应用的每个实例或节点本质上都是相同消费者组下的独立消费者彼此互不影响。它们之间的协调工作由Kafka集群Broker上对应的协调者组件来完成。当有实例增加或退出时协调者自动感知并重新分配负载。
我画了一张图来展示每个Kafka Streams实例内部的构造从这张图中我们可以看出每个实例都由一个消费者实例、特定的流处理逻辑以及一个生产者实例组成而这些实例中的消费者实例共同构成了一个消费者组。通过这个机制Kafka Streams应用同时实现了高伸缩性和高容错性而这一切都是自动提供的不需要你手动实现。
而像Flink这样的框架它的容错性和扩展性是通过专属的主节点Master Node全局来协调控制的。
Flink支持通过ZooKeeper实现主节点的高可用性避免单点失效某个节点出现故障会自动触发恢复操作。这种全局性协调模型对于流处理中的作业而言非常实用但不太适配单独的流处理应用程序。原因就在于它不像Kafka Streams那样轻量级应用程序必须要实现特定的API来开启检查点机制checkpointing同时还需要亲身参与到错误恢复的过程中。
应该这样说在不同的场景下Kafka Streams和Flink这种重量级的协调模型各有优劣。
消息语义保障精确一次处理语义Exactly Once SemanticsEOS我们刚刚提到过EOS目前很多流处理框架都宣称它们实现了EOS也包括Kafka Streams本身。关于精确一次处理语义有一些地方需要澄清一下。
实际上当把Spark、Flink与Kafka结合使用时如果不使用Kafka在0.11.0.0版本引入的幂等性Producer和事务型Producer这些框架是无法实现端到端的EOS的。
因为这些框架与Kafka是相互独立的彼此之间没有任何语义保障机制。但如果使用了事务机制情况就不同了。这些外部系统利用Kafka的事务机制保障了消息从Kafka读取到计算再到写入Kafka的全流程EOS。这就是所谓的端到端精确一次处理语义。
之前Spark和Flink宣称的EOS都是在各自的框架内实现的无法实现端到端的EOS。只有使用了Kafka的事务机制它们对应的Connector才有可能支持端到端精确一次处理语义。
Spark官网上明确指出了用户若要实现与Kafka的EOS必须自己确保幂等输出和位移保存在同一个事务中。如果你不能自己实现这套机制那么就要依赖于Kafka提供的事务机制来保证。
而Flink在Kafka 0.11之前也宣称提供EOS不过是有前提条件的即每条消息对Flink应用状态的影响有且只有一次。
举个例子如果你使用Flink从Kafka读取消息然后不加任何处理直接写入到MySQL那么这个操作就是无状态的此时Flink无法保证端到端的EOS。
换句话说Flink最后写入到MySQL的Kafka消息可能有重复的。当然Flink社区自1.4版本起正式实现了端到端的EOS其基本设计思想正是基于Kafka 0.11幂等性Producer的两阶段提交机制。
两阶段提交2PC机制是一种分布式事务机制用于实现分布式系统上跨多个节点事务的原子性提交。下面这张图来自于神书“Designing Data-Intensive Applications”中关于2PC讲解的章节。它清晰地描述了一次成功2PC的过程。在这张图中两个数据库参与到分布式事务的提交过程中它们各自做了一些变更现在需要使用2PC来保证两个数据库的变更被原子性地提交。如图所示2PC被分为两个阶段Prepare阶段和Commit阶段。只有完整地执行了这两个阶段这个分布式事务才算是提交成功。分布式系统中的2PC常见于数据库内部实现或以XA事务的方式供各种异质系统使用。Kafka也借鉴了2PC的思想在Kafka内部实现了基于2PC的事务机制。
但是对于Kafka Streams而言情况就不同了。它天然支持端到端的EOS因为它本来就是和Kafka紧密相连的。
下图展示了一个典型的Kafka Streams应用的执行逻辑。通常情况下一个Kafka Streams需要执行5个步骤
读取最新处理的消息位移读取消息数据执行处理逻辑将处理结果写回到Kafka保存位置信息。
这五步的执行必须是原子性的否则无法实现精确一次处理语义。
在设计上Kafka Streams在底层大量使用Kafka事务机制和幂等性Producer来实现多分区的原子性写入又因为它只能读写Kafka因此Kafka Streams很容易地就实现了端到端的EOS。
总之虽然Flink自1.4版本也提供与Kafka的EOS但从适配性来考量的话应该说Kafka Streams与Kafka的适配性是最好的。
41 Kafka Streams DSL开发实例
DSL也就是Domain Specific Language意思是领域特定语言。它提供了一组便捷的API帮助我们实现流式数据处理逻辑。今天我就来分享一些Kafka Streams中的DSL开发方法以及具体实例。
Kafka Streams背景介绍
流处理平台是专门处理无限数据集的引擎。就Kafka Streams而言它仅仅是一个客户端库。所谓的Kafka Streams应用就是调用了Streams API的普通Java应用程序。只不过在Kafka Streams中流处理逻辑是用拓扑来表征的。
一个拓扑结构本质上是一个有向无环图DAG它由多个处理节点Node和连接节点的多条边组成如下图所示图中的节点也称为处理单元或Processor它封装了具体的事件处理逻辑。Processor在其他流处理平台也被称为操作算子。常见的操作算子包括转换map、过滤filter、连接join和聚合aggregation等。后面我会详细介绍几种常见的操作算子。
大体上Kafka Streams开放了两大类API供你定义Processor逻辑。
第1类就是我刚刚提到的DSL它是声明式的函数式API使用起来感觉和SQL类似你不用操心它的底层是怎么实现的你只需要调用特定的API告诉Kafka Streams你要做什么即可。
举个简单的例子你可以看看下面这段代码尝试理解下它是做什么的。
movies.filter((title, movie) - movie.getGenre().equals(动作片)).xxx()...这段代码虽然用了Java 8的Lambda表达式但从整体上来看它要做的事情应该还是很清晰的它要从所有Movie事件中过滤出影片类型是“动作片”的事件。这就是DSL声明式API的实现方式。
第2类则是命令式的低阶API称为Processor API。比起DSL这组API提供的实现方式更加灵活。你可以编写自定义的算子来实现一些DSL天然没有提供的处理逻辑。事实上DSL底层也是用Processor API实现的。
目前Kafka Streams DSL提供的API已经很丰富了基本上能够满足我们大部分的处理逻辑需求我今天重点介绍一下DSL的使用方法。
不论是用哪组API实现所有流处理应用本质上都可以分为两类有状态的Stateful应用和无状态的Stateless应用。
有状态的应用指的是应用中使用了类似于连接、聚合或时间窗口Window的API。一旦调用了这些API你的应用就变为有状态的了也就是说你需要让Kafka Streams帮你保存应用的状态。
无状态的应用是指在这类应用中某条消息的处理结果不会影响或依赖其他消息的处理。常见的无状态操作包括事件转换以及刚刚那个例子中的过滤等。
关键概念
了解了这些背景之后你还需要掌握一些流处理领域内的关键概念即流、表以及流表二元性还有时间和时间窗口。
流表二元性
流就是一个永不停止至少理论上是这样的的事件序列而表和关系型数据库中的概念类似是一组行记录。在流处理领域两者是有机统一的流在时间维度上聚合之后形成表表在时间维度上不断更新形成流这就是所谓的流表二元性。流表二元性在流处理领域内的应用是Kafka框架赖以成功的重要原因之一。
下面这张图展示了表转换成流流再转换成表的全过程。刚开始时表中只有一条记录“张三1”。将该条记录转成流变成了一条事件。接着表增加了新记录“李四1”。针对这个变更流中也增加了对应的新事件。之后表中张三的对应值从1更新为2流也增加了相应的更新事件。最后表中添加了新数据“王五1”流也增加了新记录。至此表转换成流的工作就完成了。
从这个过程中我们可以看出流可以看作是表的变更事件日志Changelog。与之相反的是流转换成表的过程可以说是这个过程的逆过程我们为流中的每条事件打一个快照Snapshot就形成了表。
流和表的概念在流处理领域非常关键。在Kafka Streams DSL中流用KStream表示而表用KTable表示。
Kafka Streams还定义了GlobalKTable。本质上它和KTable都表征了一个表里面封装了事件变更流但是它和KTable的最大不同在于当Streams应用程序读取Kafka主题数据到GlobalKTable时它会读取主题所有分区的数据而对KTable而言Streams程序实例只会读取部分分区的数据这主要取决于Streams实例的数量。
时间
在流处理领域内精确定义事件时间是非常关键的一方面它是决定流处理应用能否实现正确性的前提另一方面流处理中时间窗口等操作依赖于时间概念才能正常工作。
常见的时间概念有两类事件发生时间Event Time和事件处理时间Processing Time。理想情况下我们希望这两个时间相等即事件一旦发生就马上被处理但在实际场景中这是不可能的Processing Time永远滞后于Event Time而且滞后程度又是一个高度变化无法预知就像“Streaming Systems”一书中的这张图片所展示的那样该图中的45°虚线刻画的是理想状态即Event Time等于Processing Time而粉色的曲线表征的是真实情况即Processing Time落后于Event Time而且落后的程度Lag不断变化毫无规律。
如果流处理应用要实现结果的正确性就必须要使用基于Event Time的时间窗口而不能使用基于Processing Time的时间窗口。
时间窗口
所谓的时间窗口机制就是将流数据沿着时间线切分的过程。常见的时间窗口包括固定时间窗口Fixed Windows、滑动时间窗口Sliding Windows和会话窗口Session Windows。Kafka Streams同时支持这三类时间窗口。在后面的例子中我会详细介绍如何使用Kafka Streams API实现时间窗口功能。
运行WordCount实例
关于Kafka Streams及其DSL的基本概念我都阐述完了下面我给出大数据处理领域的Hello World实例WordCount程序。
每个大数据处理框架第一个要实现的程序基本上都是单词计数。我们来看下Kafka Streams DSL如何实现WordCount。我先给出完整代码稍后我会详细介绍关键部分代码的含义以及运行它的方法。
package kafkalearn.demo.wordcount;import org.apache.kafka.clients.consumer.ConsumerConfig;
import org.apache.kafka.common.serialization.Serdes;
import org.apache.kafka.streams.KafkaStreams;
import org.apache.kafka.streams.StreamsBuilder;
import org.apache.kafka.streams.StreamsConfig;
import org.apache.kafka.streams.kstream.KStream;
import org.apache.kafka.streams.kstream.KTable;
import org.apache.kafka.streams.kstream.Produced;import java.util.Arrays;
import java.util.Locale;
import java.util.Properties;
import java.util.concurrent.CountDownLatch;public final class WordCountDemo {public static void main(final String[] args) {final Properties props new Properties();props.put(StreamsConfig.APPLICATION_ID_CONFIG, wordcount-stream-demo);props.put(StreamsConfig.BOOTSTRAP_SERVERS_CONFIG, localhost:9092);props.put(StreamsConfig.DEFAULT_KEY_SERDE_CLASS_CONFIG, Serdes.String().getClass().getName());props.put(StreamsConfig.DEFAULT_VALUE_SERDE_CLASS_CONFIG, Serdes.String().getClass().getName());props.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, earliest);final StreamsBuilder builder new StreamsBuilder();final KStreamString, String source builder.stream(wordcount-input-topic);final KTableString, Long counts source.flatMapValues(value - Arrays.asList(value.toLowerCase(Locale.getDefault()).split( ))).groupBy((key, value) - value).count();counts.toStream().to(wordcount-output-topic, Produced.with(Serdes.String(), Serdes.Long()));final KafkaStreams streams new KafkaStreams(builder.build(), props);final CountDownLatch latch new CountDownLatch(1);Runtime.getRuntime().addShutdownHook(new Thread(wordcount-stream-demo-jvm-hook) {Overridepublic void run() {streams.close();latch.countDown();}});try {streams.start();latch.await();} catch (final Throwable e) {System.exit(1);}System.exit(0)}
}在程序开头我构造了一个Properties对象实例对Kafka Streams程序的关键参数进行了赋值比如application id、bootstrap servers和默认的KV序列化器Serializer和反序列化器Deserializer。其中application id是Kafka Streams应用的唯一标识必须要显式地指定。默认的KV序列化器、反序列化器是为消息的Key和Value进行序列化和反序列化操作的。
接着我构造了一个StreamsBuilder对象并使用该对象实例创建了一个KStream这个KStream从名为wordcount-input-topic的Kafka主题读取消息。该主题消息由一组单词组成单词间用空格分割比如zhangsan lisi wangwu。
由于我们要进行单词计数所以就需要将消息中的单词提取出来。有了前面的概念介绍你应该可以猜到KTable是很合适的存储结构因此下一步就是将刚才的这个KStream转换成KTable。
我们先对单词进行分割这里我用到了flatMapValues方法代码中的Lambda表达式实现了从消息中提取单词的逻辑。由于String.split()方法会返回多个单词因此我们使用flatMapValues而不是mapValues。原因是前者能够将多个元素“打散”成一组单词而如果使用后者我们得到的就不是一组单词而是多组单词了。
这些都做完之后程序调用groupBy方法对单词进行分组。由于是计数相同的单词必须被分到一起然后就是调用count方法对每个出现的单词进行统计计数并保存在名为counts的KTable对象中。
最后我们将统计结果写回到Kafka中。由于KTable是表是静态的数据因此这里要先将其转换成KStream然后再调用to方法写入到名为wordcount-output-topic的主题中。此时counts中事件的Key是单词而Value是统计个数因此我们在调用to方法时同时指定了Key和Value的序列化器分别是字符串序列化器和长整型序列化器。
至此Kafka Streams的流计算逻辑就编写完了接下来就是构造KafkaStreams实例并启动它了。通常来说这部分的代码都是类似的即调用start方法启动整个流处理应用以及配置一个JVM关闭钩子Shutdown Hook实现流处理应用的关闭等。
总体来说Kafka Streams DSL实现WordCount的方式还是很简单的仅仅调用几个操作算子就轻松地实现了分布式的单词计数实时处理功能。事实上现在主流的实时流处理框架越来越倾向于这样的设计思路即通过提供丰富而便捷的开箱即用操作算子简化用户的开发成本采用类似于搭积木的方式快捷地构建实时计算应用。
待启动该Java程序之后你需要创建出对应的输入和输出主题并向输入主题不断地写入符合刚才所说的格式的单词行之后你需要运行下面的命令去查看输出主题中是否正确地统计了你刚才输入的单词个数
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 \--topic wordcount-output-topic \--from-beginning \--formatter kafka.tools.DefaultMessageFormatter \--property print.keytrue \--property print.valuetrue \--property key.deserializerorg.apache.kafka.common.serialization.StringDeserializer \--property value.deserializerorg.apache.kafka.common.serialization.LongDeserializer开发API
介绍了具体的例子之后我们来看下Kafka Streams还提供了哪些功能强大的API。我们可以重点关注两个方面一个是常见的操作算子另一个是时间窗口API。
常见操作算子
操作算子的丰富程度和易用性是衡量流处理框架受欢迎程度的重要依据之一。Kafka Streams DSL提供了很多开箱即用的操作算子大体上分为两大类无状态算子和有状态算子。下面我就向你分别介绍几个经常使用的算子。
在无状态算子中filter的出场率是极高的。它执行的就是过滤的逻辑。依然拿WordCount为例假设我们只想统计那些以字母s开头的单词的个数我们可以在执行完flatMapValues后增加一行代码代码如下
.filter(((key, value) - value.startsWith(s)))另一个常见的无状态算子当属map一族了。Streams DSL提供了很多变体比如map、mapValues、flatMap和flatMapValues。我们已经见识了flatMapValues的威力其他三个的功能也是类似的只是所有带Values的变体都只对消息体执行转换不触及消息的Key而不带Values的变体则能修改消息的Key。
举个例子假设当前消息没有Key而Value是单词本身现在我们想要将消息变更成这样的KV对即Key是单词小写而Value是单词长度那么我们可以调用map方法代码如下
KStreamString, Integer transformed stream.map((key, value) - KeyValue.pair(value.toLowerCase(), value.length()));最后我再介绍一组调试用的无状态算子print和peek。Streams DSL支持你使用这两个方法查看你的消息流中的事件。这两者的区别在于print是终止操作一旦你调用了print方法后面就不能再调用任何其他方法了而peek则允许你在查看消息流的同时依然能够继续对其进行处理比如下面这两段代码所示
stream.print(Printed.toFile(streams.out).withLabel(debug));
stream.peek((key, value) - System.out.println(key key , value value)).map(...);常见的有状态操作算子主要涉及聚合Aggregation方面的操作比如计数、求和、求平均值、求最大最小值等。Streams DSL目前只提供了count方法用于计数其他的聚合操作需要你自行使用API实现。
假设我们有个消息流每条事件就是一个单独的整数现在我们想要对其中的偶数进行求和那么Streams DSL中的实现方法如下
final KTableInteger, Integer sumOfEvenNumbers input.filter((k, v) - v % 2 0).selectKey((k, v) - 1).groupByKey().reduce((v1, v2) - v1 v2);我简单解释一下selectKey调用。由于我们要对所有事件中的偶数进行求和因此需要把这些消息的Key都调整成相同的值因此这里我使用selectKey指定了一个Dummy Key值即上面这段代码中的数值1。它没有任何含义仅仅是让所有消息都赋值上这个Key而已。真正核心的代码在于reduce调用它是执行求和的关键逻辑。
时间窗口实例
前面说过Streams DSL支持3类时间窗口。前两类窗口通过TimeWindows.of方法来实现会话窗口通过SessionWindows.with来实现。
假设在刚才的WordCount实例中我们想每一分钟统计一次单词计数那么需要在调用count之前增加下面这行代码
.windowedBy(TimeWindows.of(Duration.ofMinutes(1)))同时你还需要修改counts的类型此时它不再是KTable了而变成了KTable因为引入了时间窗口所以事件的Key也必须要携带时间窗口的信息。除了这两点变化WordCount其他部分代码都不需要修改。
可见Streams DSL在API封装性方面还是做得很好的通常你只需要增加或删减几行代码就能实现处理逻辑的修改了。
小结
流表二元性流就是一个永不停止至少理论上是这样的)的事件序列而表是一组行记录。流在时间维度上聚合之后形成表表在时间维度上不断更新形成流。时间概念常见的有两类分别是事件发生时间和事件处理时间。在实际场景中事件处理时间永远滞后于事件发生时间。时间窗口机制将流数据沿着时间线切分的过程常见的时间窗口包括固定时间窗口、滑动时间窗口和会话窗口。常见操作算子无状态算子中的filter、map一族、print和peek有状态算子中涉及聚合方面的操作。
