Εν αναμονή της έναρξης μιας νέας ροής στο ρυθμό Έχουμε ετοιμάσει μια μετάφραση ενδιαφέροντος υλικού.
Αναθεώρηση
Θα μιλήσουμε για ένα αρκετά δημοφιλές μοτίβο με το οποίο οι εφαρμογές χρησιμοποιούν πολλαπλούς χώρους αποθήκευσης δεδομένων, όπου κάθε κατάστημα χρησιμοποιείται για τους δικούς του σκοπούς, για παράδειγμα, για την αποθήκευση της κανονικής μορφής δεδομένων (MySQL, κ.λπ.), για την παροχή προηγμένων δυνατοτήτων αναζήτησης (ElasticSearch, κ.λπ.) .), προσωρινή αποθήκευση (Memcached, κ.λπ.) και άλλα. Συνήθως, όταν χρησιμοποιούνται πολλαπλοί χώροι αποθήκευσης δεδομένων, ένας από αυτούς λειτουργεί ως κύριος χώρος αποθήκευσης και οι άλλοι ως χώροι αποθήκευσης παραγώγων. Το μόνο πρόβλημα είναι πώς να συγχρονίσετε αυτές τις αποθήκες δεδομένων.
Εξετάσαμε μια σειρά από διαφορετικά μοτίβα που προσπάθησαν να λύσουν το πρόβλημα του συγχρονισμού πολλών καταστημάτων, όπως διπλές εγγραφές, κατανεμημένες συναλλαγές κ.λπ. Ωστόσο, αυτές οι προσεγγίσεις έχουν σημαντικούς περιορισμούς όσον αφορά την πραγματική χρήση, την αξιοπιστία και τη συντήρηση. Εκτός από το συγχρονισμό δεδομένων, ορισμένες εφαρμογές πρέπει επίσης να εμπλουτίσουν τα δεδομένα καλώντας εξωτερικές υπηρεσίες.
Η Delta αναπτύχθηκε για να λύσει αυτά τα προβλήματα. Η Delta παρέχει τελικά μια συνεπή πλατφόρμα που βασίζεται σε συμβάντα για συγχρονισμό και εμπλουτισμό δεδομένων.
Υπάρχουσες λύσεις
Διπλή είσοδος
Για να διατηρήσετε δύο αποθήκες δεδομένων σε συγχρονισμό, μπορείτε να χρησιμοποιήσετε τη διπλή εγγραφή, η οποία γράφει στο ένα κατάστημα και στη συνέχεια γράφει στο άλλο αμέσως μετά. Η πρώτη εγγραφή μπορεί να επαναληφθεί και η δεύτερη μπορεί να ακυρωθεί εάν η πρώτη αποτύχει αφού εξαντληθεί ο αριθμός των προσπαθειών. Ωστόσο, οι δύο χώροι αποθήκευσης δεδομένων ενδέχεται να μην συγχρονιστούν εάν αποτύχει η εγγραφή στο δεύτερο χώρο αποθήκευσης. Αυτό το πρόβλημα συνήθως επιλύεται με τη δημιουργία μιας διαδικασίας ανάκτησης που μπορεί να μεταφέρει περιοδικά δεδομένα από την πρώτη αποθήκευση στη δεύτερη ή να το κάνει μόνο εάν εντοπιστούν διαφορές στα δεδομένα.
Προβλήματα:
Η εκτέλεση μιας διαδικασίας ανάκτησης είναι μια συγκεκριμένη εργασία που δεν μπορεί να επαναχρησιμοποιηθεί. Επιπλέον, τα δεδομένα μεταξύ των τοποθεσιών αποθήκευσης παραμένουν εκτός συγχρονισμού μέχρι να πραγματοποιηθεί η διαδικασία επαναφοράς. Η λύση γίνεται πιο περίπλοκη εάν χρησιμοποιούνται περισσότερες από δύο αποθήκες δεδομένων. Τέλος, η διαδικασία επαναφοράς μπορεί να προσθέσει φορτίο στην αρχική πηγή δεδομένων.
Αλλαγή πίνακα καταγραφής
Όταν πραγματοποιούνται αλλαγές σε ένα σύνολο πινάκων (όπως εισαγωγή, ενημέρωση και διαγραφή μιας εγγραφής), οι εγγραφές αλλαγών προστίθενται στον πίνακα καταγραφής ως μέρος της ίδιας συναλλαγής. Ένα άλλο νήμα ή διαδικασία ζητά συνεχώς συμβάντα από τον πίνακα καταγραφής και τα εγγράφει σε έναν ή περισσότερους χώρους αποθήκευσης δεδομένων, εάν είναι απαραίτητο, αφαιρώντας συμβάντα από τον πίνακα καταγραφής αφού επιβεβαιωθεί η εγγραφή από όλα τα καταστήματα.
Προβλήματα:
Αυτό το μοτίβο θα πρέπει να υλοποιηθεί ως βιβλιοθήκη και ιδανικά χωρίς αλλαγή του κώδικα της εφαρμογής που το χρησιμοποιεί. Σε ένα πολυγλωσσικό περιβάλλον, η υλοποίηση μιας τέτοιας βιβλιοθήκης θα πρέπει να υπάρχει σε οποιαδήποτε απαραίτητη γλώσσα, αλλά η διασφάλιση της συνέπειας της λειτουργικότητας και της συμπεριφοράς μεταξύ των γλωσσών είναι πολύ δύσκολη.
Ένα άλλο πρόβλημα έγκειται στη λήψη αλλαγών σχήματος σε συστήματα που δεν υποστηρίζουν αλλαγές σχήματος συναλλαγών [1][2], όπως η MySQL. Επομένως, το μοτίβο της πραγματοποίησης μιας αλλαγής (για παράδειγμα, μιας αλλαγής σχήματος) και της συναλλακτικής καταγραφής της στον πίνακα καταγραφής αλλαγών δεν θα λειτουργεί πάντα.
Κατανεμημένες Συναλλαγές
Οι κατανεμημένες συναλλαγές μπορούν να χρησιμοποιηθούν για τον διαχωρισμό μιας συναλλαγής σε πολλαπλές ετερογενείς αποθήκες δεδομένων, έτσι ώστε η λειτουργία είτε να δεσμεύεται σε όλες τις αποθήκες δεδομένων που χρησιμοποιούνται είτε να μην δεσμεύεται σε κανένα από αυτά.
Προβλήματα:
Οι κατανεμημένες συναλλαγές αποτελούν πολύ μεγάλο πρόβλημα για ετερογενείς αποθήκες δεδομένων. Από τη φύση τους, μπορούν να βασίζονται μόνο στον χαμηλότερο κοινό παρονομαστή των εμπλεκόμενων συστημάτων. Για παράδειγμα, οι συναλλαγές XA μπλοκάρουν την εκτέλεση εάν η διαδικασία εφαρμογής αποτύχει κατά τη φάση προετοιμασίας. Επιπλέον, η XA δεν παρέχει ανίχνευση αδιεξόδου ούτε υποστηρίζει αισιόδοξα σχήματα ελέγχου συγχρονισμού. Επιπλέον, ορισμένα συστήματα όπως το ElasticSearch δεν υποστηρίζουν το XA ή οποιοδήποτε άλλο ετερογενές μοντέλο συναλλαγής. Έτσι, η εξασφάλιση ατομικότητας εγγραφής σε διάφορες τεχνολογίες αποθήκευσης δεδομένων παραμένει ένα πολύ δύσκολο έργο για τις εφαρμογές [3].
Δέλτα
Η Delta σχεδιάστηκε για να αντιμετωπίζει τους περιορισμούς των υπαρχουσών λύσεων συγχρονισμού δεδομένων και επίσης επιτρέπει τον εμπλουτισμό δεδομένων on-the-fly. Στόχος μας ήταν να αφαιρέσουμε όλες αυτές τις πολυπλοκότητες μακριά από τους προγραμματιστές εφαρμογών, ώστε να μπορέσουν να επικεντρωθούν πλήρως στην υλοποίηση της επιχειρηματικής λειτουργικότητας. Στη συνέχεια θα περιγράψουμε το "Movie Search", την πραγματική περίπτωση χρήσης για το Delta του Netflix.
Το Netflix χρησιμοποιεί ευρέως μια αρχιτεκτονική microservice και κάθε microservice συνήθως εξυπηρετεί έναν τύπο δεδομένων. Οι βασικές πληροφορίες για την ταινία περιέχονται σε μια μικρουπηρεσία που ονομάζεται Υπηρεσία Ταινιών και τα σχετικά δεδομένα, όπως πληροφορίες για παραγωγούς, ηθοποιούς, πωλητές κ.λπ. διαχειρίζονται πολλές άλλες μικροϋπηρεσίες (συγκεκριμένα Deal Service, Talent Service και Vendor Service).
Οι επιχειρησιακοί χρήστες στο Netflix Studios χρειάζεται συχνά να κάνουν αναζήτηση σε διάφορα κριτήρια ταινιών, γι' αυτό είναι πολύ σημαντικό για αυτούς να μπορούν να κάνουν αναζήτηση σε όλα τα δεδομένα που σχετίζονται με ταινίες.
Πριν από την Delta, η ομάδα αναζήτησης ταινιών χρειαζόταν να αντλήσει δεδομένα από πολλές μικροϋπηρεσίες πριν από την ευρετηρίαση των δεδομένων της ταινίας. Επιπλέον, η ομάδα έπρεπε να αναπτύξει ένα σύστημα που θα ενημερώνει περιοδικά το ευρετήριο αναζήτησης ζητώντας αλλαγές από άλλες μικροϋπηρεσίες, ακόμα κι αν δεν υπήρχαν καθόλου αλλαγές. Αυτό το σύστημα έγινε γρήγορα περίπλοκο και δύσκολο στη συντήρηση.
Εικόνα 1. Σύστημα ψηφοφορίας προς Delta
Μετά τη χρήση του Delta, το σύστημα απλοποιήθηκε σε ένα σύστημα που βασίζεται σε συμβάντα όπως φαίνεται στο παρακάτω σχήμα. Τα συμβάντα CDC (Change-Data-Capture) αποστέλλονται σε θέματα Keystone Kafka χρησιμοποιώντας το Delta-Connector. Μια εφαρμογή Delta που έχει δημιουργηθεί χρησιμοποιώντας το Delta Stream Processing Framework (με βάση το Flink) λαμβάνει συμβάντα CDC από ένα θέμα, τα εμπλουτίζει καλώντας άλλες μικροϋπηρεσίες και, τέλος, μεταβιβάζει τα εμπλουτισμένα δεδομένα σε ένα ευρετήριο αναζήτησης στο Elasticsearch. Η όλη διαδικασία λαμβάνει χώρα σχεδόν σε πραγματικό χρόνο, δηλαδή μόλις πραγματοποιηθούν αλλαγές στην αποθήκη δεδομένων, τα ευρετήρια αναζήτησης ενημερώνονται.
Εικόνα 2. Διοχέτευση δεδομένων με χρήση Delta
Στις επόμενες ενότητες, θα περιγράψουμε τη λειτουργία του Delta-Connector, το οποίο συνδέεται με την αποθήκευση και δημοσιεύει συμβάντα CDC στο επίπεδο μεταφοράς, το οποίο είναι μια υποδομή μετάδοσης δεδομένων σε πραγματικό χρόνο που δρομολογεί συμβάντα CDC σε θέματα Kafka. Και στο τέλος, θα μιλήσουμε για το πλαίσιο επεξεργασίας ροής Delta, το οποίο μπορούν να χρησιμοποιήσουν οι προγραμματιστές εφαρμογών για την επεξεργασία δεδομένων και τη λογική εμπλουτισμού.
CDC (Change-Data-Capture)
Έχουμε αναπτύξει μια υπηρεσία CDC που ονομάζεται Delta-Connector, η οποία μπορεί να καταγράψει δεσμευμένες αλλαγές από το χώρο αποθήκευσης δεδομένων σε πραγματικό χρόνο και να τις εγγράψει σε μια ροή. Οι αλλαγές σε πραγματικό χρόνο λαμβάνονται από τα αρχεία καταγραφής συναλλαγών και αποθήκευσης. Τα dumps χρησιμοποιούνται επειδή τα αρχεία καταγραφής συναλλαγών συνήθως δεν αποθηκεύουν ολόκληρο το ιστορικό των αλλαγών. Οι αλλαγές συνήθως χαρακτηρίζονται σε σειρά ως συμβάντα Delta, επομένως ο παραλήπτης δεν χρειάζεται να ανησυχεί για την προέλευση της αλλαγής.
Το Delta-Connector υποστηρίζει πολλές πρόσθετες λειτουργίες όπως:
- Δυνατότητα εγγραφής προσαρμοσμένων δεδομένων εξόδου μετά τον Kafka.
- Δυνατότητα ενεργοποίησης χειροκίνητων ταχυτήτων ανά πάσα στιγμή για όλους τους πίνακες, έναν συγκεκριμένο πίνακα ή για συγκεκριμένα πρωτεύοντα κλειδιά.
- Τα Dumps μπορούν να ανακτηθούν σε κομμάτια, επομένως δεν χρειάζεται να ξεκινήσετε ξανά από την αρχή σε περίπτωση αποτυχίας.
- Δεν χρειάζεται να τοποθετήσετε κλειδαριές σε τραπέζια, κάτι που είναι πολύ σημαντικό για να διασφαλιστεί ότι η κυκλοφορία εγγραφής στη βάση δεδομένων δεν θα αποκλειστεί ποτέ από την υπηρεσία μας.
- Υψηλή διαθεσιμότητα λόγω περιττών περιπτώσεων σε ζώνες διαθεσιμότητας AWS.
Αυτήν τη στιγμή υποστηρίζουμε MySQL και Postgres, συμπεριλαμβανομένων των αναπτύξεων σε AWS RDS και Aurora. Υποστηρίζουμε και την Κασσάνδρα (multi-master). Μπορείτε να μάθετε περισσότερες λεπτομέρειες για το Delta-Connector εδώ .
Ο Κάφκα και το στρώμα μεταφοράς
Το επίπεδο μεταφοράς συμβάντων της Delta είναι χτισμένο στην υπηρεσία ανταλλαγής μηνυμάτων της πλατφόρμας .
Ιστορικά, η ανάρτηση στο Netflix έχει βελτιστοποιηθεί για προσβασιμότητα και όχι για μακροζωία (δείτε παρακάτω). ). Η αντιστάθμιση ήταν πιθανή ασυνέπεια δεδομένων μεσίτη σε διάφορα σενάρια αιχμής. Για παράδειγμα, ακάθαρτη εκλογή αρχηγού είναι υπεύθυνος για τον παραλήπτη που ενδέχεται να έχει διπλότυπα ή χαμένα συμβάντα.
Με τη Delta, θέλαμε ισχυρότερες εγγυήσεις ανθεκτικότητας για να διασφαλίσουμε την παράδοση συμβάντων CDC σε παράγωγα καταστήματα. Για το σκοπό αυτό, προτείναμε ένα ειδικά σχεδιασμένο σύμπλεγμα Kafka ως αντικείμενο πρώτης κατηγορίας. Μπορείτε να δείτε ορισμένες ρυθμίσεις μεσίτη στον παρακάτω πίνακα:
Στα συμπλέγματα Keystone Kafka, ακάθαρτη εκλογή αρχηγού συνήθως περιλαμβάνονται για να διασφαλιστεί η προσβασιμότητα του εκδότη. Αυτό μπορεί να οδηγήσει σε απώλεια μηνύματος εάν ένα μη συγχρονισμένο αντίγραφο επιλεγεί ως ηγέτης. Για ένα νέο σύμπλεγμα Kafka υψηλής διαθεσιμότητας, η επιλογή ακάθαρτη εκλογή αρχηγού απενεργοποιήθηκε για να αποφευχθεί η απώλεια μηνύματος.
Αυξηθήκαμε επίσης παράγοντας αναπαραγωγής από 2 έως 3 και ελάχιστα insync αντίγραφα 1 έως 2. Οι εκδότες που γράφουν σε αυτό το σύμπλεγμα απαιτούν αποδοχές από όλους τους άλλους, διασφαλίζοντας ότι 2 στα 3 αντίγραφα έχουν τα πιο πρόσφατα μηνύματα που αποστέλλονται από τον εκδότη.
Όταν μια περίπτωση μεσίτη τερματίζεται, μια νέα παρουσία αντικαθιστά την παλιά. Ωστόσο, ο νέος μεσίτης θα χρειαστεί να προλάβει τα μη συγχρονισμένα αντίγραφα, κάτι που μπορεί να διαρκέσει αρκετές ώρες. Για να μειώσουμε τον χρόνο ανάκτησης για αυτό το σενάριο, αρχίσαμε να χρησιμοποιούμε μπλοκ αποθήκευσης δεδομένων (Amazon Elastic Block Store) αντί για τοπικούς δίσκους μεσίτη. Όταν μια νέα παρουσία αντικαθιστά μια τερματισμένη παρουσία μεσίτη, επισυνάπτει τον τόμο EBS που είχε η τερματισμένη παρουσία και αρχίζει να έρχεται με νέα μηνύματα. Αυτή η διαδικασία μειώνει τον χρόνο εκκαθάρισης του ανεκτέλετου από ώρες σε λεπτά, επειδή το νέο στιγμιότυπο δεν χρειάζεται πλέον να αναπαραχθεί από μια κενή κατάσταση. Γενικά, η χωριστή αποθήκευση και οι κύκλοι ζωής μεσίτη μειώνουν σημαντικά τον αντίκτυπο της αλλαγής μεσίτη.
Για να αυξήσουμε περαιτέρω την εγγύηση παράδοσης δεδομένων, χρησιμοποιήσαμε για ανίχνευση τυχόν απώλειας μηνύματος υπό ακραίες συνθήκες (για παράδειγμα, αποσυγχρονισμός ρολογιού στον οδηγό κατάτμησης).
Πλαίσιο επεξεργασίας ροής
Το επίπεδο επεξεργασίας της Delta είναι χτισμένο πάνω από την πλατφόρμα Netflix SPaaS, η οποία παρέχει ενσωμάτωση του Apache Flink με το οικοσύστημα Netflix. Η πλατφόρμα παρέχει μια διεπαφή χρήστη που διαχειρίζεται την ανάπτυξη εργασιών Flink και την ενορχήστρωση των συμπλεγμάτων Flink πάνω από την πλατφόρμα διαχείρισης κοντέινερ Titus. Η διεπαφή διαχειρίζεται επίσης τις διαμορφώσεις εργασιών και επιτρέπει στους χρήστες να κάνουν αλλαγές διαμόρφωσης δυναμικά χωρίς να χρειάζεται να μεταγλωττίσουν εκ νέου εργασίες Flink.
Η Delta παρέχει ένα πλαίσιο επεξεργασίας ροής που βασίζεται στο Flink και στο SPaaS που χρησιμοποιεί με βάση σχολιασμούς DSL (Domain Specific Language) για αφηρημένες τεχνικές λεπτομέρειες. Για παράδειγμα, για να ορίσετε το βήμα στο οποίο τα συμβάντα θα εμπλουτιστούν με την κλήση εξωτερικών υπηρεσιών, οι χρήστες πρέπει να γράψουν το ακόλουθο DSL και το πλαίσιο θα δημιουργήσει ένα μοντέλο με βάση αυτό, το οποίο θα εκτελεστεί από το Flink.
Εικόνα 3. Παράδειγμα εμπλουτισμού σε DSL στο Delta
Το πλαίσιο επεξεργασίας όχι μόνο μειώνει την καμπύλη μάθησης, αλλά παρέχει επίσης κοινά χαρακτηριστικά επεξεργασίας ροής, όπως η αντιγραφή, η σχηματοποίηση και η ευελιξία και η ανθεκτικότητα για την επίλυση κοινών λειτουργικών προβλημάτων.
Το Delta Stream Processing Framework αποτελείται από δύο βασικές ενότητες, τη μονάδα DSL & API και την ενότητα Runtime. Η ενότητα DSL & API παρέχει API DSL και UDF (User-Defined-Function) έτσι ώστε οι χρήστες να μπορούν να γράφουν τη δική τους λογική επεξεργασίας (όπως φιλτράρισμα ή μετασχηματισμοί). Η ενότητα Runtime παρέχει μια υλοποίηση ενός αναλυτή DSL που δημιουργεί μια εσωτερική αναπαράσταση των βημάτων επεξεργασίας σε μοντέλα DAG. Το στοιχείο Εκτέλεση ερμηνεύει τα μοντέλα DAG για να αρχικοποιήσει τις πραγματικές δηλώσεις Flink και τελικά να εκτελέσει την εφαρμογή Flink. Η αρχιτεκτονική του πλαισίου φαίνεται στο παρακάτω σχήμα.
Εικόνα 4. Αρχιτεκτονική του πλαισίου επεξεργασίας ροής Delta
Αυτή η προσέγγιση έχει πολλά πλεονεκτήματα:
- Οι χρήστες μπορούν να επικεντρωθούν στην επιχειρηματική τους λογική χωρίς να χρειάζεται να εμβαθύνουν στις ιδιαιτερότητες του Flink ή της δομής SPaaS.
- Η βελτιστοποίηση μπορεί να γίνει με τρόπο που είναι διαφανής για τους χρήστες και τα σφάλματα μπορούν να διορθωθούν χωρίς να απαιτούνται αλλαγές στον κωδικό χρήστη (UDF).
- Η εμπειρία εφαρμογής Delta απλοποιείται για τους χρήστες, επειδή η πλατφόρμα παρέχει ευελιξία και ανθεκτικότητα από το κουτί και συλλέγει μια ποικιλία λεπτομερών μετρήσεων που μπορούν να χρησιμοποιηθούν για ειδοποιήσεις.
Παραγωγική χρήση
Η Delta βρίσκεται στην παραγωγή για πάνω από ένα χρόνο και παίζει βασικό ρόλο σε πολλές εφαρμογές του Netflix Studio. Βοήθησε τις ομάδες να εφαρμόσουν περιπτώσεις χρήσης, όπως ευρετηρίαση αναζήτησης, αποθήκευση δεδομένων και ροές εργασίας που βασίζονται σε συμβάντα. Παρακάτω είναι μια επισκόπηση της αρχιτεκτονικής υψηλού επιπέδου της πλατφόρμας Delta.
Εικόνα 5. Η αρχιτεκτονική υψηλού επιπέδου της Delta.
Ευχαριστώ
Θα θέλαμε να ευχαριστήσουμε τους ακόλουθους ανθρώπους που συμμετείχαν στη δημιουργία και ανάπτυξη της Delta στο Netflix: Allen Wang, Charles Zhao, Jaebin Yoon, Josh Snyder, Kasturi Chatterjee, Mark Cho, Olof Johansson, Piyush Goyal, Prashanth Ramdas, Raghuram Onti Srinivasan, Sandeep Gupta, Steven Wu, Tharanga Gamaethige, Yun Wang και Zhenzhong Xu.
πηγές
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Επεξεργασία εκδηλώσεων στο Διαδίκτυο. Commun. ACM 62(5): 43–49 (2019). DOI:
: "Εργαλείο δημιουργίας δεδομένων για το Amazon Redshift Storage."
Πηγή: www.habr.com