sqlschool.gr logo

articles

Articles of SQLschool.gr Team

Considerations on Data Transformation Phase during ETL process

Antonios Chatzipavlis
Wednesday 04 April 2012

Σε συνέχεια των προηγούμενων μου post που σχετίζονται με την διαδικασία ETL με την οποία μεταφέρονται τα δεδομένα από την πηγή στο DW στα οποία είδαμε τι πρέπει να προσέξουμε στην φάση extract και στην χρήση της staging area, έφτασε η στιγμή να μιλήσουμε για την φάση του data transformation.
Η φάση αυτή είναι ίσως η δυσκολότερη σε σχέση με τις άλλες και μάλιστα απαιτεί και περισσότερο χρόνο ανάπτυξης. Σημαντικό αξίωμα (όπως λέμε στα μαθηματικά) για την υλοποίηση της είναι η κατανόηση με σαφήνεια των απαιτήσεων αλλά και των δεδομένων που υπάρχουν στις πηγές που γίνονται extract και έχουν αναφερθεί στο post αυτό και αυτό. Η εμπειρία μου αλλά και πολλών ακόμα συναδέλφων έχει δείξει ότι η όποια προσπάθεια υλοποίησης της συγκεκριμένης φάσης χωρίς να ικανοποιείται το παραπάνω αξίωμα είναι μαθηματικά βέβαιο ότι θα δημιουργηθεί, όπως λέμε στα χωριά μας, μια τρύπα στο νερό. Παρόλα αυτά στην συγκεκριμένη φάση υπάρχουν κάποιες αρχές/οδηγίες που αν ακολουθηθούν με σεβασμό θα έχουμε εξασφαλίσει δύο βασικά στοιχεία το performance και το manageability της φάσης αυτής, το οποίο φυσικά θα έχει αντίκτυπο σε όλο το ETL process και αυτές είναι:
  1. Τα οποιαδήποτε aggregations (sum, avg κλπ) θα πρέπει να γίνονται όσο το δυνατό περισσότερο σε επίπεδο database και όχι στο ETL όπως με την χρήση των SSIS aggregate transformations καθώς αυτά είναι αρκετά αργά επειδή για να γίνουν πρέπει όλα τα δεδομένα να φορτωθούν στην μνήμη. Εξάλλου το να γίνουν σε επίπεδο database είναι αρκετά πιο γρήγορο και ευκολότερο.
  2.  Για τους ίδιους ακριβώς λόγους που αναφέρθηκαν για aggregations θα πρέπει να κάνουμε και για τα sort operations. Υλοποιώντας τα σε επίπεδο database είναι σίγουρα και ευκολότερο αλλά και γρηγορότερο.
  3.  Προσπαθούμε να έχουμε τα joins που χρειάζονται στα δεδομένα μας σε επίπεδο database καθώς είναι γρηγορότερα και ευκολότερα στην υλοποίηση σε σχέση με τα SSIS Merge Join transformations. Μάλιστα μπορούμε να επιτύχουμε μεγιστοποίηση της απόδοσης σε αυτά όταν γίνονται σε επίπεδο database εάν στους staging πίνακες που έχουμε δημιουργήσει με τα δεδομένα βάλουμε τους κατάλληλους indexes* που θα βοηθήσουν τα joins.
  4.  Προσπαθούμε να κάνουμε τα διάφορα lookup transformations σε επίπεδο βάσης για τους ίδιους ακριβώς λόγους με τα joins. Η δημιουργία κατάλληλων indexes* και εδώ θα βοηθήσει σημαντικά το performance.
  5.  Επειδή τα ETL έχουν την τάση να χρησιμοποιούν αρκετή μνήμη κάνουμε εκτεταμένο memory monitoring σε αυτά με την χρήση των κατάλληλων performance counters ώστε να βρούμε τα πραγματικό μέγεθος μνήμης που αυτά χρειάζονται για την εκτέλεση τους και να ρυθμίσουμε κατάλληλα τα properties όπως αυτά που υπάρχουν στα SSIS Data Flow tasks και είναι τα DefaultBufferMaxSize, DefaultBufferMaxRows, BufferTempStoragePath και BLOBTempStoragePath.
  6.  Συγκρίνουμε πάντα το performance με το παραγόμενο αποτέλεσμα καθώς κανείς δεν θέλει να έχει μεν μια γρήγορη διαδικασία η οποία όμως δεν παράγει το σωστό αποτέλεσμα που οι προδιαγραφές έχουν ορίσει. Για αυτό και θα πρέπει η συνεργασία με τους business key users κρίνεται απαραίτητη σε όλη την διάρκεια της υλοποίησης.
  7.  Υλοποιούμε ένα σύστημα με το οποίο θα έχουμε την δυνατότητα να κάνουμε error handling και tracking. Με αυτό θα πρέπει να έχουμε την δυνατότητα σε επίπεδο εγγραφής να ξέρουμε αν αυτή πέρασε με επιτυχία τα transformation ή όχι και για τα όχι πρέπει να έχουμε την δυνατότητα να ξέρουμε και την αιτία της αποτυχίας. Για αυτό δεν χρειάζεται να κάνουμε πολλά ή να ανακαλύψουμε τον τροχό, έχει φροντίσει ο Ralph Kimball με το να την περιγράψει αναλυτικότατα στο βιβλίο του “The Data Warehouse Lifecycle Toolkit” στο οποίο περιγράφει μια δομή πινάκων που στην ουσία κρατάνε metadata και πληροφορίες για το ποιο ETL έχει εκτελεστεί πότε έχει εκτελεστεί τι λάθη έχει και την ανάλυση αυτών σε επίπεδο record & field και το οποίο θα σας το αναλύσω σε επόμενο post.
/*antonch*/ Σημειώσεις *Η χρήση των indexes βοηθάει στα reads και όχι στα writes. Για το λόγο αυτό θα πρέπει να δημιουργούνται αφού έχω μεταφέρει τα δεδομένα από τις πηγές στους staging πίνακες. Σε διαφορετική περίπτωση θα έχω overhead κατά την εισαγωγή των δεδομένων.

Antonios Chatzipavlis

Antonios Chatzipavlis

Antonios is a Data Solutions Consultant and Trainer. He has been working in IT since 1988. In his career, he has worked as senior developer, IT Manager, Solutions Architect and IT Consultant. Since 1995 he has been devoted on new technologies and software development tools, mainly by Microsoft, either by training company staff and colleagues or assisting them in design, development and implementation as a consultant or chief developer. He has focused in Databases and Data Science since 1995. He specialized in Microsoft SQL Server since version 6.0 in areas like SQL Server Internals, Database Design and Development, Business Intelligence and in 2010 he has started working with Azure Data Platform, NoSQL databases, Big Data Technologies and Machine Learning. He is an active member of many IT communities in Greece, answering colleagues' questions and writing articles in his web site. He is the owner of SQLschool.gr which is a community portal with a lot of information about Microsoft SQL Server. He has been a Microsoft Certified Trainer (MCT) since 2000. Microsoft honored him as MVP on Data Platform due to his activities in SQL Server since 2010. He holds a large number of Microsoft Certifications and Microsoft SQL Server Certifications since version 6.5.

Tip

What's New in SQL Server 2022 - Episodes

More Tips...

Become a member

If you want to receive updates from us become a member to our community.

Connect

Explore

Learn


sqlschool.gr © 2010-2024 All rights reserved

This site uses cookies for operational and analytics purposes only. By continuing to browse this site, you agree to their use.