แชร์ผ่าน


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

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

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

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

สคีมาที่สร้างขึ้นโดยอัตโนมัติในจุดสิ้นสุดการวิเคราะห์ 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 ของคุณ และค้นหาปุ่มรีเฟรช ดังที่แสดงในรูปต่อไปนี้

สกรีนช็อตจากพอร์ทัล Fabric ที่แสดงปุ่มรีเฟรชปลายทางการวิเคราะห์ SQL

คำแนะนำ

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

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

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

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

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

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

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

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

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