Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Something about Kafka
Frank Yao
@超⼤大杯摩卡星冰乐
2013-06-29
13年7月5⽇日星期五
Agenda
• WHAT is Kafka?
• HOW we use it in Vipshop?
• WHY Kafka is so ‘fast’?
13年7月5⽇日星期五
WHAT is Kafka?
13年7月5⽇日星期五
WHAT
• “Kafka is a messaging system that was
originally developed at LinkedIn to
serve as the foundation for LinkedIn's
ac...
User cases
• Operational monitoring: real-time, heads-up
monitoring
• Reporting and Batch processing: load data into
a dat...
Performance
(Below test is from Kafka website)
• Parameters:
• message size = 200 bytes
• batch size = 200 messages
• fetc...
Batch Size
13年7月5⽇日星期五
Consumer Throughput
13年7月5⽇日星期五
Data Size?
13年7月5⽇日星期五
Producers thread?
13年7月5⽇日星期五
Topic Number?
13年7月5⽇日星期五
Tradition Queue
• ActiveMQ, RabbitMQ...
13年7月5⽇日星期五
13年7月5⽇日星期五
My Test
• Use Flume:
• In/Out ~= 30w message per second
13年7月5⽇日星期五
Kafka in Vipshop
13年7月5⽇日星期五
Data ‘in’ Kafka
• Operational monitoring
• Nginx access log
• PHP error log, slow log
• Reporting and Batch processing:
• ...
How many Data?
• Peak Time(10:00~10:30):
• IN : 15k-20k msg per second
• OUT : 30k-40k msg per second
13年7月5⽇日星期五
13年7月5⽇日星期五
Apps depends on Kakfa
13年7月5⽇日星期五
Kibana(Elasticsearch)
13年7月5⽇日星期五
real-time pv uv
13年7月5⽇日星期五
HDFS
13年7月5⽇日星期五
Load use Kafka
13年7月5⽇日星期五
Replace RabbitMQ
RabbitMQ Kafka
Servers
Load
Language
Deployment
Client
Management
RabbitMQ Kafka
6 1
>10 <2.5
Erlang Scal...
WHY Kafka ‘fast’
13年7月5⽇日星期五
Basics
• producers
• consumers
• consumer groups
• brokers
13年7月5⽇日星期五
Kafka Arch
13年7月5⽇日星期五
Kafka Arch
13年7月5⽇日星期五
Kafka Deployment
13年7月5⽇日星期五
Major Design Elements
• Persistent messages
• Throughput >>> features
• Consumers hold states
• ALL is distributed
13年7月5⽇...
Detail Agenda
• Maximizing Performance
• Filesystem vs. Memory
• BTree?
• Zero-copy
• End-to-end Batch Compression
• Consu...
Maximize Performance
13年7月5⽇日星期五
Filesystem vs. Memory
Maximize Performance
13年7月5⽇日星期五
Who is fast?
13年7月5⽇日星期五
Memory
Filesystem
13年7月5⽇日星期五
Disk
hardware linear writes random writes
6*7200rpm SATA
RAID-5
300MB/sec 50k/sec
13年7月5⽇日星期五
ACM Pieces
13年7月5⽇日星期五
Let’s see something REAL
13年7月5⽇日星期五
Server Stats
13年7月5⽇日星期五
page cache
• use free memory for disk caching to make
random write fast
13年7月5⽇日星期五
13年7月5⽇日星期五
Drawbacks
• All disk reads and writes will go through this
unified cache. This feature cannot easily be
turned off without ...
If JVM...
13年7月5⽇日星期五
13年7月5⽇日星期五
If we use memory(JVM)
• The memory overhead of objects is very
high, often doubling the size of the data
stored (or worse)...
cache size
• at least double the available cache by
having automatic access to all free
memory, and likely double again by...
comparison
in-disk in-memory
GC
Initialization
Logic
no GC stop the world
stay warm even if
restarted
rebuilt slow(10min f...
Conclusion
• using the filesystem and relying on
pagecache is superior to maintaining an
in-memory cache or other structure...
Go Extreme!
• Write to filesystem DIRECTLY!
• (In effect this just means that it is transferred
into the kernel's pagecache...
Furthermore
• You can configure: every N messages or
every M seconds. It is to put a bound on
the amount of data "at risk" ...
BTree
Maximize Performance
13年7月5⽇日星期五
Background
• Messaging system meta is often a BTree.
• BTree operations are O(logN).
13年7月5⽇日星期五
BTree
• O(logN) ~= constant time
13年7月5⽇日星期五
BTree is slow on Disk!
13年7月5⽇日星期五
BTree for Disk
• Disk seeks come at 10 ms a pop
• each disk can do only one seek at a time
• parallelism is limited
• the ...
Lock
• Page or row locking to avoid lock the
tree
13年7月5⽇日星期五
Two Facts
• no advantage of driver density because
of the heavy reliance on disk seek
• need small (< 100GB) high RPM SAS
...
Use Log file Structure!
13年7月5⽇日星期五
Feature
• One queue is one log file
• Operations is O(1)
• Reads do not block writes or each other
• Decouple with data siz...
zero-copy
Maximize Performance
13年7月5⽇日星期五
1. The operating system reads data from the disk
into pagecache in kernel space
2. The application reads the data from ker...
zerocopy
• data is copied into pagecache exactly
once and reused on each consumption
instead of being stored in memory and...
13年7月5⽇日星期五
zerocopy performance
13年7月5⽇日星期五
End-to-end Batch
Compression
Maximizing Performance
13年7月5⽇日星期五
Consider that
C1
C2
C3
P1
P2
2*compression+
3*de-compression
M=num(P)
N=num(C)
M*compression+
N*de-compression
13年7月5⽇日星期五
Key point
• End-to-end: compress by producers and
de-compress by consumers
• Batch: compression aims to compress a
‘messag...
Consumer State
13年7月5⽇日星期五
Facts
• No ACK
• Consumers maintain the message state
13年7月5⽇日星期五
Features
• Message is in a partition
• Stored and given out in the order they
arrive
• ‘ watermark’ - ‘offset’ in Kafka
13...
track state
• write msg state in zookeeper
• in one transaction with writing data
• side benefit: ‘rewind’ msg
13年7月5⽇日星期五
Screenshot
13年7月5⽇日星期五
push vs. pull
Consumer State
13年7月5⽇日星期五
push system
• if a consumer is <defunct>?
13年7月5⽇日星期五
Kafka use pull model
13年7月5⽇日星期五
Message
Format & Data structure
13年7月5⽇日星期五
Msg Format
• N byte message:
• If magic byte is 0
1. 1 byte "magic" identifier to allow format changes
2. 4 byte CRC32 of t...
Log format on-disk
• On-disk format of a message
• message length : 4 bytes (value: 1+4+n)
• ‘magic’ value : 1 byte
• crc ...
Kafka Log Implementation
13年7月5⽇日星期五
Screenshot
13年7月5⽇日星期五
Screenshot
13年7月5⽇日星期五
Writes
Message
13年7月5⽇日星期五
Writes
• Append-write
• When rotate:
• M : M messages in a log file
• S : S seconds after last flush
• Durability guarantee:...
Reads
Message
13年7月5⽇日星期五
Buffer Reads
• auto double buffer size
• you can specify the max buffer size
13年7月5⽇日星期五
Offset Search
• Search steps:
1. locating the log segment file in which
the data is stored
2. calculating the file-specific o...
Features
• Reset the offset
• OutOfRangeException(problem we
met)
13年7月5⽇日星期五
Deletes
Message
13年7月5⽇日星期五
Deletes
• Policy: N days ago or N GB
• Deleting while reading?
• a copy-on-write style segment list
implementation that pr...
Zookeeper
13年7月5⽇日星期五
Directory Structure
Zookeeper
13年7月5⽇日星期五
Broker Node
• /brokers/ids/[0...N] --> host:port (ephemeral node)
13年7月5⽇日星期五
Broker Topic
• /brokers/topics/[topic]/[0...N] --> nPartions (ephemeral node)
13年7月5⽇日星期五
Consumer Id
• /consumers/[group_id]/ids/[consumer_id] --> {"topic1":
#streams, ..., "topicN": #streams} (ephemeral node)
1...
Consumer Offset Tracking
• /consumers/[group_id]/offsets/[topic]/[broker_id-partition_id] -->
offset_counter_value ((persi...
Partition Owner
• /consumers/[group_id]/owners/[topic]/[broker_id-partition_id] -->
consumer_node_id (ephemeral node)
13年7...
Why Kafka fast?
• Maximizing Performance
• Filesystem vs. Memory
• BTree?
• Zero-copy
• End-to-end Batch Compression
• Con...
Thank You!
13年7月5⽇日星期五
Upcoming SlideShare
Loading in …5
×

Something about Kafka - Why Kafka is so fast

16,693 views

Published on

This slide briefly introduced the reason why kafka is so fast in performance.

Published in: Technology

Something about Kafka - Why Kafka is so fast

  1. 1. Something about Kafka Frank Yao @超⼤大杯摩卡星冰乐 2013-06-29 13年7月5⽇日星期五
  2. 2. Agenda • WHAT is Kafka? • HOW we use it in Vipshop? • WHY Kafka is so ‘fast’? 13年7月5⽇日星期五
  3. 3. WHAT is Kafka? 13年7月5⽇日星期五
  4. 4. WHAT • “Kafka is a messaging system that was originally developed at LinkedIn to serve as the foundation for LinkedIn's activity stream and operational data processing pipeline.” 13年7月5⽇日星期五
  5. 5. User cases • Operational monitoring: real-time, heads-up monitoring • Reporting and Batch processing: load data into a data warehouse or Hadoop system 13年7月5⽇日星期五
  6. 6. Performance (Below test is from Kafka website) • Parameters: • message size = 200 bytes • batch size = 200 messages • fetch size = 1MB • flush interval = 600 messages 13年7月5⽇日星期五
  7. 7. Batch Size 13年7月5⽇日星期五
  8. 8. Consumer Throughput 13年7月5⽇日星期五
  9. 9. Data Size? 13年7月5⽇日星期五
  10. 10. Producers thread? 13年7月5⽇日星期五
  11. 11. Topic Number? 13年7月5⽇日星期五
  12. 12. Tradition Queue • ActiveMQ, RabbitMQ... 13年7月5⽇日星期五
  13. 13. 13年7月5⽇日星期五
  14. 14. My Test • Use Flume: • In/Out ~= 30w message per second 13年7月5⽇日星期五
  15. 15. Kafka in Vipshop 13年7月5⽇日星期五
  16. 16. Data ‘in’ Kafka • Operational monitoring • Nginx access log • PHP error log, slow log • Reporting and Batch processing: • Nginx access log • PHP error log, slow log • App log • b2c • Recommend • Pay • Passport 13年7月5⽇日星期五
  17. 17. How many Data? • Peak Time(10:00~10:30): • IN : 15k-20k msg per second • OUT : 30k-40k msg per second 13年7月5⽇日星期五
  18. 18. 13年7月5⽇日星期五
  19. 19. Apps depends on Kakfa 13年7月5⽇日星期五
  20. 20. Kibana(Elasticsearch) 13年7月5⽇日星期五
  21. 21. real-time pv uv 13年7月5⽇日星期五
  22. 22. HDFS 13年7月5⽇日星期五
  23. 23. Load use Kafka 13年7月5⽇日星期五
  24. 24. Replace RabbitMQ RabbitMQ Kafka Servers Load Language Deployment Client Management RabbitMQ Kafka 6 1 >10 <2.5 Erlang Scala Difficult Easy A lot Not Many Web-console JMX 13年7月5⽇日星期五
  25. 25. WHY Kafka ‘fast’ 13年7月5⽇日星期五
  26. 26. Basics • producers • consumers • consumer groups • brokers 13年7月5⽇日星期五
  27. 27. Kafka Arch 13年7月5⽇日星期五
  28. 28. Kafka Arch 13年7月5⽇日星期五
  29. 29. Kafka Deployment 13年7月5⽇日星期五
  30. 30. Major Design Elements • Persistent messages • Throughput >>> features • Consumers hold states • ALL is distributed 13年7月5⽇日星期五
  31. 31. Detail Agenda • Maximizing Performance • Filesystem vs. Memory • BTree? • Zero-copy • End-to-end Batch Compression • Consumer state • Message delivery semantics • Consumer state • Push vs. Pull • Message • Message format • Disk structure • Zookeeper • Directory Structure 13年7月5⽇日星期五
  32. 32. Maximize Performance 13年7月5⽇日星期五
  33. 33. Filesystem vs. Memory Maximize Performance 13年7月5⽇日星期五
  34. 34. Who is fast? 13年7月5⽇日星期五
  35. 35. Memory Filesystem 13年7月5⽇日星期五
  36. 36. Disk hardware linear writes random writes 6*7200rpm SATA RAID-5 300MB/sec 50k/sec 13年7月5⽇日星期五
  37. 37. ACM Pieces 13年7月5⽇日星期五
  38. 38. Let’s see something REAL 13年7月5⽇日星期五
  39. 39. Server Stats 13年7月5⽇日星期五
  40. 40. page cache • use free memory for disk caching to make random write fast 13年7月5⽇日星期五
  41. 41. 13年7月5⽇日星期五
  42. 42. Drawbacks • All disk reads and writes will go through this unified cache. This feature cannot easily be turned off without using direct I/O, so even if a process maintains an in-process cache of the data, this data will likely be duplicated in OS pagecache, effectively storing everything twice. 13年7月5⽇日星期五
  43. 43. If JVM... 13年7月5⽇日星期五
  44. 44. 13年7月5⽇日星期五
  45. 45. If we use memory(JVM) • The memory overhead of objects is very high, often doubling the size of the data stored (or worse). • Java garbage collection becomes increasingly sketchy and expensive as the in-heap data increases. 13年7月5⽇日星期五
  46. 46. cache size • at least double the available cache by having automatic access to all free memory, and likely double again by storing a compact byte structure rather than individual objects. Doing so will result in a cache of up to 28-30GB on a 32GB machine. 13年7月5⽇日星期五
  47. 47. comparison in-disk in-memory GC Initialization Logic no GC stop the world stay warm even if restarted rebuilt slow(10min for 10GB) and cold cache handle by OS handle by programs 13年7月5⽇日星期五
  48. 48. Conclusion • using the filesystem and relying on pagecache is superior to maintaining an in-memory cache or other structure 13年7月5⽇日星期五
  49. 49. Go Extreme! • Write to filesystem DIRECTLY! • (In effect this just means that it is transferred into the kernel's pagecache where the OS can flush it later.) 13年7月5⽇日星期五
  50. 50. Furthermore • You can configure: every N messages or every M seconds. It is to put a bound on the amount of data "at risk" in the event of a hard crash. • Varnish use pagecache-centric design as well. 13年7月5⽇日星期五
  51. 51. BTree Maximize Performance 13年7月5⽇日星期五
  52. 52. Background • Messaging system meta is often a BTree. • BTree operations are O(logN). 13年7月5⽇日星期五
  53. 53. BTree • O(logN) ~= constant time 13年7月5⽇日星期五
  54. 54. BTree is slow on Disk! 13年7月5⽇日星期五
  55. 55. BTree for Disk • Disk seeks come at 10 ms a pop • each disk can do only one seek at a time • parallelism is limited • the observed performance of tree structures is often super-linear 13年7月5⽇日星期五
  56. 56. Lock • Page or row locking to avoid lock the tree 13年7月5⽇日星期五
  57. 57. Two Facts • no advantage of driver density because of the heavy reliance on disk seek • need small (< 100GB) high RPM SAS drives to maintain a sane ratio of data to seek capacity 13年7月5⽇日星期五
  58. 58. Use Log file Structure! 13年7月5⽇日星期五
  59. 59. Feature • One queue is one log file • Operations is O(1) • Reads do not block writes or each other • Decouple with data size • Retain messages after consumption 13年7月5⽇日星期五
  60. 60. zero-copy Maximize Performance 13年7月5⽇日星期五
  61. 61. 1. The operating system reads data from the disk into pagecache in kernel space 2. The application reads the data from kernel space into a user-space buffer 3. The application writes the data back into kernel space into a socket buffer 4. The operating system copies the data from the socket buffer to the NIC buffer where it is sent over the network 13年7月5⽇日星期五
  62. 62. zerocopy • data is copied into pagecache exactly once and reused on each consumption instead of being stored in memory and copied out to kernel space every time it is read 13年7月5⽇日星期五
  63. 63. 13年7月5⽇日星期五
  64. 64. zerocopy performance 13年7月5⽇日星期五
  65. 65. End-to-end Batch Compression Maximizing Performance 13年7月5⽇日星期五
  66. 66. Consider that C1 C2 C3 P1 P2 2*compression+ 3*de-compression M=num(P) N=num(C) M*compression+ N*de-compression 13年7月5⽇日星期五
  67. 67. Key point • End-to-end: compress by producers and de-compress by consumers • Batch: compression aims to compress a ‘message set’ • Kafka supports GZIP and Snappy protocols 13年7月5⽇日星期五
  68. 68. Consumer State 13年7月5⽇日星期五
  69. 69. Facts • No ACK • Consumers maintain the message state 13年7月5⽇日星期五
  70. 70. Features • Message is in a partition • Stored and given out in the order they arrive • ‘ watermark’ - ‘offset’ in Kafka 13年7月5⽇日星期五
  71. 71. track state • write msg state in zookeeper • in one transaction with writing data • side benefit: ‘rewind’ msg 13年7月5⽇日星期五
  72. 72. Screenshot 13年7月5⽇日星期五
  73. 73. push vs. pull Consumer State 13年7月5⽇日星期五
  74. 74. push system • if a consumer is <defunct>? 13年7月5⽇日星期五
  75. 75. Kafka use pull model 13年7月5⽇日星期五
  76. 76. Message Format & Data structure 13年7月5⽇日星期五
  77. 77. Msg Format • N byte message: • If magic byte is 0 1. 1 byte "magic" identifier to allow format changes 2. 4 byte CRC32 of the payload 3. N - 5 byte payload • If magic byte is 1 1. 1 byte "magic" identifier to allow format changes 2. 1 byte "attributes" identifier to allow annotations on the message independent of the version (e.g. compression enabled, type of codec used) 3. 4 byte CRC32 of the payload 4. N - 6 byte payload 13年7月5⽇日星期五
  78. 78. Log format on-disk • On-disk format of a message • message length : 4 bytes (value: 1+4+n) • ‘magic’ value : 1 byte • crc : 4 bytes • payload : n bytes • partition id and node id to uniquely identify a message 13年7月5⽇日星期五
  79. 79. Kafka Log Implementation 13年7月5⽇日星期五
  80. 80. Screenshot 13年7月5⽇日星期五
  81. 81. Screenshot 13年7月5⽇日星期五
  82. 82. Writes Message 13年7月5⽇日星期五
  83. 83. Writes • Append-write • When rotate: • M : M messages in a log file • S : S seconds after last flush • Durability guarantee: losing at most M messages or S seconds of data in the event of a system crash 13年7月5⽇日星期五
  84. 84. Reads Message 13年7月5⽇日星期五
  85. 85. Buffer Reads • auto double buffer size • you can specify the max buffer size 13年7月5⽇日星期五
  86. 86. Offset Search • Search steps: 1. locating the log segment file in which the data is stored 2. calculating the file-specific offset from the global offset value 3. reading from that file offset • Simple binary in memory 13年7月5⽇日星期五
  87. 87. Features • Reset the offset • OutOfRangeException(problem we met) 13年7月5⽇日星期五
  88. 88. Deletes Message 13年7月5⽇日星期五
  89. 89. Deletes • Policy: N days ago or N GB • Deleting while reading? • a copy-on-write style segment list implementation that provides consistent views to allow a binary search to proceed on an immutable static snapshot view of the log segments 13年7月5⽇日星期五
  90. 90. Zookeeper 13年7月5⽇日星期五
  91. 91. Directory Structure Zookeeper 13年7月5⽇日星期五
  92. 92. Broker Node • /brokers/ids/[0...N] --> host:port (ephemeral node) 13年7月5⽇日星期五
  93. 93. Broker Topic • /brokers/topics/[topic]/[0...N] --> nPartions (ephemeral node) 13年7月5⽇日星期五
  94. 94. Consumer Id • /consumers/[group_id]/ids/[consumer_id] --> {"topic1": #streams, ..., "topicN": #streams} (ephemeral node) 13年7月5⽇日星期五
  95. 95. Consumer Offset Tracking • /consumers/[group_id]/offsets/[topic]/[broker_id-partition_id] --> offset_counter_value ((persistent node) 13年7月5⽇日星期五
  96. 96. Partition Owner • /consumers/[group_id]/owners/[topic]/[broker_id-partition_id] --> consumer_node_id (ephemeral node) 13年7月5⽇日星期五
  97. 97. Why Kafka fast? • Maximizing Performance • Filesystem vs. Memory • BTree? • Zero-copy • End-to-end Batch Compression • Consumer state • Message delivery semantics • Consumer state • Push vs. Pull • Message • Message format • Disk structure • Zookeeper • Directory Structure 13年7月5⽇日星期五
  98. 98. Thank You! 13年7月5⽇日星期五

×