ข้อควรพิจารณาเกี่ยวกับประสิทธิภาพของจุดสิ้นสุดการวิเคราะห์ SQL

ตําแหน่งข้อมูลการวิเคราะห์ SQL ช่วยให้คุณสามารถสืบค้นข้อมูลในเลคเฮาส์โดยใช้ภาษา T-SQL และโปรโตคอล TDS มันใช้ประโยชน์จากเครื่องยนต์ Fabric คลังข้อมูล

เคล็ดลับ

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

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

กระบวนการเบื้องหลังมีหน้าที่ในการสแกนเลคเฮาส์เพื่อหาการเปลี่ยนแปลง และรักษาตําแหน่งข้อมูลการวิเคราะห์ SQL up-toวันที่สําหรับการเปลี่ยนแปลงทั้งหมดที่มุ่งมั่นไปยังเลคเฮาส์ในพื้นที่ทํางาน แพลตฟอร์ม Fabric จัดการกระบวนการซิงค์อย่างโปร่งใส เมื่อตรวจพบการเปลี่ยนแปลงในเลคเฮ้าส์ กระบวนการเบื้องหลังจะอัปเดตเมตาดาต้าและจุดสิ้นสุดการวิเคราะห์ SQL แสดงการเปลี่ยนแปลงที่กําหนดให้กับตารางเลคเฮ้าส์ ภายใต้สภาพการทํางานปกติ การหน่วงเวลาระหว่างจุดสิ้นสุดของ lakehouse และ SQL Analytics จะใช้เวลาไม่เกินหนึ่งนาที ระยะเวลาที่แท้จริงอาจแตกต่างกันไปตั้งแต่ไม่กี่วินาทีถึงนาที ขึ้นอยู่กับปัจจัยหลายประการที่บทความนี้กล่าวถึง กระบวนการเบื้องหลังจะทํางานขณะที่ SQL analytics endpoint ยังทํางานอยู่ และจะหยุดหลังจาก 15 นาทีโดยไม่มีการสืบค้น

คำแนะนำ

การค้นพบเมตาดาต้าอัตโนมัติติดตามการเปลี่ยนแปลงที่ผูกมัดกับเลคเฮ้าส์ และเป็นอินสแตนซ์เดียวต่อพื้นที่ทํางาน Fabric หากคุณสังเกตเห็นเวลาแฝงที่เพิ่มขึ้นสําหรับการเปลี่ยนแปลงในการซิงค์ระหว่างเลคเฮาส์และตําแหน่งข้อมูลการวิเคราะห์ SQL อาจเป็นเพราะเลคเฮาส์จํานวนมากในพื้นที่ทํางานเดียว ในสถานการณ์เช่นนี้ ให้พิจารณาโยกย้ายเลคเฮาส์แต่ละเลคไปยังพื้นที่ทํางานแยกต่างหาก เนื่องจากวิธีการนี้ช่วยให้การค้นพบข้อมูลเมตาอัตโนมัติสามารถปรับขนาดได้
ไฟล์ Parquet ไม่สามารถทําการออกแบบได้ เมื่อมีการอัปเดตหรือการดําเนินการลบ ตารางเดลต้าจะเพิ่มไฟล์ Parquet ใหม่ด้วยชุดการเปลี่ยนแปลง ซึ่งจะเพิ่มจํานวนไฟล์เมื่อเวลาผ่านไป ขึ้นอยู่กับความถี่ของการอัปเดตและการลบ ถ้าคุณไม่จัดกําหนดการการบํารุงรักษา รูปแบบนี้จะสร้างค่าใช้จ่ายในการอ่านในที่สุด และเงื่อนไขนี้จะส่งผลต่อเวลาที่ใช้ในการซิงค์การเปลี่ยนแปลงไปยังตําแหน่งข้อมูลการวิเคราะห์ SQL เมื่อต้องการแก้ไขปัญหานี้ ให้กําหนดเวลา การดําเนินการบํารุงรักษาโต๊ะเลคเฮาส์เป็นประจํา
ในบางสถานการณ์ คุณอาจสังเกตเห็นว่าการเปลี่ยนแปลงที่ผูกมัดกับเลคเฮาส์จะไม่สามารถมองเห็นได้ในตําแหน่งข้อมูลการวิเคราะห์ SQL ที่เกี่ยวข้อง ตัวอย่างเช่น คุณอาจสร้างตารางใหม่ใน lakehouse แต่ยังไม่ได้แสดงรายการในตําแหน่งข้อมูลการวิเคราะห์ SQL หรือคุณอาจคอมมิตแถวจํานวนมากไปยังตารางในเลคเฮาส์ แต่ข้อมูลนี้ยังไม่ปรากฏในตําแหน่งข้อมูลการวิเคราะห์ SQL คุณสามารถเริ่มซิงค์เมตาดาต้าแบบออนดีมานด์ในพอร์ทัล Fabric หรือใช้ Refresh SQL analytics metadata endpoint REST API
กระบวนการซิงค์อัตโนมัติไม่รองรับคุณสมบัติเดลต้าทั้งหมด สําหรับข้อมูลเพิ่มเติมเกี่ยวกับฟังก์ชันการทํางานที่ได้รับการสนับสนุนโดยแต่ละกลไกใน Fabric ดูการทํางานร่วมกันในรูปแบบตาราง Delta Lake
หากมีการเปลี่ยนแปลงตารางจํานวนมากในระหว่างการประมวลผลการแปลงการแยกข้อมูลและโหลด (ETL) ความล่าช้าที่คาดไว้จะเกิดขึ้นจนกว่าการเปลี่ยนแปลงทั้งหมดจะได้รับการประมวลผล

การปรับตารางเลคเฮาส์ให้เหมาะสมสําหรับการสืบค้นตําแหน่งข้อมูลการวิเคราะห์ SQL

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

สําหรับตารางที่เขียนโดย Spark ให้ใช้การตั้งค่าเริ่มต้นใน Fabric Spark runtime 2.0 หรือใหม่กว่า รันไทม์เหล่านี้ช่วยให้ขนาด ไฟล์เป้าหมายแบบปรับตัว ได้โดยค่าเริ่มต้น สามารถเลือกขนาดไฟล์เป้าหมายที่เหมาะสมที่สุดตามตาราง ตั้งแต่ 128 MB สําหรับตารางขนาดเล็ก ไปจนถึง 1 GB สําหรับตารางขนาดใหญ่ หลีกเลี่ยงการตั้งเป้าหมายคงที่หรือจํากัดจํานวนแถวตามต้องการบนการตั้งค่าเริ่มต้น การจํากัดแถวไม่ได้คํานึงถึงความกว้างของแถว และสามารถสร้างไฟล์ขนาดเล็กสําหรับตารางที่แคบได้

หากคุณใช้ Fabric Spark runtime 1.3 ให้เปิดใช้งานขนาดไฟล์เป้าหมายแบบปรับได้และเป้าหมายการบีบอัดระดับไฟล์ ซึ่งมีให้เป็นฟีเจอร์ที่เลือกเข้าร่วมได้

V-Order เป็นประโยชน์หลักกับ Power BI Direct Lake และแม้ว่าจะช่วยเพิ่มการบีบอัดสําหรับงานบางประเภท แต่โดยทั่วไปแล้วไม่จําเป็นหรือแนะนําโดยค่าเริ่มต้นเพื่อประสิทธิภาพสูงสุดของจุดวิเคราะห์ SQL

การตั้งค่าการเขียนเริ่มต้นไม่สามารถแทนที่การดูแลตารางได้ ใช้แนวทางต่อไปนี้เพื่อรักษาเลย์เอาต์ให้มีสุขภาพดีเมื่อตารางเปลี่ยนแปลง:

เปิดใช้งานการ บีบอัดอัตโนมัติ สําหรับงานที่มีความหน่วงเวลาการเขียนแบบซิงโครนัสที่เพิ่มขึ้นเป็นระยะ ๆ เป็นที่ยอมรับได้ Auto Compaction เป็นฟีเจอร์ของ Spark ที่ทํางานเฉพาะเมื่อมีไฟล์ขนาดเล็กมากเกินไปในตาราง
กําหนดเวลางานเป็น OPTIMIZE ระยะสําหรับงานที่ความหน่วงที่เพิ่มขึ้นจากการบีบอัดอัตโนมัติไม่เป็นไปตามข้อกําหนด SLA สําหรับการอัปเดตข้อมูล
ดําเนินการ VACUUM ตามข้อกําหนดการเก็บรักษาและการเดินทางข้ามเวลาเพื่อลบไฟล์ที่บันทึก Delta ไม่อ้างอิงอีกต่อไป VACUUM ลดพื้นที่จัดเก็บที่เก็บไว้แต่ไม่ปรับปรุงการจัดวางไฟล์ที่ใช้งานอยู่
หลีกเลี่ยงการแบ่งพาร์ติชันที่มีจํานวนไฟล์สูงและการตั้งค่าตัวเขียนแบบกําหนดเองที่สร้างไฟล์ขนาดเล็กจํานวนมาก

หากคุณไม่ใช้การบีบอัดอัตโนมัติ เพื่อระบุตารางที่ต้องการการบํารุงรักษา ให้ใช้ท่อข้อมูลและ sys.sp_get_table_health_metrics T-SQL stored procedure ก่อนรัน OPTIMIZE. สําหรับบทช่วยสอน โปรดดู ปรับตาราง Lakehouse ให้เหมาะสมตามการตรวจสอบสถานภาพ

Note

สําหรับคําแนะนําเกี่ยวกับการบํารุงรักษาทั่วไปของโต๊ะเลคเฮาส์ โปรดดู เรียกใช้การบํารุงรักษาโต๊ะจาก Lakehouse

ข้อควรพิจารณาเกี่ยวกับขนาดของพาร์ติชัน

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

หลีกเลี่ยงคอลัมน์พาร์ติชันที่มีจํานวนสูงซึ่งอาจสร้างพาร์ติชันสําหรับแต่ละค่าที่ไม่ซ้ํากัน เลือกคอลัมน์ที่สร้างพาร์ติชันที่มีขนาดใกล้เคียงหรือมากกว่า 1 GB สําหรับข้อมูลเพิ่มเติม ดูที่การแบ่งตาราง Delta Lake
การรับข้อมูลแบบแบตช์และสตรีมมิ่งสามารถสร้างไฟล์ขนาดเล็กได้เมื่อมีการเปลี่ยนแปลงบ่อยหรือเล็ก ใช้ การดูแลโต๊ะ Lakehouse เป็นประจําเพื่อบีบอัดไฟล์เหล่านี้

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

สคริปต์ตัวอย่างสําหรับรายละเอียดพาร์ติชัน

ใช้สมุดโน้ตต่อไปนี้เพื่อพิมพ์รายงานที่ระบุขนาดและรายละเอียดของพาร์ติชันที่อยู่ใต้ตาราง Delta

อันดับแรก ให้ระบุเส้นทาง ABFSS สําหรับตาราง Delta ของคุณในตัวแปรdelta_table_path
- คุณสามารถรับเส้นทาง ABFSS ของตาราง delta จาก Fabric portal Explorer ได้ คลิกขวาบนชื่อตาราง จากนั้นเลือก COPY PATH จากรายการตัวเลือก
สคริปต์จะส่งออกพาร์ติชันทั้งหมดสําหรับตาราง Delta
สคริปต์จะวนผ่านแต่ละพาร์ติชันเพื่อคํานวณขนาดทั้งหมดและจํานวนไฟล์
สคริปต์จะส่งออกรายละเอียดของพาร์ติชัน แฟ้มต่อพาร์ติชัน และขนาดต่อพาร์ติชันใน GB

คุณสามารถคัดลอกสคริปต์ทั้งหมดได้จากบล็อกโค้ดต่อไปนี้:

# Purpose: Print out details of partitions, files per partitions, and size per partition in GB.
from notebookutils import mssparkutils

# Define ABFSS path for your delta table. You can get ABFSS path of a delta table by simply right-clicking on table name and selecting COPY PATH from the list of options.
delta_table_path = "abfss://<workspace id>@<onelake>.dfs.fabric.microsoft.com/<lakehouse id>/Tables/<tablename>"

# List all partitions for given delta table
partitions = mssparkutils.fs.ls(delta_table_path)

# Initialize a dictionary to store partition details
partition_details = {}

# Iterate through each partition
for partition in partitions:
  if partition.isDir:
      partition_name = partition.name
      partition_path = partition.path
      files = mssparkutils.fs.ls(partition_path)
      
      # Calculate the total size of the partition

      total_size = sum(file.size for file in files if not file.isDir)
      
      # Count the number of files

      file_count = sum(1 for file in files if not file.isDir)
      
      # Write partition details

      partition_details[partition_name] = {
          "size_bytes": total_size,
          "file_count": file_count
      }
      
# Print the partition details
for partition_name, details in partition_details.items():
  print(f"{partition_name}, Size: {details['size_bytes']:.2f} bytes, Number of files: {details['file_count']}")

คำติชม

หน้านี้มีประโยชน์หรือไม่

อัปเดตล่าสุดเมื่อ 2026-09-16