การรีเฟรชแบบเพิ่มหน่วยขั้นสูงด้วยจุดสิ้นสุด XMLA

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

พาร์ ติ ชัน

พาร์ติชันตารางชุดข้อมูลจะไม่สามารถมองเห็นได้ และไม่สามารถจัดการในบริการได้ คุณสามารถจัดการพาร์ติชันผ่านจุดสิ้นสุด XMLA ได้โดยใช้เครื่องมือ เช่น Premium SQL Server Management Studio (SSMS) ตัวแก้ไขตารางแบบโอเพนซอร์ส สคริปต์ด้วย Tabular Model Scripting Language (TMSL) และโดยทางโปรแกรมด้วย Tabular Object Model (TOM)

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

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

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

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

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

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

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

ชุดข้อมูลจะเก็บพาร์ติชันไว้ตลอดช่วงร้านค้าในอดีต บวกกับพาร์ติชันตลอดระยะเวลาการรีเฟรชปัจจุบัน โดยใช้ตัวอย่างของเราข้างต้น ข้อมูลในอดีตทั้งสามปีจะถูกเก็บไว้ในพาร์ติชันในปี 2018, 2019, 2020 และพาร์ติชันหรับช่วง 2021Q101 เดือน, รอบระยะเวลา 2021Q10201 วัน และพาร์ติชันของช่วงเวลาการรีเฟรชวันปัจจุบัน เนื่องจากเราเลือกที่จะรักษาข้อมูลในอดีตเป็นเวลา สาม ปี พาร์ติชันของปี 2018 จะถูกเก็บไว้จนกว่าการรีเฟรชครั้งแรกในวันที่ 1 มกราคม 2022

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

การจัดการการรีเฟรชด้วย SQL Server Management Studio (SSMS)

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

แทนที่การทำงานการรีเฟรชแบบเพิ่มหน่วย

ด้วย SSMS คุณยังสามารถควบคุมวิธีการเรียกการรีเฟรชได้โดยใช้Tabular Model Scripting Language (TMSL)และTabular Object Model (TOM) ตัวอย่างเช่น ใน SSMS ในตัวค้นหาวัตถุ ให้คลิกขวาที่ตารางแล้วเลือกตัวเลือกเมนู ตารางกระบวนการและจากนั้นคลิกปุ่ม สคริปต์ เพื่อสร้างสั่งรีเฟรชTMSL

พารามิเตอร์เหล่านี้สามารถใช้กับสั่งรีเฟรช TMSL เพื่อแทนที่การรีเฟรชแบบเพิ่มหน่วยตามค่าเริ่มต้น:

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

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

{ 
  "refresh": {
    "type": "full",

    "applyRefreshPolicy": true,
    "effectiveDate": "12/31/2013",

    "objects": [
      {
        "database": "IR_AdventureWorks", 
        "table": "FactInternetSales" 
      }
    ]
  }
}

หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับการแทนที่การรีเฟรชแบบเพิ่มหน่วยตามค่าเริ่มต้นด้วย TMSL ดูที่ คำสั่งรีเฟรช

ตรวจสอบให้แน่ใจว่ามีประสิทธิภาพสูงสุด

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

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

ป้องกันไม่ให้หมดเวลาในการรีเฟรชทั้งหมดเริ่มต้น

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

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

ใช้นโยบายการรีเฟรช

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

Power Queryตัวกรอง for empty partitions

ก่อนที่จะเผยแพร่รูปแบบไปยังบริการ ใน ตัวแก้ไข Power Query ให้เพิ่มตัวกรองอื่นลงในคอลัมน์ ProductKey ที่กรองค่าใด ๆ นอกเหนือจาก 0 มีประสิทธิภาพ หรือกรองข้อมูลทั้งหมดจากตาราง FactInternetSales

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

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

หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับการประมวลผลตารางและพาร์ติชันจาก 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 ..."
    ]
}

การปรับใช้เมตาดาต้าเท่านั้น

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

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

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

สวนงานที่จะกําหนดPremiumความจุแบบกําหนดค่าไว้ใช้กับเครื่องมืออ่าน-เขียน XMLA ที่สามารถเข้ากันได้เปิดใช้งานการปรับใช้เฉพาะเมตาดาต้าเท่านั้น ตัวอย่างเช่น ALM Toolkit เป็นเครื่องมือ diff แบบ schema สำหรับชุดข้อมูล Power BI และสามารถใช้เพื่อดำเนินการปรับใช้เมตาดาต้าเท่านั้น

ดาวน์โหลดและติดตั้ง ALM Toolkit รุ่นล่าสุดจาก Analysis Services Git repo การแนะนําทีละขั้นตอนเกี่ยวกับการใช้ ALM Toolkit ไม่ได้รวมอยู่ในเอกสาร Microsoft ลิงก์และข้อมูลของเอกสาร ALM Toolkit มีให้ที่ริบบิ้น ช่วยเหลือ หากต้องการดำเนินการปรับใช้เมตาดาต้าเท่านั้น ให้ทำการเปรียบเทียบและเลือกอินสแตนซ์ Power BI Desktop ที่กำลังทำงานเป็นแหล่งข้อมูล และชุดข้อมูลที่มีอยู่ในบริการเป็นเป้าหมาย พิจารณาความแตกต่างที่แสดงและข้ามการอัปเดตของตารางด้วยพาร์ติชันรีเฟรชแบบเพิ่มหน่วยหรือใช้กล่องโต้ตอบตัวเลือกเพื่อเก็บพาร์ติชันให้อัปเดตตาราง ตรวจสอบการเลือกเพื่อให้แน่ใจว่ามีความสมบูรณ์ของโมเดลเป้าหมายจากนั้นจึงอัปเดต

อาจดูได้จาก

พาร์ติชันในรูปแบบตาราง
เครื่องมือภายนอกเพื่อ Power BI
กำหนดค่าการรีเฟรชตามกำหนดเวลา
แก้ไขปัญหาการรีเฟรชแบบเพิ่มหน่วย