แนวทางปฏิบัติที่ดีที่สุดสําหรับ REST API ของการดําเนินการคิวรี DAX

ทําตามคําแนะนําเหล่านี้เพื่อรับประโยชน์สูงสุดจาก Execute DAX Queries REST API ในปริมาณงานการผลิต

เลือกปลายทางที่เหมาะสม

Power BI มี REST API สองรายการสําหรับการดําเนินการคิวรี DAX เลือกสิ่งที่ตรงกับความสามารถของลูกค้าของคุณ:

• ดําเนินการคิวรี DAX (ลูกศร) — ใช้เมื่อใดก็ตามที่แอปพลิเคชันไคลเอ็นต์ของคุณสามารถใช้สตรีม IPC ลูกศรไบนารีได้ ความเที่ยงตรงของประเภทแบบไม่สูญเสียข้อมูล และการ deserialization แบบไม่มีสําเนาลงในเฟรมเวิร์กแบบคอลัมน์ เช่น แพนด้า โพลาร์ และ Apache Spark API นี้ยังรองรับพารามิเตอร์ขั้นสูง เช่น queryTimeout และ resultsetRowcountLimit. ต้องใช้ความจุแบบพรีเมียมหรือ Fabric
• ดําเนินการสืบค้น (JSON) — ใช้เมื่อผู้บริโภคของคุณเป็นแพลตฟอร์มแบบ low-code/no-code โฟลว์ Power Automate หรือเครื่องมือใดๆ ที่สามารถแยกวิเคราะห์ JSON เท่านั้น API นี้ทํางานบนความจุ Pro, PPU และ Premium/Fabric แต่มีขีดจํากัดแบบตายตัวที่ 100,000 แถวและ 1,000,000 ค่าต่อการสืบค้น

ตามกฎทั่วไป หากชุดผลลัพธ์ของคุณเกินสองสามร้อยแถว ป้อนเข้าสู่ไปป์ไลน์การวิเคราะห์ หรือต้องการความเที่ยงตรงของชนิดที่แม่นยํา ให้ใช้ Execute DAX Queries API ด้วย Arrow

ปรับคิวรี DAX ให้เหมาะสมสําหรับจุดสิ้นสุดลูกศร

DAX ที่มีประสิทธิภาพช่วยลดทั้งเวลาดําเนินการคิวรีและขนาดเพย์โหลดการตอบสนอง:

• ส่งคืนเฉพาะคอลัมน์ที่คุณต้องการ ใช้ SELECTCOLUMNS หรือแสดงรายการคอลัมน์ที่ชัดเจนแทนการส่งกลับทั้งตาราง ทุกคอลัมน์พิเศษจะเพิ่มลงใน Schema และขนาดชุดงานของเรกคอร์ด
• ชอบSUMMARIZECOLUMNSมากกว่า ADDCOLUMNS .FILTER SUMMARIZECOLUMNS สร้างแผนการสืบค้นที่มีประสิทธิภาพมากขึ้นในกลไกจัดการ VertiPaq
• ใช้เพื่อ TOPN จํากัดแถว เมื่อคุณต้องการเพียงผลลัพธ์สูงสุด ให้ TOPN ผลักดันขีดจํากัดลงในกลไกจัดการแทนที่จะถ่ายโอนแถวทั้งหมดและกรองฝั่งไคลเอ็นต์
• หลีกเลี่ยงคอลัมน์จากการคํานวณที่ซับซ้อนในคิวรี การวัดผลและการรวมนั้นใช้ได้ แต่การคํานวณระดับแถวบนตารางขนาดใหญ่อาจทําให้การดําเนินการช้าลงอย่างมาก
• รวม EVALUATE หลายใบแจ้งยอดในคําขอเดียว Execute DAX Queries API สนับสนุนคําสั่งหลาย EVALUATE คําสั่งภายในสตริงเดียว query โดยแต่ละคําสั่งจะส่งคืนชุดผลลัพธ์แยกต่างหาก วิธีนี้จะหลีกเลี่ยงค่าใช้จ่ายของไปกลับ HTTP แยกต่างหาก

จัดการการรับรองความถูกต้องอย่างมีประสิทธิภาพ

• แคชและนําโทเค็นกลับมาใช้ใหม่ ใช้แคชโทเค็นในตัวของ MSAL เพื่อหลีกเลี่ยงการเรียก Microsoft Entra ID ในทุกคําขอ สําหรับโฟลว์ไคลเอ็นต์ที่เป็นความลับ MSAL จะแคชโทเค็นโดยอัตโนมัติเมื่อคุณใช้อินสแตนซ์เดียวกัน ConfidentialClientApplication ซ้ํา
• ใช้ข้อมูลประจําตัวของลูกค้าที่เป็นความลับสําหรับบริการ สําหรับบริการระดับกลางแบบไม่ต้องใส่ข้อมูล ให้ใช้ข้อมูลเข้าสู่ระบบไคลเอ็นต์ (ข้อมูลลับไคลเอ็นต์หรือใบรับรอง) แทนโทเค็นผู้ใช้ที่ได้รับมอบหมาย วิธีนี้จะหลีกเลี่ยงการพึ่งพาเซสชันผู้ใช้ที่ลงชื่อเข้าใช้
• ต้องการข้อมูลประจําตัวที่มีการจัดการใน Azure เมื่อบริการของคุณทํางานใน Azure (App Service, Functions, AKS) ให้ใช้ข้อมูลประจําตัวที่มีการจัดการเพื่อกําจัดการจัดการข้อมูลประจําตัวทั้งหมด
• จัดการกับการหมดอายุของโทเค็นอย่างสง่างาม โดยทั่วไปโทเค็นการเข้าถึงจะหมดอายุหลังจากผ่านไปหนึ่งชั่วโมง ตรวจสอบ 401 Unauthorized การตอบกลับและรีเฟรชโทเค็นก่อนลองอีกครั้ง

จัดการข้อผิดพลาดและการลองใหม่

API ดําเนินการคิวรี DAX สามารถส่งคืนข้อผิดพลาดได้สองวิธี:

1. ข้อผิดพลาดระดับ HTTP — รหัสสถานะ HTTP มาตรฐานที่มีเนื้อหาข้อผิดพลาด JSON รหัสทั่วไป:

   รหัสสถานะ	ความหมาย	แอคชัน
   400	คําขอไม่ถูกต้อง (DAX ไม่ถูกต้อง พารามิเตอร์ขาดหายไป)	แก้ไขคําขอ — อย่าลองอีกครั้ง
   401	ไม่ได้รับอนุญาต (โทเค็นหมดอายุหรือไม่ถูกต้อง)	รีเฟรชโทเค็นและลองอีกครั้งหนึ่งครั้ง
   403	ต้องห้าม (สิทธิ์ไม่เพียงพอ)	ตรวจสอบว่าผู้เรียกมีสิทธิ์สร้างและอ่านในแบบจําลองความหมาย
   429	คําขอมากเกินไป (ถูกควบคุม)	รอระยะเวลาในส่วน Retry-After หัว แล้วลองอีกครั้ง
   500 / 502 / 503	ข้อผิดพลาดของเซิร์ฟเวอร์ชั่วคราว	ลองอีกครั้งด้วยการย้อนกลับแบบเอ็กซ์โพเนนเชียล

2. ข้อผิดพลาดระดับสตรีม — HTTP 200 ที่มีชุดแถวข้อผิดพลาดฝังอยู่ในการตอบสนองลูกศร ตรวจสอบข้อมูลเมตาของสคีมาลูกศรและIsError=trueอ่านค่าและFaultCodeFaultStringข้อมูลเมตา รวมถึงแถวข้อผิดพลาดสําหรับข้อมูลตําแหน่งโดยละเอียด

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

ควบคุมขนาดชุดผลลัพธ์

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

วิธีจัดการชุดผลลัพธ์ให้ได้

• ตั้งค่า resultsetRowcountLimit ในเนื้อหาคําขอ การดําเนินการนี้จะบังคับใช้ขีดจํากัดแถวฝั่งเซิร์ฟเวอร์ต่อชุดผลลัพธ์ หากคุณทราบว่าผู้บริโภคต้องการเพียง 10,000 แถว ให้กําหนดขีดจํากัดอย่างชัดเจน
• ใช้ใน TOPN คิวรี DAX ของคุณ TOPN จํากัดแถวที่ระดับกลไกจัดการ ซึ่งมีประสิทธิภาพมากกว่าการตัดทอนฝั่งไคลเอ็นต์
• ประมวลผลชุดงานเรกคอร์ดแบบเพิ่มหน่วย การตอบสนองของลูกศรจะถูกแบ่งออกเป็นชุดงานบันทึกสูงสุด 100,000 แถว ใน Python ให้วนซ้ําแบทช์ด้วย reader.read_next_batch() แทนการเรียก reader.read_all() เมื่อทํางานกับผลลัพธ์ขนาดใหญ่ เพื่อให้การใช้หน่วยความจําคงที่

รักษาความปลอดภัยให้กับบริการระดับกลางของคุณ

หากคุณสร้างบริการระดับกลางที่พร็อกซีคิวรี DAX สําหรับผู้บริโภคดาวน์สตรีม:

• ตรวจสอบข้อมูลประจําตัวของผู้โทร รับรองความถูกต้องของคําขอขาเข้าด้วย Microsoft Entra ID หรือผู้ให้บริการข้อมูลประจําตัวอื่นก่อนที่จะส่งต่อคิวรีไปยัง Power BI อย่าเปิดเผยตําแหน่งข้อมูล Execute DAX Queries เป็นพร็อกซีแบบเปิด
• บังคับใช้สิทธิ์การใช้งานน้อยที่สุด ให้สิทธิ์เฉพาะบริการหลักที่จําเป็น (สร้างและอ่านบนโมเดลความหมายเฉพาะ) อย่าใช้บทบาทผู้ดูแลระบบพื้นที่ทํางานหรือผู้ดูแลระบบผู้เช่าสําหรับการเข้าถึง API
• อย่าฝังข้อมูลเข้าสู่ระบบในโค้ด จัดเก็บข้อมูลลับของไคลเอ็นต์ใน Azure Key Vault หรือใช้ข้อมูลประจําตัวที่มีการจัดการ หมุนเวียนข้อมูลลับตามกําหนดเวลาปกติ
• ฆ่าเชื้ออินพุต DAX ถ้าระดับกลางของคุณยอมรับข้อความคิวรี DAX จากผู้โทร ให้ตรวจสอบความถูกต้องของอินพุตเพื่อป้องกันการแทรกการดําเนินการที่ไม่คาดคิด
• ใช้ effectiveUsername พารามิเตอร์ด้วยความระมัดระวัง พารามิเตอร์นี้ใช้ Row-Level ความปลอดภัยในนามของผู้ใช้ที่ระบุ ตรวจสอบให้แน่ใจว่าข้อมูลประจําตัวที่โทรได้รับอนุญาตให้แอบอ้างเป็นผู้ใช้ที่ระบุ

ตรวจสอบและบันทึก

ติดตามความสมบูรณ์และประสิทธิภาพของการใช้งาน API ของคุณ:

• ข้อมูลเมตาของการค้นหาบันทึก — บันทึกข้อความการค้นหา ขนาดการตอบกลับ สถานะ HTTP และระยะเวลาสําหรับแต่ละคําขอ วิธีนี้จะช่วยระบุคิวรีที่ช้าและข้อผิดพลาดที่ไม่คาดคิด
• ตรวจสอบอัตราการควบคุม — ติดตาม 429 การตอบกลับเป็นเปอร์เซ็นต์ของคําขอทั้งหมด แนวโน้มที่เพิ่มขึ้นบ่งชี้ว่าคุณต้องลดความถี่ในการร้องขอหรือกระจายภาระตลอดเวลา
• วัดเวลา deserialization — สําหรับการตอบกลับของ Arrow ให้บันทึกเวลาที่ใช้ในการอ่านและทําให้แบทช์บันทึกเป็นรูปธรรมแยกต่างหากจากเวลาไปกลับ HTTP สิ่งนี้จะช่วยแยกความแตกต่างของเวลาแฝงของเครือข่ายจากการประมวลผลฝั่งไคลเอ็นต์
• ใช้ Application Insights หรือเทียบเท่า — หากระดับกลางของคุณทํางานใน Azure ให้เปิดใช้งาน Application Insights เพื่อรับการติดตามการขึ้นต่อกัน การแจ้งเตือนความล้มเหลว และการติดตามแบบกระจายแบบครบวงจร
• ติดตามอัตราการเข้าชมแคชโทเค็น — อัตราการเข้าชมแคชที่ต่ําหมายถึงการเรียกรับโทเค็นบ่อยครั้ง ซึ่งเพิ่มเวลาแฝงและเป็นสัญญาณของการแคช MSAL ที่กําหนดค่าไม่ถูกต้อง

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

• ทําความเข้าใจ API คิวรี DAX
• เริ่มต้นใช้งาน REST API ดําเนินการคิวรี DAX
• บทช่วยสอน: สร้างบริการดําเนินการคิวรี DAX ระดับกลาง
• บทช่วยสอน: การแยก Python ปริมาณมากสําหรับวิทยาศาสตร์ข้อมูล