kafka-and-streaming

Kafka and Streaming Data

Back to Data Engineering Index

Reference: Intro to Apache Kafka Universe: Kafka คืออะไร ?

Streaming Data

Streaming data หรือ event คือข้อมูลเล็กๆ (ขนาดประมาณ Kilobytes) และถูกสร้างขึ้นแบบต่อเนื่องๆ เมื่อข้อมูลไหลเข้ามาสู่ระบบ ก็จะนำข้อมูลมา process ทันที เพื่อนำข้อมูลนี้ไปใช้แบบ real-time หรือ near real-time

Use Cases

• ข้อมูลการเงินใน stock market
• ข้อมูล sensor จากรถขนส่ง เพื่อส่งไปหา streaming application หาพิกัดของรถ
• ข้อมูล social media feeds
• ข้อมูลของการเล่นของ player ในเกมที่นำมาวิเคราะห์แบบ real-time

Why Developers Use Kafka

1. สามารถนำมาทำเป็น Cluster เพื่อใช้การทำ Distributed messaging queue/system ได้
2. ประยุกต์ใช้ในการทำ Notification system หรือ Activity tracking ได้
3. ใช้ทำ Logging flow หรือ Monitoring system แบบ Real-time ได้
4. เป็นส่วนประกอบของการทำ Data analytics แบบที่ต้องการความเร็วในการวิเคราะห์ข้อมูลได้ทันที
5. เป็น Stage ของการทำ Decoupling สำหรับ System หลายๆ System ได้
6. สามารถนำไป Integrate กับ Tool stacks ต่างๆ ได้ง่ายและมีความเคลื่อนไหวใน Tech community สูง

Apache Kafka

Apache Kafka คือ open-source distributed event-streaming platform โดยถูกนำไปใช้สร้าง real-time data pipeline และ streaming apps ปัจจุบันกลายมาเป็นหนึ่งใน Apache Software Foundation

Key Characteristics

• เขียนด้วยภาษา Java และ Scala
• ไว้เพื่อทำ high-throughput และ low latency platform
• สำหรับ real-time data

Basic Architecture

Producer

• ดึงข้อมูลมาจาก external system เช่น web server, components of applications, IoT devices, monitoring agents
• Write event data ส่งไป Kafka

Consumer

• มีหน้าที่ดึงข้อมูลมาใช้จาก producers
• นำข้อมูลนี้ไปสู่ปลายทางอื่นๆ เช่น database, data lake, หรือ data analytics application

Kafka

• ทำหน้าที่เป็นคนกลางคั่นระหว่าง producer และ consumer
• Kafka system นี้จะเรียกว่า Kafka Cluster

Cluster Structure

ใน Cluster จะมีหลาย nodes ซึ่ง node ใน Kafka เราจะเรียกว่า broker ซึ่งเป็นที่มาว่าทำไม Kafka ถูกจัดว่าเป็น distributed system

producer จะเป็นคน publish event ไปหา Kafka topics ซึ่ง consumer นั้นจะ subscribe จาก topic ที่ต้องการ โดยที่ topic นั้นจะมีหลาย consumer ก็ได้

Pub/Sub Messaging

Kafka เป็น publish/subscribe messaging system หรือ pub/sub messaging คือ pattern หนึ่งในการส่งข้อมูลจาก ผู้ส่ง (publisher) ไปหา ผู้รับ (subscriber) โดยจะส่งเป็น piece of data (message)

ความพิเศษ:

• Publisher จะไม่ได้ระบุเป็นพิเศษว่า subscriber ต้องเป็นใคร
• สามารถส่งไปหาหลาย subscriber ก็ได้

Kafka Components

Kafka Broker

เป็นตัวกลางในการจัดการและจัดเก็บข้อมูลในระบบ Kafka (เปรียบเหมือน server)

• แต่ละ Broker จะมีตัวเลขที่ไม่ซ้ำกัน และเป็นตัวเลขเฉพาะของแต่ละ Server
• ประกอบไปด้วย Topic หลายๆ Topics แล้วแต่จะกำหนดด้วย Configuration
• หากมีหลายๆ Brokers รวมเป็น Cluster

Kafka Topic

Topic คือ Stream ของข้อความที่ถูกจัดกลุ่มเข้าด้วยกัน สามารถเปรียบเทียบได้กับ table ใน database โดยที่ชื่อของ Topic จะต้อง Unique ไม่ซ้ำกันภายใน Kafka cluster

Topic Characteristics

• Topic ถือว่าเป็น Logical representation ดังนั้นในหนึ่งคลัสเตอร์สามารถมีกี่ Topic ก็ได้
• Topic เป็นตัวกลางสำหรับส่งผ่านข้อความระหว่าง Producer และ Consumer
• ข้อความที่ส่งเข้ามาใน Topic ถือว่าเป็น Immutability ไม่สามารถแก้ไขข้อความได้
• ข้อความใน Topic จะมี retention ในการ delete จาก Hard disk เสมอ (default as 7 days)

Partitions and Offsets

โดย topic จะถูกแบ่งเป็น partitions และในแต่ละ partition แต่ละ message ก็จะได้รับ id หรือเรียกว่า offset

ข้อควรระวัง:

• ข้อมูลใน offset เดียวกัน ไม่ใช่ข้อมูลเดียวกัน
  • ข้อมูล Partition 0 ที่ offset 1 ≠ partition 1 ที่ offset 1
• ข้อมูลที่ถูก write ใน partition จะไม่สามารถเปลี่ยนแปลงได้ (immutable)
• การเรียง order จะทำได้แค่ภายใน partition เท่านั้น

Topic Examples

ตัวอย่างการกระจายตัวของ Partition เพื่อรักษา Consistency ของการประมวลผล และเพิ่ม Load Balancing ระหว่าง Broker

Create a topic named “A” with 3 partitions and “B” with 2 partitions:

Topic Replication: Set Replication Factor ในระดับ Topic เพื่อเพิ่ม Fault tolerance สามารถรับการที่ Broker บางตัว down ในบางจังหวะ

Topic A → replication factor = 1, and Topic B → replication factor = 2:

When broker 101 is down, Topic B partition 1 at broker 102 becomes partition leader:

Zookeeper

• Zookeeper ช่วย Kafka broker ในการจัดสรร Leader election สำหรับ partition and topic
• Zookeeper ช่วย Kafka บันทึก configuration/metadata/permission ภายใน cluster
• Zookeeper จัดการ tracking ว่าภายใน Cluster มี Kafka broker ใดบ้างที่ยัง operate อยู่
• Zookeeper จัดการ notification ระหว่างตัวเองกับ Kafka ในกรณีที่มีการเปลี่ยนแปลง หรือ failure

Kafka Message

• เป็น Key(binary) - Value(binary)
• Kafka รองรับรูปแบบของ Message ในรูปของ Byte เท่านั้น (8-bit binary digits)
• ไม่ต้องการ deal กับ data type จำนวนมากมายหลายชนิด

Serialization/Deserialization

• ก่อนที่ Producer จะส่งข้อความเข้า Kafka topic จะต้องทำ Message serialization เพื่อให้ข้อความอยู่ในรูป Byte message
• หลังจาก Consumer รับข้อความออกจาก Kafka topic จะต้องทำ Message deserialization เพื่อให้ข้อความจริงปรากฏออกมา

Kafka Producer

Producer จะเป็นคนส่ง message ไปหา topics และ message จะถูกกระจายไปตาม partition

Key Concepts

• 1 Kafka message จะ represent ได้เพียง 1 Offset
• Order guarantee มีผลแค่ภายใน Partition เดียวกันเอง
• Offset จะรันเลขไปเรื่อยๆ ไม่มีการนำเลขกลับมาใช้ใหม่

Partitioning Strategy

การกระจายนี้ Partitioning strategy ทำได้ 2 แบบ:

1. Default: hash(key) % num_partition
   • Key ของ kafka message สามารถกำหนดได้ว่า message นั้นจะถูกส่งไปที่ partition ไหน
2. No key: Round-robin

Producer Configuration

เราสามารถ configure ทำ Kafka producer setting เพื่อบอกว่าเราพร้อมที่จะรับ data loss เพื่อ trade-off กับความเร็วในการส่งข้อมูลมากน้อยแค่ไหน:

• acks=0 → Producer ไม่รอการคอนเฟิร์มกลับจาก Kafka (มีความเสี่ยงต่อ data loss ที่สุด แต่ส่งเร็วสุด)
• acks=1 → Producer รอการคอนเฟิร์มกลับจาก leader acknowledgment เท่านั้น (ความเสี่ยงน้อย)
• acks=all → Producer รอการคอนเฟิร์มกลับจาก leader and replica acknowledgment เท่านั้น (no data loss)

Kafka Consumer

Consumer จะทำหน้าที่อ่านข้อมูลจาก topic ด้วยการ pull message มา

Consumer Behavior

• ความฉลาดของมันคือ consumer จะรู้ว่าควรอ่านข้อมูลจาก broker ไหน
• วิธีอ่านของ consumer คือจะอ่านไล่จาก offset ต่ำไปสูงในแต่ละ partition ตามลำดับ
• Order guarantee มีผลแค่ภายใน Partition เดียวกันเอง
• ถ้า broker failed ขึ้นมา consumer ก็จะรู้ว่าต้องกลับไปอ่านจากจุดไหน ด้วยการดูจาก offset
• เมื่อฝั่ง producer มีการทำ serializer ดังนั้นฝั่ง consumer ก็จะมี deserializer เช่นกัน

Delivery Semantics

Exactly Once

• Consumer อ่านข้อมูลมา โดยไม่ทำให้เกิด duplication หรือ data loss แน่นอน
• สามารถใช้ idempotent target sink/process เข้ามาช่วยแก้ปัญหา
• ถือว่าเป็น semantics ที่ ideal ที่สุด
• Idempotency หมายถึง ถ้ามีการส่งข้อมูลเดิมมาที่ consumer จะไม่ทำการ process ซ้ำ หรือทำซ้ำได้แต่ผลการทำงานจะต้องเหมือนทำงานไปแค่ครั้งเดียว

At Most Once

• เมื่อ consumer ได้รับข้อความจาก offset นั้นๆ แล้ว จะ commit offset กลับไปที่ broker
• ถ้าเกิดข้อผิดพลาดระหว่างที่กำลังรับข้อมูล offset นั้นๆ จะไม่ถูก commit และจะไม่ถูกอ่านอีกครั้ง

At Least Once

• เมื่อ consumer ได้รับข้อความจาก offset นั้นๆ แล้ว จะ commit offset กลับไปที่ broker
• ถ้าเกิดข้อผิดพลาดระหว่างที่กำลังรับข้อมูล offset นั้นๆ จะไม่ถูก commit และจะถูกอ่านอีกครั้ง
• วิธีที่สามารถทำให้เกิด duplication ของข้อมูลได้ เพราะฉะนั้นต้องรองรับ deduplication

Consumer Group

Consumer มี Consumer group ที่จะรวม consumer หลายตัวเข้าด้วยกัน เพื่อช่วยกันอ่าน message ในแต่ละ partition

• Kafka จะเก็บ offset ว่า consumer group อ่านถึงไหนแล้ว ชื่อ __consumer_offsets อยู่ใน topic
• เพราะด้วยเหตุนี้ ถ้า consumers ตาย มันก็จะกลับไปอ่านต่อจาก offsets เดิมได้ (committed offset)

Advanced Components

Kafka Connect

ทำหน้าที่ดึงหรือส่งผ่านข้อมูลจาก system (source connector) หนึ่งไปยังอีก system (sink connector) ได้ โดยที่ Developer ไม่ต้องสร้าง Kafka Producer/Consumer ขึ้นมาเอง

Kafka Streams

เป็น Client library ของ Kafka ที่มีการเสริมเติมแต่ง functionality ให้มีการทำ aggregation, joining ต่างๆ บน data streams ได้ เพราะฉะนั้นเราสามารถ transform ข้อมูลแบบ real-time ได้

ksqlDB

ksqlDB เป็น platform ที่เชื่อมต่อกับ Apache Kafka โดยตรง เพื่อประมวลผลข้อมูลแบบ real-time ระหว่าง application ต่างๆ โดยให้ผู้ใช้งานสามารถเขียน SQL-like statements สำหรับการประมวลผลข้อมูลโดยตรงจาก Kafka topics

(ksqlDB is built on-top of Kafka Streams → KStream,KTable)

Additional Concepts

Replication

• Topics จะมีการทำ replication factor ด้วย
• Partitions จะถูกเก็บไว้ที่ broker อื่น หาก broker นั้นตายขึ้นมา ก็ยังมีสำรองไว้อยู่อีก broker นึง
• มี concept ของ Leader ในแต่ละ partition จะมีเพียง 1 broker ที่เป็น leader สำหรับ partition นั้นๆ
• เวลา producer จะส่งข้อมูลหา broker ก็จะส่งแต่ตัวที่เป็น leader แล้ว broker ตัวที่เป็น follower ก็จะ replicate ตาม leader ไป

Kafka vs RabbitMQ

Kafka มักถูกเปรียบเทียบกับ traditional messaging queue (Message broker) เสมอ เช่น RabbitMQ, IBM MQ, และ Microsoft Message Queue

Message Broker Concept

Message broker นั้นมี concept คือทำให้ application, services ภายใน system เขาคุยกันและแลกเปลี่ยนข้อมูลกันได้ โดยทำหน้าที่เป็นคนคั่นระหว่าง sender กับ receiver โดยที่ sender ไม่ต้องรู้ว่าจะต้องส่งหา receiver ตัวไหน มีการทำ route, store, deliver message

Key Differences

Aspect	Kafka	RabbitMQ
Message Retention	เก็บ message ไว้ (default 7 วัน)	ลบ message เมื่อ consumer รับแล้ว
Message Delivery	Consumer pull message	Broker push message
Intelligence	Consumer ฉลาด (รู้ว่าต้อง pull จากไหน)	Broker ฉลาด (คำนวนว่า consumer จะ process ยังไง)
Scaling	Horizontal (เพิ่ม node)	Vertical (เพิ่ม performance ให้ node เดิม)
Multi-consumer	หลาย consumer ได้รับ message เดียวกัน	Message ถูกลบหลัง consume

---

Related:

• Data Analytics Platforms