在早期的博客文章《卡夫卡内部分析民主化》中, hdp 和 hdf 中的3个强大的新访问模式, 我们讨论了不同的访问模式, 这些模式为应用程序开发人员和 bi 分析师提供了强大的新工具来实现多样化的使用卡夫卡是其应用程序体系结构的关键组成部分的情况。在这篇文章中, 我们将详细讨论流访问模式和在 hdfdf 3.3 中添加的卡夫卡流支持以及即将发布的 hdp 3.1 版本。
在添加卡夫卡流支持之前, hdp 和 hdf 支持两个流处理引擎: 带有风暴的火花结构化流和流分析管理器 (sam)。因此, 这自然会产生以下问题: 为什么要向平台添加第三个流处理引擎？
通过选择使用 spark 结构化流或 sam 支持, 客户可以根据其非功能需求和用例选择正确的流处理引擎。但是, 这两种引擎都不能满足我们从客户处看到的以下类型的要求:
- 轻量级库, 以卡夫卡为消息/事件主干, 构建基于事件的微服务。
- 应用程序运行时不应需要群集。
- 面向希望以编程方式构建具有简单 api 的流应用程序以不太复杂的用例的应用程序开发人员。
- 要求围绕精确的一次性语义, 其中数据管道只包括卡夫卡。
卡夫卡流满足了这些要求。随着卡夫卡流的加入, 客户现在有了更多的选择, 可以根据自己的要求和使用案例选择合适的流处理引擎。下表提供了一些一般的指南/比较。
上表中充满了大量的信息。那么, 卡夫卡流何时成为满足您流处理需求的理想选择？请考虑以下事项:
- 您的流处理应用程序包括卡夫卡到卡夫卡管道。
- 您不需要/另一个群集进行流处理。
- 您希望执行常见的流处理功能, 如筛选、联接、聚合, 以及在流上丰富流, 以便使用更简单的流处理应用程序。
- 您的目标用户是具有 java 开发背景的开发人员。
- 您的用例是关于构建轻量级微服务、简单的 etl 和流分析应用程序。
这三个受支持的流引擎中的每一个都使用一组集中的平台服务, 提供安全性 (身份验证/授权)、审核、治理、架构管理和监视功能。
下一步是什么？
在下面的文章中, 我们将演示如何使用与架构注册、atlas 和 ranger 集成的卡夫卡流, 使用虚构的用例构建一组微服务应用程序。