Ζούμε σε μια καταπληκτική εποχή που μπορείτε γρήγορα και εύκολα να συνδέσετε πολλά έτοιμα εργαλεία ανοιχτού κώδικα, να τα ρυθμίσετε με τη «συνείδησή σας απενεργοποιημένη» σύμφωνα με τις συμβουλές του stackoverflow, χωρίς να εμβαθύνετε στα «πολλά γράμματα» και να εκκινήσετε σε εμπορική λειτουργία. Και όταν χρειάζεται να ενημερώσετε/επεκτείνετε ή κάποιος κάνει κατά λάθος επανεκκίνηση μερικών μηχανών - συνειδητοποιείτε ότι κάποιου είδους εμμονικό κακό όνειρο έχει ξεκινήσει, όλα έχουν γίνει δραματικά περίπλοκα πέρα από την αναγνώριση, δεν υπάρχει επιστροφή, το μέλλον είναι ασαφές και ασφαλέστερο, αντί για προγραμματισμό, εκτρέφετε μέλισσες και κάνετε τυρί.
Δεν είναι τυχαίο που πιο έμπειροι συνάδελφοι, με τα κεφάλια τους σκορπισμένα με σφάλματα και επομένως ήδη γκρίζα, σκέπτονται την απίστευτα γρήγορη ανάπτυξη πακέτων «κοντέινερ» σε «κύβους» σε δεκάδες διακομιστές σε «μοντέρνες γλώσσες» με ενσωματωμένη υποστήριξη για ασύγχρονη μη αποκλειστική I/O, χαμογέλα σεμνά . Και συνεχίζουν σιωπηλά να ξαναδιαβάζουν το «man ps», να εμβαθύνουν στον πηγαίο κώδικα «nginx» μέχρι να αιμορραγήσουν τα μάτια τους και να γράφουν, να γράφουν, να γράφουν δοκιμές μονάδων. Οι συνάδελφοι ξέρουν ότι το πιο ενδιαφέρον θα έρθει όταν «όλα αυτά» μια μέρα πονταριστούν τη νύχτα την παραμονή της Πρωτοχρονιάς. Και θα βοηθηθούν μόνο από τη βαθιά κατανόηση της φύσης του unix, τον απομνημονευμένο πίνακα καταστάσεων TCP/IP και τους βασικούς αλγόριθμους ταξινόμησης-αναζήτησης. Για να ξαναζωντανέψει το σύστημα καθώς χτυπούν οι ήχοι.
Α, ναι, αποσπάθηκα λίγο, αλλά ελπίζω να κατάφερα να μεταφέρω την κατάσταση της αναμονής.
Σήμερα θέλω να μοιραστώ την εμπειρία μας στην ανάπτυξη μιας βολικής και φθηνής στοίβας για την DataLake, η οποία επιλύει την πλειονότητα των αναλυτικών εργασιών στην εταιρεία για εντελώς διαφορετικά δομικά τμήματα.
Πριν από λίγο καιρό, καταλάβαμε ότι οι εταιρείες χρειάζονται όλο και περισσότερο τους καρπούς τόσο των προϊόντων όσο και των τεχνικών αναλύσεων (για να μην αναφέρουμε το κερασάκι στην τούρτα με τη μορφή μηχανικής μάθησης) και για να κατανοήσουμε τις τάσεις και τους κινδύνους - πρέπει να συλλέξουμε και να αναλύσουμε όλο και περισσότερες μετρήσεις.
Βασικές τεχνικές αναλύσεις στο Bitrix24
Πριν από αρκετά χρόνια, ταυτόχρονα με την κυκλοφορία της υπηρεσίας Bitrix24, επενδύσαμε ενεργά χρόνο και πόρους για τη δημιουργία μιας απλής και αξιόπιστης αναλυτικής πλατφόρμας που θα βοηθούσε να δούμε γρήγορα προβλήματα στην υποδομή και να σχεδιάσουμε το επόμενο βήμα. Φυσικά, ήταν σκόπιμο να ληφθούν έτοιμα εργαλεία που ήταν όσο το δυνατόν πιο απλά και κατανοητά. Ως αποτέλεσμα, το nagios επιλέχθηκε για παρακολούθηση και το munin για ανάλυση και οπτικοποίηση. Τώρα έχουμε χιλιάδες επιταγές σε nagios, εκατοντάδες γραφήματα στο munin και οι συνάδελφοί μας τα χρησιμοποιούν με επιτυχία κάθε μέρα. Οι μετρήσεις είναι σαφείς, τα γραφήματα είναι ξεκάθαρα, το σύστημα λειτουργεί αξιόπιστα εδώ και αρκετά χρόνια και σε αυτό προστίθενται τακτικά νέες δοκιμές και γραφήματα: όταν θέτουμε σε λειτουργία μια νέα υπηρεσία, προσθέτουμε πολλές δοκιμές και γραφήματα. Καλή τύχη.
Finger on the Pulse - Advanced Technical Analytics
Η επιθυμία να λάβουμε πληροφορίες σχετικά με προβλήματα "το συντομότερο δυνατό" μας οδήγησε σε ενεργά πειράματα με απλά και κατανοητά εργαλεία - pinba και xhprof.
Το Pinba μας έστειλε στατιστικά στοιχεία σε πακέτα UDP σχετικά με την ταχύτητα λειτουργίας τμημάτων ιστοσελίδων σε PHP και μπορούσαμε να δούμε στο διαδίκτυο στον χώρο αποθήκευσης MySQL (το Pinba διαθέτει τη δική του μηχανή MySQL για γρήγορη ανάλυση συμβάντων) μια σύντομη λίστα προβλημάτων και να απαντήσουμε σε τους. Και το xhprof μας επέτρεψε αυτόματα να συλλέξουμε γραφήματα της εκτέλεσης των πιο αργών σελίδων PHP από πελάτες και να αναλύσουμε τι θα μπορούσε να οδηγήσει σε αυτό - ήρεμα, ρίχνοντας τσάι ή κάτι πιο δυνατό.
Πριν από λίγο καιρό, το κιτ εργαλείων αναπληρώθηκε με έναν άλλο αρκετά απλό και κατανοητό κινητήρα που βασίζεται στον αλγόριθμο αντίστροφης ευρετηρίασης, που έχει εφαρμοστεί τέλεια στη θρυλική βιβλιοθήκη Lucene - Elastic/Kibana. Η απλή ιδέα της καταγραφής εγγράφων με πολλαπλά νήματα σε ένα αντίστροφο ευρετήριο Lucene με βάση τα συμβάντα στα αρχεία καταγραφής και μια γρήγορη αναζήτηση μέσω αυτών χρησιμοποιώντας διαίρεση όψεων αποδείχθηκε πολύ χρήσιμη.
Παρά την μάλλον τεχνική εμφάνιση των οπτικοποιήσεων στο Kibana με έννοιες χαμηλού επιπέδου όπως ο «κουβάς» «που ρέει προς τα πάνω» και η ανανεωμένη γλώσσα της μη εντελώς ξεχασμένης σχεσιακής άλγεβρας, το εργαλείο άρχισε να μας βοηθάει καλά στις ακόλουθες εργασίες:
- Πόσα σφάλματα PHP είχε ο πελάτης Bitrix24 στην πύλη p1 την τελευταία ώρα και ποια; Κατανοήστε, συγχωρήστε και διορθώστε γρήγορα.
- Πόσες βιντεοκλήσεις πραγματοποιήθηκαν σε πύλες στη Γερμανία τις προηγούμενες 24 ώρες, με ποια ποιότητα και υπήρχαν δυσκολίες με το κανάλι/δίκτυο;
- Πόσο καλά λειτουργεί η λειτουργικότητα του συστήματος (η επέκταση C για PHP), που έχει μεταγλωττιστεί από την πηγή στην πιο πρόσφατη ενημέρωση υπηρεσίας και διατίθεται στους πελάτες; Υπάρχουν segfaults;
- Τα δεδομένα πελατών χωρούν στη μνήμη PHP; Υπάρχουν σφάλματα σχετικά με την υπέρβαση της μνήμης που εκχωρείται στις διεργασίες: "εκτός μνήμης"; Βρείτε και εξουδετερώστε.
Εδώ είναι ένα συγκεκριμένο παράδειγμα. Παρά τη διεξοδική και πολυεπίπεδη δοκιμή, ο πελάτης, με μια πολύ μη τυπική θήκη και κατεστραμμένα δεδομένα εισόδου, έλαβε ένα ενοχλητικό και απροσδόκητο σφάλμα, ήχησε μια σειρήνα και ξεκίνησε η διαδικασία γρήγορης επιδιόρθωσης:
Επιπλέον, το kibana σάς επιτρέπει να οργανώνετε ειδοποιήσεις για συγκεκριμένες εκδηλώσεις και σε σύντομο χρονικό διάστημα το εργαλείο στην εταιρεία άρχισε να χρησιμοποιείται από δεκάδες υπαλλήλους από διαφορετικά τμήματα - από τεχνική υποστήριξη και ανάπτυξη έως QA.
Η δραστηριότητα οποιουδήποτε τμήματος εντός της εταιρείας έχει καταστεί βολική για παρακολούθηση και μέτρηση - αντί να αναλύετε χειροκίνητα αρχεία καταγραφής σε διακομιστές, χρειάζεται απλώς να ρυθμίσετε τα αρχεία καταγραφής ανάλυσης μία φορά και να τα στείλετε στο ελαστικό σύμπλεγμα για να απολαύσετε, για παράδειγμα, τη σκέψη στο kibana πίνακας ελέγχου ο αριθμός των πωληθέντων δικέφαλων γατών που τυπώθηκαν σε τρισδιάστατο εκτυπωτή για τον τελευταίο σεληνιακό μήνα.
Βασικά Business Analytics
Όλοι γνωρίζουν ότι τα επιχειρηματικά αναλυτικά στοιχεία στις εταιρείες συχνά ξεκινούν με την εξαιρετικά ενεργή χρήση, ναι, του Excel. Το κυριότερο όμως είναι ότι δεν τελειώνει εκεί. Το Google Analytics που βασίζεται στο cloud προσθέτει επίσης λάδι στη φωτιά - αρχίζετε γρήγορα να συνηθίζετε τα καλά πράγματα.
Στην αρμονικά αναπτυσσόμενη εταιρεία μας, εδώ κι εκεί άρχισαν να εμφανίζονται «προφήτες» πιο εντατικής δουλειάς με μεγαλύτερα δεδομένα. Η ανάγκη για πιο εμπεριστατωμένες και πολύπλευρες αναφορές άρχισε να εμφανίζεται τακτικά και με τις προσπάθειες ανδρών από διαφορετικά τμήματα, πριν από λίγο καιρό οργανώθηκε μια απλή και πρακτική λύση - ένας συνδυασμός ClickHouse και PowerBI.
Για αρκετό καιρό, αυτή η ευέλικτη λύση βοήθησε πολύ, αλλά σταδιακά άρχισε να γίνεται κατανοητό ότι το ClickHouse δεν είναι καουτσούκ και δεν μπορεί να κοροϊδεύεται έτσι.
Εδώ είναι σημαντικό να καταλάβουμε καλά ότι το ClickHouse, όπως το Druid, όπως το Vertica, όπως το Amazon RedShift (που βασίζεται στο postgres), είναι αναλυτικές μηχανές βελτιστοποιημένες για αρκετά βολικές αναλύσεις (αθροίσματα, συναθροίσεις, ελάχιστο-μέγιστο ανά στήλη και μερικές πιθανές συνδέσεις ), επειδή οργανωμένη για αποτελεσματική αποθήκευση στηλών σχεσιακών πινάκων, σε αντίθεση με τη MySQL και άλλες γνωστές σε εμάς βάσεις δεδομένων (προσανατολισμένες σε γραμμές).
Στην ουσία, το ClickHouse είναι απλώς μια πιο ευρύχωρη «βάση δεδομένων», με όχι πολύ βολική εισαγωγή σημείο προς σημείο (έτσι προορίζεται, όλα είναι εντάξει), αλλά ευχάριστα αναλυτικά στοιχεία και ένα σύνολο από ενδιαφέρουσες ισχυρές λειτουργίες για εργασία με δεδομένα. Ναι, μπορείτε ακόμη και να δημιουργήσετε ένα σύμπλεγμα - αλλά καταλαβαίνετε ότι το σφυρήλατο καρφί με μικροσκόπιο δεν είναι απολύτως σωστό και αρχίσαμε να αναζητούμε άλλες λύσεις.
Ζήτηση για python και αναλυτές
Η εταιρεία μας έχει πολλούς προγραμματιστές που γράφουν κώδικα σχεδόν καθημερινά για 10-20 χρόνια σε PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash. Υπάρχουν επίσης πολλοί έμπειροι διαχειριστές συστημάτων που έχουν βιώσει περισσότερες από μία απολύτως απίστευτες καταστροφές που δεν εντάσσονται στους νόμους των στατιστικών (για παράδειγμα, όταν η πλειονότητα των δίσκων σε ένα raid-10 καταστρέφεται από έναν ισχυρό κεραυνό). Σε τέτοιες συνθήκες, για πολύ καιρό δεν ήταν ξεκάθαρο τι ήταν ο «αναλυτής python». Η Python είναι σαν την PHP, μόνο το όνομα είναι λίγο μεγαλύτερο και υπάρχουν λίγο λιγότερα ίχνη ουσιών που αλλοιώνουν το μυαλό στον πηγαίο κώδικα του διερμηνέα. Ωστόσο, καθώς δημιουργήθηκαν όλο και περισσότερες αναλυτικές αναφορές, οι έμπειροι προγραμματιστές άρχισαν να κατανοούν όλο και περισσότερο τη σημασία της στενής εξειδίκευσης σε εργαλεία όπως το numpy, το pandas, το matplotlib, το seaborn.
Καθοριστικό ρόλο, πιθανότατα, έπαιξε η ξαφνική λιποθυμία των εργαζομένων από τον συνδυασμό των λέξεων «logistic regression» και η επίδειξη αποτελεσματικής αναφοράς μεγάλων δεδομένων χρησιμοποιώντας, ναι, ναι, pyspark.
Το Apache Spark, το λειτουργικό του παράδειγμα στο οποίο ταιριάζει τέλεια η σχεσιακή άλγεβρα και οι δυνατότητές του έκαναν τέτοια εντύπωση στους προγραμματιστές που ήταν συνηθισμένοι στη MySQL που η ανάγκη ενίσχυσης των τάξεων με έμπειρους αναλυτές έγινε ξεκάθαρη σαν μέρα.
Περαιτέρω προσπάθειες του Apache Spark/Hadoop να απογειωθεί και τι δεν πήγε αρκετά σύμφωνα με το σενάριο
Ωστόσο, σύντομα έγινε σαφές ότι κάτι συστηματικά δεν πήγαινε καλά με το Spark ή ήταν απλώς απαραίτητο να πλένετε καλύτερα τα χέρια σας. Εάν η στοίβα Hadoop/MapReduce/Lucene δημιουργήθηκε από αρκετά έμπειρους προγραμματιστές, κάτι που είναι προφανές αν κοιτάξετε προσεκτικά τον πηγαίο κώδικα στην Java ή τις ιδέες του Doug Cutting στο Lucene, τότε το Spark, ξαφνικά, γράφεται στην εξωτική γλώσσα Scala, η οποία είναι πολύ αμφιλεγόμενο από την άποψη της πρακτικότητας και επί του παρόντος δεν αναπτύσσεται. Και η τακτική πτώση στους υπολογισμούς στο σύμπλεγμα Spark λόγω της παράλογης και όχι πολύ διαφανούς εργασίας με την εκχώρηση μνήμης για λειτουργίες μείωσης (πολλά πλήκτρα φτάνουν ταυτόχρονα) έχει δημιουργήσει ένα φωτοστέφανο γύρω του από κάτι που έχει περιθώριο ανάπτυξης. Επιπλέον, η κατάσταση επιδεινώθηκε από έναν μεγάλο αριθμό παράξενων ανοιχτών θυρών, προσωρινών αρχείων που αυξάνονται στα πιο ακατανόητα μέρη και μια κόλαση εξαρτήσεων βάζων - κάτι που έκανε τους διαχειριστές συστήματος να έχουν ένα συναίσθημα που ήταν γνωστό από την παιδική ηλικία: άγριο μίσος (ή ίσως έπρεπε να πλένουν τα χέρια τους με σαπούνι).
Ως αποτέλεσμα, έχουμε «επιζήσει» από πολλά εσωτερικά αναλυτικά έργα που χρησιμοποιούν ενεργά το Apache Spark (συμπεριλαμβανομένων των Spark Streaming, Spark SQL) και το οικοσύστημα Hadoop (και ούτω καθεξής και ούτω καθεξής). Παρά το γεγονός ότι με την πάροδο του χρόνου μάθαμε να προετοιμάζουμε και να παρακολουθούμε το "αυτό" αρκετά καλά, και το "αυτό" ουσιαστικά σταμάτησε ξαφνικά να συντρίβεται λόγω αλλαγών στη φύση των δεδομένων και της ανισορροπίας του ομοιόμορφου κατακερματισμού RDD, η επιθυμία να πάρουμε κάτι ήδη έτοιμο , ενημερωνόταν και διαχειριζόταν κάπου στο σύννεφο γινόταν όλο και πιο δυνατό. Ήταν εκείνη τη στιγμή που προσπαθήσαμε να χρησιμοποιήσουμε την έτοιμη συναρμολόγηση cloud του Amazon Web Services - και, στη συνέχεια, προσπάθησε να λύσει προβλήματα χρησιμοποιώντας το. Το EMR είναι το Apache Spark που παρασκευάστηκε από την Amazon με πρόσθετο λογισμικό από το οικοσύστημα, όπως και οι κατασκευές Cloudera/Hortonworks.
Η αποθήκευση αρχείων από καουτσούκ για αναλυτικά στοιχεία είναι επείγουσα ανάγκη
Η εμπειρία του «μαγειρέματος» του Hadoop/Spark με εγκαύματα σε διάφορα σημεία του σώματος δεν ήταν μάταιη. Η ανάγκη να δημιουργηθεί μια ενιαία, φθηνή και αξιόπιστη αποθήκευση αρχείων που θα είναι ανθεκτική σε αστοχίες υλικού και στην οποία θα είναι δυνατή η αποθήκευση αρχείων σε διαφορετικές μορφές από διαφορετικά συστήματα και η δημιουργία αποτελεσματικών και χρονικά αποδοτικών δειγμάτων για αναφορές από αυτά τα δεδομένα Σαφή.
Ήθελα επίσης η ενημέρωση του λογισμικού αυτής της πλατφόρμας να μην μετατραπεί σε πρωτοχρονιάτικο εφιάλτη με την ανάγνωση ιχνών Java 20 σελίδων και την ανάλυση λεπτομερών αρχείων καταγραφής χιλιομέτρων του συμπλέγματος χρησιμοποιώντας Spark History Server και έναν μεγεθυντικό φακό με οπίσθιο φωτισμό. Ήθελα να έχω ένα απλό και διαφανές εργαλείο που να μην απαιτεί τακτική κατάδυση κάτω από την κουκούλα, εάν το τυπικό αίτημα MapReduce του προγραμματιστή σταματούσε να εκτελείται όταν ο εργαζόμενος μείωσης δεδομένων έπεσε από τη μνήμη λόγω ενός όχι πολύ καλά επιλεγμένου αλγόριθμου κατάτμησης δεδομένων πηγής.
Είναι το Amazon S3 υποψήφιο για το DataLake;
Η εμπειρία με το Hadoop/MapReduce μας δίδαξε ότι χρειαζόμαστε ένα επεκτάσιμο, αξιόπιστο σύστημα αρχείων και κλιμακωτούς εργάτες πάνω από αυτό, που «έρχονται» πιο κοντά στα δεδομένα, ώστε να μην οδηγούν τα δεδομένα στο δίκτυο. Οι εργαζόμενοι θα πρέπει να μπορούν να διαβάζουν δεδομένα σε διαφορετικές μορφές, αλλά κατά προτίμηση να μην διαβάζουν περιττές πληροφορίες και να μπορούν να αποθηκεύουν δεδομένα εκ των προτέρων σε μορφές βολικές για τους εργαζόμενους.
Για άλλη μια φορά, η βασική ιδέα. Δεν υπάρχει καμία επιθυμία να "χύσετε" μεγάλα δεδομένα σε μια ενιαία αναλυτική μηχανή συμπλέγματος, η οποία αργά ή γρήγορα θα πνιγεί και θα πρέπει να την θρυμματίσετε άσχημα. Θέλω να αποθηκεύω αρχεία, μόνο αρχεία, σε κατανοητή μορφή και να εκτελώ αποτελεσματικά αναλυτικά ερωτήματα σε αυτά χρησιμοποιώντας διαφορετικά αλλά κατανοητά εργαλεία. Και θα υπάρχουν όλο και περισσότερα αρχεία σε διαφορετικές μορφές. Και είναι καλύτερο να μοιράζετε όχι τον κινητήρα, αλλά τα δεδομένα πηγής. Χρειαζόμαστε μια επεκτάσιμη και καθολική DataLake, αποφασίσαμε...
Τι θα συμβεί αν αποθηκεύετε αρχεία στο γνωστό και γνωστό επεκτάσιμο χώρο αποθήκευσης cloud Amazon S3, χωρίς να χρειάζεται να προετοιμάσετε τα δικά σας κομματάκια από το Hadoop;
Είναι σαφές ότι τα προσωπικά δεδομένα είναι «χαμηλά», αλλά τι γίνεται με άλλα δεδομένα εάν τα βγάλουμε εκεί και «τα οδηγήσουμε αποτελεσματικά»;
Οικοσύστημα Cluster-bigdata-analytics των Υπηρεσιών Ιστού της Amazon - με πολύ απλά λόγια
Κρίνοντας από την εμπειρία μας με το AWS, το Apache Hadoop/MapReduce χρησιμοποιείται ενεργά εκεί εδώ και πολύ καιρό κάτω από διάφορες σάλτσες, για παράδειγμα στην υπηρεσία DataPipeline (ζηλεύω τους συναδέλφους μου, έμαθαν πώς να το προετοιμάζουν σωστά). Εδώ δημιουργούμε αντίγραφα ασφαλείας από διαφορετικές υπηρεσίες από πίνακες DynamoDB:
Και εκτελούνται τακτικά σε ενσωματωμένα συμπλέγματα Hadoop/MapReduce όπως το ρολόι εδώ και αρκετά χρόνια. «Ρυθμίστε το και ξεχάστε το»:
Μπορείτε επίσης να συμμετάσχετε αποτελεσματικά στον σατανισμό δεδομένων εγκαθιστώντας φορητούς υπολογιστές Jupiter στο cloud για αναλυτές και χρησιμοποιώντας την υπηρεσία AWS SageMaker για να εκπαιδεύσετε και να αναπτύξετε μοντέλα τεχνητής νοημοσύνης στη μάχη. Εδώ είναι πώς φαίνεται για εμάς:
Και ναι, μπορείτε να σηκώσετε έναν φορητό υπολογιστή για τον εαυτό σας ή έναν αναλυτή στο cloud και να τον συνδέσετε σε ένα σύμπλεγμα Hadoop/Spark, να κάνετε τους υπολογισμούς και στη συνέχεια να τα καταφέρετε:
Πραγματικά βολικό για μεμονωμένα αναλυτικά έργα και για ορισμένα έχουμε χρησιμοποιήσει με επιτυχία την υπηρεσία EMR για μεγάλης κλίμακας υπολογισμούς και αναλύσεις. Τι γίνεται με μια λύση συστήματος για το DataLake, θα λειτουργήσει; Αυτή τη στιγμή ήμασταν στα όρια της ελπίδας και της απόγνωσης και συνεχίσαμε την αναζήτηση.
AWS Glue - τακτοποιημένο Apache Spark σε στεροειδή
Αποδείχθηκε ότι το AWS έχει τη δική του έκδοση της στοίβας "Hive/Pig/Spark". Ο ρόλος του Hive, δηλ. Ο κατάλογος των αρχείων και των τύπων τους στο DataLake εκτελείται από την υπηρεσία “Data catalog”, η οποία δεν κρύβει τη συμβατότητά της με τη μορφή Apache Hive. Πρέπει να προσθέσετε πληροφορίες σε αυτήν την υπηρεσία σχετικά με το πού βρίσκονται τα αρχεία σας και σε ποια μορφή είναι. Τα δεδομένα μπορούν να βρίσκονται όχι μόνο στο s3, αλλά και στη βάση δεδομένων, αλλά αυτό δεν είναι το θέμα αυτής της ανάρτησης. Δείτε πώς είναι οργανωμένος ο κατάλογος δεδομένων DataLake:
Τα αρχεία είναι καταχωρημένα, τέλεια. Εάν τα αρχεία έχουν ενημερωθεί, εκκινούμε ανιχνευτές είτε χειροκίνητα είτε βάσει χρονοδιαγράμματος, τα οποία θα ενημερώνουν τις πληροφορίες σχετικά με αυτά από τη λίμνη και θα τα αποθηκεύουν. Στη συνέχεια, τα δεδομένα από τη λίμνη μπορούν να επεξεργαστούν και τα αποτελέσματα να ανέβουν κάπου. Στην πιο απλή περίπτωση, ανεβάζουμε και στο s3. Η επεξεργασία δεδομένων μπορεί να γίνει οπουδήποτε, αλλά προτείνεται να ρυθμίσετε τις παραμέτρους της επεξεργασίας σε ένα σύμπλεγμα Apache Spark χρησιμοποιώντας προηγμένες δυνατότητες μέσω του AWS Glue API. Στην πραγματικότητα, μπορείτε να πάρετε τον παλιό και γνωστό κώδικα python χρησιμοποιώντας τη βιβλιοθήκη pyspark και να ρυθμίσετε την εκτέλεσή του σε N κόμβους ενός συμπλέγματος κάποιας χωρητικότητας με παρακολούθηση, χωρίς να σκάβετε στα σπλάχνα του Hadoop και να σέρνετε κοντέινερ docker-moker και να εξαλείψετε τις διενέξεις εξάρτησης .
Για άλλη μια φορά, μια απλή ιδέα. Δεν χρειάζεται να διαμορφώσετε το Apache Spark, απλά πρέπει να γράψετε κώδικα python για το pyspark, να τον δοκιμάσετε τοπικά στην επιφάνεια εργασίας σας και στη συνέχεια να τον εκτελέσετε σε ένα μεγάλο σύμπλεγμα στο cloud, προσδιορίζοντας πού βρίσκονται τα δεδομένα προέλευσης και πού θα τοποθετήσετε το αποτέλεσμα. Μερικές φορές αυτό είναι απαραίτητο και χρήσιμο, και ορίστε πώς το ρυθμίζουμε:
Έτσι, εάν χρειάζεται να υπολογίσετε κάτι σε ένα σύμπλεγμα Spark χρησιμοποιώντας δεδομένα στο s3, γράφουμε κώδικα σε python/pyspark, τον δοκιμάζουμε και καλή τύχη στο σύννεφο.
Τι γίνεται με την ενορχήστρωση; Τι θα γινόταν αν η εργασία έπεφτε και εξαφανιστεί; Ναι, προτείνεται να φτιάξουμε ένα όμορφο pipeline στο στυλ Apache Pig και το δοκιμάσαμε, αλλά προς το παρόν αποφασίσαμε να χρησιμοποιήσουμε την βαθιά προσαρμοσμένη ενορχήστρωση σε PHP και JavaScript (καταλαβαίνω, υπάρχει γνωστική ασυμφωνία, αλλά λειτουργεί, για χρόνια και χωρίς λάθη).
Η μορφή των αρχείων που είναι αποθηκευμένα στη λίμνη είναι το κλειδί για την απόδοση
Είναι πολύ, πολύ σημαντικό να κατανοήσουμε δύο ακόμη βασικά σημεία. Προκειμένου τα ερωτήματα σχετικά με τα δεδομένα του αρχείου στη λίμνη να εκτελούνται όσο το δυνατόν γρηγορότερα και η απόδοση να μην υποβαθμίζεται όταν προστίθενται νέες πληροφορίες, πρέπει:
- Αποθηκεύστε στήλες αρχείων χωριστά (ώστε να μην χρειάζεται να διαβάσετε όλες τις γραμμές για να κατανοήσετε τι υπάρχει στις στήλες). Για αυτό πήραμε τη μορφή παρκέ με συμπίεση
- Είναι πολύ σημαντικό να μοιράζετε αρχεία σε φακέλους όπως: γλώσσα, έτος, μήνας, ημέρα, εβδομάδα. Οι μηχανές που κατανοούν αυτόν τον τύπο διαμοιρασμού θα κοιτάζουν μόνο τους απαραίτητους φακέλους, χωρίς να κοιτάζουν όλα τα δεδομένα στη σειρά.
Ουσιαστικά, με αυτόν τον τρόπο, τοποθετείτε τα δεδομένα πηγής με την πιο αποτελεσματική μορφή για τους αναλυτικούς κινητήρες που είναι αναρτημένοι από πάνω, οι οποίοι ακόμη και σε σπασμένους φακέλους μπορούν επιλεκτικά να εισάγουν και να διαβάζουν μόνο τις απαραίτητες στήλες από αρχεία. Δεν χρειάζεται να "γεμίσετε" τα δεδομένα πουθενά (ο αποθηκευτικός χώρος απλά θα σκάσει) - απλώς τοποθετήστε τα αμέσως με σύνεση στο σύστημα αρχείων στη σωστή μορφή. Φυσικά, εδώ θα πρέπει να είναι ξεκάθαρο ότι η αποθήκευση ενός τεράστιου αρχείου csv στο DataLake, το οποίο πρέπει πρώτα να διαβαστεί γραμμή προς γραμμή από το σύμπλεγμα για να εξαχθούν οι στήλες, δεν είναι πολύ σκόπιμο. Σκεφτείτε ξανά τα παραπάνω δύο σημεία, αν δεν είναι ακόμα σαφές γιατί συμβαίνουν όλα αυτά.
AWS Athena - το jack-in-the-box
Και μετά, ενώ δημιουργούσαμε μια λίμνη, κατά κάποιο τρόπο συναντήσαμε κατά λάθος την Amazon Athena. Ξαφνικά αποδείχθηκε ότι τακτοποιώντας προσεκτικά τα τεράστια αρχεία καταγραφής μας σε θραύσματα φακέλων στη σωστή μορφή στήλης (παρκέ), μπορείτε πολύ γρήγορα να κάνετε εξαιρετικά κατατοπιστικές επιλογές από αυτά και να δημιουργήσετε αναφορές ΧΩΡΙΣ, χωρίς σύμπλεγμα Apache Spark/Glue.
Ο κινητήρας Athena που τροφοδοτείται από δεδομένα στο s3 βασίζεται στο θρυλικό - ένας εκπρόσωπος της οικογένειας προσεγγίσεων MPP (μαζική παράλληλη επεξεργασία) για την επεξεργασία δεδομένων, λαμβάνοντας δεδομένα εκεί που βρίσκονται, από το s3 και το Hadoop μέχρι την Κασσάνδρα και τα συνηθισμένα αρχεία κειμένου. Απλώς πρέπει να ζητήσετε από την Athena να εκτελέσει ένα ερώτημα SQL και, στη συνέχεια, όλα "λειτουργούν γρήγορα και αυτόματα". Είναι σημαντικό να σημειωθεί ότι η Athena είναι «έξυπνη», πηγαίνει μόνο στους απαραίτητους κομματιασμένους φακέλους και διαβάζει μόνο τις στήλες που απαιτούνται στο αίτημα.
Ενδιαφέρουσα είναι και η τιμολόγηση για αιτήματα προς την Αθηνά. Πληρώνουμε . Εκείνοι. όχι για τον αριθμό των μηχανημάτων στο σύμπλεγμα ανά λεπτό, αλλά... για τα δεδομένα που σαρώθηκαν πραγματικά σε 100-500 μηχανές, μόνο τα δεδομένα που είναι απαραίτητα για την ολοκλήρωση του αιτήματος.
Και ζητώντας μόνο τις απαραίτητες στήλες από σωστά μοιρασμένους φακέλους, αποδείχθηκε ότι η υπηρεσία Athena μας κοστίζει δεκάδες δολάρια το μήνα. Λοιπόν, υπέροχο, σχεδόν δωρεάν, σε σύγκριση με τα αναλυτικά στοιχεία σε συμπλέγματα!
Παρεμπιπτόντως, ορίστε πώς μοιράζουμε τα δεδομένα μας στο s3:
Ως αποτέλεσμα, σε σύντομο χρονικό διάστημα, εντελώς διαφορετικά τμήματα της εταιρείας, από την ασφάλεια πληροφοριών μέχρι τα αναλυτικά, άρχισαν να υποβάλλουν ενεργά αιτήματα στην Athena και γρήγορα, σε δευτερόλεπτα, να λαμβάνουν χρήσιμες απαντήσεις από «μεγάλα» δεδομένα για αρκετά μεγάλα χρονικά διαστήματα: μήνες, εξάμηνο κλπ. Π.
Αλλά προχωρήσαμε παραπέρα και αρχίσαμε να πηγαίνουμε στο σύννεφο για απαντήσεις : ένας αναλυτής γράφει ένα ερώτημα SQL σε μια οικεία κονσόλα, η οποία σε 100-500 μηχανές "για πένες" στέλνει δεδομένα στο s3 και επιστρέφει μια απάντηση συνήθως σε λίγα δευτερόλεπτα. Ανετος. Και γρήγορα. Ακόμα δεν μπορώ να το πιστέψω.
Ως αποτέλεσμα, έχοντας αποφασίσει να αποθηκεύσουμε δεδομένα σε s3, σε αποτελεσματική στηλώδη μορφή και με εύλογο διαμοιρασμό δεδομένων σε φακέλους... λάβαμε το DataLake και μια γρήγορη και φθηνή μηχανή ανάλυσης - δωρεάν. Και έγινε πολύ δημοφιλής στην παρέα, γιατί... κατανοεί την SQL και δουλεύει τάξεις μεγέθους πιο γρήγορα από ό,τι μέσω της εκκίνησης/διακοπής/δημιουργίας συμπλεγμάτων. "Και αν το αποτέλεσμα είναι το ίδιο, γιατί να πληρώσετε περισσότερα;"
Ένα αίτημα προς την Αθηνά μοιάζει κάπως έτσι. Εάν θέλετε, φυσικά, μπορείτε να σχηματίσετε αρκετά , αλλά θα περιοριστούμε στην απλή ομαδοποίηση. Ας δούμε ποιους κωδικούς απόκρισης είχε ο πελάτης πριν από μερικές εβδομάδες στα αρχεία καταγραφής του διακομιστή web και βεβαιωθείτε ότι δεν υπάρχουν σφάλματα:
Ευρήματα
Έχοντας διανύσει, για να μην πω μια μακρά, αλλά επίπονη διαδρομή, αξιολογώντας συνεχώς επαρκώς τους κινδύνους και το επίπεδο πολυπλοκότητας και το κόστος υποστήριξης, βρήκαμε μια λύση για το DataLake και τα αναλυτικά στοιχεία που δεν παύουν να μας ευχαριστούν τόσο με την ταχύτητα όσο και με το κόστος ιδιοκτησίας.
Αποδείχθηκε ότι η κατασκευή ενός αποτελεσματικού, γρήγορου και φθηνού στη λειτουργία DataLake για τις ανάγκες εντελώς διαφορετικών τμημάτων της εταιρείας είναι απολύτως εντός των δυνατοτήτων ακόμη και έμπειρων προγραμματιστών που δεν έχουν εργαστεί ποτέ ως αρχιτέκτονες και δεν ξέρουν πώς να σχεδιάζουν τετράγωνα σε τετράγωνα με βέλη και γνωρίζουν 50 όρους από το οικοσύστημα Hadoop.
Στην αρχή του ταξιδιού, το κεφάλι μου χώριζε από τους πολλούς άγριους ζωολογικούς κήπους ανοιχτού και κλειστού λογισμικού και την κατανόηση του βάρους της ευθύνης στους απογόνους. Απλώς ξεκινήστε να δημιουργείτε το DataLake σας από απλά εργαλεία: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., συλλέγοντας σχόλια και κατανοώντας βαθιά τη φυσική των διαδικασιών που λαμβάνουν χώρα. Όλα περίπλοκα και θολά - δώστε τα σε εχθρούς και ανταγωνιστές.
Εάν δεν θέλετε να μεταβείτε στο cloud και θέλετε να υποστηρίζετε, να ενημερώνετε και να επιδιορθώνετε έργα ανοιχτού κώδικα, μπορείτε να δημιουργήσετε ένα σχήμα παρόμοιο με το δικό μας τοπικά, σε φθηνές μηχανές γραφείου με Hadoop και Presto στην κορυφή. Το κύριο πράγμα είναι να μην σταματήσετε και να προχωρήσετε μπροστά, να μετρήσετε, να αναζητήσετε απλές και ξεκάθαρες λύσεις και όλα θα πάνε σίγουρα! Καλή επιτυχία σε όλους και τα λέμε ξανά!
Πηγή: www.habr.com