Μιας και ξεκίνησα με το τελευταίο μου post να ασχολούμαι με το Data Warehouse (DW) λέω να το συνεχίσω και να κάνω μερικά ακόμα βήματα.

Το πρόβλημα

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

Αυτό υπόσχονται ότι παρέχουν οι λύσεις BI.

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

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

· Το γεγονός ότι τα key business data είναι διασκορπισμένα σε πολλά και πιθανότατα ετερογενή συστήματα. Κάτι τέτοιο όπως είναι φυσικό δυσκολεύει την συλλογή των απαραίτητων πληροφοριών. · Αν καταφέρεις να ξεπεράσεις το παραπάνω εμπόδιο το επόμενο είναι ακόμα πιο δύσκολο και αφορά την δυνατότητα να βρεις την σωστή πληροφορία. Την πληροφορία αυτή που σου χρειάζεται για να μπορέσεις να δώσεις την δυνατότητα σε αυτούς που λαμβάνουν τις αποφάσεις να πάρουν την σωστή απόφαση. Αυτό είναι ένα task το οποίο και χρόνο χρειάζεται αλλά θα πρέπει να γίνει έλεγχος τόσο ποιότητας δεδομένων όσο και λαθών σε αυτά. · Τέλος θα πρέπει να απαντήσεις σε μια σειρά από ερωτήσεις που είναι απλές αλλά ουσιαστικές για την εργασία όπως πχ «Πόσα προϊόντα υπάρχουν; Πως αυτά κατανέμονται; Πόσους πελάτες έχουμε; Τι γεωγραφική κατανομή αυτοί έχουν; Κλπ».

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

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

Data Warehousing

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

Συνήθως σε μια λύση Data Warehousing συναντάμε

• Τις πηγές των δεδομένων (data sources). Συνήθως είναι τα OLTP databases ή αρχεία τα οποία δημιουργούνται από εφαρμογές και περιέχουν δεδομένα αυτών των εφαρμογών.
• Μια ή περισσότερες διαδικασίες ETL (Extract Transform Load) με τις οποίες διαβάζονται από τα data sources τα δεδομένα τους, μετατρέπονται σύμφωνα με τους κανόνες που έχουν ορισθεί ώστε αυτά να είναι έγκυρα και φορτώνονται στο DW.
• Tα Data staging areas τα οποία είναι εσωτερικά σημεία (μπορεί να είναι και εξωτερικά) στο DW όπου τοποθετούνται τα δεδομένα από τα data sources με σκοπό αυτά να προετοιμαστούν για την εισαγωγή τους στο DW.
• To relational schema της βάσης που αποτελεί το DW.

Αρκετές λύσεις Data Warehousing πλέον έχουν και άλλα στοιχεία όπως

• Master Data Management (MDM) για την παροχή καθιερωμένων ορισμών στα δεδομένα που χρησιμοποιούνται μέσα στον οργανισμό.
• Data Quality Services (DQS) για την παροχή data cleansing και deduplication των δεδομένων.

Data Warehouse

Θεμέλιο μια ΒΙ λύσης είναι το DW. Με τον όρο Data Warehouse αναφέρονται στην κεντροποιημένη αποθήκη των δεδομένων που μπορούν να χρησιμοποιηθούν για reporting και ανάλυση προς τους επιφορτισμένους με το καθήκον λήψης αποφάσεων.

Ένα DW συνήθως περιέχει μεγάλο όγκο δεδομένων που κυρίως είναι ιστορικά transactions. Επειδή σε αυτό γίνονται πολλά read operations καθώς στην ουσία ρωτάμε τις περισσότερες φορές παρά γράφουμε είναι optimized για read. Οι περιπτώσεις που χρειάζεται να γίνουν write operations είναι αυτές κατά τις οποίες φορτώνουμε τα δεδομένα από τα OLTP συστήματα μας, και αυτές δεν γίνονται συνεχόμενα αλλά σε τακτικά χρονικά διαστήματα.

Ένα DW μπορεί να είναι είτε ένα κεντρικό DW από όπου όλοι αντλούν πληροφορίες, είτε πολλά μικρά DW (departmental) που το καθένα εξυπηρετεί συγκεκριμένο task μέσα στον οργανισμό. Τέλος υπάρχει και η λογική του hub and spoke όπου έχω ένα κεντρικό DW το οποίο συγχρονίζεται με μικρότερα (departmental) Data Marts (Inmon methodology).

Tι πρέπει να προσέξω κατά το σχεδιασμό και την υλοποίηση ενός DW;

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

Καταρχήν θα πρέπει να λάβουμε σοβαρά υπόψη ότι η συγκεκριμένη βάση θα πρέπει να είναι γρήγορη στις αναζητήσεις για μεγάλο (τεράστιο θα έλεγα καλύτερα) αριθμό εγγραφών. Αυτό σημαίνει ότι θα πρέπει να σχεδιαστεί η βάση με γνώμονα αυτό. Έτσι το πρώτο πράγμα το οποίο θα πρέπει να φροντίσουμε να είναι στο δυνατό ελάχιστο βαθμό απαραίτητο η χρήση των JOINS. Μια συχνά προτεινόμενη αλλά και γενικά αποδεκτή λύση είναι η χρήση των star schemas (Kimball’s methodology), με την χρήση των facts και dimension tables.

Θα πρέπει να δοθεί ιδιαίτερη προσοχή στην επιλογή των μετρούμενων που θα υπάρχουν στα facts tables αλλά και στα κλειδιά τα οποία θα πρέπει να υπάρχουν σε αυτό ώστε να μπορεί να γίνεται η σύνδεση με τους dimensional tables. Ένα ακόμα στοιχείο είναι το granularity που θα έχω στην πληροφορία που κρατώ στα fact tables. Εδώ θα πρέπει να επισημάνω ότι σε αρκετές περιπτώσεις έχω την ανάγκη για τα ίδια στοιχεία να έχω διαφορετικό granularity πχ μπορεί να θέλω να έχω αναλυτικά αν γραμμή είδους τα τιμολόγια – πωλήσεις στο fact table αλλά να υπάρχει και η ανάγκη να είναι συγκεντρωτικά ανά τιμολόγιο. Σε αυτές τις περιπτώσεις καλό θα είναι να έχω διαφορετικό fact table!.

Επίσης θα πρέπει να δοθεί προσοχή στο πως θα χειριζόμαστε τις αλλαγές με τη πάροδο του χρόνου πχ μέχρι το Μάρτιο του 2012 ο πωλητής Α ήταν κάτω από τις οδηγίες του Manager Χ και από τον Απρίλιο του 2012 είναι κάτω από τον Manager Ψ. Φυσικά κανένας δεν θα ήθελε όταν γίνει αυτή η αλλαγή οι πωλήσεις που έχει κάνει ο πωλητής όσο ήταν στο Manager X να φαίνονται πλέον στον Manager Ψ. Άρα θα πρέπει αυτό και άλλα παρόμοια σαν αυτό να αντιμετωπιστούν από την αρχή (Slowly Changed Dimensions – R. Kimball).

Ακόμα θα πρέπει, ανάλογα φυσικά με τον οργανισμό που σχεδιάζεται η λύση, να γίνει επισταμένη μελέτη και υλοποίηση στο φυσικό σχεδιασμό της βάσης. Επειδή το σύνηθες είναι να έχουμε τεράστιο όγκο δεδομένων, ιδιαίτερα στους fact tables, καλό θα είναι από την αρχή να έχουμε στην σκέψη μας την λογική του table partitioning σε ξεχωριστά filegroups που το κάθε ένα να είναι σε ξεχωριστό φυσικό δίσκο ούτως ώστε να βελτιστοποιήσω την απόδοση των ερωτημάτων που γίνονται σε αυτά. Αλλά θα έχω και άλλα οφέλη όπως την δυνατότητα να εκτελώ filegroup backups.

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

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

Τί που πρέπει να προσέξω με τα Data Sources;

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

Από τα σημαντικότερα είναι να γίνει η σωστή επιλογή του provider με τον οποίο θα διαβάσω αυτά. Αν και υπάρχουν providers που σου δίνουν την δυνατότητα να διαβάσεις τα πάντα πχ ODBC δεν είναι φρόνιμο να το κάνεις εφόσον για το συγκεκριμένο Data Source υπάρχει native OLEDB provider ο οποίος δίνει καλύτερο performance.

Τα credentials και τα permissions που χρειάζονται για να αποκτηθεί η πρόσβαση σε αυτά δεν είναι κάτι το οποίο θα πρέπει να το περνάμε στο ντούκου. Θα πρέπει να έρθουμε σε επαφή με τους ανθρώπους που έχουν τα δεδομένα αυτά ώστε να μας δοθεί αυτό που πραγματικά χρειαζόμαστε για να μπορέσουμε να έχουμε απρόσκοπτη σύνδεση με τα δεδομένα αυτά.

Το σημείο το οποίο συνήθως μας δημιουργεί τα περισσότερα προβλήματα έχει να κάνει με το format των δεδομένων. Κανένας μας δεν θα ήθελε να δει ξανά μπροστά του θέματα data conversion ειδικά όταν μας δίνουν text files και θέλουμε να κάνουμε convert αριθμούς από text. Κανένας μας δεν θα ήθελε να δει ξανά θέματα data truncation. Κανένας μας δεν θα ήθελε να μην μπορεί να διαβάσει σωστά ημερομηνίες ή να έχει Unicode support θέματα με χαρακτήρες.

Τέλος θα πρέπει να γνωρίζουμε με ακρίβεια κάθε πότε θα διαβάζουμε από αυτά και θα μεταφέρουμε τα δεδομένα στο DW μας. Θα πρέπει να καταλάβουμε ότι δεν είμαστε μόνοι μας. Συνήθως τα συστήματα από τα οποία ζητάμε να αντλήσουμε τα δεδομένα είναι παραγωγικά συστήματα που εξυπηρετούν πιθανότατα χιλιάδες concurrent connections. Δεν θα είναι όμορφο να πάμε την ώρα που υπάρχει το pick της χρήσης των πόρων των συστημάτων αυτών και να ζητάμε να μας φέρει την Άρτα και τα Γιάννενα. Πρέπει να έρθουμε σε επαφή με του διαχειριστές των δεδομένων αυτών ώστε να ορίσουμε μαζί το πότε, πως και με ποιο τρόπο θα γίνεται η μεταφόρτωση των δεδομένων.

Staging Area υπάρχει κάτι που πρέπει να προσέξω;

Αν και υπάρχουν περιπτώσεις όπου μπορείς να διαβάζεις τα δεδομένα από τα data sources και να τα μεταφέρεις αυτόματα στο DW εντούτοις το να τα βάζεις σε μια staging περιοχή σου δίνει την δυνατότητα να κάνεις περισσότερα πράγματα χωρίς να επιβαρύνεις χρονικά και σε πόρους τα data sources συστήματα.

Μπορείς να κάνεις καλύτερο data synchronization με το DW ιδιαίτερα σε περιπτώσεις που έχεις να συνθέσεις την πληροφορία που θα βάλεις σε αυτό από πολλές πηγές. Ασυζητητή μπορείς να κάνεις καλύτερο data validation, cleansing, deduplication, transformation.

To σε τι format θα είναι η περιοχή αυτή είναι ένα ακόμα θέμα το οποίο θα πρέπει να διερευνηθεί. Θα πρέπει να επιλέξεις αν θα είναι database, text ή XML αρχεία, θα είναι συνδυασμός αυτών; Αυτά θα πρέπει να απαντηθούν με γνώμονα την ευκολία διαχείρισης τους και το performance.

Αν είναι database θα είναι στην ίδια βάση του DW; Θα είναι σε ξεχωριστή database; Θα είναι σε ξεχωριστό server; Ποιο θα είναι το collation; Ποια είναι τα server requirements; Το κόστος; Τι χρόνο χρειάζονται για να μεταφερθούν αυτά μέσω του δικτύου; Μήπως θα πρέπει να χρησιμοποιήσω τεχνικές T-SQL για το φόρτωμα τους (BULK INSERT) ή Command line tools όπως bcp;

Τί που πρέπει να προσέξω στις ETL διαδικασίες μου;

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

Πότε, πως και που θα κάνω τυχόν field concatenation ή οποιοδήποτε transformation; Θα το κάνω με το T-SQL; Θα το κάνω με SSIS Derived Column ή κάποιο άλλο SSIS task; Σε ποιο σημείο; Κατά την στιγμή που κάνω data extraction; Θα το κάνω στο staging area;

Όλα αυτά πρέπει να απαντηθούν και υπάρχουν αρκετές παράμετροι που θα με οδηγήσουν στην επιλογή της σωστής απάντησης όπως

• To performance overhead που μπαίνει με το συγκεκριμένο transformation.
• Σε τι βαθμό μπορώ να κάνω querying and updating στο data source ή στο staging area.
• Τι dependencies έχω στα δεδομένα μου όταν πρέπει να κάνω ένα transformation;
• H δυσκολία που υπάρχει στην υλοποίηση του transformation.
• Θα έχω incremental ETL ή κάθε φορά θα διαβάζω τα πάντα

Επίλογος

Καλώς ήρθατε στον μαγικό κόσμο του DW και του ΒΙ. Αρχίζει να μου αρέσει αυτή σειρά των posts και θα ακολουθήσουν, να είμαι  καλά πρώτα ο Θεός, και άλλα…