Snowflake เปิดทดลอง Horizon Catalog คุมสิทธิ์ตาราง Iceberg จากเอนจินภายนอก อ่านและเขียนได้
Snowflake เปิด Public Preview ให้ Horizon Catalog บังคับใช้นโยบายกรองแถวและปิดบังคอลัมน์กับตาราง Iceberg ที่เอนจินภายนอกอ่านและเขียน ประกาศ 6 ต.ค. 2026
โดย กองบรรณาธิการ THAI DATA อ่าน 5 นาที
สรุปประเด็นสำคัญ
- Snowflake ประกาศเมื่อ 6 ตุลาคม 2026 เปิด Public Preview ให้ Horizon Catalog บังคับใช้นโยบาย row access และ column masking กับตาราง Apache Iceberg ที่ถูกเรียกจากเอนจินภายนอก
- เอนจินที่รองรับ Iceberg REST Scan Plan API เช่น Apache Spark, Trino, PyIceberg, Apache Flink และ DuckDB ใช้ได้โดยไม่ต้องติดตั้งปลั๊กอินเพิ่ม กรณี Spark ต้องใช้ Iceberg 1.11 ขึ้นไป
- ข้อกำหนด Scan Plan แบบโอเพนซอร์สตอบ HTTP 403 เมื่อเขียนตารางที่มีนโยบาย แต่ Horizon Catalog ยอมให้ เขียน ได้ หากเงื่อนไขนโยบายอยู่ในรูปแบบที่รองรับ
- เปิดให้บัญชี Enterprise Edition ขึ้นไป ชุดข้อมูลที่กรองแล้วถูกลบภายใน 24 ชั่วโมง และมีค่า compute ของ Snowflake สำหรับประเมินนโยบาย
Snowflake ประกาศเมื่อวันที่ 6 ตุลาคม 2026 เปิดทดลองแบบ Public Preview ให้ Horizon Catalog บังคับใช้นโยบายกรองแถว (row access) และปิดบังคอลัมน์ (column masking) กับตาราง Apache Iceberg ที่ถูกอ่านและเขียนจากเอนจินภายนอก เช่น Apache Spark, Trino และ PyIceberg ผ่าน Iceberg REST Catalog API องค์กรกำหนดนโยบายครั้งเดียวใน Snowflake โดยเอนจินภายนอกไม่ต้องติดตั้งปลั๊กอินเพิ่ม
เอกสารของ Snowflake ระบุว่าความสามารถนี้เปิดให้ทุกบัญชีที่เป็น Enterprise Edition ขึ้นไป Snowflake อ้างว่า Horizon Catalog เป็นแคตตาล็อกรายแรกของอุตสาหกรรมที่คุมสิทธิ์ระดับละเอียดได้กับตาราง Iceberg ทุกแบบ ทั้งตารางที่ Snowflake จัดการเองและตารางที่ระบบอื่นจัดการ
Horizon Catalog แก้ปัญหาอะไร
Apache Iceberg ทำให้องค์กรเก็บข้อมูลไว้ชุดเดียวบน cloud storage แล้วให้หลายเอนจินประมวลผลได้ แต่บล็อกของ Snowflake ยอมรับว่าก่อนการประกาศครั้งนี้ เอนจินภายนอกเข้าถึงตารางที่มีนโยบายป้องกันข้อมูลไม่ได้เลย query จะล้มด้วยข้อผิดพลาดทันที องค์กรจึงต้องเลือกระหว่างความยืดหยุ่นในการใช้ compute กับการกำกับดูแลข้อมูล
บล็อกเมื่อ 27 มกราคม 2026 ของ Snowflake อธิบายว่าทางอ้อมที่ทีมข้อมูลใช้กันคือทำสำเนาตารางที่กรองหรือปิดบังแล้วแยกให้ผู้ใช้แต่ละกลุ่ม หรือสร้าง view เฉพาะของแต่ละเอนจิน ทั้งสองทางเพิ่มต้นทุนและงานดูแล ตอนนั้น Snowflake เริ่มจากให้ Snowflake Connector for Spark ส่งการอ่านเขียนตารางที่มีนโยบายผ่าน Snowflake และบอกว่า Iceberg REST Scan Plan API คือรากฐานระยะยาว รอบนี้คือการส่งมอบรากฐานนั้น
Horizon Catalog คุมสิทธิ์การอ่านและการเขียนอย่างไร
เอกสารของ Snowflake อธิบายขั้นตอนเมื่อเอนจินภายนอก query ตารางที่มีนโยบายไว้ดังนี้
- ส่งคำขอ เอนจินส่งคำขอ scan ตามมาตรฐาน Iceberg REST Catalog
- ประเมินนโยบาย Horizon Catalog ตรวจบริบทของ query กับนโยบาย row access และ masking ที่ผูกกับตาราง หากไม่ต้องกรองหรือปิดบังจะข้ามขั้นสร้าง scan plan เพื่อลดเวลา
- สร้าง scan plan ถ้าต้องกรอง Horizon Catalog สร้างชุดข้อมูลที่บังคับใช้นโยบายแล้ว
- บังคับใช้ เอนจินเห็นเฉพาะแถวและค่าที่ได้รับอนุญาต แล้วประมวลผลต่อด้วย compute ของตัวเอง
ข้อกำหนด Scan Plan ของ Iceberg แบบโอเพนซอร์สรองรับเฉพาะการอ่าน การเขียนลงตารางที่มีนโยบายจะได้ข้อผิดพลาด HTTP 403 จุดที่ Snowflake ทำเพิ่มคือ Horizon Catalog ตรวจสิทธิ์ของผู้เขียนและบริบทของนโยบายก่อน commit ทำให้เขียนได้ แต่มีเงื่อนไขว่านโยบายต้องใช้รูปแบบเงื่อนไขที่รองรับ เช่น ตรวจ CURRENT_ROLE() จากรายชื่อ role ตรวจ CURRENT_USER() กับชื่อผู้ใช้ ใช้ IS_ROLE_IN_SESSION() หรืออ่านแท็กของผู้ใช้ด้วย SYSTEM$GET_TAG() นโยบายรูปแบบอื่นอาจถูกปฏิเสธด้วย HTTP 403
เชื่อมกับการจัดประเภทข้อมูลและการตรวจสอบย้อนหลัง
Snowflake วาง Horizon Catalog เป็นศูนย์กลางของวงจรกำกับดูแลสามขั้น ขั้นแรก Sensitive Data Classification ตรวจหาคอลัมน์ที่มีข้อมูลอ่อนไหวและแปลงเป็นแท็ก ขั้นที่สอง ทีมข้อมูลผูกนโยบาย masking หรือ row access เข้ากับแท็กแบบ attribute-based access control (ABAC) ตารางหรือคอลัมน์ที่มีแท็กนั้นจะได้รับการป้องกันอัตโนมัติ ขั้นที่สาม Access History และ Lineage บันทึกการทำงานที่มาจากเอนจินภายนอก ผู้ดูแลกรองดูได้จากคอลัมน์ event_source ที่มีค่า horizon_irc ในมุมมอง ACCESS_HISTORY และบันทึกนี้ครอบคลุมทั้งคนและเอเจนต์ AI อย่าง Snowflake Cortex
บล็อกยกตัวอย่างลูกค้าสองราย Srinivas Podila จาก Salesforce กล่าวว่า lakehouse ขององค์กรใช้หลายเอนจิน การกำกับดูแลจึงพึ่งเอนจินใดเอนจินหนึ่งไม่ได้ ส่วนทีมของ Booking.com ระบุว่าใช้ Horizon Catalog คุมสิทธิ์ข้อมูล Iceberg ชุดเดียวไม่ว่าจะประมวลผลด้วย Spark, PyIceberg หรือ Flink
ข้อจำกัดและค่าใช้จ่าย
เอกสารระบุข้อควรพิจารณาที่ทีมสถาปัตยกรรมข้อมูลควรรู้ก่อนทดลอง
- ชุดข้อมูลที่กรองแล้วเก็บใน external volume ของลูกค้า และถูกลบอัตโนมัติหลัง 24 ชั่วโมง query ที่รันนานกว่านั้นอาจล้มเหลว
- Snowflake บังคับใช้นโยบายกับผู้ที่เข้าถึง storage โดยตรงนอกระบบสิทธิ์ของ Snowflake ไม่ได้
- ใช้ได้เฉพาะ snapshot ล่าสุด query ที่ระบุ snapshot ID ถูกบล็อก
- ไม่รองรับ aggregation pushdown, TopN, join pushdown ระหว่างตารางที่มีนโยบายสองตาราง และ filter pushdown แบบใช้ฟังก์ชัน ซึ่งเป็นข้อจำกัดของ Iceberg REST Scan API เอง
- นโยบายที่ใช้ฟังก์ชัน
CURRENT_STATEMENT()ใช้ไม่ได้ และตารางที่ระบบอื่นจัดการโดยไม่มี external volume ยังไม่รองรับ
ด้านค่าใช้จ่าย การใช้ Scan Plan API กิน compute ของ Snowflake สำหรับประเมินและบังคับใช้นโยบาย บวกค่าพื้นที่เก็บชั่วคราว และค่าโอนข้อมูลข้ามภูมิภาคหากแคตตาล็อก storage และเอนจินอยู่คนละภูมิภาค อัตราอยู่ในหมวด External Governance ของตารางค่าบริการ serverless ของ Snowflake
ทำไมเรื่องนี้สำคัญ
ห้าวันก่อนหน้า Databricks เพิ่งประกาศให้ Cross-engine ABAC ใน Unity Catalog พร้อมใช้งานทั่วไป ทั้งสองค่ายเลือกใช้กลไก scan planning ของ Iceberg REST Catalog เหมือนกัน ให้แคตตาล็อกเป็นผู้ตัดสินสิทธิ์แทนเอนจิน ความต่างหลักอยู่ที่สถานะและการเขียนข้อมูล
| ประเด็น | Snowflake Horizon Catalog | Databricks Unity Catalog |
|---|---|---|
| สถานะ | Public Preview (6 ต.ค. 2026) | พร้อมใช้งานทั่วไป (1 ต.ค. 2026) |
| เอนจินภายนอกเขียนตารางที่มีนโยบาย | ได้ หากนโยบายใช้รูปแบบเงื่อนไขที่รองรับ | ไม่ได้ ต้องยกเว้นผู้เขียนออกจากนโยบาย |
| ค่าประมวลผลนโยบาย | compute ของ Snowflake | serverless compute ของ Databricks |
Snowflake บอกด้วยว่าวิศวกรของบริษัทกำลังผลักดันข้อเสนอ Read Restrictions ในชุมชน Apache Iceberg ซึ่งจะเป็นมาตรฐานเปิดให้เอนจินบังคับใช้นโยบายเดียวกันเอง หากมาตรฐานนี้ผ่าน การคุมสิทธิ์ข้ามเอนจินจะผูกกับผู้ขายรายใดรายหนึ่งน้อยลง
สิ่งที่องค์กรควรทำ
- ทีมที่ดูแลข้อมูลส่วนบุคคลตาม PDPA ใช้แท็กและนโยบาย masking เดียวกันปิดบังเลขบัตรประชาชนหรือเบอร์โทรใน Horizon Catalog แทนการทำสำเนาตารางให้แต่ละทีม แต่ต้องทดสอบให้มั่นใจก่อน เพราะยังเป็น Public Preview
- ปิดช่องทางเข้าถึง storage โดยตรง เอกสารระบุชัดว่า Snowflake คุมผู้ที่อ่านไฟล์จาก bucket โดยตรงไม่ได้ ควรทบทวนสิทธิ์ IAM บน S3, Azure Storage หรือ Google Cloud Storage ให้เหลือเฉพาะบัญชีบริการที่จำเป็น
- ตรวจรูปแบบนโยบายก่อนเปิดให้เขียน ไล่ดูว่านโยบายที่มีอยู่ใช้เงื่อนไขในรายการที่รองรับหรือไม่ และอัปเกรด Spark ให้ใช้ Iceberg 1.11 ขึ้นไป
- ตั้งการติดตามค่าใช้จ่ายและบันทึกการเข้าถึง ดูยอด compute ของ External Governance และ query มุมมอง ACCESS_HISTORY ที่
event_sourceเป็นhorizon_ircเป็นประจำ - องค์กรที่ใช้ทั้ง Snowflake และ Databricks ควรกำหนดให้ชัดว่าตารางชุดใดใช้แคตตาล็อกใดเป็นผู้ตัดสินสิทธิ์ เพื่อไม่ให้นโยบายซ้ำซ้อนหรือขัดกัน ติดตามข่าวแพลตฟอร์มข้อมูลเพิ่มเติมได้ที่หมวดข้อมูล
คำถามที่พบบ่อย
Horizon Catalog ของ Snowflake เพิ่มความสามารถอะไรใหม่?
ตั้งแต่ 6 ตุลาคม 2026 Horizon Catalog เปิด Public Preview การบังคับใช้นโยบาย row access และ column masking กับตาราง Apache Iceberg ที่เอนจินภายนอกเรียกผ่าน Iceberg REST Catalog API ทั้งการอ่านและการเขียน โดยกำหนดนโยบายครั้งเดียวใน Snowflake
เอนจินอะไรใช้กับ Horizon Catalog ได้บ้าง?
Snowflake ระบุว่าเอนจินที่รองรับ Iceberg Scan Plan API ใช้ได้ เช่น Apache Spark, Trino, PyIceberg, Apache Flink และ DuckDB กรณี Apache Spark เอกสารให้ใช้ Iceberg รุ่น 1.11 ขึ้นไป เอนจินไม่ต้องเข้าใจภาษานโยบายของ Snowflake หรือติดตั้งตัวเชื่อมพิเศษ
Horizon Catalog ต่างจาก Cross-engine ABAC ของ Databricks อย่างไร?
ทั้งสองใช้แนวทาง Iceberg REST scan planning เหมือนกัน แต่ Cross-engine ABAC ของ Databricks พร้อมใช้งานทั่วไปแล้วเมื่อ 1 ตุลาคม 2026 และเอนจินภายนอกอ่านได้อย่างเดียว ส่วน Horizon Catalog ยังเป็น Public Preview แต่ยอมให้เขียนตารางที่มีนโยบายได้ในรูปแบบเงื่อนไขที่รองรับ
ใช้ Horizon Catalog กับ Scan Plan API มีข้อจำกัดอะไร?
ชุดข้อมูลที่กรองแล้วถูกลบหลัง 24 ชั่วโมง query ที่นานกว่านั้นจึงอาจล้มเหลว ใช้ได้เฉพาะ snapshot ล่าสุด ไม่รองรับ aggregation pushdown, TopN และ join pushdown ระหว่างตารางที่มีนโยบาย และผู้ที่เข้าถึง storage โดยตรงจะข้ามนโยบายได้
แหล่งอ้างอิง
- Unified Governance for the Interoperable Lakehouse with Snowflake Horizon Catalog — Snowflake
- Enforce data protection policies on Apache Iceberg tables using the Scan Plan API — Snowflake Documentation
- Extend Unified Governance Across the Iceberg Ecosystem with Horizon Catalog — Snowflake
- Cross-engine attribute-based access controls (ABAC) — Databricks
พบข้อมูลคลาดเคลื่อน? แจ้งกองบรรณาธิการ