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

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

Συμβουλή

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

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

Μια διαδικασία παρασκηνίου είναι υπεύθυνη για τη σάρωση του lakehouse για αλλαγές και τη διατήρηση του τελικού σημείου ανάλυσης SQL up-toημερομηνίας για όλες τις αλλαγές που έχουν δεσμευτεί σε lakehouses σε έναν χώρο εργασίας. Η πλατφόρμα 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. Πάρα πολλά μικρά αρχεία αυξάνουν την επιβάρυνση αρχείων και μεταδεδομένων, ενώ πολύ λίγα μεγάλα αρχεία μπορούν να περιορίσουν τον παραλληλισμό σάρωσης.

Για πίνακες που έχουν συνταχθεί από το Spark, χρησιμοποιήστε τις προεπιλεγμένες ρυθμίσεις στο χρόνο εκτέλεσης του Fabric Spark 2.0 ή νεότερη έκδοση. Αυτοί οι χρόνοι εκτέλεσης επιτρέπουν στο προσαρμόσιμο μέγεθος αρχείου προορισμού από προεπιλογή για την επιλογή του βέλτιστου μεγέθους αρχείου προορισμού ανά πίνακα, από 128 MB για μικρότερους πίνακες έως 1 GB για τους μεγαλύτερους πίνακες. Αποφύγετε τον ορισμό στατικών στόχων ή αυθαίρετου ορίου πλήθους σειρών πάνω από τις προεπιλεγμένες διαμορφώσεις. Ένα όριο γραμμών δεν λαμβάνει υπόψη το πλάτος της γραμμής και μπορεί να δημιουργήσει μικρά αρχεία για στενούς πίνακες.

Εάν χρησιμοποιείτε το Fabric Spark runtime 1.3, ενεργοποιήστε το προσαρμόσιμο μέγεθος αρχείου προορισμού και τους προορισμούς συμπίεσης σε επίπεδο αρχείου, οι οποίοι είναι διαθέσιμοι ως δυνατότητες συγκατάθεσης.

Δεν χρειάζεστε V-Order για βελτιωμένη απόδοση τελικού σημείου ανάλυσης SQL, καθώς το Spark εγγράφει αρχεία parquet που είναι συμπιεσμένα Snappy για να μειώσει τόσο την ανάγνωση όσο και την εγγραφή εισόδου/εξόδου.

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

  • Ενεργοποιήστε την αυτόματη συμπύκνωση για φόρτους εργασίας όπου είναι αποδεκτός ο περιοδικός προστιθέμενος λανθάνων χρόνος σύγχρονης εγγραφής. Η αυτόματη συμπίεση είναι μια δυνατότητα Spark που εκτελείται μόνο όταν υπάρχουν πάρα πολλά μικρά αρχεία σε έναν πίνακα.
  • Προγραμματίστε περιοδικές OPTIMIZE εργασίες για φόρτους εργασίας όπου ο περιοδικός προστιθέμενος λανθάνων χρόνος από την αυτόματη συμπύκνωση δεν πληροί τις SLA ενημέρωσης δεδομένων.
  • Εκτελέστε VACUUM σύμφωνα με τις απαιτήσεις διατήρησης και ταξιδιού στο χρόνο για να καταργήσετε αρχεία στα οποία δεν αναφέρεται πλέον το αρχείο καταγραφής Delta. VACUUM Μειώνει τον χώρο αποθήκευσης που διατηρείται αλλά δεν βελτιώνει την ενεργή διάταξη αρχείων.
  • Αποφύγετε την κατάτμηση υψηλής πληθικότητας και τις προσαρμοσμένες διαμορφώσεις εγγραφής που δημιουργούν πολλά μικρά αρχεία.

Εάν δεν χρησιμοποιείτε αυτόματη συμπύκνωση, για να εντοπίσετε πίνακες που χρειάζονται συντήρηση, χρησιμοποιήστε μια διοχέτευση δεδομένων και την αποθηκευμένη διαδικασία T-SQL πριν από την sys.sp_get_table_health_metrics εκτέλεση OPTIMIZE. Για ένα πρόγραμμα εκμάθησης, ανατρέξτε στο θέμα Βελτιστοποίηση πινάκων Lakehouse με βάση τους ελέγχους εύρυθμης λειτουργίας.

Σημείωμα

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

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

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

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

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

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

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

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

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

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

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