StreamNative ได้เปิดตัว Ursa Engine แพลตฟอร์มสตรีมมิงข้อมูลใหม่ที่สัญญาว่าจะลดต้นทุนได้อย่างมากเมื่อเทียบกับการใช้งาน Apache Kafka แบบดั้งเดิม บริษัทอ้างว่าธุรกิจสามารถลดต้นทุนได้ถึง 95% และมีความเร็วในการขยายระบบเร็วขึ้น 1000 เท่า ขณะที่ยังคงความเข้ากันได้กับ Kafka API อย่างสมบูรณ์ อย่างไรก็ตาม การประกาศนี้ได้จุดประกายการถกเถียงอย่างเข้มข้นภายในชุมชนนักพัฒนาเกี่ยวกับความแม่นยำของเบนช์มาร์กและลักษณะที่เป็นกรรมสิทธิ์ของแพลตฟอร์ม
การเปรียบเทียบต้นทุน:
- Ursa : $50 USD ต่อชั่วโมงสำหรับ workloads GB/s
- อ้างว่าลดต้นทุนได้: สูงสุด 95% เมื่อเทียบกับ Kafka แบบดั้งเดิม
- การปรับปรุงประสิทธิภาพ: การขยายระบบเร็วขึ้น 1000 เท่า, throughput สูงขึ้น 2.5 เท่า
- อิงจากการ deployment แบบ multi-zone บน AWS โดยไม่ใช้ tiered storage
 |
|---|
| กราฟิกนี้แสดงให้เห็นถึงความซับซ้อนและต้นทุนที่ซ่อนอยู่ซึ่งเกี่ยวข้องกับการใช้งาน Kafka แบบดั้งเดิม เพื่อเป็นบริบทสำหรับการอ้างเรื่องต้นทุนของ Ursa Engine |
การอ้างเรื่องการลดต้นทุนเผชิญกับการตรวจสอบ
การอ้างที่สะดุดตามากที่สุดคือการใช้งาน Kafka ที่มีปริมาณการประมวลผลสูงด้วยราคาเพียง 50 ดอลลาร์สหรัฐต่อชั่วโมงสำหรับการประมวลผลกิกะไบต์ต่อวินาที StreamNative ได้เผยแพร่การเปรียบเทียบต้นทุนโดยละเอียดที่แสดงให้เห็นว่าการใช้งาน Kafka ที่มีปริมาณ 5 GB/s จะถูกกว่าอย่างมากบน Ursa เมื่อเทียบกับคู่แข่งอย่าง WarpStream, Amazon MSK และ Redpanda การวิเคราะห์นี้สมมติการใช้งานแบบหลายโซนบน AWS โดยไม่เปิดใช้งาน tiered storage
อย่างไรก็ตาม ผู้เชี่ยวชาญในอุตสาหกรรมกำลังโต้แย้งตัวเลขเหล่านี้ พนักงานของ Redpanda ได้ชี้ให้เห็นข้อบกพร่องที่อาจเกิดขึ้นในวิธีการเบนช์มาร์ก โดยเฉพาะเรื่องต้นทุนการรับส่งข้อมูลข้าม availability zone พวกเขาระบุว่าด้วยการปรับรูปแบบการรับส่งข้อมูลที่เหมาะสมและฟีเจอร์ follower fetching ความแตกต่างของต้นทุนที่อ้างไว้อาจลดลงได้อย่างมาก และเรียกการเปรียบเทียบนี้ว่าเป็นการทำเบนช์มาร์กเพื่อการตลาดที่ไม่สุจริต
 |
|---|
| ภาพนี้แสดงแนวคิดเกี่ยวกับการวิเคราะห์การลดต้นทุนและข้อผิดพลาดที่อาจเกิดขึ้นในการเปรียบเทียบประสิทธิภาพของ Ursa Engine กับคู่แข่ง |
สถาปัตยกรรมแบบไร้ผู้นำและคำถามต่างๆ
นวัตกรรมหลักของ Ursa อยู่ที่สถาปัตยกรรมแบบไร้ผู้นำที่แยก metadata ออกจากการจัดเก็บข้อมูล ไม่เหมือนกับการใช้งาน Kafka แบบดั้งเดิมที่ต้องการโปรโตคอลฉันทามติแบบมีผู้นำ Ursa อ้างว่าสามารถขจัดความจำเป็นในการส่งข้อมูลผ่าน lead broker เดียว การออกแบบนี้คาดว่าจะลดการรับส่งข้อมูลข้ามโซนที่มีราคาแพงซึ่งทำให้ต้นทุนในการใช้งานแบบหลาย availability zone เพิ่มขึ้น
ชุมชนด้านเทคนิคยังคงสงสัยเกี่ยวกับวิธีการทำงานของแนวทางแบบไร้ผู้นำนี้ นักพัฒนาที่คุ้นเคยกับโปรโตคอลฉันทามติระบุว่าทั้ง Kafka และ Pulsar ต่างพึ่งพาระบบแบบมีผู้นำเพื่อให้การรับประกันของพวกเขา ทำให้เกิดคำถามเกี่ยวกับการแลกเปลี่ยนที่ Ursa ทำเพื่อให้ได้การออกแบบแบบไร้ผู้นำ StreamNative อธิบายว่าพวกเขาใช้ Apache BookKeeper สำหรับงานที่ต้องการความล่าช้าต่ำและ object storage สำหรับสถานการณ์ที่เน้นการประหยัดต้นทุน
หมายเหตุ: โปรโตคอลฉันทามติคือวิธีการที่ช่วยให้ระบบแบบกระจายสามารถตกลงเรื่องความสอดคล้องของข้อมูลและการเรียงลำดับข้ามเซิร์ฟเวอร์หลายตัว
สถาปัตยกรรมทางเทคนิค:
- การออกแบบแบบไร้ผู้นำ: ขจัดการกำหนดเส้นทางของ lead broker เดี่ยว
- ตัวเลือกการจัดเก็บข้อมูล: Object storage ( AWS S3 , GCP GCS , Azure Blob ) สำหรับการปรับปรุงต้นทุน; Apache BookKeeper สำหรับงานที่ต้องการความหน่วงต่ำ
- การรวมเข้ากับ Lakehouse : รองรับรูปแบบ Apache Iceberg และ Delta Lake แบบดั้งเดิม
- การรองรับโปรโตคอล: ความเข้ากันได้กับ Kafka API แบบเต็มรูปแบบ รวมถึงโปรโตคอล Apache Pulsar
คำสัญญาโอเพนซอร์สเผชิญกับความสงสัยของชุมชน
บางทีประเด็นที่ถกเถียงกันมากที่สุดคือสถานะที่เป็นกรรมสิทธิ์ในปัจจุบันของ Ursa แพลตฟอร์มนี้มีให้บริการผ่านคลาวด์เซอร์วิสของ StreamNative เท่านั้น แม้ว่าผู้ร่วมก่อตั้ง Sijie Guo จะสัญญาว่าจะเปิดซอร์สส่วนประกอบหลักในเร็วๆ นี้ สิ่งนี้ได้กระตุ้นความกังวลที่คุ้นเคยในชุมชนนักพัฒนาเกี่ยวกับบริษัทที่ใช้คำสัญญาโอเพนซอร์สเพื่อการตลาดขณะที่ยังคงการควบคุมแบบกรรมสิทธิ์
ผู้คนสงสัยเรื่องการถูกหลอก มีหลายกรณีในอดีตที่บริษัทต่างๆ โฆษณาด้วย FOSS แต่ไม่ได้หมายความจริงๆ
ความระแวงของชุมชนเกิดจากประสบการณ์ซ้ำๆ กับบริษัทที่เริ่มแรกสัญญาว่าจะเปิดซอร์สแต่ต่อมาเปลี่ยนทิศทาง นักพัฒนาสนใจโดยเฉพาะในความสามารถในการ self-hosting โดยเชื่อว่าพวกเขาสามารถบรรลุต้นทุนที่ต่ำกว่าได้ด้วยการใช้งานโดยตรงบนโครงสร้างพื้นฐานคลาวด์แทนที่จะผ่านบริการที่จัดการโดย StreamNative
การรวม Lakehouse ทำให้ Ursa แตกต่าง
นอกเหนือจากการอ้างเรื่องต้นทุน Ursa ทำให้ตัวเองแตกต่างผ่านการรวมกับสถาปัตยกรรม lakehouse อย่างเป็นธรรมชาติ แพลตฟอร์มจัดเก็บข้อมูลโดยตรงในรูปแบบตารางเปิดอย่าง Apache Iceberg และ Delta Lake ขจัดความจำเป็นในการใช้ connector แยกต่างหากและลดการทำซ้ำของข้อมูลระหว่างระบบสตรีมมิงและระบบวิเคราะห์ การรวมกับส่วนประกอบของ modern data stack อย่าง Snowflake's Open Catalog นี้แสดงถึงการเปลี่ยนแปลงทางสถาปัตยกรรมที่สำคัญจากแพลตฟอร์มสตรีมมิงแบบดั้งเดิม
จังหวะเวลาสอดคล้องกับแนวโน้มในอุตสาหกรรมที่กว้างขึ้นไปสู่สถาปัตยกรรมฐานข้อมูลที่ใช้ object storage เป็นฐาน คล้ายกับที่ Snowflake ปฏิวัติการจัดเก็บข้อมูลด้วยการใช้ object storage ในปี 2016 แพลตฟอร์มสตรีมมิงตอนนี้กำลังตามรอยเท้า Ursa เข้าร่วมกับโซลูชันสตรีมมิงที่ใช้ object storage อื่นๆ อย่าง AutoMQ และ WarpStream ที่ถูกยกเลิกแล้วในหมวดหมู่ที่กำลังเกิดขึ้นนี้
ภูมิทัศน์การแข่งขัน:
- คู่แข่งโดยตรง: WarpStream (ยกเลิกแล้ว), AutoMQ, Amazon MSK, Redpanda
- ตำแหน่งในตลาด: แพลตฟอร์มสตรีมมิงที่ใช้ object storage เป็นฐาน
- ความพร้อมใช้งาน: ปัจจุบันใช้งานได้เฉพาะบนคลาวด์ผ่าน StreamNative เท่านั้น มีการสัญญาว่าจะมีเวอร์ชัน open source
- การรองรับคลาวด์: AWS, Google Cloud Platform, Microsoft Azure
 |
|---|
| กราฟิกนี้แสดงให้เห็นกระบวนการย้ายข้อมูลจากบริการ Kafka ไปยัง Ursa Engine ของ StreamNative โดยแสดงให้เห็นการเปลี่ยนผ่านไปสู่สถาปัตยกรรมข้อมูลแบบใหม่ |
บทสรุป
Ursa Engine แสดงถึงความพยายามที่ทะเยอทะยานในการคิดสถาปัตยกรรมโครงสร้างพื้นฐานการสตรีมข้อมูลใหม่สำหรับยุคคลาวด์ แม้ว่าการประหยัดต้นทุนที่สัญญาไว้และนวัตกรรมทางสถาปัตยกรรมจะน่าสนใจ แต่แพลตฟอร์มเผชิญกับคำถามที่ถูกต้องเกี่ยวกับวิธีการเบนช์มาร์กและความมุ่งมั่นต่อโอเพนซอร์สในระยะยาว ขณะที่ตลาดข้อมูลสตรีมมิงยังคงพัฒนาไปสู่การรวม object storage และ lakehouse ความสำเร็จของ Ursa น่าจะขึ้นอยู่กับการส่งมอบการเปรียบเทียบประสิทธิภาพที่โปร่งใสและการปฏิบัติตามคำสัญญาโอเพนซอร์ส ชุมชนนักพัฒนายังคงมองในแง่ดีอย่างระมัดระวัง แต่เห็นได้ชัดว่าคาดหวังหลักฐานที่เป็นรูปธรรมมากกว่านี้ก่อนการใช้งานอย่างแพร่หลาย
อ้างอิง: Ursa Engine