Αυτό το άρθρο είναι μια μετάφραση του άρθρου μου για το μέσο - , το οποίο αποδείχθηκε αρκετά δημοφιλές, πιθανώς λόγω της απλότητάς του. Ως εκ τούτου, αποφάσισα να το γράψω στα ρωσικά και να προσθέσω λίγο για να καταστήσω σαφές σε έναν απλό άνθρωπο που δεν είναι ειδικός δεδομένων τι είναι η αποθήκη δεδομένων (DW) και τι είναι η λίμνη δεδομένων (Λίμνη δεδομένων) και πώς συνεννοηθείτε μαζί.
Γιατί ήθελα να γράψω για τη λίμνη δεδομένων; Δουλεύω με δεδομένα και αναλυτικά στοιχεία για πάνω από 10 χρόνια και τώρα σίγουρα δουλεύω με μεγάλα δεδομένα στο Amazon Alexa AI στο Κέμπριτζ, το οποίο βρίσκεται στη Βοστώνη, αν και ζω στη Βικτώρια στο νησί Βανκούβερ και επισκέπτομαι συχνά τη Βοστώνη, το Σιάτλ , και στο Βανκούβερ, και μερικές φορές ακόμη και στη Μόσχα, μιλάω σε συνέδρια. Γράφω και κατά καιρούς, αλλά γράφω κυρίως στα αγγλικά, και έχω ήδη γράψει , έχω επίσης την ανάγκη να μοιράζομαι τις τάσεις των αναλυτικών στοιχείων από τη Βόρεια Αμερική και μερικές φορές γράφω .
Πάντα εργαζόμουν με αποθήκες δεδομένων και από το 2015 άρχισα να συνεργάζομαι στενά με τις Υπηρεσίες Ιστού της Amazon και γενικά στράφηκα στο cloud analytics (AWS, Azure, GCP). Παρατήρησα την εξέλιξη των λύσεων ανάλυσης από το 2007 και εργάστηκα ακόμη και για τον προμηθευτή αποθήκης δεδομένων Teradata και την υλοποίησα στη Sberbank, και τότε εμφανίστηκαν τα Big Data with Hadoop. Όλοι άρχισαν να λένε ότι η εποχή της αποθήκευσης είχε περάσει και τώρα όλα ήταν στο Hadoop, και μετά άρχισαν να μιλάνε για τη Λίμνη των Δεδομένων, ξανά, ότι τώρα το τέλος της αποθήκης δεδομένων είχε έρθει σίγουρα. Αλλά ευτυχώς (ίσως δυστυχώς για κάποιους που κέρδισαν πολλά χρήματα δημιουργώντας το Hadoop), η αποθήκη δεδομένων δεν χάθηκε.
Σε αυτό το άρθρο θα δούμε τι είναι μια λίμνη δεδομένων. Αυτό το άρθρο προορίζεται για άτομα που έχουν μικρή ή καθόλου εμπειρία με αποθήκες δεδομένων.
Στην εικόνα είναι η λίμνη Bled, αυτή είναι μια από τις αγαπημένες μου λίμνες, αν και ήμουν εκεί μόνο μια φορά, τη θυμόμουν για το υπόλοιπο της ζωής μου. Αλλά θα μιλήσουμε για έναν άλλο τύπο λίμνης - μια λίμνη δεδομένων. Ίσως πολλοί από εσάς να έχετε ήδη ακούσει για αυτόν τον όρο περισσότερες από μία φορές, αλλά ένας ακόμη ορισμός δεν θα βλάψει κανέναν.
Πρώτα απ 'όλα, εδώ είναι οι πιο δημοφιλείς ορισμοί μιας λίμνης δεδομένων:
"μια αποθήκευση αρχείων όλων των τύπων ακατέργαστων δεδομένων που είναι διαθέσιμα για ανάλυση από οποιονδήποτε στον οργανισμό" - Martin Fowler.
«Αν νομίζετε ότι ένα data mart είναι ένα μπουκάλι νερό - καθαρισμένο, συσκευασμένο και συσκευασμένο για βολική κατανάλωση, τότε μια λίμνη δεδομένων είναι μια τεράστια δεξαμενή νερού στη φυσική της μορφή. Χρήστες, μπορώ να μαζέψω νερό για τον εαυτό μου, να βουτήξω βαθιά, να εξερευνήσω» - James Dixon.
Τώρα γνωρίζουμε με βεβαιότητα ότι μια λίμνη δεδομένων έχει να κάνει με την ανάλυση, μας επιτρέπει να αποθηκεύουμε μεγάλες ποσότητες δεδομένων στην αρχική της μορφή και έχουμε την απαραίτητη και βολική πρόσβαση στα δεδομένα.
Συχνά μου αρέσει να απλοποιώ τα πράγματα, αν μπορώ να εξηγήσω έναν περίπλοκο όρο με απλά λόγια, τότε καταλαβαίνω μόνος μου πώς λειτουργεί και σε τι χρειάζεται. Μια μέρα, χάζευα στη συλλογή φωτογραφιών του iPhone, και με ξημέρωσε, αυτή είναι μια πραγματική λίμνη δεδομένων, έκανα ακόμη και μια διαφάνεια για συνέδρια:
Όλα είναι πολύ απλά. Τραβάμε μια φωτογραφία στο τηλέφωνο, η φωτογραφία αποθηκεύεται στο τηλέφωνο και μπορεί να αποθηκευτεί στο iCloud (αποθήκευση αρχείων cloud). Το τηλέφωνο συλλέγει επίσης μεταδεδομένα φωτογραφιών: τι εμφανίζεται, γεωγραφική ετικέτα, ώρα. Ως αποτέλεσμα, μπορούμε να χρησιμοποιήσουμε το φιλικό περιβάλλον του iPhone για να βρούμε τη φωτογραφία μας και βλέπουμε ακόμη και ενδείξεις, για παράδειγμα, όταν ψάχνω για φωτογραφίες με τη λέξη φωτιά, βρίσκω 3 φωτογραφίες με εικόνα πυρκαγιάς. Για μένα, αυτό είναι ακριβώς σαν ένα εργαλείο Business Intelligence που λειτουργεί πολύ γρήγορα και με ακρίβεια.
Και φυσικά, δεν πρέπει να ξεχνάμε την ασφάλεια (εξουσιοδότηση και έλεγχος ταυτότητας), διαφορετικά τα δεδομένα μας μπορούν εύκολα να καταλήξουν στον δημόσιο τομέα. Υπάρχουν πολλά νέα σχετικά με μεγάλες εταιρείες και νεοσύστατες επιχειρήσεις των οποίων τα δεδομένα έγιναν δημόσια διαθέσιμα λόγω της αμέλειας των προγραμματιστών και της μη τήρησης απλών κανόνων.
Ακόμη και μια τόσο απλή εικόνα μας βοηθά να φανταστούμε τι είναι μια λίμνη δεδομένων, τις διαφορές της από μια παραδοσιακή αποθήκη δεδομένων και τα κύρια στοιχεία της:
- Τα δεδομένα φορτώνονται (Η κατάποση) είναι ένα βασικό συστατικό της λίμνης δεδομένων. Τα δεδομένα μπορούν να εισέλθουν στην αποθήκη δεδομένων με δύο τρόπους - παρτίδα (φόρτωση κατά διαστήματα) και ροή (ροή δεδομένων).
- Αποθήκευση αρχείων (Αποθήκευση) είναι το κύριο συστατικό της Λίμνης Δεδομένων. Χρειαζόμασταν η αποθήκευση να είναι εύκολα επεκτάσιμη, εξαιρετικά αξιόπιστη και χαμηλού κόστους. Για παράδειγμα, στο AWS είναι S3.
- Κατάλογος και Αναζήτηση (Κατάλογος και Αναζήτηση) - για να αποφύγουμε το Data Swamp (αυτό συμβαίνει όταν απορρίπτουμε όλα τα δεδομένα σε ένα σωρό και μετά είναι αδύνατο να εργαστούμε μαζί του), πρέπει να δημιουργήσουμε ένα επίπεδο μεταδεδομένων για να ταξινομήσουμε τα δεδομένα ώστε οι χρήστες να βρίσκουν εύκολα τα δεδομένα που χρειάζονται για ανάλυση. Επιπλέον, μπορείτε να χρησιμοποιήσετε πρόσθετες λύσεις αναζήτησης όπως το ElasticSearch. Η αναζήτηση βοηθά τον χρήστη να βρει τα απαιτούμενα δεδομένα μέσω μιας φιλικής προς το χρήστη διεπαφής.
- Επεξεργασία (Διαδικασία) - αυτό το βήμα είναι υπεύθυνο για την επεξεργασία και τη μετατροπή δεδομένων. Μπορούμε να μετατρέψουμε δεδομένα, να αλλάξουμε τη δομή τους, να τα καθαρίσουμε και πολλά άλλα.
- Ασφάλεια (Ασφάλεια) - Είναι σημαντικό να αφιερώσετε χρόνο στον σχεδιασμό ασφάλειας της λύσης. Για παράδειγμα, κρυπτογράφηση δεδομένων κατά την αποθήκευση, την επεξεργασία και τη φόρτωση. Είναι σημαντικό να χρησιμοποιείτε μεθόδους ελέγχου ταυτότητας και εξουσιοδότησης. Τέλος, απαιτείται ένα εργαλείο ελέγχου.
Από πρακτική άποψη, μπορούμε να χαρακτηρίσουμε μια λίμνη δεδομένων με τρία χαρακτηριστικά:
- Συλλέξτε και αποθηκεύστε οτιδήποτε — η λίμνη δεδομένων περιέχει όλα τα δεδομένα, τόσο ακατέργαστα μη επεξεργασμένα δεδομένα για οποιαδήποτε χρονική περίοδο όσο και επεξεργασμένα/καθαρισμένα δεδομένα.
- Βαθιά σάρωση — μια λίμνη δεδομένων επιτρέπει στους χρήστες να εξερευνούν και να αναλύουν δεδομένα.
- Ευέλικτη πρόσβαση — Η λίμνη δεδομένων παρέχει ευέλικτη πρόσβαση για διαφορετικά δεδομένα και διαφορετικά σενάρια.
Τώρα μπορούμε να μιλήσουμε για τη διαφορά μεταξύ μιας αποθήκης δεδομένων και μιας λίμνης δεδομένων. Συνήθως οι άνθρωποι ρωτούν:
- Τι γίνεται με την αποθήκη δεδομένων;
- Αντικαθιστούμε την αποθήκη δεδομένων με λίμνη δεδομένων ή την επεκτείνουμε;
- Είναι ακόμα δυνατό να γίνει χωρίς μια λίμνη δεδομένων;
Εν ολίγοις, δεν υπάρχει ξεκάθαρη απάντηση. Όλα εξαρτώνται από τη συγκεκριμένη κατάσταση, τις ικανότητες της ομάδας και τον προϋπολογισμό. Για παράδειγμα, η μετεγκατάσταση μιας αποθήκης δεδομένων στην Oracle στο AWS και η δημιουργία μιας λίμνης δεδομένων από μια θυγατρική της Amazon - Woot - .
Από την άλλη πλευρά, ο πωλητής Snowflake λέει ότι δεν χρειάζεται πλέον να σκέφτεστε μια λίμνη δεδομένων, καθώς η πλατφόρμα δεδομένων τους (μέχρι το 2020 ήταν μια αποθήκη δεδομένων) σας επιτρέπει να συνδυάσετε τόσο μια λίμνη δεδομένων όσο και μια αποθήκη δεδομένων. Δεν έχω δουλέψει πολύ με το Snowflake και είναι πραγματικά ένα μοναδικό προϊόν που μπορεί να το κάνει αυτό. Η τιμή του τεύχους είναι άλλο θέμα.
Συμπερασματικά, η προσωπική μου άποψη είναι ότι χρειαζόμαστε ακόμα μια αποθήκη δεδομένων ως κύρια πηγή δεδομένων για την αναφορά μας και ότι δεν ταιριάζει το αποθηκεύουμε σε μια λίμνη δεδομένων. Όλος ο ρόλος των αναλυτικών στοιχείων είναι να παρέχει εύκολη πρόσβαση στις επιχειρήσεις για τη λήψη αποφάσεων. Ό,τι και να πει κανείς, οι επιχειρησιακοί χρήστες εργάζονται πιο αποτελεσματικά με μια αποθήκη δεδομένων από μια λίμνη δεδομένων, για παράδειγμα στο Amazon - υπάρχει το Redshift (αναλυτική αποθήκη δεδομένων) και υπάρχει το Redshift Spectrum/Athena (διεπαφή SQL για μια λίμνη δεδομένων στο S3 βάσει Κυψέλη/Πρέστο). Το ίδιο ισχύει και για άλλες σύγχρονες αποθήκες αναλυτικών δεδομένων.
Ας δούμε μια τυπική αρχιτεκτονική αποθήκης δεδομένων:
Αυτή είναι μια κλασική λύση. Έχουμε συστήματα πηγής, χρησιμοποιώντας ETL/ELT αντιγράφουμε δεδομένα σε μια αποθήκη αναλυτικών δεδομένων και τα συνδέουμε με μια λύση Business Intelligence (το αγαπημένο μου είναι το Tableau, τι γίνεται με το δικό σας;).
Αυτή η λύση έχει τα ακόλουθα μειονεκτήματα:
- Οι λειτουργίες ETL/ELT απαιτούν χρόνο και πόρους.
- Κατά κανόνα, η μνήμη για την αποθήκευση δεδομένων σε μια αποθήκη αναλυτικών δεδομένων δεν είναι φθηνή (για παράδειγμα, Redshift, BigQuery, Teradata), καθώς πρέπει να αγοράσουμε ένα ολόκληρο σύμπλεγμα.
- Οι επαγγελματίες χρήστες έχουν πρόσβαση σε καθαρά και συχνά συγκεντρωτικά δεδομένα και δεν έχουν πρόσβαση σε ανεπεξέργαστα δεδομένα.
Φυσικά, όλα εξαρτώνται από την περίπτωσή σας. Εάν δεν έχετε προβλήματα με την αποθήκη δεδομένων σας, τότε δεν χρειάζεστε καθόλου λίμνη δεδομένων. Αλλά όταν προκύπτουν προβλήματα με την έλλειψη χώρου, ισχύος ή τιμής παίζει βασικό ρόλο, τότε μπορείτε να εξετάσετε την επιλογή μιας λίμνης δεδομένων. Αυτός είναι ο λόγος για τον οποίο η λίμνη δεδομένων είναι πολύ δημοφιλής. Ακολουθεί ένα παράδειγμα αρχιτεκτονικής λίμνης δεδομένων:
Χρησιμοποιώντας την προσέγγιση της λίμνης δεδομένων, φορτώνουμε ακατέργαστα δεδομένα στη λίμνη δεδομένων μας (παρτίδα ή ροή) και στη συνέχεια επεξεργαζόμαστε τα δεδομένα όπως απαιτείται. Η λίμνη δεδομένων επιτρέπει στους επιχειρηματίες χρήστες να δημιουργούν τους δικούς τους μετασχηματισμούς δεδομένων (ETL/ELT) ή να αναλύουν δεδομένα σε λύσεις Business Intelligence (εάν υπάρχει διαθέσιμος ο απαραίτητος οδηγός).
Ο στόχος οποιασδήποτε λύσης αναλυτικών στοιχείων είναι η εξυπηρέτηση των επιχειρηματικών χρηστών. Επομένως, πρέπει πάντα να εργαζόμαστε σύμφωνα με τις επιχειρηματικές απαιτήσεις. (Στο Amazon αυτή είναι μια από τις αρχές - η εργασία προς τα πίσω).
Δουλεύοντας τόσο με μια αποθήκη δεδομένων όσο και με μια λίμνη δεδομένων, μπορούμε να συγκρίνουμε και τις δύο λύσεις:
Το κύριο συμπέρασμα που μπορεί να εξαχθεί είναι ότι η αποθήκη δεδομένων δεν ανταγωνίζεται τη λίμνη δεδομένων, αλλά μάλλον τη συμπληρώνει. Αλλά είναι στο χέρι σας να αποφασίσετε τι είναι σωστό για την περίπτωσή σας. Είναι πάντα ενδιαφέρον να το δοκιμάζετε μόνοι σας και να βγάλετε τα σωστά συμπεράσματα.
Θα ήθελα επίσης να σας πω μια από τις περιπτώσεις που άρχισα να χρησιμοποιώ την προσέγγιση της λίμνης δεδομένων. Όλα είναι αρκετά ασήμαντα, προσπάθησα να χρησιμοποιήσω ένα εργαλείο ELT (είχαμε Matillion ETL) και Amazon Redshift, η λύση μου λειτούργησε, αλλά δεν ταιριάζει στις απαιτήσεις.
Χρειάστηκε να πάρω αρχεία καταγραφής ιστού, να τα μετατρέψω και να τα συγκεντρώσω για να παρέχω δεδομένα για 2 περιπτώσεις:
- Η ομάδα μάρκετινγκ ήθελε να αναλύσει τη δραστηριότητα των ρομπότ για SEO
- Το ΙΤ ήθελε να εξετάσει τις μετρήσεις απόδοσης ιστότοπου
Πολύ απλά, πολύ απλά κούτσουρα. Εδώ είναι ένα παράδειγμα:
https 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188
192.168.131.39:2817 10.0.0.1:80 0.086 0.048 0.037 200 200 0 57
"GET https://www.example.com:443/ HTTP/1.1" "curl/7.46.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337281-1d84f3d73c47ec4e58577259" "www.example.com" "arn:aws:acm:us-east-2:123456789012:certificate/12345678-1234-1234-1234-123456789012"
1 2018-07-02T22:22:48.364000Z "authenticate,forward" "-" "-"Ένα αρχείο ζύγιζε 1-4 megabyte.
Υπήρχε όμως μια δυσκολία. Είχαμε 7 domains σε όλο τον κόσμο και δημιουργήθηκαν 7000 χιλιάδες αρχεία σε μια μέρα. Αυτός δεν είναι πολύ μεγαλύτερος όγκος, μόνο 50 gigabyte. Αλλά το μέγεθος του συμπλέγματος Redshift μας ήταν επίσης μικρό (4 κόμβοι). Η φόρτωση ενός αρχείου με τον παραδοσιακό τρόπο κράτησε περίπου ένα λεπτό. Δηλαδή, το πρόβλημα δεν λύθηκε κατά μέτωπο. Και αυτό συνέβη όταν αποφάσισα να χρησιμοποιήσω την προσέγγιση της λίμνης δεδομένων. Η λύση έμοιαζε κάπως έτσι:
Είναι αρκετά απλό (θέλω να σημειώσω ότι το πλεονέκτημα της εργασίας στο cloud είναι η απλότητα). Χρησιμοποίησα:
- AWS Elastic Map Reduce (Hadoop) για υπολογιστική ισχύ
- Το AWS S3 ως αποθήκευση αρχείων με δυνατότητα κρυπτογράφησης δεδομένων και περιορισμού της πρόσβασης
- Spark ως υπολογιστική ισχύς InMemory και PySpark για λογική και μετασχηματισμό δεδομένων
- Παρκέ ως αποτέλεσμα του Spark
- Το AWS Glue Crawler ως συλλέκτης μεταδεδομένων σχετικά με νέα δεδομένα και κατατμήσεις
- Redshift Spectrum ως διεπαφή SQL στη λίμνη δεδομένων για υπάρχοντες χρήστες Redshift
Το μικρότερο σύμπλεγμα EMR+Spark επεξεργάστηκε ολόκληρη τη στοίβα των αρχείων σε 30 λεπτά. Υπάρχουν και άλλες περιπτώσεις για το AWS, ειδικά πολλές που σχετίζονται με την Alexa, όπου υπάρχουν πολλά δεδομένα.
Μόλις πρόσφατα έμαθα ότι ένα από τα μειονεκτήματα μιας λίμνης δεδομένων είναι το GDPR. Το πρόβλημα είναι όταν ο πελάτης ζητά να το διαγράψει και τα δεδομένα βρίσκονται σε ένα από τα αρχεία, δεν μπορούμε να χρησιμοποιήσουμε τη γλώσσα χειρισμού δεδομένων και τη λειτουργία DELETE όπως σε μια βάση δεδομένων.
Ελπίζω ότι αυτό το άρθρο έχει διευκρινίσει τη διαφορά μεταξύ μιας αποθήκης δεδομένων και μιας λίμνης δεδομένων. Αν σας ενδιαφέρει, μπορώ να μεταφράσω περισσότερα άρθρα μου ή άρθρα επαγγελματιών που διάβασα. Και επίσης μιλήστε για τις λύσεις με τις οποίες δουλεύω και την αρχιτεκτονική τους.
Πηγή: www.habr.com