ชุมชน Apache Iceberg ได้รับรองข้อกำหนด V3 อย่างเป็นทางการแล้ว ซึ่งถือเป็นก้าวสำคัญสำหรับเทคโนโลยี data lakehouse อย่างไรก็ตาม การสนทนาภายในชุมชนนักพัฒนาเผยให้เห็นว่า แม้ข้อกำหนดนี้จะสัญญาว่าจะมีการปรับปรุงที่สำคัญ แต่เส้นทางสู่การนำไปใช้อย่างแพร่หลายยังเผชิญกับอุปสรรคในการนำไปใช้งานหลายประการ
คุณสมบัติหลักของ Apache Iceberg V3:
- Deletion Vectors: บิตแมปไบนารีที่ใช้การบีบอัด Roaring bitmap เพื่อการลบข้อมูลระดับแถวอย่างมีประสิทธิภาพ
- Default Column Values: การพัฒนาโครงสร้างข้อมูลแบบทันทีโดยไม่ต้องเขียนไฟล์ข้อมูลใหม่
- Row-Level Lineage: การสนับสนุนการตรวจสอบและ CDC pipeline ที่ได้รับการปรับปรุง
- Rich Data Types: ประเภทข้อมูล VARIANT สำหรับ JSON, ประเภทข้อมูล GEOMETRY/GEOGRAPHY, และ timestamps ที่มีความแม่นยำระดับนาโนวินาที
กำหนดการเปิดตัวสร้างความสับสนให้กับผู้ใช้
สมาชิกในชุมชนกำลังแสวงหาความชัดเจนเกี่ยวกับเวลาที่ฟีเจอร์ V3 จะพร้อมใช้งานจริง ข้อกำหนดได้รับการรับรองแล้ว แต่กำหนดเวลาการนำไปใช้งานยังไม่ชัดเจนสำหรับผู้ใช้หลายคน Apache Iceberg เวอร์ชัน 1.10 คาดว่าจะเป็นรุ่นแรกที่รองรับฟีเจอร์ V3 แม้ว่าความสามารถทั้งหมดจะยังไม่พร้อมใช้งานทันทีในเครื่องมือ query ต่างๆ เช่น Spark หรือ Flink ฟีเจอร์ V3 บางอย่าง รวมถึง variant types และ column lineages ได้ปรากฏในเวอร์ชัน 1.9.0 แล้ว แต่ยังไม่มีการรองรับจากเครื่องมือต่างๆ อย่างแพร่หลายสำหรับการใช้งานจริง
ไทม์ไลน์การพัฒนา:
- ข้อกำหนด V3: ได้รับการรับรองแล้ว (ปัจจุบัน)
- Apache Iceberg 1.9.0 : มีฟีเจอร์ V3 บางส่วนพร้อมใช้งาน (ประเภทตัวแปร, การติดตามต้นกำเนิดคอลัมน์)
- Apache Iceberg 1.10 : คาดว่าจะเป็นรีลีสแรกที่รองรับ V3 อย่างสมบูรณ์
- การรองรับ Query Engine: การเปิดตัวแบบค่อยเป็นค่อยไปใน Spark , Flink และ engine อื่นๆ
ความกังวลเรื่องความพร้อมของระบบนิเวศนอกเหนือจาก Java
ระบบนิเวศ Iceberg ที่กว้างขึ้นเผชิญกับความท้าทายด้านความพร้อมที่สำคัญนอกเหนือจากสภาพแวดล้อม Java การใช้งาน iceberg-rust ขาดการรองรับ HDFS ซึ่งเน้นย้ำถึงช่องว่างในไลบรารีที่ไม่ใช่ Java รูปแบบนี้สะท้อนถึงการพัฒนาในอดีตของไลบรารี Apache Arrow และ Parquet ที่ใช้เวลามากในการทำให้การใช้งานในภาษาโปรแกรมต่างๆ มีความสามารถที่เท่าเทียมกัน
API การจัดเก็บข้อมูลระดับไลบรารีมีความซับซ้อนและมักจะมีปัญหา ดูเหมือนว่าจะมีไลบรารีเพียงสามตัวที่สามารถเขียนข้อมูลไปยัง Iceberg ได้ ( Java , Python , Rust อาจจะรวม Golang ) ในขณะที่ส่วนที่เหลือจะสามารถเข้าถึงการอ่านข้อมูลเท่านั้น
ความซับซ้อนของ API การจัดเก็บข้อมูลชี้ให้เห็นว่าภาษาโปรแกรมจำนวนจำกัดเท่านั้นที่อาจจะมีความสามารถในการเขียนข้อมูลได้อย่างเต็มรูปแบบ ซึ่งอาจจะจำกัดการนำเทคโนโลยีนี้ไปใช้ในสภาพแวดล้อมการพัฒนาที่หลากหลาย
สถานะการรองรับภาษาโปรแกรม:
- คาดว่าจะรองรับการเขียนแบบเต็มรูปแบบ: Java, Python, Rust และอาจรวมถึง Go
- การรองรับแบบจำกัด: ภาษาอื่น ๆ ส่วนใหญ่น่าจะเข้าถึงได้แบบอ่านอย่างเดียว
- ข้อจำกัดที่ทราบแล้ว: iceberg-rust ยังไม่รองรับ HDFS
- เอกสารประกอบ: มีเอกสาร API สำหรับ Java เป็นหลัก
ปัญหาความชัดเจนของเอกสารและข้อกำหนด
ความคิดเห็นจากชุมชนระบุว่าเอกสารข้อกำหนด V3 ต้องการการปรับปรุงเพื่อให้เข้าถึงได้ง่ายขึ้น ในขณะที่นักพัฒนาบางคนพบว่าข้อกำหนด Iceberg ชัดเจนกว่าทางเลือกอื่นๆ เช่น เอกสารโปรโตคอลของ Delta Lake คนอื่นๆ ชี้ให้เห็นถึงความจำเป็นในการมีข้อกำหนดที่อ่านง่ายกว่าเอกสาร Java API ปัจจุบัน ช่องว่างในเอกสารนี้อาจทำให้ความพยายามในการนำไปใช้งานในแพลตฟอร์มและภาษาโปรแกรมต่างๆ ช้าลง
คำถามเรื่องความพร้อมในการใช้งานจริงยังไม่ได้รับคำตอบ
แม้จะมีความสัญญาทางเทคนิคของฟีเจอร์ V3 เช่น deletion vectors และ default column values แต่ชุมชนยังขาดรายงานประสบการณ์การใช้งานจริงที่เป็นรูปธรรม ผู้ใช้กระตือรือร้นที่จะเข้าใจผลกระทบต่อประสิทธิภาพในโลกแห่งความเป็นจริง แต่ข้อมูลการทดสอบการใช้งานจริงที่ครอบคลุมยังมีจำกัดเนื่องจากการนำไปใช้งานยังคงเปิดตัวอยู่
การรับรอง Apache Iceberg V3 แสดงถึงความก้าวหน้าที่สำคัญสำหรับเทคโนโลยี data lakehouse แต่การสนทนาในชุมชนเน้นย้ำว่าการอนุมัติข้อกำหนดเป็นเพียงจุดเริ่มต้นของการเดินทางการนำไปใช้งานและการยอมรับที่ยาวนานกว่า
อ้างอิง: A Deeper Dive into Apache Iceberg V3: How New Designs Are Solving Core Data Lake Challenges
 |
|---|
| ภาพนี้เน้นให้เห็นบล็อกโพสต์ที่อภิปรายเกี่ยวกับการออกแบบใหม่ใน Apache Iceberg V3 ซึ่งแสดงให้เห็นโซลูชันสำหรับความท้าทายหลักของ data lake |