พัฒนาแบบจําลองความหมาย Direct Lake
บทความนี้อธิบายหัวข้อการออกแบบที่เกี่ยวข้องกับการพัฒนาแบบจําลองความหมาย Direct Lake
สร้างแบบจําลอง
คุณใช้พอร์ทัล Fabric เพื่อสร้างแบบจําลองความหมาย Direct Lake ในพื้นที่ทํางาน เป็นกระบวนการอย่างง่ายที่เกี่ยวข้องกับการเลือกตารางจากเลคเฮ้าส์หรือคลังเดียวเพื่อเพิ่มไปยังแบบจําลองความหมาย
จากนั้นคุณสามารถใช้ ประสบการณ์ การสร้างแบบจําลองเว็บเพื่อพัฒนาแบบจําลองความหมายต่อไปได้ ประสบการณ์นี้ช่วยให้คุณสามารถสร้างความสัมพันธ์ระหว่างตาราง สร้างหน่วยวัดและกลุ่มการคํานวณ ทําเครื่องหมายตารางวันที่ และตั้งค่าคุณสมบัติสําหรับแบบจําลองและวัตถุ (เช่น รูปแบบคอลัมน์) คุณยังสามารถตั้งค่าการรักษาความปลอดภัยระดับแถว (RLS) สําหรับแบบจําลองโดยการกําหนดบทบาทและกฎ และโดยการเพิ่มสมาชิก (บัญชีผู้ใช้หรือกลุ่มความปลอดภัยของ Microsoft Entra) ไปยังบทบาทเหล่านั้น
อีกวิธีหนึ่งคือ คุณสามารถพัฒนาแบบจําลองของคุณต่อไปได้โดยใช้เครื่องมือที่สอดคล้องกับ XMLA เช่น SQL Server Management Studio (SSMS) (เวอร์ชัน 19.1 หรือใหม่กว่า) หรือโอเพนซอร์ส เครื่องมือชุมชน สําหรับข้อมูลเพิ่มเติม โปรดดู ที่ การสนับสนุนการเขียนแบบจําลองที่มีตําแหน่ง ข้อมูล XMLA ในภายหลังที่บทความนี้
เคล็ดลับ
คุณสามารถเรียนรู้วิธีการสร้างเลคเฮ้าส์ ตาราง Delta และแบบจําลองความหมาย Direct Lake พื้นฐานโดยจบ บทช่วยสอนนี้
ตารางแบบจําลอง
ตารางแบบจําลองจะขึ้นอยู่กับตารางหรือมุมมองของจุดสิ้นสุดการวิเคราะห์ SQL อย่างไรก็ตาม หลีกเลี่ยงการใช้มุมมองเมื่อใดก็ตามที่เป็นไปได้ นั่นเป็นเพราะคิวรีไปยังตารางแบบจําลองที่ยึดตามมุมมองจะย้อนกลับไปยังโหมด DirectQuery เสมอซึ่งอาจส่งผลให้ประสิทธิภาพการทํางานของคิวรีช้าลง
ตารางควรประกอบด้วยคอลัมน์สําหรับการกรอง การจัดกลุ่ม การเรียงลําดับ และการสรุป นอกเหนือจากคอลัมน์ที่สนับสนุนความสัมพันธ์ของแบบจําลอง ในขณะที่คอลัมน์ที่ไม่จําเป็นจะไม่ส่งผลกระทบต่อประสิทธิภาพการคิวรีแบบจําลองเชิงความหมาย (เนื่องจากคอลัมน์เหล่านั้นจะไม่ถูกโหลดลงในหน่วยความจํา) แต่จะส่งผลให้ขนาดพื้นที่จัดเก็บขนาดใหญ่ขึ้นใน OneLake และจําเป็นต้องมีทรัพยากรการคํานวณมากขึ้นเพื่อโหลดและบํารุงรักษา
คำเตือน
การใช้คอลัมน์ที่ใช้ การมาสก์ข้อมูลแบบไดนามิก (DDM) ในแบบจําลองความหมาย Direct Lake ไม่ได้รับการสนับสนุน
หากต้องการเรียนรู้วิธีการเลือกตารางที่จะรวมไว้ในแบบจําลองความหมาย Direct Lake ของคุณ โปรดดู ที่ แก้ไขตารางสําหรับแบบจําลองความหมาย Direct Lake
สําหรับข้อมูลเพิ่มเติมเกี่ยวกับคอลัมน์ที่จะรวมไว้ในตารางแบบจําลองความหมายของคุณ ให้ดู ทําความเข้าใจที่เก็บข้อมูลสําหรับแบบจําลองความหมาย Direct Lake
บังคับใช้กฎการเข้าถึงข้อมูล
เมื่อคุณมีข้อกําหนดในการจัดส่งชุดย่อยของข้อมูลแบบจําลองไปยังผู้ใช้ที่แตกต่างกัน คุณสามารถบังคับใช้กฎการเข้าถึงข้อมูลได้ คุณบังคับใช้กฎโดยการตั้งค่าการรักษาความปลอดภัยระดับออบเจ็กต์ (OLS) และ/หรือการรักษาความปลอดภัยระดับแถว (RLS) ใน จุด สิ้นสุดการวิเคราะห์ SQL หรือในแบบจําลองความหมาย
หมายเหตุ
หัวข้อของการ บังคับใช้กฎ การเข้าถึงข้อมูลจะแตกต่างกัน แต่มีความเกี่ยวข้องกัน การตั้งค่า สิทธิ์ สําหรับผู้ใช้เนื้อหา ผู้สร้าง และผู้ใช้ที่จะจัดการแบบจําลองความหมาย (และรายการ Fabric ที่เกี่ยวข้อง) สําหรับข้อมูลเพิ่มเติมเกี่ยวกับการตั้งค่าสิทธิ์ ดู จัดการแบบจําลองความหมาย Direct Lake
การรักษาความปลอดภัยระดับวัตถุ (OLS)
OLS เกี่ยวข้องกับการจํากัดการเข้าถึงเพื่อค้นหาและคิวรีออบเจ็กต์หรือคอลัมน์ ตัวอย่างเช่น คุณอาจใช้ OLS เพื่อจํากัดผู้ใช้ที่สามารถเข้าถึง Salary
คอลัมน์จาก Employee
ตารางได้
สําหรับจุดสิ้นสุดการวิเคราะห์ SQL คุณสามารถตั้งค่า OLS เพื่อ ควบคุมการเข้าถึงออบเจ็กต์ปลายทาง เช่น ตารางหรือมุมมอง และการรักษาความปลอดภัยระดับคอลัมน์ (CLS) เพื่อ ควบคุมการเข้าถึงคอลัมน์ตารางปลายทาง
สําหรับแบบจําลองความหมาย คุณสามารถตั้งค่า OLS เพื่อ ควบคุมการเข้าถึงตารางหรือคอลัมน์แบบจําลองได้ คุณจําเป็นต้องใช้โอเพนซอร์สเครื่องมือชุมชนเช่น Tabular Editor เพื่อตั้งค่า OLS
การรักษาความปลอดภัยระดับแถว (RLS)
RLS เกี่ยวข้องกับการจํากัดการเข้าถึงชุดย่อยของข้อมูลในตาราง ตัวอย่างเช่น คุณอาจใช้ RLS เพื่อให้แน่ใจว่าพนักงานขายสามารถเข้าถึงข้อมูลยอดขายสําหรับลูกค้าในภูมิภาคการขายของพวกเขาเท่านั้น
สําหรับจุดสิ้นสุดการวิเคราะห์ SQL คุณสามารถตั้งค่า RLS เพื่อ ควบคุมการเข้าถึงแถวในตารางปลายทางได้
สำคัญ
เมื่อคิวรีใช้ตารางใดก็ตามที่มี RLS ในจุดสิ้นสุดการวิเคราะห์ SQL คิวรีจะย้อนกลับไปยังโหมด DirectQuery ประสิทธิภาพการทํางานของคิวรีอาจช้าลง
สําหรับแบบจําลองเชิงความหมาย คุณสามารถตั้งค่า RLS เพื่อ ควบคุมการเข้าถึงแถวในตารางแบบจําลอง คุณสามารถตั้งค่า RLS ใน ประสบการณ์ การสร้างแบบจําลองเว็บหรือโดยใช้เครื่องมือของบุคคลที่สาม
วิธีการประเมินคิวรี
เหตุผล ในการพัฒนาแบบจําลอง ความหมาย Direct Lake คือการคิวรีที่มีประสิทธิภาพสูงผ่านข้อมูลจํานวนมากใน OneLake ดังนั้นคุณควรพยายามออกแบบโซลูชันที่เพิ่มโอกาสในการคิวรีในหน่วยความจํา
ขั้นตอนต่อไปนี้เป็นการประเมินคิวรีโดยประมาณ (และไม่ว่าคิวรีจะล้มเหลว) ประโยชน์ของโหมดที่เก็บข้อมูล Direct Lake สามารถทําได้เฉพาะเมื่อขั้นตอนที่ห้าสําเร็จ
- ถ้าคิวรีประกอบด้วยตารางหรือคอลัมน์ใด ๆ ที่จํากัดโดย OLS แบบจําลองความหมาย ผลลัพธ์ของข้อผิดพลาดจะถูกส่งกลับ (วิชวลรายงานจะไม่สามารถแสดงได้)
- ถ้าคิวรีมีคอลัมน์ใด ๆ ที่จํากัดโดย SQL Analytics endpoint CLS (หรือตารางถูกปฏิเสธ) ระบบจะส่งกลับผลลัพธ์ข้อผิดพลาด (วิชวลรายงานจะล้มเหลวในการแสดงผล)
- ถ้าการเชื่อมต่อระบบคลาวด์ใช้ SSO (ค่าเริ่มต้น) CLS จะถูกกําหนดโดยระดับการเข้าถึงของผู้ใช้รายงาน
- ถ้าการเชื่อมต่อคลาวด์ใช้ข้อมูลประจําตัวแบบคงที่ CLS จะถูกกําหนดโดยระดับการเข้าถึงของข้อมูลประจําตัวแบบคงที่
- ถ้าคิวรีมีตารางใด ๆ ในจุดสิ้นสุดการวิเคราะห์ SQL ที่บังคับใช้ RLS หรือมุมมองที่ใช้ คิวรีจะกลับไปเป็นโหมด DirectQuery
- ถ้าการเชื่อมต่อระบบคลาวด์ใช้ SSO (ค่าเริ่มต้น) RLS จะถูกกําหนดโดยระดับการเข้าถึงของผู้ใช้รายงาน
- ถ้าการเชื่อมต่อคลาวด์ใช้ข้อมูลประจําตัวแบบคงที่ RLS จะถูกกําหนดโดยระดับการเข้าถึงของข้อมูลประจําตัวแบบคงที่
- ถ้าคิวรี เกิน guardrails ของความจุ คิวรีนั้นจะกลับสู่โหมด DirectQuery
- มิฉะนั้น คิวรีจะพอใจกับแคชในหน่วยความจํา ข้อมูลคอลัมน์ถูก โหลดลงในหน่วยความจํา ตามและเมื่อจําเป็น
สิทธิ์ของรายการต้นทาง
บัญชีที่ใช้เพื่อเข้าถึงข้อมูลเป็นหนึ่งในรายการต่อไปนี้
- ถ้าการเชื่อมต่อระบบคลาวด์ใช้ SSO (ค่าเริ่มต้น) แสดงว่าเป็นผู้ใช้รายงาน
- ถ้าการเชื่อมต่อระบบคลาวด์ใช้ข้อมูลประจําตัวแบบคงที่ จะเป็นข้อมูลประจําตัวแบบคงที่
บัญชีต้องมี อย่างน้อยหนึ่งสิทธิ์ในการอ่าน และ ReadData บนรายการต้นทาง (เลคเฮ้าส์หรือคลังสินค้า) สิทธิ์ของรายการสามารถสืบทอดจากบทบาทพื้นที่ทํางานหรือกําหนดให้ชัดเจนสําหรับรายการตามที่อธิบายไว้ในบทความนี้
สมมติว่าเป็นไปตามข้อกําหนดนี้ Fabric อนุญาตให้เข้าถึงแบบจําลองความหมายที่จําเป็นในการอ่านตาราง Delta และไฟล์ Parquet ที่เกี่ยวข้อง (เพื่อโหลดข้อมูลคอลัมน์ลงในหน่วยความจํา) และสามารถใช้กฎการเข้าถึงข้อมูลได้
ตัวเลือกกฎการเข้าถึงข้อมูล
คุณสามารถตั้งค่ากฎการเข้าถึงข้อมูลได้ใน:
- เฉพาะแบบจําลองความหมายเท่านั้น
- จุดสิ้นสุดการวิเคราะห์ SQL เท่านั้น
- ในทั้งแบบจําลองความหมายและจุดสิ้นสุดการวิเคราะห์ SQL
กฎในแบบจําลองความหมาย
หากคุณต้องบังคับใช้กฎการเข้าถึงข้อมูล คุณควรดําเนินการดังกล่าวในแบบจําลองความหมายเมื่อใดก็ตามที่สามารถดําเนินการได้ นั่นเป็นเพราะ RLS ที่บังคับใช้โดยแบบจําลองความหมายสามารถทําได้โดยการกรองแคชข้อมูลในหน่วยความจําเพื่อให้ได้คิวรีที่มีประสิทธิภาพสูง
นอกจากนี้ยังเป็นวิธีที่เหมาะสมเมื่อผู้ใช้รายงานไม่ได้รับอนุญาตให้คิวรี่ของเลคเฮ้าส์หรือคลังข้อมูล
ไม่ว่าในกรณีใด ขอแนะนําเป็นอย่างยิ่งว่าการเชื่อมต่อระบบคลาวด์ใช้ข้อมูลประจําตัวแบบคงที่แทน SSO SSO จะหมายความว่าผู้ใช้ปลายทางสามารถเข้าถึงจุดสิ้นสุดการวิเคราะห์ SQL โดยตรงและอาจข้ามกฎความปลอดภัยในแบบจําลองความหมาย
สำคัญ
สิทธิ์รายการแบบจําลองเชิงความหมายสามารถ ตั้งค่าอย่างชัดเจน ผ่านทาง แอป Power BI หรือ ได้รับโดยนัย ผ่านบทบาทพื้นที่ทํางาน
โดยเฉพาะอย่างยิ่ง จะไม่มีการบังคับใช้กฎการเข้าถึงข้อมูลแบบจําลองเชิงความหมายสําหรับผู้ใช้ที่ มีสิทธิ์เขียน ในแบบจําลองความหมาย ในทางกลับกัน กฎการเข้าถึงข้อมูลจะนําไปใช้กับผู้ใช้ที่ได้รับมอบหมายบทบาทพื้นที่ทํางานของผู้ชม อย่างไรก็ตาม ผู้ใช้ที่กําหนดให้กับบทบาทผู้ดูแลระบบ สมาชิก หรือผู้สนับสนุนของพื้นที่ทํางานโดยปริยายจะมีสิทธิ์เขียนบนแบบจําลองความหมาย และดังนั้นจึงไม่มีการบังคับใช้กฎการเข้าถึงข้อมูล สําหรับข้อมูลเพิ่มเติม ให้ดู บทบาทในพื้นที่ทํางาน
กฎในจุดสิ้นสุดการวิเคราะห์ SQL
เหมาะสมที่จะบังคับใช้กฎการเข้าถึงข้อมูลในจุดสิ้นสุดการวิเคราะห์ SQL เมื่อการเชื่อมต่อระบบคลาวด์แบบจําลองเชิงความหมายใช้การลงชื่อเข้าระบบครั้งเดียว (SSO) นั่นเป็นเพราะว่าข้อมูลประจําตัวของผู้ใช้ได้รับมอบหมายให้คิวรีจุดสิ้นสุดการวิเคราะห์ SQL เพื่อให้แน่ใจว่าคิวรีจะส่งกลับเฉพาะข้อมูลที่อนุญาตให้ผู้ใช้สามารถเข้าถึงได้ นอกจากนี้ยังเหมาะสมที่จะบังคับใช้กฎการเข้าถึงข้อมูลในระดับนี้เมื่อผู้ใช้จะสอบถามจุดสิ้นสุดการวิเคราะห์ SQL โดยตรงสําหรับปริมาณงานอื่น ๆ (ตัวอย่างเช่น เพื่อสร้างรายงานที่มีการแบ่งหน้าของ Power BI หรือส่งออกข้อมูล)
อย่างไรก็ตาม อย่างไรก็ตาม คิวรีแบบจําลองเชิงความหมายจะกลับไปเป็นโหมด DirectQuery เมื่อมีตารางใด ๆ ที่บังคับใช้ RLS ในจุดสิ้นสุดการวิเคราะห์ SQL ดังนั้น แบบจําลองความหมายอาจไม่แคชข้อมูลลงในหน่วยความจําเพื่อให้ได้คิวรีที่มีประสิทธิภาพสูง
กฎที่ทั้งสองเลเยอร์
คุณสามารถบังคับใช้กฎการเข้าถึงข้อมูลได้ทั้งสองเลเยอร์ อย่างไรก็ตาม วิธีการนี้เกี่ยวข้องกับความซับซ้อนและค่าใช้จ่ายในการจัดการที่มากเกินไป ในกรณีนี้ เราขอแนะนําอย่างยิ่งให้การเชื่อมต่อระบบคลาวด์ใช้ข้อมูลประจําตัวแบบคงที่แทน SSO
การเปรียบเทียบตัวเลือกกฎการเข้าถึงข้อมูล
ตารางต่อไปนี้เปรียบเทียบตัวเลือกการตั้งค่าการเข้าถึงข้อมูล
ใช้กฎการเข้าถึงข้อมูลกับ | ข้อคิดเห็น |
---|---|
เฉพาะแบบจําลองแสดงความหมายเท่านั้น | ใช้ตัวเลือกนี้เมื่อผู้ใช้ไม่ได้รับสิทธิ์รายการในการคิวรีของเลคเฮ้าส์หรือคลังสินค้า ตั้งค่าการเชื่อมต่อระบบคลาวด์เพื่อใช้ข้อมูลประจําตัวแบบคงที่ ประสิทธิภาพคิวรีสูงสามารถทําได้จากแคชในหน่วยความจํา |
จุดสิ้นสุดการวิเคราะห์ SQL เท่านั้น | ใช้ตัวเลือกนี้เมื่อผู้ใช้จําเป็นต้องเข้าถึงข้อมูลจากคลังสินค้าหรือแบบจําลองความหมาย และด้วยกฎการเข้าถึงข้อมูลที่สอดคล้องกัน ตรวจสอบให้แน่ใจว่ามีการเปิดใช้งาน SSO สําหรับการเชื่อมต่อระบบคลาวด์ ประสิทธิภาพการทํางานของคิวรีอาจช้า |
เลคเฮ้าส์หรือคลังสินค้า และ รูปแบบความหมาย | ตัวเลือกนี้เกี่ยวข้องกับค่าใช้จ่ายในการจัดการเพิ่มเติม ตั้งค่าการเชื่อมต่อระบบคลาวด์เพื่อใช้ข้อมูลประจําตัวแบบคงที่ |
แนวทางปฏิบัติที่แนะนําสําหรับการบังคับใช้กฎการเข้าถึงข้อมูล
ต่อไปนี้คือแนวทางปฏิบัติที่แนะนําที่เกี่ยวข้องกับการบังคับใช้กฎการเข้าถึงข้อมูล:
- ถ้าผู้ใช้ที่แตกต่างกันต้องถูกจํากัดให้กับชุดย่อยของข้อมูล เมื่อใดก็ตามที่สามารถทํางานได้ ให้บังคับใช้ RLS ที่เลเยอร์แบบจําลองเชิงความหมายเท่านั้น ด้วยวิธีนี้ ผู้ใช้จะได้รับประโยชน์จากคิวรีในหน่วยความจําที่มีประสิทธิภาพสูง ในกรณีนี้ เราขอแนะนําอย่างยิ่งให้การเชื่อมต่อระบบคลาวด์ใช้ข้อมูลประจําตัวแบบคงที่แทน SSO
- หากเป็นไปได้ ให้หลีกเลี่ยงการบังคับใช้ OLS และ CLS ที่เลเยอร์ใดก็ตามเนื่องจากส่งผลให้เกิดข้อผิดพลาดในวิชวลรายงาน ข้อผิดพลาดอาจทําให้เกิดความสับสนหรือความกังวลสําหรับผู้ใช้ สําหรับคอลัมน์สรุป พิจารณาการสร้างหน่วยวัดที่ส่งกลับค่า BLANK ในเงื่อนไขบางอย่างแทน CLS (ถ้าเป็นไปได้)
การสนับสนุนการเขียนแบบจําลองที่มีตําแหน่งข้อมูล XMLA
แบบจําลองความหมาย Direct Lake รองรับการดําเนินการเขียนที่มีตําแหน่งข้อมูล XMLA โดยใช้เครื่องมือเช่น SSMS (19.1 หรือใหม่กว่า) และโอเพนซอร์สเครื่องมือชุมชน
เคล็ดลับ
สําหรับข้อมูลเพิ่มเติมเกี่ยวกับการใช้เครื่องมือของบุคคลที่สามในการพัฒนา จัดการ หรือปรับแบบจําลองความหมายให้เหมาะสม โปรดดู สถานการณ์การใช้งานการจัดการ แบบจําลองข้อมูลขั้นสูง
ก่อนที่คุณจะสามารถเขียนการดําเนินการได้ คุณต้องเปิดใช้งานตัวเลือกการอ่าน-เขียน XMLA สําหรับความจุ สําหรับข้อมูลเพิ่มเติม ดูเปิดใช้งาน XMLA แบบอ่าน-เขียน
การดําเนินการเขียนแบบจําลองด้วยการสนับสนุนตําแหน่งข้อมูล XMLA:
- การปรับแต่ง การผสาน การเขียนสคริปต์ การดีบัก และการทดสอบเมตาดาต้าของแบบจําลอง Direct Lake
- การควบคุมแหล่งที่มาและเวอร์ชัน การรวมอย่างต่อเนื่องและการปรับใช้อย่างต่อเนื่อง (CI/CD) ด้วย Azure DevOps และ GitHub สําหรับข้อมูลเพิ่มเติม ดู การจัดการวงจรชีวิตเนื้อหา
- งานอัตโนมัติ เช่น การรีเฟรชแบบจําลองความหมายและการนําการเปลี่ยนแปลงไปใช้กับแบบจําลองความหมาย Direct Lake โดยใช้ PowerShell และ REST API
เมื่อเปลี่ยนแบบจําลองความหมายโดยใช้ XMLA คุณต้องอัปเดต คอลเลกชัน ChangedProperties และ PBI_RemovedChildren สําหรับวัตถุที่เปลี่ยนแปลงเพื่อรวมคุณสมบัติที่ปรับเปลี่ยนหรือลบออก หากคุณไม่ได้ดําเนินการอัปเดตดังกล่าว เครื่องมือการสร้างแบบจําลอง Power BI อาจเขียนทับการเปลี่ยนแปลงใด ๆ ในครั้งถัดไปที่มีการซิงโครไนซ์ Schema
แบบจําลองที่สนับสนุนสําหรับการเปลี่ยนแบบจําลองความหมายโดยใช้ XMLA มีดังนี้:
- เปลี่ยนชื่อตาราง/คอลัมน์ (ChangeProperty = name)
- ลบตาราง (เพิ่มตารางไปยัง PBI_RemovedChildren คําอธิบายประกอบในนิพจน์คิวรี)
สำคัญ
ตาราง Direct Lake ที่สร้างขึ้นโดยใช้แอปพลิเคชัน XMLA จะอยู่ในสถานะที่ยังไม่ได้ประมวลผลเบื้องต้นจนกว่าแอปพลิเคชันจะส่งคําสั่งรีเฟรช คิวรีที่เกี่ยวข้องกับตารางที่ไม่ได้ประมวลผลจะกลับไปใช้โหมด DirectQuery เสมอ ดังนั้นเมื่อคุณสร้างแบบจําลองความหมายใหม่ ตรวจสอบให้แน่ใจว่าได้รีเฟรชแบบจําลองเพื่อประมวลผลตาราง
สําหรับข้อมูลเพิ่มเติม โปรดดู การเชื่อมต่อแบบจําลองความหมายที่มีตําแหน่งข้อมูล XMLA
เมตาดาต้าแบบจําลอง Direct Lake
เมื่อคุณเชื่อมต่อกับแบบจําลองความหมาย Direct Lake ด้วยตําแหน่งข้อมูล XMLA เมตาดาต้าจะมีลักษณะเหมือนกับแบบจําลองอื่น ๆ อย่างไรก็ตาม แบบจําลอง Direct Lake แสดงความแตกต่างดังต่อไปนี้:
- คุณสมบัติของ
compatibilityLevel
วัตถุฐานข้อมูลคือ 1604 (หรือสูงกว่า) - คุณสมบัติโหมดของพาร์ติชัน Direct Lake ถูกตั้งค่า
directLake
เป็น - พาร์ติชัน Direct Lake ใช้นิพจน์ที่ใช้ร่วมกันเพื่อกําหนดแหล่งข้อมูล นิพจน์จะชี้ไปยังจุดสิ้นสุดการวิเคราะห์ SQL ของเลคเฮ้าส์หรือคลังสินค้า Direct Lake ใช้จุดสิ้นสุดการวิเคราะห์ SQL เพื่อค้นหา schema และข้อมูลความปลอดภัย แต่จะโหลดข้อมูลโดยตรงจาก OneLake (เว้นแต่ว่าจะ ย้อนกลับไปยังโหมด DirectQuery ไม่ว่าด้วยเหตุผลใดก็ตาม)
งานหลังการเผยแพร่
หลังจากที่คุณเผยแพร่แบบจําลองความหมาย Direct Lake คุณควรทํางานการตั้งค่าบางอย่างให้เสร็จสมบูรณ์ สําหรับข้อมูลเพิ่มเติม ดู จัดการแบบจําลองความหมาย Direct Lake
ฟีเจอร์ที่ไม่รองรับ
คุณลักษณะแบบจําลองต่อไปนี้ไม่ได้รับการสนับสนุนโดยแบบจําลองความหมาย Direct Lake:
- ตารางจากการคํานวณที่อ้างอิงตารางหรือคอลัมน์ในโหมดที่เก็บข้อมูล Direct Lake
- คอลัมน์จากการคํานวณที่อ้างอิงตารางหรือคอลัมน์ในโหมดที่เก็บข้อมูล Direct Lake
- ตารางแบบไฮบริด
- การรวมที่ผู้ใช้กําหนดเอง
- โมเดลแบบรวมในที่นี้คุณไม่สามารถรวมตารางโหมดที่เก็บข้อมูล Direct Lake เข้ากับตาราง โหมดที่เก็บข้อมูล DirectQuery หรือคู่ในแบบจําลองเดียวกันได้ อย่างไรก็ตาม คุณสามารถใช้ Power BI Desktop เพื่อสร้างการเชื่อมต่อแบบสดไปยังแบบจําลองความหมาย Direct Lake และจากนั้นขยายด้วยหน่วยวัดใหม่ และจากนั้นคุณสามารถเลือกตัวเลือกเพื่อทํา การเปลี่ยนแปลงแบบจําลอง นี้เพื่อเพิ่มตารางใหม่ (โดยใช้โหมดที่เก็บข้อมูลแบบนําเข้า DirectQuery หรือโหมดที่เก็บข้อมูลแบบคู่) การดําเนินการนี้สร้างการเชื่อมต่อ DirectQuery ไปยังแบบจําลองความหมายในโหมด Direct Lake ดังนั้นตารางจะแสดงเป็นโหมดที่เก็บข้อมูล DirectQuery แต่โหมดที่เก็บข้อมูลนี้ไม่ได้แสดงว่าย้อนกลับไป DirectQuery เฉพาะการเชื่อมต่อระหว่างแบบจําลองใหม่นี้กับแบบจําลอง Direct Lake คือ DirectQuery และคิวรียังคงใช้ Direct Lake เพื่อรับข้อมูลจาก OneLake สําหรับข้อมูลเพิ่มเติม ดู สร้างแบบจําลองแบบรวมบนแบบจําลองความหมาย
- คอลัมน์ที่ยึดตามคอลัมน์จุดสิ้นสุดการวิเคราะห์ SQL ที่ใช้รูปแบบข้อมูลแบบไดนามิก