Something about Kafka - Why Kafka is so fast

9,992
-1

Published on

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

Published in: Technology
0 Comments
72 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
9,992
On Slideshare
0
From Embeds
0
Number of Embeds
13
Actions
Shares
0
Downloads
341
Comments
0
Likes
72
Embeds 0
No embeds

No notes for slide

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⽇日星期五
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×