Databricks เปิดเผยรายละเอียดข้อกำหนด Apache Iceberg ใหม่ 2 ฉบับ เพื่อการกำกับดูแลข้ามแคตตาล็อก
Databricks describes two new Apache Iceberg specs, read restrictions and catalog labels, aimed at standardizing policy enforcement across engines and catalogs.
คำตอบโดยย่อ
Databricks ประกาศอะไรเกี่ยวกับการกำกับดูแลข้อมูลใน Open Lakehouse?
Databricks says the Apache Iceberg community has adopted two new specifications, read restrictions and catalog labels, to the Iceberg REST Catalog. Read restrictions let catalogs delegate policy enforcement to trusted engines, while catalog labels let catalogs exchange governance metadata, such as PII tags, across federated systems like Unity Catalog and Snowflake.
ประเด็นสำคัญ
- Databricks reports that the Apache Iceberg community has advanced two additions to the Iceberg REST Catalog: read restrictions and catalog labels.
- ข้อจำกัดด้านการอ่านข้อมูล (Read restrictions) ช่วยให้แคตตาล็อกสามารถประเมินนโยบายการเข้าถึงของผู้ใช้แต่ละราย และส่งคืนคำสั่งสำหรับกรองแถว (row-filter) และคัดเลือกคอลัมน์ (column-projection) ที่เอนจินซึ่งเชื่อถือได้ อย่างเช่น Trino ที่ได้รับการกำหนดค่าอย่างปลอดภัย จะต้องนำไปบังคับใช้ ทั้งนี้ Databricks ระบุว่าเอนจินที่ไม่น่าเชื่อถือ เช่น Spark หรือ DuckDB จำเป็นต้องอาศัยการบังคับใช้แบบรวมศูนย์แทน
- Databricks states the read restrictions spec defines nine predefined column-projection actions and standardized row-filter expressions, but does not define how a catalog establishes trust with an engine.
- ตามข้อมูลของ Databricks ป้ายกำกับแคตตาล็อก (catalog labels) ช่วยให้แคตตาล็อกต่าง ๆ เช่น Unity Catalog, Snowflake, AWS Lake Formation และ Google Cloud Knowledge Catalog สามารถแลกเปลี่ยนข้อมูลเมทาดาทาแบบคีย์-แวลูในระดับตารางและคอลัมน์ได้ โดยแคตตาล็อกปลายทางจะนำข้อมูลดังกล่าวไปจับคู่เข้ากับโมเดลการติดแท็กหรือนโยบายของตนเอง
- Databricks notes that labels are opaque key-value pairs with no shared semantics, so enterprises still need their own conventions to interpret them consistently across catalogs.
Databricks เผยแพร่รายละเอียดข้อกำหนดใหม่สองรายการที่ชุมชน Apache Iceberg นำมาใช้กับ Iceberg REST Catalog ได้แก่ ข้อจำกัดการอ่านข้อมูล (read restrictions) และป้ายกำกับแคตตาล็อก (catalog labels) บริษัทระบุว่าทั้งสองข้อกำหนดนี้มีจุดมุ่งหมายเพื่อสร้างมาตรฐานการบังคับใช้นโยบายด้านธรรมาภิบาลข้อมูล เมื่อมีการเข้าถึงข้อมูลผ่านเอนจินประมวลผลและแคตตาล็อกแบบสหพันธ์ (federated catalog) ที่แตกต่างกัน
ข้อจำกัดการอ่านข้อมูล
Databricks อธิบายว่าข้อจำกัดการอ่านข้อมูลตอบโจทย์สถานการณ์ทั่วไปที่องค์กรกำกับดูแลข้อมูลไว้ในแคตตาล็อกเดียว แต่ต้องการสืบค้นข้อมูลนั้นด้วยเอนจินหรือเครื่องมือที่ต่างกัน ภายใต้โมเดลนี้ แคตตาล็อกจะประเมินตัวตนและบริบทของผู้ใช้ที่ร้องขอ ตัดสินใจว่าควรใช้ตัวกรองแถวหรือการปิดบังคอลัมน์แบบใด แล้วส่งข้อจำกัดเหล่านั้นกลับไปยังเอนจินที่ตนเชื่อถือให้เป็นผู้บังคับใช้
Databricks แยกแนวทางนี้ออกจากการบังคับใช้แบบรวมศูนย์ (centralized enforcement) ซึ่งทุกขั้นตอนเกิดขึ้นภายในสภาพแวดล้อมของแคตตาล็อกเอง บริษัทยกตัวอย่างการดำเนินงานของตนเอง โดยระบุว่า Databricks ใช้การควบคุมการเข้าถึงแบบละเอียด (fine-grained access control) บนคอมพิวต์เฉพาะทาง ด้วยการส่งต่อคิวรีผ่านสิ่งที่เรียกว่า secure filtering fleet และฟีเจอร์ Unity Catalog Cross-engine ABAC ได้ขยายแนวทางนี้ไปยังเอนจินอื่นผ่าน scan และ plan API ของ Iceberg REST catalog
สำหรับการบังคับใช้แบบมอบหมาย (delegated enforcement) Databricks ระบุว่าเอนจินจะไม่ได้รับนโยบายในรูปแบบที่ผู้ดูแลระบบเขียนไว้โดยตรง แต่จะได้รับคำสั่งกรองหรือปิดบังข้อมูลที่ประมวลผลแล้วสำหรับผู้ใช้รายนั้นโดยเฉพาะ บริษัทระบุว่าข้อกำหนดฉบับแรกนี้กำหนดการดำเนินการฉายคอลัมน์ (column-projection) ไว้ล่วงหน้า 9 รูปแบบ และนิพจน์ตัวกรองแถวที่เป็นมาตรฐาน เช่น การเปรียบเทียบหรือการเป็นสมาชิกของเซต พร้อมทั้งตั้งข้อสังเกตว่านโยบายที่พึ่งพา subquery ตารางค้นหา (lookup table) หรือ UDF แบบกำหนดเองนั้น ยังไม่สามารถแสดงออกได้ด้วยวิธีนี้ในขณะนี้
Databricks ยังชี้ให้เห็นว่าข้อกำหนดนี้ไม่ได้นิยามวิธีที่แคตตาล็อกจะพิสูจน์ว่าเอนจินหนึ่งน่าเชื่อถือ โดยระบุว่าเพียงแค่คำกล่าวอ้างจากฝั่งไคลเอนต์นั้นไม่เพียงพอ และผู้ดูแลระบบจำเป็นต้องใช้กลไกความปลอดภัยของตนเอง บริษัทชี้ไปยังการอภิปรายในชุมชน Iceberg ที่พิจารณาทางเลือกต่าง ๆ รวมถึง mTLS และ OAuth โดยระบุว่าเรื่องความเชื่อถือยังคงอยู่นอกเหนือขอบเขตของโปรโตคอลเอง Databricks ยกตัวอย่างว่าการติดตั้ง Trino ที่กำหนดค่าความปลอดภัยไว้อย่างรัดกุมถือเป็นเอนจินที่เชื่อถือได้ ในขณะที่ Spark และ DuckDB ถูกจัดว่าเป็นเอนจินที่ไม่น่าเชื่อถือ เมื่อผู้ใช้สามารถควบคุมรันไทม์และรันโค้ดใด ๆ ก็ได้ตามต้องการ
ป้ายกำกับแคตตาล็อก
ข้อกำหนดที่สอง คือป้ายกำกับแคตตาล็อก มุ่งแก้ปัญหาด้านธรรมาภิบาลข้อมูลข้ามแคตตาล็อกแบบสหพันธ์ ตามข้อมูลของ Databricks บริษัทระบุว่าปัจจุบันองค์กรจำนวนมากเชื่อมต่อแคตตาล็อกหลายตัวเข้าด้วยกัน ไม่ว่าจะเป็น Unity Catalog, Snowflake, AWS Lake Formation และ Google Cloud Knowledge Catalog ซึ่งแต่ละระบบต่างมีโมเดลการยืนยันตัวตนและภาษานโยบายเป็นของตนเอง
Databricks อธิบายว่าป้ายกำกับช่วยให้แคตตาล็อกต้นทาง (producing catalog) สามารถแนบเมทาดาต้าแบบคีย์-ค่าที่มีน้ำหนักเบาเข้ากับตารางและคอลัมน์ ซึ่งแคตตาล็อกปลายทาง (consuming catalog) จะนำไปแมปเข้ากับระบบการจัดประเภทหรือการติดแท็กของตนเอง ก่อนจะบังคับใช้นโยบายเฉพาะของระบบนั้น ๆ ต่อไป ตัวอย่างที่บริษัทยกขึ้นมาคือ แคตตาล็อกต้นทางที่ติดป้ายกำกับคอลัมน์หนึ่งว่า "ssn" ด้วยค่า "pii=ssn" ซึ่งแคตตาล็อกปลายทางสามารถใช้เป็นตัวกระตุ้นให้เกิดนโยบายการปิดบังข้อมูลได้
Databricks ระบุว่าเนื่องจากการบังคับใช้นโยบายยังคงอยู่ภายในแคตตาล็อกปลายทางเป็นการภายใน แต่ละระบบจึงยังคงความสามารถในการแสดงออกของนโยบาย (policy expressiveness) และเก็บร่องรอยการตรวจสอบ (audit trail) ของตนเองไว้ได้ โดยไม่จำเป็นต้องเรียกไปยังแคตตาล็อกอื่นทุกครั้งที่มีการตัดสินใจเรื่องการเข้าถึง บริษัทเตือนว่าป้ายกำกับเป็นเพียงคู่คีย์-ค่าที่ทึบแสง (opaque) ไม่มีความหมายร่วมกันหรือตัวระบุที่คงที่ตามที่มาตรฐานกำหนดไว้ ซึ่งหมายความว่าแคตตาล็อกปลายทางจะเห็นเพียงป้ายกำกับที่ถูกแปลผลแล้วเท่านั้น ไม่ใช่วัตถุประสงค์ดั้งเดิมที่ตั้งใจไว้ Databricks ระบุว่าองค์กรต่าง ๆ ยังคงต้องมีข้อตกลงร่วมกันหรือการแมปที่ชัดเจนเป็นของตนเอง เพื่อตีความป้ายกำกับให้สอดคล้องกัน
การนำสองโมเดลไปใช้งาน
Databricks สรุปว่าการเลือกใช้แนวทางใดขึ้นอยู่กับปลายทาง กล่าวคือ การบังคับใช้แบบรวมศูนย์สำหรับเอนจินที่ไม่น่าเชื่อถือ ข้อจำกัดการอ่านข้อมูลสำหรับเอนจินที่เชื่อถือได้ และป้ายกำกับแคตตาล็อกสำหรับการเชื่อมต่อระหว่างแคตตาล็อกแบบสหพันธ์
ที่มา: Databricks Blog, "Unifying governance across engines and catalogs in the Open Lakehouse," เผยแพร่เมื่อวันที่ 10 กันยายน 2026
คำถามที่พบบ่อย
- ข้อจำกัดในการอ่านคืออะไร
- Databricks describes read restrictions as a new Iceberg REST Catalog contract in which a catalog evaluates access policy for a requesting user and returns row-filter and column-projection instructions that a trusted engine must enforce when reading a table.
- ป้ายกำกับแค็ตตาล็อกคืออะไร
- According to Databricks, catalog labels let a producing catalog attach key-value metadata, such as marking a column as containing PII, to tables and columns, which a consuming catalog can map into its own governance model during federation.
- เครื่องมือค้นหาใดบ้างที่ถือว่าเชื่อถือได้ภายใต้ข้อจำกัดด้านการอ่าน
- Databricks gives a securely configured Trino deployment as an example of a trusted engine, since it provides native enforcement of row filters and column masks, while it lists Spark and DuckDB as untrusted when users control the runtime.
- ข้อกำหนดเรื่องข้อจำกัดการอ่านนี้ระบุวิธีการสร้างความน่าเชื่อถือ (trust) ไว้หรือไม่
- No. Databricks says the specification defines what a trusted engine must enforce but not how a catalog verifies that trust, noting the Iceberg community has discussed mechanisms such as mTLS and OAuth.