- วงการการจัดการข้อมูลกำลังเปลี่ยนแปลงอย่างรวดเร็ว และจากการเติบโตของคลาวด์สตอเรจและความต้องการการวิเคราะห์แบบเรียลไทม์ ทำให้แนวคิด Data Lakehouse กำลังได้รับความสนใจ
- โปรเจ็กต์อย่าง Apache Iceberg, Apache Hudi และ Delta Lake ได้มอบความสามารถหลักให้กับสถาปัตยกรรม Lakehouse เช่น schema evolution, ธุรกรรม ACID และการอัปเดตอย่างมีประสิทธิภาพ
- Napa ซึ่งเป็นระบบภายในของ Google นำเสนอแนวทางที่ก้าวล้ำไปกว่าระบบ Lakehouse ในปัจจุบัน
- ยิ่งไปกว่านั้น ยังมีการเสนอ LakeDB ซึ่งเป็นรูปแบบถัดไปของ Lakehouse โดยผสานแนวคิดจากระบบอื่นอย่าง Apache Pinot
สภาพแวดล้อม Lakehouse ปัจจุบัน: Iceberg, Hudi, Delta Lake
- Apache Iceberg
- รองรับ schema evolution, time travel และการวางแผนคิวรีอย่างมีประสิทธิภาพด้วยการจัดการเมทาดาทาที่ละเอียด
- มอบการรับประกันความสอดคล้องสำหรับชุดข้อมูลเชิงวิเคราะห์ขนาดใหญ่
- Apache Hudi
- ใช้สตอเรจแบบ log-structured และการทำดัชนีเพื่อจัดการ upsert, delete และ CDC (การดักจับการเปลี่ยนแปลงข้อมูล) ได้อย่างมีประสิทธิภาพ
- เน้นเรื่องการเปลี่ยนแปลงข้อมูลและการประมวลผลแบบ incremental
- Delta Lake
- มอบธุรกรรม ACID สำหรับ Spark และเวิร์กโหลดบิ๊กดาต้า
- รองรับ schema validation, time travel และการประมวลผลแบบรวมระหว่าง batch กับ streaming
- มีการรองรับ declarative pipeline และ materialized view บางส่วนผ่าน Delta Live Tables
Napa ของ Google: แนวทางระดับมหภาค
- เป็นระบบจัดการข้อมูลเชิงวิเคราะห์แบบครบวงจร รองรับคิวรีที่มี latency ต่ำและการโหลดข้อมูลอย่างต่อเนื่องสำหรับข้อมูลขนาดใหญ่
- การโหลดข้อมูลบนพื้นฐาน LSM(Log-Structured Merge)-Tree
- เลือกใช้แนวทาง LSM-tree เพื่อให้ได้ write throughput สูง และมีโครงสร้างที่ผสานเข้ากับข้อมูลเดิมผ่านการ compaction
- การใช้ materialized view
- ดูแลและอัปเดต materialized view โดยอัตโนมัติเพื่อเร่งความเร็วคิวรี
- Queryable Timestamp(QT)
- มอบการจัดการจุดเวลาอย่างสอดคล้องกันทั้งระบบ
- สามารถปรับสมดุลระหว่างความสดใหม่ของข้อมูลกับประสิทธิภาพคิวรีได้อย่างละเอียด
- การผสานรวม F1 Query
- ใช้เอนจิน F1 Query ของ Google เพื่อประมวลผลคิวรีเชิงวิเคราะห์ที่ซับซ้อนได้อย่างมีประสิทธิภาพ
- ความสามารถในการกำหนดค่าได้สูง
- ปรับความสดใหม่ของข้อมูล ประสิทธิภาพ และต้นทุนให้เหมาะกับความต้องการของผู้ใช้ได้
เปรียบเทียบ Napa, Iceberg, Hudi, Delta Lake
- Napa เป็นระบบจัดการข้อมูลเชิงวิเคราะห์แบบครบวงจร ที่รองรับคิวรีความเร็วสูงผ่าน materialized view ที่อิง LSM และควบคุมความสดใหม่ของข้อมูลได้อย่างละเอียดด้วยเทคนิคที่เรียกว่า Queryable Timestamp(QT) เหมาะกับสถานการณ์ที่ต้องการวิเคราะห์และรายงานข้อมูลขนาดใหญ่ได้อย่างรวดเร็ว และด้วยความยืดหยุ่นในการตั้งค่าที่สูง จึงช่วยบริหารสมดุลระหว่างต้นทุน ประสิทธิภาพ และความสดใหม่ได้อย่างเหมาะสม
- Iceberg เป็นโปรเจ็กต์ที่เน้น table format โดยจัดการไฟล์ข้อมูลขนาดใหญ่ผ่านเมทาดาทา และมอบความสามารถอย่าง atomic update เหมาะกับการใช้งานในสภาพแวดล้อม data lake ที่ต้องการความสามารถอย่าง data warehousing, schema evolution และ time travel โดยตัวเลือกการตั้งค่าส่วนใหญ่จะเน้นที่ layout ของตารางหรือเมทาดาทา
- Hudi เป็นแพลตฟอร์มที่นำความสามารถแบบฐานข้อมูลมาใช้กับ data lake โดยใช้สตอเรจแบบ log-structured และเทคนิคการทำดัชนีเพื่อจัดการงานเปลี่ยนแปลงข้อมูลอย่าง upsert และ delete ได้อย่างมีประสิทธิภาพ ออกแบบมาเพื่อรองรับการโหลดข้อมูลแบบเรียลไทม์, CDC และข้อกำหนดด้านการปฏิบัติตามกฎระเบียบอย่าง GDPR ได้ดี แต่ไม่ได้มีฟังก์ชัน materialized view มาให้เป็นพื้นฐาน
- Delta Lake เป็นเลเยอร์สตอเรจที่รองรับธุรกรรม ACID โดยประมวลผลงาน batch และ streaming ร่วมกัน พร้อมทั้งรองรับ schema enforcement และ time travel เพื่อเพิ่มประสิทธิภาพคิวรีจะทำงานร่วมกับ Spark โดยใช้ data skipping และ caching และยังรองรับแนวคิดคล้าย materialized view ผ่าน Delta Live Tables มักถูกใช้เมื่ออยากเพิ่มความน่าเชื่อถือและความสามารถด้านธุรกรรมให้กับสภาพแวดล้อม data lake ที่หลากหลาย
ข้อเสนอเกี่ยวกับ LakeDB: ได้แรงบันดาลใจจาก Napa และเรียนรู้จากที่อื่น
- มีการเสนอแนวคิด LakeDB ที่รวมไอเดียนวัตกรรมจาก Napa และ Apache Pinot เป็นต้น เพื่อให้ได้ระบบจัดการข้อมูลที่บูรณาการมากขึ้นและยืดหยุ่นมากขึ้น
- LakeDB มุ่งเป็นโซลูชันจัดการข้อมูลที่เมื่อผู้ใช้ระบุความต้องการแบบ declarative (เช่น ความสดใหม่ ต้นทุน ความสอดคล้อง การใช้ดัชนี ฯลฯ) แล้ว ระบบจะทำการเพิ่มประสิทธิภาพให้โดยอัตโนมัติ
1. การบูรณาการสตอเรจ การโหลดข้อมูล เมทาดาทา และการประมวลผลคิวรี
- รวมสตอเรจ การโหลดข้อมูล เมทาดาทา และการประมวลผลคิวรีไว้ในระบบเดียว
- ผู้ใช้เพียงระบุความสดใหม่และความสอดคล้องของข้อมูล ระบบจะปรับงานที่จำเป็นให้โดยอัตโนมัติ
- ขณะที่ Iceberg, Hudi และ Delta Lake ต้องเชื่อมกับเครื่องมือแยกต่างหากในส่วนนี้ ทำให้ความซับซ้อนเพิ่มขึ้น
2. การเพิ่มประสิทธิภาพ materialized view และ layout ข้อมูลอย่างชาญฉลาด
- สลับใช้แนวทาง CoW(Copy-on-Write) และ MoR(Merge-on-Read) โดยอัตโนมัติตามเวิร์กโหลด
- สร้างและดูแล snapshot กับ materialized view อย่างเหมาะสมตามข้อกำหนดด้านประสิทธิภาพและต้นทุนที่ผู้ใช้กำหนด
- Hudi, Delta Lake และ Iceberg ส่วนใหญ่ยังต้องตั้งค่ากระบวนการนี้ด้วยตนเอง
3. การควบคุมความสดใหม่ของข้อมูลอย่างละเอียด
- เช่นเดียวกับ QT ของ Napa เมื่อผู้ใช้กำหนดระดับความสดใหม่ที่ต้องการ ระบบจะหาจุดแลกเปลี่ยนระหว่างประสิทธิภาพกับต้นทุนให้
- ระบบเดิมมักพึ่งพา snapshot แบบเป็นรอบและการมอนิเตอร์ จึงยากที่จะรับประกันความเป็นเรียลไทม์
4. การทำดัชนีและการพาร์ทิชันขั้นสูงที่ได้แรงบันดาลใจจาก Apache Pinot
- รองรับแนวทางการทำดัชนีขั้นสูงอย่าง Star-Tree เพื่อให้รองรับการวิเคราะห์ที่มี cardinality สูงได้
- มุ่งยกระดับประสิทธิภาพให้เหนือกว่าการพาร์ทิชันแบบง่ายและ data skipping ของ Iceberg และ Delta Lake
5. การกำหนดค่าที่ยืดหยุ่น
- ตารางเดียวกันสามารถถูกตั้งค่าให้เหมาะกับผู้ใช้งานหลายกลุ่มที่มีความต้องการด้านประสิทธิภาพ ต้นทุน และความสดใหม่ต่างกันได้
- ระบบเดิมมีขอบเขตการตั้งค่าจำกัด จึงต้องใช้การปรับแต่งด้วยมือจำนวนมากเพื่อรองรับเวิร์กโหลดที่หลากหลาย
6. การรองรับ ACID และ schema evolution
- สืบทอดและต่อยอดพื้นฐานด้าน ACID และ schema evolution จาก Iceberg และ Delta Lake
- มุ่งทำให้การเปลี่ยน schema พร้อมกันและการรับประกันความสอดคล้องของข้อมูลในสภาพแวดล้อมแบบกระจายเป็นแบบอัตโนมัติ
7. ความเปิดกว้างและการขยายตัว
- รองรับ open standard และการเชื่อมต่อกับ query engine ที่หลากหลาย พร้อมขยายได้ตามความจำเป็น
- ไม่ผูกติดกับ vendor หรือแพลตฟอร์มใดแพลตฟอร์มหนึ่ง และเปิดให้ประยุกต์ใช้ความสามารถต่าง ๆ ได้อย่างยืดหยุ่นตามความต้องการของผู้ใช้
เหตุผลที่ LakeDB เป็นวิวัฒนาการถัดไป
- ประสิทธิภาพ: ด้วยดัชนีขั้นสูง, materialized view และการเพิ่มประสิทธิภาพ layout ข้อมูลแบบไดนามิก ทำให้เข้าใกล้ความเร็วระดับ OLAP
- ความเรียบง่าย: มีความสามารถด้านการจัดการในระบบเดียว ผู้ใช้เพียงกำหนดความต้องการ เช่น ความสดใหม่หรือประสิทธิภาพ แล้วระบบจะปรับให้โดยอัตโนมัติ
- ประสิทธิผล: ลดการใช้ทรัพยากรและภาระการดำเนินงาน จึงคาดหวังข้อได้เปรียบด้านต้นทุนได้
- ความยืดหยุ่น: รองรับเวิร์กโหลดที่หลากหลายด้วยการควบคุมความสดใหม่ของข้อมูลอย่างละเอียดและตัวเลือกการตั้งค่าที่หลากหลาย
- การวิเคราะห์แบบเรียลไทม์: นำเทคนิคการทำดัชนีของ Apache Pinot มาใช้ เพื่อมุ่งให้ได้ทั้ง latency ต่ำและ throughput สูง
บทสรุป
- Apache Iceberg, Apache Hudi และ Delta Lake มีบทบาทสำคัญอย่างมากในการพัฒนาแนวคิด Lakehouse
- หากผสานแนวทางของ Napa จาก Google เข้ากับแนวคิดจาก Apache Pinot และระบบอื่น ๆ ก็จะสามารถวางวิสัยทัศน์ของ LakeDB ที่บูรณาการมากกว่าและทรงพลังกว่าได้
- LakeDB มีแนวโน้มสูงที่จะกลายเป็นสถาปัตยกรรมการจัดการข้อมูลยุคถัดไป ในฐานะระบบบูรณาการที่สมบูรณ์ซึ่งครอบคลุมสตอเรจ การโหลดข้อมูล เมทาดาทา และการประมวลผลคิวรี
ยังไม่มีความคิดเห็น