Apache Iceberg กลายเป็นหัวข้อร้อนแรงในโครงสร้างพื้นฐานข้อมูล แต่ความท้าทายทางเทคนิคที่สำคัญกำลังก่อให้เกิดการอภิปรายอย่างเข้มข้นในหมู่นักพัฒนา ปัญหาหลักมุ่งเน้นไปที่วิธีการจัดการการดำเนินการลบอย่างมีประสิทธิภาพเมื่อสตรีมการเปลี่ยนแปลงแบบเรียลไทม์จากฐานข้อมูลแบบดั้งเดิมอย่าง Postgres เข้าสู่ระบบจัดเก็บข้อมูลที่เน้นการวิเคราะห์ของ Iceberg
ปัญหาหลักทางเทคนิค
เมื่อบริษัทต่างๆ ต้องการมิเรอร์การเปลี่ยนแปลงฐานข้อมูล Postgres เข้าสู่ Apache Iceberg สำหรับการวิเคราะห์ พวกเขาต้องเผชิญกับการเลือกพื้นฐานระหว่างกลไกการลบสองแบบ Position deletes ทำงานโดยการระบุตำแหน่งไฟล์ที่แน่นอนและหมายเลขแถว ให้ประสิทธิภาพการสืบค้นที่ยอดเยี่ยมเนื่องจากระบบสามารถข้ามแถวได้โดยไม่ต้องอ่าน อย่างไรก็ตาม วิธีการนี้ต้องการทราบตำแหน่งการจัดเก็บทางกายภาพล่วงหน้า ซึ่งสร้างคอขวดสำคัญสำหรับสถานการณ์สตรีมมิ่งแบบเรียลไทม์
ในทางกลับกัน Equality deletes ทำงานโดยการจับคู่ค่า primary key แทนที่จะเป็นตำแหน่งทางกายภาพ วิธีการนี้เข้ากันได้อย่างเป็นธรรมชาติกับระบบ Change Data Capture (CDC) ที่สตรีมการเปลี่ยนแปลงฐานข้อมูล แต่มันบังคับให้การสืบค้นต้องดำเนินการ merge-on-read สแกนทั้งไฟล์ข้อมูลและไฟล์การลบเพื่อกรองเรคคอร์ดที่ถูกลบออก
การเปรียบเทียบกลไก Iceberg Delete
| ประเภทการลบ | กลไกการทำงาน | ประสิทธิภาพ Query | ความเข้ากันได้กับ CDC | ความซับซ้อนในการเขียน |
|---|---|---|---|---|
| Position Deletes | เส้นทางไฟล์ + หมายเลขแถว | สูง (สามารถข้ามแถวได้) | แย่ (ต้องค้นหาตำแหน่ง) | สูง (ต้องการตำแหน่งทางกายภาพ) |
| Equality Deletes | การจับคู่ primary key | ต่ำกว่า (ต้อง merge-on-read) | ยอดเยี่ยม (เข้ากันได้ตามธรรมชาติ) | ต่ำ (โดยตรงจาก CDC stream) |
ชุมชนผลักดันการตั้งสมมติฐานสถาปัตยกรรม
ชุมชนทางเทคนิคได้ตั้งคำถามสำคัญเกี่ยวกับการเลือกสถาปัตยกรรมพื้นฐาน นักพัฒนาคนหนึ่งชี้ให้เห็นถึงโซลูชันที่ดูเหมือนชัดเจนที่อุตสาหกรรมดูเหมือนจะมองข้าม: การรักษาการแมประหว่างแถว Postgres และตำแหน่ง Iceberg เนื่องจากกระบวนการ CDC ต้องการรักษาสถานะอยู่แล้ว ทำไมไม่เก็บการแมปทั้งหมด? ขนาดจะเทียบเท่ากับดัชนีเดียวของฐานข้อมูล และการอัปเดตจะเร็วกว่าตาราง Postgres ต้นทาง
การแมปที่ต้องการจะมีขนาดประมาณเท่ากับดัชนีเดียวในตาราง ทำไมไม่เก็บมันไว้ที่ไหนสักแห่ง? การอัปเดตจะเร็วกว่าการอัปเดตตาราง Postgres ต้นทาง ดังนั้นมันจะตามทัน
การตั้งคำถามเกี่ยวกับแนวทางพื้นฐาน
ผู้เชี่ยวชาญบางคนโต้แย้งว่าไปป์ไลน์ Postgres-to-Iceberg ทั้งหมดแสดงถึงการตัดสินใจสถาปัตยกรรมที่มีข้อบกพร่อง พวกเขาโต้แย้งว่าการใช้ CDC เพื่อสร้างสแนปช็อตตารางใหม่โดยการใช้ตรรกะ merge-on-read นอกฐานข้อมูลนั้นพลาดจุดประสงค์ของสิ่งที่ CDC ถูกออกแบบมา CDC เป็นเลิศในการจับและประมวลผลการเปลี่ยนแปลงแต่ละรายการแยกกัน ไม่ใช่ในการรักษาการจำลองตารางที่สมบูรณ์
การวิจารณ์ขยายไปถึงการเลือกใช้ Iceberg เองสำหรับกรณีการใช้งานนี้ ในฐานะระบบจัดเก็บแบบคอลัมน์ที่ปรับให้เหมาะสมสำหรับการวิเคราะห์ประวัติศาสตร์ขนาดใหญ่ Iceberg ไม่ได้ถูกออกแบบสำหรับข้อมูลเชิงสัมพันธ์หรือการดำเนินการแบบเรียลไทม์ นักวิจารณ์แนะนำว่าฐานข้อมูลอนุกรมเวลาอย่าง TimescaleDB หรือ InfluxDB จะเหมาะสมกว่าสำหรับปริมาณงานเหล่านี้
คำถามเรื่องความเป็นผู้ใหญ่และความเป็นจริงในการใช้งาน
การอภิปรายยังเน้นย้ำความกังวลเกี่ยวกับการอ้างความเป็นผู้ใหญ่ของ Apache Iceberg ในขณะที่การใช้งาน Java มีมาหลายปีแล้ว ไลบรารีภาษาอื่นๆ ล้าหลังอย่างมีนัยสำคัญ ไลบรารี Rust เพิ่งได้รับความสามารถในการเขียน และเนื่องจากไม่มีเซิร์ฟเวอร์ Iceberg กลาง ไลบรารีเหล่านี้จึงเป็นผลิตภัณฑ์ทั้งหมดเมื่อโต้ตอบกับระบบจัดเก็บอย่าง Amazon S3
การสนับสนุนเครื่องมือสืบค้นสำหรับ equality deletes ยังคงไม่สอดคล้องกันทั่วระบบนิเวศ ในขณะที่เครื่องมือบางตัวให้การสนับสนุน Iceberg อย่างเต็มรูปแบบผ่านการรวมแบบเนทีฟ อื่นๆ อาศัยแคตตาล็อกภายนอกอย่าง AWS Glue และอาจสนับสนุนเฉพาะ position deletes หรือขาดการจัดการไฟล์การลบที่เชื่อถือได้
สถานะการรองรับของ Query Engine
การรองรับ Iceberg แบบเต็มรูปแบบ:
- การใช้งาน Iceberg แบบ Native ที่มีการจัดการ metadata อย่างสมบูรณ์
- รองรับทั้ง position และ equality deletes
การรองรับแบบจำกัด:
- Engine ที่ใช้ external catalog (เช่น AWS Glue )
- อาจรองรับเพียง position deletes เท่านั้น
- การจัดการ delete file ที่ไม่สม่ำเสมอ
ไม่รองรับ:
- Amazon Redshift (ไม่สามารถเขียนได้ ไม่รองรับ delete file)
- ผู้ให้บริการ data lake หลายรายที่มีการใช้งานไม่สมบูรณ์
รูปแบบที่กว้างขึ้น
ความท้าทายทางเทคนิคนี้สะท้อนแนวโน้มที่ใหญ่กว่าในโลกโครงสร้างพื้นฐานข้อมูล บริษัทต่างๆ พยายามเชื่อมช่องว่างระหว่างฐานข้อมูลธุรกรรมแบบดั้งเดิมและระบบวิเคราะห์สมัยใหม่ มักจะค้นพบว่าจุดรวมมีความซับซ้อนมากกว่าที่คาดไว้ในตอนแรก ปัญหา equality delete ใน Iceberg ทำหน้าที่เป็นการเตือนใจว่าแม้แต่เทคโนโลยีที่ดูเหมือนเป็นผู้ใหญ่ก็สามารถมีข้อจำกัดพื้นฐานเมื่อนำไปใช้กับกรณีการใช้งานที่พวกเขาไม่ได้ถูกออกแบบมาเพื่อจัดการในตอนแรก
การอภิปรายที่กำลังดำเนินอยู่แนะนำว่าในขณะที่ Apache Iceberg ยังคงได้รับการยอมรับ ชุมชนยังคงทำงานผ่านความท้าทายเชิงปฏิบัติของการใช้งานในโลกแห่งความเป็นจริง โดยเฉพาะอย่างยิ่งเมื่อเกี่ยวกับสถานการณ์การรวมข้อมูลแบบเรียลไทม์