การวางแผนการใช้งาน Power BI: การตรวจสอบระดับข้อมูล

หมายเหตุ

บทความนี้เป็นส่วนหนึ่งของ ชุดการวางแผน การใช้งาน Power BI ของบทความ ชุดข้อมูลนี้เน้นไปที่ประสบการณ์การใช้งาน Power BI ภายใน Microsoft Fabric เป็นหลัก สําหรับบทนําสู่ชุดข้อมูล โปรดดู ที่ การวางแผนการใช้งาน Power BI

บทความการตรวจสอบระดับข้อมูลนี้มีการกําหนดเป้าหมายไปยังผู้ชมหลายคน:

• ผู้สร้างข้อมูลและผู้ดูแลระบบพื้นที่ทํางาน: ผู้ใช้ที่ต้องการทําความเข้าใจการใช้งาน การปรับใช้ และประสิทธิภาพของแบบจําลองความหมาย กระแสข้อมูล และแผนผังข้อมูลที่พวกเขาสร้าง เผยแพร่ และแชร์
• ผู้ดูแลระบบ Power BI: ผู้ดูแลระบบที่มีหน้าที่ดูแล Power BI ในองค์กร ผู้ดูแลระบบ Power BI อาจต้องทํางานร่วมกับฝ่าย IT ความปลอดภัย การตรวจสอบภายใน และทีมอื่นๆ ที่เกี่ยวข้อง ผู้ดูแลระบบ Power BI อาจจําเป็นต้องทํางานร่วมกับผู้สร้างเนื้อหาเมื่อแก้ไขปัญหาประสิทธิภาพการทํางาน
• ผู้ดูแลระบบความจุ Power BI: ผู้ดูแลระบบที่รับผิดชอบการตรวจสอบความจุแบบพรีเมียมในองค์กร ผู้ดูแลระบบความจุ Power BI อาจจําเป็นต้องทํางานร่วมกับผู้สร้างเนื้อหาเมื่อแก้ไขปัญหาประสิทธิภาพการทํางาน
• ศูนย์แห่งความเป็นเลิศ ทีมไอที และ BI: ทีมที่รับผิดชอบในการตรวจสอบ Power BI พวกเขาอาจจําเป็นต้องทํางานร่วมกับผู้ดูแลระบบ Power BI และทีมอื่น ๆ ที่เกี่ยวข้อง
• ผู้ดูแลระบบ: ทีมที่มีหน้าที่รับผิดชอบในการสร้างและรักษาความปลอดภัย ทรัพยากร Azure Log Analytics และผู้ดูแลระบบฐานข้อมูลที่จัดการแหล่งข้อมูล

สำคัญ

ในบางครั้งที่บทความนี้อ้างอิงถึง Power BI Premium หรือการสมัครใช้งานความจุ (P SKU) โปรดทราบว่าในขณะนี้ Microsoft กําลังรวมตัวเลือกการซื้อและหยุดใช้งาน Power BI Premium ต่อความจุ SKU ลูกค้าใหม่และลูกค้าที่มีอยู่ควรพิจารณาซื้อการสมัครใช้งานความจุ Fabric (F SKU) แทน

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

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

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

เนื่องจากแบบจําลองความหมายของ Power BI ถูกสร้างขึ้นจากกลไกจัดการตาราง Analysis Services คุณสามารถเชื่อมต่อกับแบบจําลองข้อมูลภายในเครื่อง (ใน Power BI Desktop) หรือแบบจําลองความหมายแบบพรีเมียม (ในบริการของ Power BI) ราวกับว่าเป็นฐานข้อมูล Analysis Services ดังนั้น การตรวจสอบและการตรวจสอบความสามารถของ Analysis Services จํานวนมากจึงได้รับการสนับสนุนสําหรับแบบจําลองความหมายของ Power BI Premium

หมายเหตุ

สําหรับข้อมูลเพิ่มเติมเกี่ยวกับแบบจําลองที่โฮสต์ใน Analysis Services ดู ภาพรวมการตรวจสอบ

ส่วนที่เหลือของบทความนี้จะมุ่งเน้นไปที่แบบจําลองที่เผยแพร่ไปยังบริการของ Power BI เป็นหลัก

บันทึกเหตุการณ์แบบจําลองเชิงความหมาย

เมื่อเวลาผ่านไป ผู้สร้างข้อมูลและเจ้าของข้อมูลอาจประสบกับสถานการณ์ด้วยแบบจําลองความหมายของพวกเขา แบบจําลองความหมายสามารถ:

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

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

หมายเหตุ

การเปลี่ยนชื่อชุดข้อมูลได้เผยแพร่ในบริการของ Power BI และในเอกสาร แม้ว่าอาจมีบางอินสแตนซ์ เช่น ชื่อการดําเนินการบันทึกเหตุการณ์ — ซึ่งยังไม่เกิดการเปลี่ยนแปลง

คุณควรวิเคราะห์เหตุการณ์การติดตามแบบจําลองความหมายเพื่อ:

• ตรวจสอบกิจกรรมทั้งหมดที่เกิดขึ้นในแบบจําลองความหมาย
• แก้ไขปัญหาและปรับประสิทธิภาพของแบบจําลองความหมาย การใช้หน่วยความจํา และประสิทธิภาพของคิวรีให้เหมาะสม
• ตรวจสอบรายละเอียดและระยะเวลาการรีเฟรชแบบจําลองความหมาย
• ตรวจสอบ ภาษา สูตร Power Query (คิวรี M) ที่ส่งโดย Power Query
• ตรวจสอบ สูตร DAX และนิพจน์ที่ ส่งไปยังแบบจําลองความหมาย (กลไก Analysis Services)
• ตรวจสอบว่าเลือกโหมดที่เก็บข้อมูลที่ถูกต้องตามปริมาณงานหรือไม่และความจําเป็นในความสมดุลของข้อมูลใหม่และประสิทธิภาพสูงสุด
• ตรวจสอบบทบาทความปลอดภัยระดับแถวที่จะเรียกใช้ สําหรับผู้ใช้และแบบจําลองความหมายใด
• ทําความเข้าใจจํานวนผู้ใช้พร้อมกัน
• ตรวจสอบความถูกต้องของแบบจําลองความหมาย (ตัวอย่างเช่น เพื่อตรวจสอบคุณภาพและประสิทธิภาพข้อมูลก่อนที่จะ รับรอง แบบจําลองความหมายหรือก่อนที่จะเผยแพร่ไปยังพื้นที่ทํางานการผลิต)

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

Azure Log Analytics

Azure Log Analytics เป็นคอมโพเนนต์ของบริการ Azure Monitor การรวม Azure Log Analytics กับ Power BI ช่วยให้คุณสามารถจับภาพเหตุการณ์แบบจําลองเชิงความหมายจากแบบจําลองความหมายทั้งหมดในพื้นที่ทํางานของ Power BI รองรับเฉพาะพื้นที่ทํางานแบบพรีเมียมเท่านั้น หลังจากที่คุณตั้งค่าการรวมและเปิดใช้งานการเชื่อมต่อแล้ว (สําหรับพื้นที่ทํางานของ Power BI Premium) เหตุการณ์แบบจําลองเชิงความหมายจะถูกบันทึกโดยอัตโนมัติและส่งไปยังพื้นที่ทํางาน Azure Log Analytics อย่างต่อเนื่อง ไฟล์บันทึกแบบจําลองเชิงความหมายจะถูกจัดเก็บไว้ใน Azure Data Explorer ซึ่งเป็นฐานข้อมูลแบบผนวกเท่านั้นที่ปรับให้เหมาะสมสําหรับการจับข้อมูลระยะไกลแบบเรียลไทม์และใกล้เคียงกัน

คุณกําหนดพื้นที่ทํางาน Power BI Premium ไปยังพื้นที่ทํางาน Log Analytics ใน Azure คุณต้องสร้างทรัพยากร Log Analytics ใหม่ในการสมัครใช้งาน Azure ของคุณเพื่อเปิดใช้งานการบันทึกประเภทนี้

บันทึกจากพื้นที่ทํางาน Power BI อย่างน้อยหนึ่งรายการจะถูกส่งไปยังพื้นที่ทํางาน Log Analytics เป้าหมาย ต่อไปนี้เป็นวิธีการบางอย่างที่คุณสามารถเลือกจัดระเบียบข้อมูล

• พื้นที่ทํางานเป้าหมายหนึ่งรายการสําหรับข้อมูลการตรวจสอบทั้งหมด: จัดเก็บข้อมูลทั้งหมดในพื้นที่ทํางาน Log Analytics เดียว ซึ่งจะเป็นประโยชน์เมื่อผู้ดูแลระบบหรือผู้ใช้เดียวกันจะเข้าถึงข้อมูลทั้งหมด
• พื้นที่ทํางานเป้าหมายที่จัดระเบียบตามพื้นที่หัวเรื่อง: จัดระเบียบเนื้อหาตามพื้นที่ชื่อเรื่อง เทคนิคนี้มีประโยชน์อย่างยิ่งเมื่อผู้ดูแลระบบหรือผู้ใช้ที่แตกต่างกันได้รับอนุญาตให้เข้าถึงข้อมูลการตรวจสอบจาก Azure Log Analytics ตัวอย่างเช่น เมื่อคุณจําเป็นต้องแยกข้อมูลยอดขายจากข้อมูลการดําเนินการ
• พื้นที่ทํางานเป้าหมายหนึ่งรายการสําหรับแต่ละพื้นที่ทํางาน Power BI: ตั้งค่าความสัมพันธ์แบบหนึ่งต่อหนึ่งระหว่างพื้นที่ทํางาน Power BI และพื้นที่ทํางาน Azure Log Analytics ซึ่งจะเป็นประโยชน์เมื่อคุณมีเนื้อหาที่ละเอียดอ่อนเป็นพิเศษหรือเมื่อข้อมูลต้องปฏิบัติตามข้อกําหนดเฉพาะหรือข้อกําหนดด้านการควบคุม

เคล็ดลับ

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

สำคัญ

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

สําหรับข้อมูลเพิ่มเติมเกี่ยวกับกิจกรรมของผู้ใช้ที่คุณสามารถตรวจสอบสําหรับผู้เช่า Power BI ของคุณ ดู การตรวจสอบระดับผู้เช่า

การเชื่อมต่อ Azure Log Analytics สําหรับผู้ดูแลระบบพื้นที่ทํางานการตั้งค่าผู้เช่าควบคุมว่ากลุ่มผู้ใช้ใด (ผู้ที่มีบทบาทเป็นผู้ดูแลระบบพื้นที่ทํางานที่จําเป็น) สามารถเชื่อมต่อพื้นที่ทํางาน Power BI ไปยังพื้นที่ทํางาน Azure Log Analytics ที่มีอยู่แล้วได้

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

เคล็ดลับ

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

บันทึกแบบจําลองเชิงความหมายที่รวบรวมโดย Azure Log Analytics ประกอบด้วยคิวรีแบบจําลองความหมาย สถิติคิวรี กิจกรรมการรีเฟรชโดยละเอียด เวลา CPU ที่ใช้บนความจุแบบพรีเมียม และอื่นๆ เนื่องจากเป็นไฟล์บันทึกระดับรายละเอียดจากกลไก Analysis Services ข้อมูลจึงอาจละเอียดขึ้นได้ ปริมาณข้อมูลขนาดใหญ่เป็นเรื่องปกติสําหรับพื้นที่ทํางานขนาดใหญ่ที่ประสบกับกิจกรรมแบบจําลองที่มีความหมายสูง

เมื่อต้องการปรับค่าใช้จ่ายให้เหมาะสมเมื่อใช้ Azure Log Analytics ด้วย Power BI:

• เชื่อมต่อพื้นที่ทํางาน Power BI กับ Azure Log Analytics เฉพาะเมื่อคุณกําลังแก้ไขปัญหา ทดสอบ ปรับให้เหมาะสม หรือตรวจสอบกิจกรรมแบบจําลองเชิงความหมาย เมื่อเชื่อมต่อแล้ว การติดตามจะทํางานในแบบจําลองความหมายทั้งหมดในพื้นที่ทํางาน
• ยกเลิกการเชื่อมต่อ Azure Log Analytics จากพื้นที่ทํางาน Power BI เมื่อคุณไม่จําเป็นต้องแก้ไขปัญหา ทดสอบ ปรับให้เหมาะสม หรือตรวจสอบกิจกรรมแบบจําลองเชิงความหมายอีกต่อไป ด้วยการยกเลิกการเชื่อมต่อ คุณกําลังยุติการติดตามจากการทํางานบนแบบจําลองความหมายทั้งหมดในพื้นที่ทํางาน
• ตรวจสอบให้แน่ใจว่าคุณเข้าใจ รูปแบบ ค่าใช้จ่ายว่า Azure Log Analytics เรียกเก็บเงินสําหรับการนําเข้าข้อมูล ที่เก็บข้อมูล และคิวรีอย่างไร
• อย่าจัดเก็บข้อมูลใน Log Analytics นานกว่าระยะเวลาการเก็บข้อมูล 30 วันตามค่าเริ่มต้น นั่นเป็นเพราะการวิเคราะห์แบบจําลองความหมายโดยทั่วไปจะมุ่งเน้นไปที่กิจกรรมการแก้ไขปัญหาทันที

มีหลายวิธีในการเข้าถึงเหตุการณ์ที่ถูกส่งไปยัง Azure Log Analytics คุณสามารถใช้:

• การวิเคราะห์บันทึกจัดทําสําเร็จสําหรับแอปเทมเพลตแบบจําลองความหมาย Power BI
• ตัวเชื่อมต่อ Power BI Desktop สําหรับ Azure Data Explorer (Kusto) ใช้ Kusto Query Language (KQL) เพื่อวิเคราะห์ข้อมูลที่ถูกเก็บไว้ใน Log Analytics ถ้าคุณมีประสบการณ์คิวรี SQL คุณจะพบความคล้ายคลึงกันมากกับ KQL
• ประสบการณ์ คิวรี บนเว็บใน Azure Data Explorer
• เครื่องมือคิวรีใด ๆ ที่สามารถเรียกใช้คิวรี KQL ได้

เคล็ดลับ

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

สําหรับข้อมูลเพิ่มเติม ดู การเชื่อมต่อควบคุม Azure

รายการตรวจสอบ - เมื่อวางแผนที่จะใช้ Azure Log Analytics การตัดสินใจและการดําเนินการที่สําคัญประกอบด้วย:

• พิจารณา POC ทางเทคนิค: วางแผนสําหรับโครงการขนาดเล็กเพื่อให้แน่ใจว่าคุณเข้าใจข้อกําหนดทางเทคนิคข้อกําหนดความปลอดภัยข้อกําหนดการรักษาความปลอดภัยที่จะจับภาพได้อย่างเต็มที่และวิธีวิเคราะห์บันทึก
• ตัดสินใจว่าพื้นที่ทํางานใดควรรวมเข้ากับ Log Analytics: กําหนดว่าพื้นที่ทํางานแบบพรีเมียมใดที่มีแบบจําลองความหมายที่คุณสนใจวิเคราะห์
• ตัดสินใจว่าควรเปิดใช้งาน Log Analytics แบบเต็มเวลาสําหรับพื้นที่ทํางานใด ๆ หรือไม่: สําหรับการปรับต้นทุนให้เหมาะสม ให้พิจารณาว่ามีสถานการณ์ (หรือพื้นที่ทํางานเฉพาะ) ที่ควรเปิดใช้งานการบันทึกอย่างถาวรหรือไม่ ตัดสินใจว่าควรยกเลิกการเชื่อมต่อพื้นที่ทํางานเมื่อแก้ไขปัญหาไม่เกิดขึ้นหรือไม่
• ตัดสินใจว่าจะเก็บรักษาข้อมูล Log Analytics นานเพียงใด: ตรวจสอบว่าจําเป็นต้องตั้งค่าระยะเวลาการเก็บรักษานานกว่าค่าเริ่มต้น 30 วันหรือไม่
• ชี้แจงกระบวนการร้องขอพื้นที่ทํางาน Log Analytics ใหม่: ทํางานร่วมกับผู้ดูแลระบบ Azure ของคุณเพื่อชี้แจงว่าควรส่งคําขอสําหรับทรัพยากร Log Analytics ใหม่โดยผู้ดูแลระบบพื้นที่ทํางาน Power BI อย่างไร
• ตัดสินใจว่าจะทํางานด้านความปลอดภัยอย่างไร: ทํางานร่วมกับผู้ดูแลระบบ Azure ของคุณเพื่อตัดสินใจว่าจะเป็นไปได้มากกว่าที่ผู้ดูแลระบบพื้นที่ทํางาน Power BI จะได้รับสิทธิ์ในพื้นที่ทํางาน Azure Log Analytics หรือเพื่อให้ผู้ดูแลระบบ Azure มีสิทธิ์ในพื้นที่ทํางาน Power BI เมื่อคุณทําการตัดสินใจด้านความปลอดภัยนี้ ให้พิจารณาแผนของคุณเพื่อเชื่อมต่อและยกเลิกการเชื่อมต่อพื้นที่ทํางานเป็นประจํา (สําหรับการปรับค่าใช้จ่ายให้เหมาะสม)
• ตัดสินใจว่าจะจัดระเบียบพื้นที่ทํางาน Log Analytics เป้าหมายอย่างไร: พิจารณาว่าพื้นที่ทํางาน Azure Log Analytics มีจํานวนกี่แห่งที่เหมาะสมในการจัดระเบียบข้อมูลจากพื้นที่ทํางาน Power BI อย่างน้อยหนึ่งรายการ จัดการตัดสินใจนี้ให้สอดคล้องกับการตัดสินใจด้านความปลอดภัยของคุณว่าใครสามารถเข้าถึงข้อมูลบันทึกได้
• ตัดสินใจว่าผู้ดูแลระบบพื้นที่ทํางานรายใดที่ได้รับอนุญาตให้เชื่อมต่อ: กําหนดกลุ่มของผู้ดูแลระบบพื้นที่ทํางานที่สามารถเชื่อมต่อพื้นที่ทํางาน Power BI ไปยังพื้นที่ทํางาน Log Analytics ได้ ตั้งค่าการเชื่อมต่อ Azure Log Analytics สําหรับผู้ดูแลระบบพื้นที่ทํางานการตั้งค่าผู้เช่าเพื่อให้สอดคล้องกับการตัดสินใจนี้
• สร้างทรัพยากร Azure Log Analytics: ทํางานร่วมกับผู้ดูแลระบบ Azure ของคุณเพื่อสร้างพื้นที่ทํางาน Log Analytics แต่ละรายการ ตรวจสอบและอัปเดตสิทธิ์ที่กําหนดไว้ใน Azure เพื่อให้แน่ใจว่าการกําหนดค่า Power BI สามารถเกิดขึ้นได้โดยไม่มีปัญหาใด ๆ ตรวจสอบว่าข้อมูลที่จัดเก็บไว้ใน Azure อยู่ในภูมิภาคทางภูมิศาสตร์ที่ถูกต้อง
• ตั้งค่าการเชื่อมต่อ Log Analytics สําหรับแต่ละพื้นที่ทํางานของ Power BI: ทํางานร่วมกับผู้ดูแลระบบพื้นที่ทํางาน Power BI ของคุณเพื่อตั้งค่าการเชื่อมต่อไปยัง Log Analytics สําหรับแต่ละพื้นที่ทํางานของ Power BI ตรวจสอบว่าข้อมูลบันทึกโฟลว์ไปยังพื้นที่ทํางาน Log Analytics อย่างถูกต้อง
• สร้างคิวรีเพื่อวิเคราะห์ข้อมูล: ตั้งค่าคิวรี KQL เพื่อวิเคราะห์ข้อมูลใน Log Analytics ตามกรณีการใช้งานและความต้องการปัจจุบันของคุณ
• รวมคําแนะนําสําหรับผู้ดูแลระบบพื้นที่ทํางาน Power BI: ให้ข้อมูลและข้อกําหนดเบื้องต้นแก่ผู้ดูแลระบบพื้นที่ทํางาน Power BI ของคุณสําหรับวิธีการร้องขอพื้นที่ทํางาน Log Analytics ใหม่และวิธีการเชื่อมต่อกับพื้นที่ทํางาน Power BI นอกจากนี้ยังอธิบายเมื่อเหมาะสมเพื่อยกเลิกการเชื่อมต่อพื้นที่ทํางาน Power BI
• ให้คําแนะนําและคิวรีตัวอย่างสําหรับการวิเคราะห์ข้อมูล: สร้างคิวรี KQL สําหรับผู้ดูแลระบบพื้นที่ทํางานเพื่อให้พวกเขาเริ่มต้นวิเคราะห์ข้อมูลที่รวบรวมไว้ได้ง่ายขึ้น
• ตรวจสอบค่าใช้จ่าย: ทํางานร่วมกับผู้ดูแลระบบ Azure เพื่อตรวจสอบค่าใช้จ่าย Log Analytics อย่างต่อเนื่อง

คุณลักษณะเซิร์ฟเวอร์ SQL

คุณสามารถใช้ SQL Server Profiler (ตัวสร้างโพรไฟล์ SQL) เพื่อจับภาพเหตุการณ์แบบจําลองเชิงความหมายของ Power BI ได้ ซึ่งเป็นคอมโพเนนต์ของ SQL Server Management Studio (SSMS) การเชื่อมต่อกับแบบจําลองความหมายของ Power BI ได้รับการสนับสนุนด้วย SSMS เนื่องจากเป็นไปตามสถาปัตยกรรม Analysis Services ที่มีต้นทางใน SQL Server

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

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

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

หมายเหตุ

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

พิจารณาใช้ SQL Profiler แทน Azure Log Analytics เมื่อ:

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

เช่นเดียวกับ Azure Log Analytics (อธิบายไว้ก่อนหน้าในบทความนี้) เหตุการณ์แบบจําลองเชิงความหมายที่รวบรวมโดย SQL Profiler ได้รับมาจากบันทึกการวินิจฉัยที่มีอยู่ซึ่งพร้อมใช้งานสําหรับ Azure Analysis Services อย่างไรก็ตาม มีความแตกต่างบางอย่างในเหตุการณ์ที่พร้อมใช้งาน

เคล็ดลับ

การใช้ตัวสร้างโพรไฟล์ SQL สําหรับการตรวจสอบ Analysis Services จะครอบคลุมในหลายหนังสือ บทความ และบล็อกโพสต์ ข้อมูลส่วนใหญ่นั้นเกี่ยวข้องกับการตรวจสอบแบบจําลองความหมายของ Power BI

สำคัญ

คุณยังสามารถใช้ตัวสร้างโพรไฟล์ของ SQL เพื่อตรวจสอบคิวรีที่ส่งจากบริการของ Power BI ไปยังแหล่งข้อมูลพื้นฐาน (ตัวอย่างเช่น ไปยังฐานข้อมูลเชิงสัมพันธ์ของ SQL Server) อย่างไรก็ตาม ไม่สนับสนุนความสามารถในการติดตามฐานข้อมูลเชิงสัมพันธ์ การเชื่อมต่อกับกลไกจัดการ Analysis Services ได้ รับการสนับสนุน และ ไม่ได้ รับการสนับสนุน ถ้าคุณคุ้นเคยกับ เหตุการณ์ที่ขยายของ Analysis Services และคุณต้องการใช้การเชื่อมต่อ จาก SSMS เป็นไปได้สําหรับแบบจําลองข้อมูลใน Power BI Desktop อย่างไรก็ตาม ไม่ได้รับการสนับสนุนสําหรับ Power BI Premium ดังนั้น ส่วนนี้จะมุ่งเน้นเฉพาะการเชื่อมต่อ SQL Profiler มาตรฐานเท่านั้น

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

หมายเหตุ

คุณยังสามารถใช้ SQL Profiler เพื่อช่วยในการแก้ไขจุดบกพร่องและแก้ไขปัญหานิพจน์ DAX เฉพาะได้ คุณสามารถเชื่อมต่อ SQL Profiler กับ Power BI Desktop ในฐานะ เครื่องมือภายนอกได้ ค้นหา คลาสของเหตุการณ์บันทึก การประเมิน DAX เพื่อดูผลลัพธ์ตัวกลางของนิพจน์ DAX เหตุการณ์ดังกล่าวจะถูกสร้างขึ้นเมื่อคุณใช้ ฟังก์ชัน EVALUATEANDLOG DAX ในการคํานวณแบบจําลอง

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

รายการตรวจสอบ - เมื่อวางแผนที่จะใช้ SQL Profiler การตัดสินใจที่สําคัญและการดําเนินการประกอบด้วย:

• ตัดสินใจว่าใครสามารถติดตั้ง SSMS หรือ DAX Studio ได้: พิจารณาว่าคุณจะอนุญาตให้ผู้สร้างเนื้อหา Power BI ทั้งหมดในองค์กรของคุณติดตั้ง SSMS และ/หรือ DAX Studio เพื่อให้พวกเขาสามารถใช้โปรไฟล์ SQL ได้หรือไม่ ตัดสินใจว่าเครื่องมือเสริมเหล่านี้ได้รับการติดตั้งตามคําขอหรือเป็นส่วนหนึ่งของชุดซอฟต์แวร์มาตรฐานที่ติดตั้งไว้สําหรับผู้สร้างข้อมูลที่ได้รับอนุมัติในองค์กรหรือไม่
• เพิ่ม SQL Profiler ไปยังเมนูเครื่องมือภายนอกใน Power BI Desktop: ถ้าผู้สร้างข้อมูลจะใช้ตัวสร้างข้อมูลบ่อยครั้ง ขอให้ IT เพิ่มไปยังเมนูเครื่องมือภายนอกใน Power BI Desktop สําหรับผู้ใช้เหล่านี้โดยอัตโนมัติ
• ตัดสินใจว่าใครสามารถใช้ตําแหน่งข้อมูล XMLA: พิจารณาว่าผู้ใช้ทั้งหมดได้รับอนุญาตให้เชื่อมต่อกับแบบจําลองความหมายที่เผยแพร่แล้วโดยใช้ตําแหน่งข้อมูล XMLA หรือจํากัดเฉพาะผู้สร้างข้อมูลที่ได้รับอนุมัติเท่านั้น ตั้งค่าการตั้งค่าผู้ เช่าอนุญาตตําแหน่งข้อมูล XMLA และวิเคราะห์ใน Excel ด้วยการตั้งค่าผู้เช่าแบบจําลอง ความหมายภายในองค์กรเพื่อให้สอดคล้องกับการตัดสินใจนี้
• ให้คําแนะนําและคิวรีตัวอย่างสําหรับการวิเคราะห์ข้อมูล: สร้างเอกสารประกอบสําหรับผู้สร้างข้อมูลของคุณ เพื่อให้พวกเขาเข้าใจวิธีที่แนะนําในการตรวจสอบและตรวจสอบแบบจําลองความหมาย ให้คําแนะนําสําหรับกรณีการใช้งานทั่วไปเพื่อทําให้ง่ายต่อการเริ่มต้นการรวบรวมและวิเคราะห์ข้อมูลการติดตาม

เมตาดาต้าแบบจําลองข้อมูล

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

มุมมองการจัดการแบบไดนามิก

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

โดยเฉพาะ คุณสามารถ:

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

เคล็ดลับ

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

SSMS เป็นเครื่องมือที่ใช้ทั่วไปในการเรียกใช้ คิวรี DMV คุณยังสามารถใช้ cmdlet ของ PowerShell Invoke-ASCmd เพื่อสร้างและดําเนินการ กับสคริปต์ XMLA ที่คิวรี DMV ได้

เครื่องมือ ของบุคคลที่สามและ เครื่องมือ ภายนอกก็ได้รับความนิยมจากชุมชน Power BI เช่นกัน เครื่องมือเหล่านี้ใช้ DMV ที่จัดทําเป็นเอกสารสาธารณะเพื่อลดความซับซ้อนในการเข้าถึงและทํางานกับข้อมูลที่ DMV ส่งกลับ ตัวอย่างหนึ่งคือ DAX Studio ซึ่งรวมถึงฟังก์ชันการทํางานที่ชัดเจนเพื่อเข้าถึง DMV DAX Studio ยังมีคุณลักษณะมุมมองเมตริกที่มีอยู่ภายใน ซึ่งโดยทั่วไปเรียกว่าตัววิเคราะห์ Vertipaq ตัววิเคราะห์ Vertipaq มีส่วนติดต่อผู้ใช้สําหรับการวิเคราะห์โครงสร้างและขนาดของตาราง คอลัมน์ ความสัมพันธ์ และพาร์ติชันในแบบจําลองข้อมูล คุณยังสามารถส่งออก (หรือนําเข้า) เมตาดาต้าแบบจําลองข้อมูลไปยังไฟล์ .vpax ได้ ไฟล์ที่ส่งออกประกอบด้วยเมตาดาต้าเกี่ยวกับโครงสร้างและขนาดของแบบจําลองข้อมูลเท่านั้น โดยไม่ต้องจัดเก็บข้อมูลแบบจําลองใด ๆ

เคล็ดลับ

พิจารณาการแชร์ไฟล์ .vpax กับบุคคลอื่นเมื่อคุณต้องการความช่วยเหลือเกี่ยวกับแบบจําลองข้อมูล ด้วยวิธีนี้ คุณจะไม่แชร์ข้อมูลแบบจําลองกับบุคคลดังกล่าว

คุณสามารถใช้คิวรี DMV ในระหว่างขั้นตอนต่างๆ ของวงจรชีวิตของแบบจําลองความหมาย

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

เคล็ดลับ

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

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

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

ตัววิเคราะห์แนวทางปฏิบัติที่ดีที่สุด

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

เคล็ดลับ

หากต้องการตั้งค่า BPA ให้ดาวน์โหลดชุดกฎแนวทางปฏิบัติที่ดีที่สุดซึ่งมีให้โดย Microsoft ใน GitHub

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

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

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

เคล็ดลับ

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

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

• ตัดสินใจว่าใครสามารถติดตั้ง SSMS ได้: ตรวจสอบว่าคุณจะอนุญาตให้ผู้สร้างเนื้อหา Power BI ทั้งหมดในองค์กรของคุณติดตั้ง SSMS เพื่อให้พวกเขาสามารถเชื่อมต่อกับแบบจําลองความหมายที่เผยแพร่แล้วได้หรือไม่ ตัดสินใจว่าจะติดตั้งตามคําขอหรือเป็นส่วนหนึ่งของชุดซอฟต์แวร์มาตรฐานที่ติดตั้งไว้สําหรับผู้สร้างข้อมูลที่ได้รับอนุมัติในองค์กร
• ตัดสินใจว่าใครสามารถติดตั้งเครื่องมือของบุคคลที่สามได้: พิจารณาว่าคุณจะอนุญาตให้ผู้สร้างเนื้อหา Power BI ทั้งหมดในองค์กรของคุณติดตั้งเครื่องมือของบุคคลที่สาม (เช่น DAX Studio และตัวแก้ไขตาราง) เพื่อให้พวกเขาสามารถตรวจสอบแบบจําลองข้อมูลภายในเครื่องและ/หรือเผยแพร่แบบจําลองความหมายได้ ตัดสินใจว่าจะติดตั้งตามคําขอหรือเป็นส่วนหนึ่งของชุดซอฟต์แวร์มาตรฐานที่ติดตั้งไว้สําหรับผู้สร้างข้อมูลที่ได้รับอนุมัติในองค์กร
• ตั้งค่ากฎแนวทางปฏิบัติที่ดีที่สุด: ตัดสินใจว่ากฎตัววิเคราะห์แนวทางปฏิบัติที่ดีที่สุดข้อใดที่สามารถสแกนแบบจําลองข้อมูลในองค์กรของคุณได้
• ตัดสินใจว่าใครสามารถใช้ตําแหน่งข้อมูล XMLA ได้: ตรวจสอบว่าผู้ใช้ทั้งหมดได้รับอนุญาตให้เชื่อมต่อกับแบบจําลองความหมายโดยใช้ตําแหน่งข้อมูล XMLA หรือจํากัดเฉพาะผู้สร้างข้อมูลที่ได้รับอนุมัติเท่านั้น ตั้งค่าการตั้งค่าผู้ เช่าอนุญาตตําแหน่งข้อมูล XMLA และวิเคราะห์ใน Excel ด้วยการตั้งค่าผู้เช่าแบบจําลอง ความหมายภายในองค์กรเพื่อให้สอดคล้องกับการตัดสินใจนี้
• ให้คําแนะนําสําหรับผู้สร้างเนื้อหา: สร้างเอกสารสําหรับผู้สร้างข้อมูลของคุณเพื่อให้พวกเขาเข้าใจวิธีที่แนะนําในการวิเคราะห์แบบจําลองเชิงความหมาย ให้คําแนะนําสําหรับกรณีการใช้งานทั่วไปเพื่อทําให้ง่ายต่อการเริ่มรวบรวมและวิเคราะห์ผลลัพธ์ DMV และ/หรือใช้ตัววิเคราะห์แนวทางปฏิบัติที่ดีที่สุด

แบบจําลองข้อมูลและประสิทธิภาพของคิวรี

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

ตัววิเคราะห์ประสิทธิภาพ

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

เคล็ดลับ

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

สําหรับข้อมูลเพิ่มเติมเกี่ยวกับตัววิเคราะห์ประสิทธิภาพ ให้ดู การตรวจสอบระดับรายงาน

การวินิจฉัยคิวรี

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

ข้อมูลที่คุณสามารถได้จากการวินิจฉัยคิวรีประกอบด้วย:

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

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

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

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

การประเมินผลคิวรีและการพับ

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

แอปเมตริกพรีเมียม

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

เคล็ดลับ

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

แอปเมตริกพรีเมียมประกอบด้วยแบบจําลองความหมายภายในและชุดรายงานเริ่มต้น ซึ่งช่วยให้คุณดําเนินการตรวจสอบความจุ Power BI Premium (P SKU) หรือ Power BI Embedded (A SKU) แบบใกล้เคียงกับเวลาจริง ซึ่งรวมถึงข้อมูลในช่วงสองถึงสี่สัปดาห์ที่ผ่านมา (ขึ้นอยู่กับเมตริก)

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

รายการตรวจสอบ - เมื่อพิจารณาวิธีการใช้สําหรับการตรวจสอบแบบจําลองข้อมูลและประสิทธิภาพของคิวรี การตัดสินใจและการดําเนินการที่สําคัญประกอบด้วย:

• ระบุเป้าหมายประสิทธิภาพการทํางานของคิวรีแบบจําลองเชิงความหมาย: ตรวจสอบให้แน่ใจว่าคุณมีความเข้าใจที่ดีเกี่ยวกับความหมายของประสิทธิภาพของแบบจําลองความหมายที่ดี กําหนดว่าเมื่อใดที่คุณจะต้องกําหนดเป้าหมายประสิทธิภาพการทํางานของคิวรีเฉพาะ (ตัวอย่างเช่น คิวรีเพื่อสนับสนุนรายงานต้องแสดงภายในห้าวินาที) ถ้าเป็นเช่นนั้น ตรวจสอบให้แน่ใจว่าเป้าหมายถูกสื่อสารกับผู้สร้างข้อมูลในองค์กรของคุณ
• ระบุเป้าหมายประสิทธิภาพการรีเฟรชแบบจําลองเชิงความหมาย: กําหนดว่าเมื่อใดที่คุณจะต้องใช้เป้าหมายการรีเฟรชข้อมูลที่เฉพาะเจาะจง (ตัวอย่างเช่น การดําเนินการรีเฟรชข้อมูลให้เสร็จสมบูรณ์ภายใน 15 นาทีและก่อนเวลา 5 โมง) ถ้าเป็นเช่นนั้น ตรวจสอบให้แน่ใจว่าเป้าหมายถูกสื่อสารกับผู้สร้างข้อมูลในองค์กรของคุณ
• ให้ความรู้แก่ทีมสนับสนุนของคุณ: ตรวจสอบให้แน่ใจว่าทีมสนับสนุนผู้ใช้ภายในของคุณคุ้นเคยกับความสามารถในการวิเคราะห์เพื่อให้พวกเขาพร้อมที่จะสนับสนุนผู้ใช้ Power BI เมื่อพวกเขาต้องการความช่วยเหลือ
• เชื่อมต่อทีมสนับสนุนและผู้ดูแลระบบฐานข้อมูลของคุณ: ตรวจสอบให้แน่ใจว่าทีมสนับสนุนของคุณทราบวิธีการติดต่อผู้ดูแลระบบที่ถูกต้องสําหรับแต่ละแหล่งข้อมูล (ตัวอย่างเช่น เมื่อแก้ไขปัญหาการพับคิวรี)
• ทํางานร่วมกับผู้ดูแลระบบความจุพรีเมียมของคุณ: ทํางานร่วมกับผู้ดูแลระบบความจุของคุณเพื่อแก้ไขปัญหาแบบจําลองความหมายที่อยู่ในพื้นที่ทํางานที่กําหนดให้กับความจุพรีเมียมหรือความจุ Power BI Embedded เมื่อเหมาะสม ให้ส่งคําขอการเข้าถึงแอปเมตริกพรีเมียม
• ให้คําแนะนําสําหรับผู้สร้างเนื้อหา: สร้างเอกสารประกอบสําหรับผู้สร้างข้อมูลของคุณเพื่อให้พวกเขาเข้าใจสิ่งที่ควรดําเนินการเมื่อแก้ไขปัญหา
• รวมไว้ในเอกสารการฝึกอบรม: ให้คําแนะนําแก่ผู้สร้างข้อมูลของคุณเกี่ยวกับวิธีการสร้างแบบจําลองข้อมูลที่มีประสิทธิภาพดี ช่วยให้พวกเขานําพฤติกรรมการออกแบบที่ดีมาใช้ในช่วงต้น มุ่งเน้นไปที่การสอนผู้สร้างข้อมูลถึงวิธีตัดสินใจด้านการออกแบบที่ดี

การตรวจสอบแหล่งข้อมูล

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

คุณสามารถตรวจสอบแหล่งข้อมูลเพื่อ:

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

มีหลายการดําเนินการที่ผู้สร้างเนื้อหา Power BI อาจดําเนินการเมื่อพวกเขาวิเคราะห์ผลลัพธ์การตรวจสอบ พวกเขาสามารถ:

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

ผู้ดูแลระบบอาจดําเนินการอื่น ๆ พวกเขาสามารถ:

• แนะนําเลเยอร์ข้อมูลกลาง เช่น กระแสข้อมูล Power BI (เมื่อคลังข้อมูลไม่ใช่ตัวเลือกที่ทํางานได้) ผู้สร้างเนื้อหา Power BI สามารถใช้กระแสข้อมูลเป็นแหล่งข้อมูลของพวกเขาแทนการเชื่อมต่อโดยตรงไปยังแหล่งข้อมูล ชั้นข้อมูลระหว่างกลางสามารถลดการโหลดในระบบต้นทางได้ นอกจากนี้ยังมีประโยชน์เพิ่มเติมของตรรกะการเตรียมข้อมูลแบบรวมศูนย์ สําหรับข้อมูลเพิ่มเติม โปรดดู สถานการณ์การใช้งานการเตรียม ข้อมูลแบบบริการตนเอง
• เปลี่ยนตําแหน่งที่ตั้งแหล่งข้อมูลเพื่อลดผลกระทบของเวลาแฝงบนเครือข่าย (ตัวอย่างเช่น ใช้ขอบเขตข้อมูลเดียวกันสําหรับบริการของ Power BI แหล่งข้อมูล และเกตเวย์)
• ปรับแหล่งข้อมูลให้เหมาะสมเพื่อให้ดึงข้อมูลสําหรับ Power BI ได้อย่างมีประสิทธิภาพมากขึ้น เทคนิคทั่วไปหลายวิธีรวมถึงการสร้างดัชนีตาราง การสร้างมุมมองที่มีการจัดทําดัชนี การสร้างคอลัมน์ที่มีการคํานวณแบบคงอยู่ การบํารุงรักษาสถิติ การใช้ตารางในหน่วยความจําหรือ columnstore และการสร้างมุมมองที่เป็นเนื้อความ
• กําหนดให้ผู้ใช้ใช้แบบจําลองแบบอ่านอย่างเดียวของแหล่งข้อมูล แทนที่จะเป็นฐานข้อมูลการผลิตต้นฉบับ แบบจําลองอาจพร้อมใช้งานเป็นส่วนหนึ่งของกลยุทธ์ฐานข้อมูลความพร้อมใช้งานสูง (HA) ประโยชน์ประการหนึ่งของแบบจําลองแบบอ่านอย่างเดียวคือการลดเนื้อหาในระบบต้นทาง

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

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

เคล็ดลับ

ผู้ดูแลระบบ Power BI สามารถรวบรวมคลังผู้เช่าทั้งหมด (ซึ่งรวมถึงสายข้อมูล) และเข้าถึงกิจกรรมของผู้ใช้ในบันทึกกิจกรรม ด้วยความสัมพันธ์ของกิจกรรมสายข้อมูลและผู้ใช้ ผู้ดูแลระบบสามารถระบุแหล่งข้อมูลและเกตเวย์ที่ใช้บ่อยที่สุดได้

สําหรับข้อมูลเพิ่มเติมเกี่ยวกับสินค้าคงคลังของผู้เช่าและบันทึกกิจกรรม ดู การตรวจสอบระดับผู้เช่า

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

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

การตรวจสอบการรีเฟรชข้อมูล

การดําเนินการรีเฟรชข้อมูลเกี่ยวข้องกับการนําเข้าข้อมูลจากแหล่งข้อมูลต้นแบบลงในแบบจําลองความหมาย กระแสข้อมูล หรือ Datamart ของ Power BI คุณสามารถกําหนดตารางเวลาการดําเนินการรีเฟรชข้อมูล หรือเรียกใช้ตามความต้องการ

ข้อตกลงระดับบริการ

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

ไฟล์บันทึกแบบจําลองเชิงความหมาย

ไฟล์บันทึกเหตุการณ์แบบจําลองเชิงความหมายจาก Azure Log Analytics หรือ SQL Profiler (อธิบายไว้ก่อนหน้านี้ในบทความนี้) ประกอบด้วยข้อมูลโดยละเอียดเกี่ยวกับสิ่งที่เกิดขึ้นในแบบจําลองเชิงความหมาย เหตุการณ์ที่จับภาพไว้มีกิจกรรมการรีเฟรชแบบจําลองความหมาย บันทึกเหตุการณ์จะเป็นประโยชน์โดยเฉพาะอย่างยิ่งเมื่อคุณต้องการแก้ไขปัญหาและตรวจสอบการรีเฟรชแบบจําลองเชิงความหมาย

แบบจําลองความหมายของความจุแบบพรีเมียม

เมื่อคุณมีเนื้อหาที่โฮสต์อยู่ในความจุ Power BI Premium คุณมีความสามารถในการตรวจสอบการดําเนินการรีเฟรชข้อมูลมากขึ้น

• หน้า สรุปการ รีเฟรชของ Power BI ในพอร์ทัลผู้ดูแลระบบมีข้อมูลสรุปของประวัติการรีเฟรช ข้อมูลสรุปนี้มีข้อมูลเกี่ยวกับระยะเวลาการรีเฟรชและข้อความแสดงข้อผิดพลาด
• แอปการใช้งานและเมตริก Power BI Premium ยังประกอบด้วยข้อมูลการรีเฟรชที่เป็นประโยชน์ ซึ่งมีประโยชน์เมื่อคุณต้องการตรวจสอบกิจกรรมการรีเฟรชสําหรับความจุ Power BI Premium (P SKU) หรือความจุ Power BI Embedded (A SKU)

การรีเฟรชแบบจําลองความหมายที่ปรับปรุงประสิทธิภาพแล้ว

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

การตรวจสอบกําหนดการรีเฟรชข้อมูล

ผู้ดูแลระบบ Power BI สามารถตรวจสอบกําหนดการรีเฟรชข้อมูลในผู้เช่าเพื่อดูว่ามีการดําเนินการรีเฟรชจํานวนมากที่กําหนดไว้พร้อมกันในระหว่างกรอบเวลาที่กําหนด (ตัวอย่างเช่น ระหว่างเวลา 5.00 น. ถึง 07.00 น. ซึ่งอาจเป็นเวลารีเฟรชข้อมูลที่ไม่ว่างเป็นพิเศษ) ผู้ดูแลระบบมีสิทธิ์ในการเข้าถึงเมตาดาต้ากําหนดการรีเฟรชแบบจําลองความหมายจากเมตาดาต้าที่สแกน API ซึ่งเรียกว่า API ของสแกนเนอร์

Power BI REST API

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

คุณสามารถเรียกใช้ประวัติการรีเฟรชข้อมูลได้โดยใช้:

• รับประวัติการรีเฟรชใน Group REST API เพื่อดึงข้อมูลการรีเฟรชสําหรับพื้นที่ทํางาน
• รับการรีเฟรชสําหรับความจุ REST API เพื่อดึงข้อมูลการรีเฟรชสําหรับความจุ

เคล็ดลับ

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

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

• กําหนดเป้าหมายเฉพาะ: เมื่อตรวจสอบการรีเฟรชข้อมูล รับความชัดเจนเกี่ยวกับสิ่งที่คุณต้องทําให้สําเร็จและขอบเขตการตรวจสอบที่ควรเป็น (ตัวอย่างเช่น แบบจําลองความหมายการผลิต แบบจําลองความหมายที่ได้รับการรับรอง และอื่น ๆ)
• พิจารณาการตั้งค่า SLA: พิจารณาว่า SLA จะเป็นประโยชน์ในการตั้งค่าความคาดหวังสําหรับความพร้อมใช้งานข้อมูลและเมื่อใดที่กําหนดเวลาการรีเฟรชข้อมูลควรทํางาน
• ทํางานร่วมกับผู้ดูแลระบบฐานข้อมูลและเกตเวย์: ทํางานกับฐานข้อมูลหรือผู้ดูแลระบบของคุณ และผู้ดูแลระบบเกตเวย์ เพื่อตรวจสอบหรือแก้ไขปัญหาการรีเฟรชข้อมูล
• การถ่ายโอนความรู้สําหรับทีมสนับสนุน: ตรวจสอบให้แน่ใจว่าทีมสนับสนุนของคุณทราบวิธีการช่วยเหลือผู้สร้างเนื้อหาเมื่อมีปัญหาการรีเฟรชข้อมูลเกิดขึ้น
• อัปเดตการฝึกอบรมและคําแนะนํา: รวมข้อมูลสําคัญและเคล็ดลับสําหรับผู้สร้างข้อมูลเกี่ยวกับวิธีการรีเฟรชข้อมูลจากแหล่งข้อมูลขององค์กรและแหล่งข้อมูลทั่วไป รวมแนวทางปฏิบัติที่ดีที่สุดและการกําหนดลักษณะองค์กรสําหรับวิธีการจัดการการรีเฟรชข้อมูล
• ใช้ที่อยู่อีเมลสนับสนุนสําหรับการแจ้งเตือน: สําหรับเนื้อหาที่สําคัญ ให้ตั้งค่าการแจ้งเตือนการรีเฟรชเพื่อใช้ที่อยู่อีเมลสนับสนุน
• ตั้งค่าการตรวจสอบการรีเฟรชแบบรวมศูนย์: ใช้ Power BI REST API เพื่อรวบรวมประวัติการรีเฟรชข้อมูล

การตรวจสอบกระแสข้อมูล

คุณสร้างกระแสข้อมูล Power BI ด้วย Power Query Online มีคุณลักษณะด้านประสิทธิภาพการทํางานของคิวรีจํานวนมากและการวินิจฉัย Power Query ซึ่งอธิบาย ไว้ก่อนหน้านี้สามารถใช้ได้

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

คุณสามารถใช้ Power BI REST API เพื่อตรวจสอบธุรกรรมของกระแสข้อมูลได้ ตัวอย่างเช่น ใช้ API รับธุรกรรม กระแสข้อมูลเพื่อตรวจสอบสถานะของการรีเฟรชกระแสข้อมูล

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

เคล็ดลับ

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

การตรวจสอบ Datamart

Datamart ของ Power BI มีคอมโพเนนต์แบบรวมมากมาย รวมถึงกระแสข้อมูล ฐานข้อมูลที่มีการจัดการ และแบบจําลองความหมาย ดูส่วนก่อนหน้าของบทความนี้เพื่อเรียนรู้เกี่ยวกับการตรวจสอบและการตรวจสอบของแต่ละคอมโพเนนต์

คุณสามารถติดตามกิจกรรมของผู้ใช้สําหรับ Datamarts ของ Power BI ได้โดยใช้บันทึกกิจกรรมของ Power BI สําหรับข้อมูลเพิ่มเติม ดู การตรวจสอบระดับผู้เช่า

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

ใน บทความถัดไปในชุดนี้ เรียนรู้เกี่ยวกับการตรวจสอบระดับผู้เช่า