แชร์ผ่าน


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

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

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

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

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

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

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

สกรีนช็อตของการเลือกจัดการการรวม

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

สกรีนช็อตแสดงกล่องโต้ตอบจัดการการรวม

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

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

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

  • คอลัมน์รายละเอียดต้องมีชนิดข้อมูลเดียวกันกับคอลัมน์การรวม ยกเว้นฟังก์ชันการสรุปแถวตาราง Count และ Count แถวตาราง Count และ Count จะพร้อมใช้งานสําหรับคอลัมน์การรวมจํานวนเต็มเท่านั้น และไม่ต้องการชนิดข้อมูลที่ตรงกัน
  • ไม่อนุญาตให้มีการรวมแบบสายโซ่ที่ครอบคลุมสามตารางขึ้นไป ตัวอย่างเช่น การรวมใน Table A ไม่สามารถอ้างอิงถึง Table B ที่มีการรวมที่อ้างอิงถึง Table C ได้
  • ไม่อนุญาตสําหรับการรวมแบบซ้ํา ที่สองรายการใช้ฟังก์ชัน การสรุป เดียวกันและอ้างถึง ตารางรายละเอียด และ คอลัมน์รายละเอียดเดียวกัน
  • ตารางรายละเอียดต้องใช้โหมดที่เก็บข้อมูล DirectQuery ไม่ใช่นําเข้า
  • การจัดกลุ่มตามคอลัมน์ Foreign Key ที่ใช้โดยความสัมพันธ์ที่ไม่ได้ใช้งานและการใช้ฟังก์ชัน USERELATIONSHIP สําหรับการรวมผู้เยี่ยมชมไม่ได้รับการสนับสนุน อีกทางเลือกหนึ่งคือ คุณสามารถใช้ฟังก์ชัน TREATAS แทน USERELATIONSHIP ได้ เมื่อใช้ TREATAS ตรวจสอบให้แน่ใจว่าไม่มีความสัมพันธ์ที่ใช้งานอยู่ระหว่างตาราง การรวมยังคงสามารถโจมตีได้เมื่อใช้ TREATAS กับการกําหนดค่านี้
  • การรวมที่อิงตามคอลัมน์ 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 สําหรับการรวมที่สําเร็จ

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

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

ไม่อนุญาต RLS บนตารางการรวมเท่านั้น

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

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

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

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

ตารางรายละเอียดในแบบจําลอง

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

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

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

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

ตารางการรวมในแบบจําลอง

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

การรวมสําหรับตาราง Sales Agg

หมายเหตุ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

คิวรีที่ไม่สามารถใช้การรวมได้

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

คิวรีการรวมที่ซับซ้อน

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

คิวรีการรวม COUNTROWS

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

คิวรีการรวม AVERAGE

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

คิวรีการรวม DISTINCTCOUNT

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

คิวรีการรวม SUMMARIZECOLUMNS

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

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

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

ตาราง IoT

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

ตาราง Driver Activity Agg

กําหนดการแม็ปการรวมสําหรับตาราง Driver Activity Agg ในกล่องโต้ตอบ จัดการการรวม

กล่องโต้ตอบ Manage aggregation สําหรับตาราง Driver Activity Agg

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

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

ตารางการรวม Driver Activity Agg

ตั้งค่าโหมดการจัดเก็บของตาราง Driver Activity Agg แบบรวมเป็น นําเข้า

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

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

คิวรีการรวม GroupBy ที่สําเร็จ

โดยเฉพาะอย่างยิ่งสําหรับแบบจําลองที่มีแอตทริบิวต์ตัวกรองในตารางข้อเท็จจริง ควรใช้การรวม แบบ 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 เนื่องจากมีความสัมพันธ์

รายการสําหรับตารางการรวม Sales Agg

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

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

ตัวอย่างคิวรีที่ทําให้เกิดการรวม

แบบสอบถามต่อไปนี้ไม่ใช้การรวม เนื่องจากตารางการรวมไม่ครอบคลุม CalendarDay

สกรีนช็อตแสดงข้อความของคิวรีที่มี CalendarDay

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

สกรีนช็อตแสดงข้อความของคิวรีที่มีฟังก์ชัน DATESYTD

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

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

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

  • ตาราง 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 ก่อน คิวรีย่อยที่ไม่ได้อยู่ในความละเอียดที่ กิจกรรมผู้ขับขี่ Agg2 สามารถตอบได้สามารถพิจารณา Driver Activity Agg แทนได้ คิวรี่รายละเอียดที่ไม่สามารถตอบได้จากตารางรวมใด ตารางหนึ่งสามารถตรงไปยัง Driver Activity

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

สกรีนช็อตแสดงกล่องโต้ตอบจัดการการรวมที่มีลําดับความสําคัญที่ถูกเรียกออกมา

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

ตารางการรวม Driver Activity Agg2

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

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

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

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

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

ผลลัพธ์ของเหตุการณ์เมื่อใช้การรวม

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

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

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

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

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

ชุมชน

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