เจาะลึก
Data Engineering
Liquid Clustering vs ZOrdering vs Partitioning: เลือกผิดชีวิตเปลี่ยนจริงไหม?
มีสองโหมดพังที่ยังไม่มีใครจดเป็นเอกสาร แต่ระบบ production กำลังเจออยู่ตอนนี้
ทีมข่าว เอไอไทย.com
⏱ อ่าน 4 นาที
การเลือก layout ข้อมูลใน lakehouse ไม่ใช่แค่เรื่อง performance — มันคือการเดิมพันว่า workload ของคุณจะเปลี่ยนไปในทางไหน
ถ้าคุณเคยนั่งเทียบ partition กับ Z-Order แล้วปวดหัวว่าจะเลือกอะไรดี บทความนี้ของ Kushal Kumar Vishwakarma บน InfoQ น่าจะทำให้คุณรู้สึกดีขึ้นหน่อย เพราะเขาลงมือ benchmark จริงบน Delta Lake เทียบสามวิธี — Liquid Clustering, ZOrdering และ partitioning — ข้าม workload สี่แบบ
แต่ที่ทำให้บทความนี้น่าสนใจไม่ใช่แค่ตัวเลข benchmark ทั่วไป แต่มันไปเจอ "failure mode" สองแบบที่ยังไม่มีใครเขียนเป็นเอกสารทางการ ซึ่งคนเขียนบอกตรงๆ ว่า น่าจะกำลังกระทบระบบ production อยู่ตอนนี้ อันนี้คือประเด็นที่ควรค่าแก่การอ่านจริงๆ
Physical data layout เป็นหนึ่งในการตัดสินใจที่ "ผลกระทบสูง" ที่สุดในงาน lakehouse engineering — เลือกถูกก็ query เร็ว ประหยัด compute เลือกผิดก็จ่ายค่า cloud เพิ่มแบบไม่รู้ตัว โดยเฉพาะกับระบบที่ข้อมูลโตขึ้นทุกวัน การ migrate layout ทีหลังก็ไม่ใช่เรื่องสนุก
Liquid Clustering ถูกโปรโมตมานานว่าเป็นคำตอบที่ "ฉลาดกว่า" เพราะปรับ layout ได้เองตาม query pattern โดยไม่ต้องตายตัวเหมือน partitioning แบบเก่า แต่คำถามคือ — มันดีกว่าจริงในทุกกรณีไหม? บทความนี้ตอบด้วยข้อมูล ไม่ใช่ marketing copy
Liquid Clustering
ปรับ layout อัตโนมัติตาม workload ไม่ต้องกำหนด partition column เอง — ยืดหยุ่นที่สุด แต่ก็ต้องแลกกับอะไรบางอย่าง
ZOrdering
เทคนิคเดิมที่หลายคนคุ้นเคย จัดเรียงข้อมูลหลายมิติในไฟล์เดียว ต้องรันคำสั่ง optimize เองเป็นรอบ
Partitioning
วิธีคลาสสิก แบ่งข้อมูลตาม column ที่กำหนด ตายตัว แต่คาดเดาได้
การที่ผู้เขียนทดสอบข้าม workload สี่แบบบน Delta Lake ไม่ใช่แค่การ benchmark เล่นๆ — มันคือการพยายามหาว่า "คำตอบที่ถูก" ขึ้นอยู่กับ pattern การ query ของคุณยังไง ซึ่งเป็นสิ่งที่เอกสารส่วนใหญ่ไม่ค่อยพูดถึง
จุดที่ผมคิดว่าน้ำหนักที่สุดของบทความนี้คือการค้นพบ failure mode สองแบบที่ undocumented — คือไม่มีในเอกสารทางการของ Databricks หรือ Delta Lake เลย แต่ผู้เขียนเจอจากการทดสอบจริง และคาดว่ามันกำลังเกิดขึ้นในระบบ production ของหลายองค์กรอยู่ตอนนี้
นี่คือสิ่งที่ผมชอบในงานแบบนี้ — ไม่ได้มาเพื่อขาย feature แต่มาจากการนั่งทดสอบเอง เจอของจริง แล้วเอามาเล่าให้คนอื่นฟัง ซึ่งในโลก data engineering ที่เต็มไปด้วย blog post จาก vendor นั้น หายากพอสมควร
ผู้เขียนยังเสนอ decision framework สำหรับเลือก layout strategy ด้วย ไม่ใช่แค่บอกว่า "อันนี้ดีกว่า" ลอยๆ แต่ให้หลักคิดว่า workload แบบไหนควรใช้วิธีไหน — ซึ่งน่าจะมีประโยชน์กับทีมที่กำลังตัดสินใจเรื่องนี้อยู่จริงๆ
ถ้าคุณทำงานกับ Delta Lake หรือ lakehouse อยู่แล้ว และกำลังลังเลว่าจะเปลี่ยนไป Liquid Clustering ดีไหม บทความนี้คือสิ่งที่ควรอ่านก่อนตัดสินใจ เพราะอย่างน้อยมันจะบอกคุณว่า "จุดที่มันพัง" อยู่ตรงไหน ซึ่งเอกสารทางการมักไม่บอก
เรื่อง layout ข้อมูลไม่ใช่แค่ tuning performance แต่คือการตัดสินใจเชิงสถาปัตยกรรมที่กระทบทั้งค่าใช้จ่ายและความยืดหยุ่นในระยะยาว — และการมี benchmark ที่ทดสอบจริงแบบนี้ มีค่ากว่าคำโฆษณาใดๆ ของ vendor
ที่มา: InfoQ AI/ML — อ่านต้นฉบับ
ความคิดเห็น 1
กำลังโหลดความคิดเห็น...