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

คุณสามารถเชื่อมต่อกับแหล่งข้อมูลต่าง ๆ ได้ทุกประเภท เมื่อใช้Power BI Desktopหรือบริการ Power BIและคุณสามารถทำการเชื่อมต่อข้อมูลเหล่านั้นด้วยวิธีต่าง ๆ ได้You can connect to all sorts of different data sources when using Power BI Desktop or the Power BI service, and make those data connections in different ways. คุณสามารถนำเข้าข้อมูลไปยัง Power BI ซึ่งเป็นวิธีทั่วไปในการรับข้อมูล หรือคุณสามารถเชื่อมต่อโดยตรงไปยังข้อมูลในที่เก็บแหล่งข้อมูลดั้งเดิม หรือที่เรียกว่าDirectQueryYou can import data to Power BI, which is the most common way to get data, or connect directly to data in the original source repository, which is known as DirectQuery. บทความนี้อธิบายความสามารถของ DirectQuery:This article describes DirectQuery capabilities:

  • ตัวเลือกการเชื่อมต่อที่แตกต่างกันสำหรับ DirectQueryDifferent connectivity options for DirectQuery
  • คำแนะนำว่าเมื่อใดที่คุณควรใช้ DirectQuery แทนการนำเข้าGuidance for when you should consider using DirectQuery rather than import
  • ข้อเสียของการใช้ DirectQueryDrawbacks of using DirectQuery
  • แนวทางปฏิบัติที่ดีที่สุดสำหรับการใช้ DirectQueryBest practices for using DirectQuery

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

  • คุณควรนำเข้าข้อมูลไปยัง Power BI ทุกที่ที่เป็นไปได้You should import data to Power BI wherever possible. การนำเข้าข้อมูลจะใช้ประโยชน์จากกลไกจัดการคิวรีประสิทธิภาพสูงของ Power BI และมอบประสบการณ์ที่มีการโต้ตอบสูงและโดดเด่นImporting takes advantage of the high performance query engine of Power BI, and provides a highly interactive and fully featured experience.
  • ถ้าเป้าหมายของคุณไม่สามารถดำเนินการนำเข้าข้อมูล โปรดพิจารณาการใช้ DirectQueryIf your goals can't be met by importing data, consider using DirectQuery. ตัวอย่างเช่น ถ้าข้อมูลมีการเปลี่ยนแปลงบ่อย และรายงานต้องแสดงข้อมูลล่าสุด การใช้ DirectQuery อาจที่ดีที่สุดFor example, if the data is changing frequently and reports must reflect the latest data, DirectQuery may be best. อย่างไรก็ตาม จะสามารถใช้ DirectQuery ได้เมื่อแหล่งข้อมูลต้นแบบมีคิวรีแบบโต้ตอบ น้อยกว่า 5 วินาที สำหรับคิวรีรวมทั่วไป และสามารถจัดการกับการโหลดคิวรีที่จะสร้างขึ้นHowever, using DirectQuery is only feasible when the underlying data source can provide interactive queries, less than 5 seconds for the typical aggregate query, and can handle the query load that will be generated. นอกจากนี้ ควรพิจารณารายการของข้อจำกัดสำหรับการใช้งาน DirectQuery อย่างรอบคอบ เพื่อให้แน่ใจว่ายังคงสามารถดำเนินการตามเป้าหมายของคุณAdditionally, the list of limitations for the use of DirectQuery should be considered carefully.

ชุดของความสามารถที่เสนอโดย Power BI สำหรับการนำเข้าและ DirectQuery มีการพัฒนาตลอดเวลาThe set of capabilities offered by Power BI for import and DirectQuery evolve over time. การเปลี่ยนแปลงจะรวมถึงการให้ความยืดหยุ่นมากขึ้นเมื่อมีการใช้ข้อมูลที่นำเข้า และการนำเข้านั้นสามารถใช้ได้ในหลายกรณี และสามารถกำจัดข้อเสียบางส่วนของการใช้ DirectQueryChanges will include providing more flexibility when using imported data, such that import can be used in more cases and eliminating some of the drawbacks of using DirectQuery. เมื่อใช้ DirectQuery ประสิทธิภาพของแหล่งข้อมูลต้นแบบยังคงเป็นข้อพิจารณาหลักอยู่เสมอ โดยไม่คำนึงถึงการปรับปรุงRegardless of improvements, when using DirectQuery, the performance of the underlying data source always remains a major consideration. ถ้าแหล่งข้อมูลต้นแบบนั้นช้า ให้ใช้ DirectQuery และแหล่งข้อมูลนั้นจะยังไม่สามารถดำเนินการได้If that underlying data source is slow, using DirectQuery for that source will remain unfeasible.

บทความนี้ครอบคลุม DirectQuery กับ Power BI แต่ไม่รวมถึง SQL Server Analysis ServicesThis article covers DirectQuery with Power BI, and not SQL Server Analysis Services. DirectQuery ยังเป็นคุณลักษณะของ SQL Server Analysis ServicesDirectQuery is also a feature of SQL Server Analysis Services. รายละเอียดหลายอย่างที่อธิบายไว้ในบทความนี้นำไปใช้กับคุณลักษณะนั้นMany of the details described in this article apply to that feature. นอกจากนี้ยังมีความแตกต่างที่สำคัญอีกด้วยThere are also important differences. สำหรับข้อมูลเกี่ยวกับการใช้ DirectQuery กับ SQL Server Analysis Services โปรดดู DirectQuery ใน SQL Server 2016 Analysis ServicesFor information about using DirectQuery with SQL Server Analysis Services, see DirectQuery in SQL Server 2016 Analysis Services.

บทความนี้มุ่งเน้นไปที่สมุดงานที่แนะนำสำหรับ DirectQuery ซึ่งรายงานจะถูกสร้างใน Power BI Desktop แต่ยังคงครอบคลุมถึงการเชื่อมต่อโดยตรงในบริการ Power BIThis article focuses on the recommended workflow for DirectQuery, where the report is created in Power BI Desktop, but also covers connecting directly in the Power BI service.

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

Power BI เชื่อมต่อกับแหล่งข้อมูลที่แตกต่างกันจำนวนมาก ครอบคลุมไปถึง:Power BI connects to a large number of varied data sources, encompassing:

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

สำหรับแหล่งข้อมูลเหล่านี้ จะสามารถนำเข้าข้อมูลไปยัง Power BI ได้For these sources, it's possible to import the data to Power BI. บางแหล่งข้อมูลยังสามารถเชื่อมต่อโดยใช้ DirectQuery ได้อีกด้วยFor some, it's also possible to connect using DirectQuery. สำหรับข้อสรุปของแหล่งข้อมูลที่สนับสนุน DirectQuery โปรดดู แหล่งข้อมูลที่ DirectQuery สนับสนุนFor a summary of the sources that support DirectQuery, see Data Sources supported by DirectQuery. แหล่งข้อมูลเพิ่มเติมที่จะเปิดใช้งาน DirectQuery ในอนาคต จะมุ่งเน้นที่แหล่งข้อมูลที่คาดว่าจะสามารถแสดงประสิทธิภาพการทำงานคิวรีแบบโต้ตอบได้ดีMore sources will be DirectQuery enabled in the future, focusing primarily on sources that can be expected to deliver good interactive query performance.

SQL Server Analysis Services เป็นกรณีพิเศษSQL Server Analysis Services is a special case. เมื่อเชื่อมต่อกับ SQL Server Analysis Services คุณสามารถเลือกที่จะนำเข้าข้อมูล หรือใช้การเชื่อมต่อแบบสด (Live Connection) ได้When connecting to SQL Server Analysis Services, you can choose to import the data or use a live connection. การใช้การเชื่อมต่อแบบสดจะเหมือนกับ DirectQueryUsing a live connection is similar to DirectQuery. ไม่มีการนำเข้าข้อมูล และมีการคิวรีแหล่งข้อมูลต้นแบบเพื่อรีเฟรชวิชวลเสมอNo data is imported and the underlying data source is always queried to refresh a visual. การเชื่อมต่อแบบสดนั้นแตกต่างกันไปในหลาย ๆ ด้าน ดังนั้นคำศัพท์ที่ใช้จึงแตกต่างกันด้วยระหว่าง การเชื่อมต่อแบบสด กับ DirectQueryA live connection is different in many other regards, so a different term, live connection versus DirectQuery, is used.

ตัวเลือกสำหรับการเชื่อมต่อกับข้อมูลทั้งสามตัวเลือกนี้: นำเข้า, DirectQuery และ การเชื่อมต่อแบบสดThese three options for connecting to data: import, DirectQuery, and live connection.

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

สำหรับการนำเข้า เมื่อใช้รับข้อมูลใน Power BI Desktop เพื่อเชื่อมต่อกับแหล่งข้อมูลเช่น SQL Server ลักษณะการทำงานของการเชื่อมต่อดังกล่าวจะเป็นดังนี้:For import, when using Get Data in Power BI Desktop to connect to a data source like SQL Server, the behavior of that connection is as follows:

  • ในระหว่างประสบการณ์การใช้งาน รับข้อมูล เริ่มต้น ชุดของตารางที่เลือกแต่ละรายการจะกำหนดคิวรีที่จะส่งคืนชุดข้อมูลDuring the initial Get Data experience, the set of tables selected each define a query that will return a set of data. คุณสามารถแก้ไขคิวรีเหล่านั้นได้ก่อนการโหลดข้อมูล ตัวอย่างเช่น เมื่อต้องการใช้ตัวกรอง หรือรวมข้อมูล หรือต่อตารางที่แตกต่างเข้าด้วยกันThose queries can be edited before loading the data, for example, to apply filters, or aggregate the data, or join different tables.
  • เมื่อมีการโหลด ข้อมูลทั้งหมดที่กำหนดโดยคิวรีเหล่านั้นจะได้รับการนำเข้าลงในแคช Power BIUpon load, all of the data defined by those queries will be imported into the Power BI cache.
  • เมื่อสร้างวิชวลภายใน Power BI Desktop ข้อมูลที่นำเข้าจะถูกคิวรีUpon building a visual within Power BI Desktop, the imported data will be queried. Power BI store ช่วยให้มั่นใจว่าการคิวรีจะรวดเร็วThe Power BI store ensures the query will be fast. การเปลี่ยนแปลงทั้งหมดไปยังวิชวลจะปรากฏขึ้นทันทีAll changes to the visual are reflected immediately.
  • การเปลี่ยนแปลงใดก็ตามที่ทำกับข้อมูลต้นแบบจะไม่มีผลกับวิชวลAny changes to the underlying data aren't reflected in any visuals. จำเป็นต้อง รีเฟรช เพื่อนำเข้าข้อมูลอีกครั้งIt's necessary to Refresh to reimport data.
  • เมื่อมีการเผยแพร่รายงานเป็นไฟล์ .pbix ไปยังบริการ Power BI ชุดข้อมูลจะถูกสร้าง และอัปโหลดไปยังบริการ Power BIUpon publishing the report as a .pbix file to the Power BI service, a dataset is created and uploaded to the Power BI service. ข้อมูลนำเข้าจะรวมอยู่ในชุดข้อมูลนั้นThe imported data is included with that dataset. จากนั้นจะสามารถตั้งกำหนดเวลาการรีเฟรชของข้อมูลดังกล่าวได้ ตัวอย่างเช่น นำเข้าข้อมูลอีกครั้งทุกวันIt's then possible to schedule refresh of that data, for example, to reimport the data every day. อาจจำเป็นต้องกำหนดค่าเกตเวย์ข้อมูลภายในองค์กร โดยขึ้นอยู่กับตำแหน่งที่ตั้งของแหล่งข้อมูลต้นฉบับDepending upon the location of the original data source, it might be necessary to configure an on-premises data gateway.
  • เมื่อเปิดรายงานที่มีอยู่แล้วในบริการ Power BI หรือเขียนรายงานใหม่ ข้อมูลนำเข้าจะได้รับการคิวรีอีกครั้ง เพื่อยืนยันการโต้ตอบWhen opening an existing report in the Power BI service, or authoring a new report, the imported data is queried again, ensuring interactivity.
  • วิชวลหรือหน้ารายงานทั้งหมดสามารถปักหมุดเป็นไทล์แดชบอร์ดVisuals, or entire report pages, can be pinned as dashboard tiles. ไทล์จะรีเฟรชอัตโนมัติเมื่อชุดข้อมูลต้นแบบรีเฟรชThe tiles automatically refresh whenever the underlying dataset refreshes.

การเชื่อมต่อ DirectQueryDirectQuery connections

สำหรับ DirectQuery เมื่อใช้รับข้อมูลใน Power BI Desktop เพื่อเชื่อมต่อกับแหล่งข้อมูล ลักษณะการทำงานของการเชื่อมต่อจะเป็นดังนี้:For DirectQuery, when using Get Data in Power BI Desktop to connect to a data source, the behavior of that connection is as follows:

  • ในระหว่างประสบการณ์การใช้งาน รับข้อมูล เริ่มต้น แหล่งข้อมูลจะถูกเลือกDuring the initial Get Data experience, the source is selected. สำหรับแหล่งข้อมูลเชิงสัมพันธ์ ชุดตารางจะถูกเลือก และแต่ละชุดยังคงกำหนดคิวรีที่จะส่งกลับชุดข้อมูลตามหลักตรรกะFor relational sources, a set of tables are selected and each still define a query that logically returns a set of data. สำหรับแหล่งข้อมูลหลายมิติ เช่น SAP BW จะเลือกเฉพาะแหล่งข้อมูลเท่านั้นFor multidimensional sources, like SAP BW, only the source is selected.
  • อย่างไรก็ตาม เมื่อมีการโหลด จะไม่มีการนำเข้าไปยัง Power BI storeHowever, upon load, no data is imported into the Power BI store. แต่ให้ดำเนินการสร้างวิชวลภายใน Power BI Desktop คิวรีจะถูกส่งไปยังแหล่งข้อมูลต้นแบบเพื่อดึงข้อมูลจำเป็นออกมาInstead, upon building a visual within Power BI Desktop, queries are sent to the underlying data source to retrieve the necessary data. เวลาที่ใช้ในการรีเฟรชวิชวลจะขึ้นอยู่กับประสิทธิภาพของแหล่งข้อมูลต้นแบบThe time taken to refresh the visual depends on the performance of the underlying data source.
  • การเปลี่ยนแปลงใดก็ตามที่ทำกับข้อมูลต้นแบบไม่มีผลกับวิชวลที่มีอยู่โดยทันทีAny changes to the underlying data aren't immediately reflected in any existing visuals. ซึ่งคุณจำเป็นต้องรีเฟรชIt's still necessary to refresh. คิวรีที่จำเป็นสำหรับแต่ละวิชวลจะถูกส่งใหม่อีกครั้ง และจะมีการอัปเดตวิชวลตามความจำเป็นThe necessary queries are resent for each visual, and the visual is updated as necessary.
  • เมื่อมีการเผยแพร่รายงานไปยังบริการของ Power BI จะส่งผลกับชุดข้อมูลในบริการ Power BI เหมือนกับการนำเข้าอีกครั้งUpon publishing the report to the Power BI service, it will again result in a dataset in the Power BI service, the same as for import. อย่างไรก็ตามไม่มีข้อมูลใดรวมกับชุดข้อมูลนั้นHowever, no data is included with that dataset.
  • เมื่อเปิดรายงานที่มีอยู่ในบริการ Power BI หรือเขียนรายงานใหม่ แหล่งข้อมูลต้นแบบจะถูกคิวรีอีกครั้งเพื่อดึงข้อมูลจำเป็นWhen opening an existing report in the Power BI service, or authoring a new one, the underlying data source is again queried to retrieve the necessary data. อาจจำเป็นต้องกำหนดค่าเกตเวย์ข้อมูลภายในองค์กรโดยขึ้นอยู่กับตำแหน่งที่ตั้งของแหล่งข้อมูลต้นฉบับ เนื่องจากจำเป็นสำหรับโหมดนำเข้าหากข้อมูลถูกรีเฟรชDepending upon the location of the original data source, it might be necessary to configure an on-premises data gateway, as is needed for import mode if the data is refreshed.
  • วิชวลหรือหน้ารายงานทั้งหมดสามารถปักหมุดเป็นไทล์แดชบอร์ดVisuals, or entire report pages, can be pinned as Dashboard tiles. เพื่อให้แน่ใจว่าการเปิดแดชบอร์ดจะรวดเร็ว ไทล์จะถูกรีเฟรชโดยอัตโนมัติตามกำหนดการ ตัวอย่าง เช่น ทุกชั่วโมงTo ensure that opening a dashboard is fast, the tiles are automatically refreshed on a schedule, for example, every hour. คุณสามารถควบคุมความถี่ของการรีเฟรชนี้ เพื่อแสดงความถี่ที่ข้อมูลมีการเปลี่ยนแปลง และความสำคัญในการดูข้อมูลล่าสุดThe frequency of this refresh can be controlled, to reflect how frequently the data is changing, and how important it's to see the latest data. เมื่อเปิดแดชบอร์ด ไทล์จะแสดงข้อมูลตามเวลาการรีเฟรชล่าสุด และไม่จำเป็นต้องมีการเปลี่ยนแปลงล่าสุดที่ทำกับแหล่งข้อมูลต้นแบบWhen opening a dashboard, the tiles reflect the data at the time of the last refresh, and not necessarily the latest changes made to the underlying source. คุณสามารถรีเฟรชแดชบอร์ดที่เปิดอยู่เพื่อให้แน่ใจว่าเป็นปัจจุบันYou can refresh an open dashboard to ensure it's current.

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

เมื่อเชื่อมต่อกับ SQL Server Analysis Services จะมีตัวเลือกเพื่อให้นำเข้าข้อมูลจากแบบจำลองข้อมูลที่เลือก หรือเชื่อมต่อโดยตรงไปยังแบบจำลองข้อมูลที่เลือกWhen connecting to SQL Server Analysis Services, there's an option to either import data from or connect live to, the selected data model. ถ้าคุณใช้นำเข้า ให้คุณกำหนดคิวรีสำหรับแหล่งข้อมูล SQL Server Analysis Services ภายนอกนั้น และข้อมูลจะถูกนำเข้าตามปกติIf you use import, you define a query against that external SQL Server Analysis Services source, and the data is imported as normal. ถ้าคุณเลือกการเชื่อมต่อแบบสด จะไม่มีการกำหนดคิวรีใดเลย และแบบจำลองภายนอกทั้งหมดจะแสดงในรายการเขตข้อมูลIf you use connect live, there's no query defined, and the entire external model is shown in the field list.

สถานการณ์ที่อธิบายไว้ในย่อหน้าก่อนหน้านี้สามารถนำไปใช้กับการเชื่อมต่อกับแหล่งข้อมูลต่อไปนี้เช่นกัน เว้นแต่ว่าไม่มีตัวเลือกการนำเข้าข้อมูล:The situation described in the previous paragraph applies to connecting to the following sources as well, except that there's no option to import the data:

  • ชุดข้อมูล power BI ตัวอย่างเช่น เมื่อเชื่อมต่อกับชุดข้อมูล Power BI ที่ได้รับการสร้าง และเผยแพร่ไปยังบริการก่อนหน้านี้เพื่อสร้างรายงานใหม่Power BI datasets, for example, when connecting to a Power BI dataset that has previously been created and published to the service, to author a new report over it.
  • บริการข้อมูลทั่วไปCommon Data Services.

ลักษณะการทำงานของรายงานด้วย SQL Server Analysis Services เมื่อมีการเผยแพร่ไปยังบริการ Power BI จะมีลักษณะคล้ายกับรายงาน DirectQuery ดังต่อไปนี้:The behavior of reports over SQL Server Analysis Services, upon publishing to the Power BI service, is similar to DirectQuery reports in the following ways:

  • เมื่อเปิดรายงานที่มีอยู่ในบริการ Power BI หรือเขียนรายงานใหม่ แหล่งข้อมูล SQL Server Analysis Services ต้นแบบจะได้รับการคิวรี ซึ่งอาจต้องใช้เกตเวย์ข้อมูลภายในองค์กรWhen opening an existing report in the Power BI service or authoring a new report, the underlying SQL Server Analysis Services source is queried, possibly requiring an on-premises data gateway.
  • ไทล์แดชบอร์ดที่จะรีเฟรชโดยอัตโนมัติตามกำหนดการ เช่น ทุกชั่วโมงDashboard tiles are automatically refreshed on a schedule, such as every hour.

นอกจากนี้ยังมีความแตกต่างที่สำคัญอีกด้วยThere are also important differences. ตัวอย่างเช่น สำหรับการเชื่อมต่อแบบสด ข้อมูลประจำตัวของผู้ใช้ที่เปิดรายงานจะถูกส่งผ่านไปยังแหล่งที่มา SQL Server Analysis Services ต้นแบบเสมอFor instance, for live connections, the identity of the user opening the report is always passed to the underlying SQL Server Analysis Services source.

จากการเปรียบเทียบเหล่านี้ ให้ลองมาโฟกัสที่ DirectQuery ในส่วนเหลือของบทความนี้เท่านั้นWith these comparisons out of the way, let's focus solely on DirectQuery for the rest of this article.

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

ตารางต่อไปนี้อธิบายสถานการณ์ที่การเชื่อมต่อกับ DirectQuery อาจมีประโยชน์อย่างยิ่งThe following table describes scenarios where connecting with DirectQuery could be especially useful. ซึ่งรวมถึงกรณีที่การทิ้งข้อมูลในแหล่งดั้งเดิมจะถือว่าเป็นประโยชน์It includes cases where leaving the data in the original source would be considered beneficial. คำอธิบายรวมถึงการอภิปรายว่าสถานการณ์ที่ระบุมีอยู่ใน Power BI หรือไม่The description includes a discussion about whether the specified scenario is available in Power BI.

ข้อจำกัดLimitation คำอธิบายDescription
ข้อมูลมีการเปลี่ยนแปลงอยู่บ่อยครั้ง และจำเป็นต้องมีการรายงานแบบเรียลไทม์Data is changing frequently, and near real-time reporting is needed แบบจำลองที่มีข้อมูลที่นำเข้าสามารถรีเฟรชได้มากที่สุดต่อชั่วโมง (มักพบว่าบ่อยมากกว่า เมื่อใช้ Power BI Pro หรือการสมัครใช้งาน Power BI Premium)Models with imported data can be refreshed at most once per hour (more frequently with Power BI Pro or Power BI Premium subscriptions). ถ้าข้อมูลมีการเปลี่ยนแปลงอย่างต่อเนื่อง และจำเป็นสำหรับรายงานเพื่อที่จะต้องแสดงข้อมูลล่าสุด การใช้การนำเข้าที่มีการรีเฟรชตามกำหนดการอาจไม่ตรงกับความต้องการเหล่านั้นTf the data is continually changing, and it's necessary for reports to show the latest data, using import with scheduled refresh might not meet those needs. คุณสามารถสตรีมข้อมูลไปยัง Power BI โดยตรง แม้ว่าจะมีข้อจำกัดปริมาณข้อมูลที่สนับสนุนสำหรับกรณีนี้You can stream data directly into Power BI, though there are limits on the data volumes supported for this case.

ในทางตรงกันข้าม การใช้ DirectQuery หมายความว่าการเปิด หรือการรีเฟรชรายงานหรือแดชบอร์ดจะแสดงข้อมูลล่าสุดในแหล่งข้อมูลเสมอUsing DirectQuery, by contrast, means that opening or refreshing a report or dashboard always shows the latest data in the source. นอกจากนี้ยังสามารถอัปเดตไทล์แดชบอร์ดได้บ่อยมากขึ้น อัปเดตได้ทุก 15 นาทีAdditionally, the dashboard tiles can be updated more frequently, as often as every 15 minutes.
ข้อมูลมีขนาดใหญ่มากData is very large หากข้อมูลมีขนาดใหญ่มาก จะไม่สามารถนำเข้าได้ทั้งหมดIf the data is very large, it wouldn't be feasible to import it all. ในทางตรงกันข้าม DirectQuery ไม่ต้องการการถ่ายโอนข้อมูลขนาดใหญ่มากเนื่องจากมีการคิวรรีอยู่แล้วDirectQuery, by contrast, requires no large transfer of data, because it's queried in place.

อย่างไรก็ตาม ข้อมูลขนาดใหญ่อาจหมายความว่า ประสิทธิภาพการทำงานของคิวรีกับแหล่งข้อมูลต้นแบบนั้นช้าเกินไป ตามที่อธิบายไว้ในผลกระทบจากการใช้ DirectQueryHowever, large data might also imply that the performance of the queries against that underlying source is too slow, as discussed in Implications of using DirectQuery. คุณไม่จำเป็นต้องนำเข้าข้อมูลที่มีรายละเอียดสมบูรณ์เสมอYou don't always have to import the full detailed data. แต่คุณสามารถรวมข้อมูลไว้ล่วงหน้าในระหว่างการนำเข้าได้Instead, the data can be pre-aggregated during import. ตัวแก้ไขคิวรี ทำให้ง่ายต่อการรวมข้อมูลล่วงหน้าในระหว่างการนำเข้าThe Query Editor makes it easy to pre-aggregate during import. และในที่สุดก็จะสามารถนำเข้าข้อมูลรวมที่จำเป็นสำหรับแต่ละการแสดงผลด้วยภาพIn the extreme, it would be possible to import exactly the aggregate data needed for each visual. ในขณะที่ DirectQuery เป็นวิธีที่ง่ายที่สุดในการเข้าถึงข้อมูลขนาดใหญ่ แต่การนำเข้าข้อมูลรวมอาจเสนอวิธีแก้ปัญหาหากแหล่งข้อมูลต้นแบบช้าเกินไปWhile DirectQuery is the simplest approach to large data, importing aggregate data might offer a solution if the underlying source is too slow.
กฎการรักษาความปลอดภัยจะได้รับการกำหนดในแหล่งข้อมูลต้นแบบSecurity rules are defined in the underlying source เมื่อนำเข้าข้อมูลแล้ว Power BI จะเชื่อมต่อกับแหล่งข้อมูลโดยใช้ข้อมูลประจำตัวของผู้ใช้ปัจจุบันจาก Power BI Desktop หรือข้อมูลประจำตัวที่กำหนดไว้เป็นส่วนหนึ่งของการกำหนดค่าการรีเฟรชตามกำหนดการจากบริการ Power BIWhen the data is imported, Power BI connects to the data source using the current user's credentials from Power BI Desktop, or the credentials defined as part of configuring scheduled refresh from the Power BI service. ในการเผยแพร่และแบ่งปันรายงานดังกล่าว โปรดระมัดระวังเฉพาะเมื่อแบ่งปันกับผู้ใช้ที่ได้รับอนุญาตให้ดูข้อมูลเดียวกัน หรือกำหนดให้ Row Level Security เป็นส่วนหนึ่งของชุดข้อมูลIn publishing and sharing such a report, be careful to only share with users allowed to see the same data, or to define row-level security as part of the dataset.

และจะเป็นการดีเนื่องจาก DirectQuery จะทำการคิวรีแหล่งข้อมูลต้นแบบเสมอ ซึ่งการกำหนดค่านี้จะช่วยให้มีการรักษาความปลอดภัยในแหล่งข้อมูลต้นแบบที่นำมาใช้Ideally, because DirectQuery always queries the underlying source, this configuration would allow any security in that underlying source to be applied. อย่างไรก็ตามในปัจจุบันนี้ Power BI จะเชื่อมต่อกับแหล่งข้อมูลต้นแบบโดยใช้ข้อมูลปรจะตัวเดียวกับที่จะใช้สำหรับการนำเข้าเสมอHowever, currently Power BI always connects to the underlying source using the same credentials as would be used for import.

จนกว่า Power BI ช่วยให้สำหรับข้อมูลเฉพาะตัวของผู้ใช้รายงานจะส่งผ่านไปยังแหล่งข้อมูลต้นแบบ DirectQuery จะไม่ก่อให้เกิดผลดีสำหรับการรักษาความปลอดภัยของแหล่งข้อมูลUntil Power BI allows for the identity of the report consumer to pass through to the underlying source, DirectQuery offers no advantages for data source security.
ใช้ข้อจำกัดด้านอำนาจข้อมูลData sovereignty restrictions apply องค์กรบางแห่งมีนโยบายรอบด้านเกี่ยวกับอำนาจข้อมูล ซึ่งหมายความว่า ข้อมูลดังกล่าวไม่สามารถออกจากสถานที่ขององค์กรได้Some organizations have policies around data sovereignty, meaning that data can't leave the organization premises. การแก้ปัญหาที่ยึดตามการนำเข้าจะแสดงปัญหาอย่างชัดเจนA solution based on import would clearly present issues. ในทางกลับกัน ด้วย DirectQuery ที่ยังคงมีข้อมูลอยู่ในแหล่งข้อมูลต้นแบบBy contrast, with DirectQuery that data remains in the underlying source.

อย่างไรก็ตาม ถึงแม้จะใช้ DirectQuery แต่แคชบางตัวของข้อมูลในระดับวิชวลจะยังคงอยู่ในบริการ Power BI เนื่องจากการรีเฟรชตามกำหนดการของไทล์However, even with DirectQuery, some caches of data at the visual level are kept in the Power BI service because of scheduled refresh of tiles.
แหล่งข้อมูลต้นแบบคือ แหล่งข้อมูล OLAP ที่ประกอบด้วยหน่วยวัดUnderlying data source is an OLAP source, containing measures ถ้าแหล่งข้อมูลต้นแบบประกอบด้วยหน่วยวัด เช่น SAP HANA หรือ SAP Business Warehouse จากนั้นการนำเข้าข้อมูลจะทำให้เกิดปัญหาอื่น ๆIf the underlying data source contains measures, such as SAP HANA or SAP Business Warehouse, then importing the data brings other issues. นั่นหมายความว่า ข้อมูลนำเข้าดังกล่าวอยู่ในระดับเฉพาะของการรวม ตามที่กำหนดไว้โดยคิวรีIt means that the data imported is at a particular level of aggregation, as defined by the query. ตัวอย่างเช่น วัด TotalSales ตาม Class, Year และ City.For example, measures TotalSales by Class, Year, and City. จากนั้นถ้าวิชวลถูกสร้างขึ้นเพื่อขอข้อมูลในการรวมระดับสูงกว่า เช่น TotalSales ตาม Year จะเป็นการรวมมูลค่ารวมเพิ่มเติมThen if a visual is built asking for data at a higher-level aggregate, such as TotalSales by Year, it's further aggregating the aggregate value. การรวมนี้ใช้ได้สำหรับหน่วยวัดเสริม เช่น Sum และ Min แต่เป็นปัญหาสำหรับหน่วยวัดที่ไม่ใช่หน่วยวัดเสริม เช่น Average, DistinctCountThis aggregation is fine for additive measures, such as Sum and Min, but it's an issue for non-additive measures, such as Average, DistinctCount.

จำเป็นจะต้องส่งคิวรีต่อวิชวลแต่ละอัน เช่นเดียวกับใน DirectQuery เพื่อทำให้การรับข้อมูลรวมที่ถูกต้อง ตามที่จำเป็นสำหรับวิชวลเฉพาะ โดยตรงจากแหล่งมาง่ายขึ้นTo make it easy to get the correct aggregate data, as needed for the particular visual, directly from the source, it would be necessary to send queries per visual, as in DirectQuery.

เมื่อเชื่อมต่อกับ SAP Business Warehouse (BW) การเลือก DirectQuery จะช่วยให้สามารถจัดการหน่วยวัดได้When connecting to SAP Business Warehouse (BW), choosing DirectQuery allows for this treatment of measures. สำหรับข้อมูลเกี่ยวกับ SAP BW โปรดดู DirectQuery และ SAP BWFor information about SAP BW, see DirectQuery and SAP BW.

อย่างไรก็ตาม ขณะนี้ DirectQuery บน SAP HANA ถือว่าเหมือนกันกับแหล่งข้อมูลเชิงสัมพันธ์ และจึงมีลักษณะการทำงานคล้ายคลึงกับการนำเข้าHowever, currently DirectQuery over SAP HANA treats it the same as a relational source, and provides similar behavior to import. แนวทางนี้จะครอบคลุมเพิ่มเติมใน DirectQuery และ SAP HANAThis approach is covered further in DirectQuery and SAP HANA.

โดยสรุป เมื่อพิจารณาจากความสามารถในปัจจุบันของ DirectQuery ใน Power BI สถานการณ์ที่ให้ประโยชน์มีดังนี้:In summary, given the current capabilities of DirectQuery in Power BI, it offers the benefits in the following scenarios:

  • ข้อมูลมีการเปลี่ยนแปลงอยู่บ่อยครั้ง และจำเป็นต้องมีการรายงานแบบ "เรียลไทม์"Data is changing frequently, and near real-time reporting is needed.
  • จัดการข้อมูลขนาดใหญ่มาก โดยไม่จำเป็นต้องรวบรวมไว้ล่วงหน้าHandling very large data, without the need to pre-aggregate.
  • ใช้ข้อจำกัดด้านอำนาจข้อมูลData sovereignty restrictions apply.
  • แหล่งข้อมูลเป็นแหล่งข้อมูลแบบหลายมิติที่ประกอบด้วยหน่วยวัด เช่น SAP BWThe source is a multidimensional source containing measures, such as SAP BW.

โปรดทราบว่ารายละเอียดในรายการก่อนหน้านี้เกี่ยวข้องกับการใช้ Power BI เท่านั้นThe details in the previous list relate to the use of Power BI alone. แต่คุณสามารถใช้แบบจำลอง SQL Server Analysis Services หรือ Azure Analysis Services ภายนอกเพื่อนำเข้าข้อมูลได้Instead, you could use an external SQL Server Analysis Services or Azure Analysis Services model to import data. จากนั้นใช้ Power BI เพื่อเชื่อมต่อกับแบบจำลองนั้นThen use Power BI to connect to that model. แม้ว่าวิธีการดังกล่าวจะต้องใช้การกำหนดค่าเพิ่มเติม แต่ก็ช่วยให้มีความยืดหยุ่นมากขึ้นWhile that approach would require additional configuration, it does provide greater flexibility. สามารถนำเข้าข้อมูลจำนวนมากได้Much larger volumes of data can be imported. ไม่มีข้อจำกัดเกี่ยวกับความถี่ในการรีเฟรชข้อมูลThere's no restriction on how frequently the data can be refreshed.

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

การใช้ DirectQuery มีผลกระทบเชิงลบ ซึ่งจะอธิบายตามรายละเอียดในส่วนนี้Use of DirectQuery does have potentially negative implications, as detailed in this section. ข้อจำกัดบางข้อจะแตกต่างกันเล็กน้อยโดยขึ้นอยู่กับแหล่งข้อมูลที่ใช้งานSome of those limitations are slightly different depending upon the exact source that is being used. เราแก้ไขปัญหาข้อจำกัดตามความเหมาะสม และแยกบทความให้ครอบคลุมแหล่งข้อมูลที่แตกต่างกันอย่างมากWe address limitations where applicable, and separate articles cover those sources that are substantially different.

ประสิทธิภาพการทำงานและการโหลดบนแหล่งข้อมูลต้นแบบPerformance and load on the underlying source

เมื่อใช้ DirectQuery ประสบการณ์การใช้งานโดยรวมจะขึ้นอยู่กับประสิทธิภาพของแหล่งข้อมูลต้นแบบWhen using DirectQuery, the overall experience depends very much on the performance of the underlying data source. ถ้าการรีเฟรชแต่ละวิชวล ตัวอย่างเช่น หลังจากการเปลี่ยนแปลงค่าตัวแบ่งส่วนข้อมูล จะใช้เวลาสองถึงสามวินาที โดยปกติแล้วน้อยกว่า 5 วินาที ประสบการณ์การใช้งานดังกล่าวจะมีความสมเหตุสมผลIf refreshing each visual, for example, after changing a slicer value, takes a few seconds, usually less than 5 seconds, the experience would be reasonable. ประสบการณ์การใช้งานอาจรู้สึกเอื่อยเฉื่อยเมื่อเทียบกับการตอบสนองทันทีเมื่อนำเข้าข้อมูลไปยัง Power BIThe experience might feel sluggish compared to the immediate response when importing the data to Power BI. หากความช้าของแหล่งข้อมูลทำให้วิชวลแต่ละวิชวลใช้เวลานานกว่าสิบวินาที ประสบการณ์การใช้งานจะแย่มากIf the slowness of the source causes individual visuals to take longer than tens of seconds, the experience becomes extremely poor. คิวรีอาจหมดเวลาQueries may even time out.

ให้ความสนใจกับโหลดที่วางอยู่บนแหล่งข้อมูล พร้อมกับประสิทธิภาพของแหล่งต้นแบบAlong with the performance of the underlying source, pay attention to the load placed upon the source. โหลดส่งผลกระทบต่อประสิทธิภาพLoad impacts performance. ผู้ใช้แต่ละรายที่เปิดรายงานที่ใช้ร่วมกัน และไทล์แดชบอร์ดแต่ละอันที่รีเฟรช ให้ส่งคิวรีอย่างน้อยหนึ่งคิวรีต่อหนึ่งวิชวลไปยังแหล่งข้อมูลต้นแบบEach user who opens a shared report, and each dashboard tile that refreshes, sends at least one query per visual to the underlying source. ข้อเท็จจริงนี้จำเป็นต้องมีแหล่งข้อมูลที่สามารถจัดการภาระคิวรีดังกล่าว โดยยังคงรักษาประสิทธิภาพการทำงานอย่างเหมาะสมThis fact requires that the source can handle such a query load, while still maintaining reasonable performance.

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

คุณสามารถใช้หลายแหล่งข้อมูลในแบบจำลอง DirectQuery ได้เช่นเดียวกับเมื่อคุณนำเข้าข้อมูลโดยใช้คุณลักษณะ แบบจำลองรวมIt's possible to use multiple data sources in a DirectQuery model, just as when you import data, by using the Composite models feature. เมื่อคุณใช้หลายแหล่งข้อมูล สิ่งสำคัญคือต้องทำความเข้าใจวิธีการย้ายข้อมูลกลับไปมาระหว่างแหล่งข้อมูลเบื้องต้นและความเกี่ยวข้องด้านความปลอดภัยที่จะนำมาใช้When you use multiple data sources, it's important to understand how data is moved back and forth between the underlying data sources, and the security implications it brings.

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

ในทำนองเดียวกัน มีข้อจำกัดในการเปลี่ยนแปลงข้อมูลที่สามารถนำไปใช้ภายใน ตัวแก้ไขคิวรีSimilarly, there are limitations in the data transformations that can be applied within Query Editor. ด้วยข้อมูลนำเข้า ชุดการแปลงที่มีความซับซ้อนสามารถนำมาใช้เพื่อทำความสะอาดและปรับแต่งข้อมูลก่อนที่จะใช้เพื่อสร้างวิชวลได้อย่างง่ายดาย เช่น การแยกวิเคราะห์เอกสาร JSON หรือการหมุนข้อมูลจากคอลัมน์ไปเป็นรูปแบบแถวWith imported data, a sophisticated set of transformations can easily be applied to clean and reshape the data before using it to create visuals, such as parsing JSON documents, or pivoting data from a column to a row form. การแปลงเหล่านั้นจะถูกจำกัดมากขึ้นใน DirectQueryThose transformations are more limited in DirectQuery.

ก่อนอื่น เมื่อเชื่อมต่อกับแหล่งข้อมูล OLAP เช่น SAP Business Warehouse จะไม่สามารถกำหนดการแปลงได้เลย และจะนำแบบจำลองภายนอกทั้งหมดมาจากแหล่งข้อมูลFirst, when connecting to an OLAP source like SAP Business Warehouse, no transformations can be defined at all, and the entire external model is taken from the source. สำหรับแหล่งข้อมูลเชิงสัมพันธ์ เช่น SQL Server จะยังคงสามารถกำหนดชุดของการแปลงต่อคิวรีได้ แต่จะมีการจำกัดการแปลงเหล่านั้นเพื่อเหตุผลด้านประสิทธิภาพการทำงานFor relational sources, like SQL Server, it's still possible to define a set of transformations per query, but those transformations are limited for performance reasons.

การแปลงดังกล่าวจะถูกนำไปใช้กับทุกการคิวรีแหล่งข้อมูลต้นแบบ โดยทำมากกว่าหนึ่งครั้งในการรีเฟรชข้อมูล ดังนั้นจึงมีข้อจำกัดสำหรับการแปลงข้อมูลที่สามารถแปลเป็นคิวรีเนทิฟเดี่ยวได้อย่างสมเหตุสมผลAny such transformation will need to be applied on every query to the underlying source, rather than once on data refresh, so they're limited to those transformations that can reasonably be translated into a single native query. ถ้าคุณใช้การแปลงแบบที่มีความซับซ้อนเกินไป คุณจะได้รับข้อผิดพลาดที่ต้องลบ หรือแบบจำลองที่เปลี่ยนเป็นนำเข้าIf you use a transformation that is too complex, you receive an error that either it must be deleted or the model switched to import.

นอกจากนี้ คิวรีที่เป็นผลลัพธ์จากกล่องโต้ตอบรับข้อมูลหรือตัวแก้ไขคิวรีจะถูกใช้ในการเลือกย่อยภายในคิวรีที่สร้างขึ้น และส่งไปเพื่อดึงข้อมูลจำเป็นสำหรับวิชวลAdditionally, the query that results from the Get Data dialog or Query Editor will be used in a subselect within the queries generated and sent to retrieve the necessary data for a visual. คิวรีที่กำหนดไว้ในตัวแก้ไขคิวรีต้องถูกต้องภายในบริบทนี้The query defined in Query Editor must be valid within this context. โดยเฉพาะอย่างยิ่งมันเป็นไปไม่ได้ที่จะใช้คิวรีโดยนิพนธ์ตารางทั่วไป หรือสิ่งที่เรียกใช้ Stored ProceduresIn particular, it's not possible to use a query using Common Table Expressions, nor one that invokes Stored Procedures.

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

ความหมายของการสร้างแบบจำลองในบริบทนี้หมายถึงการกลั่นกรองและปรับปรุงข้อมูลดิบให้เป็นส่วนหนึ่งของการเขียนรายงานที่ใช้งานการสร้างแบบจำลองThe term modeling in this context means the act of refining and enriching the raw data, as part of authoring a report using it. ตัวอย่างเช่นExamples include:

  • กำหนดความสัมพันธ์ระหว่างตารางDefining relationships between tables
  • เพิ่มการคำนวณใหม่ (คอลัมน์และหน่วยวัดจากการคำนวณ)Adding new calculations (calculated columns and measures)
  • เปลี่ยนชื่อและซ่อนคอลัมน์และการวัดRenaming and hiding columns and measures
  • กำหนดลำดับชั้นDefining hierarchies
  • กำหนดการจัดรูปแบบ ข้อสรุปเริ่มต้นและจัดเรียงลำดับของคอลัมน์Defining the formatting, default summarization and sort order for a column
  • จัดกลุ่ม หรือแบ่งกลุ่มค่าGrouping or clustering values

เมื่อใช้ DirectQuery จะยังสามารถดำเนินการการเสริมสร้างแบบจำลองต่าง ๆ เหล่านี้ และแน่นอนว่ายังคงมีหลักการที่ว่าข้อมูลดิบจะได้รับการเสริมสร้าง เพื่อปรับปรุงการบริโภคในภายหลังWhen using DirectQuery, many of these model enrichments can still be made, and certainly there's still the principle that the raw data is being enriched, so as to improve later consumption. อย่างไรก็ตาม เมื่อใช้ DirectQuery จะมีความสามารถในการสร้างแบบจำลองบางอย่างที่ไม่พร้อมใช้งาน หรือจะถูกจำกัดHowever, there are some modeling capabilities that aren't available, or are limited, when using DirectQuery. ข้อจำกัดที่จะนำไปใช้เพื่อหลีกเลี่ยงปัญหาเกี่ยวกับประสิทธิภาพการทำงานThe limitations are generally applied to avoid performance issues. ชุดของข้อจำกัดที่ใช้โดยทั่วไปกับแหล่งข้อมูล DirectQuery ทั้งหมด จะแสดงอยู่ในรายการตรงส่วนนี้The set of limitations that are common to all DirectQuery sources are listed here. ข้อจำกัดเพิ่มเติมอาจนำไปใช้กับแต่ละแหล่งข้อมูลตามที่อธิบายไว้ใน ขั้นตอนถัดไปAdditional limitations might apply to individual sources, as described in Next steps.

  • ไม่มีลำดับชั้นวันที่ในตัว: เมื่อนำเข้าข้อมูล ทุกคอลัมน์วันที่/วันที่และเวลาจะมีลำดับชั้นวันที่แบบติดตั้งมาในตัวจะพร้อมใช้งานเป็นค่าเริ่มต้นNo built-in date hierarchy: When importing data, every date/datetime column will also have a built-in date hierarchy available by default. ตัวอย่างเช่น ถ้านำเข้าตาราง ใบสั่งขายรวมถึงคอลัมน์ OrderDate และเมื่อใช้ OrderDate ในวิชวล จะสามารถเลือกระดับที่เหมาะสม (ปี, เดือน, วัน) ที่จะใช้For example, if importing a table of sales orders including a column OrderDate, then upon using OrderDate in a visual, it will be possible to choose the appropriate level (year, month, day) to use. ลำดับชั้นของวันแบบติดตั้งมาในตัวนี้ไม่พร้อมใช้งานเมื่อใช้ DirectQueryThis built-in date hierarchy isn't available when using DirectQuery. ถ้ามีตาราง Date พร้อมใช้งานในแหล่งข้อมูลต้นแบบ ซึ่งมีอยู่ทั่วไปในคลังข้อมูลจำนวนมาก ฟังก์ชัน DAX Time Intelligence จะยังสามารถใช้งานได้ตามปกติIf there's a Date table available in the underlying source, as is common in many data warehouses, then the DAX Time Intelligence functions can be used as normal.
  • วันที่/เวลารองรับเฉพาะความแม่นยำในระดับวินาทีเท่านั้น: ขณะใช้คอลัมน์เวลาในชุดข้อมูลองคุณ Power BI จะออกรายการสืบค้นไปยังต้นทางที่เกี่ยวข้องในระดับรายละอียดระดับวินาทีDate/time support only to second accuracy: When using time columns in your dataset, Power BI only issues queries to the underlying source to a level of detail of seconds. ไม่มีการส่งคิวรีไปยังแหล่ง DirectQuery เป็นมิลลิวินาทีQueries aren't sent to the DirectQuery source for milliseconds. ลบส่วนนี้ออกจากคอลัมน์แหล่งข้อมูลของคุณRemove this part of the times from your source columns.
  • ข้อจำกัดในคอลัมน์จากการคำนวณ: คอลัมน์จากการคำนวณจะถูกจำกัดอยู่ภายในแถว คอลัมน์เหล่านั้นสามารถดูค่าของคอลัมน์อื่น ๆ ในตารางเดียวกันได้โดยไม่ต้องใช้ฟังก์ชันรวมใด ๆLimitations in calculated columns: Calculated columns are limited to being intra-row, as in, they can only refer to values of other columns of the same table, without the use of any aggregate functions. นอกจากนี้ฟังก์ชันสเกลาร์ DAX เช่น LEFT() ที่ได้รับอนุญาตจะถูกจำกัดเฉพาะฟังก์ชันเหล่านั้นที่สามารถส่งไปยังแหล่งต้นแบบได้Additionally, the DAX scalar functions, such as LEFT(), that are allowed, are limited to those functions that can be pushed to the underlying source. ฟังก์ชันจะแตกต่างกันโดยขึ้นอยู่กับความสามารถที่แท้จริงของแหล่งข้อมูลThe functions vary depending upon the exact capabilities of the source. ฟังก์ชันที่ไม่ได้รับการสนับสนุนจะไม่แสดงในการเติมข้อความอัตโนมัติ เมื่อเขียน DAX สำหรับคอลัมน์จากการคำนวณ และจะส่งผลกับข้อผิดพลาดหากมีการใช้Functions that aren't supported aren't listed in autocomplete when authoring the DAX for a calculated column, and would result in an error if used.
  • ไม่มีการสนับสนุนสำหรับฟังก์ชัน DAX หลัก-รอง: เมื่ออยู่ในแบบจำลอง DirectQuery จะไม่สามารถใช้งานตระกูลของฟังก์ชัน DAX PATH() ซึ่งโดยทั่วไปแล้วจะจัดการกับโครงสร้างหลัก-รอง เช่น แผนภูมิของบัญชี หรือลำดับชั้นของพนักงานNo support for parent-child DAX functions: When in DirectQuery mode, it's not possible to use the family of DAX PATH() functions that generally handle Parent-Child structures, such as chart of accounts, or employee hierarchies.
  • ตารางจากการคำนวณไม่ได้รับการสนับสนุน: ความสามารถในการกำหนดตารางจากการคำนวณโดยใช้นิพจน์ DAX ไม่ได้รับการสนับสนุนในโหมด DirectQueryCalculated tables aren't supported: The ability to define a calculated table using a DAX expression isn't supported in DirectQuery mode.
  • ตัวกรองความสัมพันธ์: สำหรับข้อมูลเกี่ยวกับการกรองแบบสองทิศทาง ให้ดู การกรองแบบข้ามสองทิศทางRelationship filtering: For information about bi-directional filtering, see Bidirectional cross-filtering. เอกสารทางเทคนิคนี้นำเสนอตัวอย่างในบริบทของ SQL Server Analysis ServicesThis whitepaper presents examples in the context of SQL Server Analysis Services. จุดพื้นฐานใช้กับ Power BI เท่านั้นThe fundamental points apply equally to Power BI.
  • ไม่มีคลัสเตอร์ริ่ง: เมื่อใช้ DirectQuery จะไม่สามารถใช้ความสามารถในการคลัสเตอร์ริ่งเพื่อค้นหากลุ่มโดยอัตโนมัติNo Clustering: When using DirectQuery, it's not possible to use the Clustering capability, to automatically find groups.

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

ความสามารถในการรายงานเกือบทั้งหมดได้รับการสนับสนุนสำหรับแบบจำลอง DirectQueryAlmost all reporting capabilities are supported for DirectQuery models. ดังนั้นตราบเท่าที่แหล่งข้อมูลต้นแบบมีประสิทธิภาพในระดับที่เหมาะสม จะสามารถใช้ชุดการแสดงวิชวลเดียวกันได้As such, so long as the underlying source offers a suitable level of performance, the same set of visualizations can be used. มีข้อจำกัดที่สำคัญบางข้อในบางส่วนของความสามารถอื่น ๆ ในบริการ Power BI หลังจากรายงานได้รับการเผยแพร่:There are some important limitations in some of the other capabilities offered in the Power BI service after a report is published:

  • ไม่รองรับข้อมูลเชิงลึกด่วน: ข้อมูลเชิงลึกด่วนของ Power BI จะค้นหาเซตย่อยที่ต่างกันของชุดข้อมูลของคุณในขณะที่ใช้ชุดอัลกอริทึมที่ซับซ้อนในการค้นหาแนวโน้มข้อมูลเชิงลึกที่น่าสนใจQuick Insights isn't supported: Power BI Quick Insights searches different subsets of your dataset while applying a set of sophisticated algorithms to discover potentially interesting insights. กำหนดความต้องการสำหรับคิวรีที่มีประสิทธิภาพสูงมาก ความสามารถนี้ไม่สามารถใช้ได้กับชุดข้อมูลที่ใช้ DirectQueryGiven the need for very high performance queries, this capability isn't available on datasets using DirectQuery.
  • ถามตอบ (Q&A) ไม่ได้รับการสนับสนุน: การถามตอบของ Power BI อนุญาตให้คุณสำรวจข้อมูลโดยใช้ความสามารถทางภาษาที่เป็นธรรมชาติและใช้งานง่าย และรับคำตอบในรูปแบบของแผนภูมิและกราฟQ&A isn't supported: Power BI Q&A enables you to explore your data using intuitive, natural language capabilities and receive answers in the form of charts and graphs. อย่างไรก็ตาม ถามตอบไม่ได้รับการสนับสนุนในชุดข้อมูลที่ใช้ DirectQuery ในขณะนี้However, it's currently not supported on datasets using DirectQuery.
  • การใช้ Explore ใน Excel อาจส่งผลให้เกิดประสิทธิภาพการทำงานที่แย่ลง: คุณสามารถสำรวจข้อมูลของคุณโดยใช้ความสามารถ Explore ใน Excel บนชุดข้อมูลUsing Explore in Excel will likely result in poorer performance: You can explore your data by using the Explore in Excel capability on a dataset. แนวทางนี้จะทำให้ตาราง Pivot และแผนภูมิ Pivot ได้รับการสร้างใน ExcelThis approach allows Pivot Tables and Pivot Charts to be created in Excel. แม้ว่าความสามารถนี้ได้รับการสนับสนุนในชุดข้อมูลที่ใช้ DirectQuery แต่โดยทั่วไปแล้วประสิทธิภาพการทำงานช้ากว่าการสร้างวิชวลใน Power BI ดังนั้น ถ้าการใช้ Excel เป็นสิ่งสำคัญสำหรับสถานการณ์ของคุณ ข้อเท็จจริงนี้ควรนำมาพิจารณาในการตัดสินใจใช้ DirectQueryWhile this capability is supported on datasets using DirectQuery, the performance is generally slower than creating visuals in Power BI, and therefore if the use of Excel is important for your scenarios, this fact should be accounted for in your decision to use DirectQuery.

ความปลอดภัยSecurity

ดังที่กล่าวไว้ก่อนหน้าในบทความนี้ รายงานใน DirectQuery จะใช้ข้อมูลประจำตัวคงที่เดียวกันเสมอเพื่อเชื่อมต่อกับแหล่งข้อมูลต้นแบบ หลังจากเผยแพร่ไปยังบริการ Power BIAs discussed earlier in this article, a report in DirectQuery always uses the same fixed credentials to connect to the underlying data source, after it's published to the Power BI service. ลักษณะการทำงานนี้ใช้กับ DirectQuery โดยไม่ต้องเชื่อมต่อโดยตรงกับ SQL Server Analysis Services ซึ่งแตกต่างกันในแง่นี้This behavior applies to DirectQuery, not to live connections to SQL Server Analysis Services, which is different in this respect. หลังจากเผยแพร่รายงาน DirectQuery จำเป็นต้องกำหนดค่าข้อมูลประจำตัวของผู้ใช้ที่จะใช้โดยทันทีImmediately after publish of a DirectQuery report, it's necessary to configure the credentials of the user that will be used. จนกว่าคุณจะกำหนดค่าข้อมูลประจำตัว การเปิดรายงานในบริการ Power BI จะส่งผลให้เกิดข้อผิดพลาดUntil you configure the credentials, opening the report on the Power BI service would result in an error.

เมื่อได้รับข้อมูลประจำตัวผู้ใช้ จะมีการใช้ข้อมูลประจำตัวเหล่านั้น โดยไม่คำนึงถึงผู้ใช้ที่เปิดรายงานOnce the user credentials are provided, then those credentials will be used whichever user who opens the report. ด้วยแนวทางนี้ จะเป็นเหมือนกับข้อมูลที่นำเข้าอย่างแม่นยำIn this way, it's exactly like imported data. ผู้ใช้ทุกคนจะเห็นข้อมูลเดียวกัน เว้นแต่ว่าจะมีการกำหนดความปลอดภัยระดับแถวเป็นส่วนหนึ่งของรายงานEvery user sees the same data, unless row-level security has been defined as part of the report. ซึ่งต้องให้ความสนใจเหมือนกันกับการแบ่งปันรายงาน ถ้ามีกฎความปลอดภัยใด ๆ ที่กำหนดไว้ในแหล่งข้อมูลต้นแบบThe same attention must be paid to sharing the report, if there are any security rules defined in the underlying source.

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

ในส่วนนี้จะอธิบายลักษณะการทำงานของรายงาน DirectQuery ในบริการ Power BI เพื่ออธิบายระดับของภาระที่จะถูกวางในแหล่งข้อมูลหลังบ้าน กำหนดจำนวนผู้ใช้ที่จะแบ่งปันรายงานและแดชบอร์ดด้วย ความซับซ้อนของรายงาน และเพื่อดูว่ามีการกำหนด Row Level Security ในรายงานหรือไม่This section describes the behavior of a DirectQuery report in the Power BI service, to explain the degree of load that will be placed on the back-end data source, given the number of users that the report and dashboard will be shared with, the complexity of the report, and whether row-level security has been defined in the report.

รายงาน – การเปิด การโต้ตอบกับ การแก้ไขReports – opening, interacting with, editing

เมื่อเปิดรายงาน วิชวลทั้งหมดบนหน้าที่มองเห็นในขณะนี้จะรีเฟรชWhen a report is opened, all the visuals on the currently visible page refresh. โดยทั่วไปแต่ละวิชวลจำเป็นต้องมีคิวรีอย่างน้อยหนึ่งคิวรีไปยังแหล่งข้อมูลต้นแบบEach visual generally requires at least one query to the underlying data source. วิชวลบางอย่างอาจจำเป็นต้องมีคิวรีมากกว่าหนึ่งคิวรีSome visuals might require more than one query. ตัวอย่างเช่น วิชวลอาจแสดงค่ารวมจากตารางข้อเท็จจริงที่แตกต่างกันสองตาราง หรือประกอบด้วยหน่วยวัดที่ซับซ้อนมากขึ้น หรือประกอบด้วยผลรวมของหน่วยวัดที่ไม่ใช่แบบเพิ่ม เช่น นับจำนวนที่แตกต่างกันFor example, a visual might show aggregate values from two different fact tables, or contain a more complex measure, or contain totals of a non-additive measure like Count Distinct. การย้ายไปยังหน้าใหม่จะรีเฟรชวิชวลเหล่านั้นMoving to a new page refreshes those visuals. การรีเฟรชจะส่งคิวรีชุดใหม่ไปยังแหล่งข้อมูลต้นแบบRefreshing sends a new set of queries to the underlying source.

การโต้ตอบของผู้ใช้ทั้งหมดในรายงานอาจทำให้มีการรีเฟรชวิชวลEvery user interaction on the report might result in visuals being refreshed. ตัวอย่างเช่น การเลือกค่าที่แตกต่างกันในตัวแบ่งส่วนต้องส่งชุดคิวรี่ใหม่เพื่อรีเฟรชการแสดงผลด้วยภาพที่ได้รับผลกระทบทั้งหมดFor example, selecting a different value on a slicer requires sending a new set of queries to refresh all of the affected visuals. เช่นเดียวกับการคลิกที่วิชวลเพื่อเน้นแบบไขว้ที่วิชวลอื่น ๆ หรือเปลี่ยนตัวกรองThe same is true for clicking on a visual to cross-highlight other visuals, or changing a filter.

ในทำนองเดียวกัน การแก้ไขรายงานใหม่จะจำเป็นต้องมีคิวรีที่ส่งสำหรับแต่ละขั้นตอนในเส้นทางเพื่อสร้างวิชวลขั้นสุดท้ายSimilarly, editing a new report requires queries to be sent for each step on the path to produce the final visual.

มีการแคชของผลลัพธ์บางอย่างThere's some caching of results. การรีเฟรชวิชวลเกิดขึ้นทันทีหากได้ผลลัพธ์ที่เหมือนกันเมื่อเร็ว ๆ นี้The refresh of a visual is instantaneous if the exact same results have recently been obtained. ถ้ามีการกำหนดการรักษาความปลอดภัยระดับแถว การแคชข้อมูลดังกล่าวจะไม่ถูกแชร์ไประหว่างผู้ใช้If row-level security is defined, such caches aren't shared across users.

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

สามารถผักหมุดวิชวลส่วนบุคคล หรือทั้งหน้า เป็นไทล์ในแดชบอร์ดIndividual visuals, or entire pages, can be pinned to dashboard as tiles. ไทล์ที่ยึดตามชุดข้อมูล DirectQuery จะรีเฟรชโดยอัตโนมัติตามกำหนดการTiles based on DirectQuery datasets refresh automatically according to a schedule. ไทล์ส่งคิวรีไปยังแหล่งข้อมูลหลังบ้านTiles send queries to the back-end data source. ตามค่าเริ่มต้น ชุดข้อมูลจะรีเฟรชทุกชั่วโมง แต่สามารถกำหนดค่าให้เป็นส่วนหนึ่งของการตั้งค่า ชุดข้อมูล ให้เป็นระหว่างรายสัปดาห์ และทุก 15 นาทีBy default, datasets refresh every hour, but can be configured as part of dataset settings to be between weekly and every 15 minutes.

ถ้าไม่มีการกำหนดการรักษาความปลอดภัยระดับแถวในแบบจำลอง แต่ละไทล์จะถูกรีเฟรชหนึ่งครั้ง และผลลัพธ์จะใช้ร่วมกันกับผู้ใช้ทั้งหมดIf no row-level security is defined in the model, each tile is refreshed once, and the results shared across all users. มิฉะนั้น อาจเป็นผลตัวคูณขนาดใหญ่Otherwise, there can be a large multiplier effect. แต่ละไทล์จำเป็นต้องมีคิวรีที่แยกต่างหากต่อผู้ใช้ที่จะส่งไปยังแหล่งข้อมูลต้นแบบEach tile requires separate queries per user to be sent to the underlying source.

แดชบอร์ดที่มีไทล์ 10 ไทล์ที่ใช้ร่วมกับผู้ใช้ 100 ราย และสร้างในชุดข้อมูลโดยใช้ DirectQuery ที่มีการรักษาความปลอดภัยระดับแถว และกำหนดค่าการรีเฟรชทุก 15 นาที จะส่งผลให้มีการส่งคิวรีอย่างน้อย 1000 คิวรีไปยังแหล่งข้อมูลหลังบ้านในทุก 15 นาทีA dashboard with 10 tiles, shared with 100 users, created on a dataset using DirectQuery with row-level security, and configured to refresh every 15 minutes, would result in at least 1000 queries being sent every 15 minutes to the back-end source.

ต้องพิจารณาอย่างรอบคอบในการใช้การรักษาความปลอดภัยระดับแถว และการกำหนดค่ากำหนดการรีเฟรชPay careful consideration to the use of row-level security, and the configuring of the refresh schedule.

หมดเวลาTime-outs

การหมดเวลาสี่นาทีจะถูกนำไปใช้กับคิวรีแต่ละรายการในบริการ Power BIA time-out of four minutes is applied to individual queries in the Power BI service. คิวรีใช้เวลานานกว่าที่จะล้มเหลวQueries taking longer than that will fail. ตามที่เน้นไว้ก่อนหน้านี้ เราขอแนะนำให้คุณใช้ DirectQuery สำหรับแหล่งข้อมูลซึ่งมีประสิทธิภาพใกล้เคียงกับคิวรีแบบโต้ตอบAs stressed earlier, we recommend that you use DirectQuery for sources that provide near interactive query performance. ขีดจำกัดนี้มีวัตถุประสงค์เพื่อป้องกันปัญหาจากการดำเนินการนานเกินไปThis limit is intended to prevent issues from overly long execution times.

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

ผลกระทบทั่วไปอื่น ๆ จากการใช้ DirectQuery มีดังต่อไปนี้:Some other general implications of using DirectQuery are as follows:

  • ถ้าข้อมูลมีการเปลี่ยนแปลง จำเป็นต้องรีเฟรชเพื่อให้แน่ใจว่ามีข้อมูลล่าสุดแสดงอยู่: การใช้แคชจะไม่รับประกันว่าวิชวลจะแสดงข้อมูลล่าสุดอยู่ตลอดเวลาIf data is changing, it's necessary to refresh to ensure the latest data is shown: Given the use of caches, there's no guarantee that the visual is always showing the latest data. ตัวอย่างเช่น วิชวลอาจแสดงธุรกรรมในวันสุดท้ายFor example, a visual might show the transactions in the last day. เนื่องจากมีการเปลี่ยนแปลงตัวแบ่งส่วนข้อมูล ดังกล่าวอาจรีเฟรชเพื่อแสดงธุรกรรมสำหรับสองวันล่าสุดBecause of a slicer being changed, it might refresh to show the transactions for the last two days. ธุรกรรมนี้อาจรวมถึงธุรกรรมที่มาใหม่ล่าสุดThe transactions could include recent, newly arrived transactions. การส่งกลับตัวแบ่งส่วนไปยังค่าเดิมจะส่งผลให้มีการแสดงค่าแคชที่ได้รับก่อนหน้านี้อีกครั้งReturning the slicer to its original value would result in it again showing the cached value previously obtained.

    การเลือกรีเฟรชจะล้างแคชต่าง ๆ และรีเฟรชวิชวลทั้งหมดในหน้าเพื่อแสดงข้อมูลล่าสุดSelecting Refresh clears any caches and refreshes all the visuals on the page to show the latest data.

  • ถ้าข้อมูลมีการเปลี่ยนแปลง จะไม่มีการรับประกันความสอดคล้องระหว่างวิชวล: สำหรับวิชวลอื่นไม่ว่าจะอยู่ในหน้าเดียวกันหรือหน้าอื่น อาจถูกรีเฟรชในเวลาที่ต่างกันIf data is changing, there's no guarantee of consistency between visuals: Different visuals, whether on the same page or on different pages, might be refreshed at different times. ถ้ามีการเปลี่ยนแปลงข้อมูลในแหล่งข้อมูลต้นแบบ จะไม่สามารถรับประกันได้ว่า แต่ละวิชวลจะสามารถแสดงข้อมูล ณ จุดเวลาเดียวกันIf the data in the underlying source is changing, there's no guarantee that each visual shows the data at the exact same point of time. โดยความเป็นจริงแล้วในบางครั้งจำเป็นต้องมีคิวรีมากกว่าหนึ่งคิวรีสำหรับวิชวลเดี่ยว ตัวอย่างเช่น เพื่อขอรับรายละเอียดและผลรวม จึงไม่สามารถรับประกันความสอดคล้องแม้กระทั่งภายในวิชวลแบบเดียวIndeed, given that sometimes more than one query is required for a single visual, for example, to obtain the details and the totals, then consistency even within a single visual isn't guaranteed. เพื่อรับประกันความสอดคล้องนี้ อาจจำเป็นต้องเสียค่าใช้จ่ายการสำหรับการรีเฟรชวิชวลทั้งหมดเมื่อใดก็ตามที่มีการรีเฟรชวิชวลต่าง ๆ ควบคู่ไปกับการใช้คุณสมบัติที่มีราคาแพง เช่น Snapshot Isolation ในแหล่งข้อมูลต้นแบบTo guarantee this consistency would require the overhead of refreshing all visuals whenever any visual refreshed, in tandem with the use of costly features like Snapshot Isolation in the underlying data source.

    ปัญหานี้สามารถบรรเทาลงได้อย่างมากโดยการเลือก รีเฟรช เพื่อรีเฟรชวิชวลทั้งหมดในหน้าThis issue can be mitigated to a large extent by again selecting Refresh to refresh all of the visuals on the page. ถึงแม้ว่าจะใช้โหมดการนำเข้า แต่จะยังคงเกิดปัญหาเช่นเดียวกับการรับประกันความสอดคล้อง ในขณะที่มีการนำเข้าข้อมูลจากตารางมากกว่าหนึ่งตารางEven if using import mode, there's a similar problem of guaranteeing consistency while importing data from more than one table.

  • จำเป็นต้องรีเฟรชใน Power BI Desktop เพื่อแสดงการเปลี่ยนแปลง Metadata: หลังจากเผยแพร่รายงานแล้ว รีเฟรชจะรีเฟรชวิชวลในรายงานRefresh in Power BI Desktop is needed to reflect any metadata changes: After a report is published, Refresh will refresh the visuals in the report. ถ้ามีการเปลี่ยนแปลงสคีมาของแหล่งข้อมูลต้นแบบ จะไม่มีการนำการเปลี่ยนแปลงเหล่านั้นมาใช้โดยอัตโนมัติเพื่อเปลี่ยนแปลงเขตข้อมูลที่มีอยู่ในรายการเขตข้อมูลIf the schema of the underlying source has changed, then those changes aren't automatically applied to change the available fields in the field list. ถ้ามีการลบตารางหรือคอลัมน์ออกจากแหล่งข้อมูลต้นแบบ อาจทำให้เกิดความล้มเหลวของของคิวรีเมื่อมีการรีเฟรชIf tables or columns have been removed from the underlying source, it might result in query failure upon refresh. การเปิดรายงานใน Power BI Desktop และการเลือก รีเฟรช จะอัปเดตเขตข้อมูลในแบบจำลองเพื่อให้สอดคล้องกับการเปลี่ยนแปลงOpening the report in Power BI Desktop, and choosing Refresh updates the fields in the model to reflect the changes.

  • ข้อจำกัดของการส่งกลับแถว 1 ล้านแถวในคิวรีใดก็ตาม: มีข้อจำกัดคงที่ของการวางแถว 1 ล้านแถวในแถวจำนวนมากที่สามารถส่งกลับในรูปแบบคิวรีเดี่ยวต่าง ๆ ไปยังแหล่งข้อมูลเบื้องต้นLimit of 1 million rows returned on any query: There's a fixed limit of 1 million rows placed on the number of rows that can be returned in any single query to the underlying source. โดยทั่วไปข้อจำกัดนี้ไม่มีผลกระทบในทางปฏิบัติ และตัววิชวลเองจะไม่แสดงหลายจุดThis limit generally has no practical implications, and visuals themselves aren't going to display that many points. อย่างไรก็ตาม ข้อจำกัดอาจเกิดขึ้นในกรณีที่ Power BI ไม่มีการปรับให้เหมาะสมกับคิวรีที่ส่งได้อย่างสมบูรณ์ และมีการขอผลลัพธ์ขั้นกลางที่เกินข้อจำกัดHowever, the limit can occur in cases where Power BI isn't fully optimizing the queries sent, and there's some intermediate result being requested that exceeds the limit. นอกจากนี้ยังสามารถเกิดขึ้นได้ในขณะที่สร้างวิชวลในเส้นทางสู่สถานะสุดท้ายที่สมเหตุสมผลยิ่งขึ้นIt can also occur while building a visual, on the path to a more reasonable final state. ตัวอย่างเช่น การรวมทั้ง Customer และ TotalSalesQuantity จะทำให้ถึงข้อจำกัดนี้หากมีลูกค้ามากกว่า 1 ล้านราย จนกว่าจะมีการใช้ตัวกรองบางชนิดFor example, including Customer and TotalSalesQuantity would hit this limit if there were more than 1 million customers, until some filter were applied.

    ข้อผิดพลาดที่จะถูกส่งกลับจะเป็น: "ชุดผลลัพธ์ของคิวรีต่อแหล่งข้อมูลภายนอกเกินกว่าค่าขนาดสูงสุดที่ได้รับอนุญาตของแถว '1000000' แถว"The error that would be returned would be: "The resultset of a query to external data source has exceeded the maximum allowed size of '1000000' rows."

  • ไม่สามารถเปลี่ยนจากโหมดนำเข้าเป็นโหมด DirectQuery: โปรดทราบว่า โดยทั่วไปสามารถเปลี่ยนแบบจำลองจากโหมด DirectQuery ไปใช้โหมดการนำเข้าได้ แต่ต้องมีการนำเข้าข้อมูลที่จำเป็นทั้งหมดCan't change from import to DirectQuery mode: While it's possible to switch a model from DirectQuery mode to use import mode, all the necessary data must be imported. นอกจากนี้ยังไม่สามารถสลับกลับไปได้ โดยเบื้องต้นเนื่องมาจากชุดของคุณลักษณะไม่ได้รับการสนับสนุนในโหมด DirectQueryIt's also not possible to switch back, primarily because of the set of features not supported in DirectQuery mode. นอกจากนี้แบบจำลอง DirectQuery ผ่านแหล่งข้อมูลหลายมิติ เช่น SAP BW ยังไม่สามารถเปลี่ยนจาก DirectQuery ไปเป็นการนำเข้า เนื่องจากการจัดการที่แตกต่างกันของหน่วยวัดภายนอกDirectQuery models over multidimensional sources, like SAP BW, also can't be switched from DirectQuery to import, because of the different treatment of external measures.

DirectQuery ในบริการ Power BIDirectQuery in the Power BI service

แหล่งข้อมูลทั้งหมดได้รับการสนับสนุนจาก Power BI DesktopAll sources are supported from Power BI Desktop. แหล่งข้อมูลบางแหล่งพร้อมใช้งานจากภายในบริการ Power BI โดยตรงSome sources are also available directly from within the Power BI service. ตัวอย่างเช่น ผู้ใช้ทางธุรกิจอาจสามารถใช้ Power BI เพื่อเชื่อมต่อกับข้อมูลของพวกเขาใน Salesforce และรับแดชบอร์ดได้ทันทีโดยไม่ต้องใช้ Power BI DesktopFor example, it's possible for a business user to use Power BI to connect to their data in Salesforce, and immediately get a dashboard, without use of Power BI Desktop.

แหล่งข้อมูลที่เปิดใช้ DirectQuery เพียงสองแหล่งจะพร้อมใช้งานในบริการโดยตรงOnly two of the DirectQuery enabled-sources are available directly in the service:

  • SparkSpark
  • คลังข้อมูล Azure SQLAzure SQL Data Warehouse

อย่างไรก็ตาม เราขอแนะนำเป็นอย่างยิ่งว่าการใช้ DirectQuery ผ่านทั้งสองแหล่งข้อมูลนั้นควรเริ่มต้นภายใน Power BI DesktopHowever, we recommend that any use of DirectQuery over those two sources start within Power BI Desktop. เหตุผลก็คือเมื่อการเชื่อมต่อเกิดขึ้นครั้งแรกในบริการ Power BI จะมีข้อจำกัดสำคัญมากมายThe reason is that when the connection is initially made in the Power BI service, many key limitations will apply. ในขณะที่จุดเริ่มต้นนั้นง่าย แต่การเริ่มต้นในบริการ Power BI มีข้อจำกัดในการปรับปรุงรายงานผลลัพธ์เพิ่มเติมWhile the start point was easy, starting in the Power BI service, there are limitations on enhancing the resulting report any further. ตัวอย่างเช่น ไม่สามารถสร้างการคำนวณ หรือใช้คุณลักษณะการวิเคราะห์จำนวนมาก หรือแม้แต่รีเฟรชเมตาดาต้าเพื่อสะท้อนการเปลี่ยนแปลงใดก็ตามกับสคีมาต้นแบบFor example, it's not possible then to create any calculations, or use many analytical features, or even refresh the metadata to reflect any changes to the underlying schema.

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

ถ้าคุณกำลังใช้ DirectQuery ในส่วนนี้จะแสดงคำแนะนำระดับสูงบางส่วนเกี่ยวกับวิธีการตรวจสอบความสำเร็จIf you're going to use DirectQuery, this section provides you with some high-level guidance on how to ensure success. คำแนะนำในส่วนนี้ได้รับมาจากผลกระทบของการใช้ DirectQuery ที่มีการอธิบายไว้ในบทความนี้The guidance in this section is derived from the implications of using DirectQuery that have been described in this article.

ประสิทธิภาพของแหล่งข้อมูลหลังบ้านBack-end data source performance

ตรวจสอบว่าวิชวลแบบง่ายรีเฟรชในเวลาที่เหมาะสมหรือไม่Validate that simple visuals refresh in a reasonable time. เวลาการรีเฟรชควรอยู่ภายใน 5 วินาที เพื่อให้มีประสบการณ์เชิงโต้ตอบที่เหมาะสมA refresh time should be within 5 seconds to have a reasonable interactive experience. ถ้าวิชวลใช้เวลานานกว่า 30 วินาที มีความเป็นไปได้อย่างสูงว่าปัญหาอื่นเพิ่มเติม จะเกิดขึ้นตามมาหลังจากการเผยแพร่รายงานIf visuals are taking longer than 30 seconds, it's highly likely that further issues will occur following publication of the report. ปัญหาเหล่านี้สามารถทำให้แนวทางการแก้ปัญหาใช้งานไม่ได้These issues can make the solution unworkable.

ถ้าคิวรีใช้เวลานาน ให้ตรวจสอบคิวรีที่ถูกส่งไปยังแหล่งข้อมูลต้นแบบ และเหตุผลสำหรับประสิทธิภาพการทำงานของคิวรีIf queries are slow, examine the queries being sent to the underlying source, and the reason for the query performance. หัวข้อนี้ไม่ครอบคลุมถึงแนวทางปฏิบัติที่ดีที่สุดในการเพิ่มประสิทธิภาพฐานข้อมูลทั่วทั้งชุดของแหล่งข้อมูลต้นแบบThis article doesn't cover the wide range of database optimization best practices across the full set of potential underlying sources. บทความนี้จะครอบคลุมแนวทางปฏิบัติที่เป็นมาตรฐานสำหรับฐานข้อมูล ซึ่งสามารถใช้ได้กับสถานการณ์ส่วนใหญ่:This article does cover the standard database practices that apply to most situations:

  • โดยทั่วไปแล้วความสัมพันธ์ที่ยึดตามคอลัมน์จำนวนเต็มจะทำงานได้ดีกว่าการรวมอยู่ในคอลัมน์ของชนิดข้อมูลอื่น ๆRelationships based on integer columns generally perform better than joins on columns of other data types.
  • ควรมีการสร้างดัชนีที่เหมาะสมThe appropriate indexes should be created. โดยทั่วไปการสร้างดัชนี หมายถึงการใช้ดัชนีจัดเก็บคอลัมน์ในแหล่งข้อมูลที่สนับสนุนดัชนีนั้น ตัวอย่างเช่น SQL ServerIndex creation generally means the use of column store indexes in those sources that support them, for example, SQL Server.
  • สถิติใดก็ตามที่จำเป็นในแหล่งข้อมูลควรได้รับการอัปเดตAny necessary statistics in the source should be updated.

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

เมื่อกำหนดแบบจำลอง ให้ลองทำตามคำแนะนำนี้:When defining the model, consider following this guidance:

  • หลีกเลี่ยงคิวรีที่ซับซ้อนในตัวแก้ไขคิวรีAvoid complex queries in Query Editor. ตัวแก้ไขคิวรีแปลคิวรีที่ซับซ้อนไปเป็นคิวรี SQL เดียวQuery Editor translates a complex query into a single SQL query. คิวรีเดียวจะปรากฏในการเลือกย่อยของทุกคิวรีที่ส่งไปยังตารางนั้นThe single query appears in the subselect of every query sent to that table. ถ้าคิวรีมีความซับซ้อน อาจทำให้เกิดปัญหาเกี่ยวกับประสิทธิภาพการทำงานในทุกคิวรีที่ส่งIf that query is complex, it might result in performance issues on every query sent. สามารถรับคิวรี SQL ที่แท้จริงสำหรับชุดขั้นตอนได้โดยการเลือกขั้นตอนสุดท้ายใน ตัวแก้ไขคิวรี แล้วเลือกมุมมองคิวรีเนทิฟจากเมนูบริบทได้The actual SQL query for a set of steps can be obtained by selecting the last step in Query Editor, and choosing View Native Query from the context menu.

  • เก็บหน่วยวัดแบบง่ายKeep measures simple. อย่างน้อยในขั้นตอนแรก เราขอแนะนำให้จำกัดหน่วยวัดเป็นผลรวมอย่างง่ายAt least initially, we recommend limiting measures to simple aggregates. ถ้าหน่วยวัดดำเนินการในลักษณะที่น่าพอใจ จะสามารถกำหนดหน่วยวัดที่ซับซ้อนมากขึ้นได้ แต่ควรให้ความสนใจกับประสิทธิภาพของแต่ละหน่วยวัดด้วยเช่นกันThen if the measures operate in a satisfactory manner, more complex measures can be defined, but paying attention to the performance for each.

  • หลีกเลี่ยงความสัมพันธ์ในคอลัมน์จากการคำนวณAvoid relationships on calculated columns. คำแนะนำนี้เกี่ยวข้องกับฐานข้อมูลที่คุณจำเป็นต้องทำการรวมแบบหลายคอลัมน์This guidance is relevant to databases where you need to do multi-column joins. Power BI ปัจจุบันนี้ไม่อนุญาตให้ความสัมพันธ์ยึดตามคอลัมน์หลายคอลัมน์เหมือนกับ FK/PKPower BI today doesn't allow a relationship to be based on multiple columns as the FK/PK. การแก้ไขปัญหาชั่วคราวคือ การรวมคอลัมน์เข้าด้วยกันโดยใช้คอลัมน์จากการคำนวณและสร้างฐานการรวมบนคอลัมน์นั้นThe common workaround is to concatenate the columns together using a calculated column, and base the join on that column. ในขณะที่การแก้ปัญหานี้เหมาะสมสำหรับข้อมูลที่นำเข้าสำหรับ DirectQuery จะส่งผลให้มีการรวมในนิพจน์While this workaround is reasonable for imported data, for DirectQuery, it results in a join on an expression. ซึ่งโดยทั่วไปแล้วจะป้องกันการใช้ดัชนีใดก็ตาม และนำไปสู่ประสิทธิภาพการทำงานที่ไม่ดีThat result commonly prevents use of any indexes, and leads to poor performance. การแก้ไขปัญหาชั่วคราวคือการทำให้หลายคอลัมน์กลายเป็นคอลัมน์เดี่ยวในฐานข้อมูลต้นแบบThe only workaround is to actually materialize the multiple columns into a single column in the underlying database.

  • หลีกเลี่ยงความสัมพันธ์บนคอลัมน์ตัวระบุที่ไม่ซ้ำกันAvoid relationships on uniqueidentifier columns. Power BI ไม่สนับสนุนชนิดข้อมูลของ uniqueidentifierPower BI doesn't natively support a datatype of uniqueidentifier. การระบุความสัมพันธ์ระหว่างคอลัมน์ของชนิดคอลัมน์ uniqueidentifier จะส่งผลให้มีการคิวรีด้วยการรวมที่เกี่ยวข้องกับ CastDefining a relationship between columns of type uniqueidentifier column results in a query with a join involving a cast. อีกครั้ง วิธีการนี้จะทำให้ประสิทธิภาพการทำงานแย่ลงAgain, this approach commonly leads to poor performance. จนกว่ากรณีนี้จะได้รับการปรับให้เหมาะสม การแก้ไขปัญหาชั่วคราวเป็นเพียงกาสร้างคอลัมน์ของประเภททางเลือกในฐานข้อมูลต้นแบบเท่านั้นUntil this case is specifically optimized, the only workaround is to materialize columns of an alternative type in the underlying database.

  • ซ่อนไปยังคอลัมน์ในความสัมพันธ์Hide the to column on relationships. คอลัมน์ ถึง ในความสัมพันธ์มักเป็นคีย์หลักในตาราง ถึงThe to column on relationships is commonly the primary key on the to table. คอลัมน์นั้นควรถูกซ่อนไว้That column should be hidden. ถ้าซ่อนแล้ว คอลัมน์จะไม่ปรากฏในรายการเขตข้อมูลและไม่สามารถใช้ในวิชวลได้If hidden, it doesn't appear in the field list and can't be used in visuals. บ่อยครั้งที่คอลัมน์ที่ความสัมพันธ์เป็นไปตามความเป็นข้อเท็จจริง คอลัมน์ระบบ ตัวอย่างเช่น คีย์สำรองในคลังข้อมูลOften the columns on which relationships are based are in fact system columns, for example, surrogate keys in a data warehouse. นี่คือแนวทางปฏิบัติที่ดีในการซ่อนคอลัมน์ดังกล่าวIt's good practice to hide such columns anyway. ถ้าคอลัมน์มีความหมาย ให้เปิดคอลัมน์จากการคำนวณที่มองเห็นได้ และที่มีนิพจน์อย่างง่ายที่เท่ากับคีย์หลัก ดังในตัวอย่างต่อไปนี้:If the column does have meaning, then introduce a calculated column that is visible, and that has a simple expression of being equal to the primary key, as in the following example:

        ProductKey_PK   (Destination of a relationship, hidden)
        ProductKey (= [ProductKey_PK],   visible)
        ProductName
        ...
    
  • ตรวจสอบการใช้งานทั้งหมดของคอลัมน์จากการคำนวณและการเปลี่ยนแปลงชนิดข้อมูลExamine all uses of calculated columns and data type changes. การใช้ความสามารถเหล่านี้ไม่จำเป็นต้องเป็นอันตรายUse of these capabilities aren't necessarily harmful. ซึ่งจะส่งผลให้คิวรีถูกส่งไปยังแหล่งข้อมูลต้นแบบที่ประกอบด้วยนิพจน์แทนที่จะเป็นการอ้างอิงอย่างง่ายไปยังคอลัมน์They do result in the queries sent to the underlying source containing expressions rather than simple references to columns. ซึ่งอาจส่งผลให้ไม่มีการใช้ดัชนีอีกครั้งThat again might result in indexes not being used.

  • หลีกเลี่ยงการใช้ตัวกรองแบบไขว้สองทิศทางในความสัมพันธ์Avoid use of the bi-directional cross filtering on relationships. การใช้การกรองแบบไขว้สองทิศทางสามารถทำให้คำสั่งคิวรีทำงานได้ไม่ดีUse of bi-directional cross filtering can lead to query statements that don't perform well.

  • การทดลองกับการตั้งค่า Assume referential integrity.Experiment with setting Assume referential integrity. การตั้งค่า Assume Referential Integrity ในความสัมพันธ์ทำให้คิวรีสามารถใช้งานคำสั่ง INNER JOIN แทนการใช้คำสั่ง OUTER JOINThe Assume Referential Integrity setting on relationships enables queries to use INNER JOIN statements rather than OUTER JOIN. ซึ่งโดยทั่วไปแล้วคำแนะนำนี้จะช่วยปรับปรุงประสิทธิภาพการทำงานของคิวรี แม้ว่าจะขึ้นอยู่กับข้อมูลจำเพาะของแหล่งข้อมูลThis guidance generally improves query performance, though it does depend on the specifics of the data source.

  • อย่าใช้การกรองข้อมูลสัมพัทธ์ในตัวแก้ไขคิวรีDon't use the relative data filtering in Query Editor. คุณสามารถกำหนดการกรองวันที่สัมพัทธ์ในตัวแก้ไขคิวรีได้It's possible to define relative date filtering in Query Editor. ตัวอย่างเช่น การกรองแถวที่วันที่ที่อยู่ใน 14 วันที่ผ่านมาFor example, to filter to the rows where the date is in the last 14 days.

    กรองแถวสำหรับ14 วันล่าสุด

    อย่างไรก็ตาม ตัวกรองนี้จะถูกแปลให้เป็นตัวกรองที่ยึดตามวันที่คงที่ ตามเวลาที่คิวรีถูกสร้างขึ้นHowever, this filter is translated into a filter based on the fixed date, as at the time the query was authored. ซึ่งคุณสามารถดูผลลัพธ์ได้จากการดูคิวรีเนทิฟThis result can be seen from viewing the native query.

    กรองแถวในคิวรี SQL แบบเนทิฟ

    ผลลัพธ์นี้อาจไม่ใช่สิ่งที่คุณต้องการThis result is probably not what you wanted. เพื่อให้แน่ใจว่าตัวกรองถูกนำไปใช้ตามวันที่ในเวลาที่รายงานทำงาน ให้ใช้ตัวกรองในรายงานเป็นตัวกรองรายงานแทนTo ensure the filter is applied based on the date at the time the report runs, instead apply the filter in the report as a Report Filter. ในปัจจุบันนี้ วิธีการนี้สามารถดำเนินการให้เสร็จได้โดยการสร้างคอลัมน์จากการคำนวณที่คำนวณจำนวนวันที่ผ่านมา โดยใช้ฟังก์ชัน DAX DATE() และใช้คอลัมน์จากคำนวณในตัวกรองCurrently, this approach would be done by creating a calculated column calculating the number of days ago, using the DAX DATE() function, and then using that calculated column in a filter.

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

เมื่อสร้างรายงานโดยใช้การเชื่อมต่อ DirectQuery โปรดทำตามคำแนะนำต่อไปนี้:When creating a report using a DirectQuery connection, follow this guidance:

  • พิจารณาการใช้ตัวเลือกการลดคิวรี: Power BI มีตัวเลือกในรายงานเพื่อให้ส่งคิวรีน้อยลง และเพื่อปิดใช้งานการโต้ตอบบางอย่างที่จะส่งผลให้ประสบการณ์การทำงานแย่ลง หากคิวรีที่เป็นผลลัพธ์ใช้เวลานานในการดำเนินการConsider use of Query Reduction options: Power BI provides options in the report to send fewer queries, and to disable certain interactions that would result in a poor experience if the resulting queries take a long time to run. เมื่อต้องการเข้าถึงตัวเลือกเหล่านี้ใน Power BI Desktop ไปที่ไฟล์ > ตัวเลือกและการตั้งค่า > ตัวเลือก แล้วเลือกการลดคิวรีTo access these options in Power BI Desktop, go to File > Options and settings > Options and select Query reduction.

    ตัวเลือกการลดคิวรี

    การทำเครื่องหมายที่กล่องการเลือกในการลดคิวรีจะช่วยให้คุณปิดใช้งานการเน้นแบบไขว้กับรายงานทั้งหมดของคุณChecking box selections on the Query reduction let you disable cross-highlighting throughout your entire report. คุณยังสามารถแสดงปุ่ม นำไปใช้ กับตัวแบ่งส่วนข้อมูลหรือตัวเลือกตัวกรองได้You can also show an Apply button to slicers or filter selections. วิธีการนี้ช่วยให้คุณทำการเลือกตัวแบ่งส่วนข้อมูลและตัวกรองจำนวนมากก่อนที่จะนำไปใช้This approach lets you then make many slicer and filter selections before applying them. ไม่มีการส่งคิวรีจนกว่าคุณจะเลือกปุ่ม นำไปใช้ บนตัวแบ่งส่วนข้อมูลNo queries are sent until you select the Apply button on the slicer. จากนั้นการเลือกของคุณจะสามารถใช้เพื่อกรองข้อมูลได้Your selections can then be used to filter the data.

    ตัวเลือกเหล่านี้จะนำไปใช้กับรายงานของคุณในขณะที่คุณโต้ตอบกับ Power BI DesktopThese options apply to your report while you interact with it in Power BI Desktop. ตัวเลือกเหล่านี้ยังจะนำไปใช้เมื่อผู้ใช้ของคุณใช้งานรายงานในบริการ Power BI อีกด้วยThese options also apply when your users consume the report in the Power BI service.

  • ใช้ตัวกรองเป็นอันดับแรก: ใช้ตัวกรองที่เหมาะสมทุกครั้งเมื่อเริ่มสร้างวิชวลApply filters first: Always apply any applicable filters at the start of building a visual. ตัวอย่างเช่น แทนที่จะลากใน TotalSalesAmount และ ProductName จากนั้นกรองเป็นปีใดปีหนึ่ง แต่คุณสามารถใช้ตัวกรองกับ Year ตั้งแต่เริ่มต้นได้For example, rather than drag in TotalSalesAmount and ProductName, then filter to a particular year, apply the filter on Year at the very start. แต่ละขั้นตอนของการสร้างวิชวลจะส่งคิวรีEach step of building a visual sends a query. ถึงแม้ว่าคุณสามารถทำการเปลี่ยนแปลงอื่นก่อนที่คิวรีแรกจะเสร็จสิ้นได้ แต่วิธีการนี้จะทำให้เกิดโหลดที่ไม่จำเป็นในแหล่งข้อมูลต้นแบบAlthough it's possible to then make another change before the first query has completed, this approach still leaves unnecessary load on the underlying source. การใช้ตัวกรองในช่วงแรก โดยทั่วไปแล้วจะทำให้คิวรีขั้นกลางมีค่าใช้จ่ายน้อยBy applying filters early, it generally makes those intermediate queries less costly. นอกจากนี้ การที่ไม่สามารถใช้ตัวกรองได้ในช่วงแรกอาจส่งผลให้ถึงขีดจำกัดแถว 1 ล้านแถวได้Also, failing to apply filters early can result in hitting the 1 million row limit.

  • จำกัดจำนวนของวิชวลในหน้า: เมื่อคุณเปิดหน้าหรือเปลี่ยนแปลงตัวแบ่งส่วนข้อมูลระดับหน้าหรือตัวกรอง วิชวลทั้งหมดในหน้าจะได้รับการรีเฟรชLimit the number of visuals on a page: When you open a page or change a page level slicer or filter, all of the visuals on a page are refreshed. นอกจากนี้ยังมีขีดจำกัดในเรื่องจำนวนของคิวรีที่ถูกส่งไปพร้อมกันThere's also a limit on the number of queries that are sent in parallel. ดังนั้นจำนวนของวิชวลจึงเพิ่มขึ้น วิชวลบางส่วนจะถูกรีเฟรชในลักษณะอนุกรม ทำให้เวลาที่ใช้ในการรีเฟรชทั้งหน้าเพิ่มขึ้นAs the number of visuals increases, some of the visuals will be refreshed in a serial manner, increasing the time taken to refresh the entire page. ด้วยเหตุผลนี้ เราขอแนะนำให้คุณจำกัดจำนวนของวิชวลในหน้าเดียว แทนที่จะมีหน้าได้ง่ายขึ้น จำนวนหลายหน้าFor this reason, we recommend that you limit the number of visuals on a single page, and instead have more, simpler pages.

  • พิจารณาปิดการโต้ตอบระหว่างวิชวล: ตามค่าเริ่มต้น สามารถใช้การแสดงภาพบนหน้ารายงานเพื่อกรองแบบไขว้และไฮไลท์ข้ามไปยังแสดงภาพอื่น ๆ ในหน้าดังกล่าวConsider switching off interaction between visuals: By default, visualizations on a report page can be used to cross-filter and cross-highlight the other visualizations on the page. ตัวอย่างเช่น เลือก 1999 ในแผนภูมิวงกลม และแผนภูมิคอลัมน์จะถูกเน้นแบบไขว้เพื่อแสดงยอดขายตามประเภทสำหรับ 1999For example, having selected 1999 on the pie chart, the column chart is cross highlighted to show the sales by category for 1999.

    วิชวลหลายรายการที่มีการกรองข้ามและการไฮไลต์แบบเชื่อมโยง

    การกรองข้ามและการไฮไลต์แบบเชื่อมโยงใน DirectQuery จะต้องมีการส่งคิวรีไปยังแหล่งข้อมูลต้นแบบCross-filtering and cross-highlighting in DirectQuery require queries to be submitted to the underlying source. ควรปิดการโต้ตอบ ถ้าเวลาที่ใช้ในการตอบสนองต่อการเลือกของผู้ใช้จะใช้เวลานานเกินสมควรThe interaction should be switched off if the time taken to respond to users' selections would be unreasonably long. คุณสามารถปิดการโต้ตอบนี้ได้You can switch off this interaction. ปิดการโต้ตอบนี้สำหรับรายงานทั้งหมด ตามที่อธิบายไว้ด้านบนสำหรับตัวเลือกการลดคิวรี หรือเป็นกรณี ๆ ไปSwitch off the interaction for either the entire report, as described earlier for query reduction options, or on a case-by-case basis. สำหรับข้อมูลเพิ่มเติม โปรดดู วิธีการใช้วิชวลกรองข้ามกันในรายงาน Power BIFor more information, see How visuals cross-filter each other in a Power BI report.

นอกเหนือจากรายการแนะนำก่อนหน้า แต่ละความสามารถในการรายงานต่อไปนี้อาจก่อให้เกิดปัญหาด้านประสิทธิภาพการทำงานIn addition to the previous suggestions, each of the following reporting capabilities can cause performance issues:

  • ตัวกรองหน่วยวัด: วิชวลที่มีหน่วยวัด หรือการรวมของคอลัมน์ อาจมีตัวกรองในหน่วยวัดเหล่านั้นMeasure filters: Visuals containing measures, or aggregates of columns, can contain filters in those measures. ตัวอย่างเช่น กราฟิกต่อไปนี้แสดง SalesAmount ตาม Category แต่เพียงแค่รวมประเภทเหล่านั้นกับยอดขายที่มากกว่า 20MFor example, the following graphic shows SalesAmount by Category, but only including those categories with more than 20M of sales.

    วิชวลที่แสดงหน่วยวัดที่ประกอบด้วยตัวกรอง

    วิธีการนี้ส่งผลให้มีการส่งคิวรีสองคิวรีไปยังแหล่งข้อมูลต้นแบบThis approach results in two queries being sent to the underlying source:

    • คิวรีแรกดึงข้อมูลหมวดหมู่ที่ตรงตามเงื่อนไข SalesAmount มากกว่า 20 ล้านเหรียญThe first query retrieves the Categories meeting the condition, SalesAmount greater than 20 million.
    • คิวรีที่สองเรียกใช้ข้อมูลจำเป็นสำหรับวิชวล รวมถึงหมวดหมู่ที่ตรงตามเงื่อนไขในคำสั่ง WHEREThe second query then retrieves the necessary data for the visual, including the categories that met the condition in the WHERE clause.

    ซึ่งโดยทั่วไปแล้ววิธีการนี้จะทำงานได้ดี หากมีหลายร้อยหรือหลายพันประเภท ตามตัวอย่างนี้This approach generally works well if there are hundreds or thousands of categories, as in this example. ประสิทธิภาพอาจลดลงหากจำนวนหมวดหมู่ใหญ่กว่ามากPerformance can degrade if the number of categories is much larger. คิวรีล้มเหลวสำหรับหมวดหมู่มากกว่าล้านรายการที่ตรงตามเงื่อนไขThe query fails for more than a million categories meeting the condition. ก่อนหน้านี้มีการกล่าวถึงขีดจำกัดจำนวน 1 ล้านแถวThe 1 million row limit was discussed earlier.

  • ตัวกรอง TopN: สามารถกำหนดตัวกรองขั้นสูงเพื่อกรองเฉพาะค่า N สูงสุด (หรือต่ำสุด) เท่านั้นที่จัดอันดับด้วยหน่วยวัดบางตัวTopN filters: Advanced filters can be defined to filter on only the top or bottom N values ranked by some measure. ตัวอย่างเช่น ตัวกรองสามารถมีหมวดหมู่ 10 อันดับแรกในวิชวลก่อนหน้าFor example, filters can include the top 10 categories in the previous visual. วิธีการนี้ส่งผลให้มีการส่งคิวรีสองคิวรีไปยังแหล่งข้อมูลต้นแบบอีกครั้งThis approach again results in two queries being sent to the underlying source. อย่างไรก็ตาม คิวรีแรกจะส่งกลับทุกประเภทจากแหล่งข้อมูลต้นแบบ และ TopN จะถูกกำหนดโดยยึดตามผลลัพธ์ที่ส่งกลับHowever, the first query will return all categories from the underlying source, and then the TopN are determined based on the returned results. วิธีการนี้อาจทำให้เกิดปัญหาด้านประสิทธิภาพการทำงานหรือความล้มเหลวของคิวรีเนื่องจากขีดจำกัดแถว 1 ล้านแถว ซึ่งขึ้นอยู่กับคาร์ดินัลลิติ้ของคอลัมน์เกี่ยวข้องDepending on the cardinality of the column involved, this approach can lead to performance issues or query failures because of the 1 million row limit.

  • ค่ากลาง: โดยทั่วไปแล้ว การรวมใดก็ตาม เช่น Sum หรือ Count Distinct จะถูกผลักไปยังแหล่งข้อมูลต้นแบบMedian: Generally, any aggregation, such as Sum or Count Distinct, is pushed to the underlying source. อย่างไรก็ตาม ข้อเท็จจริงนี้ไม่เป็นความจริงสำหรับค่ามัธยฐาน ซึ่งโดยทั่วไปแล้วการรวมนี้ไม่ได้รับการสนับสนุนโดยแหล่งข้อมูลต้นแบบHowever, this fact isn't true for median, which this aggregate is generally not supported by the underlying source. ในกรณีดังกล่าว ข้อมูลรายละเอียดจะถูกดึงมาจากแหล่งข้อมูลต้นแบบ และคำนวณค่ามัธยฐานจากผลลัพธ์ที่ส่งกลับIn such cases, the detail data is retrieved from the underlying source, and the median calculated from the returned results. วิธีการนี้จะเหมาะสมเมื่อมีการคำนวณค่ามัธยฐานในจำนวนของผลลัพธ์ที่ค่อนข้างน้อยThis approach is reasonable when the median is to be calculated over a relatively small number of results. ปัญหาด้านประสิทธิภาพการทำงานหรือคิวรีล้มเหลวเนื่องจากขีดจำกัดแถว 1 ล้านแถว จะเกิดขึ้นหากคาร์ดินาลลิตี้มีขนาดใหญ่Performance issues or query failures because of the 1 million row limit occur if the cardinality is large. ตัวอย่างเช่น Median Country Population อาจเหมาะสม แต่ Median Sales Price อาจไม่เหมาะสมFor example, Median Country Population might be reasonable, but Median Sales Price might not be.

  • ตัวกรองข้อความขั้นสูง (ประกอบด้วย และคล้ายกัน): เมื่อกรองข้อมูลในคอลัมน์ข้อความ การกรองขั้นสูงจะอนุญาตตัวกรองเช่น ประกอบด้วย และ เริ่มต้นด้วย และอื่น ๆAdvanced text filters (contains and similar): When filtering on a text column, the advanced filtering allows filters like contains and begins with and so on. ตัวกรองเหล่านี้อาจทำให้ประสิทธิภาพการทำงานลดลงสำหรับแหล่งข้อมูลบางแหล่งThese filters can certainly result in degraded performance for some data sources. และไม่ควรใช้ตัวกรอง ประกอบด้วย ตามค่าเริ่มต้นหากสิ่งที่ต้องการคือการจับคู่แบบตรงทั้งหมดIn particular, the default contains filter shouldn't be used if what is required is an exact match. แม้ว่าผลลัพธ์อาจจะเหมือนกัน โดยขึ้นอยู่กับข้อมูลจริง ประสิทธิภาพการทำงานอาจแตกต่างกันอย่างมากเนื่องจากการใช้ดัชนีAlthough the results might be the same, depending on the actual data, the performance might be drastically different because of indexes.

  • ตัวแบ่งส่วนข้อมูลแบบหลายตัวเลือก: ตามค่าเริ่มต้น ตัวแบ่งส่วนข้อมูลจะอนุญาตให้ดำเนินการเลือกเดียวเท่านั้นMulti select slicers: By default, slicers only allow a single selection to be made. การอนุญาตการเลือกตัวกรองหลายตัวอาจทำให้เกิดปัญหาด้านประสิทธิภาพเนื่องจากผู้ใช้เลือกชุดรายการในตัวแบ่งส่วนข้อมูลAllowing multi-selection in filters can cause some performance issues, because the user selects a set of items in the slicer. ตัวอย่างเช่น ถ้าผู้ใช้เลือกผลิตภัณฑ์ที่มีความสนใจ 10 รายการ แต่ละผลลัพธ์การเลือกใหม่ในคิวรีจะถูกส่งไปยังแหล่งข้อมูลFor example, if the user selects the 10 products of interest, each new selection results in queries being sent to the source. แม้ว่าผู้ใช้สามารถเลือกรายการถัดไปก่อนที่คิวรีจะเสร็จสมบูรณ์ วิธีการนี้จะส่งผลให้มีโหลดเพิ่มเติมในแหล่งข้อมูลต้นแบบAlthough the user can select the next item before the query completes, this approach results in extra load on the underlying source.

  • พิจารณาปิดผลรวมในวิชวล: ตามค่าเริ่มต้น ตารางและเมทริกซ์จะแสดงผลรวมและผลรวมย่อยConsider switching off totals on visuals: By default, tables and matrices display totals and subtotals. ในหลายกรณี คิวรีแบบแยกต้องถูกส่งไปยังแหล่งข้อมูลต้นแบบเพื่อรับค่าสำหรับผลรวมดังกล่าวIn many cases, separate queries must be sent to the underlying source to obtain the values for such totals. ข้อเท็จจริงนี้จะนำไปใช้เมื่อใดก็ตามที่มีการใช้การรวมของ DistinctCount หรือในกรณีทั้งหมดที่ใช้ DirectQuery ผ่าน SAP BW หรือ SAP HANAThis fact applies whenever using DistinctCount aggregation, or in all cases when using DirectQuery over SAP BW or SAP HANA. ผลรวมดังกล่าวควรจะปิดโดยใช้บานหน้าต่าง รูปแบบSuch totals should be switched off by using the Format pane.

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

คุณสามารถตั้งค่าจำนวนสูงสุดของการเชื่อมต่อ DirectQuery เปิดขึ้นสำหรับแต่ละแหล่งข้อมูลต้นแบบ ซึ่งควบคุมจำนวนของคิวรีที่ส่งไปยังแต่ละแหล่งข้อมูลพร้อมกันYou can set the maximum number of connections DirectQuery opens for each underlying data source, which controls the number of queries concurrently sent to each data source.

DirectQuery จะเปิดการเชื่อมต่อพร้อมกันสูงสุด 10 รายการ ตามค่าเริ่มต้นDirectQuery opens a default maximum number of 10 concurrent connections. คุณสามารถเปลี่ยนตัวเลขสูงสุดสำหรับไฟล์ปัจจุบันได้ใน Power BI DesktopYou can change the maximum number for the current file in Power BI Desktop. ไปยังตัวเลือก ไฟล์ > และตัวเลือก > การตั้งค่าGo to File > Options and Settings > Options. ในส่วน แฟ้มปัจจุบัน ในบานหน้าต่างด้านซ้าย ให้เลือก DirectQueryIn the Current File section in the left pane, select DirectQuery.

ตั้งค่าการเชื่อมต่อ DirectQuery สูงสุด

การตั้งค่าจะเปิดใช้งานเฉพาะเมื่อมีอย่างน้อยหนึ่งแหล่งข้อมูล DirectQuery ในรายงานปัจจุบันThe setting is only enabled when there's at least one DirectQuery source in the current report. ค่านำไปใช้ กับแหล่งข้อมูล DirectQuery ทั้งหมด และแหล่งข้อมูล DirectQuery ใด ๆ ใหม่ถูกเพิ่มลงในรายงานเดียวกันThe value applies to all DirectQuery sources, and to any new DirectQuery sources added to the same report.

การเพิ่ม การเชื่อมต่อสูงสุดต่อแหล่งข้อมูล ช่วยให้แน่ใจว่ามีคิวรีมากขึ้น ถึงจำนวนสูงสุดที่ระบุไว้ ซึ่งสามารถส่งไปยังแหล่งข้อมูลต้นแบบได้Increasing Maximum connections per data source ensures more queries, up to the maximum number specified, can be sent to the underlying data source. วิธีการนี้มีประโยชน์เมื่อมีวิชวลจำนวนมากอยู่ในหนึ่งหน้า หรือมีผู้ใช้จำนวนมากเข้าถึงรายงานในเวลาเดียวกันThis approach is useful when many visuals are on a single page, or many users access a report at the same time. เมื่อถึงขีดจำกัดจำนวนสูงสุดของการเชื่อมต่อ เพิ่มเติมคิวรีอยู่ในคิวจนกว่าการเชื่อมต่อจะพร้อมใช้งานOnce the maximum number of connections is reached, further queries are queued until a connection becomes available. เพิ่มขีดจำกัดนี้ส่งผลในการโหลดบนแหล่งข้อมูลต้นแบบ เพิ่มเติมเพื่อให้การตั้งค่าไม่รับประกันว่า จะปรับปรุงประสิทธิภาพโดยรวมIncreasing this limit does result in more load on the underlying source, so the setting isn't guaranteed to improve overall performance.

เมื่อมีการเผยแพร่รายงาน จำนวนสูงสุดของคิวรีที่เกิดขึ้นพร้อมกันที่ส่งไปยังแหล่งข้อมูลต้นแบบจะขึ้นอยู่กับขีดจำกัดคงที่Once a report is published, the maximum number of concurrent queries sent to the underlying data source also depend upon fixed limits. ขีดจำกัดขึ้นอยู่กับสภาพแวดล้อมเป้าหมายที่มีการเผยแพร่รายงานThe limits depend on the target environment to which the report is published. สภาพแวดล้อมต่าง ๆ เช่น Power BI, Power BI Premium หรือ เซิร์ฟเวอร์รายงาน Power BI สามารถกำหนดขีดจำกัดที่แตกต่างกันDifferent environments, such as Power BI, Power BI Premium, or Power BI Report Server, can impose different limits.

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

ส่วนนี้จะอธิบายวิธีการวินิจฉัยปัญหาด้านประสิทธิภาพการทำงาน หรือวิธีการรับข้อมูลรายละเอียดเพิ่มเติมเพื่ออนุญาตให้รายงานได้รับการปรับให้เหมาะสมThis section describes how to diagnose performance issues, or how to get more detailed information to allow the reports to be optimized.

เราขอแนะนำให้คุณเริ่มต้นการวินิจฉัยปัญหาด้านประสิทธิภาพการทำงานใน Power BI Desktop แทนที่จะเป็นในบริการ Power BIWe recommended that you start diagnosis of performance issues in Power BI Desktop, rather than in the Power BI service. ปัญหาด้านประสิทธิภาพการทำงานมักจะขึ้นอยู่กับประสิทธิภาพการทำงานของแหล่งข้อมูลต้นแบบPerformance issues are often based on the performance of the underlying source. คุณสามารถระบุและวินิจฉัยปัญหาได้ง่ายขึ้นในสภาพแวดล้อมที่แยกต่างหากมากขึ้นของ Power BI DesktopYou can more easily identify and diagnose issues in the more isolated environment of Power BI Desktop. ในขั้นต้น วิธีการนี้จะกำจัดองค์ประกอบบางอย่าง เช่น เกตเวย์ Power BIThis approach initially eliminates certain components, such as the Power BI gateway. ถ้าปัญหาด้านประสิทธิภาพการทำงานหายไปจาก Power BI Desktop ให้ตรวจสอบข้อมูลจำเพาะของรายงานในบริการ Power BIIf the performance issues are absent from Power BI Desktop, investigate the specifics of the report in the Power BI service. ตัววิเคราะห์ประสิทธิภาพเป็นเครื่องมือที่มีประโยชน์สำหรับการระบุปัญหาตลอดกระบวนการนี้The performance analyzer is a useful tool for identifying issues throughout this process.

ในทำนองเดียวกัน เราขอแนะนำให้ก่อนอื่นลองแยกปัญหาต่าง ๆ ให้กับแต่ละวิชวล แทนการแยกให้กับหลายวิชวลในหน้าเดียวSimilarly, we recommend to first try to isolate any issues to an individual visual, rather than many visuals on a page.

สมมติว่าคุณได้ดำเนินการขั้นตอนในย่อหน้าก่อนในส่วนนี้แล้วLet's say the steps in the previous paragraphs in this section have been taken. ตอนนี้เรามีวิชวลเดียวบนเพจใน Power BI Desktop ที่ยังคงเอื่อยเฉื่อยอยู่We now have a single visual on a page in Power BI Desktop that is still sluggish. ใช้ ตัววิเคราะห์ประสิทธิภาพ เพื่อประเมินคิวรีที่ Power BI Desktop ส่งไปยังแหล่งข้อมูลต้นแบบUse the performance analyzer to determine the queries that Power BI Desktop sends to the underlying source. นอกจากนี้ยังเป็นไปได้ที่จะดูการติดตามและข้อมูลการวินิจฉัยที่อาจถูกปล่อยออกมาจากแหล่งข้อมูลต้นแบบIt's also possible to view traces and diagnostic information that might be emitted by the underlying data source. การติดตามอาจมีรายละเอียดที่เป็นประโยชน์เกี่ยวกับวิธีดำเนินการคิวรี และวิธีการปรับปรุงคิวรีTraces might also contain useful details of how the query was executed, and how it can be improved.

นอกจากนี้ แม้ในกรณีที่ไม่มีร่องรอยดังกล่าวจากแหล่งที่มา คุณสามารถดคิวรีที่ส่งโดย Power BI พร้อมกับเวลาในการดำเนินการ ตามที่อธิบายไว้ในส่วนถัดไปFurther, even in the absence of such traces from the source, it's possible to view the queries sent by Power BI, along with their execution times, as described in the next section.

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

ตามค่าเริ่มต้น Power BI Desktop จะบันทึกเหตุการณ์ในระหว่างเซสชันที่กำหนดไว้ไปยังไฟล์การติดตามที่ชื่อ FlightRecorderCurrent.trcBy default, Power BI Desktop logs events during a given session to a trace file called FlightRecorderCurrent.trc.

สำหรับบางแหล่งข้อมูล DirectQuery บันทึกนี้จะรวมคิวรีทั้งหมดที่ส่งไปยังแหล่งข้อมูลต้นแบบFor some DirectQuery sources, this log includes all queries sent to the underlying data source. แหล่งข้อมูล DirectQuery ที่เหลือจะรวมอยู่ในอนาคตThe remaining DirectQuery sources will be included in the future. แหล่งข้อมูลต่อไปนี้ส่งคิวรีไปยังบันทึก:The following sources send queries to the log:

  • SQL ServerSQL Server
  • Azure SQL DatabaseAzure SQL Database
  • คลังข้อมูล Azure SQLAzure SQL Data warehouse
  • OracleOracle
  • TeradataTeradata
  • SAP HANASAP HANA

สามารถพบแฟ้มการติดตามในโฟลเดอร์AppDataสำหรับผู้ใช้ปัจจุบันThe trace file can be found in the AppData folder for the current user:

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

เมื่อต้องการไปโฟลเดอร์นี้ใน Power BI Desktop ให้เลือกไฟล์ > ตัวเลือกและการตั้งค่า > ตัวเลือก แล้วเลือกการวินิจฉัยTo get to this folder, in Power BI Desktop, select File > Options and settings > Options, and then select Diagnostics. กล่องโต้ตอบต่อไปนี้จะปรากฏขึ้น:The following dialog appears:

ลิงก์เพื่อเปิดโฟลเดอร์การติดตาม

เมื่อคุณเลือก เปิดโฟลเดอร์ crash dump/traces ที่อยู่ภายใต้ ตัวเลือกการวินิจฉัย โฟลเดอร์ต่อไปนี้จะเปิดขึ้น: <User>\AppData\Local\Microsoft\Power BI Desktop\TracesWhen you select Open crash dump/traces folder, under Diagnostic Options, the following folder opens: <User>\AppData\Local\Microsoft\Power BI Desktop\Traces.

การนำทางไปยังโฟลเดอร์หลักของโฟลเดอร์นั้นจะแสดงโฟลเดอร์ที่ประกอบด้วย AnalysisServicesWorkspaces ซึ่งจะประกอบด้วยโฟลเดอร์ของพื้นที่ทำงานหนึ่งสำหรับทุก ๆ อินสแตนซ์ที่เปิดของ Power BI DesktopNavigating to that folder's parent folder displays the folder containing AnalysisServicesWorkspaces, which will contain one workspace folder for every open instance of Power BI Desktop. โฟลเดอร์เหล่านี้จะได้รับการตั้งชื่อคำต่อท้ายที่เป็นจำนวนเต็ม เช่น AnalysisServicesWorkspace2058279583These folders are named with an integer suffix, such as AnalysisServicesWorkspace2058279583.

ภายในโฟลเดอร์นั้นคือโฟลเดอร์ \DataInside that folder is a \Data folder. ซึ่งประกอบด้วยไฟล์การติดตาม FlightRecorderCurrent.trc สำหรับเซสชัน Power BI ปัจจุบันIt contains the trace file FlightRecorderCurrent.trc for the current Power BI session. โฟลเดอร์พื้นที่ทำงานที่สอดคล้องกันจะถูกลบเมื่อสิ้นสุดเซสชัน Power BI Desktop ที่เชื่อมโยงThe corresponding workspace folder is deleted when the associated Power BI Desktop session ends.

ไฟล์การติดตามสามารถอ่านได้โดยใช้เครื่องมือ SQL Server ProfilerThe trace files can be read using the SQL Server Profiler tool. ได้รับเป็นส่วนหนึ่งของการดาวน์โหลดฟรี SQL Server Management StudioGet it as part of the free download SQL Server Management Studio.

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

ตัวสร้างโพรไฟล์ของ SQL Server

เมื่อต้องเปิดไฟล์การติดตาม ทำตามขั้นตอนต่อไปนี้To open the trace file, take the following steps:

  1. ใน SQL Server Profiler ให้เลือก ไฟล์ > เปิด > ไฟล์การติดตามIn SQL Server Profiler, select File > Open > Trace file.

  2. ใส่เส้นทางไปยังไฟล์ติดตามสำหรับเซสชัน Power BI เปิดอยู่ในปัจจุบัน เช่น C:\Users<user>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces\AnalysisServicesWorkspace2058279583\DataEnter the path to the trace file for the currently open Power BI session, such as: C:\Users<user>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces\AnalysisServicesWorkspace2058279583\Data.

  3. เปิด FlightRecorderCurrent.trcOpen FlightRecorderCurrent.trc.

เหตุการณ์ทั้งหมดจากเซสชันปัจจุบันจะปรากฏขึ้นAll events from the current session are displayed. ตัวอย่างที่มีคำอธิบายประกอบจะแสดงที่นี่ ซึ่งเน้นกลุ่มของเหตุการณ์An annotated example is shown here, which highlights groups of events. แต่ละกลุ่มมีเหตุการณ์ดังต่อไปนี้:Each group has the following events:

  • เหตุการณ์ Query Begin และ Query End ซึ่งแสดงจุดเริ่มต้นและสิ้นสุดของคิวรี DAX ที่สร้างขึ้น โดย UI ตัวอย่างเช่น จากวิชวลแบบ หรือ จากการเติมข้อมูลรายการของค่าในตัวกรอง UIA Query Begin and Query End event, which represent the start and end of a DAX query generated by the UI, for example, from a visual, or from populating a list of values in the filter UI.
  • เหตุการณ์ DirectQuery Begin และ DirectQuery End อย่างน้อยหนึ่งคู่ ซึ่งแสดงคิวรีที่ถูกส่งไปยังแหล่งข้อมูลต้นแบบ เป็นส่วนหนึ่งของการประเมินผลคิวรี DAXOne or more pairs of DirectQuery Begin and DirectQuery End events, which represent a query sent to the underlying data source, as part of evaluating the DAX query.

คิวรี DAX หลายรายการสามารถเรียกใช้พร้อมกันได้ ดังนั้นเหตุการณ์จากกลุ่มที่แตกต่างกันสามารถสอดแทรกกันได้Multiple DAX queries can run in parallel, so events from different groups can be interleaved. ค่าของ ActivityID สามารถใช้เพื่อกำหนดว่าเหตุการณ์ใดที่อยู่ในกลุ่มเดียวกันThe value of the ActivityID can be used to determine which events belong to the same group.

SQL Server Profiler ที่มีเหตุการณ์ Query Begin และ Query End

คอลัมน์อื่น ๆ ที่สนใจมีดังนี้:Other columns of interest are as follows:

  • ข้อมูลข้อความ: รายละเอียดข้อความของเหตุการณ์TextData: The textual detail of the event. สำหรับเหตุการณ์ Query Begin/End รายละเอียดคือคิวรี DAXFor Query Begin/End events, the detail is the DAX query. สำหรับเหตุการณ์ DirectQuery Begin/End รายละเอียดคือคิวรี SQL ที่ส่งไปยังแหล่งข้อมูลต้นแบบFor DirectQuery Begin/End events, the detail is the SQL query sent to the underlying source. TextData สำหรับเหตุการณ์ที่เลือกในปัจจุบันจะแสดงในบริเวณที่ด้านล่างThe TextData for the currently selected event is also displayed in the region at the bottom.
  • เวลาสิ้นสุด: เวลาเมื่อเหตุการณ์เสร็จสมบูรณ์EndTime: The time when the event completed.
  • ระยะเวลา: ระยะเวลาที่ใช้ในการดำเนินการคิวรี DAX หรือ SQL ในหน่วยมิลลิวินาทีDuration: The duration, in milliseconds, taken to execute the DAX or SQL query.
  • ข้อผิดพลาด: บ่งชี้ว่ามีข้อผิดพลาดเกิดขึ้นหรือไม่ ในกรณีนี้เหตุการณ์ที่แสดงจะเป็นสีแดงError: Indicates if an error occurred, in which case the event is also displayed in red.

โปรดทราบว่าในภาพด้านบน คอลัมน์ที่ดูไม่น่าสนใจบางส่วนได้รับการจำกัดให้แคบลง เพื่ออนุญาตให้คอลัมน์อื่นมองเห็นได้ง่ายขึ้นIn the image above, some of the less interesting columns have been narrowed, to allow other columns to be seen more easily.

เราขอแนะนำวิธีการต่อไปนี้ในการจับภาพการติดตามเพื่อช่วยในการวินิจฉัยปัญหาด้านประสิทธิภาพการทำงานอาจเกิดขึ้น:We recommend the following approach to capturing a trace to help diagnose a potential performance issue:

  • เปิดเซสชัน Power BI Desktop เดียวเพื่อหลีกเลี่ยงความสับสนของโฟลเดอร์พื้นที่ทำงานหลายรายการOpen a single Power BI Desktop session, to avoid the confusion of multiple workspace folders.
  • ใช้ชุดการดำเนินการที่น่าสนใจใน Power BI DesktopDo the set of actions of interest in Power BI Desktop. รวมถึงการดำเนินการเพิ่มเติมบางอย่าง เพื่อให้แน่ใจว่าเหตุการณ์ที่น่าสนใจจะถูกใส่ลงในไฟล์การติดตามInclude a few additional actions, to ensure that the events of interest are flushed into the trace file.
  • เปิด SQL Server Profiler และตรวจสอบการติดตาม ตามที่อธิบายไว้ก่อนหน้านี้Open SQL Server Profiler and examine the trace, as described previously. โปรดทราบว่าการปิด Power BI Desktop จะลบไฟล์การติดตามRemember that closing Power BI Desktop deletes the trace file. นอกจากนี้ การดำเนินการเพิ่มเติมใน Power BI Desktop จะไม่ปรากฏขึ้นทันทีAlso, further actions in Power BI Desktop don't immediately appear. ต้องปิดและเปิดไฟล์การติดตามใหม่เพื่อดูเหตุการณ์ใหม่The trace file should be closed and reopened to see the new events.
  • ทำให้แต่ละเซสชันมีขนาดเล็กพอสมควร อาจเป็น 10 วินาทีของการดำเนินการ ไม่ใช่หลายร้อยKeep individual sessions reasonably small, perhaps 10 seconds of actions, not hundreds. วิธีการนี้ช่วยให้ตีความไฟล์ติดตามได้ง่ายขึ้นThis approach makes it easier to interpret the trace file. นอกจากนี้ยังมีขีดจำกัดของขนาดของไฟล์การติดตามอีกด้วยThere's also a limit on the size of the trace file. สำหรับเซสชันแบบยาว มีโอกาสที่เหตุการณ์ช่วงแรกจะหายไปFor long sessions, there's a chance of early events being dropped.

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

รูปแบบทั่วไปของคิวรีที่สร้าง และส่งโดย Power BI Desktop ใช้การเลือกย่อยสำหรับแต่ละตารางที่อ้างอิงThe general format of queries created and sent by Power BI Desktop use subselects for each of the tables referenced. คิวรีของตัวแก้ไขคิวรีจะกำหนดการเลือกย่อยThe Query Editor query defines the subselect. ตัวอย่างเช่น สมมติว่าตาราง TPC DS ต่อไปนี้อยู่ใน SQL ServerFor example, assume the following TPC-DS tables in SQL Server:

ตาราง TPC-DS ใน SQL Server

พิจารณาคิวรีต่อไปนี้Consider the following query:

คิวรีตัวอย่าง

คิวรีนั้นจะส่งผลในวิชวลต่อไปนี้That query results in the following visual:

ผลลัพธ์วิชวลของคิวรี

การรีเฟรชวิชวลนั้นจะส่งผลให้คิวรี SQL แสดงที่นี่Refreshing that visual will result in the SQL query shown here. ตามที่คุณสามารถบอกได้ว่ามีการเลือกย่อยสามส่วนสำหรับ Web Sales Item และ Date_dim ซึ่งแต่ะละส่วนจะส่งคืนคอลัมน์ทั้งหมดในตารางที่เกี่ยวข้อง แม้ว่าจะมีเพียงสี่คอมลัมน์ที่การอ้างอิงโดยวิชวลAs you can tell, there are three subselects for Web Sales, Item, and Date_dim, that each return all the columns on the respective table, even though only four columns are actually referenced by the visual. คิวรีเหล่านี้ในการเลือกย่อยที่ถูกแรเงาจะตรงกับผลลัพธ์ของคิวรีที่กำหนดไว้ในตัวแก้ไขคิวรีThese queries in the subselects that are shaded are exactly the result of the queries defined in Query Editor. ไม่พบว่าการใช้การเลือกย่อยในลักษณะนี้มีผลกระทบต่อประสิทธิภาพการทำงาน สำหรับแหล่งข้อมูลที่ได้รับการสนับสนุนสำหรับ DirectQueryUse of subselects in this manner hasn't been found to impact performance for the data sources so far supported for DirectQuery. แหล่งข้อมูล เช่น SQL Server จะปรับการอ้างอิงไปยังคอลัมน์อื่น ๆ ให้เหมาะสมData sources like SQL Server optimize away the references to the other columns.

Power BI ใช้รูปแบบนี้เนื่องจากคิวรี SQL ที่ใช้สามารถจัดเตรียมได้จากนักวิเคราะห์โดยตรงPower BI employs this pattern because the SQL query used can be provided directly by the analyst. ซึ่งใช้ "ตามที่ระบุ" โดยไม่ต้องพยายามเขียนใหม่It's used "as provided", without an attempt to rewrite it.

คิวรี SQL ที่ใช้ตามที่ระบุไว้

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

บทความนี้อธิบายลักษณะของ DirectQuery ที่ใช้กันทั่วทั้งแหล่งข้อมูลทั้งหมดThis article describes aspects of DirectQuery that are common across all data sources. มีรายละเอียดที่เฉพาะเจาะจงสำหรับแต่ละแหล่งข้อมูลThere are certain details that are specific to individual sources. ดูหัวข้อต่อไปนี้ที่ครอบคลุมแหล่งข้อมูลที่เฉพาะSee the following articles covering specific sources:

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ DirectQuery โปรดดูทรัพยากรต่อไปนี้:For more information about DirectQuery, see the following resource: