Ζητήματα επιδόσεων τελικού σημείου ανάλυσης SQL

Το τελικό σημείο ανάλυσης SQL σάς επιτρέπει να υποβάλετε ερωτήματα σε δεδομένα στο lakehouse χρησιμοποιώντας τη γλώσσα T-SQL και το πρωτόκολλο TDS.

Συμβουλή

Για ολοκληρωμένες οδηγίες σχετικά με τη βελτιστοποίηση πινάκων Delta για κατανάλωση τελικού σημείου ανάλυσης SQL, συμπεριλαμβανομένων των προτάσεων μεγέθους αρχείου και ομάδας γραμμών, ανατρέξτε στο θέμα Συντήρηση και βελτιστοποίηση πινάκων μεταξύ φόρτων εργασίας.

Κάθε λίμνη έχει ένα τελικό σημείο ανάλυσης SQL. Ο αριθμός των τελικών σημείων ανάλυσης SQL σε έναν χώρο εργασίας συμφωνεί με τον αριθμό των λιμνοθάφτων και των βάσεων δεδομένων κατοπτρισμού που έχουν παραθεί σε αυτόν τον χώρο εργασίας.

Μια διαδικασία παρασκηνίου είναι υπεύθυνη για τη σάρωση του lakehouse για αλλαγές και τη διατήρηση του τελικού σημείου ανάλυσης SQL up-toημερομηνίας για όλες τις αλλαγές που έχουν δεσμευτεί σε lakehouses σε έναν χώρο εργασίας. Η πλατφόρμα Microsoft Fabric διαχειρίζεται με διαφάνεια τη διαδικασία συγχρονισμού. Όταν εντοπίζεται μια αλλαγή σε μια λίμνη, μια διαδικασία παρασκηνίου ενημερώνει τα μετα-δεδομένα και το τελικό σημείο ανάλυσης SQL αντικατοπτρίζει τις αλλαγές που εφαρμόζονται σε πίνακες lakehouse. Υπό κανονικές συνθήκες λειτουργίας, η καθυστέρηση μεταξύ ενός τελικού σημείου lakehouse και ανάλυσης SQL είναι λιγότερο από ένα λεπτό. Η πραγματική χρονική διάρκεια μπορεί να ποικίλλει από μερικά δευτερόλεπτα έως λεπτά, ανάλογα με πολλούς παράγοντες που εξετάζει αυτό το άρθρο. Η διαδικασία παρασκηνίου εκτελείται μόνο όταν το τελικό σημείο ανάλυσης SQL είναι ενεργό και σταματά μετά από 15 λεπτά αδράνειας.

Καθοδήγηση

Ο αυτόματος εντοπισμός μετα-δεδομένων παρακολουθεί τις αλλαγές που διαπράττονται σε lakehouses και είναι μία μοναδική παρουσία ανά χώρο εργασίας Fabric. Εάν παρατηρήσετε αυξημένο λανθάνοντα χρόνο για αλλαγές στον συγχρονισμό μεταξύ των λιμνών και του τελικού σημείου ανάλυσης SQL, αυτό μπορεί να οφείλεται σε μεγάλο αριθμό λιμνών σε έναν χώρο εργασίας. Σε ένα τέτοιο σενάριο, εξετάστε το ενδεχόμενο μετεγκατάστασης κάθε lakehouse σε ξεχωριστό χώρο εργασίας, καθώς αυτή η προσέγγιση επιτρέπει την αυτόματη ανακάλυψη μετα-δεδομένων για κλιμάκωση.
Τα αρχεία Parquet είναι αμετάβλητα βάσει σχεδίασης. Όταν υπάρχει μια λειτουργία ενημέρωσης ή διαγραφής, ένας πίνακας Delta προσθέτει νέα αρχεία Parquet με το σύνολο αλλαγών, γεγονός που αυξάνει τον αριθμό των αρχείων με την πάροδο του χρόνου, ανάλογα με τη συχνότητα των ενημερώσεων και των διαγραφών. Εάν δεν προγραμματίσετε τη συντήρηση, αυτό το μοτίβο δημιουργεί τελικά μια επιβάρυνση ανάγνωσης και αυτή η συνθήκη επηρεάζει τον χρόνο που απαιτείται για τον συγχρονισμό των αλλαγών στο τελικό σημείο ανάλυσης SQL. Για να αντιμετωπίσετε αυτό το ζήτημα, προγραμματίστε τακτικές εργασίες συντήρησης τραπεζιών lakehouse.
Σε ορισμένα σενάρια, μπορεί να παρατηρήσετε ότι οι αλλαγές που έχουν δεσμευτεί σε μια λίμνη δεν είναι ορατές στο συσχετισμένο τελικό σημείο ανάλυσης SQL. Για παράδειγμα, μπορείτε να δημιουργήσετε έναν νέο πίνακα στο lakehouse, αλλά δεν εμφανίζεται ακόμα στο τελικό σημείο ανάλυσης SQL. Εναλλακτικά, μπορείτε να δεσμεύσετε μεγάλο αριθμό γραμμών σε έναν πίνακα σε μια λίμνη, αλλά αυτά τα δεδομένα δεν είναι ακόμα ορατά στο τελικό σημείο ανάλυσης SQL. Έχετε την επιλογή να ξεκινήσετε τον συγχρονισμό μεταδεδομένων κατ' απαίτηση.
Η διαδικασία αυτόματου συγχρονισμού δεν υποστηρίζει όλες τις δυνατότητες Delta. Για περισσότερες πληροφορίες σχετικά με τη λειτουργικότητα που υποστηρίζεται από κάθε μηχανισμό στο Fabric, ανατρέξτε στο θέμα Διαλειτουργικότητα μορφής πίνακα Delta Lake.
Εάν υπάρχει εξαιρετικά μεγάλος όγκος αλλαγών πίνακα κατά τη διάρκεια της επεξεργασίας ETL (Extract Transform and Load), εμφανίζεται μια αναμενόμενη καθυστέρηση μέχρι να διεκπεραιωθούν όλες οι αλλαγές.

Βελτιστοποίηση πινάκων lakehouse για υποβολή ερωτημάτων στο τελικό σημείο ανάλυσης SQL

Όταν το τελικό σημείο ανάλυσης SQL διαβάζει πίνακες που είναι αποθηκευμένοι σε μια λίμνη, οι επιδόσεις του ερωτήματος εξαρτώνται σε μεγάλο βαθμό από τη φυσική διάταξη των υποκείμενων αρχείων Parquet.

Ένας μεγάλος αριθμός μικρών αρχείων Parquet δημιουργεί επιβάρυνση και επηρεάζει αρνητικά την απόδοση του ερωτήματος. Για να διασφαλίσετε προβλέψιμη και αποτελεσματική απόδοση, διατηρήστε την αποθήκευση πίνακα έτσι ώστε κάθε αρχείο Parquet να περιέχει δύο εκατομμύρια σειρές. Αυτός ο αριθμός σειρών παρέχει ένα ισορροπημένο επίπεδο παραλληλισμού χωρίς να κατακερματίζει το σύνολο δεδομένων σε υπερβολικά μικρές φέτες.

Εκτός από την καθοδήγηση για τον αριθμό σειρών, το μέγεθος του αρχείου είναι εξίσου σημαντικό. Το τελικό σημείο ανάλυσης SQL αποδίδει καλύτερα όταν τα αρχεία Parquet είναι αρκετά μεγάλα ώστε να ελαχιστοποιούν την επιβάρυνση χειρισμού αρχείων, αλλά όχι τόσο μεγάλα ώστε να περιορίζουν την αποτελεσματικότητα της παράλληλης σάρωσης. Για τους περισσότερους φόρτους εργασίας, η διατήρηση μεμονωμένων αρχείων Parquet κοντά στα 400 MB επιτυγχάνει την καλύτερη ισορροπία. Για να επιτύχετε αυτήν την ισορροπία, ακολουθήστε τα παρακάτω βήματα:

Ορίστε maxRecordsPerFile σε 2.000.000 πριν από την πραγματοποίηση αλλαγών δεδομένων.
Εκτελέστε τις αλλαγές δεδομένων σας (πρόσληψη δεδομένων, ενημερώσεις, διαγραφές).
Ορίστε maxFileSize στα 4 GB.
Εκτελέστε το OPTIMIZE. Για λεπτομέρειες σχετικά με τη χρήση OPTIMIZEτου , ανατρέξτε στο θέμα Εκτέλεση συντήρησης πίνακα από το Lakehouse.

Η παρακάτω δέσμη ενεργειών παρέχει ένα πρότυπο για αυτά τα βήματα και θα πρέπει να εκτελεστεί σε ένα 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
""")

Για να διατηρήσετε υγιή μεγέθη αρχείων, εκτελείτε περιοδικά λειτουργίες βελτιστοποίησης Delta, όπως OPTIMIZE, ειδικά για πίνακες που λαμβάνουν συχνά αυξητικές εισαγωγές, ενημερώσεις και διαγραφές. Αυτές οι λειτουργίες συντήρησης συμπυκνώνουν μικρά αρχεία σε κατάλληλα μεγέθη, διασφαλίζοντας ότι το τελικό σημείο ανάλυσης SQL μπορεί να επεξεργάζεται αποτελεσματικά τα ερωτήματα.

Σημείωμα

Για οδηγίες σχετικά με τη γενική συντήρηση των τραπεζιών lakehouse, ανατρέξτε στο θέμα Εκτέλεση συντήρησης πινάκων από το Lakehouse.

Ζητήματα μεγέθους διαμερίσματος

Η επιλογή της στήλης διαμερίσματος για έναν πίνακα δέλτα σε μια λίμνη επηρεάζει επίσης τον χρόνο που απαιτείται για τον συγχρονισμό των αλλαγών στο τελικό σημείο ανάλυσης SQL. Ο αριθμός και το μέγεθος των διαμερισμάτων της στήλης διαμερίσματος είναι σημαντικά για τις επιδόσεις:

Μια στήλη με υψηλή πληθικότητα (κυρίως ή εξ ολοκλήρου κατασκευασμένη από μοναδικές τιμές) οδηγεί σε μεγάλο αριθμό διαμερισμάτων. Ένας μεγάλος αριθμός διαμερισμάτων επηρεάζει αρνητικά την απόδοση της σάρωσης εντοπισμού μετα-δεδομένων για αλλαγές. Εάν η πληθικότητα μιας στήλης είναι υψηλή, επιλέξτε μια άλλη στήλη για διαμερισμό.
Το μέγεθος κάθε διαμερίσματος μπορεί επίσης να επηρεάσει τις επιδόσεις. Χρησιμοποιήστε μια στήλη που οδηγεί σε ένα διαμέρισμα τουλάχιστον (ή κοντά σε) 1 GB. Ακολουθήστε τις βέλτιστες πρακτικές για τη συντήρηση και τη βελτιστοποίηση των πινάκων δέλτα. Για μια Python δέσμη ενεργειών για την αξιολόγηση κατατμήσεων, ανατρέξτε στο θέμα Δείγμα δέσμης ενεργειών για λεπτομέρειες κατάτμησης.

Ένας μεγάλος όγκος αρχείων parquet μικρού μεγέθους αυξάνει τον χρόνο που απαιτείται για τον συγχρονισμό των αλλαγών μεταξύ ενός lakehouse και του σχετικού τελικού σημείου ανάλυσης SQL. Μπορεί να καταλήξετε με μεγάλο αριθμό αρχείων parquet σε έναν πίνακα δέλτα για έναν ή περισσότερους λόγους:

Εάν επιλέξετε ένα διαμέρισμα για έναν πίνακα Delta με μεγάλο αριθμό μοναδικών τιμών, ο πίνακας διαμερίζεται κατά κάθε μοναδική τιμή και μπορεί να έχει υπερδιαμεριστεί. Επιλέξτε μια στήλη διαμερίσματος που δεν έχει υψηλή πληθικότητα και έχει ως αποτέλεσμα μεμονωμένα διαμερίσματα τουλάχιστον 1 GB το καθένα.
Οι ρυθμοί πρόσληψης δεδομένων δέσμης και ροής μπορεί επίσης να οδηγήσουν σε μικρά αρχεία, ανάλογα με τη συχνότητα και το μέγεθος των αλλαγών που γράφονται σε ένα lakehouse. Για παράδειγμα, μπορεί να υπάρχει ένας μικρός όγκος αλλαγών που έρχονται στο lakehouse, με αποτέλεσμα μικρά αρχεία παρκέ. Για να αντιμετωπίσετε αυτό το ζήτημα, εφαρμόστε τακτική συντήρηση του τραπεζιού lakehouse.

Δείγμα δέσμης ενεργειών για λεπτομέρειες διαμερίσματος

Χρησιμοποιήστε το ακόλουθο σημειωματάριο για να εκτυπώσετε ένα μέγεθος αναφοράς με λεπτομέρειες και λεπτομέρειες για τα διαμερίσματα που στηρίζουν έναν πίνακα δέλτα.

Αρχικά, δώστε τη διαδρομή ABFSS για τον πίνακα δέλτα στη μεταβλητή delta_table_path.
- Μπορείτε να λάβετε τη διαδρομή ABFSS ενός πίνακα δέλτα από την Εξερεύνηση πύλης Fabric. Κάντε δεξί κλικ στο όνομα του πίνακα και, στη συνέχεια, επιλέξτε COPY PATH από τη λίστα επιλογών.
Η δέσμη ενεργειών εξάγει όλα τα διαμερίσματα για τον πίνακα δέλτα.
Η δέσμη ενεργειών επαναλαμβάνεται σε κάθε διαμέρισμα για να υπολογιστεί το συνολικό μέγεθος και ο αριθμός των αρχείων.
Η δέσμη ενεργειών εξάγει τις λεπτομέρειες των διαμερισμάτων, των αρχείων ανά διαμερίσματα και του μεγέθους ανά διαμέρισμα σε 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 του Lakehouse

Για κάθε πίνακα Delta στο Lakehouse, το τελικό σημείο ανάλυσης SQL δημιουργεί αυτόματα έναν πίνακα στο κατάλληλο σχήμα. Ο μηχανισμός τελικού σημείου ανάλυσης SQL βασίζεται στον μηχανισμό Fabric αποθήκη δεδομένων.

Για περισσότερες πληροφορίες, ανατρέξτε στο θέμα Συγχρονισμός μετα-δεδομένων τελικού σημείου ανάλυσης SQL. Μπορείτε επίσης να επιβάλετε μέσω προγραμματισμού μια ανανέωση της αυτόματης σάρωσης μετα-δεδομένων χρησιμοποιώντας το REST API ανανέωσης μετα-δεδομένων τελικού σημείου SQL.

Σχόλια

Ήταν χρήσιμη αυτή η σελίδα;

Last updated on 2026-05-26