In an earlier blog post, Democratizing Analytics within Kafka With 3 Powerful New Access Patterns in HDP and HDF, we discussed different access patterns that provides application developers and BI analysts powerful new tools to implement diverse use cases where Kafka is key component of their application architectures. In this blog, we will discuss in detail the streaming access pattern and the addition of Kafka Streams support in HDF 3.3 and the upcoming HDP 3.1 release.
Before the addition of Kafka Streams support, HDP and HDF supported two stream processing engines: Spark Structured Streaming and Streaming Analytics Manager (SAM) with Storm. So naturally, this begets the following question:
Why add a third stream processing engine to the platform?
With the choice of using Spark structured streaming or SAM with Storm support, customers had the choice to pick the right stream processing engine based on their non- functional requirements and use cases. However, neither of these engines addressed the following types of requirements that we saw from our customers:
Kafka Streams addresses each of these requirements. With the addition of Kafka Streams, customers now have more options to pick the right stream processing engine for their requirements and use cases. The below table provides some general guidelines / comparisons.
The table above is packed with lots of information. So, when is Kafka Streams an ideal choice for your stream processing needs? Consider the following:
Each of these three supported streaming engines use a centralized set of platform services providing security (authentication / authorization), audit, governance, schema management and monitoring capabilities.
In the following post to this, we will demonstrate using Kafka Streams integrated with Schema Registry, Atlas and Ranger to build set of microservices apps using a fictitious use case.