在这篇文章中，我们将详细讨论流媒体访问模式以及HDF 3.3和即将发布的HDP 3.1版本中Kafka Streams支持的增加。
在添加Kafka Streams支持之前，HDP和HDF支持两个流处理引擎：带有Storm的Spark Structured Streaming和Streaming Analytics Manager（SAM）。很自然，这会产生以下问题：为什么要在平台上添加第三个流处理引擎？
通过选择使用Spark结构化流式传输或SAM与Storm支持，客户可以选择根据其非功能性需求和用例选择正确的流处理引擎。但是，这些引擎都没有解决我们从客户那里看到的以下类型的要求：
- 轻量级库，用于构建基于事件的微服务，Kafka作为消息传递/事件主干。
- 应用程序运行时不应该需要群集。
- 迎合那些希望以编程方式使用简单API为不太复杂的用例构建流应用程序的应用程序开发人员。
- 对于一次性语义的要求，其中数据管道仅由Kafka组成。
Kafka Streams解决了这些要求。通过添加Kafka Streams，客户现在可以根据自己的需求和用例选择正确的流处理引擎。下表提供了一些一般指导原则/比较。
上表中包含大量信息。那么，Kafka Streams何时成为您流处理需求的理想选择？考虑以下：
- 您的流处理应用程序由Kafka到Kafka管道组成。
- 您不需要/想要另一个集群进行流处理。
- 您希望在流上执行常见的流处理功能，如过滤，连接，聚合，丰富，以便简化流处理应用程序。
- 您的目标用户是具有Java开发背景的开发人员。
- 您的用例是关于构建轻量级微服务，简单的ETL和流分析应用程序。
这三个支持的流引擎中的每一个都使用一组集中的平台服务，提供安全性（身份验证/授权），审计，治理，模式管理和监视功能。
下一步是什么？
在下面的文章中，我们将演示使用与Schema Registry，Atlas和Ranger集成的Kafka Streams，使用虚构的用例构建一组微服务应用程序。