Οδηγίες επιδόσεων στο Fabric αποθήκη δεδομένων

Ισχύει για:✅ Αποθήκη στο Microsoft Fabric

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

Φιλοδώρημα

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

Για να παρακολουθήσετε την απόδοση στην αποθήκη σας, ανατρέξτε στο θέμα Monitor Fabric Data warehouse.

Επιδόσεις ερωτημάτων

Στατιστικές

Τα στατιστικά στοιχεία είναι μόνιμα αντικείμενα που αντιπροσωπεύουν δεδομένα στις στήλες των πινάκων σας. Η συνάρτηση Βελτιστοποίηση ερωτημάτων χρησιμοποιεί στατιστικά στοιχεία για την επιλογή και εκτίμηση του κόστους ενός σχεδίου ερωτήματος. Το τελικό σημείο ανάλυσης SQL Fabric αποθήκη δεδομένων και Lakehouse χρησιμοποιεί και διατηρεί αυτόματα στατιστικά στοιχεία ιστογράμματος, στατιστικά μέσου μήκους στήλης και στατιστικά στοιχεία πληθικότητας πίνακα. Για περισσότερες πληροφορίες, ανατρέξτε στο θέμα Statistics in Fabric αποθήκη δεδομένων.

  • Οι εντολές CREATE STATISTICS και UPDATE STATISTICS T-SQL υποστηρίζονται για στατιστικά στοιχεία ιστογράμματος μίας στήλης. Μπορείτε να τα αξιοποιήσετε εάν υπάρχει ένα αρκετά μεγάλο παράθυρο μεταξύ των μετασχηματισμών πίνακα και του φόρτου εργασίας του ερωτήματός σας, όπως κατά τη διάρκεια ενός παραθύρου συντήρησης ή άλλου χρόνου εκτός λειτουργίας. Αυτή η προσέγγιση μειώνει την πιθανότητα τα ερωτήματά σας SELECT να πρέπει πρώτα να ενημερώσουν τα στατιστικά στοιχεία.
  • Προσπαθήστε να ορίσετε το σχήμα πίνακα που διατηρεί την ισοτιμία τύπου δεδομένων σε κοινές συγκρίσεις στηλών. Για παράδειγμα, εάν γνωρίζετε ότι οι στήλες συχνά συγκρίνονται μεταξύ τους σε έναν WHERE όρο ή χρησιμοποιούνται ως JOIN ... ON κατηγόρημα, βεβαιωθείτε ότι οι τύποι δεδομένων ταιριάζουν. Εάν δεν είναι δυνατή η χρήση ακριβώς των ίδιων τύπων δεδομένων, χρησιμοποιήστε παρόμοιους τύπους δεδομένων συμβατούς για έμμεση μετατροπή. Αποφύγετε ρητές μετατροπές δεδομένων. Για περισσότερες πληροφορίες, ανατρέξτε στο θέμα Μετατροπή τύπου δεδομένων.

Φιλοδώρημα

Για τους χρήστες του Lakehouse, το ACE-Cardinality στατιστικά στοιχεία μπορεί να χρησιμοποιήσει πληροφορίες από τα αρχεία καταγραφής Delta των πινάκων σας για να είναι πιο ακριβής. Βεβαιωθείτε ότι οι πίνακες Delta που δημιουργήθηκαν από το Spark περιλαμβάνουν τον πίνακα πλήθος γραμμών με: spark.conf.set("spark.databricks.delta.stats.collect", "true"). Για περισσότερες πληροφορίες, ανατρέξτε στο θέμα Ρύθμιση παραμέτρων και διαχείριση αυτοματοποιημένων στατιστικών πινάκων στο Fabric Spark.

Κατά το φιλτράρισμα πινάκων lakehouse στη στήλη χρονικής σήμανσης πριν από τον χρόνο εκτέλεσης Apache Spark 3.5.0, δεν δημιουργούνται στατιστικά στοιχεία επιπέδου ομάδας γραμμών για στήλες χρονικής σήμανσης. Αυτή η έλλειψη στατιστικών στοιχείων καθιστά δύσκολη την εφαρμογή κατάργησης της ομάδας γραμμών από τα συστήματα, όπως η Αποθήκη Fabric (γνωστή και ως παράλειψη δεδομένων ή κατηγόρημα pushdown), που είναι η βελτιστοποίηση των επιδόσεων που παραλείπει τις άσχετες ομάδες γραμμών κατά την εκτέλεση ερωτημάτων. Χωρίς αυτά τα στατιστικά στοιχεία, τα ερωτήματα φιλτραρίσματος που αφορούν στήλες χρονικής σήμανσης μπορεί να χρειαστεί να σαρώσουν περισσότερα δεδομένα, οδηγώντας σε σημαντική υποβάθμιση των επιδόσεων. Μπορείτε να αναβαθμίσετε τον χρόνο εκτέλεσης Apache Spark στο Fabric. Οι εκδόσεις Apache Spark 3.5.0 και νεότερες μπορούν να δημιουργούν στατιστικά στοιχεία επιπέδου ομάδας γραμμών για στήλες χρονικής σήμανσης. Στη συνέχεια, πρέπει να δημιουργήσετε εκ νέου τον πίνακα και να προσλάβετε τα δεδομένα προκειμένου να δημιουργηθούν στατιστικά στοιχεία επιπέδου ομάδας γραμμών.

Επιδόσεις cold cache

Η πρώτη εκτέλεση ενός ερωτήματος στο Fabric αποθήκη δεδομένων μπορεί να είναι απροσδόκητα πιο αργή από τις επόμενες εκτελέσεις. Αυτή η επιβράδυνση είναι γνωστή ως ψυχρή εκκίνηση. Μια ψυχρή εκκίνηση συμβαίνει λόγω δραστηριοτήτων προετοιμασίας ή κλιμάκωσης του συστήματος που προετοιμάζουν το περιβάλλον για επεξεργασία.

Οι εν ψυχρεί εκκινήσεις συνήθως εμφανίζονται όταν:

  • Το σύστημα φορτώνει δεδομένα από το OneLake στη μνήμη, επειδή το ερώτημα αποκτά πρόσβαση σε δεδομένα για πρώτη φορά και τα δεδομένα δεν έχουν ακόμη αποθηκευτεί στο cache.
  • Το σύστημα δημιουργεί αυτόματα τα απαραίτητα στατιστικά στοιχεία , επειδή το ερώτημα αποκτά πρόσβαση στα δεδομένα για πρώτη φορά.
  • Το σύστημα διακόπτει αυτόματα τους κόμβους μετά από κάποια περίοδο αδράνειας για να μειώσει το κόστος και προσθέτει κόμβους ως μέρος της αυτόματης κλιμάκωσης. Η επανάληψη ή η δημιουργία κόμφων συνήθως διαρκεί λιγότερο από ένα δευτερόλεπτο.

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

Η προσωρινή αποθήκευση στη μνήμη και στο δίσκο στο Fabric αποθήκη δεδομένων είναι πλήρως διαφανής και ενεργοποιείται αυτόματα. Η προσωρινή αποθήκευση ελαχιστοποιεί έξυπνα την ανάγκη για απομακρυσμένες αναγνώσεις storage αξιοποιώντας τις τοπικές κρυφές μνήμες. Το Fabric αποθήκη δεδομένων χρησιμοποιεί εκλεπτυσμένα μοτίβα access για να βελτιώσει τις αναγνώσεις δεδομένων από το storage και να αυξήσει την ταχύτητα εκτέλεσης ερωτημάτων. Για περισσότερες πληροφορίες, ανατρέξτε στο θέμα Προσωρινή αποθήκευση στο Fabric αποθήκη δεδομένων.

Μπορείτε να εντοπίσετε φαινόμενα ψυχρής εκκίνησης που προκαλούνται από τη λήψη δεδομένων από απομακρυσμένες storage στη μνήμη, υποβάλλοντας ερώτημα στην προβολή queryinsights.exec_requests_history. Ελέγξτε τη data_scanned_remote_storage_mb στήλη:

  • Μια μη μηδενική τιμή στο data_scanned_remote_storage_mb υποδηλώνει ψυχρή εκκίνηση. Η εκτέλεση του ερωτήματος έλαβε δεδομένα από το OneLake. Οι επόμενες προβολές θα πρέπει να είναι θετικά ταχύτερες σε queryinsights.exec_requests_history.
  • Η μηδενική τιμή είναι data_scanned_remote_storage_mb η τέλεια κατάσταση όπου όλα τα δεδομένα αποθηκεύονται στο cache. Δεν χρειάστηκαν αλλαγές κόμβου ή δεδομένα από το OneLake για την προβολή των αποτελεσμάτων του ερωτήματος.

Σημαντικό

Μην κρίνετε την απόδοση των ερωτημάτων με βάση την πρώτη εκτέλεση. Να ελέγχετε data_scanned_remote_storage_mb πάντα για να προσδιορίσετε εάν το ερώτημα επηρεάζεται από την ψυχρή εκκίνηση. Οι επόμενες εκτελέσεις είναι συχνά σημαντικά ταχύτερες και είναι αντιπροσωπευτικές της πραγματικής απόδοσης, γεγονός που μειώνει τον μέσο χρόνο εκτέλεσης.

Ερωτήματα σε πίνακες με στήλες συμβολοσειρών

Χρησιμοποιήστε το μικρότερο μήκος στήλης συμβολοσειράς που μπορεί να χωρέσει τιμές. Το Fabric Warehouse βελτιώνεται συνεχώς. Ωστόσο, ενδέχεται να αντιμετωπίσετε μη βέλτιστες επιδόσεις εάν χρησιμοποιείτε μεγάλους τύπους δεδομένων συμβολοσειράς, ιδιαίτερα μεγάλα αντικείμενα (LOB). Για παράδειγμα, για τον τύπο δεδομένων μιας customer_name στήλης, εξετάστε τις απαιτήσεις της επιχείρησής σας και τα αναμενόμενα δεδομένα και χρησιμοποιήστε ένα κατάλληλο μήκος n κατά τη varchar(n)δήλωση , όπως varchar(100), αντί για varchar(8000) ή varchar(μέγιστο). Τα στατιστικά στοιχεία και η εκτίμηση κόστους ερωτημάτων είναι πιο ακριβή όταν το μήκος του τύπου δεδομένων είναι πιο ακριβές στα πραγματικά δεδομένα.

  • Στο Fabric αποθήκη δεδομένων T-SQL, ανατρέξτε στην οδηγίες για την επιλογή του κατάλληλου μήκους για τύπους δεδομένων συμβολοσειράς.
  • Οι στήλες συμβολοσειράς πίνακα Lakehouse χωρίς καθορισμένο μήκος στο Spark αναγνωρίζονται από την Fabric Warehouse ως varchar(8000). Για βέλτιστες επιδόσεις, χρησιμοποιήστε την CREATE TABLE πρόταση στο SparkSQL για να ορίσετε τη στήλη συμβολοσειράς ως varchar(n), όπου n το μέγιστο μήκος στήλης μπορεί να χωρέσει τιμές.

Συναλλαγές και ταυτόχρονη εκτέλεση

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

Το Fabric αποθήκη δεδομένων υποστηρίζει συναλλαγές συμβατές με ACID χρησιμοποιώντας απομόνωση στιγμιότυπου. Αυτό σημαίνει:

  • Οι λειτουργίες ανάγνωσης και εγγραφής μπορούν να ομαδοποιηθούν σε μία συναλλαγή χρησιμοποιώντας την τυπική T-SQL (BEGIN TRANSACTION, COMMIT, ROLLBACK)
  • Σημασιολογία "Όλα ή τίποτα": Εάν μια συναλλαγή εκτείνεται σε πολλούς πίνακες και αποτύχει μία λειτουργία, πραγματοποιείται επαναφορά ολόκληρης της συναλλαγής.
  • Συνέπεια ανάγνωσης: SELECT τα ερωτήματα μέσα σε μια συναλλαγή βλέπουν ένα συνεπές στιγμιότυπο των δεδομένων, που δεν επηρεάζεται από ταυτόχρονες εγγραφές.

Υποστήριξη συναλλαγών Fabric Warehouse:

  • Data Definition Language (DDL) μέσα σε συναλλαγές: Μπορείτε να συμπεριλάβετε CREATE TABLE μέσα σε ένα μπλοκ συναλλαγών.
  • Συναλλαγές μεταξύ βάσεων δεδομένων: Υποστηρίζεται στον ίδιο χώρο εργασίας, συμπεριλαμβανομένων των αναγνώσεων από τελικά σημεία ανάλυσης SQL.
  • επαναφορά βάσει παρκέ: Δεδομένου ότι το Fabric αποθήκη δεδομένων αποθηκεύει δεδομένα σε αμετάβλητα αρχεία Parquet, οι επαναφορές είναι γρήγορες. Οι επαναροές απλώς επανέρχονται στις προηγούμενες εκδόσεις αρχείων.
  • Αυτόματη συμπύκνωση δεδομένων και σημείο ελέγχου:Συμπύκνωση δεδομένων βελτιστοποιεί την απόδοση storage και ανάγνωσης συγχωνεύοντας μικρά αρχεία Parquet και αφαιρώντας λογικά διαγραμμένες σειρές.
  • Αυτόματο σημείο ελέγχου: Κάθε λειτουργία εγγραφής (INSERT, UPDATE, DELETE) προσαρτά ένα νέο αρχείο καταγραφής JSON στο αρχείο καταγραφής συναλλαγών Delta Lake. Με την πάροδο του χρόνου, αυτό μπορεί να οδηγήσει σε εκατοντάδες ή χιλιάδες αρχεία καταγραφής, ειδικά σε σενάρια ροής ή πρόσληψης υψηλής συχνότητας. Το αυτόματο σημείο ελέγχου βελτιώνει την αποδοτικότητα ανάγνωσης μετα-δεδομένων συνοψίζοντας τα αρχεία καταγραφής συναλλαγών σε ένα ενιαίο αρχείο σημείου ελέγχου. Χωρίς σημείο ελέγχου, κάθε ανάγνωση πρέπει να σκανάρει ολόκληρο το ιστορικό του αρχείου καταγραφής συναλλαγών. Με το σημείο ελέγχου, τα μόνα αρχεία καταγραφής που διαβάζονται είναι το πιο πρόσφατο αρχείο σημείου ελέγχου και τα αρχεία καταγραφής μετά από αυτό. Αυτό μειώνει σε μεγάλο βαθμό την ανάλυση μετα-δεδομένων και I/O, ιδιαίτερα για μεγάλους ή συχνά ενημερωμένους πίνακες.

Τόσο η συμπίεση όσο και το σημείο ελέγχου είναι κρίσιμα για την υγεία των πινάκων, ειδικά σε περιβάλλοντα μακράς διαρκείας ή υψηλής ταυτόχρονης εκτέλεσης.

Έλεγχος και απομόνωση ταυτόχρονης εκτέλεσης

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

Βέλτιστες πρακτικές με συναλλαγές

  • Χρησιμοποιήστε με σύνεση τις ρητές συναλλαγές. Πάντα COMMIT ή ROLLBACK. Μην αφήνετε ανοιχτές τις συναλλαγές.
    • Διατηρήστε τις συναλλαγές βραχύβιες. Αποφύγετε συναλλαγές μεγάλης διάρκειας που περιέχουν λουκέτο χωρίς λόγο, ιδιαίτερα για ρητές συναλλαγές που περιέχουν DDL. Αυτό μπορεί να προκαλέσει διαμάχη με SELECT προτάσεις σε προβολές καταλόγου συστήματος (όπως sys.tables) και μπορεί να προκαλέσει προβλήματα με την πύλη Fabric που βασίζονται σε προβολές καταλόγου συστήματος.
  • Προσθέστε λογική επανάληψης με καθυστέρηση σε pipelines ή εφαρμογές για να χειριστείτε παροδικές διενέξεις.
    • Χρησιμοποιήστε εκθετική επιστροφή για να αποφύγετε τις επαναληπτικές καταιγίδες που επιδεινώνουν τις προσωρινές διακοπές του δικτύου.
    • Για περισσότερες πληροφορίες, ανατρέξτε στην ενότητα Επανάληψη μοτίβου.
  • Παρακολούθηση κλειδώματος και διενέξεων στην αποθήκη.
    • Χρησιμοποιήστε sys.dm_tran_locks για να ελέγξετε τις τρέχουσες κλειδαριές.

Μείωση των μεγεθών συνόλου δεδομένων που επιστρέφονται

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

  • Διαμέρισμα ή σύμπλεγμα (Liquid Clustering) μεγάλα τραπέζια στο Lakehouse.
  • Περιορίστε τον αριθμό των στηλών που επιστρέφονται. SELECT * μπορεί να είναι δαπανηρό.
  • Περιορίστε τον αριθμό των γραμμών που επιστρέφονται. Εκτελέστε όσο το δυνατόν μεγαλύτερο φιλτράρισμα δεδομένων στην αποθήκη, όχι σε εφαρμογές-πελάτες.
    • Προσπαθήστε να φιλτράρετε πριν από τη συμμετοχή σας για να μειώσετε το σύνολο δεδομένων νωρίς στην εκτέλεση του ερωτήματος.
    • Φιλτράρετε σε στήλες χαμηλής πληθικότητας για να μειώσετε το μεγάλο σύνολο δεδομένων νωρίς πριν από το JOIN.
    • Οι στήλες με υψηλή πληθικότητα είναι ιδανικές για φιλτράρισμα και JOIN. Αυτές χρησιμοποιούνται συχνά σε WHERE όρους και επωφελούνται από την εφαρμογή κατηγορημάτων σε προηγούμενο στάδιο στην εκτέλεση ερωτημάτων για φιλτράρισμα δεδομένων.
  • Στο Fabric αποθήκη δεδομένων, δεδομένου ότι οι περιορισμοί πρωτεύοντος κλειδιού και μοναδικού κλειδιού δεν επιβάλλονται, οι στήλες με αυτούς τους περιορισμούς δεν είναι απαραίτητα καλοί υποψήφιοι για JOIN.

Προγράμματα ερωτημάτων και συμβουλές ερωτημάτων

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

  • Οι χρήστες μπορούν να χρησιμοποιήσουν το SHOWPLAN_XML στο SQL Server Management Studio για να προβάλουν το σχέδιο χωρίς να εκτελέσουν το ερώτημα.
  • Προαιρετικές συμβουλές ερωτήματος μπορούν να προστεθούν σε μια πρόταση SQL για την παροχή περισσότερων οδηγιών στη βελτιστοποίηση ερωτημάτων πριν από τη δημιουργία σχεδίου. Η προσθήκη συμβουλών ερωτήματος απαιτεί προηγμένες γνώσεις των φόρτων εργασίας ερωτημάτων, επομένως, συνήθως χρησιμοποιούνται μετά την υλοποίηση άλλων βέλτιστων πρακτικών, αλλά το πρόβλημα παραμένει.

Λειτουργίες χωρίς δυνατότητα κλιμάκωσης

Το Fabric αποθήκη δεδομένων βασίζεται σε μια αρχιτεκτονική μαζικής παράλληλης επεξεργασίας (MPP), όπου τα ερωτήματα εκτελούνται σε πολλούς υπολογιστικούς κόμβους. Σε ορισμένα σενάρια, δικαιολογείται η εκτέλεση ενός κόμβου:

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

Σε αυτές τις περιπτώσεις, οι χρήστες μπορούν να λάβουν ένα προειδοποιητικό μήνυμα "Εντοπίστηκε μία ή περισσότερες λειτουργία χωρίς δυνατότητα κλιμάκωσης" και το ερώτημα ενδέχεται να εκτελεστεί αργά ή να αποτύχει μετά από μια μεγάλη εκτέλεση.

  • Εξετάστε το ενδεχόμενο μείωσης του μεγέθους του φιλτραρισμένου συνόλου δεδομένων του ερωτήματος.
  • Εάν η σημασιολογία του ερωτήματος δεν απαιτεί εκτέλεση ενός κόμβου, δοκιμάστε να εξαναγκάσουμε ένα σχέδιο κατανεμημένου ερωτήματος με το FORCE DISTRIBUTED PLAN, για παράδειγμα OPTION (FORCE DISTRIBUTED PLAN);.

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

Μπορείτε να χρησιμοποιήσετε το τελικό σημείο ανάλυσης SQL για να υποβάλετε ερωτήματα σε πίνακες Lakehouse που έχουν συμπληρωθεί με Spark SQL, χωρίς αντιγραφή ή πρόσληψη δεδομένων στην Αποθήκη.

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

Φιλοδώρημα

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

Εκτέλεση τακτικής συντήρησης πίνακα για πίνακες Lakehouse

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

Βελτιστοποίηση πινάκων lakehouse ή συντομεύσεων με πολλά μικρά αρχεία

Η ύπαρξη πολλών μικρών αρχείων δημιουργεί επιβάρυνση για την ανάγνωση μετα-δεδομένων αρχείου. Χρησιμοποιήστε την εντολή ΒΕΛΤΙΣΤΟΠΟΊΗΣΗ στην πύλη Fabric ή σε ένα Σημειωματάριο για να συνδυάσετε μικρά αρχεία σε μεγαλύτερα. Επαναλάβετε αυτήν τη διαδικασία όταν ο αριθμός των αρχείων αλλάζει σημαντικά.

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

Πίνακες ή συντομεύσεις της λίμνης ερωτημάτων που βρίσκονται στην ίδια περιοχή

Το Fabric χρησιμοποιεί υπολογιστικό υπολογισμό όπου βρίσκεται το σύνολο εκχωρημένων πόρων Fabric. Η υποβολή ερωτημάτων σε δεδομένα, όπως στο δικό σας Azure Data Lake Storage ή στο OneLake, σε μια άλλη περιοχή έχει ως αποτέλεσμα επιβάρυνση επιδόσεων λόγω λανθάνοντος χρόνου δικτύου. Βεβαιωθείτε ότι τα δεδομένα βρίσκονται στην ίδια περιοχή. Ανάλογα με τις απαιτήσεις επιδόσεων σας, εξετάστε το ενδεχόμενο να διατηρήσετε μόνο μικρούς πίνακες όπως πίνακες διαστάσεων σε μια απομακρυσμένη περιοχή.

Φιλτράρισμα πινάκων λιμνών και συντομεύσεων στις ίδιες στήλες

Εάν φιλτράρετε συχνά γραμμές πίνακα σε συγκεκριμένες στήλες, εξετάστε το ενδεχόμενο να κάνετε διαμερισμό του πίνακα.

Ο διαμερισμό λειτουργεί καλά για στήλες ή στήλες χαμηλής πληθικότητας με προβλέψιμη πληθικότητα, όπως έτη ή ημερομηνίες. Για περισσότερες πληροφορίες, ανατρέξτε στο εκπαιδευτικό βοήθημα Lakehouse - Προετοιμασία και μετασχηματισμός δεδομένων lakehouse και Φόρτωση δεδομένων στο Lakehouse με χρήση διαμερίσματος.

Η δημιουργία συμπλέγματος λειτουργεί καλά για στήλες υψηλής επιλογότητας. Εάν έχετε άλλες στήλες που χρησιμοποιείτε συχνά για φιλτράρισμα, εκτός από τον διαμερισμό στηλών, εξετάστε το ενδεχόμενο δημιουργίας συμπλέγματος του πίνακα χρησιμοποιώντας τη βελτιστοποίηση με τη σύνταξη ZORDER BYSpark SQL . Για περισσότερες πληροφορίες, ανατρέξτε στο θέμα Βελτιστοποίηση πίνακα Delta Lake.

Ομαδοποίηση δεδομένων

Μπορείτε επίσης να πραγματοποιήσετε ομαδοποίηση δεδομένων σε συγκεκριμένες στήλες στις CREATE TABLE προτάσεις T-SQL και CREATE TABLE AS SELECT (CTAS). Η ομαδοποίηση δεδομένων λειτουργεί αποθηκεύοντας σειρές με παρόμοιες τιμές σε παρακείμενες θέσεις στο storage κατά τη διάρκεια της πρόσληψης.

  • Η ομαδοποίηση δεδομένων χρησιμοποιεί μια καμπύλη πλήρωσης χώρου για την οργάνωση των δεδομένων με τρόπο που διατηρεί την τοποθεσία σε πολλές διαστάσεις, πράγμα που σημαίνει ότι οι γραμμές με παρόμοιες τιμές σε στήλες ομαδοποίησης αποθηκεύονται φυσικά κοντά μεταξύ τους. Αυτή η προσέγγιση βελτιώνει δραματικά την απόδοση του ερωτήματος εκτελώντας παράλειψη αρχείων και μειώνοντας τον αριθμό των αρχείων που σαρώνονται.
  • Τα μεταδεδομένα ομαδοποίησης δεδομένων ενσωματώνονται στη διακήρυξη κατά την πρόσληψη, επιτρέποντας στη μηχανή αποθήκης να λαμβάνει έξυπνες αποφάσεις σχετικά με τα αρχεία στα οποία θα έχει access κατά τη διάρκεια των ερωτημάτων των χρηστών. Αυτά τα μετα-δεδομένα, σε συνδυασμό με τον τρόπο αποθήκευσης γραμμών με παρόμοιες τιμές, εξασφαλίζουν ότι τα ερωτήματα με κατηγορήματα φίλτρου μπορούν να παραλείψουν ολόκληρα αρχεία και ομάδες γραμμών που δεν εμπίπτουν στο πεδίο του κατηγορήματος.

Για παράδειγμα: εάν ένα ερώτημα στοχεύει μόνο το 10% των δεδομένων ενός πίνακα, η δημιουργία συμπλέγματος εξασφαλίζει ότι σαρώνονται μόνο τα αρχεία που περιέχουν τα δεδομένα εντός της περιοχής του φίλτρου, μειώνοντας την κατανάλωση εισόδου/εξόδου και υπολογισμού. Οι μεγαλύτεροι πίνακες επωφελούνται περισσότερο από την ομαδοποίηση δεδομένων, καθώς τα οφέλη της παράβλεψης αρχείων κλιμακώνονται με τον όγκο δεδομένων.

Βελτιστοποίηση τύπου δεδομένων

Η επιλογή των σωστών τύπων δεδομένων είναι απαραίτητη για την απόδοση και την αποδοτικότητα της storage στην αποθήκη σας. Οι ακόλουθες οδηγίες βοηθούν να διασφαλίσετε ότι ο σχεδιασμός του σχήματός σας υποστηρίζει γρήγορα ερωτήματα, αποτελεσματική storage και συντηρησιμότητα.

Για περισσότερες πληροφορίες σχετικά με τους τύπους δεδομένων που υποστηρίζονται από το Fabric αποθήκη δεδομένων, ανατρέξτε στο θέμα Τύποι δεδομένων στο Fabric αποθήκη δεδομένων.

Φιλοδώρημα

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

Αντιστοίχιση τύπων δεδομένων με τη σημασιολογία δεδομένων

Για να διασφαλίσετε τόσο τη clarity όσο και την απόδοση, είναι σημαντικό να ευθυγραμμίσετε τον τύπο δεδομένων κάθε στήλης με την πραγματική φύση και συμπεριφορά των δεδομένων που αποθηκεύει.

  • Χρησιμοποιήστε την ημερομηνία, ώρα ή datetime2(n) για χρονικές τιμές αντί για την αποθήκευσή τους ως συμβολοσειρές.
  • Χρησιμοποιήστε ακέραιους τύπους για αριθμητικές τιμές, εκτός εάν απαιτείται μορφοποίηση (για παράδειγμα, αρχικά μηδενικά).
  • Χρησιμοποιήστε τύπους χαρακτήρων (char, varchar) όταν η διατήρηση της μορφοποίησης είναι απαραίτητη (για παράδειγμα, αριθμοί που μπορούν να ξεκινήσουν με μηδέν, κωδικούς προϊόντων, αριθμούς με παύλες).

Χρήση ακέραιων τύπων για ακέραιους αριθμούς

Κατά την αποθήκευση τιμών όπως αναγνωριστικά, μετρητές ή άλλους ακέραιους αριθμούς, προτιμήστε τους ακέραιους τύπους (smallint, int, bigint) αντί για τους δεκαδικούς/αριθμούς. Οι ακέραιοι τύποι απαιτούν λιγότερο storage από τους τύπους δεδομένων που επιτρέπουν ψηφία στα δεξιά της υποδιαστολής. Κατά συνέπεια, επιτρέπουν ταχύτερες λειτουργίες αριθμητικών και σύγκρισης και βελτιώνουν την απόδοση ευρετηρίου και ερωτημάτων.

Λάβετε υπόψη τις περιοχές τιμών για κάθε τύπο ακέραιων δεδομένων που υποστηρίζεται από το Fabric αποθήκη δεδομένων. Για περισσότερες πληροφορίες, int, bigint, smallint (Transact-SQL).

Εξετάστε τη χρήση δεκαδικής και αριθμητικής ακρίβειας και κλίμακας

Εάν πρέπει να χρησιμοποιήσετε δεκαδικά/ψηφία, κατά τη δημιουργία της στήλης επιλέξτε τη μικρότερη ακρίβεια και κλίμακα που μπορεί να χωρέσει τα δεδομένα σας. Η ακρίβεια over-provisioning αυξάνει τις απαιτήσεις storage και μπορεί να υποβαθμίσει την απόδοση καθώς αυξάνονται τα δεδομένα.

  • Αναμένετε την αναμενόμενη ανάπτυξη και ανάγκες της αποθήκης σας. Για παράδειγμα, εάν σκοπεύετε να αποθηκεύσετε όχι περισσότερα από τέσσερα ψηφία στα δεξιά της υποδιαστολής, χρησιμοποιήστε decimal(9,4) ή decimal(19,4) για πιο αποτελεσματική storage.
  • Να καθορίζετε πάντα ακρίβεια και κλίμακα κατά τη δημιουργία μιας δεκαδικής/αριθμητικής στήλης. Όταν δημιουργείται σε έναν πίνακα που ορίζεται ως μόλις decimal, χωρίς να καθορίζεται (p,s) για ακρίβεια και κλίμακα, δημιουργείται μια δεκαδική/αριθμητική στήλη ως decimal(18,0). Ένα δεκαδικό με ακρίβεια 18 καταναλώνει 9 byte storage ανά σειρά. Μια κλίμακα 0 δεν αποθηκεύει δεδομένα στα δεξιά της υποδιαστολής. Για πολλούς ακέραιους αριθμούς επιχειρήσεων, smallint, int, bigint είναι πολύ πιο αποδοτικό από decimal(18,0). Για παράδειγμα, οποιοσδήποτε εννιαψήφιος ακέραιος αριθμός μπορεί να αποθηκευτεί ως τύπος δεδομένων ακέραιος για 4 byte storage ανά σειρά.

Για πλήρεις πληροφορίες, ανατρέξτε στο θέμα Δεκαδικά και αριθμητικά (Transact-SQL).

Εξετάστε πότε πρέπει να χρησιμοποιήσετε το varchar πάνω από char

Χρησιμοποιήστε τη συνάρτηση varchar(n) αντί του char(n) για τις στήλες συμβολοσειρών, εκτός εάν απαιτείται ρητά αναπλήρωση σταθερού μήκους. Μια στήλη varchar αποθηκεύει μόνο το πραγματικό μήκος συμβολοσειράς ανά γραμμή, καθώς και μια μικρή επιβάρυνση και μειώνει τον χαμένο χώρο, το οποίο βελτιώνει την αποδοτικότητα I/O.

  • Χρησιμοποιήστε τη συνάρτηση varchar(n) για τιμές όπως ονόματα, διευθύνσεις και περιγραφές, καθώς έχουν ευρέως μεταβλητές τιμές. Τα στατιστικά στοιχεία και η εκτίμηση κόστους ερωτημάτων είναι πιο ακριβή όταν το μήκος του τύπου δεδομένων είναι πιο ακριβές στα πραγματικά δεδομένα.
  • Χρησιμοποιήστε το char(n) όταν γνωρίζετε ότι η συμβολοσειρά θα είναι σταθερό μήκος κάθε φορά. Για παράδειγμα, η αποθήκευση της συμβολοσειράς 000000000 ως char(9) έχει νόημα αν η συμβολοσειρά αποτελείται πάντα από 9 αριθμητικούς χαρακτήρες που μπορούν να ξεκινούν με μηδέν.
  • Το μήκος n στη δήλωση τύπου δεδομένων στήλης είναι τα storage byte. Για σύνολα χαρακτήρων κωδικοποίησης πολλών byte όπως το UTF-8, η κωδικοποίηση για το Fabric αποθήκη δεδομένων, οι λατινικοί χαρακτήρες και οι αριθμοί καταλαμβάνουν 1 byte storage. Ωστόσο, υπάρχουν χαρακτήρες Unicode που απαιτούν περισσότερα από 1 byte, όπως ιαπωνικούς χαρακτήρες που απαιτούν 3 byte για την αποθήκευση, επομένως, ο αριθμός των χαρακτήρων Unicode που αποθηκεύονται στην πραγματικότητα μπορεί να είναι μικρότερος από το μήκος nτου τύπου δεδομένων . Για περισσότερες πληροφορίες, ανατρέξτε στα ορίσματα char και varchar.

Αποφύγετε στήλες που επιδέχονται τιμές null όταν είναι δυνατό

Καθορίστε τις στήλες όπως NOT NULL το επιτρέπει το μοντέλο δεδομένων. Από προεπιλογή, μια στήλη σε έναν πίνακα επιτρέπει NULL τιμές. Οι στήλες που επιδέχονται τιμές null έχουν τα ακόλουθα χαρακτηριστικά:

  • Προσθέτουν γενικά μετα-δεδομένα.
  • Μπορεί να μειώσει την αποτελεσματικότητα των βελτιστοποιήσεων ερωτημάτων και στατιστικών.
  • Μπορεί να επηρεάσει τις επιδόσεις σε αναλυτικά ερωτήματα μεγάλης κλίμακας.

Πρόσληψη δεδομένων και προετοιμασία σε μια αποθήκη

ΑΝΤΙΓΡΑΦΗ ΣΤΟ

Η εντολή T-SQL COPY IN είναι ο συνιστώμενος τρόπος για την πρόσληψη δεδομένων από Azure Data Lake Storage στο Fabric αποθήκη δεδομένων. Για περισσότερες πληροφορίες και παραδείγματα, ανατρέξτε στο θέμα Πρόσληψη δεδομένων στην Αποθήκη σας χρησιμοποιώντας την πρόταση COPY.

Εξετάστε τις παρακάτω προτάσεις για βέλτιστες επιδόσεις:

  • Μέγεθος αρχείου: Βεβαιωθείτε ότι κάθε αρχείο που προσλαμβάνεται είναι ιδανικά μεταξύ 100 MB και 1 GB για μεγιστοποιημένη ταχύτητα μετάδοσης. Αυτό βοηθά στη βελτιστοποίηση της διαδικασίας πρόσληψης και τη βελτίωση των επιδόσεων.
  • Αριθμός αρχείων: Για μεγιστοποίηση της παράλληλης εκτέλεσης και των επιδόσεων ερωτημάτων, επιδιώξτε τη δημιουργία μεγάλου αριθμού αρχείων. Δώστε προτεραιότητα στη δημιουργία όσο το δυνατόν περισσότερα αρχεία, διατηρώντας παράλληλα ένα ελάχιστο μέγεθος αρχείου 100 MB.
  • Παράλληλη φόρτωση: Χρησιμοποιήστε πολλαπλές COPY INTO προτάσεις που εκτελούνται παράλληλα για τη φόρτωση δεδομένων σε διαφορετικούς πίνακες. Αυτή η προσέγγιση μπορεί να μειώσει σημαντικά το παράθυρο ETL/ELT λόγω παραλληλισμού.
  • Μέγεθος εκχωρημένων πόρων: Για μεγαλύτερους όγκους δεδομένων, εξετάστε το ενδεχόμενο κλιμάκωσης σε μεγαλύτερους Εκχωρημένους πόρους Fabric για να λάβετε τους πρόσθετους υπολογιστικούς πόρους που απαιτούνται για την εξυπηρέτηση πρόσθετου αριθμού παράλληλης επεξεργασίας και μεγαλύτερων όγκων δεδομένων.

Το Fabric αποθήκη δεδομένων υποστηρίζει επίσης δήλωση BULK INSERT που είναι συνώνυμο του COPY INTO. Η ίδια σύσταση ισχύει για BULK INSERT πρόταση.

CTAS ή ΕΙΣΑΓΩΓΉ

Χρησιμοποιήστε CREATE TABLE AS SELECT (CTAS) ή INSERT σε συνδυασμό με εντολές πίνακα/συντόμευσης SELECT FROM Lakehouse. Αυτές οι μέθοδοι θα μπορούσαν να είναι πιο αποδοτικές και αποδοτικές από τη χρήση pipelines, επιτρέποντας ταχύτερες και πιο αξιόπιστες μεταφορές δεδομένων. Για περισσότερες πληροφορίες και παραδείγματα, ανατρέξτε στο θέμα Πρόσληψη δεδομένων στην Αποθήκη σας χρησιμοποιώντας Transact-SQL.

Η έννοια της αύξησης του αριθμού παραλληλισμού και κλιμάκωσης σε μεγαλύτερους Εκχωρημένους πόρους Fabric ισχύει επίσης για λειτουργίες CTAS/ΕΙΣΑΓΩΓΉ για την αύξηση της ταχύτητας.

Ανάγνωση δεδομένων από το Azure Data Lake Storage ή το Blob Storage με το OPENROWSET

Η λειτουργία OPENROWSET σάς επιτρέπει να διαβάζετε αρχεία CSV ή Parquet από Azure Data Lake ή Azure Blob storage, χωρίς να τα απορροφάτε στην Αποθήκη. Για περισσότερες πληροφορίες και παραδείγματα, ανατρέξτε στο θέμα Αναζήτηση περιεχομένου αρχείου με χρήση της συνάρτησης OPENROWSET.

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

Κατά την ανάγνωση δεδομένων με χρήση της συνάρτησης OPENROWSET, λάβετε υπόψη τις παρακάτω προτάσεις για βέλτιστες επιδόσεις:

  • Παρκέ: Δοκιμάστε να χρησιμοποιήσετε το Parquet αντί για το CSV ή μετατρέψτε το CSV σε Parquet, εάν εκτελείτε συχνά ερωτήματα για τα αρχεία. Το Parquet είναι σε μορφή στήλης. Επειδή τα δεδομένα συμπιέζονται, τα μεγέθη αρχείων του είναι μικρότερα από τα αρχεία CSV που περιέχουν τα ίδια δεδομένα. Το Fabric αποθήκη δεδομένων παραλείπει τις στήλες και τις γραμμές που δεν χρειάζονται σε ένα ερώτημα, εάν διαβάζετε αρχεία Parquet.
  • Μέγεθος αρχείου: Βεβαιωθείτε ότι κάθε αρχείο που προσλαμβάνεται είναι ιδανικά μεταξύ 100 MB και 1 GB για μεγιστοποιημένη ταχύτητα μετάδοσης. Αυτό βοηθά στη βελτιστοποίηση της διαδικασίας πρόσληψης και τη βελτίωση των επιδόσεων. Είναι προτιμότερο να έχετε αρχεία ίσου μεγέθους.
  • Αριθμός αρχείων: Για μεγιστοποίηση της παράλληλης εκτέλεσης και των επιδόσεων ερωτημάτων, επιδιώξτε τη δημιουργία μεγάλου αριθμού αρχείων. Δώστε προτεραιότητα στη δημιουργία όσο το δυνατόν περισσότερα αρχεία, διατηρώντας παράλληλα ένα ελάχιστο μέγεθος αρχείου 100 MB.
  • Χώρισμα: Κάντε διαμερισμό των δεδομένων σας αποθηκεύοντας διαμερίσματα σε διαφορετικούς φακέλους ή ονόματα αρχείων, εάν ο φόρτος εργασίας σας τα φιλτράρει κατά στήλες διαμερίσματος.
  • Εκτίμηση: Προσπαθήστε να ορίσετε ROWS_PER_BATCH τον αριθμό των γραμμών στα υποκείμενα αρχεία, εάν πιστεύετε ότι δεν λαμβάνετε τις αναμενόμενες επιδόσεις.
  • Μέγεθος εκχωρημένων πόρων: Για μεγαλύτερους όγκους δεδομένων, εξετάστε το ενδεχόμενο κλιμάκωσης σε μεγαλύτερο SKU για να λάβετε περισσότερους υπολογιστικούς πόρους που απαιτούνται για να εξυπηρετήσετε επιπλέον αριθμό παράλληλης επεξεργασίας και μεγαλύτερους όγκους δεδομένων.

Αποφυγή εισαγωγής, ενημερώσεων και διαγραφών

Για να εξασφαλίσετε αποτελεσματική διάταξη αρχείων και βέλτιστη απόδοση ερωτημάτων στο Fabric αποθήκη δεδομένων, αποφύγετε τη χρήση πολλών μικρών συναλλαγών INSERT, UPDATE και DELETE. Αυτές οι αλλαγές σε επίπεδο γραμμών δημιουργούν ένα νέο αρχείο Parquet για κάθε λειτουργία, με αποτέλεσμα ένα μεγάλο αριθμό μικρών αρχείων και κατακερματισμένων ομάδων γραμμών. Αυτός ο κατακερματισμός οδηγεί σε:

  • Αυξημένος λανθάνων χρόνος ερωτήματος λόγω μη αποδοτικής σάρωσης αρχείων.
  • Υψηλότερο κόστος storage και υπολογισμού.
  • Μεγαλύτερη εξάρτηση από διαδικασίες συμπύκνωσης φόντου.

Προτεινόμενες προσεγγίσεις:

  • Μαζικές συναλλαγές που εγγράφονται στο Fabric αποθήκη δεδομένων.
    • Για παράδειγμα, αντί για πολλές μικρές INSERT προτάσεις, τα δεδομένα προ-σταδίου μαζί και την εισαγωγή δεδομένων σε μία INSERT πρόταση.
  • Χρησιμοποιήστε την ΑΝΤΙΓΡΑΦΉ ΣΤΟ για μαζικές εισαγωγές και εκτελέστε ενημερώσεις και διαγραφές σε δέσμες όποτε αυτό είναι εφικτό.
  • Διατηρήστε ένα ελάχιστο εισαγόμενο μέγεθος αρχείου 100 MB για να εξασφαλίσετε αποδοτική δημιουργία ομάδας γραμμών.
  • Για περισσότερες οδηγίες και βέλτιστες πρακτικές σχετικά με την πρόσληψη δεδομένων, ανατρέξτε στο θέμα Βέλτιστες πρακτικές πρόσληψης δεδομένων σε μια αποθήκη.

Συμπύκνωση δεδομένων

Στο Fabric αποθήκη δεδομένων, η συμπίεση δεδομένων είναι μια διαδικασία βελτιστοποίησης παρασκηνίου που συγχωνεύει μικρά, αναποτελεσματικά αρχεία Parquet σε λιγότερα, μεγαλύτερα αρχεία. Συχνά, αυτά τα αρχεία δημιουργούνται από συχνές INSERTUPDATEλειτουργίες , ή DELETE . Η συμπύκνωση δεδομένων μειώνει τον κατακερματισμό του αρχείου, βελτιώνει την αποτελεσματικότητα της ομάδας γραμμών και βελτιώνει τις συνολικές επιδόσεις του ερωτήματος.

Παρόλο που ο μηχανισμός Fabric αποθήκη δεδομένων επιλύει αυτόματα τον κατακερματισμό με την πάροδο του χρόνου μέσω της συμπίεσης δεδομένων, οι επιδόσεις ενδέχεται να υποβαθμιστούν μέχρι να ολοκληρωθεί η διαδικασία. Η συμπίεση δεδομένων εκτελείται αυτόματα χωρίς παρέμβαση του χρήστη για το Fabric αποθήκη δεδομένων.

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

Πρόληψη συμπίεσης δεδομένων

Το Fabric αποθήκη δεδομένων αποφεύγει έξυπνα και ενεργά τις διενέξεις εγγραφής-εγγραφής μεταξύ εργασιών συμπίεσης παρασκηνίου και λειτουργιών χρήστη. Από τον Οκτώβριο του 2025, ενεργοποιείται η πρόληψη συμπίεσης δεδομένων.

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

Οι διενέξεις εγγραφής-εγγραφής με την υπηρεσία συμπίεσης δεδομένων παρασκηνίου του Fabric αποθήκη δεδομένων εξακολουθούν να είναι δυνατές. Είναι δυνατό να δημιουργηθεί μια διένεξη εγγραφής-εγγραφής με συμπίεση δεδομένων, για παράδειγμα, εάν μια εφαρμογή χρησιμοποιεί μια ρητή συναλλαγή και εκτελεί εργασίες χωρίς διένεξη (όπως INSERT) πριν από μια λειτουργία σε διένεξη (UPDATE, DELETE, MERGE). Η συμπίεση δεδομένων μπορεί να δεσμευτεί με επιτυχία, προκαλώντας αργότερα την αποτυχία της ρητής συναλλαγής λόγω διένεξης. Για περισσότερες πληροφορίες σχετικά με τις διενέξεις εγγραφής-εγγραφής ή ενημέρωσης, ανατρέξτε στην ενότητα Κινήσεις σε πίνακες αποθήκης στο Microsoft Fabric.

V-Order στο Fabric αποθήκη δεδομένων

Το V-Order είναι μια βελτιστοποίηση χρόνου εγγραφής στη μορφή αρχείου parquet που επιτρέπει γρήγορες αναγνώσεις σε Microsoft Fabric. Το V-Order στο Fabric αποθήκη δεδομένων βελτιώνει την απόδοση των ερωτημάτων εφαρμόζοντας ταξινόμηση και συμπίεση σε αρχεία πίνακα.

Από προεπιλογή, η σειρά V ενεργοποιείται σε όλες τις αποθήκες για να εξασφαλιστεί ότι οι λειτουργίες ανάγνωσης, ιδιαίτερα τα αναλυτικά ερωτήματα, είναι όσο το δυνατόν ταχύτερες και αποτελεσματικές.

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

Προτού αποφασίσουν να απενεργοποιήσουν την παραγγελία V, οι χρήστες θα πρέπει να ελέγξουν διεξοδικά τις επιδόσεις του φόρτου εργασίας τους για να διασφαλίσουν ότι δικαιολογείται η ανταλλαγή. Ένα συνηθισμένο μοτίβο είναι η χρήση μιας αποθήκης προεργασίας με απενεργοποιημένο το V-Order για πρόσληψη υψηλής απόδοσης, μετασχηματισμό δεδομένων και πρόσληψη των υποκείμενων δεδομένων σε μια αποθήκη δεδομένων με δυνατότητα V-Order για καλύτερη απόδοση ανάγνωσης. Για περισσότερες πληροφορίες, ανατρέξτε στην ενότητα Απενεργοποίηση V-Order στην Αποθήκη στο Microsoft Fabric.

Κλωνοποίηση πινάκων αντί αντιγραφής πινάκων

Οι κλώνοι Table στο Fabric αποθήκη δεδομένων παρέχουν έναν γρήγορο και αποτελεσματικό τρόπο δημιουργίας πινάκων χωρίς αντιγραφή δεδομένων. Με μια προσέγγιση κλωνοποίησης με μηδενικό αντίγραφο, μόνο τα μετα-δεδομένα του πίνακα αναπαράγονται, ενώ τα υποκείμενα αρχεία δεδομένων αναφέρονται απευθείας από το OneLake. Αυτό επιτρέπει στους χρήστες να δημιουργούν συνεπή, αξιόπιστα αντίγραφα πίνακα σχεδόν αμέσως, χωρίς την επιβάρυνση της πλήρους αντιγραφής δεδομένων.

Οι κλώνοι μηδενικού αντιγράφου είναι ιδανικοί για σενάρια όπως η ανάπτυξη, η δοκιμή και η δημιουργία αντιγράφων ασφαλείας, προσφέροντας μια λύση υψηλής απόδοσης, αποδοτικής storage που συμβάλλει στη μείωση του κόστους υποδομής.

  • Οι κλωνοποιημένοι πίνακες αντιγράφουν επίσης όλες τις βασικές δυνατότητες ασφαλείας από την προέλευση, συμπεριλαμβανομένων των Row-Level Ασφάλειας (RLS), Column-Level Ασφάλειας (CLS) και Δυναμικής απόκρυψης δεδομένων (DDM), χωρίς την ανάγκη εφαρμογής πολιτικών μετά την κλωνοποίηση.
  • Οι κλώνοι μπορούν να δημιουργηθούν από ένα συγκεκριμένο χρονικό σημείο εντός της περιόδου διατήρησης δεδομένων, υποστηρίζοντας δυνατότητες ταξιδιού χρόνου.
  • Οι κλωνοποιημένοι πίνακες υπάρχουν ανεξάρτητα από την προέλευσή τους, οι αλλαγές που γίνονται στην προέλευση δεν επηρεάζουν τον κλώνο και οι αλλαγές στον κλώνο δεν επηρεάζουν την προέλευση. Η προέλευση ή ο κλώνος μπορούν να απορριφθούν ανεξάρτητα.

Υποβολή ερωτήματος σε προβολές μετα-δεδομένων

Για περισσότερες πληροφορίες σχετικά με τις προβολέςqueryinsights, ανατρέξτε στο θέμα Πληροφορίες ερωτήματος στο Fabric αποθήκη δεδομένων.

Για περισσότερες πληροφορίες σχετικά με τον κύκλο ζωής των ερωτημάτων DMV, ανατρέξτε στο θέμα Παρακολούθηση συνδέσεων, περιόδων λειτουργίας και αιτήσεων με χρήση DMV.

Σχετικό περιεχόμενο

  • Last updated on