How Open Sourcing Made Apache Kafka A Dominant Streaming Platform (techrepublic.com)

Open sourced in 2010, the Apache Kafka distributed streaming platform is now used at more than a third of Fortune 500 companies (as well as seven of the world's top 10 banks). An anonymous reader writes: Co-creator Neha Narkhede says "We saw the need for a distributed architecture with microservices that we could scale quickly and robustly. The legacy systems couldn't help us anymore." In a new interview with TechRepublic, Narkhede explains that while working at LinkedIn, "We had the vision of building the entire company's business logic as stream processors that express transformations on streams of data... [T]hough Kafka started off as a very scalable messaging system, it grew to complete our vision of being a distributed streaming platform."

Narkhede became the CTO and co-founder of Confluent, which supports enterprise installations of Kafka, and now says that being open source "helps you build a pipeline for your product and reduce the cost of sales... [T]he developer is the new decision maker. If the product experience is tailored to ensure that the developers are successful and the technology plays a critical role in your business, you have the foundational pieces of building a growing and profitable business around an open-source technology... Kafka is used as the source-of-truth pipeline carrying critical data that businesses rely on for real-time decision-making."

Comments

helps you what in the what?

[war4peace]

The amount of corporate bullshit in TFS makes my head hurt and spin... at the same time.

Re:helps you what in the what?

[Anonymous Coward]

its another shitty java clusterfuck

Re:helps you what in the what?

[Anonymous Coward]

I'm using Kafka to create data-driven feeds that leverage business intelligence in semantic data-driven mashups. By integrating a webscale dynamic platform it's added critical synergies to my KPIs.

Kafka

[Anonymous Coward]

The experience I've had testing Kafka with large amounts of data lead me to a couple conclusions.

Kafka is a lot of overhead to control streams, that don't solve the problems you are having when you need distributed streaming solutions. Primarily, bottlenecks, write speeds, read speeds, and processing performance irregularity (including debugging).

The idea that Kafka helps you with stream processing in a way that more traditional methods (load balancing, splitting on load, processing in parallel) can't or don't or that it's easier, is false.

If you're on an ec2, open a socket to S3 and write, have something process it. You'll save a lot of cycles (in every way).

This article is some slick IBM-style marketing which is not very helpful to people with existing technical challenges.

Re:Kafka

[K. S. Kyosuke]

Kafka is a lot of overhead to control streams, that don't solve the problems you are having when you need distributed streaming solutions. Primarily, bottlenecks, write speeds, read speeds, and processing performance irregularity (including debugging). The idea that Kafka helps you with stream processing in a way that more traditional methods (load balancing, splitting on load, processing in parallel) can't or don't or that it's easier, is false.

Isn't this ideally a subject for a specialized language, or an embedded one? I know nothing about Kafka but it really seems that bolting a framework or a library to your system does little to help you with either performance or abstraction in a case like this.

Helps you Java guys stay busy

[thesjaakspoiler]

because getting through those docs and getting the whole d*** thing to work is creating more jobs than it proclaims to save.

The vision

[Anonymous Coward]

We had the vision of building the entire company's business logic as stream processors that express transformations on streams of data

Yikes, reality surpasses Dilbert.

Re:The vision

[K. S. Kyosuke]

Sounds like a special case of functional programming. I didn't know that Dilbert had problems with functional programming mentioned in it.

Moves data from this cluster to that cluster relia

[raymorris]

Suppose you have some service that produces data. This service might be on one server, or a group of servers.

Some other service receives this data. Perhaps the receiving service transforms the data in some way before passing it along to some other system.

Kafka helps with that. It avoids some simple problems. For example, I once worked on a system in which a cron transferred the data at midnight each day. Each day, it sent over that day's data. Records created right at midnight might get skipped, or might get sent twice. In case of a network glitch, you'd have to manually retry in the morning. Kafka avoids those kinds of problems.

Kafka is built on the idea that both producers and consumers may be groups of partially redundant servers, with the data split up between different servers. Kafka has features to enable load balancing.

So it's appropriate where you want to get data from some group of servers to another group, possibly through a middle group, you want it reliable, load balanced, etc, without inventing and later correcting your own protocols.

My read was that Kafka assists with those methods

[raymorris]

> The idea that Kafka helps you with stream processing in a way that more traditional methods (load balancing, splitting on load, processing in parallel) can't or don't or that it's easier, is false.

My read was not that Kafka is supposed to *replace* "load balancing, splitting on load, processing in parallel", but that it's intended to *enable* "load balancing, splitting on load, processing in parallel". Not that it does something that load balancing doesn't do, but that it provides a proven load balancing solution, or at least some key parts.

WTF does it do?

[PhunkySchtuff]

I've got no idea what Kafka does, and the summary really doesn't tell you much at all. I was about to put in a helpful post saying what it is, but even after visiting their home page I've still got no idea.

Apparently Kafka is used for building real-time data pipelines and streaming apps. It is horizontally scalable, fault-tolerant, wicked fast, and runs in production in thousands of companies.

How about the Intro
We think of a streaming platform as having three key capabilities:
It lets you publish and subscribe to streams of records. In this respect it is similar to a message queue or enterprise messaging system.
      It lets you store streams of records in a fault-tolerant way.
      It lets you process streams of records as they occur.

What is Kafka good for?
It gets used for two broad classes of application:
      Building real-time streaming data pipelines that reliably get data between systems or applications
      Building real-time streaming applications that transform or react to the streams of data

OK, I still am not really sure what it does.

Re:WTF does it do?

[PhunkySchtuff]

OK, now it's starting to make more sense looking at the use cases

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.

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 of Kafka process data in processing pipelines consisting of multiple stages, where raw input data is consumed from Kafka topics and then aggregated, enriched, or otherwise transformed into new topics for further consumption or follow-up processing. For example, a processing pipeline for recommending news articles might crawl article content from RSS feeds and publish it to an "articles" topic; further processing might normalize or deduplicate this content and published the cleansed article content to a new topic; a final processing stage might attempt to recommend this content to users. Such processing pipelines create graphs of real-time data flows based on the individual topics. Starting in 0.10.0.0, a light-weight but powerful stream processing library called Kafka Streams is available in Apache Kafka to perform such data processing as described above. Apart from Kafka Streams, alternative open source stream processing tools include Apache Storm and Apache Samza.

Event Sourcing
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.

WTF

[fisternipply]

WTF was all that gibberish? Can someone tell me what this thing actually does?

Re:WTF

[Anonymous Coward]

It handles data. Streams of data. The simplest (and entirely realistic) case is probably log data; some application generates log output, so you use a connector (say, logback-kafka-appender if you're using slf4j) to send that log output to Kafka (this would be "publishing" to a "topic" in enterprise speak) Subscribers (clients) then subscribe to (read from) the topic and consume the log output. A simple subscriber might then simply write that data to log files.

So far, so good. Looks like any ordinary message broker. Now add some fault tolerance; your Kafka server is really a node in a cluster. You can add more Kafka nodes at will — say, different machines in the same rack or something — and your log traffic will reliably replicate between those nodes. If a node goes down everything keeps working; publishers keep publishing and consumers keep consuming without messages being lost, so now you can cycle hosts (hardware upgrades, patches, whatever) without disturbing anyone.

Now you need to send this stuff to another data center. You set up a mirror between a Kafka cluster at your first data center and a new Kafka cluster at your new data center. Consumers talk to their local cluster at the new data center (minimizing WAN traffic and latency.) Data will reliably flow from one cluster to the other. If communication fails the flow will resume and catch up when communication is restored. Kafka transparently compresses data before sending over the WAN saving you lots of bandwidth.

So lots of consumers get built around this flow of data. Dozens of applications, databases and other stuff consume all this data. Some throw most of it out looking for very specific things. Others ETL it all into big analytical systems. Meanwhile, your original application is oblivious; it's just sending log output to some Kafka cluster, entirely unaware of how many data centers and consumers are getting it.

Then you start running your application that publishes the log output at some new site. The new application instance publishes it's log output to the same topic as the existing instance. Clients just keep consuming the same topic, oblivious to the new topology.

Meanwhile you sit there monitoring all this, making sure your redundancy quotas are met, managing disk space and IOPS used to persist all the data, and calling developers and their bosses to make them stop overloading the system with excessive data.

That's Kafka in a nutshell. It's not new; it's been done before in various ways. Kafka's novelty is that it's free and popular and succeeding in the market, displacing older systems and accumulating a lot of mind share.

Re:Moves data from this cluster to that cluster re

[war4peace]

Thank you very much for the clarification.
I am a Business Intelligence Analyst and to my shame I had never heard of this solution, or maybe I had but it was so riddled with buzzwords and corporate bullshit that it became unintelligible to plebs like me.

Yes, I can see quite a few use cases for it. If they only used your words to describe it :)

Re:Moves data from this cluster to that cluster re

[abmw]

More LIke MQ with more optional plumbing?