ทําความเข้าใจวงจรชีวิตของคิวรี
มาดูกันว่า Unity Catalog จัดการการดําเนินการสืบค้นอย่างไร โดยให้ความสนใจเป็นพิเศษกับการควบคุมความปลอดภัยและการดูแลระบบ เราจะอธิบายทีละขั้นตอนเกี่ยวกับสิ่งที่จะเกิดขึ้นเมื่อมีการส่งคิวรีกับตาราง Unity Catalog ซึ่งครอบคลุมการโต้ตอบระหว่างการประมวลผล ระนาบควบคุม ระนาบข้อมูล และที่เก็บข้อมูลบนคลาวด์
วงจรชีวิตคิวรีใน Unity Catalog
ไดอะแกรมต่อไปนี้แสดงโฟลว์โดยรวมของคิวรีขณะที่เคลื่อนผ่านคอมโพเนนต์ต่างๆ ใน Unity Catalog
ขั้นตอนที่ 1: การส่งคําค้นหา
วงจรชีวิตเริ่มต้นเมื่อหลัก (ข้อมูลประจําตัวของผู้ใช้หรือบริการ) ออกคิวรี การสืบค้นสามารถเกิดขึ้นได้หลายวิธี:
- นักวิทยาศาสตร์ข้อมูลอาจใช้ คลัสเตอร์ อเนกประสงค์สําหรับปริมาณงาน Python หรือ SQL แบบโต้ตอบ
- บริการหลักอาจเรียกใช้ไปป์ไลน์หรืองานที่จัดกําหนดการบนคลัสเตอร์งาน
- นัก วิเคราะห์ข้อมูล อาจส่งแบบสอบถามผ่าน Databricks SQL โดยใช้คลังสินค้า SQL
- เครื่องมือข่าวกรองธุรกิจ (BI) ที่เชื่อมต่อกับคลังสินค้า SQL ยังสามารถสร้างคําขอได้อีกด้วย
ในแต่ละกรณี ทรัพยากรการประมวลผล - คลัสเตอร์หรือคลังสินค้า - จะได้รับคิวรีและเริ่มดําเนินการ
ขั้นตอนที่ 2: ขอการตรวจสอบความถูกต้องใน Unity Catalog
ทรัพยากรการประมวลผลจะส่งต่อคําขอไปยัง Unity Catalog Unity Catalog ทําหน้าที่เป็นระนาบควบคุมสําหรับการรักษาความปลอดภัยและการกํากับดูแล บันทึกคําขอใน บันทึกการตรวจสอบ และตรวจสอบว่าหลักมีสิทธิ์ที่จําเป็นในการเข้าถึงวัตถุที่อ้างอิงในแบบสอบถามหรือไม่ ถ้าสิทธิ์ถูกปฏิเสธ แบบสอบถามจะถูกบล็อกและบันทึกการปฏิเสธ หากได้รับสิทธิ์เข้าถึง คําขอจะดําเนินไปข้างหน้า
ขั้นตอนที่ 3: สมมติว่าข้อมูลเข้าสู่ระบบคลาวด์
สําหรับทุกออบเจ็กต์ที่อ้างอิงในคิวรี Unity Catalog จะถือว่า ข้อมูลประจําตัวระบบคลาวด์ ที่เหมาะสมที่เกี่ยวข้องกับออบเจ็กต์นั้น ข้อมูลประจําตัวเหล่านี้ได้รับการกําหนดค่าโดยผู้ดูแลระบบระบบคลาวด์
- สําหรับ ตารางที่มีการจัดการ ข้อมูลประจําตัวมักจะชี้ไปที่ที่เก็บข้อมูลบนคลาวด์ที่เชื่อมโยงกับ Metastore ของ Unity Catalog
- สําหรับ ตารางหรือไฟล์ภายนอก ข้อมูลประจําตัวจะสอดคล้องกับตําแหน่งภายนอกที่ควบคุมโดยข้อมูลประจําตัวที่เก็บข้อมูลที่กําหนดไว้
Note
ใน Azure วิธีที่ต้องการในการให้สิทธิ์การเข้าถึง Unity Catalog ไปยัง Azure Data Lake Storage (ADLS Gen2) คือผ่านตัว เชื่อมต่อข้อมูลประจําตัวที่มีการจัดการ + การเข้าถึง (เทียบกับการพึ่งพาบริการหลักเพียงอย่างเดียว) พวกเขามีประโยชน์ในการอนุญาตให้ Unity Catalog เข้าถึงบัญชีที่เก็บข้อมูลที่ได้รับการปกป้องโดยกฎเครือข่าย ซึ่งไม่สามารถทําได้โดยใช้บริการหลัก และไม่จําเป็นต้องจัดการและหมุนเวียนข้อมูลลับ
ขั้นตอนที่ 4: การออกโทเค็นที่มีขอบเขต
เมื่อตรวจสอบข้อมูลประจําตัวแล้ว Unity Catalog จะสร้าง โทเค็นการเข้าถึงชั่วคราวที่มีขอบเขต สําหรับแต่ละออบเจ็กต์ นอกจากโทเค็นแล้ว ยังมี URL การเข้าถึงที่ปลอดภัยอีกด้วย สิ่งนี้ทําให้ทรัพยากรการประมวลผลสามารถอ่านได้โดยตรงจากที่เก็บข้อมูลโดยไม่เปิดเผยข้อมูลประจําตัวที่มีอายุการใช้งานยาวนาน
ขั้นตอนที่ 5: การเข้าถึงข้อมูลจากที่เก็บข้อมูล
ทรัพยากรการประมวลผล (คลัสเตอร์หรือคลังสินค้า SQL) ใช้โทเค็นและ URL ที่จัดทําโดย Unity Catalog เพื่อขอข้อมูลโดยตรงจากตําแหน่งข้อมูล ADLS Gen2 พื้นฐาน (ผ่านabfss://dfs.core.windows.netหรือ URL)
Note
หากบัญชี ADLS ของคุณมีไฟร์วอลล์หรือข้อจํากัดเครือข่ายเสมือน คุณต้องอนุญาตให้ตัวเชื่อมต่อการเข้าถึง Azure Databricks / ข้อมูลประจําตัวที่มีการจัดการเข้าถึงที่เก็บข้อมูลอย่างชัดเจน (นอกเหนือจากการอนุญาตโหนดคอมพิวท์) หากบัญชีที่เก็บข้อมูลถูกล็อก แม้แต่โทเค็นที่ถูกต้องก็อาจถูกปฏิเสธหากข้อมูลประจําตัวไม่ได้รับอนุญาตผ่านกฎไฟร์วอลล์
ขั้นตอนที่ 6: การถ่ายโอนข้อมูล
ที่เก็บข้อมูลบนคลาวด์ส่งคืนข้อมูลที่ร้องขอไปยังทรัพยากรการประมวลผล กระบวนการนี้ทําซ้ําสําหรับทุกออบเจ็กต์ที่อ้างอิงในคิวรี
ขั้นตอนที่ 7: การกรองแบบละเอียด
Unity Catalog บังคับใช้ ตัวกรองระดับแถวและคอลัมน์ บนทรัพยากรการประมวลผลเอง สิ่งนี้ทําให้มั่นใจได้ว่าผู้บริหารจะเห็นเฉพาะชุดย่อยของข้อมูลที่พวกเขามีสิทธิ์เข้าถึงเท่านั้น
การกรองระดับแถวแนะนําเงื่อนไขที่ได้รับการประเมินในเวลาดําเนินการคิวรีภายในกลไกการคํานวณ แม้ว่าระบบที่เก็บข้อมูลพื้นฐานอาจส่งคืนชุดข้อมูลที่กว้างขึ้น แต่ Unity Catalog จะช่วยให้แน่ใจว่าเฉพาะแถวที่ตรงกับเงื่อนไขที่กําหนดเท่านั้นที่จะแสดงให้เห็นแก่หลักการที่ร้องขอ วิธีนี้ช่วยให้ผู้ใช้หลายคนสามารถสืบค้นตารางเดียวกันได้ แต่แต่ละคนจะได้รับมุมมองข้อมูลที่จํากัดและเป็นส่วนตัว ฟังก์ชันตัวกรองแถวเป็นเพรดิเคต (นิพจน์ SQL หรือฟังก์ชันที่ผู้ใช้กําหนดเอง) ที่ได้รับการประเมินระหว่างการดําเนินการคิวรี
การกรองระดับคอลัมน์ทํางานคล้ายกัน แต่ในระดับแอตทริบิวต์ คอลัมน์เฉพาะสามารถถูกปิดบังหรือแปลงเพื่อให้ข้อมูลที่ละเอียดอ่อนถูกซ่อนหรือทําให้ไม่ระบุตัวตน ขึ้นอยู่กับสิทธิ์ของหลัก สิ่งนี้ทําให้สามารถแชร์ชุดข้อมูลในวงกว้างในขณะที่มั่นใจได้ว่าฟิลด์ที่เป็นความลับจะมองเห็นได้อย่างสมบูรณ์เฉพาะผู้ที่ได้รับอนุญาตที่เหมาะสมเท่านั้น
ขั้นตอนที่ 8: การส่งคืนผลลัพธ์
ผลลัพธ์การสืบค้นที่กรองแล้วจะถูกส่งคืนจากทรัพยากรการประมวลผลไปยังผู้ใช้ งาน หรือแอปพลิเคชันที่เรียก
วิธีการทํางานของคิวรีกับ Apache Hive
Unity Catalog ได้รับการออกแบบมาเพื่อปรับปรุงการกํากับดูแล แต่ยังรักษาความเข้ากันได้กับ Hive metastore รุ่นเก่า เมื่อมีการกําหนดพื้นที่ทํางานให้กับ Metastore ของ Unity Catalog Hive จะปรากฏเป็นแค็ตตาล็อกพิเศษที่ชื่อ hive_metastore ตารางที่เก็บไว้ที่นั่นยังคงสามารถคิวรีได้โดยการอ้างอิงแค็ตตาล็อกนี้ในเนมสเปซ
Note
การควบคุมการเข้าถึงตาราง Hive metastore เป็นแบบจําลองการกํากับดูแลข้อมูลแบบดั้งเดิม
วงจรชีวิตของคิวรีกับตาราง Hive แตกต่างจากแค็ตตาล็อก Unity ในหลายวิธี:
- Hive ไม่ได้ให้การกํากับดูแลแบบรวมศูนย์และละเอียด ผู้ดูแลระบบมักจะต้องจัดการ บัญชีบริการ ข้อมูลลับ หรือโปรไฟล์อินสแตนซ์ สําหรับการรับรองความถูกต้องและการให้สิทธิ์แทน
- การเข้าถึงข้อมูลอาจเกี่ยวข้องกับการตั้งค่า จุดต่อเชื่อม การรับรองความถูกต้องแบบพาสทรู หรือนโยบายการจัดเก็บข้อมูล ซึ่งแต่ละรายการต้องมีการกําหนดค่าเพิ่มเติม
- การบันทึกการตรวจสอบและการควบคุมการเข้าถึงจะผสานรวมน้อยกว่าเมื่อเทียบกับ Unity Catalog ซึ่งอาจนําไปสู่ความไม่สอดคล้องกันในการบังคับใช้ความปลอดภัย
ขั้นตอนที่ 1: การส่งคําค้นหา
หลัก (ผู้ใช้หรือบริการ) จะส่งคิวรีไปยังคลัสเตอร์หรือจุดสิ้นสุด SQL นี่คือจุดเริ่มต้นสําหรับการค้นหา Hive ทั้งหมด
ขั้นตอนที่ 2: ตรวจสอบการเข้าถึง
คลัสเตอร์จะตรวจสอบแบบสอบถามกับรายการควบคุมการเข้าถึงตาราง (ACL) ACL เหล่านี้กําหนดว่าหลักการที่ร้องขอมีสิทธิ์เข้าถึงตารางที่ระบุหรือไม่
ขั้นตอนที่ 3: ค้นหาตําแหน่ง
หากได้รับสิทธิ์การเข้าถึง คลัสเตอร์จะปรึกษา เมตาสโตร์ Hive เพื่อค้นหาตําแหน่งที่เก็บข้อมูลของตาราง เมตาสโตร์มีข้อมูลเมตาเกี่ยวกับตาราง รวมถึงสคีมาและเส้นทางการจัดเก็บ
ขั้นตอนที่ 4: เส้นทางที่ส่งคืน
เมตาสโตร์ Hive ส่งคืน เส้นทางการจัดเก็บข้อมูล ไปยังคลัสเตอร์ โดยปกติจะเป็น URI (ตัวอย่างเช่น abfss://...) เส้นทางนี้ชี้ไปที่ตําแหน่งทางกายภาพของข้อมูลตารางในที่เก็บข้อมูลบนคลาวด์
ขั้นตอนที่ 5: คําขอข้อมูล
คลัสเตอร์พยายามอ่านข้อมูลจากที่เก็บข้อมูลบนคลาวด์ ในขั้นตอนนี้ จะต้องรับรองความถูกต้องโดยใช้กลไกใดกลไกหนึ่ง เช่น บริการหลัก การรับรองความถูกต้องแบบพาสทรู หรือโปรไฟล์อินสแตนซ์ ผู้ดูแลระบบมักจะต้องกําหนดค่าข้อมูลประจําตัวเหล่านี้ล่วงหน้า พร้อมกับข้อมูลลับและจุดต่อเชื่อม
ขั้นตอนที่ 6: ส่งคืนข้อมูล
ที่เก็บข้อมูลบนคลาวด์จะส่งข้อมูลที่ร้องขอกลับไปยังคลัสเตอร์
ขั้นตอนที่ 7: การบังคับใช้นโยบาย
คลัสเตอร์จะบังคับใช้การกรองไมล์สุดท้ายเพื่อลบข้อมูลที่อาจารย์ใหญ่ไม่ควรเห็น ซึ่งอาจเกี่ยวข้องกับการใช้ข้อจํากัดระดับแถวหรือคอลัมน์ในเวลาคิวรี
ขั้นตอนที่ 8: การส่งผลลัพธ์
ผลลัพธ์การสืบค้นขั้นสุดท้ายจะถูกส่งกลับไปยังอาจารย์ใหญ่ที่ออกคําขอ
ในทางปฏิบัติ นี่หมายความว่าการสืบค้น Hive เกี่ยวข้องกับขั้นตอนการดูแลระบบด้วยตนเองและการบํารุงรักษาอย่างต่อเนื่อง Unity Catalog ช่วยลดค่าใช้จ่ายนี้โดยการจัดการข้อมูลประจําตัวโดยอัตโนมัติ ให้โทเค็นที่มีขอบเขต และบังคับใช้นโยบายอย่างสม่ําเสมอในทุกออบเจ็กต์