流式计算新贵Kafka Stream设计详解

2017 年 8 月 20 日 机器学习研究会
本文介绍了 Kafka Stream 的背景,如 Kafka Stream 是什么,什么是流式计算,以及为什么要有 Kafka Stream。接着介绍了 Kafka Stream 的整体架构、并行模型、状态存储以及主要的两种数据集 KStream 和 KTable。然后分析了 Kafka Stream 如何解决流式系统中的关键问题,如时间定义、窗口操作、Join 操作、聚合操作,以及如何处理乱序和提供容错能力。最后结合示例讲解了如何使用 Kafka Stream。
Kafka Stream 背景  
Kafka Stream 是什么  

Kafka Stream 是 Apache Kafka 从 0.10 版本引入的一个新 Feature。它提供了对存储于 Kafka 内的数据进行流式处理和分析的功能。

Kafka Stream 的特点如下:

  • Kafka Stream 提供了一个非常简单而轻量的 Library,它可以非常方便地嵌入任意 Java 应用中,也可以任意方式打包和部署

  • 除了 Kafka 外,无任何外部依赖

  • 充分利用 Kafka 分区机制实现水平扩展和顺序性保证

  • 通过可容错的 state store 实现高效的状态操作(如 windowed join 和 aggregation)

  • 支持正好一次处理语义

  • 提供记录级的处理能力,从而实现毫秒级的低延迟

  • 支持基于事件时间的窗口操作,并且可处理晚到的数据(late arrival of records)

  • 同时提供底层的处理原语 Processor(类似于 Storm 的 spout 和 bolt),以及高层抽象的 DSL(类似于 Spark 的 map/group/reduce)


什么是流式计算   


一般流式计算会与批量计算相比较。在流式计算模型中,输入是持续的,可以认为在时间上是无界的,也就意味着,永远拿不到全量数据去做计算。同时,计算结果是持续输出的,也即计算结果在时间上也是无界的。流式计算一般对实时性要求较高,同时一般是先定义目标计算,然后数据到来之后将计算逻辑应用于数据。同时为了提高计算效率,往往尽可能采用增量计算代替全量计算。

批量处理模型中,一般先有全量数据集,然后定义计算逻辑,并将计算应用于全量数据。特点是全量计算,并且计算结果一次性全量输出。



为什么要有 Kafka Stream   


当前已经有非常多的流式处理系统,最知名且应用最多的开源流式处理系统有 Spark Streaming 和 Apache Storm。Apache Storm 发展多年,应用广泛,提供记录级别的处理能力,当前也支持 SQL on Stream。而 Spark Streaming 基于 Apache Spark,可以非常方便与图计算,SQL 处理等集成,功能强大,对于熟悉其它 Spark 应用开发的用户而言使用门槛低。另外,目前主流的 Hadoop 发行版,如 MapR,Cloudera 和 Hortonworks,都集成了 Apache Storm 和 Apache Spark,使得部署更容易。

既然 Apache Spark 与 Apache Storm 拥用如此多的优势,那为何还需要 Kafka Stream 呢?笔者认为主要有如下原因。

第一,Spark 和 Storm 都是流式处理框架,而 Kafka Stream 提供的是一个基于 Kafka 的流式处理类库。框架要求开发者按照特定的方式去开发逻辑部分,供框架调用。开发者很难了解框架的具体运行方式,从而使得调试成本高,并且使用受限。而 Kafka Stream 作为流式处理类库,直接提供具体的类给开发者调用,整个应用的运行方式主要由开发者控制,方便使用和调试。

第二,虽然 Cloudera 与 Hortonworks 方便了 Storm 和 Spark 的部署,但是这些框架的部署仍然相对复杂。而 Kafka Stream 作为类库,可以非常方便的嵌入应用程序中,它对应用的打包和部署基本没有任何要求。更为重要的是,Kafka Stream 充分利用了 Kafka 的分区机制和 Consumer 的 Rebalance 机制,使得 Kafka Stream 可以非常方便的水平扩展,并且各个实例可以使用不同的部署方式。

具体来说,每个运行 Kafka Stream 的应用程序实例都包含了 Kafka Consumer 实例,多个同一应用的实例之间并行处理数据集。而不同实例之间的部署方式并不要求一致,比如部分实例可以运行在 Web 容器中,部分实例可运行在 Docker 或 Kubernetes 中。

第三,就流式处理系统而言,基本都支持 Kafka 作为数据源。例如 Storm 具有专门的 kafka-spout,而 Spark 也提供专门的 spark-streaming-kafka 模块。事实上,Kafka 基本上是主流的流式处理系统的标准数据源。换言之,大部分流式系统中都已部署了 Kafka,此时使用 Kafka Stream 的成本非常低。

第四,使用 Storm 或 Spark Streaming 时,需要为框架本身的进程预留资源,如 Storm 的 supervisor 和 Spark on YARN 的 node manager。即使对于应用实例而言,框架本身也会占用部分资源,如 Spark Streaming 需要为 shuffle 和 storage 预留内存。

第五,由于 Kafka 本身提供数据持久化,因此 Kafka Stream 提供滚动部署和滚动升级以及重新计算的能力。

第六,由于 Kafka Consumer Rebalance 机制,Kafka Stream 可以在线动态调整并行度。


Kafka Stream 架构  




Kafka Stream 整体架构  


Kafka Stream 的整体架构图如下。

目前(Kafka 0.11.0.0)Kafka Stream 的数据源只能如上图所示是 Kafka。但是处理结果并不一定要如上图所示输出到 Kafka。实际上 KStream 和 Ktable 的实例化都需要指定 Topic。

KStream<String, String> stream = builder.stream("words-stream");

KTable<String, String> table = builder.table("words-table", "words-store");

另外,上图中的 Consumer 和 Producer 并不需要开发者在应用中显示实例化,而是由 Kafka Stream 根据参数隐式实例化和管理,从而降低了使用门槛。开发者只需要专注于开发核心业务逻辑,也即上图中 Task 内的部分。


Processor Topology   


基于 Kafka Stream 的流式应用的业务逻辑全部通过一个被称为 Processor Topology 的地方执行。它与 Storm 的 Topology 和 Spark 的 DAG 类似,都定义了数据在各个处理单元(在 Kafka Stream 中被称作 Processor)间的流动方式,或者说定义了数据的处理逻辑。

下面是一个 Processor 的示例,它实现了 Word Count 功能,并且每秒输出一次结果。


转自:大数据杂谈

登录查看更多
0

相关内容

Kafka是一种高吞吐量的分布式发布订阅消息系统,它可以处理消费者规模的网站中的所有动作流数据。 这种动作(网页浏览,搜索和其他用户的行动)是在现代网络上的许多社会功能的一个关键因素。 这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。 对于像Hadoop的一样的日志数据和离线分析系统,但又要求实时处理的限制,这是一个可行的解决方案。Kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理,也是为了通过集群来提供实时的消费。
【实用书】流数据处理,Streaming Data,219页pdf
专知会员服务
77+阅读 · 2020年4月24日
【2020新书】Kafka实战:Kafka in Action,209页pdf
专知会员服务
68+阅读 · 2020年3月9日
【Google】利用AUTOML实现加速感知神经网络设计
专知会员服务
30+阅读 · 2020年3月5日
Transformer文本分类代码
专知会员服务
117+阅读 · 2020年2月3日
【干货】大数据入门指南:Hadoop、Hive、Spark、 Storm等
专知会员服务
96+阅读 · 2019年12月4日
在K8S上运行Kafka合适吗?会遇到哪些陷阱?
DBAplus社群
9+阅读 · 2019年9月4日
详解 | 推荐系统的工程实现
AI100
42+阅读 · 2019年3月15日
OLAP引擎这么多,为什么苏宁选择用Druid?
51CTO博客
12+阅读 · 2018年12月20日
Flink 靠什么征服饿了么工程师?
阿里技术
6+阅读 · 2018年8月13日
SLA 99.99%以上!饿了么实时计算平台3年演进历程
51CTO博客
11+阅读 · 2018年4月10日
基于 Storm 的实时数据处理方案
开源中国
4+阅读 · 2018年3月15日
【智能商务】海量商品查找利器—苏宁搜索系统
产业智能官
5+阅读 · 2017年12月1日
Spark的误解-不仅Spark是内存计算,Hadoop也是内存计算
Arxiv
3+阅读 · 2018年3月21日
Arxiv
3+阅读 · 2018年3月2日
Arxiv
23+阅读 · 2017年3月9日
VIP会员
相关资讯
在K8S上运行Kafka合适吗?会遇到哪些陷阱?
DBAplus社群
9+阅读 · 2019年9月4日
详解 | 推荐系统的工程实现
AI100
42+阅读 · 2019年3月15日
OLAP引擎这么多,为什么苏宁选择用Druid?
51CTO博客
12+阅读 · 2018年12月20日
Flink 靠什么征服饿了么工程师?
阿里技术
6+阅读 · 2018年8月13日
SLA 99.99%以上!饿了么实时计算平台3年演进历程
51CTO博客
11+阅读 · 2018年4月10日
基于 Storm 的实时数据处理方案
开源中国
4+阅读 · 2018年3月15日
【智能商务】海量商品查找利器—苏宁搜索系统
产业智能官
5+阅读 · 2017年12月1日
Spark的误解-不仅Spark是内存计算,Hadoop也是内存计算
Top
微信扫码咨询专知VIP会员