การรวมที่ผู้ใช้กําหนดเอง

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

การสร้างตารางการรวม

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

แหล่งข้อมูลแบบมิติ เช่น คลังข้อมูลและดาต้ามาร์ท สามารถใช้ การรวมอิงตามความสัมพันธ์ได้ แหล่งข้อมูลขนาดใหญ่ที่ใช้ Hadoop มัก มาจากฐานการรวมข้อมูลบนคอลัมน์ GroupBy บทความนี้จะอธิบายเกี่ยวกับความแตกต่างของการสร้างแบบจําลองข้อมูล Power BI ทั่วไปสําหรับแต่ละชนิดของแหล่งข้อมูล

จัดการการรวม

ในบานหน้าต่าง ข้อมูล ของมุมมอง Power BI Desktop ให้คลิกขวาที่ตารางการรวม จากนั้นจึงเลือก จัดการการรวม

กล่องโต้ตอบ Manage aggregation แสดงแถวของแต่ละคอลัมน์ในตาราง ซึ่งคุณสามารถระบุลักษณะการทํางานของการรวมข้อมูลได้ ในตัวอย่างต่อไปนี้ คิวรีไปยังตารางรายละเอียด Sales จะถูกเปลี่ยนเส้นทางภายในไปยังตารางการรวม Sales Agg

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

การตรวจสอบความถูกต้อง

กล่องโต้ตอบ Manage aggregation จะบังคับใช้การตรวจสอบความถูกต้อง:

• คอลัมน์รายละเอียดต้องมีข้อมูลประเภทเดียวกันกับคอลัมน์การรวม ยกเว้นฟังก์ชันการสรุปการนับแถวของตารางและการนับ การนับและการนับแถวในตารางจะพร้อมใช้งานสําหรับคอลัมน์การรวมจํานวนเต็มและไม่ต้องการประเภทข้อมูลที่ตรงกัน
• ไม่อนุญาตให้มีการรวมแบบสายโซ่ที่ครอบคลุมสามตารางขึ้นไป ตัวอย่างเช่น การรวมใน Table A ไม่สามารถอ้างอิงถึง Table B ที่มีการรวมที่อ้างอิงถึง Table C ได้
• ไม่อนุญาตสําหรับการรวมแบบซ้ํา ที่สองรายการใช้ฟังก์ชันการสรุปเดียวกันและอ้างถึงตารางรายละเอียดและคอลัมน์รายละเอียดเดียวกัน
• ตารางรายละเอียดต้องใช้โหมดที่เก็บข้อมูล DirectQuery ไม่ใช่นําเข้า
• การจัดกลุ่มตามคอลัมน์ Foreign Key ที่ใช้โดยความสัมพันธ์ที่ไม่ได้ใช้งานและการใช้ฟังก์ชัน USERELATIONSHIP สําหรับการรวมผู้เยี่ยมชมไม่ได้รับการสนับสนุน
• การรวมที่อิงตามคอลัมน์ GroupBy สามารถใช้ความสัมพันธ์ระหว่างตารางการรวมได้ แต่ไม่สนับสนุนการเขียนความสัมพันธ์ระหว่างตารางการรวมใน Power BI Desktop หากจําเป็น คุณสามารถสร้างความสัมพันธ์ระหว่างตารางการรวมได้โดยใช้เครื่องมือของบุคคลที่สามหรือโซลูชันการเขียนสคริปต์ผ่าน XML สําหรับจุดสิ้นสุดการวิเคราะห์ (XMLA)

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

ตารางการรวมถูกซ่อนไว้

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

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

โหมดที่เก็บข้อมูล

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

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

หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับโหมดที่เก็บข้อมูลของตาราง โปรดดู จัดการโหมดที่เก็บข้อมูลใน Power BI Desktop

RLS สําหรับการรวม

เพื่อให้การรวมทํางานได้อย่างถูกต้อง RLS ควรกรองตารางการรวมและตารางรายละเอียด

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

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

นิพจน์ RLS ที่กรองเฉพาะตารางการรวม Sales Agg และไม่อนุญาตตารางรายละเอียด Sales

สําหรับ การรวมที่อิงตามคอลัมน์ GroupBy นิพจน์ RLS ที่นําไปใช้กับตารางรายละเอียดสามารถใช้เพื่อกรองตารางการรวมได้ เนื่องจากตารางรายละเอียดครอบคลุมคอลัมน์ GroupBy ทั้งหมดในตารางการรวม ในทางกลับกัน ตัวกรอง RLS บนตารางการรวมไม่สามารถนําไปใช้กับตารางรายละเอียด ดังนั้นจึงไม่ได้รับอนุญาต

การรวมอิงตามความสัมพันธ์

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

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

ให้สร้าง ตารางการรวม Sales Agg แทน ในตาราง Sales Agg จํานวนแถวจะเท่ากับผลรวมของ SalesAmount ที่จัดกลุ่มตาม CustomerKey, DateKey และ ProductSubcategoryKey ตาราง Sales Agg อยู่ในระดับความละเอียดสูงกว่ายอดขาย ดังนั้นแทนที่จะเป็นพันล้าน ตารางอาจมีแถวนับล้านแถวซึ่งจัดการได้ง่ายกว่า

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

• ภูมิศาสตร์
• ลูกค้า
• วันที่
• ประเภทย่อยของผลิตภัณฑ์
• หมวดหมู่สินค้า

รูปภาพต่อไปนี้แสดงแบบจําลองนี้

ตารางต่อไปนี้แสดงการรวมสําหรับตาราง Sales Agg

หมายเหตุ

ตาราง Sales Agg เช่นเดียวกับตารางใด ๆ มีความยืดหยุ่นในการโหลดด้วยวิธีการต่างๆ การรวมสามารถทําได้ในฐานข้อมูลต้นทางโดยใช้กระบวนการ ETL/ELT หรือโดย นิพจน์ M สําหรับตาราง ตารางรวมสามารถใช้โหมดพื้นที่เก็บข้อมูลการนําเข้าที่มีหรือไม่มี การรีเฟรชแบบเพิ่มหน่วยสําหรับแบบจําลองความหมายหรือสามารถใช้ DirectQuery และปรับให้เหมาะสมสําหรับการคิวรีอย่างรวดเร็วโดยใช้ ดัชนี columnstore ความยืดหยุ่นนี้จะช่วยให้สถาปัตยกรรมที่สมดุลสามารถกระจายโหลดคิวรี่เพื่อหลีกเลี่ยงปัญหาคอขวดได้

การเปลี่ยนโหมดที่เก็บข้อมูลของ ตาราง Sales Agg รวมไป เป็น นําเข้า จะเปิดกล่องโต้ตอบที่บอกว่าตารางมิติที่เกี่ยวข้องสามารถตั้งค่าเป็นโหมด พื้นที่เก็บข้อมูล Dual ได้

การตั้งค่าตารางมิติข้อมูลที่เกี่ยวข้องให้เป็น Dual ช่วยให้สามารถทําหน้าที่เป็นการนําเข้าหรือ DirectQuery ขึ้นอยู่กับคิวรี่ย่อย ในตัวอย่าง:

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

สําหรับข้อมูลเพิ่มเติมเกี่ยวกับโหมดที่เก็บข้อมูล Dual โปรดดู จัดการโหมดที่เก็บข้อมูลใน Power BI Desktop

ความสัมพันธ์แบบปกติเทียบกับแบบจํากัด

การรวมที่ตามความสัมพันธ์จําเป็นต้องมีความสัมพันธ์แบบปกติ

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

ตารางที่ด้าน กลุ่ม	ตารางบนด้าน 1
คู่	คู่
นำเข้า	นําเข้าหรือคู่
DirectQuery	DirectQuery หรือ คู่

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

สําหรับ การรวมแบบข้ามแหล่งข้อมูล ที่ไม่อิงตามความสัมพันธ์ โปรดดู การรวมที่อิงตามคอลัมน์ GroupBy

ตัวอย่างคิวรีการรวมอิงตามความสัมพันธ์

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

คิวรี่ต่อไปนี้จะไม่เกิดการรวม แม้จะร้องขอยอดรวมของ SalesAmount แต่คิวรีก็ดําเนินการ GroupBy บนคอลัมน์ในตาราง Product ซึ่งไม่มีความละเอียดที่สามารถรวบรวมได้ ถ้าคุณสังเกตความสัมพันธ์ในแบบจําลอง หมวดหมู่ย่อยของผลิตภัณฑ์สามารถมีแถวของ ผลิตภัณฑ์ ได้หลายแถว คิวรีจะไม่สามารถระบุได้ว่าจะรวมผลิตภัณฑ์ใด ในกรณีนี้ คิวรี่จะแปลงกลับเป็น DirectQuery และส่งคิวรี SQL ไปยังแหล่งข้อมูล

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

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

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

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

ฟังก์ชันตัวแสดงเวลา Data Analysis Expressions (DAX) เป็นการตระหนักรู้การรวม คิวรี่ต่อไปนี้จะทําให้เกิดการรวมเนื่องจากฟังก์ชัน DATESYTD สร้างตารางของค่า CalendarDay และตารางการรวมอยู่ในระดับการปิดกั้นที่ครอบคลุมสําหรับคอลัมน์ group-by ในตาราง Date นี่คือตัวอย่างของตัวกรองค่าตารางไปยังฟังก์ชัน CALCULATE ซึ่งสามารถทํางานกับการรวมได้

การรวมที่อิงตามคอลัมน์ GroupBy

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

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

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

คุณกําหนดการแมปการรวมสําหรับตาราง Driver Activity Agg ในกล่องโต้ตอบ Manage aggregation

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

ตารางต่อไปนี้จะแสดงการรวมตาราง Driver Activity Agg

คุณสามารถตั้งค่าโหมดที่เก็บข้อมูลของ ตาราง Driver Activity Agg รวมไปเป็นนําเข้าได้

ตัวอย่างคิวรีการรวม GroupBy

คิวรี่ต่อไปนี้จะเกิดการรวมข้อมูล เนื่องจาก ตารางการรวมครอบคลุมคอลัมน์ Activity Date (วัน กิจกรรม) ฟังก์ชัน COUNTROWS ใช้การรวมแถวของตารางที่นับ

โดยเฉพาะอย่างยิ่งสําหรับแบบจําลองที่มีแอตทริบิวต์ตัวกรองในตารางข้อเท็จจริง ควรใช้ การรวมแบบ Count table rows (การนับแถว ในตาราง) Power BI สามารถส่งคิวรีไปยังรูปแบบโดยใช้ COUNTROWS ในกรณีที่ผู้ใช้ไม่ได้ร้องขออย่างชัดแจ้ง ตัวอย่างเช่น กล่องโต้ตอบตัวกรองแสดงจํานวนแถวสําหรับแต่ละค่า

เทคนิคการรวมที่รวมกัน

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

ตัวอย่างเช่น แบบจําลองต่อไปนี้จะทําซ้ํา Month, Quarter, Semester และ Year ในตาราง Sales Agg ไม่มีความสัมพันธ์ระหว่างตาราง Sales Agg และ Date แต่มีความสัมพันธ์กับ Customer และ Product Subcategory โหมดพื้นที่เก็บข้อมูลของ Sales Agg คือ Import

ตารางต่อไปนี้แสดงรายการที่ตั้งค่าไว้ในกล่องโต้ตอบ Manage aggregations สําหรับตาราง Sales Agg รายการ GroupBy ที่ Date เป็นตารางรายละเอียดมีผลบังคับใช้บังคับให้เกิดการรวมสําหรับคิวรีที่จัดกลุ่มตามแอตทริบิวต์ Date เช่นเดียวกับในตัวอย่าง ก่อนหน้า รายการ GroupBy สําหรับ CustomerKey และ ProductSubcategoryKey ไม่ส่งผลกระทบต่อการทําให้เกิดการรวม ยกเว้น DISTINCTCOUNT เนื่องจากการมีอยู่ของความสัมพันธ์

ตัวอย่างคิวรีการรวมที่รวมกัน

คิวรี่ต่อไปนี้จะทําให้เกิดการรวมเนื่องจากตารางการรวมครอบคลุม CalendarMonth และ CategoryName สามารถเข้าถึงได้ผ่านความสัมพันธ์แบบหนึ่งต่อกลุ่ม SalesAmount ใช้การรวมข้อมูลแบบ SUM

คิวรี่ต่อไปนี้จะไม่เกิดการรวมเนื่องจากตารางการรวมไม่ครอบคลุม CalendarDay

คิวรี่เวลาอัจฉริยะต่อไปนี้จะไม่เกิดการรวมเนื่องจากฟังก์ชัน DATESYTD สร้างตารางค่า CalendarDay และตารางการรวมไม่ครอบคลุม CalendarDay

ลําดับความสําคัญของการรวม

ลําดับความสําคัญของการรวมช่วยให้สามารถพิจารณาตารางการรวมหลายรายการโดยใช้คิวรี่ย่อยรายการเดียว

ตัวอย่างต่อไปนี้เป็น โมเดล แบบรวมที่ประกอบด้วยแหล่งข้อมูลหลายแหล่ง:

• ตาราง Driver Activity DirectQuery ประกอบด้วยข้อมูล IoT มากกว่าพันล้านแถวที่มาจากระบบข้อมูลขนาดใหญ่ ซึ่งทําหน้าที่ในการคิวรี่แบบเจาะลึกเพื่อดูการอ่าน IoT แต่ละรายการในบริบทตัวกรองที่มีการควบคุม
• ตาราง Driver Activity Agg เป็นตารางรวมระดับกลางในโหมด DirectQuery มีแถวมากกว่าหนึ่งพันล้านแถวใน Azure Synapse Analytics (ชื่อเดิมคือ SQL Data Warehouse) และได้รับการปรับให้เหมาะสมที่แหล่งที่มาโดยใช้ดัชนี columnstore
• ตารางนําเข้า Driver Activity Agg2 มีความละเอียดสูงเนื่องจากแอตทริบิวต์ group-by มีจํานวนคาร์ดินอลลิตี้ (Cardinality) น้อยและต่ํา จํานวนแถวอาจต่ําถึงหนึ่งพันดังนั้นจึงสามารถใส่ลงในแคชในหน่วยความจําได้อย่างง่ายดาย แอตทริบิวต์เหล่านี้จะถูกใช้โดยแดชบอร์ดของผู้บริหารที่มีตําแหน่งสูง ดังนั้นคิวรี่ที่อ้างถึงแอตทริบิวต์ดังกล่าวควรเกิดขึ้นโดยเร็วที่สุด

หมายเหตุ

ตารางการรวม DirectQuery ที่ใช้แหล่งข้อมูลที่แตกต่างจากตารางรายละเอียดได้รับการสนับสนุนเฉพาะเมื่อตารางการรวมมาจาก SQL Server, Azure SQL หรือแหล่งที่มา Azure Synapse Analytics (ชื่อเดิมคือ SQL Data Warehouse)

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

กล่องโต้ตอบ Managed aggregation สําหรับ Driver Activity Agg2 ตั้งค่าเขตข้อมูล Precedence เป็น 10 ซึ่งสูงกว่าสําหรับ Driver Activity Agg การตั้งค่าความสําคัญสูงกว่าหมายถึงคิวรีที่ใช้การรวมพิจารณา Driver Activity Agg2 ก่อน ซึ่งสามารถตอบคิวรีย่อยที่ไม่ระดับแยกย่อยได้โดย Driver Activity Agg2 สามารถพิจารณา Driver Activity Agg แทนได้ คิวรี่รายละเอียดที่ไม่สามารถตอบได้จากตารางรวมใด ตารางหนึ่งสามารถตรงไปยัง Driver Activity

ตารางที่ระบุใน คอลัมน์ ตาราง รายละเอียด คือ Driver Activity ไม่ใช่ Driver Activity Agg เนื่องจากไม่ได้รับอนุญาตให้ใช้การรวมแบบสายโซ่

ตารางต่อไปนี้จะแสดงการรวมตาราง Driver Activity Agg2

ตรวจสอบว่าคิวรีที่ทําให้เกิดหรือไม่ทําให้เกิดการรวมข้อมูล

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

นอกจากนี้ SQL Profiler ยังมี Query Processing\Aggregate Table Rewrite Query เหตุการณ์ที่ขยายอีกด้วย

JSON snippet ต่อไปนี้แสดงตัวอย่างของผลลัพธ์ของเหตุการณ์เมื่อใช้การรวม

• matchingResult แสดงว่าคิวรี่ย่อยใช้การรวมข้อมูล
• dataRequest แสดงคอลัมน์ GroupBy และคอลัมน์รวมที่ใช้คิวรีย่อย
• การแมป แสดงคอลัมน์ในตารางการรวมที่ถูกแมปไป

เก็บแคชให้ตรงกัน

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

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

• การรวมไม่สนับสนุน พารามิเตอร์คิวรี M แบบไดนามิก

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

ชุมชน

Power BI มีชุมชนที่มีสีสันซึ่ง MVP, BI pros และเพื่อนร่วมงานแชร์ความเชี่ยวชาญในกลุ่มการอภิปราย วิดีโอ บล็อก และอื่นๆ เมื่อเรียนรู้เกี่ยวกับการรวม โปรดตรวจสอบแหล่งข้อมูลเพิ่มเติมเหล่านี้:

• ชุมชน Power BI
• ค้นหา "การรวม Power BI" บน Bing

เนื้อหาที่เกี่ยวข้อง

• การรวมอัตโนมัติ
• โมเดลแบบรวม