Something about Kafka - Why Kafka is so fast

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 • ﬂush 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⽇日星期五

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 Difﬁcult 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⽇日星期五

42. Drawbacks • All disk reads and writes will go through this uniﬁed 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⽇日星期五

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 ﬁlesystem and relying on pagecache is superior to maintaining an in-memory cache or other structure 13年7月5⽇日星期五

49. Go Extreme! • Write to ﬁlesystem DIRECTLY! • (In effect this just means that it is transferred into the kernel's pagecache where the OS can ﬂush it later.) 13年7月5⽇日星期五

50. Furthermore • You can conﬁgure: 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 ﬁle Structure! 13年7月5⽇日星期五

59. Feature • One queue is one log ﬁle • 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⽇日星期五

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 beneﬁt: ‘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⽇日星期五

82. Writes Message 13年7月5⽇日星期五

83. Writes • Append-write • When rotate: • M : M messages in a log ﬁle • S : S seconds after last ﬂush • 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⽇日星期五

Something about Kafka - Why Kafka is so fast

Du liest eine Vorschau.

Hier ansehen

Something about Kafka - Why Kafka is so fast

Weitere Verwandte Inhalte

Diashows für Sie (20)

Ähnlich wie Something about Kafka - Why Kafka is so fast (20)

Aktuellste (20)

Something about Kafka - Why Kafka is so fast