3 คะแนน โดย GN⁺ 2023-08-09 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • บทความนี้แนะนำ WarpStream ซึ่งเป็นแพลตฟอร์มสตรีมมิงข้อมูลที่เข้ากันได้กับโปรโตคอล Kafka และสร้างขึ้นโดยตรงบน S3
  • WarpStream มาในรูปแบบ Go binary เดียวแบบ stateless ทำให้ไม่จำเป็นต้องจัดการ local disk, การ rebalance broker และการดูแล ZooKeeper
  • แพลตฟอร์มนี้ลดต้นทุนโครงสร้างพื้นฐานลงอย่างมากด้วยการสตรีมข้อมูลไปยัง S3 โดยตรง และมีค่าใช้จ่ายถูกกว่า Kafka บนคลาวด์ 5-10 เท่า
  • บทความนี้วิจารณ์ความเหมาะสมของ Kafka ต่อ workload สมัยใหม่ โดยเน้นถึงค่าใช้จ่ายด้าน inter-AZ bandwidth ที่สูงและภาระด้านการดำเนินงาน
  • สถาปัตยกรรมของ WarpStream แตกต่างจาก Kafka แทนที่จะใช้ broker ระบบจะมี "agent" แบบ stateless ที่สามารถทำหน้าที่เป็น "leader" ของ topic ใดก็ได้, commit offset ให้ consumer group ใดก็ได้ หรือทำหน้าที่เป็น coordinator ของคลัสเตอร์
  • ใน WarpStream พื้นที่จัดเก็บทั้งหมดถูก offload ไปยัง object storage อย่าง S3 ทำให้ขยายระบบได้ง่ายและกู้คืนจากความล้มเหลวได้รวดเร็ว
  • WarpStream แยกข้อมูลออกจาก metadata และจัดเก็บ metadata ของ "virtual cluster" ทั้งหมดไว้ในฐานข้อมูล metadata แบบกำหนดเอง
  • แพลตฟอร์มนี้ช่วยลด total cost ของ workload Kafka ส่วนใหญ่ได้ 5-10 เท่าอย่างมาก แต่มี latency สูงกว่า โดย P99 ของคำขอจาก producer อยู่ที่ประมาณ 400ms และ latency จาก producer ถึง consumer อยู่ที่ประมาณ 1 วินาที
  • ขณะนี้ WarpStream อยู่ในขั้น developer preview และยังไม่พร้อมสำหรับการใช้งานจริงใน production
  • ผู้สร้าง WarpStream มองว่า developer UX ของ Kafka เป็นปัญหา โดยเฉพาะ abstraction ระดับต่ำของ partition และพวกเขาวางแผนจะแก้ไขเรื่องนี้ในการอัปเดตของ WarpStream ในอนาคต
  • บทความนี้ปิดท้ายด้วยการเชิญชวนให้ผู้อ่านลองใช้ WarpStream และส่ง feedback กลับมา

1 ความคิดเห็น

 
GN⁺ 2023-08-09
ความเห็นจาก Hacker News
  • บทความเกี่ยวกับลักษณะสองด้านของ Kafka ซึ่งเป็นเทคโนโลยี data streaming
  • มีการถกเถียงกันว่าบริษัทเทคโนโลยีส่วนใหญ่ใช้ Kafka หรือไม่
  • ประเด็นเรื่องความคุ้มค่าด้านต้นทุนของการ push แต่ละข้อความไปยัง S3 โดยตรง และปัญหาของการรันคลัสเตอร์ Kafka ในแต่ละ AZ
  • การแนะนำโดย Ryan Worl ผู้ร่วมก่อตั้งและ CTO ของ WarpStream ซึ่งเป็นระบบสตรีมมิงที่เข้ากันได้กับโปรโตคอล Kafka และสร้างอยู่บน S3 โดยตรง
  • เน้นย้ำเรื่องความคุ้มค่าด้านต้นทุนของ WarpStream การไม่จำเป็นต้องดูแลดิสก์/โหนดที่มี state ไม่ต้องทำ data rebalancing หรือใช้ ZooKeeper และลดค่าบริการแบนด์วิดท์ข้าม AZ
  • วิจารณ์ต้นทุนของการรัน Kafka บน VM แยกต่างหากในผู้ให้บริการคลาวด์
  • การพูดคุยเรื่องการใช้ storage adapter ในบริการจัดการ Hadoop/Kafka บนคลาวด์ที่ออกแบบมาอย่างเหมาะสมเพื่อใช้ประโยชน์จากความซ้ำซ้อนของผู้ให้บริการ
  • ผู้ใช้บางส่วนบ่นถึงข้ออ้างในบทความที่ว่า Kafka ต้องการทีมผู้เชี่ยวชาญและงบประมาณจำนวนมาก
  • เน้นย้ำว่าจริง ๆ แล้วสามารถเปลี่ยนจำนวนพาร์ทิชันใน Kafka ได้
  • มีการโต้แย้งข้ออ้างในบทความที่ว่าการดูแล Kafka ต้องใช้ทีมวิศวกรขนาดใหญ่
  • มีคำถามเกี่ยวกับวิธีที่ WarpStream จัดการบริการ ใช้ผู้ให้บริการคลาวด์หรือ bare metal และใช้ foundationdb สำหรับ metadata store หรือไม่
  • การพูดคุยเกี่ยวกับศักยภาพของ API ของ Kafka และความเป็นไปได้ในการซ่อนความซับซ้อนของการจัดการคลัสเตอร์
  • การลดต้นทุนจากการย้ายทราฟฟิก ML ขนาดใหญ่ไปยัง S3 โดยผู้ใช้คนหนึ่งรายงานว่าสามารถลดต้นทุนได้ประมาณ 90%
  • มีการเสนอให้เปลี่ยนชื่อบทความเป็น "Kafka ตายแล้ว ขอให้ Warpstream ผู้เป็นราชามีชีวิตยืนยาว" เพื่อสะท้อนการมาถึงของเทคโนโลยีใหม่