Η ανάπτυξη αποθήκευσης είναι μια μακρά και σοβαρή επιχείρηση.
Πολλά στη διάρκεια ζωής ενός έργου εξαρτώνται από το πόσο καλά το μοντέλο αντικειμένου και η δομή βάσης έχουν σχεδιαστεί στην αρχή.
Η γενικά αποδεκτή προσέγγιση ήταν και παραμένει διάφοροι συνδυασμοί του σχήματος αστεριών με την τρίτη κανονική μορφή. Κατά κανόνα, σύμφωνα με την αρχή: αρχικά δεδομένα - 3NF, βιτρίνες - ένα αστέρι. Αυτή η προσέγγιση, δοκιμασμένη στο χρόνο και υποστηριζόμενη από πολλή έρευνα, είναι το πρώτο (και μερικές φορές το μόνο) πράγμα που έρχεται στο μυαλό ενός έμπειρου ειδικού DWH όταν σκέφτεται πώς πρέπει να είναι ένα αναλυτικό αποθετήριο.
Από την άλλη πλευρά, οι επιχειρήσεις γενικά και οι απαιτήσεις των πελατών ειδικότερα τείνουν να αλλάζουν γρήγορα, ενώ τα δεδομένα αυξάνονται τόσο «σε βάθος» και «σε πλάτος». Και εδώ εμφανίζεται το κύριο μειονέκτημα του αστεριού - περιορισμένο ευελιξία.
Και αν είστε στην ήσυχη και άνετη ζωή σας ως προγραμματιστής DWH ξαφνικά:
- προέκυψε το καθήκον "να κάνουμε τουλάχιστον κάτι γρήγορα και μετά θα δούμε".
- εμφανίστηκε ένα ταχέως αναπτυσσόμενο έργο, με τη σύνδεση νέων πηγών και την αλλαγή του επιχειρηματικού μοντέλου τουλάχιστον μία φορά την εβδομάδα.
- εμφανίστηκε ένας πελάτης που δεν έχει ιδέα πώς πρέπει να φαίνεται το σύστημα και ποιες λειτουργίες πρέπει να εκτελεί τελικά, αλλά είναι έτοιμος για πειράματα και συνεπή βελτίωση του επιθυμητού αποτελέσματος με μια συνεπή προσέγγιση σε αυτό.
- ο διευθυντής του έργου κοίταξε με τα καλά νέα: "Και τώρα έχουμε ευέλικτο!".
Ή αν απλώς ενδιαφέρεστε να μάθετε πώς αλλιώς μπορείτε να δημιουργήσετε αποθηκευτικό χώρο - καλώς ήρθατε στη γάτα!
Τι σημαίνει «ευελιξία»;
Αρχικά, ας ορίσουμε ποιες ιδιότητες πρέπει να έχει ένα σύστημα για να ονομαστεί «ευέλικτο».
Ξεχωριστά, αξίζει να αναφέρουμε ότι οι περιγραφόμενες ιδιότητες θα πρέπει να αναφέρονται συγκεκριμένα Σύστημα, όχι να επεξεργάζομαι, διαδικασία την ανάπτυξή του. Επομένως, εάν θέλετε να διαβάσετε για το Agile ως μεθοδολογία ανάπτυξης, είναι καλύτερο να διαβάσετε άλλα άρθρα. Για παράδειγμα, ακριβώς εκεί, στο Habré, υπάρχουν πολλά ενδιαφέροντα υλικά (όπως и Και ).
Αυτό δεν σημαίνει ότι η διαδικασία ανάπτυξης και η δομή της αποθήκης δεδομένων είναι εντελώς άσχετα μεταξύ τους. Γενικά, η Agile ανάπτυξη ενός ευέλικτου αποθηκευτικού χώρου θα πρέπει να είναι πολύ πιο εύκολη. Ωστόσο, στην πράξη, υπάρχουν περισσότερες επιλογές με την Agile ανάπτυξη του κλασικού DWH σύμφωνα με το Kimbal και το DataVault - σύμφωνα με το waterfall παρά ευτυχείς συμπτώσεις ευελιξίας στις δύο μορφές του σε ένα έργο.
Λοιπόν, τι χαρακτηριστικά πρέπει να έχει η ευέλικτη αποθήκευση; Υπάρχουν τρία σημεία εδώ:
- Έγκαιρη παράδοση και γρήγορη ολοκλήρωση - αυτό σημαίνει ότι ιδανικά το πρώτο επιχειρηματικό αποτέλεσμα (για παράδειγμα, οι πρώτες αναφορές εργασίας) θα πρέπει να λαμβάνεται όσο το δυνατόν νωρίτερα, δηλαδή ακόμη και πριν από το σχεδιασμό και την εφαρμογή ολόκληρου του συστήματος. Ταυτόχρονα, κάθε επόμενη αναθεώρηση θα πρέπει επίσης να διαρκεί όσο το δυνατόν λιγότερο χρόνο.
- Επαναληπτική βελτίωση - αυτό σημαίνει ότι κάθε επόμενη αναθεώρηση, ιδανικά, δεν θα πρέπει να επηρεάζει την ήδη λειτουργική λειτουργικότητα. Είναι αυτή η στιγμή που συχνά γίνεται ο μεγαλύτερος εφιάλτης σε μεγάλα έργα - αργά ή γρήγορα τα μεμονωμένα αντικείμενα αρχίζουν να αποκτούν τόσες πολλές σχέσεις που γίνεται ευκολότερο να επαναλάβουμε πλήρως τη λογική σε ένα αντίγραφο δίπλα-δίπλα παρά να προσθέσουμε ένα πεδίο σε έναν υπάρχοντα πίνακα. Και αν εκπλαγείτε που η ανάλυση του αντίκτυπου των βελτιώσεων στα υπάρχοντα αντικείμενα μπορεί να διαρκέσει περισσότερο από την ίδια την αναθεώρηση, πιθανότατα δεν έχετε εργαστεί με μεγάλες αποθήκες δεδομένων στον τραπεζικό τομέα ή στις τηλεπικοινωνίες.
- Συνεχής προσαρμογή στις μεταβαλλόμενες επιχειρηματικές απαιτήσεις - η γενική δομή του αντικειμένου θα πρέπει να σχεδιαστεί όχι μόνο λαμβάνοντας υπόψη την πιθανή επέκταση, αλλά με την προσδοκία ότι η κατεύθυνση αυτής της επόμενης επέκτασης δεν θα μπορούσε καν να ονειρευτεί στο στάδιο του σχεδιασμού.
Και ναι, η συμμόρφωση με όλες αυτές τις απαιτήσεις σε ένα σύστημα είναι δυνατή (φυσικά, σε ορισμένες περιπτώσεις και με ορισμένες επιφυλάξεις).
Παρακάτω θα εξετάσω δύο από τις πιο δημοφιλείς μεθοδολογίες ευέλικτης σχεδίασης για HD − μοντέλο άγκυρας и Θησαυροφυλάκιο δεδομένων. Εκτός των παρενθέσεων υπάρχουν τόσο υπέροχα κόλπα όπως, για παράδειγμα, το EAV, το 6NF (στην καθαρή του μορφή) και οτιδήποτε σχετίζεται με λύσεις NoSQL - όχι επειδή είναι κάπως χειρότερες, ούτε καν επειδή σε αυτήν την περίπτωση το άρθρο θα απειλούσε να αποκτήσει τον όγκο μιας μέσης διατριβής. Απλώς όλα αυτά αναφέρονται σε λύσεις ελαφρώς διαφορετικής κατηγορίας - είτε σε τεχνικές που μπορείτε να εφαρμόσετε σε συγκεκριμένες περιπτώσεις, ανεξάρτητα από τη γενική αρχιτεκτονική του έργου σας (όπως το EAV), είτε σε παγκόσμια διαφορετικά παραδείγματα αποθήκευσης πληροφοριών (όπως, για παράδειγμα, βάσεις δεδομένων γραφημάτων και άλλες παραλλαγές NoSQL).
Προβλήματα της «κλασικής» προσέγγισης και οι λύσεις τους σε ευέλικτες μεθοδολογίες
Με την "κλασική" προσέγγιση εννοώ το παλιό καλό αστέρι (ανεξάρτητα από τη συγκεκριμένη υλοποίηση των υποκείμενων στρωμάτων, συγχωρέστε με τους οπαδούς των Kimball, Inmon και CDM).
1. Άκαμπτο καρδινάλιο των συνδέσεων
Αυτό το μοντέλο βασίζεται σε μια σαφή διαίρεση των δεδομένων σε μετρήσεις (Διάσταση) и γεγονότα (Γεγονός). Και αυτό, διάολε, είναι λογικό - άλλωστε, η ανάλυση δεδομένων στη συντριπτική πλειοψηφία των περιπτώσεων καταλήγει στην ανάλυση ορισμένων αριθμητικών δεικτών (γεγονότων) σε ορισμένες ενότητες (διαστάσεις).
Ταυτόχρονα, οι σύνδεσμοι μεταξύ αντικειμένων τοποθετούνται με τη μορφή συνδέσμων μεταξύ πινάκων με ένα ξένο κλειδί. Αυτό φαίνεται αρκετά φυσικό, αλλά οδηγεί αμέσως στον πρώτο περιορισμό της ευελιξίας - αυστηρός ορισμός της βασικότητας των σχέσεων.
Αυτό σημαίνει ότι στο στάδιο του σχεδιασμού των πινάκων, πρέπει να καθορίσετε για κάθε ζεύγος σχετικών αντικειμένων εάν μπορούν να συσχετιστούν ως πολλά-προς-πολλά ή μόνο 1-προς-πολλά και «προς ποια κατεύθυνση». Εξαρτάται άμεσα από το ποιος από τους πίνακες θα έχει πρωτεύον κλειδί και ποιος θα έχει ξένο κλειδί. Η αλλαγή αυτής της αναλογίας κατά τη λήψη νέων απαιτήσεων θα οδηγήσει πιθανότατα σε επανεπεξεργασία της βάσης.
Για παράδειγμα, κατά το σχεδιασμό του αντικειμένου «αποδείξεις μετρητών», εσείς, βασιζόμενοι στις ένορκες διαβεβαιώσεις του τμήματος πωλήσεων, ορίσατε τη δυνατότητα δράσης μία προαγωγή για πολλές θέσεις ελέγχου (αλλά όχι το αντίστροφο):
Και μετά από λίγο, οι συνάδελφοι εισήγαγαν μια νέα στρατηγική μάρκετινγκ στην οποία πολλαπλές προσφορές ταυτόχρονα. Και τώρα πρέπει να ολοκληρώσετε τους πίνακες επισημαίνοντας τη σχέση σε ένα ξεχωριστό αντικείμενο.
(Όλα τα παράγωγα αντικείμενα, στα οποία ενώνεται ο έλεγχος προώθησης, πρέπει τώρα επίσης να βελτιωθούν).
Σύνδεσμοι σε Data Vault και Anchor Model
Αποδείχθηκε πολύ απλό να αποφύγετε μια τέτοια κατάσταση: δεν χρειάζεται να εμπιστεύεστε το τμήμα πωλήσεων, αρκεί Όλες οι σχέσεις αποθηκεύονται αρχικά σε ξεχωριστούς πίνακες και επεξεργάζονται όπως πολλά-προς-πολλά.
Αυτή η προσέγγιση έχει προταθεί Νταν Λίστεντ ως μέρος του παραδείγματος Θησαυροφυλάκιο δεδομένων και υποστηρίζεται πλήρως Lars Rönnbäck в Μοντέλο άγκυρας.
Ως αποτέλεσμα, έχουμε το πρώτο διακριτικό χαρακτηριστικό των ευέλικτων μεθοδολογιών:
Οι σχέσεις μεταξύ αντικειμένων δεν αποθηκεύονται στα χαρακτηριστικά των μητρικών οντοτήτων, αλλά αποτελούν ξεχωριστό τύπο αντικειμένων.
В Θησαυροφυλάκιο δεδομένων τέτοιοι πίνακες λέγονται Σύνδεσμος, ενώ στο Μοντέλο άγκυρας - Γραβάτα. Με την πρώτη ματιά, μοιάζουν πολύ, αν και οι διαφορές τους δεν εξαντλούνται από το όνομα (το οποίο θα συζητηθεί παρακάτω). Και στις δύο αρχιτεκτονικές, οι πίνακες συνδέσμων μπορούν να συνδεθούν οποιοδήποτε αριθμό οντοτήτων (όχι απαραίτητα 2).
Αυτή η εκ πρώτης όψεως πλεονασμός δίνει ουσιαστική ευελιξία στις ολοκληρώσεις. Μια τέτοια δομή γίνεται ανεκτική όχι μόνο στην αλλαγή των καρδινοτήτων των υπαρχόντων συνδέσμων, αλλά και στην προσθήκη νέων - εάν τώρα μια θέση ελέγχου έχει επίσης έναν σύνδεσμο προς τον ταμία που την έχει σπάσει, η εμφάνιση ενός τέτοιου συνδέσμου θα είναι απλώς μια υπερκατασκευή σε υπάρχοντες πίνακες χωρίς να επηρεάζει υπάρχοντα αντικείμενα και διαδικασίες.
2. Αντιγραφή δεδομένων
Το δεύτερο πρόβλημα που επιλύεται από τις ευέλικτες αρχιτεκτονικές είναι λιγότερο προφανές και εγγενές στην πρώτη θέση. μετρήσεις τύπου SCD2 (σιγά σιγά αλλάζουν μετρήσεις δεύτερου τύπου), αν και όχι μόνο αυτές.
Στην κλασική αποθήκευση, μια διάσταση είναι συνήθως ένας πίνακας που περιέχει ένα υποκατάστατο κλειδί (ως PK) και ένα σύνολο επιχειρηματικών κλειδιών και χαρακτηριστικών σε ξεχωριστές στήλες.
Εάν η ιδιότητα υποστηρίζει την έκδοση εκδόσεων, τα χρονικά όρια έκδοσης προστίθενται στο τυπικό σύνολο πεδίων και εμφανίζονται πολλαπλές εκδόσεις στο χώρο αποθήκευσης ανά σειρά στην πηγή (μία για κάθε αλλαγή σε χαρακτηριστικά έκδοσης).
Εάν μια ιδιότητα περιέχει τουλάχιστον ένα χαρακτηριστικό έκδοσης που αλλάζει συχνά, ο αριθμός των εκδόσεων μιας τέτοιας ιδιότητας θα είναι εντυπωσιακός (ακόμα και αν τα άλλα χαρακτηριστικά δεν έχουν εκδοθεί ή δεν αλλάζουν ποτέ) και αν υπάρχουν πολλά τέτοια χαρακτηριστικά, ο αριθμός των εκδόσεων μπορεί να αυξηθεί εκθετικά από τον αριθμό τους. Μια τέτοια διάσταση μπορεί να καταλάβει σημαντικό χώρο στο δίσκο, αν και τα περισσότερα από τα δεδομένα που είναι αποθηκευμένα σε αυτήν είναι απλώς διπλότυπα αμετάβλητων τιμών χαρακτηριστικών από άλλες σειρές.
Ταυτόχρονα, χρησιμοποιείται επίσης συχνά αποκανονικοποίηση - ορισμένα από τα χαρακτηριστικά αποθηκεύονται σκόπιμα ως τιμή και όχι ως αναφορά σε βιβλίο αναφοράς ή άλλη διάσταση. Αυτή η προσέγγιση επιταχύνει την πρόσβαση σε δεδομένα μειώνοντας τον αριθμό των συνδέσεων κατά την πρόσβαση σε μια ιδιότητα.
Συνήθως, αυτό έχει ως αποτέλεσμα οι ίδιες πληροφορίες αποθηκεύονται ταυτόχρονα σε πολλά σημεία. Για παράδειγμα, πληροφορίες σχετικά με την περιοχή κατοικίας και την ιδιότητα μέλους της κατηγορίας πελατών μπορούν να αποθηκευτούν ταυτόχρονα στις διαστάσεις «Πελάτης» και στα στοιχεία «Αγορά», «Παράδοση» και «Επαφές τηλεφωνικού κέντρου», καθώς και στον πίνακα συνδέσμων «Πελάτης - Διαχειριστής πελατών».
Γενικά, τα παραπάνω ισχύουν και για κανονικές (χωρίς εκδόσεις) μετρήσεις, αλλά στις εκδόσεις μπορεί να έχουν διαφορετική κλίμακα: η εμφάνιση μιας νέας έκδοσης ενός αντικειμένου (ειδικά εκ των υστέρων) οδηγεί όχι μόνο στην ενημέρωση όλων των σχετικών πινάκων, αλλά και σε μια καταρράκτη εμφάνιση νέων εκδόσεων σχετικών αντικειμένων - όταν χρησιμοποιείται ο Πίνακας 1 κατά την κατασκευή Πίνακα 2, Πίνακας 2 κ.λπ. Ακόμα κι αν δεν εμπλέκεται ούτε ένα χαρακτηριστικό του Πίνακα 3 στην κατασκευή του Πίνακα 1 (αλλά εμπλέκονται και άλλα χαρακτηριστικά του Πίνακα 3 που λαμβάνονται από άλλες πηγές), η έκδοση αυτής της κατασκευής θα οδηγήσει τουλάχιστον σε πρόσθετα γενικά κόστη και το πολύ σε επιπλέον εκδόσεις στον Πίνακα 2, που δεν έχει καμία σχέση με αυτό και πιο κάτω στην αλυσίδα.
3. Μη γραμμική πολυπλοκότητα τελειοποίησης
Ταυτόχρονα, κάθε νέα βιτρίνα που χτίζεται πάνω από την άλλη αυξάνει τον αριθμό των θέσεων όπου τα δεδομένα μπορούν να «αποκλίνουν» όταν γίνονται αλλαγές στο ETL. Αυτό, με τη σειρά του, οδηγεί σε αύξηση της πολυπλοκότητας (και της διάρκειας) κάθε επόμενης αναθεώρησης.
Εάν τα παραπάνω ισχύουν για συστήματα με σπάνια τροποποιημένες διαδικασίες ETL, μπορείτε να ζήσετε σε ένα τέτοιο παράδειγμα - απλώς βεβαιωθείτε ότι οι νέες βελτιώσεις γίνονται σωστά σε όλα τα σχετικά αντικείμενα. Εάν οι αναθεωρήσεις γίνονται συχνά, η πιθανότητα να «χάσουν» κατά λάθος αρκετοί σύνδεσμοι αυξάνεται σημαντικά.
Εάν, επιπλέον, λάβουμε υπόψη ότι η «εκδοχή» ETL είναι πολύ πιο περίπλοκη από την «μη έκδοση», γίνεται αρκετά δύσκολο να αποφευχθούν λάθη κατά τη συχνή βελτίωση όλης αυτής της οικονομίας.
Αποθήκευση αντικειμένων και χαρακτηριστικών σε Data Vault και Anchor Model
Η προσέγγιση που προτείνεται από τους συγγραφείς των ευέλικτων αρχιτεκτονικών μπορεί να διατυπωθεί ως εξής:
Είναι απαραίτητο να διαχωρίσουμε τι αλλάζει από αυτό που παραμένει αμετάβλητο. Δηλαδή να αποθηκεύονται τα κλειδιά χωριστά από τα χαρακτηριστικά.
Ωστόσο, μην μπερδεύεστε δεν έχει εκδοθεί χαρακτηριστικό με αμετάβλητος: το πρώτο δεν αποθηκεύει το ιστορικό της αλλαγής του, αλλά μπορεί να αλλάξει (για παράδειγμα, κατά τη διόρθωση ενός σφάλματος εισαγωγής ή τη λήψη νέων δεδομένων), το δεύτερο δεν αλλάζει ποτέ.
Οι απόψεις σχετικά με το τι ακριβώς μπορεί να θεωρηθεί αμετάβλητο στο Data Vault και στο μοντέλο Anchor διαφέρουν.
Από άποψη αρχιτεκτονικής Θησαυροφυλάκιο δεδομένων, μπορεί να θεωρηθεί αμετάβλητο όλο το σετ κλειδιών — φυσικό (ΑΦΜ του οργανισμού, κωδικός προϊόντος στο σύστημα πηγής κ.λπ.) και υποκατάστατο. Ταυτόχρονα, τα υπόλοιπα χαρακτηριστικά μπορούν να χωριστούν σε ομάδες ανάλογα με την πηγή ή/και τη συχνότητα των αλλαγών και κρατήστε ξεχωριστό πίνακα για κάθε ομάδα με ένα ανεξάρτητο σύνολο εκδόσεων.
Στο ίδιο παράδειγμα Μοντέλο άγκυρας θεωρείται αμετάβλητη μόνο υποκατάστατο κλειδί οντότητες. Όλα τα άλλα (συμπεριλαμβανομένων των φυσικών κλειδιών) είναι απλώς μια ειδική περίπτωση των ιδιοτήτων του. Εν όλα τα χαρακτηριστικά είναι εξ ορισμού ανεξάρτητα μεταξύ τους, οπότε για κάθε χαρακτηριστικό πρέπει να δημιουργηθεί ξεχωριστό τραπέζι.
В Θησαυροφυλάκιο δεδομένων καλούνται πίνακες που περιέχουν κλειδιά οντοτήτων Hubami (Κόμβος). Οι κόμβοι περιέχουν πάντα ένα σταθερό σύνολο πεδίων:
- Κλειδιά φυσικής οντότητας
- Υποκατάστατο κλειδί
- Σύνδεσμος στην πηγή
- Χρόνος εγγραφής
Εγγραφές σε Hubs ποτέ δεν αλλάζει και δεν έχει εκδόσεις. Εξωτερικά, οι κόμβοι είναι πολύ παρόμοιοι με τους πίνακες χαρτών ID που χρησιμοποιούνται σε ορισμένα συστήματα για τη δημιουργία υποκατάστατων, ωστόσο, συνιστάται η χρήση όχι μιας ακέραιας ακολουθίας, αλλά ενός κατακερματισμού από ένα σύνολο επιχειρηματικών κλειδιών ως υποκατάστατα στο Data Vault. Αυτή η προσέγγιση απλοποιεί τη φόρτωση συνδέσμων και χαρακτηριστικών από πηγές (δεν χρειάζεται να συνδεθείτε στο hub για να λάβετε ένα υποκατάστατο, απλώς υπολογίστε τον κατακερματισμό από το φυσικό κλειδί), αλλά μπορεί να προκαλέσει άλλα προβλήματα (για παράδειγμα, με συγκρούσεις, κεφαλαία και μη εκτυπώσιμους χαρακτήρες σε πλήκτρα συμβολοσειράς κ.λπ.), επομένως δεν είναι γενικά αποδεκτό.
Όλα τα άλλα χαρακτηριστικά οντοτήτων αποθηκεύονται σε ειδικούς πίνακες που ονομάζονται Δορυφόροι (Δορυφόρος). Ένας διανομέας μπορεί να έχει πολλούς δορυφόρους που αποθηκεύουν διαφορετικά σύνολα χαρακτηριστικών.
Η κατανομή των χαρακτηριστικών μεταξύ δορυφόρων γίνεται σύμφωνα με την αρχή αλλαγή της άρθρωσης - ένας δορυφόρος μπορεί να αποθηκεύσει χαρακτηριστικά που δεν έχουν εκδοθεί (για παράδειγμα, ημερομηνία γέννησης και SNILS για ένα άτομο), στον άλλο - σπάνια μεταβαλλόμενα χαρακτηριστικά (για παράδειγμα, επίθετο και αριθμός διαβατηρίου), στον τρίτο - συχνά μεταβαλλόμενα (για παράδειγμα, διεύθυνση παράδοσης, κατηγορία, ημερομηνία τελευταίας παραγγελίας κ.λπ.). Η έκδοση εκδόσεων σε αυτήν την περίπτωση πραγματοποιείται σε επίπεδο μεμονωμένων δορυφόρων και όχι στο σύνολο της οντότητας, επομένως συνιστάται η διανομή των χαρακτηριστικών με τέτοιο τρόπο ώστε η τομή των εκδόσεων σε έναν δορυφόρο να είναι ελάχιστη (πράγμα που μειώνει τον συνολικό αριθμό των αποθηκευμένων εκδόσεων).
Επίσης, για τη βελτιστοποίηση της διαδικασίας φόρτωσης δεδομένων, τα χαρακτηριστικά που λαμβάνονται από διάφορες πηγές τοποθετούνται συχνά σε ξεχωριστούς δορυφόρους.
Οι δορυφόροι επικοινωνούν με το Hub μέσω ξένο κλειδί (που αντιστοιχεί σε καρδινάλιση 1 προς πολλά). Αυτό σημαίνει ότι πολλαπλές τιμές χαρακτηριστικών (για παράδειγμα, πολλοί αριθμοί τηλεφώνου επικοινωνίας για τον ίδιο πελάτη) υποστηρίζονται από αυτήν την «προεπιλεγμένη» αρχιτεκτονική.
В Μοντέλο άγκυρας Οι πίνακες που αποθηκεύουν κλειδιά ονομάζονται Άγκυρες. Και κρατούν:
- Μόνο υποκατάστατα κλειδιά
- Σύνδεσμος στην πηγή
- Χρόνος εγγραφής
Τα φυσικά κλειδιά από την άποψη του Anchor Model λαμβάνονται υπόψη συνηθισμένες ιδιότητες. Αυτή η επιλογή μπορεί να φαίνεται πιο δύσκολη στην κατανόηση, αλλά δίνει πολύ περισσότερο πεδίο για την αναγνώριση ενός αντικειμένου.
Για παράδειγμα, εάν τα δεδομένα για την ίδια οντότητα μπορούν να προέρχονται από διαφορετικά συστήματα, καθένα από τα οποία χρησιμοποιεί το δικό του φυσικό κλειδί. Στο Data Vault, αυτό μπορεί να οδηγήσει σε μάλλον δυσκίνητες κατασκευές πολλών κόμβων (ένας ανά πηγή + συγχώνευση κύρια έκδοση), ενώ στο μοντέλο Anchor, το φυσικό κλειδί κάθε πηγής εμπίπτει στο δικό του χαρακτηριστικό και μπορεί να χρησιμοποιηθεί κατά τη φόρτωση ανεξάρτητα από όλες τις άλλες.
Αλλά εδώ βρίσκεται μια ύπουλη στιγμή: εάν τα χαρακτηριστικά από διαφορετικά συστήματα συνδυάζονται σε μια οντότητα, πιθανότατα υπάρχουν κάποια κανόνες κόλλας, με την οποία το σύστημα πρέπει να κατανοήσει ότι οι εγγραφές από διαφορετικές πηγές αντιστοιχούν σε μία παρουσία της οντότητας.
В Θησαυροφυλάκιο δεδομένων αυτοί οι κανόνες είναι πιθανό να καθορίσουν τον σχηματισμό «υποκατάστατο κέντρο» της κύριας οντότητας και σε καμία περίπτωση δεν επηρεάζουν τα Hub που αποθηκεύουν τα φυσικά κλειδιά των πηγών και τα αρχικά τους χαρακτηριστικά. Εάν κάποια στιγμή αλλάξουν οι κανόνες για τη συγχώνευση (ή τα χαρακτηριστικά που χρησιμοποιούνται για τη συγχώνευση ενημερωθούν), θα αρκεί να διαμορφωθούν εκ νέου οι υποκατάστατοι κόμβοι.
В μοντέλο άγκυρας μια τέτοια οντότητα είναι πιθανό να αποθηκευτεί σε μονή άγκυρα. Αυτό σημαίνει ότι όλα τα χαρακτηριστικά, ανεξάρτητα από την πηγή που λαμβάνονται, θα δεσμεύονται στο ίδιο υποκατάστατο. Ο διαχωρισμός των εσφαλμένα συγχωνευμένων εγγραφών και, γενικά, η παρακολούθηση της συνάφειας της συγχώνευσης σε ένα τέτοιο σύστημα μπορεί να είναι πολύ πιο δύσκολος, ειδικά εάν οι κανόνες είναι αρκετά περίπλοκοι και αλλάζουν συχνά και το ίδιο χαρακτηριστικό μπορεί να ληφθεί από διαφορετικές πηγές (αν και είναι σίγουρα δυνατό, επειδή κάθε έκδοση του χαρακτηριστικού διατηρεί έναν σύνδεσμο προς την πηγή του).
Σε κάθε περίπτωση, εάν το σύστημά σας υποτίθεται ότι υλοποιεί τη λειτουργικότητα deduplication, συγχώνευση εγγραφών και άλλα στοιχεία MDM, θα πρέπει να διαβάσετε ιδιαίτερα προσεκτικά τις πτυχές της αποθήκευσης φυσικών κλειδιών σε ευέλικτες μεθοδολογίες. Ίσως ο πιο δυσκίνητος σχεδιασμός του Data Vault να είναι ξαφνικά πιο ασφαλής όσον αφορά τα σφάλματα συγχώνευσης.
μοντέλο άγκυρας παρέχει επίσης έναν πρόσθετο τύπο αντικειμένου που ονομάζεται Κόμπος στην πραγματικότητα είναι ένα ιδιαίτερο εκφυλισμένος τύπος άγκυρας, το οποίο μπορεί να περιέχει μόνο ένα χαρακτηριστικό. Οι κόμβοι υποτίθεται ότι χρησιμοποιούνται για την αποθήκευση επίπεδων καταλόγων (για παράδειγμα, φύλο, οικογενειακή κατάσταση, κατηγορία εξυπηρέτησης πελατών κ.λπ.). Σε αντίθεση με το Anchor, Knot δεν έχει συσχετισμένους πίνακες χαρακτηριστικών, και το μόνο χαρακτηριστικό του (όνομα) αποθηκεύεται πάντα στον ίδιο πίνακα με το κλειδί. Οι κόμβοι συνδέονται με τα Anchors με πίνακες δεσμών (Tie) με τον ίδιο τρόπο που συνδέονται μεταξύ τους οι άγκυρες.
Δεν υπάρχει σαφής άποψη σχετικά με τη χρήση των κόμβων. Για παράδειγμα, , ο οποίος προωθεί ενεργά τη χρήση του Μοντέλου Άγκυρας στη Ρωσία, πιστεύει (όχι αδικαιολόγητα) ότι είναι αδύνατο να πούμε για ένα μόνο βιβλίο αναφοράς ότι πάντα θα είναι στατικό και σε ένα επίπεδο, επομένως είναι καλύτερο να χρησιμοποιήσετε ένα πλήρες Anchor για όλα τα αντικείμενα ταυτόχρονα.
Μια άλλη σημαντική διαφορά μεταξύ Data Vault και Anchor Model είναι η παρουσία χαρακτηριστικά για συνδέσμους:
В Θησαυροφυλάκιο δεδομένων Οι σύνδεσμοι είναι τα ίδια ολοκληρωμένα αντικείμενα με τα Hub και μπορούν να έχουν δικά τους χαρακτηριστικά. Σε μοντέλο άγκυρας Οι σύνδεσμοι χρησιμοποιούνται μόνο για τη σύνδεση Anchors και δεν μπορούν να έχουν τις δικές τους ιδιότητες. Αυτή η διαφορά οδηγεί σε σημαντικά διαφορετικές προσεγγίσεις μοντελοποίησης. γεγονότα, το οποίο θα συζητηθεί στη συνέχεια.
Αποθήκευση γεγονότων
Μέχρι στιγμής, έχουμε μιλήσει κυρίως για μετρήσεις μοντελοποίησης. Τα γεγονότα είναι λίγο λιγότερο ξεκάθαρα.
В Θησαυροφυλάκιο δεδομένων ένα τυπικό αντικείμενο για την αποθήκευση γεγονότων − Σύνδεσμος, στους δορυφόρους του οποίου προστίθενται πραγματικοί δείκτες.
Αυτή η προσέγγιση φαίνεται να είναι διαισθητική. Παρέχει εύκολη πρόσβαση στους αναλυόμενους δείκτες και είναι γενικά παρόμοιος με έναν παραδοσιακό πίνακα γεγονότων (μόνο οι δείκτες δεν αποθηκεύονται στον ίδιο τον πίνακα, αλλά στον "παρακείμενο πίνακα"). Υπάρχουν όμως και παγίδες: μια από τις τυπικές βελτιώσεις του μοντέλου -η επέκταση του κλειδιού δεδομένων- το καθιστά απαραίτητο προσθέτοντας ένα νέο ξένο κλειδί στο σύνδεσμο. Και αυτό, με τη σειρά του, «σπάει» την αρθρωτή δομή και δυνητικά προκαλεί την ανάγκη για βελτιώσεις σε άλλα αντικείμενα.
В μοντέλο άγκυρας Ένας σύνδεσμος δεν μπορεί να έχει τα δικά του χαρακτηριστικά, επομένως αυτή η προσέγγιση δεν θα λειτουργήσει - απολύτως όλα τα χαρακτηριστικά και οι δείκτες πρέπει να συνδέονται με μια συγκεκριμένη άγκυρα. Το συμπέρασμα από αυτό είναι απλό - κάθε γεγονός χρειάζεται και τη δική του άγκυρα. Για ορισμένα από αυτά που έχουμε συνηθίσει να αντιλαμβανόμαστε ως γεγονότα, αυτό μπορεί να φαίνεται φυσικό - για παράδειγμα, το γεγονός μιας αγοράς μειώνεται τέλεια στο αντικείμενο "παραγγελία" ή "απόδειξη", η επίσκεψη σε έναν ιστότοπο περιορίζεται σε μια περίοδο λειτουργίας κ.λπ. Υπάρχουν όμως και γεγονότα για τα οποία δεν είναι τόσο εύκολο να βρεθεί ένα τέτοιο φυσικό «αντικείμενο μεταφοράς» - για παράδειγμα, το υπόλοιπο των εμπορευμάτων στις αποθήκες στην αρχή κάθε ημέρας.
Ως εκ τούτου, δεν υπάρχουν προβλήματα με τη σπονδυλωτή κατά την επέκταση του κλειδιού δεδομένων στο Anchor Model (αρκεί απλώς να προσθέσετε μια νέα σχέση στο αντίστοιχο Anchor), αλλά ο σχεδιασμός του μοντέλου για την εμφάνιση γεγονότων είναι λιγότερο απλός, ενδέχεται να εμφανίζονται «τεχνητές» Anchors που αντικατοπτρίζουν το μοντέλο αντικειμένου της επιχείρησης.
Πώς επιτυγχάνεται η ευελιξία
Η κατασκευή που προκύπτει και στις δύο περιπτώσεις περιέχει σημαντικά περισσότερα τραπέζιααπό την παραδοσιακή μέτρηση. Αλλά μπορεί να πάρει σημαντικά μικρότερο χώρο στο δίσκο με το ίδιο σύνολο χαρακτηριστικών έκδοσης με την παραδοσιακή διάσταση. Φυσικά, δεν υπάρχει μαγεία εδώ - όλα είναι θέμα ομαλοποίησης. Κατανέμοντας χαρακτηριστικά σε δορυφόρους (στο Data Vault) ή σε μεμονωμένους πίνακες (Anchor Model), μειώνουμε (ή εξαλείφουμε εντελώς) αντιγραφή των τιμών ορισμένων χαρακτηριστικών κατά την αλλαγή άλλων.
Για Θησαυροφυλάκιο δεδομένων το κέρδος θα εξαρτηθεί από την κατανομή των χαρακτηριστικών μεταξύ των Δορυφόρων και για μοντέλο άγκυρας — είναι σχεδόν ευθέως ανάλογο με τον μέσο αριθμό εκδόσεων ανά αντικείμενο μέτρησης.
Ωστόσο, η ανάληψη χώρου είναι ένα σημαντικό, αλλά όχι το κύριο, πλεονέκτημα της χωριστής αποθήκευσης χαρακτηριστικών. Μαζί με την ξεχωριστή αποθήκευση συνδέσμων, αυτή η προσέγγιση κάνει την αποθήκευση αρθρωτός σχεδιασμός. Αυτό σημαίνει ότι η προσθήκη τόσο μεμονωμένων χαρακτηριστικών όσο και ολόκληρων νέων θεματικών περιοχών σε ένα τέτοιο μοντέλο μοιάζει υπερκατασκευή πάνω από ένα υπάρχον σύνολο αντικειμένων χωρίς να τα αλλάξετε. Και αυτό ακριβώς κάνει τις περιγραφόμενες μεθοδολογίες ευέλικτες.
Μοιάζει επίσης με τη μετάβαση από την παραγωγή τεμαχίων στη μαζική παραγωγή - εάν στην παραδοσιακή προσέγγιση κάθε πίνακας μοντέλων είναι μοναδικός και απαιτεί ξεχωριστή προσοχή, τότε στις ευέλικτες μεθοδολογίες είναι ήδη ένα σύνολο τυπικών «λεπτομέρειών». Από τη μία πλευρά, υπάρχουν περισσότεροι πίνακες, οι διαδικασίες φόρτωσης και ανάκτησης δεδομένων θα πρέπει να φαίνονται πιο περίπλοκες. Από την άλλη γίνονται τυπικός. Αυτό σημαίνει ότι μπορεί να υπάρχει αυτοματοποιημένη και διαχειριζόμενη από μεταδεδομένα. Η ερώτηση "πώς θα το βάλουμε;", η απάντηση στην οποία θα μπορούσε να καταλάβει σημαντικό μέρος της εργασίας για το σχεδιασμό των βελτιώσεων, τώρα απλά δεν αξίζει τον κόπο (όπως και το ερώτημα του αντίκτυπου της αλλαγής του μοντέλου στις διαδικασίες εργασίας).
Αυτό δεν σημαίνει ότι οι αναλυτές σε ένα τέτοιο σύστημα δεν χρειάζονται καθόλου - κάποιος πρέπει ακόμα να επεξεργαστεί ένα σύνολο αντικειμένων με χαρακτηριστικά και να καταλάβει πού και πώς να τα φορτώσει όλα. Αλλά ο όγκος της εργασίας, καθώς και η πιθανότητα και το κόστος ενός σφάλματος, μειώνονται σημαντικά. Τόσο στο στάδιο της ανάλυσης όσο και κατά την ανάπτυξη του ETL, το οποίο σε σημαντικό μέρος μπορεί να περιοριστεί στην επεξεργασία μεταδεδομένων.
Σκοτεινή πλευρά
Όλα τα παραπάνω καθιστούν και τις δύο προσεγγίσεις πραγματικά ευέλικτες, κατασκευάσιμες και κατάλληλες για επαναληπτική βελτίωση. Φυσικά, υπάρχει και ένα «βαρέλι με πίσσα», το οποίο νομίζω ότι γνωρίζετε ήδη.
Η αποσύνθεση δεδομένων στην οποία βασίζεται η σπονδυλωτότητα των ευέλικτων αρχιτεκτονικών οδηγεί σε αύξηση του αριθμού των πινάκων και, κατά συνέπεια, πάνω από το κεφάλι για ενώσεις κατά τη λήψη. Για να λάβετε απλά όλα τα χαρακτηριστικά μιας διάστασης, αρκεί μια μόνο επιλογή στην κλασική αποθήκευση και μια ευέλικτη αρχιτεκτονική θα απαιτήσει έναν αριθμό συνδέσεων. Επιπλέον, εάν για τις αναφορές όλες αυτές οι συνδέσεις μπορούν να γραφτούν εκ των προτέρων, τότε οι αναλυτές που έχουν συνηθίσει να γράφουν SQL με το χέρι θα υποφέρουν διπλά.
Υπάρχουν πολλά γεγονότα που διευκολύνουν αυτήν την κατάσταση:
Όταν εργάζεστε με μεγάλες διαστάσεις, σχεδόν όλα τα χαρακτηριστικά του δεν χρησιμοποιούνται σχεδόν ποτέ ταυτόχρονα. Αυτό σημαίνει ότι μπορεί να υπάρχουν λιγότερες ενώσεις από ό,τι φαίνεται με την πρώτη ματιά στο μοντέλο. Στο Data Vault, μπορείτε επίσης να λάβετε υπόψη την αναμενόμενη συχνότητα κοινής χρήσης κατά την εκχώρηση χαρακτηριστικών σε δορυφόρους. Ταυτόχρονα, τα ίδια τα Hubs ή τα Anchors χρειάζονται κυρίως για τη δημιουργία και τη χαρτογράφηση υποκατάστατων στο στάδιο φόρτωσης και σπάνια χρησιμοποιούνται σε ερωτήματα (αυτό ισχύει ιδιαίτερα για τα Anchors).
Όλες οι ενώσεις γίνονται με κλειδί. Επιπλέον, ένας πιο «συμπιεσμένος» τρόπος αποθήκευσης δεδομένων μειώνει την επιβάρυνση της σάρωσης πίνακα όπου χρειάζεται (για παράδειγμα, όταν φιλτράρετε με βάση μια τιμή χαρακτηριστικού). Αυτό μπορεί να οδηγήσει στο γεγονός ότι η ανάκτηση από μια κανονικοποιημένη βάση δεδομένων με ένα σωρό συνδέσεις θα είναι ακόμη πιο γρήγορη από τη σάρωση μιας μεγάλης διάστασης με πολλές εκδόσεις ανά σειρά.
Για παράδειγμα, εδώ μέσα άρθρο υπάρχει μια λεπτομερής συγκριτική δοκιμή απόδοσης του μοντέλου Anchor με επιλογή από έναν πίνακα.
Πολλά εξαρτώνται από τον κινητήρα. Πολλές σύγχρονες πλατφόρμες διαθέτουν εσωτερικούς μηχανισμούς για τη βελτιστοποίηση των συνδέσεων. Για παράδειγμα, η MS SQL και η Oracle μπορούν να «παρακάμψουν» συνδέσεις σε πίνακες εάν τα δεδομένα τους δεν χρησιμοποιούνται οπουδήποτε εκτός από άλλες συνδέσεις και δεν επηρεάζουν την τελική επιλογή (εξάλειψη πίνακα/συμμετοχής), ενώ το MPP Vertica , αποδείχθηκε εξαιρετική μηχανή για το Anchor Model, με κάποια μη αυτόματη βελτιστοποίηση του σχεδίου ερωτημάτων. Από την άλλη πλευρά, η αποθήκευση του Anchor Model, για παράδειγμα, στο Click House, το οποίο έχει περιορισμένη υποστήριξη για σύνδεση, δεν φαίνεται ακόμα καλή ιδέα.
Επιπλέον, και για τις δύο αρχιτεκτονικές υπάρχουν ειδικά κόλπα, που διευκολύνουν την πρόσβαση στα δεδομένα (τόσο από την άποψη της απόδοσης ερωτημάτων όσο και για τους τελικούς χρήστες). Για παράδειγμα, Πίνακες σημείου χρόνου στο Data Vault ή ειδικές λειτουργίες τραπεζιού στο μοντέλο της άγκυρας.
Σε συνολικά
Η κύρια ουσία των θεωρούμενων ευέλικτων αρχιτεκτονικών είναι η σπονδυλωτότητα του «σχεδίου» τους.
Αυτή η ιδιοκτησία επιτρέπει:
- Μετά από κάποια αρχική προετοιμασία που σχετίζεται με την ανάπτυξη μεταδεδομένων και τη σύνταξη βασικών αλγορίθμων ETL, παρέχει γρήγορα στον πελάτη το πρώτο αποτέλεσμα με τη μορφή μερικών αναφορών που περιέχουν δεδομένα από λίγα μόνο αντικείμενα πηγής. Δεν είναι απαραίτητο να σκεφτούμε πλήρως (ακόμη και ανώτατου επιπέδου) ολόκληρο το μοντέλο αντικειμένου για αυτό.
- Ένα μοντέλο δεδομένων μπορεί να αρχίσει να λειτουργεί (και χρήσιμο) με μόλις 2-3 αντικείμενα και μετά μεγαλώνουν σταδιακά (σχετικά με το μοντέλο Anchor Nikolay όμορφη σύγκριση με το μυκήλιο).
- Οι περισσότερες βελτιώσεις, συμπεριλαμβανομένης της επέκτασης της θεματικής περιοχής και της προσθήκης νέων πηγών δεν επηρεάζει την υπάρχουσα λειτουργικότητα και δεν προκαλεί τον κίνδυνο να σπάσει κάτι που ήδη λειτουργεί.
- Χάρη στην αποσύνθεση σε τυπικά στοιχεία, οι διαδικασίες ETL σε τέτοια συστήματα φαίνονται ίδιες, η γραφή τους προσφέρεται για αλγόριθμο και, τελικά, αυτοματοποίηση.
Το τίμημα αυτής της ευελιξίας είναι εκτέλεση. Αυτό δεν σημαίνει ότι είναι αδύνατο να επιτευχθούν αποδεκτές επιδόσεις σε τέτοια μοντέλα. Τις περισσότερες φορές, ίσως χρειάζεστε περισσότερη προσπάθεια και προσοχή στη λεπτομέρεια για να επιτύχετε τις επιθυμητές μετρήσεις.
Εφαρμογές
Τύποι οντοτήτων Θησαυροφυλάκιο δεδομένων
Περισσότερα για το Data Vault:
Τύποι οντοτήτων Μοντέλο άγκυρας
Περισσότερα για το Anchor Model:
Συνοπτικός πίνακας με κοινά χαρακτηριστικά και διαφορές μεταξύ των εξεταζόμενων προσεγγίσεων:
Πηγή: www.habr.com