Αυτό είναι το δεύτερο μέρος μιας σειράς άρθρων σχετικά με τα αναλυτικά συστήματα ().
Σήμερα δεν υπάρχει πλέον καμία αμφιβολία ότι η προσεκτική επεξεργασία δεδομένων και η ερμηνεία των αποτελεσμάτων μπορεί να βοηθήσει σχεδόν κάθε τύπο επιχείρησης. Από αυτή την άποψη, τα αναλυτικά συστήματα φορτώνονται ολοένα και περισσότερο με παραμέτρους και ο αριθμός των ενεργοποιήσεων και των συμβάντων χρήστη στις εφαρμογές αυξάνεται.
Εξαιτίας αυτού, οι εταιρείες δίνουν στους αναλυτές τους όλο και περισσότερες ακατέργαστες πληροφορίες για να τις αναλύσουν και να τις μετατρέψουν σε ορθές αποφάσεις. Η σημασία ενός συστήματος ανάλυσης για μια εταιρεία δεν πρέπει να υποτιμάται και το ίδιο το σύστημα πρέπει να είναι αξιόπιστο και σταθερό.
Αναλυτές πελατών
Τα αναλυτικά στοιχεία πελατών είναι μια υπηρεσία που μια εταιρεία συνδέει στον ιστότοπο ή την εφαρμογή της μέσω του επίσημου SDK, την ενσωματώνει στη δική της βάση κώδικα και επιλέγει ενεργοποιητές συμβάντων. Υπάρχει ένα προφανές μειονέκτημα σε αυτήν την προσέγγιση: όλα τα δεδομένα που συλλέγονται ενδέχεται να μην υποβάλλονται σε επεξεργασία ακριβώς όπως θα θέλατε λόγω των περιορισμών οποιασδήποτε υπηρεσίας που θα επιλέξετε. Για παράδειγμα, σε ένα σύστημα δεν θα είναι εύκολο να εκτελέσετε εργασίες MapReduce, σε ένα άλλο δεν θα μπορείτε να εκτελέσετε το μοντέλο σας. Ένα άλλο μειονέκτημα θα είναι ο τακτικός (εντυπωσιακός) λογαριασμός για τις υπηρεσίες.
Υπάρχουν πολλές λύσεις ανάλυσης πελατών στην αγορά, αλλά αργά ή γρήγορα οι αναλυτές έρχονται αντιμέτωποι με το γεγονός ότι δεν υπάρχει μια καθολική υπηρεσία κατάλληλη για κάθε εργασία (ενώ οι τιμές για όλες αυτές τις υπηρεσίες αυξάνονται συνεχώς). Σε μια τέτοια κατάσταση, οι εταιρείες συχνά αποφασίζουν να δημιουργήσουν το δικό τους σύστημα ανάλυσης με όλες τις απαραίτητες προσαρμοσμένες ρυθμίσεις και δυνατότητες.
Αναλυτές διακομιστή
Τα αναλυτικά στοιχεία από την πλευρά του διακομιστή είναι μια υπηρεσία που μπορεί να αναπτυχθεί σε μια εταιρεία στους δικούς της διακομιστές και (συνήθως) με τις δικές της προσπάθειες. Σε αυτό το μοντέλο, όλα τα συμβάντα χρήστη αποθηκεύονται σε εσωτερικούς διακομιστές, επιτρέποντας στους προγραμματιστές να δοκιμάσουν διαφορετικές βάσεις δεδομένων αποθήκευσης και να επιλέξουν την πιο βολική αρχιτεκτονική. Και ακόμα κι αν εξακολουθείτε να θέλετε να χρησιμοποιείτε αναλυτικά στοιχεία πελατών τρίτου μέρους για ορισμένες εργασίες, θα είναι ακόμα δυνατό.
Τα αναλυτικά στοιχεία από την πλευρά του διακομιστή μπορούν να αναπτυχθούν με δύο τρόπους. Πρώτον: επιλέξτε κάποια βοηθητικά προγράμματα ανοιχτού κώδικα, αναπτύξτε τα στους υπολογιστές σας και αναπτύξτε επιχειρηματική λογική.
Πλεονεκτήματα
Μειονεκτήματα
Μπορείτε να προσαρμόσετε οτιδήποτε θέλετε
Αυτό είναι συχνά πολύ δύσκολο και απαιτεί ξεχωριστούς προγραμματιστές
Δεύτερον: πάρτε τις υπηρεσίες SaaS (Amazon, Google, Azure) αντί να τις αναπτύξετε μόνοι σας. Για το SaaS θα μιλήσουμε αναλυτικότερα στο τρίτο μέρος.
Πλεονεκτήματα
Μειονεκτήματα
Μπορεί να είναι φθηνότερο σε μεσαίες ποσότητες, αλλά με μεγάλη ανάπτυξη θα εξακολουθεί να είναι πολύ ακριβό
Δεν θα είναι δυνατός ο έλεγχος όλων των παραμέτρων
Η διαχείριση μεταφέρεται εξ ολοκλήρου στους ώμους του παρόχου υπηρεσιών
Δεν είναι πάντα γνωστό τι υπάρχει μέσα στην υπηρεσία (μπορεί να μην χρειάζεται)
Πώς να συλλέξετε αναλυτικά στοιχεία διακομιστή
Αν θέλουμε να απομακρυνθούμε από τη χρήση αναλυτικών στοιχείων πελατών και να δημιουργήσουμε τα δικά μας, πρώτα από όλα πρέπει να σκεφτούμε την αρχιτεκτονική του νέου συστήματος. Παρακάτω θα σας πω βήμα προς βήμα τι πρέπει να λάβετε υπόψη, γιατί χρειάζεται κάθε βήμα και ποια εργαλεία μπορείτε να χρησιμοποιήσετε.
1. Λήψη δεδομένων
Όπως και στην περίπτωση της ανάλυσης πελατών, πρώτα απ 'όλα, οι αναλυτές της εταιρείας επιλέγουν τους τύπους συμβάντων που θέλουν να μελετήσουν στο μέλλον και τους συγκεντρώνουν σε μια λίστα. Συνήθως, αυτά τα συμβάντα συμβαίνουν με μια συγκεκριμένη σειρά, που ονομάζεται "μοτίβο συμβάντων".
Στη συνέχεια, φανταστείτε ότι μια εφαρμογή για κινητά (ιστότοπος) έχει τακτικούς χρήστες (συσκευές) και πολλούς διακομιστές. Για την ασφαλή μεταφορά συμβάντων από συσκευές σε διακομιστές, απαιτείται ένα ενδιάμεσο επίπεδο. Ανάλογα με την αρχιτεκτονική, μπορεί να υπάρχουν πολλές διαφορετικές ουρές συμβάντων.
- Είναι , το οποίο χρησιμοποιείται ως ουρά για τη συλλογή συμβάντων.
Σύμφωνα με Το 2014, ο δημιουργός του Apache Kafka αποφάσισε να ονομάσει το λογισμικό με το όνομα Franz Kafka επειδή «είναι ένα σύστημα βελτιστοποιημένο για γραφή» και επειδή αγαπούσε τα έργα του Kafka. —
Στο παράδειγμά μας, υπάρχουν πολλοί παραγωγοί δεδομένων και καταναλωτές δεδομένων (συσκευές και διακομιστές) και ο Κάφκα βοηθά στη σύνδεση μεταξύ τους. Οι καταναλωτές θα περιγραφούν λεπτομερέστερα στα ακόλουθα βήματα, όπου θα είναι τα κύρια θέματα. Τώρα θα εξετάσουμε μόνο τους παραγωγούς δεδομένων (γεγονότα).
Ο Κάφκα συμπυκνώνει τις έννοιες της ουράς και της κατάτμησης· είναι καλύτερα να διαβάσετε πιο συγκεκριμένα για αυτό αλλού (για παράδειγμα, στο ). Χωρίς να υπεισέλθουμε σε λεπτομέρειες, ας φανταστούμε ότι κυκλοφορεί μια εφαρμογή για κινητά για δύο διαφορετικά λειτουργικά συστήματα. Στη συνέχεια, κάθε έκδοση δημιουργεί τη δική της ξεχωριστή ροή συμβάντων. Οι παραγωγοί στέλνουν εκδηλώσεις στον Κάφκα, καταγράφονται σε κατάλληλη ουρά.
(εικόνα )
Ταυτόχρονα, ο Κάφκα σάς επιτρέπει να διαβάζετε σε κομμάτια και να επεξεργάζεστε μια ροή γεγονότων σε μίνι παρτίδες. Το Kafka είναι ένα πολύ βολικό εργαλείο που κλιμακώνεται καλά με τις αυξανόμενες ανάγκες (για παράδειγμα, με γεωγραφική τοποθεσία των γεγονότων).
Συνήθως ένα θραύσμα είναι αρκετό, αλλά τα πράγματα γίνονται πιο περίπλοκα κατά την κλιμάκωση (όπως κάνουν πάντα). Πιθανώς κανείς δεν θα θέλει να χρησιμοποιήσει μόνο ένα φυσικό θραύσμα στην παραγωγή, καθώς η αρχιτεκτονική πρέπει να είναι ανεκτική σε σφάλματα. Εκτός από τον Κάφκα, υπάρχει μια άλλη πολύ γνωστή λύση - το RabbitMQ. Δεν το χρησιμοποιήσαμε στην παραγωγή ως ουρά για αναλύσεις συμβάντων (αν έχετε τέτοια εμπειρία, πείτε μας για αυτό στα σχόλια!). Ωστόσο, χρησιμοποιήσαμε AWS Kinesis.
Πριν προχωρήσουμε στο επόμενο βήμα, πρέπει να αναφέρουμε ένα επιπλέον επίπεδο του συστήματος - την αποθήκευση ακατέργαστων αρχείων καταγραφής. Αυτό δεν είναι ένα απαιτούμενο επίπεδο, αλλά θα είναι χρήσιμο εάν κάτι πάει στραβά και οι ουρές συμβάντων στον Κάφκα επαναφερθούν. Η αποθήκευση ακατέργαστων κορμών δεν απαιτεί μια περίπλοκη και δαπανηρή λύση· μπορείτε απλά να τα γράψετε κάπου με τη σωστή σειρά (ακόμη και σε σκληρό δίσκο).
2. Επεξεργασία ροών συμβάντων
Αφού ετοιμάσουμε όλα τα συμβάντα και τα τοποθετήσουμε στις κατάλληλες ουρές, προχωράμε στο βήμα της επεξεργασίας. Εδώ θα σας πω για τις δύο πιο συνηθισμένες επιλογές επεξεργασίας.
Η πρώτη επιλογή είναι να ενεργοποιήσετε το Spark Streaming στο σύστημα Apache. Όλα τα προϊόντα Apache ζωντανά σε HDFS, ένα ασφαλές σύστημα αρχείων με αντίγραφα αρχείων. Το Spark Streaming είναι ένα εύχρηστο εργαλείο που χειρίζεται τα δεδομένα ροής και κλιμακώνει καλά. Ωστόσο, μπορεί να είναι δύσκολο να διατηρηθεί.
Μια άλλη επιλογή είναι να δημιουργήσετε το δικό σας πρόγραμμα χειρισμού συμβάντων. Για να το κάνετε αυτό, πρέπει, για παράδειγμα, να γράψετε μια εφαρμογή Python, να την δημιουργήσετε στο Docker και να εγγραφείτε στην ουρά Kafka. Όταν φτάσουν οι σκανδαλισμοί στους χειριστές docker, η επεξεργασία θα ξεκινήσει. Με αυτήν τη μέθοδο, πρέπει να διατηρείτε τις εφαρμογές σε λειτουργία ανά πάσα στιγμή.
Ας υποθέσουμε ότι επιλέξαμε μία από τις επιλογές που περιγράφηκαν παραπάνω και προχωρήσουμε στην ίδια την επεξεργασία. Οι υπεύθυνοι επεξεργασίας θα πρέπει να ξεκινήσουν ελέγχοντας την εγκυρότητα των δεδομένων, φιλτράροντας τα σκουπίδια και τα «σπασμένα» συμβάντα. Για επικύρωση χρησιμοποιούμε συνήθως . Μετά από αυτό, μπορείτε να κάνετε αντιστοίχιση δεδομένων: δεδομένα από διαφορετικές πηγές κανονικοποιούνται και τυποποιούνται προκειμένου να προστεθούν σε έναν κοινό πίνακα.
3. Βάση δεδομένων
Το τρίτο βήμα είναι η διατήρηση κανονικοποιημένων γεγονότων. Όταν εργαζόμαστε με ένα έτοιμο αναλυτικό σύστημα, θα πρέπει να έχουμε συχνά πρόσβαση σε αυτά, επομένως είναι σημαντικό να επιλέγουμε μια βολική βάση δεδομένων.
Εάν τα δεδομένα ταιριάζουν καλά σε ένα σταθερό σχήμα, μπορείτε να επιλέξετε ή κάποια άλλη βάση δεδομένων στηλών. Με αυτόν τον τρόπο οι συναθροίσεις θα λειτουργήσουν πολύ γρήγορα. Το μειονέκτημα είναι ότι το σχήμα είναι αυστηρά καθορισμένο και επομένως δεν θα είναι δυνατή η προσθήκη αυθαίρετων αντικειμένων χωρίς τροποποίηση (για παράδειγμα, όταν συμβαίνει ένα μη τυπικό συμβάν). Αλλά μπορείτε να μετρήσετε πολύ γρήγορα.
Για μη δομημένα δεδομένα, μπορείτε να πάρετε NoSQL, για παράδειγμα, . Λειτουργεί σε HDFS, αναπαράγει καλά, μπορείτε να δημιουργήσετε πολλές περιπτώσεις και είναι ανεκτικό σε σφάλματα.
Μπορείτε επίσης να θέσετε κάτι πιο απλό, για παράδειγμα, . Είναι αρκετά αργό και για μικρούς όγκους. Αλλά το συν είναι ότι είναι πολύ απλό και επομένως κατάλληλο για εκκίνηση.
4. Συγκεντρώσεις
Έχοντας αποθηκεύσει προσεκτικά όλα τα συμβάντα, θέλουμε να συλλέξουμε όλες τις σημαντικές πληροφορίες από την παρτίδα που έφτασε και να ενημερώσουμε τη βάση δεδομένων. Σε παγκόσμιο επίπεδο, θέλουμε να λάβουμε σχετικούς πίνακες ελέγχου και μετρήσεις. Για παράδειγμα, συλλέξτε ένα προφίλ χρήστη από συμβάντα και μετρήστε με κάποιο τρόπο τη συμπεριφορά. Τα συμβάντα συγκεντρώνονται, συλλέγονται και αποθηκεύονται ξανά (σε πίνακες χρηστών). Ταυτόχρονα, μπορείτε να δημιουργήσετε ένα σύστημα έτσι ώστε να μπορείτε επίσης να συνδέσετε ένα φίλτρο στον συντονιστή-αθροιστή: συλλέξτε χρήστες μόνο από ένα συγκεκριμένο είδος συμβάντος.
Μετά από αυτό, εάν κάποιος στην ομάδα χρειάζεται μόνο αναλυτικά στοιχεία υψηλού επιπέδου, μπορούν να συνδεθούν εξωτερικά συστήματα ανάλυσης. Μπορείτε να πάρετε ξανά το Mixpanel. αλλά επειδή είναι αρκετά ακριβό, δεν αποστέλλονται όλα τα συμβάντα χρήστη εκεί, αλλά μόνο ό,τι χρειάζεται. Για να γίνει αυτό, πρέπει να δημιουργήσουμε έναν συντονιστή που θα μεταφέρει ορισμένα πρωτογενή συμβάντα ή κάτι που εμείς οι ίδιοι συγκεντρώσαμε νωρίτερα σε εξωτερικά συστήματα, API ή διαφημιστικές πλατφόρμες.
5. Frontend
Πρέπει να συνδέσετε το frontend στο σύστημα που δημιουργήθηκε. Ένα καλό παράδειγμα είναι η εξυπηρέτηση , είναι ένα γραφικό περιβάλλον βάσης δεδομένων που βοηθά στη δημιουργία πινάκων εργαλείων. Πώς λειτουργεί η αλληλεπίδραση:
- Ο χρήστης κάνει ένα ερώτημα SQL.
- Σε απάντηση λαμβάνει ένα σημάδι.
- Δημιουργεί μια «νέα οπτικοποίηση» για αυτό και λαμβάνει ένα όμορφο γράφημα που μπορείτε να αποθηκεύσετε για τον εαυτό σας.
Οι οπτικοποιήσεις στην υπηρεσία ενημερώνονται αυτόματα, μπορείτε να προσαρμόσετε και να παρακολουθήσετε την παρακολούθηση. Το Redash είναι δωρεάν εάν φιλοξενείται από μόνο του, αλλά ως SaaS θα κοστίζει 50 $ ανά μήνα.
Συμπέρασμα
Αφού ολοκληρώσετε όλα τα παραπάνω βήματα, θα δημιουργήσετε τα αναλυτικά στοιχεία του διακομιστή σας. Λάβετε υπόψη ότι αυτό δεν είναι τόσο απλό όσο η σύνδεση των αναλυτικών στοιχείων πελατών, επειδή όλα πρέπει να διαμορφωθούν μόνοι σας. Επομένως, πριν δημιουργήσετε το δικό σας σύστημα, αξίζει να συγκρίνετε την ανάγκη για ένα σοβαρό σύστημα ανάλυσης με τους πόρους που είστε διατεθειμένοι να διαθέσετε σε αυτό.
Εάν κάνατε τα μαθηματικά και διαπιστώσατε ότι το κόστος είναι πολύ υψηλό, στο επόμενο μέρος θα μιλήσω για το πώς να φτιάξετε μια φθηνότερη έκδοση των αναλυτικών στοιχείων από την πλευρά του διακομιστή.
Ευχαριστώ για την ανάγνωση! Θα χαρώ να κάνω ερωτήσεις στα σχόλια.
Πηγή: www.habr.com