DirectQuery ใน Power BI

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

บทความนี้อธิบาย:

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

บทความนี้มุ่งเน้นไปที่เวิร์กโฟลว์ DirectQuery เมื่อคุณสร้างรายงานใน Power BI Desktop แต่ยังครอบคลุมการเชื่อมต่อผ่านทาง DirectQuery ในบริการของ Power BI

หมายเหตุ

DirectQuery ยังเป็นคุณลักษณะของ SQL Server Analysis Services คุณลักษณะดังกล่าวมีรายละเอียดมากมายกับ Direct Query ใน Power BI แต่ยังมีความแตกต่างที่สําคัญ บทความนี้ครอบคลุม DirectQuery ด้วย Power BI ไม่ใช่ SQL Server Analysis Services

สําหรับข้อมูลเพิ่มเติมเกี่ยวกับ DirectQuery กับ SQL Server Analysis Services โปรดดู ใช้ DirectQuery สําหรับแบบจําลองความหมายของ Power BI และ Analysis Services (ตัวอย่าง) คุณยังสามารถดาวน์โหลด PDF DirectQuery ใน SQL Server 2016 Analysis Services ได้

โหมดการเชื่อมต่อข้อมูล Power BI

Power BI เชื่อมต่อกับแหล่งข้อมูลที่แตกต่างกันจํานวนมาก เช่น:

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

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

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

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

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

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

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

เมื่อคุณเชื่อมต่อกับแหล่งข้อมูล เช่น SQL Server และนําเข้าข้อมูลใน Power BI Desktop ผลลัพธ์ต่อไปนี้จะเกิดขึ้น:

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

• เมื่อมีการโหลด ข้อมูลทั้งหมดที่กําหนดโดยคิวรีจะนําเข้าลงในแคช Power BI

• การสร้างวิชวลภายใน Power BI Desktop จะคิวรีข้อมูลที่แคชไว้ Power BI store ช่วยให้มั่นใจได้ว่าการคิวรีจะรวดเร็วและการเปลี่ยนแปลงทั้งหมดไปยังวิชวลจะแสดงทันที

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

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

• การเปิดรายงานที่มีอยู่หรือเขียนรายงานใหม่ในบริการของ Power BI จะคิวรีข้อมูลที่นําเข้าอีกครั้งเพื่อให้มั่นใจถึงการโต้ตอบ

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

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

เมื่อคุณใช้ DirectQuery เพื่อเชื่อมต่อกับแหล่งข้อมูลใน Power BI Desktop ผลลัพธ์ต่อไปนี้จะเกิดขึ้น:

• คุณใช้ รับข้อมูล เพื่อเลือกแหล่งข้อมูล สําหรับแหล่งข้อมูลเชิงสัมพันธ์ คุณยังคงสามารถเลือกชุดของตารางที่กําหนดคิวรีที่จะส่งกลับชุดข้อมูลตามหลักตรรกะ สําหรับแหล่งข้อมูลหลายมิติ เช่น SAP Business Warehouse (SAP BW) คุณเลือกเฉพาะแหล่งข้อมูล

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

• การเปลี่ยนแปลงใด ๆ กับข้อมูลต้นแบบจะไม่มีผลกับวิชวลที่มีอยู่ทันที ซึ่งยังคงจําเป็นต้องรีเฟรช Power BI Desktop จะส่งคิวรีที่จําเป็นสําหรับแต่ละวิชวลอีกครั้ง และอัปเดตวิชวลตามความจําเป็น

• การเผยแพร่รายงานไปยังบริการของ Power BI จะสร้างและอัปโหลดแบบจําลองความหมายเหมือนกับการนําเข้า อย่างไรก็ตาม แบบจําลองความหมายนั้นไม่มีข้อมูล

• การเปิดรายงานที่มีอยู่หรือเขียนรายงานใหม่ในบริการของ Power BI คิวรีแหล่งข้อมูลพื้นฐานเพื่อดึงข้อมูลที่จําเป็น อาจจําเป็นต้องกําหนดค่าเกตเวย์ข้อมูลภายในองค์กรเพื่อให้ได้ข้อมูล โดยขึ้นอยู่กับตําแหน่งที่ตั้งของแหล่งข้อมูลต้นฉบับ

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

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

การเชื่อมต่อแบบสด

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

ตัวอย่างเช่น เมื่อคุณใช้การนําเข้าเพื่อเชื่อมต่อกับ 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 ต้นแบบ อาจต้องใช้เกตเวย์ข้อมูลภายในองค์กร

• ไทล์แดชบอร์ดจะรีเฟรชโดยอัตโนมัติตามกําหนดการ เช่น ทุกชั่วโมง

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

กรณีการใช้งาน DirectQuery

เชื่อมต่อด้วย DirectQuery จะมีประโยชน์ในสถานการณ์ต่อไปนี้ ในหลายกรณีเหล่านี้การทิ้งข้อมูลไว้ในตําแหน่งต้นทางเดิมเป็นสิ่งจําเป็นหรือเป็นประโยชน์

DirectQuery ใน Power BI มีประโยชน์สูงสุดในสถานการณ์ต่อไปนี้:

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

การเปลี่ยนแปลงข้อมูลบ่อยครั้งและคุณต้องการการรายงานแบบ "เรียลไทม์"

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

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

ข้อมูลมีขนาดใหญ่มาก

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

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

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

แหล่งข้อมูลต้นแบบกําหนดกฎความปลอดภัย

เมื่อคุณนําเข้าข้อมูล Power BI จะเชื่อมต่อกับแหล่งข้อมูลโดยใช้ข้อมูลประจําตัวของ Power BI Desktop ของผู้ใช้ปัจจุบัน หรือข้อมูลประจําตัวที่กําหนดค่าสําหรับรีเฟรชตามกําหนดการจากบริการของ Power BI ในการเผยแพร่และแบ่งปันรายงานที่มีข้อมูลที่นําเข้า คุณต้องระมัดระวังในการแชร์กับผู้ใช้ที่ได้รับอนุญาตให้ดูข้อมูลเท่านั้น หรือคุณต้องกําหนดให้ row-level security เป็นส่วนหนึ่งของแบบจําลองความหมาย

DirectQuery ช่วยให้ข้อมูลประจําตัวของผู้ดูรายงานส่งผ่านไปยังแหล่งข้อมูลต้นแบบ ซึ่งใช้กฎความปลอดภัย DirectQuery สนับสนุนการลงชื่อเข้าระบบครั้งเดียว (SSO) ไปยังแหล่งข้อมูล Azure SQL และผ่านเกตเวย์ข้อมูลไปยังเซิร์ฟเวอร์ SQL ภายในองค์กร สําหรับข้อมูลเพิ่มเติม ดูภาพรวมของการลงชื่อเข้าใช้ครั้งเดียว (SSO) สําหรับเกตเวย์ใน Power BI

ใช้ข้อจํากัดด้านอํานาจข้อมูล

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

แหล่งข้อมูลต้นแบบใช้หน่วยวัด

แหล่งข้อมูลพื้นฐาน เช่น SAP HANA หรือ SAP BW ประกอบด้วยหน่วยวัด หน่วยวัดหมายความว่าข้อมูลที่นําเข้ามีอยู่แล้วในระดับหนึ่งของการรวมตามที่กําหนดโดยคิวรี วิชวลที่ขอข้อมูลในการรวมระดับสูงกว่า เช่น TotalSales ตาม Year จะรวมค่ารวมเพิ่มเติม การรวมนี้ใช้ได้สําหรับหน่วยวัดเสริม เช่น Sum และ Min แต่อาจเป็นปัญหาสําหรับหน่วยวัดที่ไม่ใช่หน่วยวัดเสริม เช่น Average และ DistinctCount

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

ขณะนี้ DirectQuery บน SAP HANA ถือว่าข้อมูลเหมือนกับแหล่งข้อมูลเชิงสัมพันธ์ และสร้างลักษณะการทํางานคล้ายกับการนําเข้า สําหรับข้อมูลเพิ่มเติม ดู DirectQuery และ SAP HANA

ข้อจํากัดของ DirectQuery

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

ความหมายโดยนัยทั่วไป

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

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

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

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

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

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

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

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

  หมายเหตุ

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

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

ผลกระทบต่อประสิทธิภาพและโหลด

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

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

ความหมายโดยนัยของความปลอดภัย

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

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

• เชื่อมต่อไปยังแบบจําลองความหมายของ Power BI และบริการวิเคราะห์ในโหมด DirectQuery จะใช้ SSO เสมอ ดังนั้นความปลอดภัยจึงคล้ายกับการเชื่อมต่อแบบสดไปยัง Analysis Services

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

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

ข้อจํากัดการแปลงข้อมูล

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

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

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

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

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

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

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

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

ข้อจํากัดต่อไปนี้มีทั่วไปในแหล่งข้อมูล DirectQuery ทั้งหมด ข้อจํากัดเพิ่มเติมอาจนําไปใช้กับแต่ละแหล่งข้อมูล

• ไม่มีลําดับชั้นของวันที่แบบติดตั้งมาในตัว: ด้วยข้อมูลที่นําเข้า ทุกคอลัมน์วันที่/วันที่และเวลายังมีลําดับชั้นวันที่แบบติดตั้งมาในตัวจะพร้อมใช้งานเป็นค่าเริ่มต้น ตัวอย่างเช่น ถ้าคุณนําเข้าตารางใบสั่งขายที่มีคอลัมน์ OrderDate และคุณใช้ OrderDate ในวิชวล คุณสามารถเลือกระดับวันที่ที่เหมาะสมที่จะใช้ เช่น ปี เดือน หรือวันได้ ลําดับชั้นของวันแบบติดตั้งมาในตัวนี้ไม่พร้อมใช้งานกับ DirectQuery ถ้ามี ตาราง วันที่ ที่พร้อมใช้งานในแหล่งข้อมูลต้นแบบ ซึ่งมีอยู่ทั่วไปในคลังข้อมูลจํานวนมาก คุณสามารถใช้ฟังก์ชันตัวแสดงเวลา Data Analysis Expressions (DAX) ได้ตามปกติ

• วันที่/เวลารองรับเฉพาะระดับวินาที: สําหรับแบบจําลองเชิงความหมายที่ใช้คอลัมน์เวลา Power BI จะออกการคิวรีไปยังแหล่งข้อมูล DirectQuery พื้นฐานจนถึงระดับรายละเอียดวินาทีเท่านั้น ไม่ใช่มิลลิวินาที ลบข้อมูลหน่วยมิลลิวินาทีออกจากคอลัมน์ต้นทางของคุณ

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

• ไม่มีการสนับสนุนสําหรับฟังก์ชัน DAX หลัก-รอง: เมื่ออยู่ในโหมด DirectQuery จะไม่สามารถใช้ตระกูลฟังก์ชัน DAX PATH() ที่มักจะจัดการโครงสร้างหลัก-รอง เช่น แผนภูมิของบัญชีหรือลําดับชั้นของพนักงาน

• ไม่มีการคลัสเตอร์ริ่ง: เมื่อคุณใช้ DirectQuery คุณไม่สามารถใช้ความสามารถในการคลัสเตอร์ริ่งเพื่อค้นหากลุ่มโดยอัตโนมัติ

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

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

ข้อจํากัดโดยทั่วไปข้อหนึ่งคือ ความยาวสูงสุดของข้อมูลในคอลัมน์ข้อความสําหรับแบบจําลองความหมาย DirectQuery คือ 32,764 อักขระ การรายงานข้อความที่ยาวกว่าจะส่งผลให้เกิดข้อผิดพลาด

ความสามารถในการรายงาน Power BI ต่อไปนี้อาจทําให้เกิดปัญหาด้านประสิทธิภาพในรายงานที่ยึดตาม DirectQuery:

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

  

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

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

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

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

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

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

• ตัวกรองข้อความขั้นสูง เช่น 'ประกอบด้วย': การกรองขั้นสูงในคอลัมน์ข้อความจะอนุญาตตัวกรองเช่น contains และbegins with ตัวกรองเหล่านี้อาจส่งผลให้ประสิทธิภาพการทํางานลดลงสําหรับแหล่งข้อมูลบางแหล่ง โดยเฉพาะอย่างยิ่ง อย่าใช้ตัวกรองเริ่มต้น contains หากคุณต้องการข้อมูลที่ตรงกัน แม้ว่าผลลัพธ์อาจเหมือนกัน โดยขึ้นอยู่กับข้อมูลจริง ประสิทธิภาพการทํางานอาจแตกต่างกันอย่างมากเนื่องจากดัชนี

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

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

คําแนะนํา DirectQuery

ส่วนนี้ให้คําแนะนําระดับสูงเกี่ยวกับวิธีการใช้ DirectQuery ให้ผลที่ตามมา

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

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

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

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

• เพื่อประสิทธิภาพการทํางานที่ดีขึ้น ยึดตามความสัมพันธ์ในคอลัมน์จํานวนเต็ม แทนที่จะรวมคอลัมน์ของชนิดข้อมูลอื่น ๆ

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

• อัปเดตสถิติที่จําเป็นในแหล่งข้อมูล

การออกแบบแบบจําลอง

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

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

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

• หลีกเลี่ยงความสัมพันธ์บนคอลัมน์จากการคํานวณ ในฐานข้อมูลที่คุณจําเป็นต้องทําการรวมแบบหลายคอลัมน์ Power BI ไม่อนุญาตให้ใช้ความสัมพันธ์เบสกับหลายคอลัมน์เป็นคีย์หลักหรือ Foreign Key การแก้ไขปัญหาชั่วคราวคือ การเชื่อมโยงคอลัมน์โดยใช้คอลัมน์จากการคํานวณและสร้างฐานการรวมบนคอลัมน์นั้น

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

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

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

  ถ้าคอลัมน์มีความหมาย ให้เปิดคอลัมน์จากการคํานวณที่มองเห็นได้ และที่มีนิพจน์อย่างง่ายที่เท่ากับคีย์หลัก ตัวอย่างเช่น:

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

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

• หลีกเลี่ยงการกรองแบบไขว้สองทิศทางในความสัมพันธ์ การใช้การกรองแบบไขว้สองทิศทางอาจทําให้คําสั่งคิวรีทํางานได้ไม่ดี สําหรับข้อมูลเพิ่มเติมเกี่ยวกับการกรองแบบไขว้แบบสองทิศทาง ให้ดู เปิดใช้งานการกรองแบบไขว้แบบสองทิศทางสําหรับ DirectQuery ใน Power BI Desktop หรือดาวน์โหลด เอกสารทางเทคนิคการกรอง ข้ามแบบสองทิศทาง ตัวอย่างในเอกสารมีไว้สําหรับ SQL Server Analysis Services แต่จุดพื้นฐานจะใช้กับ Power BI เช่นกัน

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

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

  

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

  

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

การออกแบบรายงาน

เมื่อคุณสร้างรายงานที่ใช้การเชื่อมต่อ DirectQuery ให้ทําตามคําแนะนําต่อไปนี้:

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

  หากต้องการเข้าถึงตัวเลือกเหล่านี้ใน Power BI Desktop ให้ไปที่ ไฟล์>ตัวเลือกและการตั้งค่า>ตัวเลือก และเลือก การลดคิวรี

  

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

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

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

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

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

  

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

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

จํานวนสูงสุดของการเชื่อมต่อ

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

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

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

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

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

สภาพแวดล้อม	ขีดจํากัดสูงสุดต่อแหล่งข้อมูล
Power BI Pro	การเชื่อมต่อที่ใช้งานอยู่ 10 รายการ
Power BI พรีเมียม	ขึ้นอยู่กับข้อจํากัด SKU ของแบบจําลองความหมาย
เซิร์ฟเวอร์รายงาน Power BI	การเชื่อมต่อที่ใช้งานอยู่ 10 รายการ

หมายเหตุ

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

DirectQuery ในบริการของ Power BI

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

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

• Spark
• Azure Synapse Analytics (ชื่อเดิมคือ SQL Data Warehouse)

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

ประสิทธิภาพของรายงาน DirectQuery ในบริการของ Power BI จะขึ้นอยู่กับระดับของโหลดที่วางอยู่บนแหล่งข้อมูลต้นแบบ การโหลดขึ้นอยู่กับ:

• จํานวนผู้ใช้ที่แชร์รายงานและแดชบอร์ด
• ความซับซ้อนของรายงาน
• รายงานกําหนดความปลอดภัยระดับแถวหรือไม่

ลักษณะการทํางานของรายงานในบริการของ Power BI

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

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

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

การใช้ DirectQuery กําหนดข้อจํากัดที่สําคัญบางอย่างในความสามารถบางอย่างที่บริการของ Power BI เสนอให้สําหรับรายงานที่เผยแพร่:

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

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

• Excel จะไม่แสดงลําดับชั้น: ตัวอย่างเช่น เมื่อคุณใช้ การวิเคราะห์ใน Excel Excel จะไม่แสดงลําดับชั้นใด ๆ ที่กําหนดไว้ในแบบจําลองบริการวิเคราะห์ Azure หรือแบบจําลองความหมายของ Power BI ที่ใช้ DirectQuery

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

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

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

อาจมีผลตัวคูณขนาดใหญ่ แดชบอร์ดที่มีไทล์ 10 ไทล์ที่ใช้ร่วมกับผู้ใช้ 100 ราย ซึ่งสร้างในแบบจําลองเชิงความหมายโดยใช้ DirectQuery ที่มีการรักษาความปลอดภัยระดับแถว ส่งผลให้มีการส่งคิวรีอย่างน้อย 1000 คิวรีไปยังแหล่งข้อมูลพื้นฐานสําหรับทุกการรีเฟรช ให้ข้อพิจารณาอย่างรอบคอบในการใช้การรักษาความปลอดภัยระดับแถวและการกําหนดค่าของกําหนดการรีเฟรช

หมดเวลาคิวรี

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

การวินิจฉัยประสิทธิภาพ

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

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

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

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

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

ใช้ตัวสร้างโพรไฟล์ของเซิร์ฟเวอร์ SQL เพื่อดูคิวรี

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

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

• SQL Server
• ฐานข้อมูล Azure SQL
• Azure Synapse Analytics (ชื่อเดิมคือ SQL Data Warehouse)
• Oracle
• Teradata
• SAP HANA

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

เมื่อต้องการเปิดไฟล์การติดตามสําหรับเซสชันปัจจุบัน ให้ทําดังนี้

1. ในระหว่างเซสชัน Power BI Desktop เลือก ไฟล์>ตัวเลือกและการตั้งค่า>ตัวเลือก จากนั้นเลือก การวินิจฉัย

2. ภายใต้ คอลเลกชันบันทึกข้อมูลการหยุดทํางาน เลือก เปิดโฟลเดอร์บันทึกข้อมูลหยุดทํางาน/การติดตาม

   

   โฟลเดอร์ Power BI Desktop\Traces จะเปิดขึ้น

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

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

4. เปิด SQL Server Profiler และเลือก ไฟล์>เปิด>ไฟล์การติดตาม

5. นําทางไปยังหรือป้อนเส้นทางไปยังไฟล์การติดตามสําหรับเซสชัน Power BI ปัจจุบัน และเปิด FlightRecorderCurrent.trc

SQL Server Profiler แสดงเหตุการณ์ทั้งหมดจากเซสชันปัจจุบัน สกรีนช็อตต่อไปนี้เน้นกลุ่มของเหตุการณ์สําหรับคิวรี แต่ละกลุ่มคิวรีมีเหตุการณ์ต่อไปนี้:

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

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

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

คอลัมน์ต่อไปนี้ก็น่าสนใจเช่นกัน:

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

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

1. เปิดเซสชัน Power BI Desktop เดียวเพื่อหลีกเลี่ยงความสับสนของโฟลเดอร์พื้นที่ทํางานหลายรายการ

2. ทําชุดของการกระทําที่น่าสนใจใน Power BI Desktop รวมถึงการดําเนินการเพิ่มเติมบางอย่าง เพื่อให้แน่ใจว่าเหตุการณ์ที่น่าสนใจจะถูกใส่ลงในไฟล์การติดตาม

3. เปิด SQL Server Profiler และตรวจสอบการติดตาม โปรดทราบว่าการปิด Power BI Desktop จะลบไฟล์การติดตาม นอกจากนี้ การดําเนินการเพิ่มเติมใน Power BI Desktop จะไม่ปรากฏขึ้นทันที คุณต้องปิดและเปิดไฟล์การติดตามใหม่เพื่อดูเหตุการณ์ใหม่

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

ทําความเข้าใจรูปแบบของคิวรี

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

การเรียกใช้คิวรีต่อไปนี้:

SalesAmount (SUMX(Web_Sales, [ws_sales_price]*[ws_quantity]))
by Item[i_category]
for Date_dim[d_year] = 2000

ผลลัพธ์ในวิชวลต่อไปนี้ใน Power BI:

การรีเฟรชวิชวลนั้นจะสร้างคิวรี SQL ในรูปภาพต่อไปนี้ มีคิวรีการเลือกย่อยสามรายการสําหรับ Web_Sales, Itemและ Date_dimซึ่งแต่ละรายการจะส่งกลับคอลัมน์ทั้งหมดในตารางที่เกี่ยวข้อง แม้ว่าวิชวลจะอ้างอิงเพียงสี่คอลัมน์เท่านั้น

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

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

เนื้อหาที่เกี่ยวข้อง

สําหรับข้อมูลเพิ่มเติมเกี่ยวกับ DirectQuery ใน Power BI โปรดดู:

• ใช้ DataQuery ใน Power BI Desktop

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

• DirectQuery และ SAP HANA
• DirectQuery และ SAP BW
• ใช้ DirectQuery สําหรับแบบจําลองความหมาย Power BI และบริการวิเคราะห์