AWS Glue เปิด Table Optimization สำหรับ Iceberg ใน California ลดไฟล์เล็กและ Snapshot ค้าง

AWS Glue เปิดตัวปรับแต่งตาราง Iceberg อัตโนมัติใน California ลดไฟล์เล็กและข้อมูลค้าง

AWS ประกาศวันที่ 30 ตุลาคม 2026 ว่า AWS Glue Data Catalog รองรับ automatic table optimization สำหรับตาราง Apache Iceberg ในรีเจียน US West (N. California) หรือ us-west-1 แล้ว ผู้ดูแลสามารถเปิดการปรับแต่งเป็นรายตารางหรือทุกตารางใน Data Catalog ได้ ข่าวนี้เป็นการขยายพื้นที่ให้บริการของความสามารถเดิม จึงมีผลโดยตรงต่อทีมที่เก็บ data lake ในรีเจียน California และยังต้องจัดการไฟล์เล็กกับ snapshot ค้างด้วยงานที่สร้างเอง

ตาราง Iceberg มักได้รับการเขียนข้อมูลเพิ่มอย่างต่อเนื่อง เมื่อแต่ละงานสร้างไฟล์ขนาดเล็กจำนวนมาก การอ่านข้อมูลอาจต้องเปิดไฟล์มากเกินจำเป็นและทำให้ query ช้าลง นอกจากนี้ snapshot ที่เกินระยะเก็บและไฟล์ที่ไม่มีตารางอ้างอิงยังใช้พื้นที่จัดเก็บ AWS ระบุว่า table optimization จะเฝ้าดูตารางแล้วทำงานเบื้องหลังสามด้าน ได้แก่ รวมไฟล์เล็ก ลบ snapshot ที่เลยค่าการเก็บรักษา และลบไฟล์ที่ไม่มีการอ้างอิงซึ่งไม่จำเป็นแล้ว

การรวมไฟล์เล็กหรือ compaction มีเป้าหมายลด overhead ในการอ่าน ไม่ใช่เปลี่ยนความหมายของข้อมูลในตาราง ส่วนการลบ snapshot ต้องสัมพันธ์กับนโยบาย retention ของทีม หากองค์กรพึ่งพาการย้อนอ่านสถานะเก่าเพื่อสอบสวนหรือกู้คืน การตั้งระยะเก็บสั้นเกินไปอาจขัดกับความต้องการนั้น ก่อนเปิด optimizer ควรทบทวนว่าระยะเก็บ snapshot สอดคล้องกับการตรวจสอบและการกู้คืนที่ใช้งานจริง ไม่ควรมองการลดพื้นที่เป็นเป้าหมายเดียว

AWS ให้เปิด table optimization ผ่าน Glue console, AWS CLI หรือ AWS SDK ได้ ทีมที่ใช้ infrastructure as code ควรตรวจว่าการเปิดเป็นรายตารางหรือทุกตารางเหมาะกับภาระงานใด การเปิดทั้ง catalog ช่วยลดงานกำหนดค่าทีละรายการ แต่ควรประเมินผลกับตารางที่มีรูปแบบการเขียนและข้อกำหนด retention ต่างกัน ส่วนการเปิดเฉพาะตารางทำให้เริ่มทดสอบกับงานที่ปัญหาไฟล์เล็กชัดก่อน แล้วจึงขยายเมื่อเห็นผลด้านความเร็วและต้นทุน

วิธีเริ่มต้นที่วัดผลได้คือเลือกตาราง Iceberg ที่มีจำนวนไฟล์สูงหรือ query ช้าลงเมื่อเวลาผ่านไป บันทึกขนาดไฟล์เฉลี่ย จำนวน snapshot และเวลารัน query ที่ใช้บ่อยก่อนเปิด optimizer จากนั้นเปิดการตั้งค่าในรีเจียน us-west-1 และติดตามรอบการทำงานผ่าน Glue console, CloudWatch metrics และ logs ตามที่ AWS ระบุ หลังผ่านหลายรอบควรดูทั้งจำนวนไฟล์ พื้นที่จัดเก็บ และเวลา query เพื่อประเมินว่าการปรับแต่งคุ้มกับรูปแบบ workload นั้นจริงหรือไม่

การติดตาม logs สำคัญเพราะการเปิดตัวเลือกไม่รับประกันว่าทุกตารางได้รับการปรับแต่งตามที่คาด หาก optimizer ทำงานล้มเหลวหรือยังไม่ถึงเงื่อนไขที่ต้องดำเนินการ ผลลัพธ์อาจไม่เปลี่ยนทันที ทีมดูแลควรตรวจสถานะของแต่ละ run แยกจากกราฟต้นทุนรวม และตรวจสิทธิ์กับค่าการตั้งค่าที่เกี่ยวข้องเมื่อเห็นงานค้าง การมองเฉพาะผลลัพธ์ใน data lake อาจทำให้หาสาเหตุช้า

ข่าวนี้ไม่ได้หมายความว่าทุกรีเจียนมีความสามารถเหมือนกัน AWS ระบุเฉพาะการเพิ่ม us-west-1 และชี้ไปยังรายการรีเจียนที่รองรับในเอกสาร ผู้ดูแลที่มี data lake หลายรีเจียนควรเช็กความพร้อมของแต่ละพื้นที่ก่อนทำแผนมาตรฐานร่วมกัน สำหรับทีมใน California ประโยชน์หลักคือให้บริการจัดการงานบำรุงตาราง Iceberg ซ้ำ ๆ แทนสคริปต์ที่ต้องดูแลเอง พร้อมช่องทางติดตามผล แต่การตั้ง retention และการประเมินผลต่อ query ยังคงเป็นงานที่ต้องตัดสินตามข้อมูลจริงของแต่ละระบบ

ที่มา: AWS What's New — Glue Data Catalog optimizers in US West (N. California) ประกาศวันที่ 30 ตุลาคม 2026; AWS Glue table optimizers documentation