หมายเหตุ
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลอง ลงชื่อเข้าใช้หรือเปลี่ยนไดเรกทอรีได้
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลองเปลี่ยนไดเรกทอรีได้
โมเดลความหมายในความจุแบบพรีเมียมที่มี ตําแหน่งข้อมูล XMLA ที่เปิดใช้งานสําหรับการดําเนินการอ่าน/เขียนช่วยให้สามารถรีเฟรชขั้นสูง การจัดการพาร์ติชัน และการปรับใช้เฉพาะข้อมูลเมตาผ่านเครื่องมือ การเขียนสคริปต์ และการสนับสนุน API นอกจากนี้ การดําเนินการรีเฟรชผ่านจุดสิ้นสุด XMLA ไม่จํากัดการรีเฟรช 48 ครั้งต่อวัน และไม่มีการกําหนดขีดจํากัดเวลาการรีเฟรชตามกําหนดการ
พาร์ ติ ชัน
พาร์ติชันตารางแบบจําลองความหมายไม่สามารถมองเห็นได้ และไม่สามารถจัดการได้โดยใช้ Power BI Desktop หรือบริการของ Power BI สําหรับโมเดลในพื้นที่ทํางานที่กําหนดให้กับความจุแบบพรีเมียม พาร์ติชันสามารถจัดการได้ผ่านตําแหน่งข้อมูล XMLA คุณสามารถใช้เครื่องมือเช่น SQL Server Management Studio (SSMS) หรือตัวแก้ไขตารางแบบโอเพนซอร์สเพื่อจัดการพาร์ติชันผ่านการเขียนสคริปต์ด้วย Tabular Model Scripting Language (TMSL) และโดยทางโปรแกรมด้วย Tabular Object Model (TOM)
เมื่อคุณเผยแพร่แบบจําลองไปยังบริการของ Power BI เป็นครั้งแรก แต่ละตารางในแบบจําลองใหม่จะมีหนึ่งพาร์ติชัน สําหรับตารางที่ไม่มีนโยบายการรีเฟรชแบบเพิ่มหน่วย พาร์ติชันหนึ่งนั้นมีแถวข้อมูลทั้งหมดสําหรับตารางนั้น เว้นแต่จะใช้ตัวกรอง สําหรับตารางที่มีนโยบายการรีเฟรชแบบเพิ่มหน่วย พาร์ติชันเริ่มต้นหนึ่งพาร์ติชันนั้นมีอยู่เพียงเนื่องจาก Power BI ยังไม่ได้ใช้นโยบาย คุณกําหนดค่าพาร์ติชันเริ่มต้นใน Power BI Desktop เมื่อคุณกําหนดตัวกรองช่วงวันที่/เวลาสําหรับตารางของคุณตาม RangeStart พารามิเตอร์ และ RangeEnd และตัวกรองอื่นๆ ที่ใช้ในตัวแก้ไข Power Query พาร์ติชันเริ่มต้นนี้มีเฉพาะแถวของข้อมูลที่ตรงกับเกณฑ์การกรองของคุณ
เมื่อคุณดําเนินการรีเฟรช ครั้งแรก ตารางที่ไม่มีนโยบายการรีเฟรชแบบเพิ่มหน่วยจะรีเฟรชแถวทั้งหมดที่มีอยู่ในพาร์ติชันเดียวเริ่มต้นของตารางนั้น สําหรับตารางที่มีนโยบายการรีเฟรชแบบเพิ่มหน่วย การรีเฟรชและพาร์ติชันในอดีตจะถูกสร้างขึ้นโดยอัตโนมัติ และแถวจะถูกโหลดลงไปตามวันที่/เวลาสําหรับแต่ละแถว ถ้านโยบายการรีเฟรชแบบเพิ่มหน่วยรวมถึงการรับข้อมูลแบบเรียลไทม์ Power BI ยังเพิ่มพาร์ติชัน DirectQuery ลงในตาราง
สําคัญ
เมื่อคุณใช้การรีเฟรชแบบเพิ่มหน่วยกับข้อมูลแบบเรียลไทม์ (โหมดไฮบริด) ตารางที่เกี่ยวข้องกับตารางไฮบริดควรใช้โหมดที่เก็บข้อมูลคู่เพื่อหลีกเลี่ยงบทลงโทษด้านประสิทธิภาพ นอกจากนี้ การแคชวิชวลสามารถชะลอการอัปเดตแบบสดจนกว่าวิชวลจะคิวรีข้อมูลอีกครั้ง สําหรับข้อมูลเพิ่มเติม โปรดดู แก้ไขปัญหาการรีเฟรชแบบเพิ่มหน่วยและข้อมูลแบบเรียลไทม์
การดําเนินการรีเฟรชครั้งแรกนี้อาจใช้เวลาค่อนข้างนานขึ้นอยู่กับจํานวนข้อมูลที่ต้องโหลดจากแหล่งข้อมูล ความซับซ้อนของแบบจําลองอาจเป็นปัจจัยสําคัญเนื่องจากการดําเนินการรีเฟรชต้องทําการประมวลผลและการคํานวณใหม่มากขึ้น การดําเนินการนี้สามารถบูตสแตรปได้ สําหรับข้อมูลเพิ่มเติม โปรดดู ป้องกันการหมดเวลาในการรีเฟรชเต็มรูปแบบครั้งแรก
พาร์ติชันถูกสร้างขึ้นและตั้งชื่อตามความละเอียดของช่วงเวลา: ปี ไตรมาส เดือน และวัน พาร์ติชันล่าสุด พาร์ติชันรี เฟรช ประกอบด้วยแถวในรอบระยะเวลาการรีเฟรชที่คุณระบุในนโยบาย พาร์ติชันในอดีตประกอบด้วยแถวตามรอบระยะเวลาที่สมบูรณ์จนถึงรอบระยะเวลาการรีเฟรช ถ้าเปิดใช้งานแบบเรียลไทม์ พาร์ติชัน DirectQuery จะเลือกการเปลี่ยนแปลงข้อมูลใดๆ ที่เกิดขึ้นหลังจากวันที่สิ้นสุดของรอบระยะเวลาการรีเฟรช ความละเอียดสําหรับการรีเฟรชและพาร์ติชันในอดีตจะขึ้นอยู่กับการรีเฟรชและช่วงเวลาในอดีต (จัดเก็บ) ที่คุณเลือกเมื่อกําหนดนโยบาย
ตัวอย่างเช่น ถ้าวันที่ของวันนี้คือวันที่ 2 กุมภาพันธ์ 2021 และตาราง FactInternetSales ของเราที่แหล่งข้อมูลมีแถวจนถึงวันนี้ หากนโยบายของเราระบุว่าจะรวมการเปลี่ยนแปลงแบบเรียลไทม์ รีเฟรชแถวในช่วงเวลาการรีเฟรชหนึ่งวันล่าสุด และจัดเก็บแถวในช่วงเวลาในอดีตสามปีที่ผ่านมา จากนั้นด้วยการดําเนินการรีเฟรชครั้งแรก พาร์ติชัน DirectQuery จะถูกสร้างขึ้นสําหรับการเปลี่ยนแปลงในอนาคต พาร์ติชันนําเข้าใหม่ถูกสร้างขึ้นสําหรับแถวของวันนี้ และพาร์ติชันในอดีตจะถูกสร้างขึ้นสําหรับเมื่อวานนี้ ซึ่งเป็นช่วงเวลาทั้งวัน 1 กุมภาพันธ์ 2021 พาร์ติชันในอดีตถูกสร้างขึ้นสําหรับช่วงเวลาทั้งเดือนก่อนหน้า (มกราคม 2021) พาร์ติชันในอดีตถูกสร้างขึ้นสําหรับรอบระยะเวลาทั้งปีก่อนหน้า (2020) และพาร์ติชันในอดีตสําหรับช่วงเวลาทั้งปี 2019 และ 2018 ถูกสร้างขึ้น ไม่มีการสร้างพาร์ติชันทั้งไตรมาส เนื่องจากในวันที่ 2 กุมภาพันธ์ ไตรมาสแรกของปี 2021 ยังไม่เสร็จสมบูรณ์
ด้วยการดําเนินการรีเฟรชแต่ละครั้ง เฉพาะพาร์ติชันสําหรับรอบระยะเวลาการรีเฟรชเท่านั้นที่จะถูกรีเฟรช ตัวกรองวันที่ของพาร์ติชัน DirectQuery ได้รับการอัปเดตเพื่อรวมเฉพาะการเปลี่ยนแปลงที่เกิดขึ้นหลังจากรอบระยะเวลาการรีเฟรชปัจจุบัน พาร์ติชันการรีเฟรชใหม่จะถูกสร้างขึ้นสําหรับแถวใหม่ที่มีวันที่/เวลาใหม่ภายในรอบระยะเวลาการรีเฟรชที่อัปเดต แถวที่มีอยู่ที่มีวันที่/เวลาอยู่แล้วภายในพาร์ติชันที่มีอยู่ในช่วงเวลาการรีเฟรชจะถูกรีเฟรชด้วยการอัปเดต แถวที่มีวันที่/เวลาเก่ากว่ารอบระยะเวลาการรีเฟรชจะไม่ถูกรีเฟรชอีกต่อไป
เมื่อรอบระยะเวลาทั้งหมดปิดลง พาร์ติชันจะถูกรวมเข้าด้วยกัน ตัวอย่างเช่นหากมีการระบุระยะเวลาการรีเฟรชหนึ่งวันและระยะเวลาการจัดเก็บในอดีตสามปีในนโยบายในวันแรกของเดือนพาร์ติชันวันทั้งหมดสําหรับเดือนก่อนหน้าจะถูกรวมเป็นพาร์ติชันเดือน ในวันแรกของไตรมาสใหม่พาร์ติชันทั้งสามเดือนก่อนหน้าจะถูกรวมเป็นพาร์ติชันไตรมาส ในวันแรกของปีใหม่พาร์ติชันไตรมาสก่อนหน้าทั้งสี่จะถูกรวมเป็นพาร์ติชันปี
โมเดลจะเก็บพาร์ติชันไว้เสมอสําหรับรอบระยะเวลาการจัดเก็บในอดีตทั้งหมดรวมถึงพาร์ติชันรอบระยะเวลาทั้งหมดจนถึงรอบระยะเวลาการรีเฟรชปัจจุบัน ในตัวอย่าง ข้อมูลในอดีตสามปีเต็มจะถูกเก็บไว้ในพาร์ติชันสําหรับปี 2018, 2019, 2020 และพาร์ติชันสําหรับรอบระยะเวลาเดือน 2021Q101 รอบระยะเวลาวัน 2021Q10201 และพาร์ติชันรอบระยะเวลาการรีเฟรชวันปัจจุบัน พาร์ติชัน 2018 จะถูกเก็บไว้จนกว่าจะรีเฟรชครั้งแรกในวันที่ 1 มกราคม 2022
ด้วยการรีเฟรชแบบเพิ่มหน่วยของ Power BI และข้อมูลแบบเรียลไทม์ บริการจะจัดการการจัดการพาร์ติชันให้คุณตามนโยบาย ในขณะที่บริการสามารถจัดการการจัดการพาร์ติชันทั้งหมดสําหรับคุณ โดยใช้เครื่องมือผ่านจุดสิ้นสุด XMLA คุณสามารถเลือกรีเฟรชพาร์ติชันทีละพาร์ติชัน ตามลําดับ หรือแบบขนานได้
รูปแบบการรีเฟรชพาร์ติชันทั่วไป
เมื่อทํางานกับการดําเนินการปลายทาง XMLA ให้พิจารณารูปแบบทั่วไปเหล่านี้สําหรับการจัดการการดําเนินการรีเฟรช:
- การรีเฟรชขนาดเล็กบ่อยครั้ง: เรียกใช้การดําเนินการรีเฟรชขนาดเล็กที่ตรงเป้าหมายหลายรายการในช่วงเวลาทําการโดยใช้คําสั่งพาร์ติชัน XMLA หรือ REST API ที่ปรับปรุงแล้วเพื่อให้ข้อมูลล่าสุดเป็นปัจจุบันโดยไม่ต้องประมวลผลทั้งตาราง
- การทดแทนในอดีตที่เลือก: ทําการรีเฟรชพาร์ติชันในอดีตที่ใหญ่ขึ้นหรือการแก้ไขข้อมูลแบบครั้งเดียวในช่วงนอกเวลาทําการโดยใช้ TMSL เพื่อสร้าง
applyRefreshPolicy: falseช่วงเวลาในอดีตที่เฉพาะเจาะจงใหม่โดยไม่ส่งผลกระทบต่อพฤติกรรมของนโยบายอัตโนมัติ - การโหลดเริ่มต้นแบบทีละขั้นตอน: สําหรับช่วงเวลาในอดีตขนาดใหญ่ ให้แบ่งการรีเฟรชเริ่มต้นออกเป็นชุดงานที่เล็กลงโดยการประมวลผลพาร์ติชันทีละน้อยเพื่อหลีกเลี่ยงการหมดเวลาและจัดการการใช้ทรัพยากร
รูปแบบเหล่านี้ช่วยให้คุณสามารถสร้างสมดุลระหว่างความใหม่ของข้อมูลแบบเรียลไทม์กับประสิทธิภาพของระบบและข้อจํากัดของทรัพยากร
การจัดการการรีเฟรชด้วย SQL Server Management Studio
SQL Server Management Studio (SSMS) สามารถใช้เพื่อดูและจัดการพาร์ติชันที่สร้างขึ้นโดยโปรแกรมประยุกต์ของนโยบายการรีเฟรชแบบเพิ่มหน่วย ตัวอย่างเช่น เมื่อใช้ SSMS คุณสามารถรีเฟรชพาร์ติชันในอดีตที่เฉพาะเจาะจงที่ไม่ได้อยู่ในช่วงการรีเฟรชแบบเพิ่มหน่วยเพื่อทําการอัปเดตย้อนหลังโดยไม่ต้องรีเฟรชข้อมูลในอดีตทั้งหมด นอกจากนี้ยังสามารถใช้ SSMS เมื่อบูตสแตรปเพื่อโหลดข้อมูลในอดีตสําหรับโมเดลขนาดใหญ่โดยการเพิ่ม/รีเฟรชพาร์ติชันในอดีตทีละน้อยเป็นชุด
แทนที่พฤติกรรมการรีเฟรชแบบเพิ่มหน่วย
ด้วย SSMS คุณยังสามารถควบคุมวิธีการเรียกใช้การรีเฟรชได้มากขึ้นโดยใช้ภาษาการเขียนสคริปต์แบบจําลองตารางและแบบจําลองวัตถุตาราง ตัวอย่างเช่น ใน SSMS ใน Object Explorer ให้คลิกขวาที่ตาราง แล้วเลือกตัวเลือกเมนู Process Table แล้วเลือกปุ่ม Script เพื่อสร้างคําสั่งรีเฟรช TMSL
พารามิเตอร์เหล่านี้สามารถใช้กับคําสั่งรีเฟรช TMSL เพื่อแทนที่พฤติกรรมการรีเฟรชแบบเพิ่มหน่วยเริ่มต้น:
applyRefreshPolicy ถ้าตารางมีการกําหนด
applyRefreshPolicyนโยบายการรีเฟรชแบบเพิ่มหน่วย ให้กําหนดว่ามีการใช้นโยบายหรือไม่ ถ้าไม่มีการใช้นโยบาย การดําเนินการแบบเต็มกระบวนการจะปล่อยให้ข้อกําหนดพาร์ติชันไม่เปลี่ยนแปลง และพาร์ติชันทั้งหมดในตารางจะถูกรีเฟรชอย่างสมบูรณ์ ค่าเริ่มต้นคือ จริงeffectiveDate. หากมีการใช้นโยบายการรีเฟรชแบบเพิ่มหน่วย จําเป็นต้องทราบวันที่ปัจจุบันเพื่อกําหนดช่วงกรอบเวลาแบบหมุนเวียนสําหรับการรีเฟรชแบบเพิ่มหน่วยและรอบระยะเวลาในอดีต พารามิเตอร์ช่วยให้คุณสามารถ
effectiveDateแทนที่วันที่ปัจจุบันได้ พารามิเตอร์นี้มีประโยชน์สําหรับการทดสอบ การสาธิต และสถานการณ์ทางธุรกิจที่ข้อมูลถูกรีเฟรชทีละน้อยจนถึงวันที่ในอดีตหรืออนาคต เช่น งบประมาณในอนาคต ค่าเริ่มต้นคือวันที่ปัจจุบัน
{
"refresh": {
"type": "full",
"applyRefreshPolicy": true,
"effectiveDate": "12/31/2013",
"objects": [
{
"database": "IR_AdventureWorks",
"table": "FactInternetSales"
}
]
}
}
เมื่อต้องการเรียนรู้เพิ่มเติมเกี่ยวกับการแทนที่พฤติกรรมการรีเฟรชแบบเพิ่มหน่วยเริ่มต้นด้วย TMSL โปรดดู คําสั่งรีเฟรช
การจัดการนโยบายด้วยตัวแก้ไขตาราง
นอกจาก SSMS แล้ว คุณสามารถใช้ ตัวแก้ไขตาราง เพื่อสร้างและแก้ไขนโยบายการรีเฟรชแบบเพิ่มหน่วยได้โดยตรงกับโมเดลความหมายผ่านตําแหน่งข้อมูล XMLA วิธีนี้ช่วยให้คุณสามารถปรับการตั้งค่านโยบาย เช่น รอบระยะเวลาการรีเฟรช รอบระยะเวลาในอดีต และนิพจน์แหล่งที่มา โดยไม่จําเป็นต้องเผยแพร่แบบจําลองจาก Power BI Desktop อีกครั้ง ตัวแก้ไขตารางยังสามารถใช้เพื่อใช้นโยบายการรีเฟรชกับตารางที่มีอยู่ และจัดการ RangeStart และ RangeEnd นิพจน์พารามิเตอร์ สําหรับข้อมูลเพิ่มเติม โปรดดู การ รีเฟรชแบบเพิ่มหน่วย ในเอกสารประกอบตัวแก้ไขตาราง
รีเฟรชการประสานงานและระบบอัตโนมัติ
นอกเหนือจากการใช้ SSMS, TMSL และ TOM เพื่อจัดการการรีเฟรชผ่านตําแหน่งข้อมูล XMLA คุณยังสามารถประสานการดําเนินการรีเฟรชแบบจําลองความหมายโดยใช้ Power BI REST API API การรีเฟรชที่ปรับปรุงแล้วให้ความสามารถเพิ่มเติม รวมถึงการรีเฟรชระดับตารางและระดับพาร์ติชัน ตรรกะการลองใหม่ การยกเลิก และการจัดการการหมดเวลาแบบกําหนดเอง วิธีการนี้มีประโยชน์สําหรับการรวมการดําเนินการรีเฟรชเข้ากับเวิร์กโฟลว์อัตโนมัติและไปป์ไลน์ CI/CD สําหรับคําแนะนําโดยละเอียด โปรดดู การรีเฟรชขั้นสูงด้วย Power BI REST API
มั่นใจได้ถึงประสิทธิภาพสูงสุด
บริการของ Power BI อาจส่งคิวรีการเริ่มต้นไปยังแหล่งข้อมูลสําหรับแต่ละพาร์ติชันการรีเฟรชแบบเพิ่มหน่วย คุณอาจสามารถปรับปรุงประสิทธิภาพการรีเฟรชแบบเพิ่มหน่วยได้โดยการลดจํานวนคิวรีการเริ่มต้นโดยการตรวจสอบการตั้งค่าคอนฟิกต่อไปนี้:
- ตารางที่คุณกําหนดค่าการรีเฟรชแบบเพิ่มหน่วยควรได้รับข้อมูลจากแหล่งข้อมูลเดียว ถ้าตารางได้รับข้อมูลจากแหล่งข้อมูลมากกว่าหนึ่งแหล่งข้อมูล จํานวนคิวรีที่ส่งโดยบริการสําหรับการดําเนินการรีเฟรชแต่ละครั้งจะถูกคูณด้วยจํานวนแหล่งข้อมูล ซึ่งอาจลดประสิทธิภาพการรีเฟรช ตรวจสอบให้แน่ใจว่าคิวรีสําหรับตารางการรีเฟรชแบบเพิ่มหน่วยมีไว้สําหรับแหล่งข้อมูลเดียว
- สําหรับโซลูชันที่มีทั้งการรีเฟรชพาร์ติชันนําเข้าแบบเพิ่มหน่วยและข้อมูลแบบเรียลไทม์ด้วย Direct Query พาร์ติชันทั้งหมด ต้องคิวรีข้อมูลจากแหล่งข้อมูลเดียว
- หากข้อกําหนดด้านความปลอดภัยของคุณอนุญาต ให้ตั้งค่าระดับความเป็นส่วนตัวของแหล่งข้อมูลเป็น องค์กร หรือ สาธารณะ โดยค่าเริ่มต้น ระดับความเป็นส่วนตัวจะเป็น ส่วนตัว อย่างไรก็ตาม ระดับนี้สามารถป้องกันไม่ให้มีการแลกเปลี่ยนข้อมูลกับแหล่งคลาวด์อื่นๆ เมื่อต้องการตั้งค่าระดับความเป็นส่วนตัว ให้เลือกเมนู ตัวเลือกเพิ่มเติม แล้วเลือก การตั้งค่า>ข้อมูลประจําตัว>ของแหล่งข้อมูลแก้ไขข้อมูลประจํา>ตัวการตั้งค่าระดับความเป็นส่วนตัวสําหรับแหล่งข้อมูลนี้ ถ้ามีการตั้งค่าระดับความเป็นส่วนตัวในแบบจําลอง Power BI Desktop ก่อนที่จะเผยแพร่ไปยังบริการ จะไม่ถูกถ่ายโอนไปยังบริการเมื่อคุณเผยแพร่ คุณยังคงต้องตั้งค่าในการตั้งค่าแบบจําลองความหมายในบริการ เมื่อต้องการเรียนรู้เพิ่มเติม ให้ดูที่ ระดับความเป็นส่วนตัว
- หากใช้เกตเวย์ข้อมูลภายในองค์กร ให้แน่ใจว่าคุณกําลังใช้เวอร์ชัน 3000.77.3 หรือสูงกว่า
ป้องกันการหมดเวลาในการรีเฟรชเต็มรูปแบบครั้งแรก
หลังจากที่คุณเผยแพร่ไปยังบริการของ Power BI การดําเนินการรีเฟรชแบบเต็มเริ่มต้นสําหรับแบบจําลองจะสร้างพาร์ติชันสําหรับตารางการรีเฟรชแบบเพิ่มหน่วย โหลด และประมวลผลข้อมูลในอดีตสําหรับรอบระยะเวลาทั้งหมดที่กําหนดไว้ในนโยบายการรีเฟรชแบบเพิ่มหน่วย สําหรับบางรุ่นที่โหลดและประมวลผลข้อมูลจํานวนมาก ระยะเวลาที่การดําเนินการรีเฟรชเริ่มต้นใช้อาจเกินขีดจํากัดเวลาการรีเฟรชที่กําหนดโดยบริการหรือขีดจํากัดเวลาคิวรีที่กําหนดโดยแหล่งข้อมูล
การบูตสแตรปการดําเนินการรีเฟรชเริ่มต้นช่วยให้บริการสามารถสร้างออบเจ็กต์พาร์ติชันสําหรับตารางการรีเฟรชแบบเพิ่มหน่วย แต่ไม่โหลดและประมวลผลข้อมูลในอดีตลงในพาร์ติชันใดๆ จากนั้น SSMS จะถูกใช้เพื่อเลือกการประมวลผลพาร์ติชัน ขึ้นอยู่กับจํานวนข้อมูลที่จะโหลดสําหรับแต่ละพาร์ติชันคุณสามารถประมวลผลแต่ละพาร์ติชันตามลําดับหรือเป็นชุดเล็ก ๆ วิธีนี้ช่วยลดศักยภาพของพาร์ติชันเหล่านั้นอย่างน้อยหนึ่งพาร์ติชันที่จะทําให้เกิดการหมดเวลา วิธีการต่อไปนี้ใช้ได้กับแหล่งข้อมูลใดๆ
ใช้นโยบายการรีเฟรช
เครื่องมือ Tabular Editor 2 แบบโอเพ่นซอร์สเป็นวิธีง่ายๆ ในการบูตสแตรปการดําเนินการรีเฟรชเริ่มต้น หลังจากเผยแพร่แบบจําลองที่มีนโยบายการรีเฟรชแบบเพิ่มหน่วยที่กําหนดไว้สําหรับ Power BI Desktop ไปยังบริการ ให้เชื่อมต่อกับแบบจําลองโดยใช้จุดสิ้นสุด XMLA ในโหมดอ่าน/เขียน เรียกใช้ใช้ นโยบายการรีเฟรช บนตารางการรีเฟรชแบบเพิ่มหน่วย เมื่อใช้เฉพาะนโยบายพาร์ติชันจะถูกสร้างขึ้น แต่ไม่มีการโหลดข้อมูลลงไป จากนั้นเชื่อมต่อกับ SSMS เพื่อรีเฟรชพาร์ติชันตามลําดับหรือเป็นชุดเพื่อโหลดและประมวลผลข้อมูล สําหรับข้อมูลเพิ่มเติม โปรดดู การ รีเฟรชแบบเพิ่มหน่วย ในเอกสารประกอบตัวแก้ไขตาราง
ตัวกรอง Power Query สําหรับพาร์ติชันว่าง
ก่อนที่จะเผยแพร่แบบจําลองไปยังบริการ ในตัวแก้ไข Power Query ให้เพิ่มตัวกรองอื่นลงในProductKeyคอลัมน์ที่กรองค่าอื่นที่ไม่ใช่ 0 อย่างมีประสิทธิภาพ หรือกรองข้อมูลทั้งหมดออกจากตาราง FactInternetSales
หลังจากเลือก ปิด & นําไปใช้ ในตัวแก้ไข Power Query กําหนดนโยบายการรีเฟรชแบบเพิ่มหน่วย และบันทึกแบบจําลอง แบบจําลองจะถูกเผยแพร่ไปยังบริการ จากบริการ การดําเนินการรีเฟรชเริ่มต้นจะทํางานบนแบบจําลอง พาร์ติชันสําหรับตาราง FactInternetSales ถูกสร้างขึ้นตามนโยบาย แต่ไม่มีการโหลดและประมวลผลข้อมูลเนื่องจากข้อมูลทั้งหมดถูกกรองออก
หลังจากการดําเนินการรีเฟรชเริ่มต้นเสร็จสมบูรณ์ กลับในตัวแก้ไข Power Query ตัวกรองอื่นใน ProductKey คอลัมน์จะถูกลบออก หลังจากเลือก ปิด & นําไปใช้ในตัวแก้ไข Power Query และบันทึกแบบจําลอง แบบจําลองจะไม่ถูกเผยแพร่อีกครั้ง ถ้ามีการเผยแพร่แบบจําลองอีกครั้ง จะเขียนทับการตั้งค่านโยบายการรีเฟรชแบบเพิ่มหน่วย และบังคับให้รีเฟรชแบบเต็มบนแบบจําลองเมื่อดําเนินการรีเฟรชในภายหลังจากบริการ ให้ดําเนินการปรับใช้ข้อมูลเมตาเท่านั้นโดยใช้ชุดเครื่องมือการจัดการวงจรชีวิตของแอปพลิเคชัน (ALM) ที่ลบตัวกรองบนProductKeyคอลัมน์ออกจากแบบจําลอง จากนั้นสามารถใช้ SSMS เพื่อเลือกประมวลผลพาร์ติชันได้ เมื่อพาร์ติชันทั้งหมดได้รับการประมวลผลอย่างสมบูรณ์ ซึ่งต้องมีการคํานวณกระบวนการใหม่ในพาร์ติชันทั้งหมดจาก SSMS การดําเนินการรีเฟรชที่ตามมาบนโมเดลจากบริการจะรีเฟรชเฉพาะพาร์ติชันการรีเฟรชแบบเพิ่มหน่วยเท่านั้น
เคล็ดลับ
อย่าลืมดูวิดีโอ บล็อก และอื่นๆ ที่จัดทําโดยชุมชนผู้เชี่ยวชาญ BI ของ Power BI
เมื่อต้องการเรียนรู้เพิ่มเติมเกี่ยวกับการประมวลผลตารางและพาร์ติชันจาก SSMS ให้ดูที่ ประมวลผลฐานข้อมูล ตาราง หรือพาร์ติชัน (Analysis Services) เมื่อต้องการเรียนรู้เพิ่มเติมเกี่ยวกับการประมวลผลแบบจําลอง ตาราง และพาร์ติชันโดยใช้ TMSL โปรดดู คําสั่งรีเฟรช (TMSL)
คิวรีแบบกําหนดเองสําหรับการตรวจหาการเปลี่ยนแปลงข้อมูล
สามารถใช้ TMSL และ TOM เพื่อแทนที่พฤติกรรมการเปลี่ยนแปลงข้อมูลที่ตรวจพบ วิธีนี้สามารถใช้เพื่อหลีกเลี่ยงการคงคอลัมน์การปรับปรุงล่าสุดในแคชในหน่วยความจํา นอกจากนี้ยังสามารถเปิดใช้งานสถานการณ์ที่การตั้งค่าคอนฟิกหรือตารางคําสั่งถูกเตรียมโดยกระบวนการแยก แปลง และโหลด (ETL) อนุญาตให้คุณตั้งค่าสถานะเฉพาะพาร์ติชันที่ต้องรีเฟรช วิธีนี้สามารถสร้างกระบวนการรีเฟรชแบบเพิ่มหน่วยที่มีประสิทธิภาพมากขึ้น ซึ่งจะรีเฟรชเฉพาะช่วงเวลาที่ต้องการ
มี pollingExpression จุดประสงค์เพื่อเป็นนิพจน์ M ที่มีน้ําหนักเบาหรือชื่อของคิวรี M อื่น ต้องส่งคืนค่าสเกลาร์และดําเนินการสําหรับแต่ละพาร์ติชัน ถ้าค่าที่ส่งคืนแตกต่างจากครั้งล่าสุดที่มีการรีเฟรชแบบเพิ่มหน่วย พาร์ติชันจะถูกตั้งค่าสถานะสําหรับการประมวลผลแบบเต็ม
ตัวอย่างต่อไปนี้ครอบคลุมทั้งหมด 120 เดือนในรอบระยะเวลาที่ผ่านมาสําหรับการเปลี่ยนแปลงที่ลงวันที่ย้อนหลัง การระบุ 120 เดือนแทนที่จะเป็น 10 ปีหมายความว่าการบีบอัดข้อมูลอาจไม่มีประสิทธิภาพเท่า อย่างไรก็ตาม จะหลีกเลี่ยงการรีเฟรชทั้งปีในอดีต ซึ่งจะมีราคาแพงกว่าเมื่อหนึ่งเดือนเพียงพอสําหรับการเปลี่ยนแปลงย้อนหลัง
"refreshPolicy": {
"policyType": "basic",
"rollingWindowGranularity": "month",
"rollingWindowPeriods": 120,
"incrementalGranularity": "month",
"incrementalPeriods": 120,
"pollingExpression": "<M expression or name of custom polling query>",
"sourceExpression": [
"let ..."
]
}
เคล็ดลับ
อย่าลืมดูวิดีโอ บล็อก และอื่นๆ ที่จัดทําโดยชุมชนผู้เชี่ยวชาญ BI ของ Power BI
การปรับใช้ข้อมูลเมตาเท่านั้น
เมื่อคุณเผยแพร่ไฟล์ .pbix เวอร์ชันใหม่จาก Power BI Desktop ไปยังพื้นที่ทํางาน คุณจะเห็นพร้อมท์ต่อไปนี้เพื่อแทนที่แบบจําลองที่มีอยู่
ในบางกรณี คุณอาจไม่ต้องการแทนที่แบบจําลอง โดยเฉพาะอย่างยิ่งกับการรีเฟรชแบบเพิ่มหน่วย แบบจําลองใน Power BI Desktop อาจมีขนาดเล็กกว่าแบบจําลองในบริการของ Power BI มาก ถ้าแบบจําลองในบริการของ Power BI มีการใช้นโยบายการรีเฟรชแบบเพิ่มหน่วย คุณอาจสูญเสียข้อมูลในอดีตหลายปีหากมีการแทนที่แบบจําลอง การรีเฟรชข้อมูลในอดีตทั้งหมดอาจใช้เวลาหลายชั่วโมงและส่งผลให้ระบบหยุดทํางานสําหรับผู้ใช้
แต่เป็นการดีกว่าที่จะทําการปรับใช้ข้อมูลเมตาเท่านั้น ซึ่งช่วยให้สามารถปรับใช้วัตถุใหม่ได้โดยไม่สูญเสียข้อมูลในอดีต ตัวอย่างเช่น หากคุณเพิ่มหน่วยวัดเพียงไม่กี่รายการ คุณสามารถปรับใช้เฉพาะหน่วยวัดใหม่โดยไม่จําเป็นต้องรีเฟรชข้อมูล ซึ่งช่วยประหยัดเวลา
สําหรับพื้นที่ทํางานที่กําหนดให้กับความจุแบบพรีเมียมที่กําหนดค่าสําหรับการอ่าน/เขียนตําแหน่งข้อมูล XMLA เครื่องมือที่เข้ากันได้จะเปิดใช้งานการปรับใช้ข้อมูลเมตาเท่านั้น ตัวอย่างเช่น ชุดเครื่องมือ ALM เป็นเครื่องมือ Schema diff สําหรับแบบจําลอง Power BI และสามารถใช้เพื่อดําเนินการปรับใช้ข้อมูลเมตาเท่านั้น
ดาวน์โหลดและติดตั้ง ALM Toolkit เวอร์ชันล่าสุดจากที่เก็บ Git ของ Analysis Services คําแนะนําทีละขั้นตอนเกี่ยวกับการใช้ ALM Toolkit ไม่รวมอยู่ในเอกสารประกอบของ Microsoft ลิงก์เอกสารประกอบ ALM Toolkit และข้อมูลเกี่ยวกับความสามารถในการสนับสนุนมีอยู่ใน Ribbon วิธีใช้ เมื่อต้องการดําเนินการปรับใช้ข้อมูลเมตาเท่านั้น ให้ทําการเปรียบเทียบและเลือกอินสแตนซ์ Power BI Desktop ที่ทํางานอยู่เป็นแหล่งข้อมูล และแบบจําลองที่มีอยู่ในบริการของ Power BI เป็นเป้าหมาย พิจารณาความแตกต่างที่แสดงและข้ามการอัปเดตตารางด้วยพาร์ติชันการรีเฟรชแบบเพิ่มหน่วย หรือใช้กล่องโต้ตอบ ตัวเลือก เพื่อเก็บพาร์ติชันสําหรับการอัปเดตตาราง ตรวจสอบการเลือกเพื่อให้แน่ใจว่าโมเดลเป้าหมายมีความสมบูรณ์ แล้วอัปเดต
การเพิ่มนโยบายการรีเฟรชแบบเพิ่มหน่วยและข้อมูลแบบเรียลไทม์โดยทางโปรแกรม
คุณยังสามารถใช้ TMSL และ TOM เพื่อเพิ่มนโยบายการรีเฟรชแบบเพิ่มหน่วยให้กับแบบจําลองที่มีอยู่ผ่านจุดสิ้นสุด XMLA
Note
เพื่อหลีกเลี่ยงปัญหาความเข้ากันได้ ให้ตรวจสอบให้แน่ใจว่าคุณใช้ไลบรารีไคลเอ็นต์ Analysis Services เวอร์ชันล่าสุด ตัวอย่างเช่น เมื่อต้องการทํางานกับนโยบายไฮบริด เวอร์ชันต้องเป็น 19.27.1.8 หรือสูงกว่า
กระบวนการประกอบด้วยขั้นตอนต่อไปนี้:
ตรวจสอบให้แน่ใจว่ารุ่นเป้าหมายมีระดับความเข้ากันได้ขั้นต่ําที่กําหนด ใน SSMS ให้คลิกขวาที่ [ชื่อรุ่น]>ระดับความเข้ากันได้ของ> เมื่อต้องการเพิ่มระดับความเข้ากันได้ ให้ใช้สคริปต์ createOrReplace TMSL หรือตรวจสอบโค้ดตัวอย่าง TOM ต่อไปนี้สําหรับตัวอย่าง
a. Import policy - 1550 b. Hybrid policy - 1565เพิ่มพารามิเตอร์
RangeStartและRangeEndลงในนิพจน์แบบจําลอง หากจําเป็น ให้เพิ่มฟังก์ชันเพื่อแปลงค่าวันที่/เวลาเป็นปุ่มวันที่กําหนด
RefreshPolicyออบเจ็กต์ที่มีการเก็บถาวรที่ต้องการ (หน้าต่างกลิ้ง) และระยะเวลาการรีเฟรชแบบเพิ่มหน่วย ตลอดจนนิพจน์แหล่งที่มาที่กรองตารางเป้าหมายตามRangeStartพารามิเตอร์ และRangeEndตั้งค่าโหมดนโยบายการรีเฟรชเป็น นําเข้า หรือ ไฮบริด ขึ้นอยู่กับความต้องการข้อมูลแบบเรียลไทม์ของคุณ ไฮบริดทําให้ Power BI เพิ่มพาร์ติชัน DirectQuery ลงในตารางเพื่อดึงข้อมูลการเปลี่ยนแปลงล่าสุดจากแหล่งข้อมูลที่เกิดขึ้นหลังจากเวลารีเฟรชล่าสุดเพิ่มนโยบายการรีเฟรชลงในตารางและทําการรีเฟรชแบบเต็มเพื่อให้ Power BI แบ่งพาร์ติชันตารางตามความต้องการของคุณ
ตัวอย่างโค้ดต่อไปนี้สาธิตวิธีการทําตามขั้นตอนก่อนหน้านี้โดยใช้ TOM ถ้าคุณต้องการใช้ตัวอย่างนี้ตามที่เป็นอยู่ คุณต้องมีสําเนาสําหรับฐานข้อมูล AdventureWorksDW และนําเข้าตาราง FactInternetSales ลงในแบบจําลอง ตัวอย่างโค้ดถือว่าRangeStartพารามิเตอร์ RangeEnd และ และDateKeyฟังก์ชันไม่มีอยู่ในแบบจําลอง เพียงนําเข้าตาราง FactInternetSales และเผยแพร่แบบจําลองไปยังพื้นที่ทํางานบน Power BI Premium จากนั้นอัปเดตเพื่อให้ workspaceUrl ตัวอย่างโค้ดสามารถเชื่อมต่อกับโมเดลของคุณได้ อัปเดตบรรทัดโค้ดเพิ่มเติมตามความจําเป็น
using System;
using TOM = Microsoft.AnalysisServices.Tabular;
namespace Hybrid_Tables
{
class Program
{
static string workspaceUrl = "<Enter your Workspace URL here>";
static string databaseName = "AdventureWorks";
static string tableName = "FactInternetSales";
static void Main(string[] args)
{
using (var server = new TOM.Server())
{
// Connect to the dataset.
server.Connect(workspaceUrl);
TOM.Database database = server.Databases.FindByName(databaseName);
if (database == null)
{
throw new ApplicationException("Database cannot be found!");
}
if(database.CompatibilityLevel < 1565)
{
database.CompatibilityLevel = 1565;
database.Update();
}
TOM.Model model = database.Model;
// Add RangeStart, RangeEnd, and DateKey function.
model.Expressions.Add(new TOM.NamedExpression {
Name = "RangeStart",
Kind = TOM.ExpressionKind.M,
Expression = "#datetime(2021, 12, 30, 0, 0, 0) meta [IsParameterQuery=true, Type=\"DateTime\", IsParameterQueryRequired=true]"
});
model.Expressions.Add(new TOM.NamedExpression
{
Name = "RangeEnd",
Kind = TOM.ExpressionKind.M,
Expression = "#datetime(2021, 12, 31, 0, 0, 0) meta [IsParameterQuery=true, Type=\"DateTime\", IsParameterQueryRequired=true]"
});
model.Expressions.Add(new TOM.NamedExpression
{
Name = "DateKey",
Kind = TOM.ExpressionKind.M,
Expression =
"let\n" +
" Source = (x as datetime) => Date.Year(x)*10000 + Date.Month(x)*100 + Date.Day(x)\n" +
"in\n" +
" Source"
});
// Apply a RefreshPolicy with Real-Time to the target table.
TOM.Table salesTable = model.Tables[tableName];
TOM.RefreshPolicy hybridPolicy = new TOM.BasicRefreshPolicy
{
Mode = TOM.RefreshPolicyMode.Hybrid,
IncrementalPeriodsOffset = -1,
RollingWindowPeriods = 1,
RollingWindowGranularity = TOM.RefreshGranularityType.Year,
IncrementalPeriods = 1,
IncrementalGranularity = TOM.RefreshGranularityType.Day,
SourceExpression =
"let\n" +
" Source = Sql.Database(\"demopm.database.windows.net\", \"AdventureWorksDW\"),\n" +
" dbo_FactInternetSales = Source{[Schema=\"dbo\",Item=\"FactInternetSales\"]}[Data],\n" +
" #\"Filtered Rows\" = Table.SelectRows(dbo_FactInternetSales, each [OrderDateKey] >= DateKey(RangeStart) and [OrderDateKey] < DateKey(RangeEnd))\n" +
"in\n" +
" #\"Filtered Rows\""
};
salesTable.RefreshPolicy = hybridPolicy;
model.RequestRefresh(TOM.RefreshType.Full);
model.SaveChanges();
}
Console.WriteLine("{0}{1}", Environment.NewLine, "Press [Enter] to exit...");
Console.ReadLine();
}
}
}