แชร์ผ่าน


การแสดงภาพและการตีความการวินิจฉัยคิวรีใน Power BI

บทนำ

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

การมีความเข้าใจที่ดีว่าแต่ละคอลัมน์ในสคีมาการวินิจฉัยแบบสอบถามหมายถึงอะไร ซึ่งเราจะไม่ทําซ้ําในบทช่วยสอนสั้นๆ นี้ มีการ เขียนฉบับเต็มที่นี่

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

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

การสร้างการแสดงภาพ

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

สําหรับการแสดงภาพที่สอง ทางเลือกหนึ่งคือการใช้แผนภูมิคอลัมน์แบบเรียงซ้อน ในพารามิเตอร์ "แกน" คุณอาจต้องการใช้ "รหัส" หรือ "ขั้นตอน" หากเรากําลังดูการรีเฟรช เนื่องจากมันไม่เกี่ยวข้องกับขั้นตอนในตัวแก้ไข เราอาจต้องการดูที่ 'Id' สําหรับพารามิเตอร์ 'Legend' คุณควรตั้งค่า 'หมวดหมู่' หรือ 'การทํางาน' (ขึ้นอยู่กับความละเอียดที่คุณต้องการ) สําหรับ "ค่า" ให้ตั้งค่า "ระยะเวลาพิเศษ" (และตรวจสอบว่าไม่ใช่ %เพื่อให้คุณได้ค่าระยะเวลาดิบ) สุดท้าย สําหรับคําแนะนําเครื่องมือ ให้ตั้งค่า ' เวลาเริ่มต้นเร็วที่สุด'

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

การแสดงภาพรายละเอียดและการรวมเวลา

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

การตีความการแสดงภาพ

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

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

หากเราต้องการดูว่าเวลาใช้ไปอย่างไร เราก็สามารถดูการแสดงภาพที่เราสร้างขึ้นด้านบนได้

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

สําหรับผลลัพธ์ OData ของฉัน ฉันเห็นในภาพว่าใช้เวลาส่วนใหญ่ในการดึงข้อมูลจากแหล่งที่มา - หากฉันเลือกรายการ 'แหล่งข้อมูล' ในคําอธิบายแผนภูมิ จะแสดงการดําเนินการต่างๆ ทั้งหมดที่เกี่ยวข้องกับการส่งคิวรีไปยังแหล่งข้อมูล

สรุปการวินิจฉัยแบบสอบถาม OData Northwind

หากเราดําเนินการเดียวกันทั้งหมดและสร้างการแสดงภาพที่คล้ายคลึงกัน แต่ด้วยการติดตาม SQL แทนที่จะเป็น ODATA เราจะเห็นว่าแหล่งข้อมูลทั้งสองเปรียบเทียบกันอย่างไร!

สรุปการวินิจฉัยแบบสอบถาม OData Northwind พร้อมการติดตาม SQL

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

ดังที่กล่าวมาข้างต้นเราสามารถเลือกหมวดหมู่ 'แหล่งข้อมูล' ในคําอธิบายแผนภูมิเพื่อดูการสืบค้นที่ปล่อยออกมา

การขุดลงไปในข้อมูล

การมองเส้นทาง

เมื่อคุณกําลังดูสิ่งนี้ หากดูเหมือนว่าเวลาที่ใช้ไปนั้นแปลก ตัวอย่างเช่น ในคิวรี OData คุณอาจเห็นว่ามีคิวรีแหล่งข้อมูลที่มีค่าต่อไปนี้:

Request:
https://services.odata.org/V4/Northwind/Northwind.svc/Customers?$filter=ContactTitle%20eq%20%27Sales%20Representative%27&$select=CustomerID%2CCountry HTTP/1.1
Content-Type: application/json;odata.metadata=minimal;q=1.0,application/json;odata=minimalmetadata;q=0.9,application/atomsvc+xml;q=0.8,application/atom+xml;q=0.8,application/xml;q=0.7,text/plain;q=0.7

<Content placeholder>

Response:
Content-Type: application/json;odata.metadata=minimal;q=1.0,application/json;odata=minimalmetadata;q=0.9,application/atomsvc+xml;q=0.8,application/atom+xml;q=0.8,application/xml;q=0.7,text/plain;q=0.7
Content-Length: 435

<Content placeholder>

คิวรีแหล่งข้อมูลนี้เชื่อมโยงกับการดําเนินการที่ใช้เพียง 1% ของระยะเวลาเฉพาะบุคคล ในขณะเดียวกันก็มีสิ่งที่คล้ายกัน:

Request:
GET https://services.odata.org/V4/Northwind/Northwind.svc/Customers?$filter=ContactTitle eq 'Sales Representative'&$select=CustomerID%2CCountry HTTP/1.1

Response:
https://services.odata.org/V4/Northwind/Northwind.svc/Customers?$filter=ContactTitle eq 'Sales Representative'&$select=CustomerID%2CCountry
HTTP/1.1 200 OK

คิวรีแหล่งข้อมูลนี้เชื่อมโยงกับการดําเนินการที่ใช้เกือบ 75% ของระยะเวลาเฉพาะบุคคล หากคุณเปิด เส้นทาง คุณจะพบว่าคนหลังเป็นลูกของอดีต ซึ่งหมายความว่าการสืบค้นแรกโดยพื้นฐานแล้วจะเพิ่มเวลาเพียงเล็กน้อยด้วยตัวเอง โดยการค้นหาข้อมูลจริงจะถูกติดตามโดยคําค้นหา 'ภายใน'

สิ่งเหล่านี้เป็นค่านิยมสุดโต่ง แต่อยู่ในขอบเขตของสิ่งที่อาจเห็นได้