เกี่ยวกับการใช้ DirectQuery ใน Power BI

คุณสามารถเชื่อมต่อกับแหล่งข้อมูลต่าง ๆ ได้ทุกประเภท เมื่อใช้ Power BI Desktop หรือ บริการ Power BI และคุณสามารถทำการเชื่อมต่อข้อมูลเหล่านั้นด้วยวิธีต่าง ๆ ได้ คุณสามารถ นำเข้า ข้อมูลไปยัง Power BI ซึ่งเป็นวิธีทั่วไปในการรับข้อมูล หรือคุณสามารถเชื่อมต่อโดยตรงไปยังข้อมูลในที่เก็บแหล่งข้อมูลดั้งเดิม หรือที่เรียกว่า DirectQuery บทความนี้อธิบายความสามารถของ DirectQuery:

• ตัวเลือกการเชื่อมต่อที่แตกต่างกันสำหรับ DirectQuery
• คำแนะนำว่าเมื่อใดที่คุณควรใช้ DirectQuery แทนการนำเข้า
• ข้อเสียของการใช้ DirectQuery
• แนวทางปฏิบัติที่ดีที่สุดสำหรับการใช้ DirectQuery

ปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดสำหรับการใช้การนำเข้าเมื่อเทียบกับ DirectQuery:

• คุณควรนำเข้าข้อมูลไปยัง Power BI ทุกที่ที่เป็นไปได้ การนำเข้าข้อมูลจะใช้ประโยชน์จากกลไกจัดการคิวรีประสิทธิภาพสูงของ Power BI และมอบประสบการณ์ที่มีการโต้ตอบสูงและโดดเด่น
• ถ้าเป้าหมายของคุณไม่สามารถดำเนินการนำเข้าข้อมูล โปรดพิจารณาการใช้ DirectQuery ตัวอย่างเช่น ถ้าข้อมูลมีการเปลี่ยนแปลงบ่อย และรายงานต้องแสดงข้อมูลล่าสุด การใช้ DirectQuery อาจที่ดีที่สุด อย่างไรก็ตาม จะสามารถใช้ DirectQuery ได้เมื่อแหล่งข้อมูลต้นแบบมีคิวรีแบบโต้ตอบ น้อยกว่า 5 วินาที สำหรับคิวรีรวมทั่วไป และสามารถจัดการกับการโหลดคิวรีที่จะสร้างขึ้น นอกจากนี้ ควรพิจารณารายการของข้อจำกัดสำหรับการใช้งาน DirectQuery อย่างรอบคอบ เพื่อให้แน่ใจว่ายังคงสามารถดำเนินการตามเป้าหมายของคุณ

ชุดของความสามารถที่เสนอโดย Power BI สำหรับการนำเข้าและ DirectQuery มีการพัฒนาตลอดเวลา การเปลี่ยนแปลงจะรวมถึงการให้ความยืดหยุ่นมากขึ้นเมื่อมีการใช้ข้อมูลที่นำเข้า และการนำเข้านั้นสามารถใช้ได้ในหลายกรณี และสามารถกำจัดข้อเสียบางส่วนของการใช้ DirectQuery เมื่อใช้ DirectQuery ประสิทธิภาพของแหล่งข้อมูลต้นแบบยังคงเป็นข้อพิจารณาหลักอยู่เสมอ โดยไม่คำนึงถึงการปรับปรุง ถ้าแหล่งข้อมูลต้นแบบนั้นช้า ให้ใช้ DirectQuery และแหล่งข้อมูลนั้นจะยังไม่สามารถดำเนินการได้

บทความนี้ครอบคลุม DirectQuery กับ Power BI แต่ไม่รวมถึง SQL Server Analysis Services DirectQuery ยังเป็นคุณลักษณะของ SQL Server Analysis Services รายละเอียดหลายอย่างที่อธิบายไว้ในบทความนี้นำไปใช้กับคุณลักษณะนั้น นอกจากนี้ยังมีความแตกต่างที่สำคัญอีกด้วย สำหรับข้อมูลเกี่ยวกับการใช้ DirectQuery กับ SQL Server Analysis Services โปรดดู DirectQuery ใน SQL Server 2016 Analysis Services

บทความนี้มุ่งเน้นไปที่สมุดงานที่แนะนำสำหรับ DirectQuery ซึ่งรายงานจะถูกสร้างใน Power BI Desktop แต่ยังคงครอบคลุมถึงการเชื่อมต่อโดยตรงในบริการ Power BI

โหมดการเชื่อมต่อ Power BI

Power BI เชื่อมต่อกับแหล่งข้อมูลที่แตกต่างกันจำนวนมาก ครอบคลุมไปถึง:

• บริการออนไลน์ (Salesforce, Dynamics 365 และอื่น ๆ)
• ฐานข้อมูล (SQL Server, Access, Amazon Redshift และอื่น ๆ)
• ไฟล์แบบง่าย (Excel, JSON และอื่น ๆ)
• แหล่งข้อมูลอื่น ๆ (Spark, เว็บไซต์, Microsoft Exchange และอื่น ๆ)

สำหรับแหล่งข้อมูลเหล่านี้ จะสามารถนำเข้าข้อมูลไปยัง Power BI ได้ บางแหล่งข้อมูลยังสามารถเชื่อมต่อโดยใช้ DirectQuery ได้อีกด้วย สำหรับข้อสรุปของแหล่งข้อมูลที่สนับสนุน DirectQuery โปรดดู แหล่งข้อมูลที่ DirectQuery สนับสนุน แหล่งข้อมูลเพิ่มเติมที่จะเปิดใช้งาน DirectQuery ในอนาคต จะมุ่งเน้นที่แหล่งข้อมูลที่คาดว่าจะสามารถแสดงประสิทธิภาพการทำงานคิวรีแบบโต้ตอบได้ดี

SQL Server Analysis Services เป็นกรณีพิเศษ เมื่อเชื่อมต่อกับ SQL Server Analysis Services คุณสามารถเลือกที่จะนำเข้าข้อมูล หรือใช้ การเชื่อมต่อแบบสด (Live Connection) ได้ การใช้การเชื่อมต่อแบบสดจะเหมือนกับ DirectQuery ไม่มีการนำเข้าข้อมูล และมีการคิวรีแหล่งข้อมูลต้นแบบเพื่อรีเฟรชวิชวลเสมอ การเชื่อมต่อแบบสดนั้นแตกต่างกันไปในหลาย ๆ ด้าน ดังนั้นคำศัพท์ที่ใช้จึงแตกต่างกันด้วยระหว่าง การเชื่อมต่อแบบสด กับ DirectQuery

ตัวเลือกสำหรับการเชื่อมต่อกับข้อมูลทั้งสามตัวเลือกนี้: นำเข้า, DirectQuery และ การเชื่อมต่อแบบสด

นำเข้าการเชื่อมต่อ

สำหรับการนำเข้า เมื่อใช้ รับข้อมูล ใน Power BI Desktop เพื่อเชื่อมต่อกับแหล่งข้อมูลเช่น SQL Server ลักษณะการทำงานของการเชื่อมต่อดังกล่าวจะเป็นดังนี้:

• ในระหว่างประสบการณ์การใช้งาน รับข้อมูล เริ่มต้น ชุดของตารางที่เลือกแต่ละรายการจะกำหนดคิวรีที่จะส่งคืนชุดข้อมูล คุณสามารถแก้ไขคิวรีเหล่านั้นได้ก่อนการโหลดข้อมูล ตัวอย่างเช่น เมื่อต้องการใช้ตัวกรอง หรือรวมข้อมูล หรือต่อตารางที่แตกต่างเข้าด้วยกัน
• เมื่อมีการโหลด ข้อมูลทั้งหมดที่กำหนดโดยคิวรีเหล่านั้นจะได้รับการนำเข้าลงในแคช Power BI
• เมื่อสร้างวิชวลภายใน Power BI Desktop ข้อมูลที่นำเข้าจะถูกคิวรี Power BI store ช่วยให้มั่นใจว่าการคิวรีจะรวดเร็ว การเปลี่ยนแปลงทั้งหมดไปยังวิชวลจะปรากฏขึ้นทันที
• การเปลี่ยนแปลงใดก็ตามที่ทำกับข้อมูลต้นแบบจะไม่มีผลกับวิชวล จำเป็นต้อง รีเฟรช เพื่อนำเข้าข้อมูลอีกครั้ง
• เมื่อมีการเผยแพร่รายงานเป็นไฟล์ .pbix ไปยังบริการ Power BI ชุดข้อมูลจะถูกสร้าง และอัปโหลดไปยังบริการ Power BI ข้อมูลนำเข้าจะรวมอยู่ในชุดข้อมูลนั้น จากนั้นจะสามารถตั้งกำหนดเวลาการรีเฟรชของข้อมูลดังกล่าวได้ ตัวอย่างเช่น นำเข้าข้อมูลอีกครั้งทุกวัน อาจจำเป็นต้องกำหนดค่าเกตเวย์ข้อมูลภายในองค์กร โดยขึ้นอยู่กับตำแหน่งที่ตั้งของแหล่งข้อมูลต้นฉบับ
• เมื่อเปิดรายงานที่มีอยู่แล้วในบริการ Power BI หรือเขียนรายงานใหม่ ข้อมูลนำเข้าจะได้รับการคิวรีอีกครั้ง เพื่อยืนยันการโต้ตอบ
• วิชวลหรือหน้ารายงานทั้งหมดสามารถปักหมุดเป็นไทล์แดชบอร์ด ไทล์จะรีเฟรชอัตโนมัติเมื่อชุดข้อมูลต้นแบบรีเฟรช

การเชื่อมต่อ DirectQuery

สำหรับ DirectQuery เมื่อใช้ รับข้อมูล ใน Power BI Desktop เพื่อเชื่อมต่อกับแหล่งข้อมูล ลักษณะการทำงานของการเชื่อมต่อจะเป็นดังนี้:

• ในระหว่างประสบการณ์การใช้งาน รับข้อมูล เริ่มต้น แหล่งข้อมูลจะถูกเลือก สำหรับแหล่งข้อมูลเชิงสัมพันธ์ ชุดตารางจะถูกเลือก และแต่ละชุดยังคงกำหนดคิวรีที่จะส่งกลับชุดข้อมูลตามหลักตรรกะ สำหรับแหล่งข้อมูลหลายมิติ เช่น SAP BW จะเลือกเฉพาะแหล่งข้อมูลเท่านั้น
• อย่างไรก็ตาม เมื่อมีการโหลด จะไม่มีการนำเข้าไปยัง Power BI store แต่ให้ดำเนินการสร้างวิชวลภายใน Power BI Desktop คิวรีจะถูกส่งไปยังแหล่งข้อมูลต้นแบบเพื่อดึงข้อมูลจำเป็นออกมา เวลาที่ใช้ในการรีเฟรชวิชวลจะขึ้นอยู่กับประสิทธิภาพของแหล่งข้อมูลต้นแบบ
• การเปลี่ยนแปลงใดก็ตามที่ทำกับข้อมูลต้นแบบไม่มีผลกับวิชวลที่มีอยู่โดยทันที ซึ่งคุณจำเป็นต้องรีเฟรช คิวรีที่จำเป็นสำหรับแต่ละวิชวลจะถูกส่งใหม่อีกครั้ง และจะมีการอัปเดตวิชวลตามความจำเป็น
• เมื่อมีการเผยแพร่รายงานไปยังบริการของ Power BI จะส่งผลกับชุดข้อมูลในบริการ Power BI เหมือนกับการนำเข้าอีกครั้ง อย่างไรก็ตาม ไม่มีข้อมูลใด รวมกับชุดข้อมูลนั้น
• เมื่อเปิดรายงานที่มีอยู่ในบริการ Power BI หรือเขียนรายงานใหม่ แหล่งข้อมูลต้นแบบจะถูกคิวรีอีกครั้งเพื่อดึงข้อมูลจำเป็น อาจจำเป็นต้องกำหนดค่าเกตเวย์ข้อมูลภายในองค์กรโดยขึ้นอยู่กับตำแหน่งที่ตั้งของแหล่งข้อมูลต้นฉบับ เนื่องจากจำเป็นสำหรับโหมดนำเข้าหากข้อมูลถูกรีเฟรช
• วิชวลหรือหน้ารายงานทั้งหมดสามารถปักหมุดเป็นไทล์แดชบอร์ด เพื่อให้แน่ใจว่าการเปิดแดชบอร์ดจะรวดเร็ว ไทล์จะถูกรีเฟรชโดยอัตโนมัติตามกำหนดการ ตัวอย่าง เช่น ทุกชั่วโมง คุณสามารถควบคุมความถี่ของการรีเฟรชนี้ เพื่อแสดงความถี่ที่ข้อมูลมีการเปลี่ยนแปลง และความสำคัญในการดูข้อมูลล่าสุด เมื่อเปิดแดชบอร์ด ไทล์จะแสดงข้อมูลตามเวลาการรีเฟรชล่าสุด และไม่จำเป็นต้องมีการเปลี่ยนแปลงล่าสุดที่ทำกับแหล่งข้อมูลต้นแบบ คุณสามารถรีเฟรชแดชบอร์ดที่เปิดอยู่เพื่อให้แน่ใจว่าเป็นปัจจุบัน

การเชื่อมต่อโดยตรง

เมื่อเชื่อมต่อกับ SQL Server Analysis Services จะมีตัวเลือกเพื่อให้นำเข้าข้อมูลจากแบบจำลองข้อมูลที่เลือก หรือเชื่อมต่อโดยตรงไปยังแบบจำลองข้อมูลที่เลือก ถ้าคุณใช้นำเข้า ให้คุณกำหนดคิวรีสำหรับแหล่งข้อมูล SQL Server Analysis Services ภายนอกนั้น และข้อมูลจะถูกนำเข้าตามปกติ ถ้าคุณเลือกการเชื่อมต่อแบบสด จะไม่มีการกำหนดคิวรีใดเลย และแบบจำลองภายนอกทั้งหมดจะแสดงในรายการเขตข้อมูล

สถานการณ์ที่อธิบายไว้ในย่อหน้าก่อนหน้านี้สามารถนำไปใช้กับการเชื่อมต่อกับแหล่งข้อมูลต่อไปนี้เช่นกัน เว้นแต่ว่าไม่มีตัวเลือกการนำเข้าข้อมูล:

• ชุดข้อมูล power BI ตัวอย่างเช่น เมื่อเชื่อมต่อกับชุดข้อมูล Power BI ที่ได้รับการสร้าง และเผยแพร่ไปยังบริการก่อนหน้านี้เพื่อสร้างรายงานใหม่
• Microsoft Dataverse

ลักษณะการทำงานของรายงานด้วย SQL Server Analysis Services เมื่อมีการเผยแพร่ไปยังบริการ Power BI จะมีลักษณะคล้ายกับรายงาน DirectQuery ดังต่อไปนี้:

• เมื่อเปิดรายงานที่มีอยู่ในบริการ Power BI หรือเขียนรายงานใหม่ แหล่งข้อมูล SQL Server Analysis Services ต้นแบบจะได้รับการคิวรี ซึ่งอาจต้องใช้เกตเวย์ข้อมูลภายในองค์กร
• ไทล์แดชบอร์ดที่จะรีเฟรชโดยอัตโนมัติตามกำหนดการ เช่น ทุกชั่วโมง

นอกจากนี้ยังมีความแตกต่างที่สำคัญอีกด้วย ตัวอย่างเช่น สำหรับการเชื่อมต่อแบบสด ข้อมูลประจำตัวของผู้ใช้ที่เปิดรายงานจะถูกส่งผ่านไปยังแหล่งที่มา SQL Server Analysis Services ต้นแบบเสมอ

จากการเปรียบเทียบเหล่านี้ ให้ลองมาโฟกัสที่ DirectQuery ในส่วนเหลือของบทความนี้เท่านั้น

DirectQuery จะมีประโยชน์เมื่อไหร่

ตารางต่อไปนี้อธิบายสถานการณ์ที่การเชื่อมต่อกับ DirectQuery อาจมีประโยชน์อย่างยิ่ง ซึ่งรวมถึงกรณีที่การทิ้งข้อมูลในแหล่งดั้งเดิมจะถือว่าเป็นประโยชน์ คำอธิบายรวมถึงการอภิปรายว่าสถานการณ์ที่ระบุมีอยู่ใน Power BI หรือไม่

โดยสรุป เมื่อพิจารณาจากความสามารถในปัจจุบันของ DirectQuery ใน Power BI สถานการณ์ที่ให้ประโยชน์มีดังนี้:

• ข้อมูลมีการเปลี่ยนแปลงอยู่บ่อยครั้ง และจำเป็นต้องมีการรายงานแบบ "เรียลไทม์"
• จัดการข้อมูลขนาดใหญ่มาก โดยไม่จำเป็นต้องรวบรวมไว้ล่วงหน้า
• ใช้ข้อจำกัดด้านอำนาจข้อมูล
• แหล่งข้อมูลเป็นแหล่งข้อมูลแบบหลายมิติที่ประกอบด้วยหน่วยวัด เช่น SAP BW

โปรดทราบว่ารายละเอียดในรายการก่อนหน้านี้เกี่ยวข้องกับการใช้ Power BI เท่านั้น แต่คุณสามารถใช้แบบจำลอง SQL Server Analysis Services หรือ Azure Analysis Services ภายนอกเพื่อนำเข้าข้อมูลได้ จากนั้นใช้ Power BI เพื่อเชื่อมต่อกับแบบจำลองนั้น แม้ว่าวิธีการดังกล่าวจะต้องใช้การกำหนดค่าเพิ่มเติม แต่ก็ช่วยให้มีความยืดหยุ่นมากขึ้น สามารถนำเข้าข้อมูลจำนวนมากได้ ไม่มีข้อจำกัดเกี่ยวกับความถี่ในการรีเฟรชข้อมูล

ข้อเสียของการใช้ DirectQuery

การใช้ DirectQuery มีผลกระทบเชิงลบ ซึ่งจะอธิบายตามรายละเอียดในส่วนนี้ ข้อจำกัดบางข้อจะแตกต่างกันเล็กน้อยโดยขึ้นอยู่กับแหล่งข้อมูลที่ใช้งาน เราแก้ไขปัญหาข้อจำกัดตามความเหมาะสม และแยกบทความให้ครอบคลุมแหล่งข้อมูลที่แตกต่างกันอย่างมาก

ประสิทธิภาพการทำงานและการโหลดบนแหล่งข้อมูลต้นแบบ

เมื่อใช้ DirectQuery ประสบการณ์การใช้งานโดยรวมจะขึ้นอยู่กับประสิทธิภาพของแหล่งข้อมูลต้นแบบ ถ้าการรีเฟรชแต่ละวิชวล ตัวอย่างเช่น หลังจากการเปลี่ยนแปลงค่าตัวแบ่งส่วนข้อมูล จะใช้เวลาสองถึงสามวินาที โดยปกติแล้วน้อยกว่า 5 วินาที ประสบการณ์การใช้งานดังกล่าวจะมีความสมเหตุสมผล ประสบการณ์การใช้งานอาจรู้สึกเอื่อยเฉื่อยเมื่อเทียบกับการตอบสนองทันทีเมื่อนำเข้าข้อมูลไปยัง Power BI หากความช้าของแหล่งข้อมูลทำให้วิชวลแต่ละวิชวลใช้เวลานานกว่าสิบวินาที ประสบการณ์การใช้งานจะแย่มาก คิวรีอาจหมดเวลา

ให้ความสนใจกับโหลดที่วางอยู่บนแหล่งข้อมูล พร้อมกับประสิทธิภาพของแหล่งต้นแบบ โหลดส่งผลกระทบต่อประสิทธิภาพ ผู้ใช้แต่ละรายที่เปิดรายงานที่ใช้ร่วมกัน และไทล์แดชบอร์ดแต่ละอันที่รีเฟรช ให้ส่งคิวรีอย่างน้อยหนึ่งคิวรีต่อหนึ่งวิชวลไปยังแหล่งข้อมูลต้นแบบ ข้อเท็จจริงนี้จำเป็นต้องมีแหล่งข้อมูลที่สามารถจัดการภาระคิวรีดังกล่าว โดยยังคงรักษาประสิทธิภาพการทำงานอย่างเหมาะสม

ผลกระทบด้านความปลอดภัยเมื่อรวมแหล่งข้อมูล

คุณสามารถใช้หลายแหล่งข้อมูลในแบบจำลอง DirectQuery ได้เช่นเดียวกับเมื่อคุณนำเข้าข้อมูลโดยใช้คุณลักษณะ แบบจำลองรวม เมื่อคุณใช้หลายแหล่งข้อมูล สิ่งสำคัญคือต้องทำความเข้าใจวิธีการย้ายข้อมูลกลับไปมาระหว่างแหล่งข้อมูลเบื้องต้นและความเกี่ยวข้องด้านความปลอดภัยที่จะนำมาใช้

การแปลงข้อมูลที่จำกัด

ในที่คล้ายกัน มีข้อจํากัดในการแปลงข้อมูลที่สามารถใช้งานภายในตัวแก้ไข Power Queryเดียวกัน ด้วยข้อมูลนำเข้า ชุดการแปลงที่มีความซับซ้อนสามารถนำมาใช้เพื่อทำความสะอาดและปรับแต่งข้อมูลก่อนที่จะใช้เพื่อสร้างวิชวลได้อย่างง่ายดาย เช่น การแยกวิเคราะห์เอกสาร JSON หรือการหมุนข้อมูลจากคอลัมน์ไปเป็นรูปแบบแถว การแปลงเหล่านั้นจะถูกจำกัดมากขึ้นใน DirectQuery

ก่อนอื่น เมื่อเชื่อมต่อกับแหล่งข้อมูล OLAP เช่น SAP Business Warehouse จะไม่สามารถกำหนดการแปลงได้เลย และจะนำแบบจำลองภายนอกทั้งหมดมาจากแหล่งข้อมูล สำหรับแหล่งข้อมูลเชิงสัมพันธ์ เช่น SQL Server จะยังคงสามารถกำหนดชุดของการแปลงต่อคิวรีได้ แต่จะมีการจำกัดการแปลงเหล่านั้นเพื่อเหตุผลด้านประสิทธิภาพการทำงาน

การแปลงดังกล่าวจะถูกนำไปใช้กับทุกการคิวรีแหล่งข้อมูลต้นแบบ โดยทำมากกว่าหนึ่งครั้งในการรีเฟรชข้อมูล ดังนั้นจึงมีข้อจำกัดสำหรับการแปลงข้อมูลที่สามารถแปลเป็นคิวรีเนทิฟเดี่ยวได้อย่างสมเหตุสมผล ถ้าคุณใช้การแปลงแบบที่มีความซับซ้อนเกินไป คุณจะได้รับข้อผิดพลาดที่ต้องลบ หรือแบบจำลองที่เปลี่ยนเป็นนำเข้า

นอกจากนี้ คิวรีที่เป็นผลลัพธ์จาก กล่องโต้ตอบรับ ข้อมูลหรือ ตัวแก้ไข Power Query จะถูกใช้การเลือกย่อยภายในคิวรีที่สร้างขึ้น และส่งไปเพื่อดึงข้อมูลจําเป็นของวิชวล คิวรีที่กําหนดตัวแก้ไข Power Queryต่อไปนี้ต้องถูกต้องภายในบริบทนี้ โดยเฉพาะอย่างยิ่งมันเป็นไปไม่ได้ที่จะใช้คิวรีโดยนิพนธ์ตารางทั่วไป หรือสิ่งที่เรียกใช้ Stored Procedures

ข้อจำกัดของการสร้างแบบจำลอง

ความหมายของ การสร้างแบบจำลอง ในบริบทนี้หมายถึงการกลั่นกรองและปรับปรุงข้อมูลดิบให้เป็นส่วนหนึ่งของการเขียนรายงานที่ใช้งานการสร้างแบบจำลอง ตัวอย่างเช่น

• กำหนดความสัมพันธ์ระหว่างตาราง
• เพิ่มการคำนวณใหม่ (คอลัมน์และหน่วยวัดจากการคำนวณ)
• เปลี่ยนชื่อและซ่อนคอลัมน์และการวัด
• กำหนดลำดับชั้น
• กำหนดการจัดรูปแบบ ข้อสรุปเริ่มต้นและจัดเรียงลำดับของคอลัมน์
• จัดกลุ่ม หรือแบ่งกลุ่มค่า

เมื่อใช้ DirectQuery จะยังสามารถดำเนินการการเสริมสร้างแบบจำลองต่าง ๆ เหล่านี้ และแน่นอนว่ายังคงมีหลักการที่ว่าข้อมูลดิบจะได้รับการเสริมสร้าง เพื่อปรับปรุงการบริโภคในภายหลัง อย่างไรก็ตาม เมื่อใช้ DirectQuery จะมีความสามารถในการสร้างแบบจำลองบางอย่างที่ไม่พร้อมใช้งาน หรือจะถูกจำกัด ข้อจำกัดที่จะนำไปใช้เพื่อหลีกเลี่ยงปัญหาเกี่ยวกับประสิทธิภาพการทำงาน ชุดของข้อจำกัดที่ใช้โดยทั่วไปกับแหล่งข้อมูล DirectQuery ทั้งหมด จะแสดงอยู่ในรายการตรงส่วนนี้ ข้อจำกัดเพิ่มเติมอาจนำไปใช้กับแต่ละแหล่งข้อมูลตามที่อธิบายไว้ใน ขั้นตอนถัดไป

• ไม่มีลำดับชั้นวันที่ในตัว: เมื่อนำเข้าข้อมูล ทุกคอลัมน์วันที่/วันที่และเวลาจะมีลำดับชั้นวันที่แบบติดตั้งมาในตัวจะพร้อมใช้งานเป็นค่าเริ่มต้น ตัวอย่างเช่น ถ้านำเข้าตาราง ใบสั่งขายรวมถึงคอลัมน์ OrderDate และเมื่อใช้ OrderDate ในวิชวล จะสามารถเลือกระดับที่เหมาะสม (ปี, เดือน, วัน) ที่จะใช้ ลำดับชั้นของวันแบบติดตั้งมาในตัวนี้ไม่พร้อมใช้งานเมื่อใช้ DirectQuery ถ้ามีตาราง Date พร้อมใช้งานในแหล่งข้อมูลต้นแบบ ซึ่งมีอยู่ทั่วไปในคลังข้อมูลจำนวนมาก ฟังก์ชัน DAX Time Intelligence จะยังสามารถใช้งานได้ตามปกติ
• วันที่/เวลารองรับเฉพาะความแม่นยำในระดับวินาทีเท่านั้น: ขณะใช้คอลัมน์เวลาในชุดข้อมูลองคุณ Power BI จะออกรายการสืบค้นไปยังต้นทางที่เกี่ยวข้องในระดับรายละอียดระดับวินาที ไม่มีการส่งคิวรีไปยังแหล่ง DirectQuery เป็นมิลลิวินาที ลบส่วนนี้ออกจากคอลัมน์แหล่งข้อมูลของคุณ
• ข้อจำกัดในคอลัมน์จากการคำนวณ: คอลัมน์จากการคำนวณจะถูกจำกัดอยู่ภายในแถว คอลัมน์เหล่านั้นสามารถดูค่าของคอลัมน์อื่น ๆ ในตารางเดียวกันได้โดยไม่ต้องใช้ฟังก์ชันรวมใด ๆ นอกจากนี้ฟังก์ชันสเกลาร์ DAX เช่น LEFT() ที่ได้รับอนุญาตจะถูกจำกัดเฉพาะฟังก์ชันเหล่านั้นที่สามารถส่งไปยังแหล่งต้นแบบได้ ฟังก์ชันจะแตกต่างกันโดยขึ้นอยู่กับความสามารถที่แท้จริงของแหล่งข้อมูล ฟังก์ชันที่ไม่ได้รับการสนับสนุนจะไม่แสดงในการเติมข้อความอัตโนมัติ เมื่อเขียน DAX สำหรับคอลัมน์จากการคำนวณ และจะส่งผลกับข้อผิดพลาดหากมีการใช้
• ไม่มีการสนับสนุนสำหรับฟังก์ชัน DAX หลัก-รอง: เมื่ออยู่ในแบบจำลอง DirectQuery จะไม่สามารถใช้งานตระกูลของฟังก์ชัน DAX PATH() ซึ่งโดยทั่วไปแล้วจะจัดการกับโครงสร้างหลัก-รอง เช่น แผนภูมิของบัญชี หรือลำดับชั้นของพนักงาน
• ตารางจากการคำนวณไม่ได้รับการสนับสนุน: ความสามารถในการกำหนดตารางจากการคำนวณโดยใช้นิพจน์ DAX ไม่ได้รับการสนับสนุนในโหมด DirectQuery
• ตัวกรองความสัมพันธ์: สำหรับข้อมูลเกี่ยวกับการกรองแบบสองทิศทาง ให้ดู การกรองแบบข้ามสองทิศทาง เอกสารทางเทคนิคนี้นำเสนอตัวอย่างในบริบทของ SQL Server Analysis Services จุดพื้นฐานใช้กับ Power BI เท่านั้น
• ไม่มีคลัสเตอร์ริ่ง: เมื่อใช้ DirectQuery จะไม่สามารถใช้ความสามารถในการคลัสเตอร์ริ่งเพื่อค้นหากลุ่มโดยอัตโนมัติ

ข้อจำกัดด้านการรายงาน

ความสามารถในการรายงานเกือบทั้งหมดได้รับการสนับสนุนสำหรับแบบจำลอง DirectQuery ดังนั้นตราบเท่าที่แหล่งข้อมูลต้นแบบมีประสิทธิภาพในระดับที่เหมาะสม จะสามารถใช้ชุดการแสดงวิชวลเดียวกันได้ มีข้อจำกัดที่สำคัญบางข้อในบางส่วนของความสามารถอื่น ๆ ในบริการ Power BI หลังจากรายงานได้รับการเผยแพร่:

• ไม่รองรับข้อมูลเชิงลึกด่วน: ข้อมูลเชิงลึกด่วนของ Power BI จะค้นหาเซตย่อยที่ต่างกันของชุดข้อมูลของคุณในขณะที่ใช้ชุดอัลกอริทึมที่ซับซ้อนในการค้นหาแนวโน้มข้อมูลเชิงลึกที่น่าสนใจ กำหนดความต้องการสำหรับคิวรีที่มีประสิทธิภาพสูงมาก ความสามารถนี้ไม่สามารถใช้ได้กับชุดข้อมูลที่ใช้ DirectQuery
• การใช้ Explore ใน Excel อาจส่งผลให้เกิดประสิทธิภาพการทำงานที่แย่ลง: คุณสามารถสำรวจข้อมูลของคุณโดยใช้ความสามารถ Explore ใน Excel บนชุดข้อมูล แนวทางนี้จะทำให้ตาราง Pivot และแผนภูมิ Pivot ได้รับการสร้างใน Excel แม้ว่าความสามารถนี้ได้รับการสนับสนุนในชุดข้อมูลที่ใช้ DirectQuery แต่โดยทั่วไปแล้วประสิทธิภาพการทำงานช้ากว่าการสร้างวิชวลใน Power BI ดังนั้น ถ้าการใช้ Excel เป็นสิ่งสำคัญสำหรับสถานการณ์ของคุณ ข้อเท็จจริงนี้ควรนำมาพิจารณาในการตัดสินใจใช้ DirectQuery
• ลExcelดังนี้: เมื่อเชื่อมต่อโดยใช้ DirectQuery จาก Excel ไปยังแบบลอง Azure Analysis Services หรือชุดข้อมูล Power BI ตัวอย่างเช่น ใช้วิเคราะห์ใน Excelลดับชั้นใด ๆ ที่กําหนดไว้ในรูปแบบหรือชุดข้อมูลจะไม่แสดง
• ความยาวสูงสุดสำหรับคอลัมน์ข้อความ: ความยาวสูงสุดของข้อมูลในคอลัมน์ข้อความสำหรับชุดข้อมูลที่ใช้ DirectQuery คือ 32,764 อักขระ การรายงานข้อความที่ยาวเกินกว่านั้นจะทำให้เกิดข้อผิดพลาด

ความปลอดภัย

ดังที่กล่าวไว้ก่อนหน้าในบทความนี้ รายงานใน DirectQuery จะใช้ข้อมูลประจำตัวคงที่เดียวกันเสมอเพื่อเชื่อมต่อกับแหล่งข้อมูลต้นแบบ หลังจากเผยแพร่ไปยังบริการ Power BI ลักษณะการทำงานนี้ใช้กับ DirectQuery โดยไม่ต้องเชื่อมต่อโดยตรงกับ SQL Server Analysis Services ซึ่งแตกต่างกันในแง่นี้ หลังจากเผยแพร่รายงาน DirectQuery จำเป็นต้องกำหนดค่าข้อมูลประจำตัวของผู้ใช้ที่จะใช้โดยทันที จนกว่าคุณจะกำหนดค่าข้อมูลประจำตัว การเปิดรายงานในบริการ Power BI จะส่งผลให้เกิดข้อผิดพลาด

เมื่อได้รับข้อมูลประจำตัวผู้ใช้ จะมีการใช้ข้อมูลประจำตัวเหล่านั้น โดยไม่คำนึงถึงผู้ใช้ที่เปิดรายงาน ด้วยแนวทางนี้ จะเป็นเหมือนกับข้อมูลที่นำเข้าอย่างแม่นยำ ผู้ใช้ทุกคนจะเห็นข้อมูลเดียวกัน เว้นแต่ว่าจะมีการกำหนดความปลอดภัยระดับแถวเป็นส่วนหนึ่งของรายงาน ซึ่งต้องให้ความสนใจเหมือนกันกับการแบ่งปันรายงาน ถ้ามีกฎความปลอดภัยใด ๆ ที่กำหนดไว้ในแหล่งข้อมูลต้นแบบ

นอกจากนี้ยังไม่รองรับ 'ข้อมูลประจำตัวทางเลือก' เมื่อทำการเชื่อมต่อ DirectQuery กับ SQL Server จาก Power BI Desktop คุณสามารถใช้ข้อมูลประจำตัว Windows หรือข้อมูลประจำตัวฐานข้อมูลปัจจุบันของคุณ

ลักษณะการทำงานในบริการ Power BI

ในส่วนนี้จะอธิบายลักษณะการทำงานของรายงาน DirectQuery ในบริการ Power BI เพื่ออธิบายระดับของภาระที่จะถูกวางในแหล่งข้อมูลหลังบ้าน กำหนดจำนวนผู้ใช้ที่จะแบ่งปันรายงานและแดชบอร์ดด้วย ความซับซ้อนของรายงาน และเพื่อดูว่ามีการกำหนด Row Level Security ในรายงานหรือไม่

รายงาน – การเปิด การโต้ตอบกับ การแก้ไข

เมื่อเปิดรายงาน วิชวลทั้งหมดบนหน้าที่มองเห็นในขณะนี้จะรีเฟรช โดยทั่วไปแต่ละวิชวลจำเป็นต้องมีคิวรีอย่างน้อยหนึ่งคิวรีไปยังแหล่งข้อมูลต้นแบบ วิชวลบางอย่างอาจจำเป็นต้องมีคิวรีมากกว่าหนึ่งคิวรี ตัวอย่างเช่น วิชวลอาจแสดงค่ารวมจากตารางข้อเท็จจริงที่แตกต่างกันสองตาราง หรือประกอบด้วยหน่วยวัดที่ซับซ้อนมากขึ้น หรือประกอบด้วยผลรวมของหน่วยวัดที่ไม่ใช่แบบเพิ่ม เช่น นับจำนวนที่แตกต่างกัน การย้ายไปยังหน้าใหม่จะรีเฟรชวิชวลเหล่านั้น การรีเฟรชจะส่งคิวรีชุดใหม่ไปยังแหล่งข้อมูลต้นแบบ

การโต้ตอบของผู้ใช้ทั้งหมดในรายงานอาจทำให้มีการรีเฟรชวิชวล ตัวอย่างเช่น การเลือกค่าที่แตกต่างกันในตัวแบ่งส่วนต้องส่งชุดคิวรี่ใหม่เพื่อรีเฟรชการแสดงผลด้วยภาพที่ได้รับผลกระทบทั้งหมด เช่นเดียวกับการคลิกที่วิชวลเพื่อเน้นแบบไขว้ที่วิชวลอื่น ๆ หรือเปลี่ยนตัวกรอง

ในทำนองเดียวกัน การแก้ไขรายงานใหม่จะจำเป็นต้องมีคิวรีที่ส่งสำหรับแต่ละขั้นตอนในเส้นทางเพื่อสร้างวิชวลขั้นสุดท้าย

มีการแคชของผลลัพธ์บางอย่าง การรีเฟรชวิชวลเกิดขึ้นทันทีหากได้ผลลัพธ์ที่เหมือนกันเมื่อเร็ว ๆ นี้ ถ้ามีการกำหนดการรักษาความปลอดภัยระดับแถว การแคชข้อมูลดังกล่าวจะไม่ถูกแชร์ไประหว่างผู้ใช้

การรีเฟรชแดชบอร์ด

สามารถผักหมุดวิชวลส่วนบุคคล หรือทั้งหน้า เป็นไทล์ในแดชบอร์ด ไทล์ที่ยึดตามชุดข้อมูล DirectQuery จะรีเฟรชโดยอัตโนมัติตามกำหนดการ ไทล์ส่งคิวรีไปยังแหล่งข้อมูลหลังบ้าน ตามค่าเริ่มต้น ชุดข้อมูลจะรีเฟรชทุกชั่วโมง แต่สามารถกำหนดค่าให้เป็นส่วนหนึ่งของการตั้งค่า ชุดข้อมูล ให้เป็นระหว่างรายสัปดาห์ และทุก 15 นาที

ถ้าไม่มีการกำหนดการรักษาความปลอดภัยระดับแถวในแบบจำลอง แต่ละไทล์จะถูกรีเฟรชหนึ่งครั้ง และผลลัพธ์จะใช้ร่วมกันกับผู้ใช้ทั้งหมด มิฉะนั้น อาจเป็นผลตัวคูณขนาดใหญ่ แต่ละไทล์จำเป็นต้องมีคิวรีที่แยกต่างหากต่อผู้ใช้ที่จะส่งไปยังแหล่งข้อมูลต้นแบบ

แดชบอร์ดที่มีไทล์ 10 ไทล์ที่ใช้ร่วมกับผู้ใช้ 100 ราย และสร้างในชุดข้อมูลโดยใช้ DirectQuery ที่มีการรักษาความปลอดภัยระดับแถว และกำหนดค่าการรีเฟรชทุก 15 นาที จะส่งผลให้มีการส่งคิวรีอย่างน้อย 1000 คิวรีไปยังแหล่งข้อมูลหลังบ้านในทุก 15 นาที

ต้องพิจารณาอย่างรอบคอบในการใช้การรักษาความปลอดภัยระดับแถว และการกำหนดค่ากำหนดการรีเฟรช

หมดเวลา

การหมดเวลาสี่นาทีจะถูกนำไปใช้กับคิวรีแต่ละรายการในบริการ Power BI คิวรีใช้เวลานานกว่าที่จะล้มเหลว ตามที่เน้นไว้ก่อนหน้านี้ เราขอแนะนำให้คุณใช้ DirectQuery สำหรับแหล่งข้อมูลซึ่งมีประสิทธิภาพใกล้เคียงกับคิวรีแบบโต้ตอบ ขีดจำกัดนี้มีวัตถุประสงค์เพื่อป้องกันปัญหาจากการดำเนินการนานเกินไป

ผลกระทบอื่น ๆ

ผลกระทบทั่วไปอื่น ๆ จากการใช้ DirectQuery มีดังต่อไปนี้:

• ถ้าข้อมูลมีการเปลี่ยนแปลง จำเป็นต้องรีเฟรชเพื่อให้แน่ใจว่ามีข้อมูลล่าสุดแสดงอยู่: การใช้แคชจะไม่รับประกันว่าวิชวลจะแสดงข้อมูลล่าสุดอยู่ตลอดเวลา ตัวอย่างเช่น วิชวลอาจแสดงธุรกรรมในวันสุดท้าย เนื่องจากมีการเปลี่ยนแปลงตัวแบ่งส่วนข้อมูล ดังกล่าวอาจรีเฟรชเพื่อแสดงธุรกรรมสำหรับสองวันล่าสุด ธุรกรรมนี้อาจรวมถึงธุรกรรมที่มาใหม่ล่าสุด การส่งกลับตัวแบ่งส่วนไปยังค่าเดิมจะส่งผลให้มีการแสดงค่าแคชที่ได้รับก่อนหน้านี้อีกครั้ง

  การเลือก รีเฟรช จะล้างแคชต่าง ๆ และรีเฟรชวิชวลทั้งหมดในหน้าเพื่อแสดงข้อมูลล่าสุด

• ถ้าข้อมูลมีการเปลี่ยนแปลง จะไม่มีการรับประกันความสอดคล้องระหว่างวิชวล: สำหรับวิชวลอื่นไม่ว่าจะอยู่ในหน้าเดียวกันหรือหน้าอื่น อาจถูกรีเฟรชในเวลาที่ต่างกัน ถ้ามีการเปลี่ยนแปลงข้อมูลในแหล่งข้อมูลต้นแบบ จะไม่สามารถรับประกันได้ว่า แต่ละวิชวลจะสามารถแสดงข้อมูล ณ จุดเวลาเดียวกัน โดยความเป็นจริงแล้วในบางครั้งจำเป็นต้องมีคิวรีมากกว่าหนึ่งคิวรีสำหรับวิชวลเดี่ยว ตัวอย่างเช่น เพื่อขอรับรายละเอียดและผลรวม จึงไม่สามารถรับประกันความสอดคล้องแม้กระทั่งภายในวิชวลแบบเดียว เพื่อรับประกันความสอดคล้องนี้ อาจจำเป็นต้องเสียค่าใช้จ่ายการสำหรับการรีเฟรชวิชวลทั้งหมดเมื่อใดก็ตามที่มีการรีเฟรชวิชวลต่าง ๆ ควบคู่ไปกับการใช้คุณสมบัติที่มีราคาแพง เช่น Snapshot Isolation ในแหล่งข้อมูลต้นแบบ

  ปัญหานี้สามารถบรรเทาลงได้อย่างมากโดยการเลือก รีเฟรช เพื่อรีเฟรชวิชวลทั้งหมดในหน้า ถึงแม้ว่าจะใช้โหมดการนำเข้า แต่จะยังคงเกิดปัญหาเช่นเดียวกับการรับประกันความสอดคล้อง ในขณะที่มีการนำเข้าข้อมูลจากตารางมากกว่าหนึ่งตาราง

• จำเป็นต้องรีเฟรชใน Power BI Desktop เพื่อแสดงการเปลี่ยนแปลง Metadata: หลังจากเผยแพร่รายงานแล้ว รีเฟรช จะรีเฟรชวิชวลในรายงาน ถ้ามีการเปลี่ยนแปลงสคีมาของแหล่งข้อมูลต้นแบบ จะไม่มีการนำการเปลี่ยนแปลงเหล่านั้นมาใช้โดยอัตโนมัติเพื่อเปลี่ยนแปลงเขตข้อมูลที่มีอยู่ในรายการเขตข้อมูล ถ้ามีการลบตารางหรือคอลัมน์ออกจากแหล่งข้อมูลต้นแบบ อาจทำให้เกิดความล้มเหลวของของคิวรีเมื่อมีการรีเฟรช การเปิดรายงานใน Power BI Desktop และการเลือก รีเฟรช จะอัปเดตเขตข้อมูลในแบบจำลองเพื่อให้สอดคล้องกับการเปลี่ยนแปลง

• ข้อจำกัดของการส่งกลับแถว 1 ล้านแถวในคิวรีใดก็ตาม: มีข้อจำกัดคงที่ของการวางแถว 1 ล้านแถวในแถวจำนวนมากที่สามารถส่งกลับในรูปแบบคิวรีเดี่ยวต่าง ๆ ไปยังแหล่งข้อมูลเบื้องต้น โดยทั่วไปข้อจำกัดนี้ไม่มีผลกระทบในทางปฏิบัติ และตัววิชวลเองจะไม่แสดงหลายจุด อย่างไรก็ตาม ข้อจำกัดอาจเกิดขึ้นในกรณีที่ Power BI ไม่มีการปรับให้เหมาะสมกับคิวรีที่ส่งได้อย่างสมบูรณ์ และมีการขอผลลัพธ์ขั้นกลางที่เกินข้อจำกัด นอกจากนี้ยังสามารถเกิดขึ้นได้ในขณะที่สร้างวิชวลในเส้นทางสู่สถานะสุดท้ายที่สมเหตุสมผลยิ่งขึ้น ตัวอย่างเช่น การรวมทั้ง Customer และ TotalSalesQuantity จะทำให้ถึงข้อจำกัดนี้หากมีลูกค้ามากกว่า 1 ล้านราย จนกว่าจะมีการใช้ตัวกรองบางชนิด

  ข้อผิดพลาดที่จะถูกส่งกลับจะเป็น: "ชุดผลลัพธ์ของคิวรีต่อแหล่งข้อมูลภายนอกเกินกว่าค่าขนาดสูงสุดที่ได้รับอนุญาตของแถว '1000000' แถว"

• ไม่สามารถเปลี่ยนจากโหมดนำเข้าเป็นโหมด DirectQuery: โปรดทราบว่า โดยทั่วไปสามารถเปลี่ยนแบบจำลองจากโหมด DirectQuery ไปใช้โหมดการนำเข้าได้ แต่ต้องมีการนำเข้าข้อมูลที่จำเป็นทั้งหมด นอกจากนี้ยังไม่สามารถสลับกลับไปได้ โดยเบื้องต้นเนื่องมาจากชุดของคุณลักษณะไม่ได้รับการสนับสนุนในโหมด DirectQuery นอกจากนี้แบบจำลอง DirectQuery ผ่านแหล่งข้อมูลหลายมิติ เช่น SAP BW ยังไม่สามารถเปลี่ยนจาก DirectQuery ไปเป็นการนำเข้า เนื่องจากการจัดการที่แตกต่างกันของหน่วยวัดภายนอก

DirectQuery ในบริการ Power BI

แหล่งข้อมูลทั้งหมดได้รับการสนับสนุนจาก Power BI Desktop แหล่งข้อมูลบางแหล่งพร้อมใช้งานจากภายในบริการ Power BI โดยตรง ตัวอย่างเช่น ผู้ใช้ทางธุรกิจอาจสามารถใช้ Power BI เพื่อเชื่อมต่อกับข้อมูลของพวกเขาใน Salesforce และรับแดชบอร์ดได้ทันทีโดยไม่ต้องใช้ Power BI Desktop

แหล่งข้อมูลที่เปิดใช้ DirectQuery เพียงสองแหล่งจะพร้อมใช้งานในบริการโดยตรง

• Spark
• Azure Synapsy Analytics (เดิมSQLคลังข้อมูล)

อย่างไรก็ตาม เราขอแนะนำเป็นอย่างยิ่งว่าการใช้ DirectQuery ผ่านทั้งสองแหล่งข้อมูลนั้นควรเริ่มต้นภายใน Power BI Desktop เหตุผลก็คือเมื่อการเชื่อมต่อเกิดขึ้นครั้งแรกในบริการ Power BI จะมีข้อจำกัดสำคัญมากมาย ในขณะที่จุดเริ่มต้นนั้นง่าย แต่การเริ่มต้นในบริการ Power BI มีข้อจำกัดในการปรับปรุงรายงานผลลัพธ์เพิ่มเติม ตัวอย่างเช่น ไม่สามารถสร้างการคำนวณ หรือใช้คุณลักษณะการวิเคราะห์จำนวนมาก หรือแม้แต่รีเฟรชเมตาดาต้าเพื่อสะท้อนการเปลี่ยนแปลงใดก็ตามกับสคีมาต้นแบบ

คำแนะนำสำหรับการใช้ DirectQuery อย่างเป็นผลสำเร็จ

ถ้าคุณกำลังใช้ DirectQuery ในส่วนนี้จะแสดงคำแนะนำระดับสูงบางส่วนเกี่ยวกับวิธีการตรวจสอบความสำเร็จ คำแนะนำในส่วนนี้ได้รับมาจากผลกระทบของการใช้ DirectQuery ที่มีการอธิบายไว้ในบทความนี้

ประสิทธิภาพของแหล่งข้อมูลหลังบ้าน

ตรวจสอบว่าวิชวลแบบง่ายรีเฟรชในเวลาที่เหมาะสมหรือไม่ เวลาการรีเฟรชควรอยู่ภายใน 5 วินาที เพื่อให้มีประสบการณ์เชิงโต้ตอบที่เหมาะสม ถ้าวิชวลใช้เวลานานกว่า 30 วินาที มีความเป็นไปได้อย่างสูงว่าปัญหาอื่นเพิ่มเติม จะเกิดขึ้นตามมาหลังจากการเผยแพร่รายงาน ปัญหาเหล่านี้สามารถทำให้แนวทางการแก้ปัญหาใช้งานไม่ได้

ถ้าคิวรีใช้เวลานาน ให้ตรวจสอบคิวรีที่ถูกส่งไปยังแหล่งข้อมูลต้นแบบ และเหตุผลสำหรับประสิทธิภาพการทำงานของคิวรี หัวข้อนี้ไม่ครอบคลุมถึงแนวทางปฏิบัติที่ดีที่สุดในการเพิ่มประสิทธิภาพฐานข้อมูลทั่วทั้งชุดของแหล่งข้อมูลต้นแบบ บทความนี้จะครอบคลุมแนวทางปฏิบัติที่เป็นมาตรฐานสำหรับฐานข้อมูล ซึ่งสามารถใช้ได้กับสถานการณ์ส่วนใหญ่:

• โดยทั่วไปแล้วความสัมพันธ์ที่ยึดตามคอลัมน์จำนวนเต็มจะทำงานได้ดีกว่าการรวมอยู่ในคอลัมน์ของชนิดข้อมูลอื่น ๆ
• ควรมีการสร้างดัชนีที่เหมาะสม โดยทั่วไปการสร้างดัชนี หมายถึงการใช้ดัชนีจัดเก็บคอลัมน์ในแหล่งข้อมูลที่สนับสนุนดัชนีนั้น ตัวอย่างเช่น SQL Server
• สถิติใดก็ตามที่จำเป็นในแหล่งข้อมูลควรได้รับการอัปเดต

คำแนะนำการออกแบบแบบจำลอง

เมื่อกำหนดแบบจำลอง ให้ลองทำตามคำแนะนำนี้:

• หลีกเลี่ยงคิวรีที่ซับซ้อนตัวแก้ไข Power Queryรายงาน ตัวแก้ไข Power Queryแปลคิวรีที่ซับซ้อนให้เป็นคิวรีSQLเดียว คิวรีเดียวจะปรากฏในการเลือกย่อยของทุกคิวรีที่ส่งไปยังตารางนั้น ถ้าคิวรีมีความซับซ้อน อาจทำให้เกิดปัญหาเกี่ยวกับประสิทธิภาพการทำงานในทุกคิวรีที่ส่ง สามารถรับSQLคิวรีที่แท้จริงสามชุดขั้นตอนได้โดยการเลือกขั้นตอนสุดท้ายตัวแก้ไข Power Queryแล้วเลือก ดูคิวรีเนทิ ฟจากเมนูบริบทได้

• เก็บหน่วยวัดแบบง่าย อย่างน้อยในขั้นตอนแรก เราขอแนะนำให้จำกัดหน่วยวัดเป็นผลรวมอย่างง่าย ถ้าหน่วยวัดดำเนินการในลักษณะที่น่าพอใจ จะสามารถกำหนดหน่วยวัดที่ซับซ้อนมากขึ้นได้ แต่ควรให้ความสนใจกับประสิทธิภาพของแต่ละหน่วยวัดด้วยเช่นกัน

• หลีกเลี่ยงความสัมพันธ์ในคอลัมน์จากการคำนวณ คำแนะนำนี้เกี่ยวข้องกับฐานข้อมูลที่คุณจำเป็นต้องทำการรวมแบบหลายคอลัมน์ Power BI ปัจจุบันนี้ไม่อนุญาตให้ความสัมพันธ์ยึดตามคอลัมน์หลายคอลัมน์เหมือนกับ FK/PK การแก้ไขปัญหาชั่วคราวคือ การรวมคอลัมน์เข้าด้วยกันโดยใช้คอลัมน์จากการคำนวณและสร้างฐานการรวมบนคอลัมน์นั้น ในขณะที่การแก้ปัญหานี้เหมาะสมสำหรับข้อมูลที่นำเข้าสำหรับ DirectQuery จะส่งผลให้มีการรวมในนิพจน์ ซึ่งโดยทั่วไปแล้วจะป้องกันการใช้ดัชนีใดก็ตาม และนำไปสู่ประสิทธิภาพการทำงานที่ไม่ดี การแก้ไขปัญหาชั่วคราวคือการทำให้หลายคอลัมน์กลายเป็นคอลัมน์เดี่ยวในฐานข้อมูลต้นแบบ

• หลีกเลี่ยงความสัมพันธ์บนคอลัมน์ตัวระบุที่ไม่ซ้ำกัน Power BI ไม่สนับสนุนชนิดข้อมูลของ uniqueidentifier การระบุความสัมพันธ์ระหว่างคอลัมน์ของชนิดคอลัมน์ uniqueidentifier จะส่งผลให้มีการคิวรีด้วยการรวมที่เกี่ยวข้องกับ Cast อีกครั้ง วิธีการนี้จะทำให้ประสิทธิภาพการทำงานแย่ลง จนกว่ากรณีนี้จะได้รับการปรับให้เหมาะสม การแก้ไขปัญหาชั่วคราวเป็นเพียงกาสร้างคอลัมน์ของประเภททางเลือกในฐานข้อมูลต้นแบบเท่านั้น

• ซ่อนไปยังคอลัมน์ในความสัมพันธ์ คอลัมน์ ถึง ในความสัมพันธ์มักเป็นคีย์หลักในตาราง ถึง คอลัมน์นั้นควรถูกซ่อนไว้ ถ้าซ่อนแล้ว คอลัมน์จะไม่ปรากฏในรายการเขตข้อมูลและไม่สามารถใช้ในวิชวลได้ บ่อยครั้งที่คอลัมน์ที่ความสัมพันธ์เป็นไปตามความเป็นข้อเท็จจริง คอลัมน์ระบบ ตัวอย่างเช่น คีย์สำรองในคลังข้อมูล นี่คือแนวทางปฏิบัติที่ดีในการซ่อนคอลัมน์ดังกล่าว ถ้าคอลัมน์มีความหมาย ให้เปิดคอลัมน์จากการคำนวณที่มองเห็นได้ และที่มีนิพจน์อย่างง่ายที่เท่ากับคีย์หลัก ดังในตัวอย่างต่อไปนี้:

      ProductKey_PK   (Destination of a relationship, hidden)
      ProductKey (= [ProductKey_PK],   visible)
      ProductName
      ...
  

• ตรวจสอบการใช้งานทั้งหมดของคอลัมน์จากการคำนวณและการเปลี่ยนแปลงชนิดข้อมูล การใช้ความสามารถเหล่านี้ไม่จำเป็นต้องเป็นอันตราย ซึ่งจะส่งผลให้คิวรีถูกส่งไปยังแหล่งข้อมูลต้นแบบที่ประกอบด้วยนิพจน์แทนที่จะเป็นการอ้างอิงอย่างง่ายไปยังคอลัมน์ ซึ่งอาจส่งผลให้ไม่มีการใช้ดัชนีอีกครั้ง

• หลีกเลี่ยงการใช้ตัวกรองแบบไขว้สองทิศทางในความสัมพันธ์ การใช้การกรองแบบไขว้สองทิศทางสามารถทำให้คำสั่งคิวรีทำงานได้ไม่ดี

• การทดลองกับการตั้งค่า Assume referential integrity. การตั้งค่า Assume Referential Integrity ในความสัมพันธ์ทำให้คิวรีสามารถใช้งานคำสั่ง INNER JOIN แทนการใช้คำสั่ง OUTER JOIN ซึ่งโดยทั่วไปแล้วคำแนะนำนี้จะช่วยปรับปรุงประสิทธิภาพการทำงานของคิวรี แม้ว่าจะขึ้นอยู่กับข้อมูลจำเพาะของแหล่งข้อมูล

• อย่าใช้การกรองข้อมูลสัมพัทธ์ในตัวแก้ไข Power Queryข้อมูล คุณสามารถกําหนดการกรองวันที่ที่สัมพันธ์กันตัวแก้ไข Power Queryตาราง ตัวอย่างเช่น การกรองแถวที่วันที่ที่อยู่ใน 14 วันที่ผ่านมา

  

  อย่างไรก็ตาม ตัวกรองนี้จะถูกแปลให้เป็นตัวกรองที่ยึดตามวันที่คงที่ ตามเวลาที่คิวรีถูกสร้างขึ้น ซึ่งคุณสามารถดูผลลัพธ์ได้จากการดูคิวรีเนทิฟ

  

  ผลลัพธ์นี้อาจไม่ใช่สิ่งที่คุณต้องการ เพื่อให้แน่ใจว่าตัวกรองถูกนำไปใช้ตามวันที่ในเวลาที่รายงานทำงาน ให้ใช้ตัวกรองในรายงานเป็นตัวกรองรายงานแทน ในปัจจุบันนี้ วิธีการนี้สามารถดำเนินการให้เสร็จได้โดยการสร้างคอลัมน์จากการคำนวณที่คำนวณจำนวนวันที่ผ่านมา โดยใช้ฟังก์ชัน DAX DATE() และใช้คอลัมน์จากคำนวณในตัวกรอง

คำแนะนำการออกแบบรายงาน

เมื่อสร้างรายงานโดยใช้การเชื่อมต่อ DirectQuery โปรดทำตามคำแนะนำต่อไปนี้:

• พิจารณาการใช้ตัวเลือกการลดคิวรี: Power BI มีตัวเลือกในรายงานเพื่อให้ส่งคิวรีน้อยลง และเพื่อปิดใช้งานการโต้ตอบบางอย่างที่จะส่งผลให้ประสบการณ์การทำงานแย่ลง หากคิวรีที่เป็นผลลัพธ์ใช้เวลานานในการดำเนินการ เมื่อต้องการเข้าถึงตัวเลือกเหล่านี้ใน Power BI Desktop ไปที่ ไฟล์ > ตัวเลือกและการตั้งค่า > ตัวเลือก แล้วเลือก การลดคิวรี

  

  การทำเครื่องหมายที่กล่องการเลือกใน การลดคิวรี จะช่วยให้คุณปิดใช้งานการเน้นแบบไขว้กับรายงานทั้งหมดของคุณ คุณยังสามารถแสดงปุ่ม นำไปใช้ กับตัวแบ่งส่วนข้อมูลหรือตัวเลือกตัวกรองได้ วิธีการนี้ช่วยให้คุณทำการเลือกตัวแบ่งส่วนข้อมูลและตัวกรองจำนวนมากก่อนที่จะนำไปใช้ ไม่มีการส่งคิวรีจนกว่าคุณจะเลือกปุ่ม นำไปใช้ บนตัวแบ่งส่วนข้อมูล จากนั้นการเลือกของคุณจะสามารถใช้เพื่อกรองข้อมูลได้

  ตัวเลือกเหล่านี้จะนำไปใช้กับรายงานของคุณในขณะที่คุณโต้ตอบกับ Power BI Desktop ตัวเลือกเหล่านี้ยังจะนำไปใช้เมื่อผู้ใช้ของคุณใช้งานรายงานในบริการ Power BI อีกด้วย

• ใช้ตัวกรองเป็นอันดับแรก: ใช้ตัวกรองที่เหมาะสมทุกครั้งเมื่อเริ่มสร้างวิชวล ตัวอย่างเช่น แทนที่จะลากใน TotalSalesAmount และ ProductName จากนั้นกรองเป็นปีใดปีหนึ่ง แต่คุณสามารถใช้ตัวกรองกับ Year ตั้งแต่เริ่มต้นได้ แต่ละขั้นตอนของการสร้างวิชวลจะส่งคิวรี ถึงแม้ว่าคุณสามารถทำการเปลี่ยนแปลงอื่นก่อนที่คิวรีแรกจะเสร็จสิ้นได้ แต่วิธีการนี้จะทำให้เกิดโหลดที่ไม่จำเป็นในแหล่งข้อมูลต้นแบบ การใช้ตัวกรองในช่วงแรก โดยทั่วไปแล้วจะทำให้คิวรีขั้นกลางมีค่าใช้จ่ายน้อย นอกจากนี้ การที่ไม่สามารถใช้ตัวกรองได้ในช่วงแรกอาจส่งผลให้ถึงขีดจำกัดแถว 1 ล้านแถวได้

• จำกัดจำนวนของวิชวลในหน้า: เมื่อคุณเปิดหน้าหรือเปลี่ยนแปลงตัวแบ่งส่วนข้อมูลระดับหน้าหรือตัวกรอง วิชวลทั้งหมดในหน้าจะได้รับการรีเฟรช นอกจากนี้ยังมีขีดจำกัดในเรื่องจำนวนของคิวรีที่ถูกส่งไปพร้อมกัน ดังนั้นจำนวนของวิชวลจึงเพิ่มขึ้น วิชวลบางส่วนจะถูกรีเฟรชในลักษณะอนุกรม ทำให้เวลาที่ใช้ในการรีเฟรชทั้งหน้าเพิ่มขึ้น ด้วยเหตุผลนี้ เราขอแนะนำให้คุณจำกัดจำนวนของวิชวลในหน้าเดียว แทนที่จะมีหน้าได้ง่ายขึ้น จำนวนหลายหน้า

• พิจารณาปิดการโต้ตอบระหว่างวิชวล: ตามค่าเริ่มต้น สามารถใช้การแสดงภาพบนหน้ารายงานเพื่อกรองแบบไขว้และไฮไลท์ข้ามไปยังแสดงภาพอื่น ๆ ในหน้าดังกล่าว ตัวอย่างเช่น เลือก 1999 ในแผนภูมิวงกลม และแผนภูมิคอลัมน์จะถูกเน้นแบบไขว้เพื่อแสดงยอดขายตามประเภทสำหรับ 1999

  

  การกรองข้ามและการไฮไลต์แบบเชื่อมโยงใน DirectQuery จะต้องมีการส่งคิวรีไปยังแหล่งข้อมูลต้นแบบ ควรปิดการโต้ตอบ ถ้าเวลาที่ใช้ในการตอบสนองต่อการเลือกของผู้ใช้จะใช้เวลานานเกินสมควร คุณสามารถปิดการโต้ตอบนี้ได้ ปิดการโต้ตอบนี้สำหรับรายงานทั้งหมด ตามที่อธิบายไว้ด้านบนสำหรับตัวเลือกการลดคิวรี หรือเป็นกรณี ๆ ไป สำหรับข้อมูลเพิ่มเติม โปรดดู วิธีการใช้วิชวลกรองข้ามกันในรายงาน Power BI

นอกเหนือจากรายการแนะนำก่อนหน้า แต่ละความสามารถในการรายงานต่อไปนี้อาจก่อให้เกิดปัญหาด้านประสิทธิภาพการทำงาน

• ตัวกรองหน่วยวัด: วิชวลที่มีหน่วยวัด หรือการรวมของคอลัมน์ อาจมีตัวกรองในหน่วยวัดเหล่านั้น ตัวอย่างเช่น กราฟิกต่อไปนี้แสดง SalesAmount ตาม Category แต่เพียงแค่รวมประเภทเหล่านั้นกับยอดขายที่มากกว่า 20M

  

  วิธีการนี้ส่งผลให้มีการส่งคิวรีสองคิวรีไปยังแหล่งข้อมูลต้นแบบ

  • คิวรีแรกดึงข้อมูลหมวดหมู่ที่ตรงตามเงื่อนไข SalesAmount มากกว่า 20 ล้านเหรียญ
  • คิวรีที่สองเรียกใช้ข้อมูลจำเป็นสำหรับวิชวล รวมถึงหมวดหมู่ที่ตรงตามเงื่อนไขในคำสั่ง WHERE

  ซึ่งโดยทั่วไปแล้ววิธีการนี้จะทำงานได้ดี หากมีหลายร้อยหรือหลายพันประเภท ตามตัวอย่างนี้ ประสิทธิภาพอาจลดลงหากจำนวนหมวดหมู่ใหญ่กว่ามาก คิวรีล้มเหลวสำหรับหมวดหมู่มากกว่าล้านรายการที่ตรงตามเงื่อนไข ก่อนหน้านี้มีการกล่าวถึงขีดจำกัดจำนวน 1 ล้านแถว

• ตัวกรอง TopN: สามารถกำหนดตัวกรองขั้นสูงเพื่อกรองเฉพาะค่า N สูงสุด (หรือต่ำสุด) เท่านั้นที่จัดอันดับด้วยหน่วยวัดบางตัว ตัวอย่างเช่น ตัวกรองสามารถมีหมวดหมู่ 10 อันดับแรกในวิชวลก่อนหน้า วิธีการนี้ส่งผลให้มีการส่งคิวรีสองคิวรีไปยังแหล่งข้อมูลต้นแบบอีกครั้ง อย่างไรก็ตาม คิวรีแรกจะส่งกลับทุกประเภทจากแหล่งข้อมูลต้นแบบ และ TopN จะถูกกำหนดโดยยึดตามผลลัพธ์ที่ส่งกลับ วิธีการนี้อาจทำให้เกิดปัญหาด้านประสิทธิภาพการทำงานหรือความล้มเหลวของคิวรีเนื่องจากขีดจำกัดแถว 1 ล้านแถว ซึ่งขึ้นอยู่กับคาร์ดินัลลิติ้ของคอลัมน์เกี่ยวข้อง

• ค่ากลาง: โดยทั่วไปแล้ว การรวมใดก็ตาม เช่น Sum หรือ Count Distinct จะถูกผลักไปยังแหล่งข้อมูลต้นแบบ อย่างไรก็ตาม ข้อเท็จจริงนี้ไม่เป็นความจริงสำหรับค่ามัธยฐาน ซึ่งโดยทั่วไปแล้วการรวมนี้ไม่ได้รับการสนับสนุนโดยแหล่งข้อมูลต้นแบบ ในกรณีดังกล่าว ข้อมูลรายละเอียดจะถูกดึงมาจากแหล่งข้อมูลต้นแบบ และคำนวณค่ามัธยฐานจากผลลัพธ์ที่ส่งกลับ วิธีการนี้จะเหมาะสมเมื่อมีการคำนวณค่ามัธยฐานในจำนวนของผลลัพธ์ที่ค่อนข้างน้อย ปัญหาด้านประสิทธิภาพการทำงานหรือคิวรีล้มเหลวเนื่องจากขีดจำกัดแถว 1 ล้านแถว จะเกิดขึ้นหากคาร์ดินาลลิตี้มีขนาดใหญ่ ตัวอย่างเช่น Median Country Population อาจเหมาะสม แต่ Median Sales Price อาจไม่เหมาะสม

• ตัวกรองข้อความขั้นสูง (ประกอบด้วย และคล้ายกัน): เมื่อกรองข้อมูลในคอลัมน์ข้อความ การกรองขั้นสูงจะอนุญาตตัวกรองเช่น ประกอบด้วย และ เริ่มต้นด้วย และอื่น ๆ ตัวกรองเหล่านี้อาจทำให้ประสิทธิภาพการทำงานลดลงสำหรับแหล่งข้อมูลบางแหล่ง และไม่ควรใช้ตัวกรอง ประกอบด้วย ตามค่าเริ่มต้นหากสิ่งที่ต้องการคือการจับคู่แบบตรงทั้งหมด แม้ว่าผลลัพธ์อาจจะเหมือนกัน โดยขึ้นอยู่กับข้อมูลจริง ประสิทธิภาพการทำงานอาจแตกต่างกันอย่างมากเนื่องจากการใช้ดัชนี

• ตัวแบ่งส่วนข้อมูลแบบหลายตัวเลือก: ตามค่าเริ่มต้น ตัวแบ่งส่วนข้อมูลจะอนุญาตให้ดำเนินการเลือกเดียวเท่านั้น การอนุญาตการเลือกตัวกรองหลายตัวอาจทำให้เกิดปัญหาด้านประสิทธิภาพเนื่องจากผู้ใช้เลือกชุดรายการในตัวแบ่งส่วนข้อมูล ตัวอย่างเช่น ถ้าผู้ใช้เลือกผลิตภัณฑ์ที่มีความสนใจ 10 รายการ แต่ละผลลัพธ์การเลือกใหม่ในคิวรีจะถูกส่งไปยังแหล่งข้อมูล แม้ว่าผู้ใช้สามารถเลือกรายการถัดไปก่อนที่คิวรีจะเสร็จสมบูรณ์ วิธีการนี้จะส่งผลให้มีโหลดเพิ่มเติมในแหล่งข้อมูลต้นแบบ

• พิจารณาปิดผลรวมในวิชวล: ตามค่าเริ่มต้น ตารางและเมทริกซ์จะแสดงผลรวมและผลรวมย่อย ในหลายกรณี คิวรีแบบแยกต้องถูกส่งไปยังแหล่งข้อมูลต้นแบบเพื่อรับค่าสำหรับผลรวมดังกล่าว ข้อเท็จจริงนี้จะนำไปใช้เมื่อใดก็ตามที่มีการใช้การรวมของ DistinctCount หรือในกรณีทั้งหมดที่ใช้ DirectQuery ผ่าน SAP BW หรือ SAP HANA ผลรวมดังกล่าวควรจะปิดโดยใช้บานหน้าต่าง รูปแบบ

จำนวนสูงสุดของตัวเลือกการเชื่อมต่อสำหรับ DirectQuery

คุณสามารถตั้งค่าจำนวนสูงสุดของการเชื่อมต่อ DirectQuery เปิดขึ้นสำหรับแต่ละแหล่งข้อมูลต้นแบบ ซึ่งควบคุมจำนวนของคิวรีที่ส่งไปยังแต่ละแหล่งข้อมูลพร้อมกัน

DirectQuery จะเปิดการเชื่อมต่อพร้อมกันสูงสุด 10 รายการ ตามค่าเริ่มต้น คุณสามารถเปลี่ยนตัวเลขสูงสุดสำหรับไฟล์ปัจจุบันได้ใน Power BI Desktop ไปยังตัวเลือก ไฟล์ > และตัวเลือก > การตั้งค่า ในส่วน แฟ้ม ปัจจุบัน ในบานหน้าต่างด้านซ้าย ให้เลือก การตั้งค่าชุดข้อมูลที่ เผยแพร่

การตั้งค่าจะเปิดใช้งานเฉพาะเมื่อมีอย่างน้อยหนึ่งแหล่งข้อมูล DirectQuery ในรายงานปัจจุบัน ค่านำไปใช้ กับแหล่งข้อมูล DirectQuery ทั้งหมด และแหล่งข้อมูล DirectQuery ใด ๆ ใหม่ถูกเพิ่มลงในรายงานเดียวกัน

การเพิ่ม การเชื่อมต่อสูงสุดต่อแหล่งข้อมูล ช่วยให้แน่ใจว่ามีคิวรีมากขึ้น ถึงจำนวนสูงสุดที่ระบุไว้ ซึ่งสามารถส่งไปยังแหล่งข้อมูลต้นแบบได้ วิธีการนี้มีประโยชน์เมื่อมีวิชวลจำนวนมากอยู่ในหนึ่งหน้า หรือมีผู้ใช้จำนวนมากเข้าถึงรายงานในเวลาเดียวกัน เมื่อถึงขีดจำกัดจำนวนสูงสุดของการเชื่อมต่อ เพิ่มเติมคิวรีอยู่ในคิวจนกว่าการเชื่อมต่อจะพร้อมใช้งาน เพิ่มขีดจำกัดนี้ส่งผลในการโหลดบนแหล่งข้อมูลต้นแบบ เพิ่มเติมเพื่อให้การตั้งค่าไม่รับประกันว่า จะปรับปรุงประสิทธิภาพโดยรวม

เมื่อมีการเผยแพร่รายงาน จำนวนสูงสุดของคิวรีที่เกิดขึ้นพร้อมกันที่ส่งไปยังแหล่งข้อมูลต้นแบบจะขึ้นอยู่กับขีดจำกัดคงที่ ขีดจำกัดขึ้นอยู่กับสภาพแวดล้อมเป้าหมายที่มีการเผยแพร่รายงาน สภาพแวดล้อมต่าง ๆ เช่น Power BI, Power BI Premium หรือ เซิร์ฟเวอร์รายงาน Power BI สามารถกำหนดขีดจำกัดที่แตกต่างกัน

การวินิจฉัยปัญหาด้านประสิทธิภาพการทำงาน

ส่วนนี้จะอธิบายวิธีการวินิจฉัยปัญหาด้านประสิทธิภาพการทำงาน หรือวิธีการรับข้อมูลรายละเอียดเพิ่มเติมเพื่ออนุญาตให้รายงานได้รับการปรับให้เหมาะสม

เราขอแนะนำให้คุณเริ่มต้นการวินิจฉัยปัญหาด้านประสิทธิภาพการทำงานใน Power BI Desktop แทนที่จะเป็นในบริการ Power BI ปัญหาด้านประสิทธิภาพการทำงานมักจะขึ้นอยู่กับประสิทธิภาพการทำงานของแหล่งข้อมูลต้นแบบ คุณสามารถระบุและวินิจฉัยปัญหาได้ง่ายขึ้นในสภาพแวดล้อมที่แยกต่างหากมากขึ้นของ Power BI Desktop ในขั้นต้น วิธีการนี้จะกำจัดองค์ประกอบบางอย่าง เช่น เกตเวย์ Power BI ถ้าปัญหาด้านประสิทธิภาพการทำงานหายไปจาก Power BI Desktop ให้ตรวจสอบข้อมูลจำเพาะของรายงานในบริการ Power BI ตัววิเคราะห์ประสิทธิภาพเป็นเครื่องมือที่มีประโยชน์สำหรับการระบุปัญหาตลอดกระบวนการนี้

ในทำนองเดียวกัน เราขอแนะนำให้ก่อนอื่นลองแยกปัญหาต่าง ๆ ให้กับแต่ละวิชวล แทนการแยกให้กับหลายวิชวลในหน้าเดียว

สมมติว่าคุณได้ดำเนินการขั้นตอนในย่อหน้าก่อนในส่วนนี้แล้ว ตอนนี้เรามีวิชวลเดียวบนเพจใน Power BI Desktop ที่ยังคงเอื่อยเฉื่อยอยู่ ใช้ ตัววิเคราะห์ประสิทธิภาพ เพื่อประเมินคิวรีที่ Power BI Desktop ส่งไปยังแหล่งข้อมูลต้นแบบ นอกจากนี้ยังเป็นไปได้ที่จะดูการติดตามและข้อมูลการวินิจฉัยที่อาจถูกปล่อยออกมาจากแหล่งข้อมูลต้นแบบ การติดตามอาจมีรายละเอียดที่เป็นประโยชน์เกี่ยวกับวิธีดำเนินการคิวรี และวิธีการปรับปรุงคิวรี

นอกจากนี้ แม้ในกรณีที่ไม่มีร่องรอยดังกล่าวจากแหล่งที่มา คุณสามารถดคิวรีที่ส่งโดย Power BI พร้อมกับเวลาในการดำเนินการ ตามที่อธิบายไว้ในส่วนถัดไป

การกำหนดคิวรีที่ถูกส่ง โดย Power BI Desktop

ตามค่าเริ่มต้น Power BI Desktop จะบันทึกเหตุการณ์ในระหว่างเซสชันที่กำหนดไว้ไปยังไฟล์การติดตามที่ชื่อ FlightRecorderCurrent.trc

สำหรับบางแหล่งข้อมูล DirectQuery บันทึกนี้จะรวมคิวรีทั้งหมดที่ส่งไปยังแหล่งข้อมูลต้นแบบ แหล่งข้อมูล DirectQuery ที่เหลือจะรวมอยู่ในอนาคต แหล่งข้อมูลต่อไปนี้ส่งคิวรีไปยังบันทึก:

• SQL Server
• Azure SQL Database
• Azure Synapsy Analytics (เดิมSQLคลังข้อมูล)
• Oracle
• Teradata
• SAP HANA

สามารถพบแฟ้มการติดตามในโฟลเดอร์ AppData สำหรับผู้ใช้ปัจจุบัน

<User>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces

เมื่อต้องการไปโฟลเดอร์นี้ใน Power BI Desktop ให้เลือก ไฟล์ > ตัวเลือกและการตั้งค่า > ตัวเลือก แล้วเลือก การวินิจฉัย กล่องโต้ตอบต่อไปนี้จะปรากฏขึ้น:

เมื่อคุณเลือก เปิดโฟลเดอร์ crash dump/traces ที่อยู่ภายใต้ ตัวเลือกการวินิจฉัย โฟลเดอร์ต่อไปนี้จะเปิดขึ้น: <User>\AppData\Local\Microsoft\Power BI Desktop\Traces

การนำทางไปยังโฟลเดอร์หลักของโฟลเดอร์นั้นจะแสดงโฟลเดอร์ที่ประกอบด้วย AnalysisServicesWorkspaces ซึ่งจะประกอบด้วยโฟลเดอร์ของพื้นที่ทำงานหนึ่งสำหรับทุก ๆ อินสแตนซ์ที่เปิดของ Power BI Desktop โฟลเดอร์เหล่านี้จะได้รับการตั้งชื่อคำต่อท้ายที่เป็นจำนวนเต็ม เช่น AnalysisServicesWorkspace2058279583

ภายในโฟลเดอร์นั้นคือโฟลเดอร์ \Data ซึ่งประกอบด้วยไฟล์การติดตาม FlightRecorderCurrent.trc สำหรับเซสชัน Power BI ปัจจุบัน โฟลเดอร์พื้นที่ทำงานที่สอดคล้องกันจะถูกลบเมื่อสิ้นสุดเซสชัน Power BI Desktop ที่เชื่อมโยง

ไฟล์การติดตามสามารถอ่านได้โดยใช้เครื่องมือ SQL Server Profiler ได้รับเป็นส่วนหนึ่งของการดาวน์โหลดฟรี SQL Server Management Studio

เมื่อคุณดาวน์โหลด และติดตั้งSQL Server Management Studio ให้เรียกใช้ ตัวสร้างโพรไฟล์ของ SQL Server

เมื่อต้องเปิดไฟล์การติดตาม ทำตามขั้นตอนต่อไปนี้

1. ใน SQL Server Profiler ให้เลือก ไฟล์ > เปิด > ไฟล์การติดตาม

2. ใส่เส้นทางไปยังไฟล์ติดตามสำหรับเซสชัน Power BI เปิดอยู่ในปัจจุบัน เช่น C:\Users<user>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces\AnalysisServicesWorkspace2058279583\Data

3. เปิด FlightRecorderCurrent.trc

เหตุการณ์ทั้งหมดจากเซสชันปัจจุบันจะปรากฏขึ้น ตัวอย่างที่มีคำอธิบายประกอบจะแสดงที่นี่ ซึ่งเน้นกลุ่มของเหตุการณ์ แต่ละกลุ่มมีเหตุการณ์ดังต่อไปนี้:

• เหตุการณ์ Query Begin และ Query End ซึ่งแสดงจุดเริ่มต้นและสิ้นสุดของคิวรี DAX ที่สร้างขึ้น โดย UI ตัวอย่างเช่น จากวิชวลแบบ หรือ จากการเติมข้อมูลรายการของค่าในตัวกรอง UI
• เหตุการณ์ DirectQuery Begin และ DirectQuery End อย่างน้อยหนึ่งคู่ ซึ่งแสดงคิวรีที่ถูกส่งไปยังแหล่งข้อมูลต้นแบบ เป็นส่วนหนึ่งของการประเมินผลคิวรี DAX

คิวรี DAX หลายรายการสามารถเรียกใช้พร้อมกันได้ ดังนั้นเหตุการณ์จากกลุ่มที่แตกต่างกันสามารถสอดแทรกกันได้ ค่าของ ActivityID สามารถใช้เพื่อกำหนดว่าเหตุการณ์ใดที่อยู่ในกลุ่มเดียวกัน

คอลัมน์อื่น ๆ ที่สนใจมีดังนี้:

• ข้อมูลข้อความ: รายละเอียดข้อความของเหตุการณ์ สำหรับเหตุการณ์ Query Begin/End รายละเอียดคือคิวรี DAX สำหรับเหตุการณ์ DirectQuery Begin/End รายละเอียดคือคิวรี SQL ที่ส่งไปยังแหล่งข้อมูลต้นแบบ TextData สำหรับเหตุการณ์ที่เลือกในปัจจุบันจะแสดงในบริเวณที่ด้านล่าง
• เวลาสิ้นสุด: เวลาเมื่อเหตุการณ์เสร็จสมบูรณ์
• ระยะเวลา: ระยะเวลาที่ใช้ในการดำเนินการคิวรี DAX หรือ SQL ในหน่วยมิลลิวินาที
• ข้อผิดพลาด: บ่งชี้ว่ามีข้อผิดพลาดเกิดขึ้นหรือไม่ ในกรณีนี้เหตุการณ์ที่แสดงจะเป็นสีแดง

โปรดทราบว่าในภาพด้านบน คอลัมน์ที่ดูไม่น่าสนใจบางส่วนได้รับการจำกัดให้แคบลง เพื่ออนุญาตให้คอลัมน์อื่นมองเห็นได้ง่ายขึ้น

เราขอแนะนำวิธีการต่อไปนี้ในการจับภาพการติดตามเพื่อช่วยในการวินิจฉัยปัญหาด้านประสิทธิภาพการทำงานอาจเกิดขึ้น:

• เปิดเซสชัน Power BI Desktop เดียวเพื่อหลีกเลี่ยงความสับสนของโฟลเดอร์พื้นที่ทำงานหลายรายการ
• ใช้ชุดการดำเนินการที่น่าสนใจใน Power BI Desktop รวมถึงการดำเนินการเพิ่มเติมบางอย่าง เพื่อให้แน่ใจว่าเหตุการณ์ที่น่าสนใจจะถูกใส่ลงในไฟล์การติดตาม
• เปิด SQL Server Profiler และตรวจสอบการติดตาม ตามที่อธิบายไว้ก่อนหน้านี้ โปรดทราบว่าการปิด Power BI Desktop จะลบไฟล์การติดตาม นอกจากนี้ การดำเนินการเพิ่มเติมใน Power BI Desktop จะไม่ปรากฏขึ้นทันที ต้องปิดและเปิดไฟล์การติดตามใหม่เพื่อดูเหตุการณ์ใหม่
• ทำให้แต่ละเซสชันมีขนาดเล็กพอสมควร อาจเป็น 10 วินาทีของการดำเนินการ ไม่ใช่หลายร้อย วิธีการนี้ช่วยให้ตีความไฟล์ติดตามได้ง่ายขึ้น นอกจากนี้ยังมีขีดจำกัดของขนาดของไฟล์การติดตามอีกด้วย สำหรับเซสชันแบบยาว มีโอกาสที่เหตุการณ์ช่วงแรกจะหายไป

การทำความเข้าใจเกี่ยวกับรูปแบบของคิวรีที่ถูกส่งโดย Power BI Desktop

รูปแบบทั่วไปของคิวรีที่สร้าง และส่งโดย Power BI Desktop ใช้การเลือกย่อยสำหรับแต่ละตารางที่อ้างอิง คิวตัวแก้ไข Power Queryกําหนดการเลือกย่อย ตัวอย่างเช่น สมมติว่าตาราง TPC DS ต่อไปนี้อยู่ใน SQL Server

พิจารณาคิวรีต่อไปนี้

คิวรีนั้นจะส่งผลในวิชวลต่อไปนี้

การรีเฟรชวิชวลนั้นจะส่งผลให้คิวรี SQL แสดงที่นี่ ตามที่คุณสามารถบอกได้ว่ามีการเลือกย่อยสามส่วนสำหรับ Web Sales Item และ Date_dim ซึ่งแต่ะละส่วนจะส่งคืนคอลัมน์ทั้งหมดในตารางที่เกี่ยวข้อง แม้ว่าจะมีเพียงสี่คอมลัมน์ที่การอ้างอิงโดยวิชวล คิวรีเหล่านี้ในการเลือกย่อยที่ถูกแรเงาจะตรงกับผลลัพธ์ของคิวรีที่กําหนดตัวแก้ไข Power Queryแบบสอบถาม ไม่พบว่าการใช้การเลือกย่อยในลักษณะนี้มีผลกระทบต่อประสิทธิภาพการทำงาน สำหรับแหล่งข้อมูลที่ได้รับการสนับสนุนสำหรับ DirectQuery แหล่งข้อมูล เช่น SQL Server จะปรับการอ้างอิงไปยังคอลัมน์อื่น ๆ ให้เหมาะสม

Power BI ใช้รูปแบบนี้เนื่องจากคิวรี SQL ที่ใช้สามารถจัดเตรียมได้จากนักวิเคราะห์โดยตรง ซึ่งใช้ "ตามที่ระบุ" โดยไม่ต้องพยายามเขียนใหม่

ขั้นตอนถัดไป

บทความนี้อธิบายลักษณะของ DirectQuery ที่ใช้กันทั่วทั้งแหล่งข้อมูลทั้งหมด มีรายละเอียดที่เฉพาะเจาะจงสำหรับแต่ละแหล่งข้อมูล ดูหัวข้อต่อไปนี้ที่ครอบคลุมแหล่งข้อมูลที่เฉพาะ

• DirectQuery และ SAP HANA
• DirectQuery และ SAP BW

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ DirectQuery โปรดดูทรัพยากรต่อไปนี้:

• แหล่งข้อมูลที่สนับสนุนโดย DirectQuery