เจาะประเด็น
Data Engineering
มอนิเตอร์ Lag แบบเก่าตายแล้ว: ถึงเวลาคิดเรื่อง "เวลาในคิว" ของ Data Pipeline ระดับ Petabyte
Kafka Offset Lag บอกได้แค่ว่าข้อมูลค้างอยู่ แต่บอกไม่ได้ว่ามันจะมาถึงมือคนใช้เมื่อไหร่ — บทความนี้ชี้วิธีคิดใหม่ที่ pragmatic กว่าเยอะ
ทีมข่าว เอไอไทย.com
⏱ อ่าน 6 นาที
ตัวชี้วัดที่คุณใช้อยู่ทุกวันนี้ มันวัด "ความปวดหัว" ได้จริงหรือแค่วัด "จำนวนข้อมูลที่ค้าง"?
เริ่มต้นด้วยคำถามง่ายๆ ที่คนทำ Data Pipeline ทุกคนต้องเคยเจอ: Kafka Offset Lag มันบอกอะไรเราได้บ้าง? หลายคนตอบได้ทันทีว่ามันคือตัวเลขที่บอกว่า Consumer อ่านข้อมูลไปถึงไหนแล้ว เทียบกับ Producer ที่เขียนเข้ามา ถ้าตัวเลขเยอะปุ๊บ แปลว่าข้อมูลค้างปั๊บ ทีมงานต้องลุ้นกันตัวโก่งว่า Consumer จะตามทันไหม แต่ในโลกของ Apache Hudi ที่มีข้อมูลระดับ Petabyte คำตอบมันไม่ได้ง่ายแบบนั้นอีกต่อไป
บทความจาก InfoQ โดย Srikanth Mamidala ชี้ให้เห็นจุดอ่อนสำคัญของการมอนิเตอร์แบบเดิม: Offset Lag มันบอกแค่ "ปริมาณ" งานที่ค้าง แต่มันไม่บอก "เวลา" ที่งานชิ้นนั้นจะเสร็จ ยกตัวอย่างง่ายๆ ถ้าคิวมีงาน 100 ชิ้น แต่ตัว Consumer ประมวลผลได้แค่วินาทีละ 1 ชิ้น มันก็ใช้เวลา 100 วินาที แต่ถ้า Consumer ประมวลผลได้ 100 ชิ้นต่อวินาที งานมันก็จบใน 1 วินาที — Lag เท่ากันแต่ประสบการณ์ผู้ใช้ต่างกันราวฟ้ากับเหว นี่คือช่องโหว่ที่บทความนี้ชวนให้เรากลับมาคิดใหม่
ในระบบ Data Lake ขนาดใหญ่ที่ใช้ Hudi เป็น storage layer ชีวิตมันไม่ได้จบแค่ "อ่านจาก Kafka แล้วเขียนลง Hudi" เพราะ Hudi มีความซับซ้อนในชั้นของมันเอง ทั้งการจัดการ file versions, การทำ clustering, การ clean up ไฟล์เก่า หรือแม้แต่ compaction ของ Mor (Merge-on-Read) — แต่ละขั้นตอนใช้เวลาไม่เท่ากัน และที่สำคัญมันไม่ได้วิ่งขนานกันตลอดเวลา ต่อให้ Kafka Lag เป็นศูนย์ ข้อมูลก็อาจจะยังไม่อยู่ในสถานะที่ query ได้จริงเพราะติดค้างอยู่ในกระบวนการเหล่านี้
ประเด็นคือ ถ้าเราใช้แค่ Offset Lag เป็นตัวบอก "สุขภาพ" ของระบบ เราจะเห็นภาพลวงตาว่าทุกอย่างโอเค ทั้งที่ความจริงข้อมูลมันไปติดแหง็กอยู่ที่ขั้นตอนอื่น วิธีที่บทความนี้เสนอคือการเปลี่ยนความคิดจากการวัด "จำนวน" ไปเป็นการวัด "เวลา" — โดยเฉพาะการคำนวณ "Time in Queue" หรือเวลาที่ข้อมูลแต่ละชิ้นรออยู่ในคิวก่อนจะถูกประมวลผลเสร็จสมบูรณ์ ซึ่งเป็นตัวชี้วัดที่ตรงกับความรู้สึกของผู้ใช้งานจริงๆ มากกว่า
แทนที่จะมัวจ้องว่า Kafka Lag เป็นเท่าไหร่ บทความนี้เสนอให้เรามองภาพรวมของ pipeline ทั้งหมดเป็นระบบคิว (Queueing System) โดยมองว่าแต่ละขั้นตอนมีทั้ง "เวลารอคอย" และ "เวลาประมวลผล" รวมกันเป็นเวลาที่ข้อมูลกว่าจะพร้อมใช้งานจริง การมอนิเตอร์แบบนี้ทำให้เราเห็นคอขวด (bottleneck) ที่แท้จริงของระบบ ไม่ใช่แค่จุดที่เห็นชัดเจนที่สุด
ที่สำคัญไปกว่านั้นคือการใช้หลักการของ Little's Law ซึ่งเป็นสูตรพื้นฐานในทฤษฎีคิว มาใช้คำนวณหาความสัมพันธ์ระหว่างจำนวนข้อมูลในระบบ (Work in Progress) กับอัตราการประมวลผล (Throughput) เพื่อหาค่าเวลาที่ข้อมูลใช้ในระบบทั้งหมด สูตรนี้ช่วยให้เราคาดการณ์ได้ว่า ถ้าเร่ง throughput ได้เท่านี้ เวลารอคอยจะลดลงเท่าไหร่ — ซึ่งเป็นข้อมูลที่เอาไปคุยกับฝ่าย business ได้เป็นเรื่องเป็นราว ไม่ใช่แค่พูดว่า "lag เยอะ" แล้วจบ
การลงรายละเอียดในบทความยังครอบคลุมถึงการจัดการกับ Hudi ในส่วนของ timeline service และการทำ archival ของ metadata ซึ่งเป็นจุดที่หลายทีมมองข้าม แต่กลายเป็นคอขวดใหญ่เมื่อข้อมูลโตถึงระดับ petabyte เพราะ metadata ที่ไม่ถูกจัดการอย่างเหมาะสมจะทำให้การ query ช้าลงโดยที่เราไม่รู้ตัว และการมอนิเตอร์แบบ Time in Queue จะช่วยจับจุดเหล่านี้ได้แม่นยำกว่าเดิม
มอง Lag เป็นอาการ ไม่ใช่โรค
Offset Lag สูงคืออาการบอกว่ามีปัญหา แต่ต้นเหตุอาจอยู่ที่ Hudi compaction, clustering, หรือแม้แต่ schema evolution ที่ช้า — ต้องหาจุดที่แท้จริงให้เจอ
ใช้ Little's Law เป็นอาวุธลับ
สูตร WIP = Throughput × Cycle Time ช่วยให้เราแปลง "จำนวนข้อมูลค้าง" เป็น "เวลาที่ผู้ใช้ต้องรอ" ซึ่งเป็นภาษาที่ทุกแผนกเข้าใจตรงกัน
มอนิเตอร์ทั้งระบบ ไม่ใช่จุดเดียว
การมองแค่ Kafka Lag เหมือนการตรวจโรคที่วัดแค่อุณหภูมิ แต่ไม่ได้เช็คว่ามันคือไข้หวัดหรือไข้เลือดออก — ต้องดูหลายจุดประกอบกัน
สิ่งที่ผมชอบที่สุดในบทความนี้คือการย้ำว่า "ตัวชี้วัดที่ดีต้องสะท้อนประสบการณ์ของผู้ใช้จริงๆ" ไม่ใช่ตัวเลขเทคนิคที่ดูดีใน dashboard แต่ไม่มีความหมายกับคนที่รอข้อมูลไปทำรายงานส่งเจ้านาย การเปลี่ยนวิธีคิดจาก "เราผลิตข้อมูลได้เท่าไหร่" เป็น "ข้อมูลใช้เวลานานแค่ไหนกว่าจะถึงมือผู้ใช้" คือก้าวสำคัญของการทำ Data Engineering ที่โตเป็นผู้ใหญ่
เลิกมัวจ้อง Offset Lag แล้วหันมาคิดเรื่อง Time in Queue กันเถอะ — เพราะท้ายที่สุดแล้ว ผู้ใช้ไม่ได้สนใจว่าข้อมูลค้างอยู่กี่ล้าน record เขาสนใจแค่ว่าข้อมูลจะพร้อมใช้เมื่อไหร่ และถ้าคุณยังตอบคำถามนี้ไม่ได้ ระบบคุณก็ยังไม่ดีพอ
ที่มา: InfoQ — อ่านต้นฉบับ
ความคิดเห็น 4
กำลังโหลดความคิดเห็น...