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

นําไปใช้กับ:✅ จุดสิ้นสุดการวิเคราะห์ SQL ใน Microsoft Fabric

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

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

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

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

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

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

ตารางในจุดสิ้นสุดการวิเคราะห์ SQL จะถูกสร้างขึ้นด้วยความล่าช้าเล็กน้อย เมื่อคุณสร้างหรืออัปเดตตาราง Delta Lake ในทะเลสาบ ตารางปลายทางการวิเคราะห์ SQL ที่อ้างอิงตาราง Delta Lake จะถูกสร้างขึ้น/รีเฟรชโดยอัตโนมัติ

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

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

คุณยังสามารถบังคับให้มีการรีเฟรชเมตาดาต้าอัตโนมัติโดยใช้ รีเฟรชเมตาดาต้าปลายทาง SQL REST API

คำแนะนำ

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

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

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

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

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

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

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

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 (~400 MB)
spark.conf.set("spark.databricks.delta.optimize.maxFileSize", 400 * 1024 * 1024)

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

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

Note

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

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

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

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

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

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

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

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

ก่อนอื่น คุณต้องระบุเส้นทาง ABSFF สําหรับตาราง 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']}")

คำติชม

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

Last updated on 2026-01-27