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

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

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

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

คำแนะนำ

• การค้นพบเมตาดาต้าอัตโนมัติติดตามการเปลี่ยนแปลงที่ผูกมัดกับเลคเฮ้าส์ และเป็นอินสแตนซ์เดียวต่อพื้นที่ทํางาน Fabric หากคุณสังเกตเห็นเวลาแฝงที่เพิ่มขึ้นสําหรับการเปลี่ยนแปลงในการซิงค์ระหว่างเลคเฮาส์และตําแหน่งข้อมูลการวิเคราะห์ SQL อาจเป็นเพราะเลคเฮาส์จํานวนมากในพื้นที่ทํางานเดียว ในสถานการณ์เช่นนี้ ให้พิจารณาโยกย้ายเลคเฮาส์แต่ละเลคไปยังพื้นที่ทํางานแยกต่างหาก เนื่องจากวิธีการนี้ช่วยให้การค้นพบข้อมูลเมตาอัตโนมัติสามารถปรับขนาดได้
• ไฟล์ Parquet ไม่สามารถทําการออกแบบได้ เมื่อมีการอัปเดตหรือการดําเนินการลบ ตารางเดลต้าจะเพิ่มไฟล์ Parquet ใหม่ด้วยชุดการเปลี่ยนแปลง ซึ่งจะเพิ่มจํานวนไฟล์เมื่อเวลาผ่านไป ขึ้นอยู่กับความถี่ของการอัปเดตและการลบ ถ้าคุณไม่จัดกําหนดการการบํารุงรักษา รูปแบบนี้จะสร้างค่าใช้จ่ายในการอ่านในที่สุด และเงื่อนไขนี้จะส่งผลต่อเวลาที่ใช้ในการซิงค์การเปลี่ยนแปลงไปยังตําแหน่งข้อมูลการวิเคราะห์ SQL เมื่อต้องการแก้ไขปัญหานี้ ให้กําหนดเวลา การดําเนินการบํารุงรักษาโต๊ะเลคเฮาส์เป็นประจํา
• ในบางสถานการณ์ คุณอาจสังเกตเห็นว่าการเปลี่ยนแปลงที่ผูกมัดกับเลคเฮาส์จะไม่สามารถมองเห็นได้ในตําแหน่งข้อมูลการวิเคราะห์ SQL ที่เกี่ยวข้อง ตัวอย่างเช่น คุณอาจสร้างตารางใหม่ใน lakehouse แต่ยังไม่ได้แสดงรายการในตําแหน่งข้อมูลการวิเคราะห์ SQL หรือคุณอาจคอมมิตแถวจํานวนมากไปยังตารางในเลคเฮาส์ แต่ข้อมูลนี้ยังไม่ปรากฏในตําแหน่งข้อมูลการวิเคราะห์ SQL คุณมีตัวเลือกในการเริ่มการซิงค์ข้อมูลเมตาตามความต้องการ
• กระบวนการซิงค์อัตโนมัติไม่รองรับคุณสมบัติเดลต้าทั้งหมด สําหรับข้อมูลเพิ่มเติมเกี่ยวกับฟังก์ชันการทํางานที่ได้รับการสนับสนุนโดยแต่ละกลไกใน 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 เพื่อเพิ่มประสิทธิภาพ SQL analytics endpoint เพราะ Spark จะเขียนไฟล์ parquet ที่บีบอัดด้วย Snappy เพื่อลดทั้งการอ่านและเขียน I/O

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

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

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

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

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

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

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

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

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

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

1. อันดับแรก ให้ระบุเส้นทาง ABFSS สําหรับตาราง Delta ของคุณในตัวแปรdelta_table_path
   • คุณสามารถรับเส้นทาง ABFSS ของตาราง delta จาก Fabric portal Explorer ได้ คลิกขวาบนชื่อตาราง จากนั้นเลือก COPY PATH จากรายการตัวเลือก
2. สคริปต์จะส่งออกพาร์ติชันทั้งหมดสําหรับตาราง Delta
3. สคริปต์จะวนผ่านแต่ละพาร์ติชันเพื่อคํานวณขนาดทั้งหมดและจํานวนไฟล์
4. สคริปต์จะส่งออกรายละเอียดของพาร์ติชัน แฟ้มต่อพาร์ติชัน และขนาดต่อพาร์ติชันใน 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 แบบรีเฟรช

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

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