Apache Kafka is a scalable publish-subscribe messaging system
with its core architecture as a distributed commit log.
It was originally built as its centralized event
pipelining platform for online data integration tasks. Over
the past years developing and operating Kafka, we extend
its log-structured architecture as a replicated logging backbone
for much wider application scopes in the distributed
environment. I am going to talk about our design
and engineering experience to replicate Kafka logs for various
distributed data-driven systems, including
source-of-truth data storage and stream processing.
Building a Replicated Logging System with Apache Kafka
1. Building a Replicated Logging System with Apache
Kafka
Guozhang Wang, Joel Koshy, Sriram Subramanian, Kartik Paramasivam
Mammad Zadeh, Neha Narkhede, Jun Rao, Jay Kreps, Joe Stein
42. Configurable ISR Commits
ACK mode Latency On Failures
“no" no network delay some data loss
“leader" 1 network roundtrip a few data loss
“all" ~2 network roundtrips no data loss
43. • Use an embedded controller
• Detect broker failure via ZooKeeper
• Leader failure => elect new leader from ISR
• Leader and ISR persisted in Zookeeper
• For Controller fail-over
Membership Management
58. Example: Espresso
• A distributed document store
• Primary online data serving
platform at LI
• Member profile, homepage, InMail, etc
[SIGMOD 2013]
59. Old Espresso Replication
Data Center-1
Storage
Node
Storage
NodeMySQL
Replication
MySQL MySQL
Search
Index
Hadoop …
…Databus
Cross-DC
Replicator
Data Center-1
Storage
Node
Storage
NodeMySQL
Replication
MySQL MySQL
Search
Index
Hadoop …
DatabusCross-DC
Replicator
68. New Espresso Replication
Data Center-1
Storage
Node
Storage
Node
Storage
Node
Kafka Logs
MySQL MySQL MySQL
Data Center-n
Storage
Node
Storage
Node
Storage
Node
Kafka Logs
MySQL MySQL MySQL
Kafka
MirrorMaker
Search
Index
Hadoop …
…
Search
Index
Hadoop …
* In Progress
78. Take-aways
• Log-centric data flow helps scaling your
systems
• Kafka: replicated log streams for real-time
platforms
THANKS!
Notas do Editor
Thank you. And good morning, today I am going to talk about Kafka, and how it can be built as a general replicated log streams for a wide use of scalable systems.
This is a joint work from the Apache Kafka community.
First of all, being in this room, I think it is safe to say “we all love logs”.
Logs have been around almost as long as this research community.
No-overwrite in POSTGRES
ARIES: Write-Ahead-Logging in the 80’s
Today, reading the 50 page Aries pager has been the must-to-do for every single database graduate student including myself.
Similarly, Log-Structured storage architecture.
Replicated State Machine
And in all these examples, the log is used as the source of truth data change log to scale the systems while providing durability and consistency.
So that is all good stuff about logs, but where is Kafka is this big picture.
Well, Kafka is an Apache open sourced distributed messaging system that stores messages as a commit log.
Data-serving websites, LinkedIn has a lot of data
We have this variety of data and and we need to build all these products around such data.
Messaging: ActiveMQ
User Activity: In house log aggregation
Logging: Splunk
Metrics: JMX => Zenoss
Database data: Databus, custom ETL
This idea of using logs for data flow has been floating around LinkedIn, log-centric fashion.
Take all the organization's data and put it into a central log for real-time subscription.
Data integration, replication, real-time stream processing.
Disks are fast when used sequentially
File system caching
Topic = message stream
Topic has partitions, partitions are distributed to brokers
higher availability and durability
evenly distributed
replicated log => replicated state machine
One of the replicas is leader, leader evenly spread
All writes go to leader
Leader propagates writes to followers in order
Leader decides when to commit message
The size of the ISR is decoupled from the size of the replica set, hence the number of replicas and acknowledgements are independent.
ack=3
committed messages to consumer
messages are committed is independent of the ack chosen by the producer.
ack=1
ack=1
ack=3, follower slow
under replicated partitions
ack=3, broker failure
load balancing
cluster expansion
load balancing
cluster expansion
This is a major initiative and will put Kafka on the critical path for site latency sensitive data paths which also require much higher message delivery guarantees.
Data standardization, site monitoring
Data flow graph. Flow rate may overwhelm query processor: batch processing, sampling, synopsis, etc
In-memory storage constraints: single-pass algorithms, no stream backtracking