ทําความเข้าใจและปรับการรีเฟรชกระแสข้อมูลให้เหมาะสม

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

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

ทําความเข้าใจกับการรีเฟรช

มีการรีเฟรชสองประเภทที่สามารถใช้ได้กับกระแสข้อมูล:

  • แบบเต็ม ซึ่งดําเนินการล้างค่าที่สมบูรณ์และโหลดข้อมูลของคุณอีกครั้ง

  • การเพิ่ม (Premium เท่านั้น) ซึ่งประมวลผลชุดย่อยของข้อมูลของคุณตามกฎตามเวลาซึ่งแสดงเป็นตัวกรองที่คุณกําหนดค่า ตัวกรองบนคอลัมน์วันที่จะแบ่งพาร์ติชันข้อมูลเป็นช่วงในบริการของ Power BI แบบไดนามิก หลังจากที่คุณกําหนดค่าการรีเฟรชแบบเพิ่มหน่วยกระแสข้อมูลจะเปลี่ยนคิวรีของคุณโดยอัตโนมัติเพื่อรวมการกรองตามวันที่ คุณสามารถแก้ไขคิวรีที่สร้างขึ้นโดยอัตโนมัติโดยใช้เครื่องมือแก้ไขขั้นสูงใน Power Query เพื่อปรับแต่งหรือกําหนดค่าการรีเฟรชของคุณ ถ้าคุณนํา Azure Data Lake Storage ของคุณเองมาใช้ คุณสามารถดูตัวแบ่งส่วนเวลาของข้อมูลของคุณตามนโยบายการรีเฟรชที่คุณได้ตั้งค่าไว้ได้

    หมายเหตุ

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

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

  • การรีเฟรชจะเร็วขึ้นหลังจากการรีเฟรชครั้งแรก เนื่องจากข้อเท็จจริงต่อไปนี้:

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

  • การใช้ทรัพยากรลดลง - เมื่อต้องรีเฟรชข้อมูลน้อยลง ทําให้ปริมาณการใช้โดยรวมของความจําและทรัพยากรอื่นๆ ลดลงด้วย

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

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

ทําความเข้าใจและปรับการรีเฟรชให้เหมาะสม

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

Screenshot of dataflows refresh history.

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

Item คำอธิบาย Pro พรีเมียม
ร้องขอเมื่อ การรีเฟรชเวลาถูกจัดกําหนดการหรือรีเฟรชในขณะนี้ถูกคลิก ในเวลาท้องถิ่น
ชื่อกระแสข้อมูล ชื่อของกระแสข้อมูลของคุณ
สถานะการรีเฟรชกระแสข้อมูล เสร็จสมบูรณ์ ล้มเหลว หรือข้าม (สําหรับเอนทิตี) เป็นสถานะที่เป็นไปได้ ใช้กรณีเช่นเอนทิตีที่เชื่อมโยงเป็นเหตุผลว่าทําไมอาจเห็นการข้าม
ชื่อเอนทิตี้ ชื่อตาราง
ชื่อพาร์ติชัน รายการนี้จะขึ้นอยู่กับถ้ากระแสข้อมูลเป็นแบบพรีเมียมหรือไม่ และหาก Pro แสดงเป็น NA เนื่องจากไม่สนับสนุนการรีเฟรชแบบเพิ่มหน่วย Premium แสดง FullRefreshPolicyPartition หรือ IncrementalRefreshPolicyPartition-[DateRange]
สถานะการรีเฟรช สถานะการรีเฟรชของเอนทิตี้หรือพาร์ติชันแต่ละรายการซึ่งมีสถานะสําหรับส่วนเวลาดังกล่าวของข้อมูลที่กําลังรีเฟรช
เวลาเริ่มต้น ใน Premium รายการนี้คือเวลาที่กระแสข้อมูลถูกจัดคิวสําหรับการประมวลผลสําหรับเอนทิตีหรือพาร์ติชัน เวลานี้อาจแตกต่างกันหากกระแสข้อมูลมีการขึ้นต่อกัน และต้องรอให้ชุดผลลัพธ์ของกระแสข้อมูลเริ่มต้นการประมวลผล
เวลาสิ้นสุด เวลาสิ้นสุดคือเวลาที่เอนทิตีกระแสข้อมูลหรือพาร์ติชันเสร็จสมบูรณ์ ถ้ามี
ระยะเวลา เวลาที่ผ่านไปทั้งหมดสําหรับการรีเฟรชกระแสข้อมูลที่แสดงใน HH:MM:SS
ประมวลผลแถวแล้ว สําหรับเอนทิตีหรือพาร์ติชันที่กําหนด จํานวนแถวที่สแกนหรือเขียนโดยกลไกของกระแสข้อมูล รายการนี้อาจไม่ประกอบด้วยข้อมูลตามการดําเนินการที่คุณดําเนินการเสมอไป ข้อมูลอาจถูกเว้นไว้เมื่อไม่ได้ใช้กลไกการคํานวณ หรือเมื่อคุณใช้เกตเวย์ขณะที่ข้อมูลถูกประมวลผลที่นั่น
ไบต์ที่ประมวลผล สําหรับเอนทิตีหรือพาร์ติชันที่กําหนด ข้อมูลที่เขียนโดยกลไกของกระแสข้อมูล จะแสดงเป็นไบต์

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

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

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

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

คําแนะนําในการรีเฟรชกระแสข้อมูล

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

การประสานรวม

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

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

การตรวจสอบ

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

ข้อผิดพลาดการหมดเวลา

การปรับเวลาที่ใช้ในการดําเนินการแยก แปลง และโหลด (ETL) ให้เหมาะสมที่สุด ใน Power BI กรณีต่อไปนี้จะนําไปใช้:

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

คําแนะนําการหมดเวลา

ค่าเกณฑ์การหมดเวลาสําหรับกระแสข้อมูล Power BI Pro คือ:

  • สองชั่วโมงที่ระดับเอนทิตี้แต่ละระดับ
  • สามชั่วโมงในระดับกระแสข้อมูลทั้งหมด

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

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

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

ระยะเวลาที่ยาวนาน

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

คําแนะนําสําหรับระยะเวลาการรีเฟรชแบบยาว

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

ถัดไป จะช่วยประเมินว่าคุณสามารถใช้การรีเฟรชแบบเพิ่มหน่วยได้หรือไม่

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

อย่างไรก็ตาม แหล่งข้อมูล เช่น ไฟล์ข้อมูลธรรมดา, blobs และ API มักไม่สนับสนุนการกรอง ในกรณีที่ Back-end ของแหล่งข้อมูลไม่สนับสนุนตัวกรอง จะไม่สามารถเก็บข้อมูลเข้าในตัวกรองได้ ในกรณีดังกล่าว โปรแกรม Mash-up จะชดเชยและใช้ตัวกรองภายในเครื่อง ซึ่งอาจจําเป็นต้องเรียกแบบจําลองความหมายแบบเต็มจากแหล่งข้อมูล การดําเนินการนี้อาจทําให้การรีเฟรชแบบเพิ่มหน่วยช้า และกระบวนการสามารถใช้ทรัพยากรหมดทั้งในบริการของ Power BI หรือในเกตเวย์ข้อมูลภายในองค์กร ถ้าใช้

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

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

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

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

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

    • เครื่องมือเช่น Azure Speed Test สามารถบ่งชี้เวลาแฝงบนเครือข่ายระหว่างไคลเอ็นต์และภูมิภาค Azure ได้ โดยทั่วไป พยายามให้แหล่งข้อมูล เกตเวย์ และคลัสเตอร์ Power BI ของคุณอยู่ใกล้กันมากที่สุดเพื่อลดผลกระทบของเวลาแฝงบนเครือข่าย ควรตกค้างในภูมิภาคเดียวกัน ถ้าเเวลาแฝงบนเครือข่ายคือปัญหา ให้ลองย้ายเกตเวย์และแหล่งข้อมูลมาใกล้กับคลัสเตอร์ Power BI ของคุณมากขึ้น โดยการวางไว้ภายในเครื่องเสมือนที่โฮสต์แบบคลาวด์

เวลาตัวประมวลผลสูง

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

คําแนะนําสําหรับเวลาตัวประมวลผลสูง

มีตัวเลือกสองตัวเลือกในการปรับเวลาตัวประมวลผลสูงให้เหมาะสม

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

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

ใช้กลไกการคํานวณเพื่อเพิ่มประสิทธิภาพสูงสุด

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

ส่วนต่อไปนี้จะให้คําแนะนําเกี่ยวกับการใช้กลไกการคํานวณและสถิติ

คำเตือน

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

คําแนะนําเกี่ยวกับสถานะกลไกการคํานวณ

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

NA - สถานะนี้หมายความว่าไม่ได้ใช้กลไกการคํานวณ เนื่องจาก:

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

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

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

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

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

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

สถานะการพับจะปรากฏขึ้นหากคุณกําลังใช้แหล่งข้อมูลภายในองค์กรหรือระบบคลาวด์ ก่อนอื่นให้คุณโหลดข้อมูลลงในกระแสข้อมูลการจัดเตรียมและอ้างอิงข้อมูลนั้นในกระแสข้อมูลนี้ สถานะนี้ใช้กับเอนทิตีที่อ้างอิงเอนทิตีอื่นเท่านั้น ซึ่งหมายความว่าคิวรีของคุณกําลังทํางานอยู่ด้านบนของกลไก SQL และคิวรีเหล่านี้มีศักยภาพในการปรับปรุงด้วยการคํานวณ SQL เพื่อให้แน่ใจว่ากลไกจัดการ SQL ประมวลผลการแปลงของคุณ ใช้การแปลงข้อมูลที่สนับสนุน SQL Folding เช่น merge (join), group by (aggregation) และผนวก (union) ในตัวแก้ไขคิวรี

แคช + พับ - เมื่อคุณเห็น แคช + พับอาจเป็นไปได้ว่าการรีเฟรชข้อมูลได้รับการปรับให้เหมาะสมเนื่องจากคุณมีเอนทิตีที่ทั้งคู่อ้างอิงถึงเอนทิตีอื่นและเรียกว่าอัพสตรีมของเอนทิตีอื่น การดําเนินการนี้ยังทํางานที่ด้านบนของ SQL และนอกจากนี้ยังมีศักยภาพในการปรับปรุงด้วยการคํานวณ SQL เพื่อให้แน่ใจว่า คุณจะได้รับประสิทธิภาพที่ดีที่สุดที่เป็นไปได้ ใช้การแปลงที่สนับสนุน SQL Folding เช่น merge (join), group by (aggregation) และผนวก (union) ในตัวแก้ไขคิวรี

คําแนะนําสําหรับการปรับประสิทธิภาพกลไกการคํานวณให้เหมาะสม

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

เอนทิตีที่คํานวณและเชื่อมโยงในพื้นที่ทํางานเดียวกัน:

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

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

นอกจากนี้ยังสร้างกระแส ข้อมูลภายในแนวทางและข้อจํากัดที่เผยแพร่

เมื่อเครื่องคํานวณเปิดอยู่ แต่ประสิทธิภาพการทํางานช้า:

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

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

ข้อควรพิจารณาและข้อจำกัด

สิทธิ์การใช้งาน Power BI Pro มีขีดจํากัดการรีเฟรชกระแสข้อมูล 8 การรีเฟรชต่อวัน