ทําความเข้าใจและปรับการรีเฟรชกระแสข้อมูลให้เหมาะสม
กระแสข้อมูล Power BI ช่วยให้คุณสามารถเชื่อมต่อ แปลง รวม และกระจายข้อมูลสําหรับการวิเคราะห์แบบปลายทางได้ องค์ประกอบสําคัญในกระแสข้อมูลคือกระบวนการรีเฟรช ซึ่งใช้ขั้นตอนการแปลงที่คุณสร้างในกระแสข้อมูลและอัปเดตข้อมูลในรายการด้วยตนเอง
เพื่อทําความเข้าใจเวลาทํางาน ประสิทธิภาพการทํางาน และไม่ว่าคุณจะได้รับประโยชน์สูงสุดจากกระแสข้อมูลของคุณหรือไม่ คุณสามารถดาวน์โหลดประวัติการรีเฟรชหลังจากที่คุณรีเฟรชกระแสข้อมูลได้
ทําความเข้าใจกับการรีเฟรช
มีการรีเฟรชสองประเภทที่สามารถใช้ได้กับกระแสข้อมูล:
แบบเต็ม ซึ่งดําเนินการล้างค่าที่สมบูรณ์และโหลดข้อมูลของคุณอีกครั้ง
การเพิ่ม (Premium เท่านั้น) ซึ่งประมวลผลชุดย่อยของข้อมูลของคุณตามกฎตามเวลาซึ่งแสดงเป็นตัวกรองที่คุณกําหนดค่า ตัวกรองบนคอลัมน์วันที่จะแบ่งพาร์ติชันข้อมูลเป็นช่วงในบริการของ Power BI แบบไดนามิก หลังจากที่คุณกําหนดค่าการรีเฟรชแบบเพิ่มหน่วยกระแสข้อมูลจะเปลี่ยนคิวรีของคุณโดยอัตโนมัติเพื่อรวมการกรองตามวันที่ คุณสามารถแก้ไขคิวรีที่สร้างขึ้นโดยอัตโนมัติโดยใช้เครื่องมือแก้ไขขั้นสูงใน Power Query เพื่อปรับแต่งหรือกําหนดค่าการรีเฟรชของคุณ ถ้าคุณนํา Azure Data Lake Storage ของคุณเองมาใช้ คุณสามารถดูตัวแบ่งส่วนเวลาของข้อมูลของคุณตามนโยบายการรีเฟรชที่คุณได้ตั้งค่าไว้ได้
หมายเหตุ
หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับการรีเฟรชแบบเพิ่มหน่วยและวิธีการทํางาน โปรดดู การใช้การรีเฟรชแบบเพิ่มหน่วยกับกระแสข้อมูล
การรีเฟรชแบบเพิ่มหน่วยจะทําให้กระแสข้อมูลขนาดใหญ่ใน Power BI มีสิทธิประโยชน์ต่อไปนี้:
การรีเฟรชจะเร็วขึ้นหลังจากการรีเฟรชครั้งแรก เนื่องจากข้อเท็จจริงต่อไปนี้:
- Power BI รีเฟรชพาร์ติชัน N สุดท้ายที่ระบุโดยผู้ใช้ (โดยที่พาร์ติชันคือ วัน/สัปดาห์/เดือน และอื่น ๆ) หรือ
- Power BI รีเฟรชเฉพาะข้อมูลที่จําเป็นต้องรีเฟรช ตัวอย่างเช่น การรีเฟรชเฉพาะห้าวันที่ผ่านมาของแบบจําลองความหมาย 10 ปี
- Power BI จะรีเฟรชข้อมูลที่มีการเปลี่ยนแปลงเท่านั้น ตราบใดที่คุณระบุคอลัมน์ที่คุณต้องการตรวจสอบการเปลี่ยนแปลง
การรีเฟรชน่าเชื่อถือมากขึ้น - ไม่จําเป็นต้องรักษาการเชื่อมต่อระยะยาวกับระบบต้นทางที่ผันผวน
การใช้ทรัพยากรลดลง - เมื่อต้องรีเฟรชข้อมูลน้อยลง ทําให้ปริมาณการใช้โดยรวมของความจําและทรัพยากรอื่นๆ ลดลงด้วย
Power BI ใช้การประมวลผลแบบขนานบนพาร์ติชันทุกที่ที่เป็นไปได้ ซึ่งอาจทําให้รีเฟรชได้เร็วขึ้น
ในสถานการณ์การรีเฟรชเหล่านี้ หากการรีเฟรชล้มเหลว ข้อมูลจะไม่อัปเดต ข้อมูลของคุณอาจล้าหลังจนกว่าการรีเฟรชล่าสุดจะเสร็จสมบูรณ์ หรือคุณสามารถรีเฟรชด้วยตนเองและสามารถดําเนินการให้เสร็จสมบูรณ์ได้โดยไม่มีข้อผิดพลาด การรีเฟรชเกิดขึ้นที่พาร์ติชันหรือเอนทิตี ดังนั้นถ้าการรีเฟรชแบบเพิ่มหน่วยล้มเหลว หรือเอนทิตีมีข้อผิดพลาด ธุรกรรมการรีเฟรชทั้งหมดจะไม่เกิดขึ้น กล่าวอีกวิธีหนึ่งคือ ถ้าพาร์ติชัน (นโยบายการรีเฟรชแบบเพิ่มหน่วย) หรือเอนทิตีล้มเหลวสําหรับกระแสข้อมูล การดําเนินการรีเฟรชทั้งหมดจะล้มเหลว และไม่มีการอัปเดตข้อมูล
ทําความเข้าใจและปรับการรีเฟรชให้เหมาะสม
เพื่อให้เข้าใจวิธีการดําเนินการรีเฟรชกระแสข้อมูลได้ดียิ่งขึ้น ให้ตรวจสอบ ประวัติการรีเฟรช สําหรับกระแสข้อมูลโดยนําทางไปยังกระแสข้อมูลของคุณ เลือกตัวเลือก เพิ่มเติม (...) สําหรับกระแสข้อมูล จากนั้นเลือกประวัติการรีเฟรชการตั้งค่า > คุณยังสามารถเลือกกระแสข้อมูลในพื้นที่ทํางาน จากนั้นเลือก ตัวเลือกเพิ่มเติม (...) > รีเฟรชประวัติ
ประวัติการรีเฟรชให้ภาพรวมของการรีเฟรช รวมถึงชนิด – ตามความต้องการหรือตามกําหนดเวลา ระยะเวลา และสถานะการเรียกใช้ หากต้องการดูรายละเอียดในรูปแบบของไฟล์ 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 หลายคุณลักษณะ
ระยะเวลาที่ยาวนาน
กระแสข้อมูลที่ซับซ้อนหรือใหญ่อาจใช้เวลาในการรีเฟรชมากขึ้นเนื่องจากกระแสข้อมูลที่ปรับให้เหมาะสมไม่ดี ส่วนต่อไปนี้จะให้คําแนะนําเกี่ยวกับวิธีการลดระยะเวลาการรีเฟรชที่นาน
คําแนะนําสําหรับระยะเวลาการรีเฟรชแบบยาว
ขั้นตอนแรกในการปรับปรุงระยะเวลาการรีเฟรชที่นานสําหรับกระแสข้อมูลคือการสร้างกระแสข้อมูลตาม แนวทางปฏิบัติที่ดีที่สุด รูปแบบที่โดดเด่นรวมถึง:
- ใช้ เอนทิตี ที่มีการเชื่อมโยงสําหรับข้อมูลที่สามารถใช้ในภายหลังในการแปลงอื่น ๆ
- ใช้เอนทิตี ที่คํานวณเพื่อแคชข้อมูล ช่วยลดการโหลดข้อมูลและภาระการนําเข้าข้อมูลในระบบต้นทาง
- แยกข้อมูลลงใน การจัดเตรียมกระแส ข้อมูลและ การแปลงกระแสข้อมูล โดยแยก ETL เป็นกระแสข้อมูลที่แตกต่างกัน
- ปรับการขยายการทํางานของตารางให้เหมาะสม
- ทําตามคําแนะนํา สําหรับกระแสข้อมูลที่ซับซ้อน
ถัดไป จะช่วยประเมินว่าคุณสามารถใช้การรีเฟรชแบบเพิ่มหน่วยได้หรือไม่
การใช้ การรีเฟรช แบบเพิ่มหน่วยสามารถปรับปรุงประสิทธิภาพการทํางานได้ เป็นสิ่งสําคัญที่ตัวกรองพาร์ติชันจะถูกส่งไปยังระบบแหล่งข้อมูลเมื่อมีการส่งคิวรีให้ดําเนินการรีเฟรช การผลักดันการกรองข้อมูลลงไปหมายความว่าแหล่งข้อมูลควรสนับสนุน 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 การรีเฟรชต่อวัน