Kafka Streams与其余流处理平台的差别在哪里？
本文已收录GitHub，更有互联网大厂面试真题，面试攻略，高效学习资料等git
近些年来，开源流处理领域涌现出了不少优秀框架。光是在 Apache 基金会孵化的项目，关于流处理的大数据框架就有十几个之多，好比早期的 Apache Samza、ApacheStorm，以及这两年火爆的 Spark 以及 Flink 等。github
应该说，每一个框架都有本身独特的地方，也都有本身的缺陷。面对这众多的流处理框架，咱们应该如何选择呢？在本文汇总，我就来梳理几个主流的流处理平台，并重点分析一下 KafkaStreams 与其余流处理平台的差别。面试
什么是流处理平台？
首先，咱们有必要了解一下流处理平台的概念。“Streaming Systems”一书是这么定义“流处理平台”的：流处理平台（Streaming System）是处理无限数据集（Unbounded Dataset）的数据处理引擎，而流处理是与批处理（Batch Processing）相对应的。数据库
所谓的无限数据，是指数据永远没有尽头。流处理平台是专门处理这种数据集的系统或框架。固然，这并非说批处理系统不能处理这种无限数据集，只是一般状况下，它更擅长处理有限数据集（Bounded Dataset）。架构
那流处理和批处理究竟该如何区分呢？下面这张图应该能帮助你快速且直观地理解它们的区别。框架
好了，如今我来详细解释一下流处理和批处理的区别。分布式
长期以来，流处理给人的印象一般是低延时，可是结果不许确。每来一条消息，它就能计算一次结果，但因为它处理的大可能是***数据，可能永远也不会结束，所以在流处理中，咱们很难精确描述结果什么时候是精确的。理论上，流处理的计算结果会不断地逼近精确结果。ide
可是，它的竞争对手批处理则正好相反。批处理能提供准确的计算结果，但每每延时很高。微服务
所以，业界的大神们扬长避短，将二者结合在一块儿使用。一方面，利用流处理快速地给出不那么精确的结果；另外一方面，依托于批处理，最终实现数据一致性。这就是所谓的Lambda 架构。学习
延时低是个很好的特性，但若是计算结果不许确，流处理是没法彻底替代批处理的。所谓计算结果准确，在教科书或文献中有个专属的名字，叫正确性（Correctness）。能够这么说，目前难以实现正确性是流处理取代批处理的最大障碍，而实现正确性的基石是精确一次处理语义（Exactly Once Semantics，EOS）。
这里的精确一次是流处理平台能提供的一类一致性保障。常见的一致性保障有三类：
- 至多一次（At most once）语义：消息或事件对应用状态的影响最多只有一次。
- 至少一次（At least once）语义：消息或事件对应用状态的影响最少一次。
- 精确一次（Exactly once）语义：消息或事件对应用状态的影响有且只有一次。
注意，我这里说的都是对应用状态的影响。对于不少有反作用（Side Effect）的操做而言，实现精确一次语义几乎是不可能的。举个例子，假设流处理中的某个步骤是发送邮件操做，当邮件发送出去后，假若后面出现问题要回滚整个流处理流程，已发送的邮件是无法追回的，这就是所谓的反作用。当你的流处理逻辑中存在包含反作用的操做算子时，该操做算子的执行是没法保证精确一次处理的。所以，咱们一般只是保证这类操做对应用状态的影响精确一次罢了。后面咱们会重点讨论 Kafka Streams 是如何实现 EOS 的。
本文讨论的流处理既包含真正的实时流处理，也包含微批化（Microbatch）的流处理。所谓的微批化，其实就是重复地执行批处理引擎来实现对无限数据集的处理。典型的微批化实现平台就是Spark Streaming。
Kafka Streams的特点
相比于其余流处理平台，Kafka Streams 最大的特点就是它不是一个平台，至少它不是一个具有完整功能（Full-Fledged）的平台，好比其余框架中自带的调度器和资源管理器，就是 Kafka Streams 不提供的。
Kafka 官网明肯定义 Kafka Streams 是一个Java 客户端库（Client Library）。你可使用这个库来构建高伸缩性、高弹性、高容错性的分布式应用以及微服务。
使用 Kafka Streams API 构建的应用就是一个普通的 Java 应用程序。你能够选择任何熟悉的技术或框架对其进行编译、打包、部署和上线。
在我看来，这是 Kafka Streams 与 Storm、Spark Streaming 或 Flink 最大的区别。
Java 客户端库的定位既能够说是特点，也能够说是一个缺陷。目前 Kafka Streams 在国内推广缓慢的一个重要缘由也在于此。毕竟，不少公司但愿它是一个功能完备的平台，既能提供流处理应用 API，也能提供集群资源管理与调度方面的能力。因此，这个定位究竟是特点仍是缺陷，仁者见仁、智者见智吧。
Kafka Streams与其余框架的差别
接下来，我从应用部署、上下游数据源、协调方式和消息语义保障（SemanticGuarantees）4 个方面，详细分析一下 Kafka Streams 与其余框架的差别。
应用部署
首先，咱们从流处理应用部署方式上对 Kafka Streams 及其余框架进行区分。
咱们刚刚提到过，Kafka Streams 应用须要开发人员自行打包和部署，你甚至能够将Kafka Streams 应用嵌入到其余 Java 应用中。所以，做为开发者的你，除了要开发代码以外，还要自行管理 Kafka Streams 应用的生命周期，要么将其打包成独立的 jar 包单独运行，要么将流处理逻辑嵌入到微服务中，开放给其余服务调用。
但不管是哪一种部署方式，你须要本身处理，不要期望 Kafka Streams 帮你作这些事情。
相反地，其余流处理平台则提供了完整的部署方案。我以 Apache Flink 为例来解释一下。在 Flink 中，流处理应用会被建模成单个的流处理计算逻辑，并封装进 Flink 的做业中。相似地，Spark 中也有做业的概念，而在 Storm 中则叫拓扑（Topology）。做业的生命周期由框架来管理，特别是在 Flink 中，Flink 框架自行负责管理做业，包括做业的部署和更新等。这些都无需应用开发人员干预。
另外，Flink 这类框架都存在资源管理器（Resource Manager）的角色。一个做业所需的资源彻底由框架层的资源管理器来支持。常见的资源管理器，如 YARN、Kubernetes、Mesos 等，比较新的流处理框架（如 Spark、Flink 等）都是支持的。像 Spark 和 Flink这样的框架，也支持 Standalone 集群的方式，即不借助于任何已有的资源管理器，彻底由集群本身来管理资源。这些都是 Kafka Streams 没法提供的。
所以，从应用部署方面来看，Kafka Streams 更倾向于将部署交给开发人员来作，而不是依赖于框架本身实现。
上下游数据源
谈完了部署方式的差别，咱们来讲说链接上下游数据源方面的差别。简单来讲，KafkaStreams 目前只支持从 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 这种重量级的协调模型各有优劣。
消息语义保障
咱们刚刚提到过 EOS，目前不少流处理框架都宣称它们实现了 EOS，也包括 KafkaStreams 自己。关于精确一次处理语义，有一些地方须要澄清一下。
实际上，当把 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的两阶段提交机制。
两阶段提交（2-Phase Commit，2PC）机制是一种分布式事务机制，用于实现分布式系统上跨多个节点事务的原子性提交。下面这张图来自于神书“Designing Data-IntensiveApplications”中关于 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 的适配性是最好的。
总结
好了，咱们来小结一下。本文重点分享了 Kafka Streams 与其余流处理框架或平台的差别。总的来讲，Kafka Streams 是一个轻量级的客户端库，而其余流处理平台都是功能完备的流处理解决方案。这是 Kafka Streams 的特点所在，但同时可能也是缺陷。不过，我认为不少状况下咱们并不须要重量级的流处理解决方案，采用轻量级的库 API 帮助咱们实现实时计算是很方便的情形，我想，这或许是 Kafka Streams 将来的破局之路吧。