A Comprehensive Analysis: Apache Kafka

Disclaimer: This post is a combination of original content and facts gathered from reputable sources sited below. I've been compelled to write these posts due so many tech writers putting out articles that are not technically sound, these posts are meant to be factoid for a "one-stop" reference. Also please keep in mind many of these topics are so new they are evolving as I type this post, so your inputs are greatly appreciated & welcomed.

As part of my comprehensive analysis series, I wanted to take a closer look at another open source tool that is gaining popularity within the Big Data world, as it relates to messaging systems. Over the years there have been multiple options for a messaging systems, but with the introduction of Big Data, scalability & speed become a major components to the new age tools we consider as part of the enterprise technological evolution. This post will discuss:

1. What's the history behind Apache Kafka?
2. What is Apache Kafka? and it's various components? and What do they do?

Brief History of Apache Kafka

Apache Kafka was originally developed by LinkedIn, and was subsequently open sourced in early 2011. Graduation from the Apache Incubator occurred on 23 October 2012. In November 2014, several engineers who built Kafka at LinkedIn created a new company named Confluent with a focus on Kafka.

Jay Kreps, one of the Co-Founders of Kafka had taken a lot of literature classes in college and he liked much of Franz Kafka's work. When developing Kafka with fellow Co-Founders, Neha Narkhede and Jun Rao, an open source tool that was optimized for writing, it seemed like a natural fit to name it after the famous writer.

Apache Kafka is an open-source message broker project developed by the Apache Software Foundation written in Scala. The project aims to provide a unified, high-throughput, low-latency platform for handling real-time data feeds. The design is heavily influenced by transaction logs.

Before we start the deeper dive into Apache Kafka, we must establish a high level understanding of Apache Kafka in the data stream life cycle. 

The data stream life cycle consists of these (3) key components:

1. Create -  creating data from a multitude of event sources (machines, social media, sensors, logs, databases, click stream, email, HTML, images, location, etc)

2. Collect - make data streams available for consumption (ActiveMQ, RabbitMQ, Apache Kafka, etc.)

3. Process - processing streams and possibly creating derived streams (Apache MapReduce, Tez, Flink, Spark, Storm, etc.)

It is this "Collect" component that we will focus on in this post, as we take a deeper look at Apache Kafka and it's various components. This graphic below from the Rich Relevance blog site does a great job illustrating Apache Kafka's role in Big Data architecture.

Source: RichRelevance Blog Site: How we selected Apache Kafka on our path to real-time data ingestion 

If you already use a traditional messaging service for existing applications, why not use that same technology to stream this new data into HDFS? Apache Kafka has 4 key attributes that make it the tool of choice in Big Data environments.

Source:  Software Mill Blog site 

• Faster & Distributed by Design
• Scale - Apache Kafka has the scalability and performance required by Big Data. 
• Pub/Sub capabilities - Older messaging technologies are queue-based, requiring a lot of manual configuration to make them work. Apache Kafka has the technology that is simpler, cost-effective to manage, more cloud friendly, and supports Enterprise required pub/sub capabilities.
• Slow consumer friendly -  In all big data deployments, whether you’re using data processing engines, MapReduce, Tez, Flink, Storm or Spark to feed data in, they all become slow consumers from the point of view of the messaging system. If the streaming messaging system is not designed to buffer effectively for slow consumers, you’ll find yourself with a significant scalability and manageability problems.

Apache Kafka Overview (Excerpt on Apache Kafka from Apache Software Organization Website) 

Apache Kafka is a distributed, partitioned, replicated commit log service. It provides the functionality of a messaging system, but with a unique design.

Source: Hortonsworks website

Here are the basics of messaging terminology:

• Apache Kafka maintains feeds of messages in categories called topics.
• The processes that publish messages to a Kafka topic producers.
• The processes that subscribe to topics and process the feed of published messages are called consumers.
• Apache Kafka is run as a cluster comprised of one or more servers each of which is called a broker.

So, at a high level, producers send messages over the network to the Kafka cluster(s) which in turn serves them up to consumers.

Communication between the clients and the servers is done with a simple, high-performance, language agnostic TCP protocol. A Java client is provided for Apache Kafka, but clients are available in many languages.

Topics & Logs

Let's first dive into the high-level abstraction Kafka provides—the topic.

A topic is a category or feed name to which messages are published. For each topic, the Kafka cluster maintains a partitioned log that looks like this:

Source: Apache Software Organization

Each partition is an ordered, immutable sequence of messages that is continually appended to—a commit log. The messages in the partitions are each assigned a sequential id number called the offset that uniquely identifies each message within the partition.

The Kafka cluster retains all published messages—whether or not they have been consumed—for a configurable period of time. For example if the log retention is set to two days, then for the two days after a message is published it is available for consumption, after which it will be discarded to free up space. Kafka's performance is effectively constant with respect to data size so retaining lots of data is not a problem.

In fact the only metadata retained on a per-consumer basis is the position of the consumer in the log, called the "offset". This offset is controlled by the consumer: normally a consumer will advance its offset linearly as it reads messages, but in fact the position is controlled by the consumer and it can consume messages in any order it likes. For example a consumer can reset to an older offset to reprocess.

This combination of features means that Kafka consumers are very cheap—they can come and go without much impact on the cluster or on other consumers. For example, you can use our command line tools to "tail" the contents of any topic without changing what is consumed by any existing consumers.

The partitions in the log serve several purposes. First, they allow the log to scale beyond a size that will fit on a single server. Each individual partition must fit on the servers that host it, but a topic may have many partitions so it can handle an arbitrary amount of data. Second they act as the unit of parallelism—more on that in a bit.

Distribution

The partitions of the log are distributed over the servers in the Kafka cluster with each server handling data and requests for a share of the partitions. Each partition is replicated across a configurable number of servers for fault tolerance.

Each partition has one server which acts as the "leader" and zero or more servers which act as "followers". The leader handles all read and write requests for the partition while the followers passively replicate the leader. If the leader fails, one of the followers will automatically become the new leader. Each server acts as a leader for some of its partitions and a follower for others so load is well balanced within the cluster.

Producers

Producers publish data to the topics of their choice. The producer is responsible for choosing which message to assign to which partition within the topic. This can be done in a round-robin fashion simply to balance load or it can be done according to some semantic partition function (say based on some key in the message). More on the use of partitioning in a second.

Consumers

Messaging traditionally has two models: queuing and publish-subscribe. In a queue, a pool of consumers may read from a server and each message goes to one of them; in publish-subscribe the message is broadcast to all consumers. Kafka offers a single consumer abstraction that generalizes both of these—the consumer group.

Consumers label themselves with a consumer group name, and each message published to a topic is delivered to one consumer instance within each subscribing consumer group. Consumer instances can be in separate processes or on separate machines.

Source: Apache Software Organization

If all the consumer instances have the same consumer group, then this works just like a traditional queue balancing load over the consumers.

If all the consumer instances have different consumer groups, then this works like publish-subscribe and all messages are broadcast to all consumers.

More commonly, however, we have found that topics have a small number of consumer groups, one for each "logical subscriber". Each group is composed of many consumer instances for scalability and fault tolerance. This is nothing more than publish-subscribe semantics where the subscriber is cluster of consumers instead of a single process.

Kafka has stronger ordering guarantees than a traditional messaging system, too.

A traditional queue retains messages in-order on the server, and if multiple consumers consume from the queue then the server hands out messages in the order they are stored. However, although the server hands out messages in order, the messages are delivered asynchronously to consumers, so they may arrive out of order on different consumers. This effectively means the ordering of the messages is lost in the presence of parallel consumption. Messaging systems often work around this by having a notion of "exclusive consumer" that allows only one process to consume from a queue, but of course this means that there is no parallelism in processing.

Kafka does it better, by having a notion of parallelism—the partition—within the topics, Kafka is able to provide both ordering guarantees and load balancing over a pool of consumer processes. This is achieved by assigning the partitions in the topic to the consumers in the consumer group so that each partition is consumed by exactly one consumer in the group. By doing this we ensure that the consumer is the only reader of that partition and consumes the data in order. Since there are many partitions this still balances the load over many consumer instances. Note however that there cannot be more consumer instances in a consumer group than partitions.

Kafka only provides a total order over messages within a partition, not between different partitions in a topic. Per-partition ordering combined with the ability to partition data by key is sufficient for most applications. However, if you require a total order over messages this can be achieved with a topic that has only one partition, though this will mean only one consumer process per consumer group.

Guarantees

At a high-level Kafka gives the following guarantees:

• Messages sent by a producer to a particular topic partition will be appended in the order they are sent. That is, if a message M1 is sent by the same producer as a message M2, and M1 is sent first, then M1 will have a lower offset than M2 and appear earlier in the log.
• A consumer instance sees messages in the order they are stored in the log.
• For a topic with replication factor N, we will tolerate up to N-1 server failures without losing any messages committed to the log.

More details on these guarantees are given in the design section of the Apache Software foundation Kafka documentation.

Here is a description of a few of the popular use cases for Apache Kafka. For an overview of a number of these areas in action, see this blog post.

Apache Kafka popular use cases:

Messaging

Kafka works well as a replacement for a more traditional message broker. Message brokers are used for a variety of reasons (to decouple processing from data producers, to buffer unprocessed messages, etc). In comparison to most messaging systems Kafka has better throughput, built-in partitioning, replication, and fault-tolerance which makes it a good solution for large scale message processing applications.

In our experience messaging uses are often comparatively low-throughput, but may require low end-to-end latency and often depend on the strong durability guarantees Kafka provides.

In this domain Kafka is comparable to traditional messaging systems such as ActiveMQ or RabbitMQ.

Website Activity Tracking

The original use case for Kafka was to be able to rebuild a user activity tracking pipeline as a set of real-time publish-subscribe feeds. This means site activity (page views, searches, or other actions users may take) is published to central topics with one topic per activity type. These feeds are available for subscription for a range of use cases including real-time processing, real-time monitoring, and loading into Hadoop or offline data warehousing systems for offline processing and reporting.

Activity tracking is often very high volume as many activity messages are generated for each user page view.

Metrics

Kafka is often used for operational monitoring data. This involves aggregating statistics from distributed applications to produce centralized feeds of operational data.

Log Aggregation

Many people use Kafka as a replacement for a log aggregation solution. Log aggregation typically collects physical log files off servers and puts them in a central place (a file server or HDFS perhaps) for processing. Kafka abstracts away the details of files and gives a cleaner abstraction of log or event data as a stream of messages. This allows for lower-latency processing and easier support for multiple data sources and distributed data consumption. In comparison to log-centric systems like Scribe or Flume, Kafka offers equally good performance, stronger durability guarantees due to replication, and much lower end-to-end latency.

Stream Processing

Many users end up doing stage-wise processing of data where data is consumed from topics of raw data and then aggregated, enriched, or otherwise transformed into new Kafka topics for further consumption. For example a processing flow for article recommendation might crawl article content from RSS feeds and publish it to an "articles" topic; further processing might help normalize or deduplicate this content to a topic of cleaned article content; a final stage might attempt to match this content to users. This creates a graph of real-time data flow out of the individual topics. Storm and Samza are popular frameworks for implementing these kinds of transformations.

Event Processing

Event sourcing is a style of application design where state changes are logged as a time-ordered sequence of records. Kafka's support for very large stored log data makes it an excellent backend for an application built in this style.

Commit Log

Kafka can serve as a kind of external commit-log for a distributed system. The log helps replicate data between nodes and acts as a re-syncing mechanism for failed nodes to restore their data. The log compaction feature in Kafka helps support this usage. In this usage Kafka is similar to Apache BookKeeper project.

I hope this post has shed some light on Apache Kafka, and how incorporating into your current Big Data environment could yield some strong efficiency. Feel free to post your comments below, would love to hear from everyone. These posts are meant to be as much informative as collaborative.Rassul Fazelat (follow me here @BigDataVision), is Managing Partner - Founder of Data Talent Advisors, a boutique Data & Analytics Talent Advisory & Headhunting firm, Organizer of NYC Big Data Visionaries Meetup, Co-Organizer of NYC Marketing Analytics Forum & Co-Organizer of NYC Advanced Analytics Meetup.

Other posts in the Comprehensive Analysis (Big Data) series:

• Deconstructing AI - A Closer Look
• 3 Reason Why Hadoop as a Service Is Making Sense For Business Analytics
• A Comprehensive Analysis: Blockchain Technology Beyond Bitcoin
• A Comprehensive Analysis: Big Data Security
• A Comprehensive Analysis: Dataflow Technology
• A Comprehensive Analysis: Data Processing Part Deux: Apache Spark vs Apache Storm
• A Comprehensive Analysis - NoSQL vs RDBMS
• A Comprehensive Analysis: Apache Kafka 
• A Comprehensive Analysis: Java vs Scala
• A Comprehensive Analysis: Apache Flink and How it compares to Apache Spark
• A Comprehensive Analysis: Apache Spark vs MapReduce

 Big Data Career series:

• Why are Enterprise Big Data Architects not Data Scientists?
• Why Data Engineers are not Data Scientists?
• Top 5 Majors for a Data Science Career

References: Apache Kafka Documentation per Apache Software Organization website https://kafka.apache.org/documentation.html#api