แชร์ผ่าน

คำแนะนำแบบจำลอง DirectQuery ใน Power BI Desktop

  • บทความ

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

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

หมายเหตุ

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

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

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

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

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

หมายเหตุ

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

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

  • เพิ่มดัชนี: กําหนดดัชนีที่เหมาะสม—ในตารางหรือมุมมองเพื่อสนับสนุนการดึงข้อมูลที่มีประสิทธิภาพสําหรับการกรองและการจัดกลุ่มวิชวลรายงานที่คาดไว้ สําหรับแหล่งข้อมูล SQL Server, Azure SQL Database หรือ Azure Synapse Analytics (ชื่อเดิมคือ SQL Data Warehouse) ดู คู่มือ สถาปัตยกรรมและการออกแบบ SQL Server Index สําหรับข้อมูลที่เป็นประโยชน์เกี่ยวกับคําแนะนําการออกแบบดัชนี สําหรับแหล่งข้อมูลที่เปลี่ยนแปลงได้ของ SQL Server หรือ Azure SQL Database ให้ดู เริ่มต้นใช้งานด้วย Columnstore เพื่อการวิเคราะห์การดําเนินงานแบบเรียลไทม์

  • ออกแบบตารางแบบกระจาย: สําหรับแหล่งข้อมูล Azure Synapse Analytics (ชื่อเดิมคือ SQL Data Warehouse) ซึ่งใช้สถาปัตยกรรม Massively Parallel Processing (MPP) ให้พิจารณากําหนดค่าตารางชนิดข้อเท็จจริงขนาดใหญ่เป็นแฮชที่กระจาย และตารางชนิดมิติเพื่อทําซ้ําในโหนดการคํานวณทั้งหมด สําหรับข้อมูลเพิ่มเติม โปรดดูคําแนะนําสําหรับการออกแบบตารางแบบกระจายใน Azure Synapse Analytics (ชื่อเดิมคือ SQL Data Warehouse)

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

    พิจารณามุมมองที่มีการจัดทําดัชนีซึ่งสามารถรวบรวมข้อมูลตารางข้อเท็จจริงล่วงหน้าในระดับเกรนที่สูงขึ้นได้ ตัวอย่างเช่น ถ้า ตาราง ยอดขาย จัดเก็บข้อมูลที่ระดับใบสั่งซื้อ คุณสามารถสร้างมุมมองเพื่อสรุปข้อมูลนี้ได้ มุมมองอาจขึ้นอยู่กับคําสั่ง SELECT ที่จัดกลุ่ม ข้อมูลตารางยอดขาย ตามวันที่ (ในระดับเดือน) ลูกค้า ผลิตภัณฑ์ และสรุปค่าหน่วยวัดเช่น ยอดขาย ปริมาณ, ฯลฯ จากนั้นสามารถทําดัชนีมุมมองได้ สําหรับ SQL Server หรือแหล่งฐานข้อมูล Azure SQL ให้ดู สร้างมุมมองที่จัดทําดัชนี

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

ปรับการออกแบบแบบจําลองให้เหมาะสม

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

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

    ภาพหน้าจอของ Power BI Desktop ที่แสดงตัวเลือก

    ภาพหน้าจอของ Power BI Desktop ที่แสดงหน้าต่างคิวรีในระบบของฐานข้อมูล คําสั่งคิวรีรวมตารางแหล่งข้อมูลสองตาราง

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

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

    …
from [dbo].[Sales] as [_]
where [_].[OrderDate] >= convert(datetime2, '2018-01-01 00:00:00') and [_].[OrderDate] < convert(datetime2, '2019-01-01 00:00:00'))

    วิธีการออกแบบที่ดีกว่าคือการรวมคอลัมน์เวลาที่สัมพันธ์กันในตารางวันที่ คอลัมน์เหล่านี้จะจัดเก็บค่าออฟเซตที่สัมพันธ์กับวันที่ปัจจุบัน ตัวอย่างเช่น ใน คอลัมน์ RelativeYear ค่าศูนย์แทนปีปัจจุบัน -1 แทนปีก่อนหน้า เป็นต้น อย่างไรก็ตาม คอลัมน์ RelativeYear จะปรากฎขึ้นในตารางวันที่ แม้ว่าประสิทธิภาพจะน้อยลง แต่ก็ยังสามารถเพิ่มเป็นคอลัมน์จากการคํานวณของแบบจําลองโดยยึดตามนิพจน์โดยใช้ฟังก์ชัน DAX ของ TODAY และ DATE

  • เก็บหน่วยวัดแบบง่าย: อย่างน้อยในขั้นตอนแรก เราาขอแนะนําให้จํากัดหน่วยวัดเป็นผลรวมอย่างง่าย ฟังก์ชันการรวมประกอบด้วย SUM, COUNT, MIN, MAX และ AVERAGE จากนั้น หากหน่วยวัดนั้นสามารถตอบสนองได้อย่างเพียงพอ คุณสามารถทดลองกับหน่วยวัดที่ซับซ้อนมากขึ้น แต่ให้ความสนใจกับประสิทธิภาพของการวัดแต่ละรายการ แม้ว่าฟังก์ชัน DAX ของ CALCULATE สามารถใช้ในการสร้างนิพจน์หน่วยวัดที่มีความซับซ้อนซึ่งจัดการบริบทตัวกรอง แต่อาจก่อให้เกิดคิวรีในระบบของแบบดั้งเดิมที่มีราคาแพงที่ไม่ได้ทํางานได้ดี

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

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

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

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

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

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

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

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

    • การตั้งค่าจะเปิดใช้งานเฉพาะเมื่อมีอย่างน้อยหนึ่งแหล่งข้อมูล DirectQuery ในแบบจําลอง ค่าจะนําไปใช้กับแหล่งข้อมูล DirectQuery ทั้งหมดและแหล่งข้อมูล DirectQuery ใหม่ใด ๆ ที่เพิ่มลงในแบบจําลอง
    • การเพิ่มค่า การเชื่อมต่อสูงสุดต่อแหล่งข้อมูล ช่วยให้มั่นใจได้ว่าจะสามารถส่งคิวรีไปยังแหล่งข้อมูลพื้นฐานได้มากขึ้น (สูงสุดถึงจํานวนสูงสุดที่ระบุ) ซึ่งจะเป็นประโยชน์เมื่อมีวิชวลจํานวนมากในหน้าเดียว หรือมีผู้ใช้หลายคนที่เข้าถึงรายงานในเวลาเดียวกัน เมื่อถึงขีดจํากัดจํานวนสูงสุดของการเชื่อมต่อ เพิ่มเติมคิวรีถูกจัดคิวจนกว่าการเชื่อมต่อจะพร้อมใช้งาน การเพิ่มขีดจํากัดนี้จะส่งผลให้มีการโหลดในแหล่งข้อมูลต้นแบบ ดังนั้นการตั้งค่าจึงไม่ได้รับการรับประกันการปรับปรุงประสิทธิภาพการทํางานโดยรวม
    • เมื่อมีการเผยแพร่แบบจําลองไปยัง Power BI จํานวนสูงสุดของคิวรีที่เกิดขึ้นพร้อมกันที่ส่งไปยังแหล่งข้อมูลต้นแบบจะขึ้นอยู่กับสภาพแวดล้อมด้วย สภาพแวดล้อมต่าง ๆ (เช่น Power BI, Power BI Premium หรือเซิร์ฟเวอร์รายงาน Power BI) แต่ละรายการสามารถกําหนดข้อจํากัดปริมาณงานที่แตกต่างกัน สําหรับข้อมูลเพิ่มเติมเกี่ยวกับข้อจํากัดของทรัพยากรความจุ ดูสิทธิ์การใช้งานความจุ Microsoft Fabric และกําหนดค่าและจัดการความจุใน Power BI Premium

สำคัญ

ในบางครั้งที่บทความนี้อ้างอิงถึง Power BI Premium หรือการสมัครใช้งานความจุ (P SKU) โปรดทราบว่าในขณะนี้ Microsoft กําลังรวมตัวเลือกการซื้อและหยุดใช้งาน Power BI Premium ต่อความจุ SKU ลูกค้าใหม่และลูกค้าที่มีอยู่ควรพิจารณาซื้อการสมัครใช้งานความจุ Fabric (F SKU) แทน

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

ปรับการออกแบบรายงานให้เหมาะสม

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

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

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

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

    ภาพหน้าจอของ Power BI Desktop ที่แสดงข้อมูลแบบตารางพร้อมตัวกรองที่นําไปใช้

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

    • คิวรีแรกจะดึงข้อมูลหมวดหมู่ที่ตรงตามเงื่อนไข (ยอดขาย > 15 ล้านเหรียญ)
    • คิวรีที่สองจะเรียกใช้ข้อมูลจําเป็นสําหรับวิชวล โดยการเพิ่มประเภทที่ตรงตามเงื่อนไขในคําสั่ง WHERE

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

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

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

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

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

แปลงเป็นแบบจําลองคอมโพสิต

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

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

ให้ความรู้แก่ผู้ใช้

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

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

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

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

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