Something about Kafka - Why Kafka is so fast
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Something about Kafka - Why Kafka is so fast

  • 3,318 views
Uploaded on

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

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

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
3,318
On Slideshare
2,607
From Embeds
711
Number of Embeds
5

Actions

Shares
Downloads
119
Comments
0
Likes
16

Embeds 711

http://www.scoop.it 706
http://dschool.co 2
http://webcache.googleusercontent.com 1
https://twitter.com 1
http://www.google.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Something about Kafka Frank Yao @超⼤大杯摩卡星冰乐 2013-06-29 13年7月5⽇日星期五
  • 2. Agenda • WHAT is Kafka? • HOW we use it in Vipshop? • WHY Kafka is so ‘fast’? 13年7月5⽇日星期五
  • 3. WHAT is Kafka? 13年7月5⽇日星期五
  • 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. 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. 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. Batch Size 13年7月5⽇日星期五
  • 8. Consumer Throughput 13年7月5⽇日星期五
  • 9. Data Size? 13年7月5⽇日星期五
  • 10. Producers thread? 13年7月5⽇日星期五
  • 11. Topic Number? 13年7月5⽇日星期五
  • 12. Tradition Queue • ActiveMQ, RabbitMQ... 13年7月5⽇日星期五
  • 13. 13年7月5⽇日星期五
  • 14. My Test • Use Flume: • In/Out ~= 30w message per second 13年7月5⽇日星期五
  • 15. Kafka in Vipshop 13年7月5⽇日星期五
  • 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. 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. 13年7月5⽇日星期五
  • 19. Apps depends on Kakfa 13年7月5⽇日星期五
  • 20. Kibana(Elasticsearch) 13年7月5⽇日星期五
  • 21. real-time pv uv 13年7月5⽇日星期五
  • 22. HDFS 13年7月5⽇日星期五
  • 23. Load use Kafka 13年7月5⽇日星期五
  • 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. WHY Kafka ‘fast’ 13年7月5⽇日星期五
  • 26. Basics • producers • consumers • consumer groups • brokers 13年7月5⽇日星期五
  • 27. Kafka Arch 13年7月5⽇日星期五
  • 28. Kafka Arch 13年7月5⽇日星期五
  • 29. Kafka Deployment 13年7月5⽇日星期五
  • 30. Major Design Elements • Persistent messages • Throughput >>> features • Consumers hold states • ALL is distributed 13年7月5⽇日星期五
  • 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. Maximize Performance 13年7月5⽇日星期五
  • 33. Filesystem vs. Memory Maximize Performance 13年7月5⽇日星期五
  • 34. Who is fast? 13年7月5⽇日星期五
  • 35. Memory Filesystem 13年7月5⽇日星期五
  • 36. Disk hardware linear writes random writes 6*7200rpm SATA RAID-5 300MB/sec 50k/sec 13年7月5⽇日星期五
  • 37. ACM Pieces 13年7月5⽇日星期五
  • 38. Let’s see something REAL 13年7月5⽇日星期五
  • 39. Server Stats 13年7月5⽇日星期五
  • 40. page cache • use free memory for disk caching to make random write fast 13年7月5⽇日星期五
  • 41. 13年7月5⽇日星期五
  • 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. If JVM... 13年7月5⽇日星期五
  • 44. 13年7月5⽇日星期五
  • 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. 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. 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. Conclusion • using the filesystem and relying on pagecache is superior to maintaining an in-memory cache or other structure 13年7月5⽇日星期五
  • 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. 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. BTree Maximize Performance 13年7月5⽇日星期五
  • 52. Background • Messaging system meta is often a BTree. • BTree operations are O(logN). 13年7月5⽇日星期五
  • 53. BTree • O(logN) ~= constant time 13年7月5⽇日星期五
  • 54. BTree is slow on Disk! 13年7月5⽇日星期五
  • 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. Lock • Page or row locking to avoid lock the tree 13年7月5⽇日星期五
  • 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. Use Log file Structure! 13年7月5⽇日星期五
  • 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. zero-copy Maximize Performance 13年7月5⽇日星期五
  • 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. 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. 13年7月5⽇日星期五
  • 64. zerocopy performance 13年7月5⽇日星期五
  • 65. End-to-end Batch Compression Maximizing Performance 13年7月5⽇日星期五
  • 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. 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. Consumer State 13年7月5⽇日星期五
  • 69. Facts • No ACK • Consumers maintain the message state 13年7月5⽇日星期五
  • 70. Features • Message is in a partition • Stored and given out in the order they arrive • ‘ watermark’ - ‘offset’ in Kafka 13年7月5⽇日星期五
  • 71. track state • write msg state in zookeeper • in one transaction with writing data • side benefit: ‘rewind’ msg 13年7月5⽇日星期五
  • 72. Screenshot 13年7月5⽇日星期五
  • 73. push vs. pull Consumer State 13年7月5⽇日星期五
  • 74. push system • if a consumer is <defunct>? 13年7月5⽇日星期五
  • 75. Kafka use pull model 13年7月5⽇日星期五
  • 76. Message Format & Data structure 13年7月5⽇日星期五
  • 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. 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. Kafka Log Implementation 13年7月5⽇日星期五
  • 80. Screenshot 13年7月5⽇日星期五
  • 81. Screenshot 13年7月5⽇日星期五
  • 82. Writes Message 13年7月5⽇日星期五
  • 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. Reads Message 13年7月5⽇日星期五
  • 85. Buffer Reads • auto double buffer size • you can specify the max buffer size 13年7月5⽇日星期五
  • 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. Features • Reset the offset • OutOfRangeException(problem we met) 13年7月5⽇日星期五
  • 88. Deletes Message 13年7月5⽇日星期五
  • 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. Zookeeper 13年7月5⽇日星期五
  • 91. Directory Structure Zookeeper 13年7月5⽇日星期五
  • 92. Broker Node • /brokers/ids/[0...N] --> host:port (ephemeral node) 13年7月5⽇日星期五
  • 93. Broker Topic • /brokers/topics/[topic]/[0...N] --> nPartions (ephemeral node) 13年7月5⽇日星期五
  • 94. Consumer Id • /consumers/[group_id]/ids/[consumer_id] --> {"topic1": #streams, ..., "topicN": #streams} (ephemeral node) 13年7月5⽇日星期五
  • 95. Consumer Offset Tracking • /consumers/[group_id]/offsets/[topic]/[broker_id-partition_id] --> offset_counter_value ((persistent node) 13年7月5⽇日星期五
  • 96. Partition Owner • /consumers/[group_id]/owners/[topic]/[broker_id-partition_id] --> consumer_node_id (ephemeral node) 13年7月5⽇日星期五
  • 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. Thank You! 13年7月5⽇日星期五