Confluent Platform 3.0支持使用Kafka Streams实现实时的数据处理

by Srini Penchikala on Jun 03, 2016

摘要：

来自Confluent的Confluent Platform 3.0消息系统已支持使用Kafka Streams实现实时的数据处理，这家公司也是在背后支撑Apache Kafka消息框架的公司，它近日宣布最新的开源Confluent platform已经达到了通用发布版本。

来自 Confluent的Confluent Platform 3.0消息系统支持使用Kafka Streams实现实时的数据处理，这家公司也是在背后支撑Apache Kafka消息框架的公司，它近日宣布最新的开源平台已经达到了通用发布（general availability）版本。Confluent Platform可以围绕Apache Kafka创建可扩展的数据平台，Apache Kafka是一个实时的、分布式的、具有容错功能的消息队列，它能够扩展至非常大量的消息。

Kafka Streams是进行数据实时处理的轻量级方案，可以用在欺诈和安全监控、物联网的（Internet of Things，IoT）操作和设备监控。它为Kafka提供了一个新的、原生的流开发环境。开发人员能够使用这个库基于Kafka构建分布式的流处理应用。Kafka涵盖的功能是消息和数据传输，而Kafka Streams涵盖的功能则是数据的处理。

Kafka Streams支持有状态和无状态的处理，同时还支持数据的分布式容错处理。要使用Kafka Streams，并不需要单独的集群、消息转换层或外部依赖。它每次会处理一个事件，而不是小批量（micro-batch）的消息。它还允许数据的延迟抵达并支持windowing处理乱序的数据。

读者可以下载Confluent Platform 3.0或查阅新发布版本的文档，其中包含了Kafka Streams文档以及快速起步指南。

在最近的新闻中，Confluent还宣布了Confluent Control Center的发布，这是一个用于管理Kafka集群的商业产品。Confluent Control Center可以作为Confluent Enterprise 3.0的一部分来获取，它的设计目的是帮助数据工程团队操作组织中的Kafka。这个管理工具为运维人员和数据团队提供了监控Kafka系统不同组件的功能，这些组件包括主题、生产者和消费者，并且能够理解数据管道中发生了什么状况。

借助Control Center，运维人员能够在消息级别检查数据环境，从而能够理解消息投递情况、可能出现的瓶颈并且可以在原生的Kafka环境中观察端到端的消息投递。为了满足特定的需求，Control Center UI允许运维人员连接新的数据源到集群上并配置新的数据源连接器。

如果你有兴趣学习Control Center的更多知识，可以关注接下来的webinar。

InfoQ采访到了来自Confluent的Joseph Adler（产品管理和数据科学主管）和Michael Noll（产品经理）来进一步了解这些产品发布信息以及这些产品如何帮助开发人员和运维团队。

InfoQ：Kafka Streams与其他的流数据处理框架如Storm、Spark Streaming和Apache Flink相比，其差异性是什么呢？

Joseph Adler & Michael Noll：在流处理框架方面，负责流处理的开发人员有很多不同的可选方案。事实上，其中很多方案已经将Kafka用于在它们的流处理管道中了。Kafka Streams构建在Apache Kafka坚实的技术基础之上，从这里它继承了Apache Kafka的可扩展性、弹性、容错性以及很多其他的特性。我们相信Kafka Streams降低了进入流处理领域的门槛，因此能够让很多的公司从实时洞悉业务现状中收益。Kafka Streams也继承了Kafka的安全模型，也就是加密传输中的数据，这对像金融这样的行业来说，是很好的选择。

像Spark和Flink这样的框架通常会用在中心数据工程团队中，用于发挥大数据和数据仓库设施的威力。它们的设计是“大型重量级（heavy lifting）”的——运行复杂的查询，所消耗的时间能够持续数小时甚至更长。

Kafka Streams适用于“快速的应用”或“流应用”——在这些应用中，产生响应的速度是非常重要的。输出可能是购买决策、基于特定场景的报价或者安全告警。这些开发人员一般会位于某个业务处理的流水线之中。

借助Kafka Streams，对于实时处理这样的需求，我们不必像已有的流处理框架那样安装和运维单独的集群。很多人其实已经使用Kafka从事一些实时的数据处理（如欺诈探测、用户活动跟踪或流量监控）并将Kafka作为数据平台中消息系统的基石，所以使用Kafka Streams来处理Kafka原生环境中所有的数据是很自然的选择，这样的话，就没有必要新增另外的基础设施和技术了，如果要新增技术的话，开发人员可能还需要对其理解、优化并保证它的持续运行。

InfoQ：Flink在流数据的处理中，并没有使用micro batch的方式，这与Kafka Streams的工作机制是类似的。Kafka Streams与Flink还有什么相似之处或差异吗？

Adler & Noll： Kafka Streams学习了行业之前的经验，包括学术上的，也包括开源项目社区的，如Apache Samza。这说明在重要领域具有一定的相似性，比如恰当的时间模型来区分事件时间与处理时间的语义，以及正确处理延迟到达、数据乱序的能力。这些特性对于任何实用的流处理用例都是必需的。

另外一个关键的差异在于Kafka Streams支持弹性，也就是说，可以动态地增加和收缩处理能力。例如，在Kafka Streams中，开始的时候，我们可以只有一台机器运行流处理应用，用它来处理传入的业务数据。当数据量增大，一台机器的处理能力不足以应对的时候，那么就可以（在运行时操作，无需停机）在另外一台机器上启动相同的应用，它们会自动分担工作内容。

InfoQ：Kafka Streams支持Windowing功能。你们能更详细地描述一下这个特性吗，在实时数据处理中，它的作用是什么？

Adler & Noll： windowing允许我们将持续的数据流划分为更小的块（chunk）。这种windowing最为常见的是基于时间，比如基于五分钟的间隔来执行分析。对于很多的使用场景来说，windowing是非常重要的，比如欺诈检测（“这个人在过去从来没有在一个小时内多次使用信用卡，但现在，我们在过去的五分钟内看到了五十笔交易——那么信用卡可能被盗了”）或者热门话题（“在过去的24小时内，Twitter的大多数用户关注美国的总统大选、新的Apple MacBook以及Justin Bieber的最新视频”）。

InfoQ：你们能阐述一下基于时间（Time）和基于会话（Session）的windowing方案的差别吗，以及分别应该在何时使用它们？

Adler & Noll：比如说，基于时间的windowing会将流数据划分为每隔五分钟的数据块。可以将其想象为一个计数器：每隔五分钟，你就会宣布“新窗口的数据！”有很多的使用场景都需要windowing功能，可能绝大多数都是基于时间的。

与之不同，如果是基于会话的windowing，那么它的范围就不是严格的计时器规则了，这是为了将相关的事件分组到一个所谓的会话（session）中。可以将这些会话视为一个阶段内的活动。使用基于会话windowing的一个常见使用场景就是分析用户交互事件，例如理解用户如何阅读《金融时报》的Web站点以及如何与Facebook进行交互。

InfoQ：你们能介绍一下Kafka在安全方面所提供的功能吗，这可能会涵盖到对消息和主题的限制访问以及跨Kafka服务器的加密数据传输？

Adler & Noll：在认证方面，Kafka支持SASL/Kerberos、SASL/PLAIN和SSL/TLS。而在授权方面，Kafka提供了ACL来控制对特定主题的读取/写入/管理访问，该功能可以配置为针对认证用户和特定的IP来进行。

传输中的数据可以使用SSL/TLS进行加密，它的加密发生在数据生产者到Kafka broker之间（服务器），从Kafka broker到数据消费者之间以及Kafka集群内部broker之间的通信。

InfoQ：Kafka集群能否部署到Docker容器之中？是否有什么最佳实践或在线资源，帮助开发人员进行这种集成？

Adler & Noll：是的，可以部署Kafka集群到Docker容器中。Confluent提供了实验性的Docker镜像来运行Confluent Platform，其中就包含了Apache Kafka。也就是说，运行基于Docker的Kafka环境依然还是一种例外的情况，而不是通用的规则。一方面这是因为相对来讲，Docker还是较新的技术，尚没有完全成熟。另一方面，在数据架构中，Kafka的角色是存储数据和提供数据服务，也就是说。它是“有状态”的服务。Docker的哲学和最佳实践是不要在容器内运行有状态的服务——它更适合没有状态的服务——因此，弥合这两个稍微正交的方式需要一些特殊的考量。

InfoQ：在新特性和功能增强方面，Kafka有什么规划？

Adler & Noll：在接下来的发布版本中，Apache Kafka社区规划关注于运维的简便性和更强的投递可靠性。这部分工作包括Apache Kafka中改进的数据平衡、更多的安全增强并支持精确的单次投递。Confluent Platform将会具有更多的客户端、连接器，在Confluent Control Center中则会扩展监控和管理功能。同时，Kafka Streams的第一个版本已经随Kafka 0.10一起发布了，Kafka社区和Confluent将会继续致力于扩展Kafka Streams的功能。我们正在进行的一个特性就是在实现流处理应用的时候，可以使用的一个SQL接口。这是我们想要包含进来的一个特性，它有助于扩展Kafka Streams的用户基础，也能在总体上提升流处理能力。

查看英文原文：Confluent Platform 3.0 Supports Kafka Streams for Real-Time Data Processing