Εισαγωγή

Έχοντας σχεδιάσει το DW και αφού έχουμε κάνει data analysis and profiling είμαστε πλέον στο σημείο που πρέπει να δημιουργήσουμε την διαδικασία που θα μεταφέρει τα δεδομένα από την πηγή (data source) στο DW.

Μια τέτοια διαδικασία είναι γνωστή σαν ETL Process και περιλαμβάνει τα στάδια του

• Extract data from data source
• Transform data
• Load data to destination (data warehouse tables)

Μια τέτοια διαδικασία θα πρέπει να σχεδιαστεί έτσι ώστε να έχει την μέγιστη απόδοση (performance), κλιμάκωση (scalability) και διαχείριση/συντήρηση (manageability) για όλες τις παραπάνω φάσεις ξεχωριστά για την κάθε μία, αλλά και στο σύνολο της σαν διαδικασία.

Σε αυτό το post θα ασχοληθούμε με την φάση του extract data form data source.

Για να ικανοποιηθούν τα παραπάνω (performance, scalability, manageability) θα πρέπει να είμαστε σε θέση να γνωρίζουμε ποια είναι ακριβώς τα δεδομένα τα οποία χρειάζεται να κάνουμε extract από την πηγή δεδομένων.

Incremental data loading

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

Μα θα μου πει κάποιος τι νόημα έχει αυτό που λες.

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

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

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

Για αυτό θα πρέπει να βρω τον τρόπο με τον οποίο θα εντοπίζω τις αλλαγές που έχουν γίνει από την τελευταία φορά που η διαδικασία ETL έχει εκτελεστεί.

Με αυτό θα επιτύχω να έχω μικρό αριθμό εγγραφών

• που θα πρέπει να γίνουν extract από την πηγή με όφελος να έχω μικρό χρόνο σύνδεσης με αυτή, άρα καταναλώνω λίγους πόρους από αυτή
• να επεξεργαστώ που σημαίνει ότι θα χρειαστεί και λιγότερος χρόνος για γίνει η επεξεργασία αυτή με αποτέλεσμα όπως είναι φυσικό να έχω καλύτερη απόδοση (performance)
• με αποτέλεσμα να μειώσω σημαντικά την πιθανότητα να δημιουργήσω διπλοεγγραφές στους πίνακες του DW πράγμα που θα είχα αν κάθε φορά διάβαζα τα πάντα.

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

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

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

Χρήση πεδίου ημερομηνίας που δείχνει το πότε έγινε η αλλαγή

Η τεχνική αυτή κάνει χρήση κάποιου πεδίου ημερομηνίας η οποία υποδηλώνει το πότε έχει γίνει αλλαγή ή εισαγωγή της εγγραφής. Δηλαδή σε κάθε record εκτός από τα πεδία που κρατούν την πληροφορία υπάρχει ακόμα ένα πεδίο που είναι η ημερομηνία που έγινε η αρχική καταχώρηση (insert) ή η αλλαγή (update). Στην ουσία το συγκεκριμένο πεδίο λειτουργεί με την λογική του date metadata column.

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

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

Από πολλούς προτείνετε να γίνει χρήση ενός βοηθητικού πίνακα ο οποίος να περιέχει την ημερομηνία (max date) της τελευταίας εκτέλεσης της διαδικασίας . Αυτός θα ενημερώνεται εφόσον η όλη διαδικασία θα εκτελεστεί ομαλά. Επίσης προτείνεται να γίνει για κάθε πηγή που χρησιμοποιούμε και έχει την ίδια λογική για τον εντοπισμό των αλλαγών να υπάρχει μια εγγραφή για αυτή στο συγκεκριμένο πίνακα .

Χρήση Change Data Capture (CDC)

Αρκετά RDBMS και μέσα σε αυτά και ο SQL Server έχουν την δυνατότητα με την χρήση flags και πινάκων να κρατάνε τις αλλαγές που γίνονται στα δεδομένα. Η τεχνολογία αυτή ονομάζεται Change Data Capture. Περισσότερα για την τεχνολογία αυτή μπορεί να μάθετε παρακολουθώντας το 12o SQL Saturday Night στο οποίο ασχολήθηκα διεξοδικά με αυτή .

Αν το RDBMS υποστηρίζει την συγκεκριμένη δυνατότητα δεν τίθεται θέμα συζήτησης το χρησιμοποιούμε με κλειστά μάτια για να κάνουμε την δουλειά μας.

Η επιβάρυνση που θα έχω στο παραγωγικό σύστημα με την ενεργοποίηση του CDC είναι αμελητέα ιδιαίτερα εάν αυτό είναι σε SQL Server.

Εάν μάλιστα κάνω χρήση του SQL Server 2012 όπου στα SSIS αυτού υπάρχει πλέον ξεχωριστό task αυτό του CDC Control Task τα πράγματα γίνονται εξαιρετικά ευκολότερα. (Σε επόμενο post θα σας εξηγήσω περισσότερα για το πώς λειτουργεί το συγκεκριμένο task)

Χρήση triggers και πινάκων με τις αλλαγές

Μια ακόμα τεχνική που μπορεί να χρησιμοποιηθεί εφόσον έχω την δυνατότητα να κάνω κάποιες επεμβάσεις στο data source είναι να χρησιμοποιήσω triggers για κάθε insert, update, delete όπου μέσα σε αυτούς με την χρήση των inserted και deleted virtual tables που έχω διαθέσιμους στους triggers να γράφω σε trace tables για κάθε πίνακα που χρειάζεται να διαβάσω και να μεταφέρω δεδομένα από αυτόν.

Σίγουρα με τη συγκεκριμένη διαδικασία θα δώσω ένα performance penalty στα transactions που γίνονται στο παραγωγικό σύστημα. To πόσο θα είναι αυτό θα πρέπει να το μετρήσω σε κάθε περίπτωση ξεχωριστά. Επίσης θα πρέπει να δημιουργήσω μια πληθώρα από νέα αντικείμενα που χρειάζονται για να υποστηριχθεί η τεχνική αυτή με ότι συνεπάγεται σε συντήρηση αυτών.

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

Χρήση της τεχνικής extract all , compare, eliminate

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

Με την τεχνική αυτή θα πρέπει κάθε φορά να διαβάζω όλα τα απαραίτητα δεδομένα από την πηγή μου και να τα συγκρίνω με αυτά που διάβασα την τελευταία φορά που εκτέλεσα την διαδικασία μου. Από την διαδικασίας σύγκρισης θα παραχθεί ένα Δ το οποίο ανάλογα θα πρέπει να προωθήσω για ενημέρωση των πινάκων του DW.

Αυτό σημαίνει ότι κάθε φορά θα πρέπει να κρατάω τα δεδομένα της τελευταίας εκτέλεσης με ότι αυτό συνεπάγεται σε χώρο στο δίσκο αλλά και σε I/O για να μπορέσω να τα συγκρίνω με αυτά τις τρέχουσας και ίσως θα πρέπει να λάβω υπόψη μου το γεγονός ότι και αυτά θα πρέπει να τα αποθηκεύσω σε κάποια staging area πριν κάνω την σύγκριση.

Η διαδικασία σύγκρισης είναι μια δαπανηρή εργασία καθώς θα πρέπει να συγκρίνω κάθε εγγραφή ξεχωριστά ανά πεδίο για να βρω τις αλλαγές (updates) . Τα inserts και deletes βρίσκονται σχετικά ευκολότερα.

Επίλογος

Όπως καταλαβαίνουμε από τα παραπάνω πρέπει να επενδύσω χρόνο και φαιά ουσία για να βρω την τεχνική που μου ταιριάζει καθώς είναι σημαντικό για το πώς θα εξελιχθούν οι παράγοντες που αφορούν τα performance, scalability, manageability. Μπούσουλας, ιδανική λύση, best practice ή όπως αλλιώς θέλετε να το ονομάσετε δεν υπάρχει. Φυσικά εύκολα μπορούμε να διατυπώσουμε ότι με την τεχνική CDC τα πράγματα είναι καλύτερα και αυτό είναι αλήθεια, όμως δεν υποστηρίζουν όλα τα RDBS τη τεχνολογία αυτή.