การปรับความจุแบบพรีเมียมให้เหมาะสม

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

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

• เพิ่มขนาดความจุพรีเมียมที่มีอยู่
• เพิ่มความจุแบบพรีเมียมใหม่

สุดท้าย การทดสอบวิธีการและการปรับขนาดความจุแบบพรีเมียมจะรวบรวมไว้ในบทความนี้

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

แนวทางปฏิบัติที่ดีที่สุด

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

• การใช้พื้นที่ทำงานแทนพื้นที่ทำงานส่วนบุคคล

• การแยกความสำคัญทางธุรกิจและ Self-Service BI (SSBI) ลงในความจุอื่น

  

• ถ้ามีการแชร์เนื้อหากับPower BI Proผู้ใช้เท่านั้น อาจไม่าเป็นต้องจัดเก็บเนื้อหาในความจุที่สงวนไว้

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

การกำหนดคำถามทั่วไป

การปรับใช้ Power BI Premium ให้เหมาะสมเป็นเรื่องที่ซับซ้อนที่เกี่ยวข้องกับการทำความเข้าใจข้อกำหนดของปริมาณงาน ทรัพยากรที่มีอยู่ และการใช้งานอย่างมีประสิทธิภาพ

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

ทำไมความจุจึงช้าลง และฉันสามารถทำอะไรได้บ้าง

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

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

เนื้อหาใดที่ใช้ความจุของฉันหมด

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

เมตริกหลักที่จะต้องตรวจสอบรวมถึง:

• CPU โดยเฉลี่ยและจำนวนการใช้งานสูง
• หน่วยความจำโดยเฉลี่ย และจำนวนการใช้งานสูง และการใช้หน่วยความจำสำหรับชุดข้อมูลที่เฉพาะเจาะจง กระแสข้อมูล และรายงานที่มีการแบ่งหน้า
• ชุดข้อมูลที่ใช้งานอยู่ที่โหลดในหน่วยความจำ
• ระยะเวลาการคิวรีโดยเฉลี่ยและสูงสุด
• เวลารอคิวรีโดยเฉลี่ย
• เวลาการรีเฟรชชุดข้อมูลและกระแสข้อมูลโดยเฉลี่ย

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

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

ทำไมรายงานจึงช้า

ตารางต่อไปนี้แสดงปัญหาที่เป็นไปได้และวิธีการระบุและแก้ไขปัญหาเหล่านั้น

ทรัพยากรความจุไม่เพียงพอ

การออกแบบรายงานที่ไม่มีประสิทธิภาพ

ชุดข้อมูลช้าโดยเฉพาะอย่างยิ่งเมื่อรายงานก่อนหน้านี้ทำได้ดี

การใช้รายงานพร้อมกันสูง

หมายเหตุ:
[1] การใช้หน่วยความจำเฉลี่ย (GB) และปริมาณการใช้หน่วยความจำสูงสุด (GB)
[2] การลดสัดส่วนชุดข้อมูล
[3] คิวรีชุดข้อมูล, ระยะเวลาการคิวรีโดยเฉลี่ยของชุดข้อมูล (มิลลิวินาที), จำนวนชุดข้อมูล และเวลารอของชุดข้อมูลโดยเฉลี่ย (มิลลิวินาที)
[4] จำนวนการใช้งาน CPU สูง และเวลาในการใช้งาน CPU สูงสุด (เจ็ดวันที่ผ่านมา)
[5] จำนวนการใช้งาน DQ/LC สูง และเวลาในการใช้งาน DQ/LC สูงสุด (เจ็ดวันที่ผ่านมา)

เหตุใดรายงานจึงไม่โหลด

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

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

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

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

ทำไมการรีเฟรชจึงไม่เริ่มต้นตามกำหนดเวลา

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

• มีหน่วยความจำเพียงพอ
• ไม่เกินจำนวนการรีเฟรชที่เกิดขึ้นพร้อมกันที่ความจุแบบพรีเมียมรองรับ

เมื่อไม่ตรงตามเงื่อนไข การรีเฟรชจะถูกจัดคิวไว้จนกว่าเงื่อนไขจะมีผล

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

โปรดทราบว่าจำนวนการรีเฟรชที่เกิดขึ้นพร้อมกันสูงสุดที่รองรับถูกตั้งไว้ที่ 1.5 เท่าของวี-คอร์ Backend โดยปัดเศษขึ้น

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

ผู้ดูแลระบบของความจุ (และผู้ดูแลระบบบริการของ Power BI) สามารถตรวจสอบเมตริก เวลารอรีเฟรชโดยเฉลี่ย (นาที) เพื่อกำหนดว่าการหน่วงเวลาเฉลี่ยระหว่างเวลาที่กำหนดไว้และจุดเริ่มต้นของการดำเนินการ

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

ทำไมการรีเฟรชจึงช้า

การรีเฟรชอาจช้าหรือรับรู้ได้ว่าจะช้า (ตามที่กล่าวถึงในคำถามทั่วไปก่อนหน้านี้)

เมื่อการรีเฟรชช้าลง อาจเป็นเพราะสาเหตุหลายประการ:

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

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

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

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

เมื่อต้องการเรียนรู้เพิ่มเติม ดูที่การรีเฟรชแบบเพิ่มหน่วยในชุดข้อมูล

ทำไมการรีเฟรชข้อมูลจึงไม่เสร็จสมบูรณ์

เมื่อการรีเฟรชข้อมูลเริ่มขึ้นแต่ไม่สำเร็จ อาจเป็นเพราะสาเหตุหลายประการ:

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

ผู้ดูแลระบบความจุ (และผู้ดูแลระบบบริการของ Power BI) สามารถตรวจสอบเมตริก การรีเฟรชล้มเหลวเนื่องจากหน่วยความจำไม่เพียงพอ

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

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

การปรับแบบจำลองที่เป็นโฮสต์ของ Power BI ให้เหมาะสม

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

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

ในเลเยอร์ของแหล่งข้อมูล:

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

ในเลเยอร์แบบจำลอง:

• การออกแบบคิวรี Power Query สามารถลดหรือลบการแปลงข้อมูลที่ซับซ้อนและโดยเฉพาะอย่างยิ่งที่รวมแหล่งข้อมูลที่แตกต่างกัน (คลังข้อมูลสามารถดำเนินการตามขั้นตอนนี้ได้ในช่วง Extract-Transform-Load) นอกจากนี้เพื่อให้มั่นใจว่ามีการตั้งค่าระดับความเป็นส่วนตัวของแหล่งข้อมูลที่เหมาะสม ซึ่งสามารถหลีกเลี่ยงได้โดยต้องใช้ Power BI ในการโหลดผลลัพธ์เต็มรูปแบบเพื่อสร้างผลลัพธ์แบบรวมทั่วทั้งการคิวรี
• โครงสร้างแบบจำลองจะกำหนดข้อมูลที่จะโหลดและมีผลกระทบโดยตรงต่อขนาดของแบบจำลอง ซึ่งสามารถออกแบบมาเพื่อหลีกเลี่ยงการโหลดข้อมูลที่ไม่จำเป็นโดยการลบคอลัมน์ การลบแถว (โดยเฉพาะข้อมูลประวัติ) หรือโดยการโหลดข้อมูลสรุป (มีค่าใช้จ่ายในการโหลดข้อมูลรายละเอียด) การลดขนาดแบบพิเศษสามารถทำได้โดยการลบคอลัมน์ที่มีคาร์ดินาลลิตี้สูง (โดยเฉพาะคอลัมน์ข้อความ) ซึ่งไม่ได้จัดเก็บหรือบีบอัดอย่างมีประสิทธิภาพ
• สามารถปรับปรุงประสิทธิภาพของการคิวรีแบบจำลองได้โดยการกำหนดค่าความสัมพันธ์ทิศทางเดียว เว้นแต่ว่ามีเหตุผลที่น่าสนใจเพื่อให้สามารถกรองแบบสองทิศทางได้ ลองใช้ฟังก์ชัน CROSSFILTER แทนการกรองแบบสองทิศทาง
• ตารางการรวมสามารถตอบสนองการคิวรีได้อย่างรวดเร็วโดยการโหลดข้อมูลที่สรุปไว้ล่วงหน้า อย่างไรก็ตามการดำเนินการนี้จะเพิ่มขนาดของแบบจำลองและส่งผลให้เวลาการรีเฟรชนานขึ้น โดยทั่วไป ตารางการรวมควรสำรองไว้สำหรับแบบจำลองที่มีขนาดใหญ่มากหรือการออกแบบแบบจำลองรวม
• ตารางและคอลัมน์จากการคำนวณจะเพิ่มขนาดของแบบจำลอง และทำให้เวลาการรีเฟรชนานขึ้น โดยทั่วไปขนาดของที่เก็บข้อมูลที่เล็กลงและเวลาการรีเฟรชที่รวดเร็วขึ้นสามารถเกิดขึ้นได้เมื่อมีการแสดงหรือการคำนวณข้อมูลในแหล่งข้อมูล หากไม่สามารถทำได้ การใช้คอลัมน์ที่กำหนดเองของ Power Query สามารถนำเสนอการบีบอัดที่เก็บข้อมูลที่ดีขึ้น
• อาจมีโอกาสในการปรับแต่งนิพจน์ DAX สำหรับหน่วยวัดและกฎ RLS ซึ่งอาจเขียนตรรกะใหม่เพื่อหลีกเลี่ยงสูตรราคาแพง
• การรีเฟรชแบบเพิ่มทีละส่วนสามารถลดเวลาการรีเฟรชได้อย่างมาก รวมถึงประหยัดหน่วยความจำและ CPU การรีเฟรชแบบเพิ่มทีละส่วนยังสามารถกำหนดค่าเพื่อลบข้อมูลประวัติที่มีข้อมูลการปรับแต่งขนาดของแบบจำลอง
• แบบจำลองไม่สามารถออกแบบใหม่เป็นสองแบบจำลองที่มีรูปแบบการคิวรีต่างกันและขัดแย้งกัน ตัวอย่างเช่น รายงานบางฉบับจะแสดงการรวมระดับสูงในทุก ๆ ประวัติและสามารถยอมรับเวลาแฝงใน 24 ชั่วโมง รายงานอื่น ๆ เกี่ยวข้องกับข้อมูลของวันนี้และต้องการการเข้าถึงธุรกรรมแต่ละรายการอย่างละเอียด ให้สร้างแบบจำลองสองแบบที่ปรับให้หมาะสมสำหรับแต่ละความต้องการแทนการออกแบบแบบจำลองเดียวเพื่อให้ตรงกับรายงานทั้งหมด

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

ในเลเยอร์ของแหล่งข้อมูล:

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

ในเลเยอร์แบบจำลอง:

• การออกแบบคิวรี Power Query ควรนำหลักการไม่มีการแปลงข้อมูลมาใช้ มิฉะนั้นแล้วต้องพยายามทำให้การแปลงข้อมูลอยู่ในระดับต่ำที่สุด
• สามารถปรับปรุงประสิทธิภาพของการคิวรีแบบจำลองได้โดยการกำหนดค่าความสัมพันธ์ทิศทางเดียว เว้นแต่ว่ามีเหตุผลที่น่าสนใจเพื่อให้สามารถกรองแบบสองทิศทางได้ นอกจากนี้ยังควรกำหนดค่าความสัมพันธ์ของแบบจำลองเพื่อแสดงการบังคับใช้ Referential Integrity (เมื่อเป็นกรณีนี้) และจะส่งผลให้มีการคิวรีแหล่งข้อมูลโดยใช้การรวมภายในที่มีประสิทธิภาพมากขึ้น (แทนการรวมภายนอก)
• หลีกเลี่ยงการสร้างคอลัมน์แบบกำหนดเองของคิวรี Power Query หรือคอลัมน์จากการคำนวณของแบบจำลอง โดยแสดงคอลัมน์เหล่านี้ในแหล่งข้อมูลเมื่อเป็นไปได้
• อาจมีโอกาสในการปรับแต่งนิพจน์ DAX สำหรับหน่วยวัดและกฎ RLS ซึ่งอาจเขียนตรรกะใหม่เพื่อหลีกเลี่ยงสูตรราคาแพง

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

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

การปรับแบบจำลองที่เป็นโฮสต์ภายนอกให้เหมาะสม

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

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

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

การวางแผนความจุ

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

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

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

• ขนาดแบบจำลองและลักษณะของข้อมูล - ต้องโหลดแบบจำลองการนำเข้าทั้งหมดลงในหน่วยความจำเพื่อให้สามารถทำการคิวรีหรือรีเฟรชได้ ชุดข้อมูล LC/DQ สามารถใช้เวลาของตัวประมวลผลที่สำคัญ และอาจต้องมีหน่วยความจำที่สำคัญในการประเมินการวัดผลที่ซับซ้อนหรือกฎ RLS หน่วยความจำ และขนาดของตัวประมวลผล และอัตราความเร็วของการคิวรี LC/DQ ถูกจำกัดโดยขนาดความจุ
• แบบจำลองที่ใช้งานพร้อมกัน - การคิวรีพร้อมกันของแบบจำลองการนำเข้าที่แตกต่างกันจะมีการตอบสนองและประสิทธิภาพการทำงานที่ดีที่สุดเมื่อแบบจำลองเหล่านั้นยังคงอยู่ในหน่วยความจำ ควรมีหน่วยความจำเพียงพอที่จะโฮสต์แบบจำลองที่มีการคิวรีอย่างหนักทั้งหมด พร้อมหน่วยความจำเพิ่มเติมเพื่ออนุญาตให้มีการรีเฟรช
• นำเข้าข้อมูลการรีเฟรชแบบจำลอง - ชนิดการรีเฟรช (เต็มรูปแบบหรือเพิ่มทีละส่วน) ระยะเวลาและความซับซ้อนของคิวรี Power Query และตรรกะของตาราง/คอลัมน์จากการคำนวณสามารถส่งผลกระทบต่อหน่วยความจำและการใช้งานตัวประมวลผลโดยเฉพาะ การรีเฟรชพร้อมกันจะจำกัดตามขนาดความจุ (1.5 x วี-คอร์ Backend โดยปัดเศษขึ้น)
• คิวรีที่เกิดขึ้นพร้อมกัน - คิวรีที่เกิดขึ้นพร้อมกันหลายแห่งอาจส่งผลให้รายงานไม่ตอบสนองเมื่อการเชื่อมต่อตัวประมวลผลหรือ LC/DQ เกินขีดจำกัดความจุ โดยเฉพาะอย่างยิ่งกรณีสำหรับหน้ารายงานที่มีวิชวลจำนวนมาก
• กระแสข้อมูลและรายงานที่มีการแบ่งหน้า - สามารถกำหนดค่าความจุเพื่อรองรับกระแสข้อมูลและรายงานที่มีการแบ่งหน้าโดยแต่ละรายการต้องใช้ค่าเปอร์เซ็นต์สูงสุดของหน่วยความจำความจุที่สามารถกำหนดค่าได้ ระบบได้จัดสรรหน่วยความจำให้กับกระแสข้อมูลเชิงไดนามิก แต่ในเชิงสแตติกแล้วระบบได้จัดสรรหน่วยความจำนั้นให้กับรายงานที่มีการแบ่งหน้า

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

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

โปรดทราบการซื้อสิทธิ์การใช้งานจะมีวี-คอร์ให้กับผู้เช่า การซื้อการสมัครใช้งาน P3 สามารถใช้เพื่อสร้างความจุแบบพรีเมียมหนึ่งแบบหรือสูงสุดสี่แบบ เช่น 1 x P3 หรือ 2 x P2 หรือ 4 x P1 ได้ นอกจากนี้ ก่อนที่จะเพิ่มขนาดความจุ P2 เป็นความจุ P3 คุณสามารถพิจารณาการแยกวี-คอร์เพื่อสร้างความจุ P1 สองแบบ

การทดสอบวิธีการ

เมื่อตัดสินใจเลือกขนาดความจุแล้ว การทดสอบสามารถทำได้โดยการสร้างสภาพแวดล้อมที่มีการควบคุม ตัวเลือกที่ใช้ได้จริงและประหยัดคือการสร้างความจุ Azure (A SKUs) โดยสังเกตว่าความจุ P1 มีขนาดเท่ากับความจุ A4 ขณะที่ความจุ P2 และ P3 มีขนาดเท่ากับความจุ A5 และ A6 ตามลำดับ ความจุ Azure สามารถสร้างได้อย่างรวดเร็วและมีการเรียกเก็บเงินเป็นรายชั่วโมง ดังนั้นเมื่อการทดสอบเสร็จสิ้น สามารถลบความจุเหล่านี้ได้อย่างง่ายดายเพื่อหยุดค่าใช้จ่ายที่เกิดขึ้น

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

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

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

หากต้องสร้างการทดสอบที่ซับซ้อนมากขึ้น ให้ลองพัฒนาแอปพลิเคชันการทดสอบโหลดเพื่อจำลองปริมาณงานจริง สำหรับข้อมูลเพิ่มเติม ให้ดูการสัมมนาผ่านเว็บ การทดสอบโหลดของแอปพลิเคชัน Power BI ที่มีการทดสอบการโหลด Visual Studio

กิตติกรรมประกาศ

บทความนี้เขียนโดย Peter Myers, MVP แพลตฟอร์มข้อมูล และผู้เชี่ยวชาญ BI อิสระด้วย โซลูชันแบบ Bitwise

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

มีคำถามเพิ่มเติมหรือไม่ ลองถามชุมชน Power BI

Power BI ได้เผยแพร่ Power BI Premium Gen2 ซึ่งช่วยปรับปรุงประสบการณ์การใช้งาน Power BI Premiumการปรับปรุงต่อไปนี้:

• ประสิทธิภาพการทำงาน
• สิทธิการใช้งานต่อผู้ใช้
• ขนาดใหญ่ขึ้น
• เมตริกที่ดีขึ้น
• การปรับขนาดอัตโนมัติ
• ลดค่าใช้จ่ายในการจัดการ

โปรดดูที่ Power BI Premiumรุ่น2เพื่อPremium Power BI