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

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

เคล็ดลับ

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

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

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

คำแนะนำ

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

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

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

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

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

ตั้งค่า maxRecordsPerFile เป็น 2,000,000 ก่อนที่ข้อมูลจะเปลี่ยนแปลง
ดําเนินการเปลี่ยนแปลงข้อมูล (การนําเข้าข้อมูล การอัปเดต การลบ)
ตั้งค่า maxFileSize เป็น 4 GB
รัน OPTIMIZE สําหรับรายละเอียดเกี่ยวกับการใช้งาน OPTIMIZEโปรดดู เรียกใช้การบํารุงรักษาตารางจาก Lakehouse

สคริปต์ต่อไปนี้มีเทมเพลตสําหรับขั้นตอนเหล่านี้ และควรดําเนินการบนเลคเฮาส์:

from delta.tables import DeltaTable

# 1. CONFIGURE LIMITS

# Cap files to 2M rows during writes. This should be done before data ingestion occurs. 
spark.conf.set("spark.sql.files.maxRecordsPerFile", 2000000)

# 2. INGEST DATA
# Here, you ingest data into your table 

# 3. CAP FILE SIZE (~4GB)
spark.conf.set("spark.databricks.delta.optimize.maxFileSize", 4 * 1024 * 1024 * 1024)

# 4. RUN OPTIMIZE (bin-packing)
spark.sql("""
    OPTIMIZE myTable
""")

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

Note

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

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

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

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

ไฟล์ parquet ขนาดเล็กจํานวนมากจะเพิ่มเวลาในการซิงค์การเปลี่ยนแปลงระหว่าง lakehouse และจุดสิ้นสุดการวิเคราะห์ SQL ที่เกี่ยวข้อง คุณอาจจบลงด้วยไฟล์ parquet จํานวนมากในตาราง delta ด้วยเหตุผลอย่างน้อยหนึ่งประการ:

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

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

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

ขั้นแรก ให้ระบุเส้นทาง ABFSS สําหรับตารางเดลต้าของคุณในตัวแปร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']}")

สคีมาที่สร้างขึ้นโดยอัตโนมัติในจุดสิ้นสุดการวิเคราะห์ SQL ของเลคเฮ้าส์

สําหรับทุกตาราง Delta ในเลคเฮ้าส์ของคุณ จุดสิ้นสุดการวิเคราะห์ SQL จะสร้างตารางใน Schema ที่เหมาะสมโดยอัตโนมัติ กลไกจัดการปลายทางการวิเคราะห์ SQL ขึ้นอยู่กับกลไกจัดการ Fabric คลังข้อมูล

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

คำติชม

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

Last updated on 2026-05-26