Η αγορά για κατανεμημένους υπολογιστές και μεγάλα δεδομένα, σύμφωνα με , αυξάνεται κατά 18-19% ετησίως. Αυτό σημαίνει ότι το θέμα της επιλογής λογισμικού για αυτούς τους σκοπούς παραμένει σχετικό. Σε αυτήν την ανάρτηση, θα ξεκινήσουμε με το γιατί χρειαζόμαστε κατανεμημένους υπολογιστές, θα σταθούμε λεπτομερέστερα στην επιλογή λογισμικού, θα μιλήσουμε για τη χρήση του Hadoop με το Cloudera και τέλος θα μιλήσουμε για την επιλογή υλικού και πώς επηρεάζει την απόδοση με διαφορετικούς τρόπους.
Γιατί χρειαζόμαστε κατανεμημένους υπολογιστές στις συνηθισμένες επιχειρήσεις; Όλα είναι απλά και πολύπλοκα ταυτόχρονα. Απλό - γιατί στις περισσότερες περιπτώσεις εκτελούμε σχετικά απλούς υπολογισμούς ανά μονάδα πληροφοριών. Δύσκολο - γιατί υπάρχουν πολλές τέτοιες πληροφορίες. Τόσα πολλά. Κατά συνέπεια, πρέπει . Έτσι, οι περιπτώσεις χρήσης είναι αρκετά καθολικές: οι υπολογισμοί μπορούν να εφαρμοστούν οπουδήποτε απαιτείται για να ληφθεί υπόψη ένας μεγάλος αριθμός μετρήσεων σε έναν ακόμη μεγαλύτερο πίνακα δεδομένων.
Ένα πρόσφατο παράδειγμα: Dodo Pizza με βάση μια ανάλυση της βάσης παραγγελιών πελατών, ότι όταν επιλέγουν μια πίτσα με αυθαίρετες επικαλύψεις, οι χρήστες συνήθως λειτουργούν με μόνο έξι βασικά σετ συστατικών συν μερικά τυχαία. Αντίστοιχα, η πιτσαρία προσάρμοσε τις αγορές. Επιπλέον, μπόρεσε να προτείνει καλύτερα πρόσθετα προϊόντα που προσφέρονται στο στάδιο της παραγγελίας στους χρήστες, γεγονός που αύξησε τα κέρδη.
Ένα άλλο παράδειγμα: Τα εμπορεύματα επέτρεψαν στην H&M να μειώσει τη συλλογή σε μεμονωμένα καταστήματα κατά 40%, διατηρώντας παράλληλα το επίπεδο των πωλήσεων. Αυτό επιτεύχθηκε με την εξαίρεση των θέσεων χαμηλής πώλησης και η εποχικότητα λήφθηκε υπόψη στους υπολογισμούς.
Επιλογή εργαλείου
Το βιομηχανικό πρότυπο για αυτό το είδος υπολογιστών είναι το Hadoop. Γιατί; Επειδή το Hadoop είναι ένα εξαιρετικό, καλά τεκμηριωμένο πλαίσιο (το ίδιο Habr δίνει πολλά λεπτομερή άρθρα για αυτό το θέμα), το οποίο συνοδεύεται από μια ολόκληρη σειρά βοηθητικών προγραμμάτων και βιβλιοθηκών. Μπορείτε να υποβάλετε τεράστια σύνολα τόσο δομημένων όσο και μη δομημένων δεδομένων ως είσοδο και το ίδιο το σύστημα θα τα κατανείμει μεταξύ της υπολογιστικής ισχύος. Επιπλέον, αυτές οι ίδιες δυνατότητες μπορούν να αυξηθούν ή να απενεργοποιηθούν ανά πάσα στιγμή - η ίδια οριζόντια επεκτασιμότητα σε δράση.
Το 2017, η επιρροή εταιρεία συμβούλων Gartner ότι το Hadoop θα γίνει σύντομα ξεπερασμένο. Ο λόγος είναι μάλλον κοινός: οι αναλυτές πιστεύουν ότι οι εταιρείες θα μεταναστεύσουν μαζικά στο cloud, αφού εκεί θα μπορούν να πληρώνουν με βάση τη χρήση της υπολογιστικής ισχύος. Ο δεύτερος σημαντικός παράγοντας που υποτίθεται ότι μπορεί να «θάψει» τον Hadoop είναι η ταχύτητα της εργασίας. Επειδή επιλογές όπως το Apache Spark ή το Google Cloud DataFlow είναι πιο γρήγορες από το MapReduce που βρίσκεται στο Hadoop.
Το Hadoop βασίζεται σε πολλούς πυλώνες, οι πιο αξιοσημείωτοι από τους οποίους είναι οι τεχνολογίες MapReduce (ένα σύστημα διανομής δεδομένων για υπολογισμούς μεταξύ διακομιστών) και το σύστημα αρχείων HDFS. Το τελευταίο έχει σχεδιαστεί ειδικά για την αποθήκευση πληροφοριών που διανέμονται μεταξύ των κόμβων συμπλέγματος: κάθε μπλοκ σταθερού μεγέθους μπορεί να τοποθετηθεί σε πολλούς κόμβους και χάρη στην αναπαραγωγή, το σύστημα είναι ανθεκτικό σε αστοχίες μεμονωμένων κόμβων. Αντί για πίνακα αρχείων, χρησιμοποιείται ένας ειδικός διακομιστής που ονομάζεται NameNode.
Η παρακάτω εικόνα δείχνει πώς λειτουργεί το MapReduce. Στο πρώτο στάδιο, τα δεδομένα διαιρούνται σύμφωνα με ένα συγκεκριμένο χαρακτηριστικό, στο δεύτερο στάδιο κατανέμονται με υπολογιστική ισχύ, στο τρίτο στάδιο πραγματοποιείται ο υπολογισμός.
Το MapReduce δημιουργήθηκε αρχικά από την Google για τις ανάγκες της αναζήτησής της. Στη συνέχεια, το MapReduce μπήκε σε δωρεάν κώδικα και ο Apache ανέλαβε το έργο. Λοιπόν, η Google σταδιακά μετεγκαταστάθηκε σε άλλες λύσεις. Μια ενδιαφέρουσα απόχρωση: αυτή τη στιγμή, η Google έχει ένα έργο που ονομάζεται Google Cloud Dataflow, που τοποθετείται ως το επόμενο βήμα μετά το Hadoop, ως γρήγορη αντικατάστασή του.
Μια πιο προσεκτική ματιά δείχνει ότι το Google Cloud Dataflow βασίζεται σε μια παραλλαγή του Apache Beam, ενώ το Apache Beam περιλαμβάνει το καλά τεκμηριωμένο πλαίσιο Apache Spark, το οποίο μας επιτρέπει να μιλάμε για σχεδόν την ίδια ταχύτητα εκτέλεσης λύσης. Λοιπόν, το Apache Spark λειτουργεί καλά στο σύστημα αρχείων HDFS, το οποίο σας επιτρέπει να το αναπτύξετε σε διακομιστές Hadoop.
Προσθέστε εδώ τον όγκο της τεκμηρίωσης και τις έτοιμες λύσεις για το Hadoop και το Spark ενάντια στο Google Cloud Dataflow και η επιλογή του εργαλείου γίνεται προφανής. Επιπλέον, οι μηχανικοί μπορούν να αποφασίσουν μόνοι τους ποιον κώδικα - υπό το Hadoop ή το Spark - θα εκτελέσουν, εστιάζοντας στην εργασία, την εμπειρία και τα προσόντα.
Cloud ή τοπικός διακομιστής
Η τάση προς τη γενική μετάβαση στο cloud οδήγησε σε έναν τόσο ενδιαφέροντα όρο όπως το Hadoop-as-a-service. Σε ένα τέτοιο σενάριο, η διαχείριση των συνδεδεμένων διακομιστών έχει γίνει πολύ σημαντική. Επειδή, δυστυχώς, παρά τη δημοτικότητά του, το καθαρό Hadoop είναι ένα αρκετά δύσκολο εργαλείο στη διαμόρφωση, αφού πρέπει να κάνετε πολλά με το χέρι. Για παράδειγμα, μπορείτε να διαμορφώσετε τους διακομιστές ξεχωριστά, να παρακολουθήσετε την απόδοσή τους και να ρυθμίσετε με ακρίβεια πολλές παραμέτρους. Γενικά, δούλεψε για ερασιτέχνη και υπάρχει μεγάλη πιθανότητα να σκάσεις κάπου ή να χάσεις κάτι.
Ως εκ τούτου, διάφορες διανομές έχουν γίνει πολύ δημοφιλείς, οι οποίες είναι αρχικά εξοπλισμένες με βολικά εργαλεία ανάπτυξης και διαχείρισης. Μία από τις πιο δημοφιλείς διανομές που υποστηρίζει το Spark και διευκολύνει τα πράγματα είναι το Cloudera. Έχει τόσο πληρωμένη όσο και δωρεάν εκδόσεις - και στην τελευταία είναι διαθέσιμη όλη η κύρια λειτουργικότητα και χωρίς περιορισμό του αριθμού των κόμβων.
Κατά τη διάρκεια της εγκατάστασης, το Cloudera Manager θα συνδεθεί μέσω SSH στους διακομιστές σας. Ένα ενδιαφέρον σημείο: κατά την εγκατάσταση, είναι καλύτερο να διευκρινίσετε ότι πραγματοποιείται από το λεγόμενο δέματα: ειδικά πακέτα, καθένα από τα οποία περιέχει όλα τα απαραίτητα εξαρτήματα που έχουν διαμορφωθεί για να λειτουργούν μεταξύ τους. Στην πραγματικότητα, αυτή είναι μια τόσο βελτιωμένη έκδοση του διαχειριστή πακέτων.
Μετά την εγκατάσταση, λαμβάνουμε μια κονσόλα διαχείρισης συμπλέγματος, όπου μπορείτε να δείτε τηλεμετρία για συμπλέγματα, εγκατεστημένες υπηρεσίες, καθώς και μπορείτε να προσθέσετε / αφαιρέσετε πόρους και να επεξεργαστείτε τη διαμόρφωση του συμπλέγματος.
Ως αποτέλεσμα, η κοπή αυτού του πυραύλου εμφανίζεται μπροστά σας, η οποία θα σας οδηγήσει στο λαμπρό μέλλον των BigData. Αλλά πριν πούμε «πάμε», ας προχωρήσουμε γρήγορα κάτω από την κουκούλα.
απαιτήσεις υλικού
Στον ιστότοπό τους, η Cloudera αναφέρει διαφορετικές πιθανές διαμορφώσεις. Οι γενικές αρχές με τις οποίες κατασκευάζονται φαίνονται στην εικόνα:
Το MapReduce μπορεί να θολώσει αυτή την αισιόδοξη εικόνα. Εξετάζοντας ξανά το διάγραμμα στην προηγούμενη ενότητα, γίνεται σαφές ότι σχεδόν σε όλες τις περιπτώσεις, μια εργασία MapReduce μπορεί να χτυπήσει ένα σημείο συμφόρησης κατά την ανάγνωση δεδομένων από δίσκο ή δίκτυο. Αυτό σημειώνεται και στο blog Cloudera. Ως αποτέλεσμα, για οποιουσδήποτε γρήγορους υπολογισμούς, συμπεριλαμβανομένου του Spark, το οποίο χρησιμοποιείται συχνά για υπολογισμούς σε πραγματικό χρόνο, η ταχύτητα I/O είναι πολύ σημαντική. Επομένως, όταν χρησιμοποιείτε το Hadoop, είναι πολύ σημαντικό να μπαίνουν στο σύμπλεγμα ισορροπημένα και γρήγορα μηχανήματα, κάτι που, για να το θέσω ήπια, δεν παρέχεται πάντα στην υποδομή του cloud.
Η ισορροπία στη διανομή φορτίου επιτυγχάνεται με τη χρήση της εικονικοποίησης Openstack σε διακομιστές με ισχυρούς επεξεργαστές πολλαπλών πυρήνων. Στους κόμβους δεδομένων εκχωρούνται οι δικοί τους πόροι επεξεργαστή και ορισμένοι δίσκοι. Στη λύση μας Atos Codex Data Lake Engine επιτυγχάνεται ευρεία εικονικοποίηση, γι' αυτό κερδίζουμε τόσο από πλευράς απόδοσης (ο αντίκτυπος της υποδομής δικτύου ελαχιστοποιείται) όσο και TCO (εξαλείφονται οι επιπλέον φυσικοί διακομιστές).
Στην περίπτωση χρήσης διακομιστών BullSequana S200, έχουμε ένα πολύ ομοιόμορφο φορτίο, χωρίς ορισμένα από τα σημεία συμφόρησης. Η ελάχιστη διαμόρφωση περιλαμβάνει 3 διακομιστές BullSequana S200, ο καθένας με δύο JBOD, καθώς και επιπλέον S200 που περιέχουν τέσσερις κόμβους δεδομένων που συνδέονται προαιρετικά. Ακολουθεί ένα παράδειγμα φόρτωσης σε μια δοκιμή TeraGen:
Οι δοκιμές με διαφορετικούς όγκους δεδομένων και τιμές αναπαραγωγής δείχνουν τα ίδια αποτελέσματα όσον αφορά την κατανομή φορτίου στους κόμβους συμπλέγματος. Ακολουθεί ένα γράφημα της κατανομής της πρόσβασης στο δίσκο με βάση τις δοκιμές απόδοσης.
Οι υπολογισμοί βασίζονται σε μια ελάχιστη διαμόρφωση 3 διακομιστών BullSequana S200. Περιλαμβάνει 9 κόμβους δεδομένων και 3 κύριους κόμβους, καθώς και δεσμευμένες εικονικές μηχανές σε περίπτωση ανάπτυξης προστασίας με βάση το OpenStack Virtualization. Αποτέλεσμα δοκιμής TeraSort: Το μέγεθος μπλοκ 512 MB ενός συντελεστή αναπαραγωγής 23,1 με κρυπτογράφηση είναι XNUMX λεπτά.
Πώς μπορεί να επεκταθεί το σύστημα; Διάφοροι τύποι επεκτάσεων είναι διαθέσιμοι για το Data Lake Engine:
- Κόμβοι δεδομένων: για κάθε 40 TB χρησιμοποιήσιμου χώρου
- Αναλυτικοί κόμβοι με δυνατότητα εγκατάστασης GPU
- Άλλες επιλογές ανάλογα με τις επιχειρηματικές ανάγκες (για παράδειγμα, εάν χρειάζεστε Kafka και τα παρόμοια)
Το συγκρότημα Atos Codex Data Lake Engine περιλαμβάνει τόσο τους ίδιους τους διακομιστές όσο και προεγκατεστημένο λογισμικό, συμπεριλαμβανομένου του κιτ Cloudera με άδεια. Το ίδιο το Hadoop, το OpenStack με εικονικές μηχανές που βασίζονται στον πυρήνα του RedHat Enterprise Linux, συστήματα αναπαραγωγής δεδομένων και δημιουργίας αντιγράφων ασφαλείας (συμπεριλαμβανομένης της χρήσης ενός κόμβου αντιγράφου ασφαλείας και του Cloudera BDR - Backup and Disaster Recovery). Το Atos Codex Data Lake Engine είναι η πρώτη λύση εικονικοποίησης που έχει πιστοποιηθεί .
Αν σας ενδιαφέρουν οι λεπτομέρειες, θα χαρούμε να απαντήσουμε στις ερωτήσεις μας στα σχόλια.
Πηγή: www.habr.com