Δημιουργία της ομάδας του Analytics κατά βούληση

Όταν μπήκα για πρώτη φορά στο Wish πριν από δυόμισι χρόνια, τα πράγματα πήγαιναν καλά. Η εφαρμογή Wish είχε φτάσει σε κορυφαίες θέσεις τόσο στα καταστήματα εφαρμογών iOS όσο και σε Android και πωλούσε πάνω από δύο εκατομμύρια αντικείμενα την ημέρα.

Επιθυμία - φτάνοντας στο κορυφαίο 10 του Android (πηγή)

Πολύ λίγοι άνθρωποι πίστευαν ότι μια μεγάλη επιχείρηση θα μπορούσε να χτιστεί από την πώληση προϊόντων σε χαμηλές τιμές. Χρησιμοποιώντας δεδομένα, η Wish κατάφερε να δοκιμάσει και να αμφισβητήσει αυτές τις υποθέσεις. Το να βασίζουμε τα δεδομένα ήταν στο DNA της εταιρείας.

Όμως, από την τεράστια ανάπτυξη της εταιρείας ήταν τεράστιοι αυξανόμενοι πόνοι από την πλευρά των αναλυτικών στοιχείων. Κάθε ομάδα χρειαζόταν επείγουσα υποστήριξη δεδομένων και είχε έλλειψη ορατότητας στους τομείς ιδιοκτησίας τους. Όμως, οι δυνατότητες ανάλυσης του Wish ήταν ακόμη στα σπάργανα και δεν μπορούσαν να ανταποκριθούν στη ζήτηση.

Υπήρξαν σημεία συμφόρησης στην πρόσβαση στα δεδομένα. Τα μόνα άτομα που μπόρεσαν να δημιουργήσουν αναφορές και να αντλήσουν δεδομένα ήταν μηχανικοί που εργάζονταν στο προϊόν. Δεδομένου ότι η υποδομή δεδομένων ήταν τόσο γυμνή, δεν μπορούσαμε να προσλάβουμε αναλυτές δεδομένων για να βοηθήσουμε. Τα αιτήματα δεδομένων και οι αναφορές είχαν μετρηθεί χρόνους ανάκαμψης σε εβδομάδες.

Τα επόμενα δύο χρόνια δουλέψαμε σκληρά για να δημιουργήσουμε αναλυτικά στοιχεία στο Wish. Κατασκευάσαμε έναν αγωγό δεδομένων από το μηδέν προς τα πάνω που επιτρέπει στους μηχανικούς, τους αναλυτές δεδομένων και τους επιστήμονες δεδομένων να ETL δεδομένα αξιόπιστα και με ασφάλεια να τροφοδοτούν την εργασία τους. Κατασκευάσαμε μια αποθήκη δεδομένων στο Redshift και το BigQuery με πυρήνες πίνακες που μπορούν να χρησιμοποιηθούν για την τροφοδοσία δευτερευόντων πινάκων που χρειάζονται οι αναλυτές. Και ξεδιπλώσαμε το Looker, τώρα χρησιμοποιούμε την εταιρεία ως πηγή αλήθειας για δεδομένα από περισσότερα από 200 άτομα σε τρεις ηπείρους.

Έχουμε πλέον πάνω από 30 άτομα αφιερωμένα στην επεξεργασία αναλυτικών στοιχείων, με σχέδια να διπλασιάσουμε αυτόν τον αριθμό φέτος. Είμαστε βέβαιοι ότι τα συστήματα και οι διαδικασίες μας μπορούν να κλιμακωθούν και ότι μπορούμε να ικανοποιήσουμε οποιαδήποτε μελλοντική ζήτηση που κατέχει η εταιρεία.

Σε αυτήν την ανάρτηση, θα μοιραστώ τα μαθήματα που μάθαμε και θα προσφέρω έναν χάρτη πορείας για άλλες εταιρείες που θέλουν να κλιμακώσουν τη λειτουργία ανάλυσης.

Αυτό το άρθρο χωρίζεται σε τέσσερα μέρη, το καθένα μιλά για διαφορετική εστίαση στη δημιουργία μιας ομάδας δεδομένων.

  1. Μέρος 1 - Ανακατασκευή του Ιδρύματος
  2. Μέρος 2 - Μηχανική κλιμάκωσης δεδομένων
  3. Μέρος 3 - Ανάλυση δεδομένων κλιμάκωσης
  4. Μέρος 4 - Πρόσληψη

Μέρος 1 - Ανακατασκευή του Ιδρύματος

Ας ξεκινήσουμε με τις πρώτες μέρες. Τα πράγματα ήταν αρκετά ξεκάθαρα μετά την ένταξή μου ότι υπήρχαν σοβαρά προβλήματα με το πώς εργαζόμαστε με τα δεδομένα.

Η πρώιμη πλατφόρμα δεδομένων

Πρώτον, το ερώτημα των δεδομένων ήταν ένας εφιάλτης. Μέχρι αυτή τη στιγμή είχαμε ένα από τα μεγαλύτερα σμήνη MongoDB στον κόσμο (κορυφαίο 3). Για λόγους αξιοπιστίας η ομάδα υποδομής απενεργοποίησε τα ερωτήματα συγκέντρωσης Mongo, που σημαίνει ότι η συγκέντρωση δεδομένων έπρεπε να γίνει από την πλευρά του πελάτη (σε ένα σενάριο Python). Αυτό που θα έπρεπε να ήταν απλές δηλώσεις SUM και GROUP BY στη SQL έπρεπε να γραφτούν ως σενάρια Python που επαναλάμβαναν εκατομμύρια έγγραφα ένα κάθε φορά, παρακολουθώντας τα αποτελέσματα σε ένθετα υπαγόρευση. Αυτά τα ερωτήματα ήταν επώδυνα να γράψω και χρειάστηκαν για πάντα να τρέξουν.

Η κατάσταση του αγωγού δεδομένων δεν ήταν πολύ καλύτερη. Το σύστημα ήταν υπερβολικά απλό και δεν διέθετε βασικά χαρακτηριστικά που κατέστησαν δυνατή τη διαχείριση μεγάλου όγκου εργασιών ETL, όπως διαχείριση εξάρτησης και λογική επανάληψης. Οι αποτυχίες ήταν εύθραυστες και καταρρέουν, οι οποίες έκαναν τις πυρκαγιές σχεδόν σε πλήρη απασχόληση.

Χρειαζόμασταν να ξαναχτίσουμε την υποδομή - και γρήγορα. Χρειαζόμαστε τη μετάβαση του αγωγού δεδομένων σε ένα πιο επεκτάσιμο και αξιόπιστο σύστημα. Και χρειαζόμασταν να χτίσουμε ένα ξεχωριστό χώρο αποθήκευσης δεδομένων για αναλυτικά στοιχεία που κάνει το ερώτημα και τη δημιουργία αναφορών πολύ πιο γρήγορα.

Αυτό που το έκανε τόσο δύσκολο ήταν ότι ως μία από τις δύο προσλήψεις εστιασμένων στα analytics στην εταιρεία, έπρεπε να κάνω ταλέντο μεταξύ της διατήρησης του τρέχοντος αγωγού σε λειτουργία, να συμβαδίζω με μεγάλο αριθμό αιτημάτων αναφοράς και δεδομένων και να εξοικονομήσω χρόνο για την ανοικοδόμηση του συστήματος. Αυτό σήμαινε συχνά εναλλαγή μεταξύ μηχανικών δεδομένων και εργασιών ανάλυσης δεδομένων - δύο είδη εργασίας που απαιτούν πολύ διαφορετικές δεξιότητες και σκέψη. Ζογκλέροντας και τα δύο, δεν νομίζω ότι έκανα και τους δύο ρόλους πολύ καλά.

Αυτό που κατέληξε να σώσει την ημέρα ήταν οι τελικοί πρώτοι αναλυτές δεδομένων μας. Ήμασταν τυχεροί που βρήκαμε τελικά ανώτερους αναλυτές αρκετά τεχνικούς που θα μπορούσαν να γράψουν ad-hoc ερωτήματα για το MongoDB και να εργαστούν στις αναφορές email που βασίζονται στο Python. Ήταν επίσης αρκετά έμπειροι που ήξεραν πώς να πλοηγούνται σε μη τεκμηριωμένες και νέες πηγές δεδομένων. Αυτό σήμαινε ότι θα μπορούσαν να αναλάβουν την κυριότητα πολλών εργασιών αναφοράς που έχω θάψει.

Τον επόμενο χρόνο, δημιουργήσαμε τα θεμέλια των αναλυτικών στοιχείων στο Wish. Οι αναλυτές ανέλαβαν τη μάνικα των αιτημάτων δεδομένων που προέρχονταν από όλες τις γωνιές της εταιρείας. Ήμουν σε θέση να επικεντρωθώ στην ανοικοδόμηση της υποδομής.

Ούτε εγώ ούτε η ομάδα των αναλυτών μας θα είχαν διαρκέσει πολύ καιρό σε αυτήν την εταιρεία εάν κανένας από εμάς δεν είχαμε προσχωρήσει στην εταιρεία. Τα δύο προβλήματα που επεξεργαστήκαμε, αντλώντας δεδομένα / αναφορές κτιρίων και εργαζόμαστε για τη βελτίωση της υποδομής, ήταν δύσκολα με πολύ διαφορετικούς τρόπους. Απαίτησαν τόσο ξεχωριστές δεξιότητες που καμία πλευρά δεν ήταν πολύ καλή στο ρόλο του άλλου.

Το κύριο μάθημα είναι ότι η απαίτηση έναρξης μιας ομάδας δεδομένων είναι να έχει τόσο μηχανικό δεδομένων όσο και αναλυτές δεδομένων. Χωρίς τουλάχιστον έναν αναλυτή δεδομένων, ο μηχανικός δεδομένων θα είναι θαμμένος κάτω από εργασίες αναφοράς και έλλειψη δεδομένων. Χωρίς τον μηχανικό δεδομένων, οι αναλυτές δεδομένων θα εξαφανιστούν από την αναζήτηση δύσκολων πηγών δεδομένων, ενώ θα ασχολούνται με τα αιτήματα δεδομένων. Και οι δύο τύποι προσλήψεων πρέπει να είναι έμπειροι. Και οι δύο ομάδες πρέπει να είναι σε θέση να το αλέσουν για λίγο έως ότου δημιουργηθεί το σύστημα.

Στις επόμενες δύο ενότητες, θα μιλήσω λεπτομερέστερα για τις προκλήσεις που αντιμετωπίζει κάθε ρόλος και συμβουλές για τον τρόπο αντιμετώπισής τους.

Συμμετοχή ως πρώιμος αναλυτής δεδομένων

Το να είσαι ένας από τους πρώτους αναλυτές δεδομένων στο Wish σήμαινε να είσαι ιδιοκτήτης ενός μεγάλου τμήματος αναφορών και να είσαι ένας από τους πρώτους ανθρώπους που ανέλαβαν τα αιτήματα δεδομένων.

Η αναφορά ήταν ένα σύστημα αποτελούμενο από σενάρια Python που δημιούργησαν email HTML που αποστέλλονται σε τακτά χρονικά διαστήματα. Υπήρχαν πάνω από εκατό από αυτά, καλύπτοντας τα διαφορετικά συστήματα και λειτουργίες εντός της εταιρείας.

Η διατήρηση αυτών των σεναρίων σύμφωνα με το πρόγραμμα ήταν μια εργασία πλήρους απασχόλησης. Η επεξεργασία δεδομένων χρησιμοποιώντας το Python και η κάλυψη όλων των ακραίων περιπτώσεων είναι δύσκολη. Ζητήματα όπως σφάλματα τύπου, ελλιπή ή ελλιπή δεδομένα και προβλήματα προβολής, ήταν όλα σφάλματα που εμφανίζονταν καθημερινά και θα προκαλούσαν την αποστολή αναφορών. Συνήθως δεν υπήρχε αρκετός χρόνος σε μια εβδομάδα για να διορθωθούν όλα τα πράγματα που προέκυψαν, επομένως η αναφορά σφαλμάτων έπρεπε να δοκιμαστεί και να δοθεί προτεραιότητα.

Δεν ήταν αρκετό που απλώς κρατήσαμε το σύστημα λειτουργικό. Η ανάπτυξη της εταιρείας δημιουργούσε μεγάλη ζήτηση για νέες αναφορές. Μόλις προσλάβαμε έναν νέο Επικεφαλής Επιχειρήσεων, πράγμα που σήμαινε ότι όλες οι αναφορές εξυπηρέτησης πελατών πρέπει να ξαναχτιστούν. Παρουσιάσαμε επίσης νέα εμπορικά προγράμματα όπως το Wish Express, την επιλογή αποστολής 7 ημερών. Κάθε ένα από αυτά τα προγράμματα χρειάστηκε το δικό του σύνολο αναφορών.

Εκτός από τις αναφορές, υπήρχε συνεχής ροή αιτημάτων δεδομένων από όλες τις πλευρές της εταιρείας. Φαινόταν πάντα ότι η ταχύτητα με την οποία ήρθαν αυξανόταν εκθετικά. Έπρεπε να είμαστε πολύ επιλεκτικοί για τη μείωση των περιττών ερωτήσεων και να δώσουμε προτεραιότητα στην εργασία μόνο για τα πιο σημαντικά αιτήματα.

Αυτή ήταν μια σκληρή δουλειά. Υπήρχε πάντα ένας πειρασμός να βιαστούμε τα πράγματα ως απάντηση στον όγκο των εισερχόμενων εργασιών. Αυτό οδήγησε σε λάθη, τα οποία μείωσαν πολύ γρήγορα την αξιοπιστία ενός αναλυτή.

Η επιτυχία σε αυτόν τον ρόλο σημαίνει δύο πράγματα:

  1. Να είναι σε θέση να παρέχει ακριβή δεδομένα με συνέπεια
  2. Για να μπορέσετε να χειριστείτε έναν παράλογο όγκο αιτημάτων.

Θα μιλήσω για αυτά τα δύο με περισσότερες λεπτομέρειες - γιατί είναι δύσκολο νωρίς και πώς να ξεπεράσουν αυτές τις δυσκολίες.

Επειδή δεν αποστέλλονται κακά δεδομένα

Αποστολή κακών δεδομένων <Δεν κάνει τίποτα <Αποστολή σωστών δεδομένων

Οι άπειροι αναλυτές δεδομένων τείνουν να αναζητούν δεδομένα χωρίς να γνωρίζουν πλήρως πώς λειτουργούν τα πράγματα.

Για να σας δώσουμε ένα παράδειγμα, ας υποθέσουμε ότι είχαμε ένα αίτημα για λήψη του τρέχοντος συνολικού ποσοστού επιστροφής χρημάτων. Ο αφελής τρόπος για να γίνει αυτό θα ήταν να κοιτάξετε το μοντέλο δεδομένων για παραγγελίες και να δείτε ότι έχει πεδίο αιτήματος επιστροφής χρημάτων. Φιλτράροντας την ύπαρξη αυτού, σε όλες τις παραγγελίες που έγιναν σε ένα δεδομένο χρονικό πλαίσιο, μπορούμε να λάβουμε μια μέτρηση ποσοστού επιστροφής χρημάτων - # επιστροφές χρημάτων / # παραγγελίες. Τότε το στέλνουμε.

Ας πούμε ότι ακούμε πίσω και τώρα ο κορυφαίος ορείχαλκος θέλει να δει πώς διαφέρει το ποσοστό επιστροφής χρημάτων για τα πακέτα που αποστέλλονται με επιβεβαίωση παράδοσης και χωρίς. Naively, θα μπορούσαμε επίσης να εφαρμόσουμε την ίδια μέθοδο και να βρούμε ένα ξεχωριστό μοντέλο δεδομένων για παρακολούθηση παραγγελιών και να δούμε ότι έχει ένα πεδίο που ονομάζεται παράδοση επιβεβαιωμένη ώρα. Και ότι μπορεί να συνδεθεί με μια παραγγελία από το πρώτο μοντέλο δεδομένων χρησιμοποιώντας αναγνωριστικό παρακολούθησης, το οποίο υπάρχει και στα δύο μοντέλα.

Γράφουμε την ίδια έλξη όπως πριν, αλλά τώρα εξαρτάται από την ύπαρξη του χρόνου επιβεβαίωσης παράδοσης, για να λάβουμε δύο μετρήσεις:

  1. Ποσοστό επιστροφής χρημάτων - Παραγγελίες με επιβεβαίωση παράδοσης: X%
  2. Ποσοστό επιστροφής χρημάτων - Παραγγελίες χωρίς επιβεβαίωση παράδοσης: Y%

Αρκετά απλό. Τότε το στέλνουμε.

Είδατε το λάθος;

Για Wish, οι ακυρώσεις παραγγελιών θεωρούνται επιστροφές χρημάτων. Δεδομένου ότι οι ακυρώσεις σημαίνει ότι οι παραγγελίες δεν έχουν αποσταλεί ακόμη, οπότε καταλήγουν πάντα στη δεύτερη μέτρηση - ποσοστό επιστροφής χρημάτων για παραγγελίες χωρίς επιβεβαίωση παράδοσης. Αυτό αυξάνει σημαντικά το δεύτερο ποσοστό επιστροφής χρημάτων. Πολύ κακές αποφάσεις θα μπορούσαν να ληφθούν από αυτό.

Αυτό το παράδειγμα συνέβη στην πραγματική ζωή (ευτυχώς πιάστηκε γρήγορα). Σκεπτόμενος κάθε φορά που έπαιρνα συντομεύσεις και παραλείποντας να κατανοήσω το σύστημα πριν βγάλω δεδομένα, τελικά θα έστελνα κακούς αριθμούς.

Η αποφυγή αυτής της παγίδας απαιτεί εμπειρία. Κάθε φορά που υπάρχει εργασία για μια νέα μέτρηση ή μια νέα πηγή δεδομένων που ο αναλυτής δεν είναι εξοικειωμένος, πρέπει να αφιερώσουν επιπλέον χρόνο για να εξερευνήσουν τα δεδομένα και να κατανοήσουν το σύστημα. Για τους πρώτους αναλυτές δεδομένων σε μια ομάδα, σχεδόν κάθε εργασία περιλαμβάνει εργασία με νέα και άγνωστα δεδομένα.

Χρειάζεται ένας έμπειρος αναλυτής δεδομένων για να μάθει πότε να επιβραδύνει. Ακόμα και όταν αντιμετωπίζετε μεγάλες ποσότητες πίεσης και επείγουσας ανάγκης.

Κατά τον χειρισμό υψηλού όγκου αιτημάτων

Αναλυτής φόρτου εργασίας κατά την εκκίνηση

Στις πρώτες μέρες του Wish, ήμασταν μια χούφτα αναλυτών και μηχανικών που κάλυπταν την ανάπτυξη μιας επιχείρησης που πραγματοποιεί πωλήσεις πολλαπλών δισεκατομμυρίων δολαρίων ετησίως. Θα μπορούσαμε να είμαστε μια ομάδα 20 και ακόμα θα εργαζόμαστε σκληρά για να καλύψουμε τη ζήτηση για δεδομένα.

Έπρεπε να είμαστε καλοί στις προτεραιότητες. Θα επικεντρωθούμε στην ολοκλήρωση των πιο σημαντικών εργασιών, και θα αναβάλουμε και θα απορρίψουμε τα πάντα.

Αλλά αυτό είναι πολύ πιο εύκολο να το πούμε παρά να γίνει. Αυτό που κάνει δίνει σε ένα αίτημα υψηλότερη προτεραιότητα από ένα άλλο; Προωθούνται τα αιτήματα λειτουργιών πριν από σφάλματα; Ποιες ομάδες θα λάβουν τη μεγαλύτερη βοήθεια;

Για να απαντήσουμε σε αυτό, κρίναμε κάθε αίτημα βάσει δύο κριτηρίων:

  1. Ο αντίκτυπος της ολοκλήρωσης της εργασίας
  2. Η εργασία που απαιτείται

Πριν δουλέψουμε στο έργο, έπρεπε να εκτιμήσουμε τον αντίκτυπό του. Αυτό σημαίνει ότι πρέπει να σκεφτούμε πώς η ολοκλήρωση της εργασίας θα επηρεάσει αυτήν την εταιρεία. Οι σχετικές ερωτήσεις περιλαμβάνουν:

  1. Ποιοι είναι οι τομείς της επιχείρησης που επηρεάζει αυτή η εργασία και το μέγεθος αυτών των περιοχών
  2. Μπορούμε να εκτιμήσουμε την ανοδική πορεία; Σε γενικές γραμμές, τάξη μεγέθους;
  3. Ποια είναι η πιθανότητα επιτυχίας;
  4. Είναι αυτό το έργο στρατηγικό για την εταιρεία; Βρισκόμαστε στον κρίσιμο δρόμο για μια μεγαλύτερη πρωτοβουλία;

Μόλις έχουμε μια γενική ιδέα για αυτό, θα πρέπει να συγκρίνουμε την εκτίμηση με το ποσό της σχετικής εργασίας. Είχαμε μια γενική ιδέα για το πόσο διαρκούν οι εργασίες. Οι διορθώσεις σφαλμάτων χρειάστηκαν μισή μέρα σε μια μέρα, οι αναφορές χρειάστηκαν δύο ημέρες έως μια εβδομάδα. Και τα αιτήματα δεδομένων ad hoc θα διαρκούσαν μισή ημέρα.

Αυτό δεν πρέπει να είναι μια ακριβής επιστήμη. Το μόνο που χρειαζόμαστε είναι μια πολύ σκληρή τάξη μεγέθους έναντι εργασίας που απαιτείται εκτίμηση που βοηθά στον προσδιορισμό των αιτημάτων που πρέπει να επεξεργαστούν.

Ακολουθώντας αυτό το πλαίσιο, ήταν η γενική προτεραιότητα για εισερχόμενα αιτήματα:

  • Γενικά, οι διορθώσεις σφαλμάτων είχαν υψηλή προτεραιότητα. Εάν κάποιος ζητήσει να διορθωθεί κάτι, μπορούμε να υποθέσουμε ότι βρήκαν αυτό το πράγμα χρήσιμο. Έτσι, η διόρθωσή του θα δημιουργήσει θετική αξία. Τις περισσότερες φορές, οι διορθώσεις σφαλμάτων ήταν γρήγορες, επομένως ο λόγος αντίκτυπου έναντι εργασίας είναι συνήθως υψηλός.
  • Τα αιτήματα λειτουργιών έπρεπε να εξεταστούν πιο προσεκτικά. Η προσθήκη μιας νέας μέτρησης σε αυτήν την αναφορά ή η δημιουργία μιας νέας αναφοράς θα βοηθήσει πραγματικά τους ενδιαφερόμενους να λάβουν καλύτερες αποφάσεις;
  • Οι βελτιώσεις συστημάτων, όπως η ενοποίηση αναφορών ή η συγχώνευση ορισμένων κοινών υπολογισμών σε ξεχωριστό αγωγό, δημιουργούν θετική αξία μεσοπρόθεσμα, αλλά χαμηλού αντίκτυπου βραχυπρόθεσμα. Αυτά πρέπει να ελαχιστοποιηθούν σε εργασίες που είναι απαραίτητες για να μην ανατινάξει το σύστημα.
  • Οι εργασίες χαμηλότερης προτεραιότητας είναι αυτές που δεν έχουν ξεκάθαρο στόχο. Αυτό συμβαίνει όταν οι ενδιαφερόμενοι δεν είναι σίγουροι για το πρόβλημα που πρέπει να λυθεί και αναζητούν περισσότερα δεδομένα για εξερεύνηση. Αυτά πρέπει να προωθηθούν πίσω, καθώς σπάνια οδηγούν τον κατάλογο σε αντίκτυπο και τείνουν να αναλαμβάνουν πολλές επαναλήψεις της εργασίας

Εάν το αίτημα έχει αντίκτυπο, αλλά συνεπάγεται περισσότερη δουλειά από ό, τι είναι απαραίτητο, συχνά περικόπτουμε τις απαιτήσεις από εργασίες. Εάν μια μέτρηση ήταν πολύ δύσκολο να υπολογιστεί, θα την καταργήσαμε από το αίτημα.

Δίνοντας προτεραιότητα στα εισερχόμενα είδη εργασίας και εστιάζοντας στις εργασίες με τον μεγαλύτερο αντίκτυπο και το μικρότερο ποσό εργασίας, καταφέραμε να κάνουμε τα περισσότερα με ό, τι λίγο χρόνο είχαμε.

Συνοψίζοντας, από νωρίς, τα αιτήματα δεδομένων είναι δύσκολο να ερωτηθούν, δύσκολο να είναι ακριβή και να έχουν παράλογο ρυθμό. Ακόμη και ακολουθώντας τις βέλτιστες πρακτικές, αυτή είναι μια συνταγή για εξουθένωση. Οι αναλυτές μπορούν να αντέξουν μόνο για τόσο καιρό.

Τα υπόλοιπα εξαρτώνται από τη μηχανική δεδομένων. Χρειαζόμασταν καλύτερη υποδομή.

Συμμετοχή ως Early Data Engineer

Το ελάχιστο βιώσιμο προϊόν της υποδομής δεδομένων περιλαμβάνει:

  1. Ένας αγωγός δεδομένων που μπορεί να χρησιμοποιηθεί για τη μεταφορά και τον περιορισμό δεδομένων
  2. Μια αποθήκη δεδομένων που έχει βελτιστοποιηθεί για αναλυτικά ερωτήματα
  3. Ένα εργαλείο επιχειρηματικής ευφυΐας που μπορεί να χρησιμοποιηθεί από αναλυτές για τη γρήγορη δημιουργία γραφημάτων

Σημείωση: Μια αναλυτική βάση δεδομένων (OLAP) είναι πολύ διαφορετική από μια παραγωγή που χρησιμοποιείται για την τροφοδοσία εφαρμογών (OLTP). Εάν μπερδευτείτε, διαβάστε αυτήν την απόκριση StackOverflow

Η εφαρμογή αυτών θα έχει ως αποτέλεσμα τη μαζική βελτίωση της αποδοτικότητας. Δημιουργία μιας πηγής δεδομένων ειδικά για επιχειρηματικά αναλυτικά στοιχεία που είναι εύκολο να ζητήσετε για μείωση του χρόνου ανάπτυξης ανά αίτημα κατά περίπου 5-7 φορές.

Η ευκολότερη υποβολή ερωτημάτων στα δεδομένα μείωσε επίσης τις τεχνικές απαιτήσεις για τους αναλυτές, γεγονός που έκανε την πρόσληψη πολύ πιο γρήγορα. Θα μπορούσαμε να εκπαιδεύσουμε αυτήν την ικανότητα αργότερα στη δουλειά, εάν χρειαστεί.

Η δημιουργία αυτού του οδικού χάρτη δεν είναι απλώς ένα πρόβλημα μηχανικής. Έπρεπε να πουλήσουμε την ιδέα της αγοράς ενός εργαλείου επιχειρηματικής ευφυΐας. Η Wish είχε μια κουλτούρα που εστιάζει στη μηχανική που προτιμούσε να χτίσει τα πράγματα στο σπίτι, οπότε έπρεπε να βρούμε έναν τρόπο να ξεπεράσουμε τις αντιρρήσεις και να αγοράσουμε την εταιρεία.

Παρακάτω, θα μιλήσω για την κατασκευή κάθε τμήματος της υποδομής δεδομένων. Και μερικά από τα βασικά μαθήματα.

Ανακατασκευή του αγωγού δεδομένων

Στην Wish, δεδομένου ότι ο υπάρχων αγωγός δεδομένων απέτυχε, η ανοικοδόμηση ήταν η πρώτη προτεραιότητα. Επιλέξαμε το Luigi ως πλαίσιο για να το ξαναχτίσουμε.

Το Luigi είναι ένα πλαίσιο ETL που αντιμετώπισε πολλά από τα προβλήματα που αντιμετώπιζε ο αγωγός:

  1. Ο τρέχων αγωγός χρησιμοποιεί τον προγραμματισμό cron για να καθορίσει τις εξαρτήσεις. Αυτό ήταν χάκεϋ και προκάλεσε αποτυχίες να καταρρεύσουν. Η Luigi έχει ενσωματωμένη διαχείριση εξάρτησης σε εργασίες.
  2. Ο τρέχων αγωγός είχε αστοχίες που απαιτούσαν χρονοβόρες επαναλήψεις. Ο Luigi είναι αδιάφορος, που σημαίνει ότι θυμάται ποιες εργασίες είναι επιτυχημένες και εκτελεί μόνο αποτυχημένες εργασίες. Αυτό καθιστά εύκολη την αποκατάσταση των αποτυχιών.
  3. Ο τρέχων αγωγός χρειάστηκε περισσότερο από 24 ώρες για να λειτουργήσει μια ημέρα εργασίας. Ο Luigi διαθέτει χρονοπρογραμματιστή, που διασφαλίζει ότι μια εργασία ETL δεν μπορεί να εκτελεστεί δύο φορές ταυτόχρονα. Από αυτό, θα μπορούσαμε να κλιμακώσουμε ένα γράφημα εργασιών σε πολλά μηχανήματα και να μειώσουμε τον χρόνο εκτέλεσης κατά περισσότερο από το μισό.

Πάνω από δύο μήνες, μετανάστευσα πάνω από 200 εργασίες ETL από το παλιό μας σύστημα και διάφορα σενάρια cron.

Η μετεγκατάσταση των εργασιών ETL σε άλλη πλατφόρμα αποδείχθηκε ασήμαντη. Το έργο καθυστέρησε στην αρχή όταν προσπάθησα να κάνω πάρα πολλά ταυτόχρονα. Μετά τη μετεγκατάσταση ορισμένων αγωγών στο νέο σύστημα, διαπίστωσα επίσης και αποφάσισα να διορθώσω ορισμένα ζητήματα ζώνης ώρας στον κώδικα ETL. Το αποτέλεσμα ήταν ένα νέο σύστημα που ήταν εξαιρετικά δύσκολο να επικυρωθεί.

Έμαθα μερικά μαθήματα από αυτό το έργο που συνοψίστηκαν όμορφα σε ένα πρόσφατο άρθρο που διάβασα για το πώς να βελτιώσω τις παλαιότερες βάσεις κώδικα:

  1. Προσπαθήστε να μην αλλάξετε πάρα πολλά πράγματα ταυτόχρονα
  2. Μην αλλάζετε τη λογική της επιχείρησης κατά την αλλαγή της υποδομής
  3. Αυτοματοποιήστε τη δοκιμή με σενάρια επικύρωσης

Οι κύριοι κίνδυνοι με την επανακατασκευή είναι ότι μπορείτε να εισαγάγετε έναν τόνο νέων σφαλμάτων. Με πάνω από 200 δουλειές ETL για μετανάστευση, το να είναι laissez faire διατηρώντας το τελικό αποτέλεσμα του συστήματος το ίδιο θα είχε σκοτώσει το έργο.

Έτσι, ο ευκολότερος τρόπος αντιμετώπισης αυτού είναι η εισαγωγή μικρών αλλαγών που μπορούν να επικυρωθούν αυτόματα χρησιμοποιώντας ένα πλαίσιο δοκιμών και να ταιριάζουν με το παλιό σύστημα. Αλλαγές που αλλάζουν το τελικό αποτέλεσμα θα πρέπει να αποφεύγονται έως ότου ολοκληρωθεί ολόκληρο το έργο.

Για αυτό το έργο, αυτό σήμαινε την κατασκευή ενός δοκιμαστικού εργαλείου που έδωσε επιτυχία / αποτυχία σε μετεγκατεστημένους αγωγούς, συγκρίνοντας την έξοδο του με τον παλιό αγωγό.

Το νέο σύστημα που βασίστηκε στη Luigi ήταν barebones. Αλλά ήταν σταθερό και αντιμετώπισε τις δικές του αποτυχίες. Ήταν κάτι στο οποίο μπορούμε να βασιστούμε καθώς χτίσαμε την υπόλοιπη υποδομή δεδομένων.

Κατασκευή της αποθήκης δεδομένων

Το γρήγορο MVP για αποθήκη δεδομένων μπορεί να προσαρμοστεί από την υπάρχουσα βάση κώδικα

Η αποθήκη δεδομένων είναι μια βάση δεδομένων που κάνει τη γραφή και την εκτέλεση ερωτημάτων ανάλυσης γρήγορα. Συνήθως περιλαμβάνει πίνακες που είναι εύκολο να κατανοηθούν και να ερωτηθούν - μια πολύ πιο καθαρή αναπαράσταση των πινάκων παραγωγής.

Για παράδειγμα, ένας από τους πιο συχνά χρησιμοποιούμενους πίνακες στην αποθήκη δεδομένων μας ονομάζεται merch_merchanttransaction. Αυτός είναι ένας πίνακας όπου κάθε σειρά αντιπροσωπεύει τα πάντα για μια παραγγελία για την οποία μπορεί να θέλει να γνωρίζει ένας αναλυτής. Αντί να καταναλώνουν χρόνο, το MongoDB συμμετέχει για λήψη παραγγελιών + δεδομένων παρακολούθησης ή παραγγελιών + πληροφοριών επιστροφής χρημάτων, οι αναλυτές μπορούν να γράφουν ερωτήματα σε αυτόν τον ενιαίο πίνακα και συνήθως λαμβάνουν αποτελέσματα σε λεπτά, έναντι ωρών που ξοδεύουν το ερώτημα MongoDB.

Η διάθεση μιας αποθήκης δεδομένων είναι εξαιρετικά εύκολη. Απλώς έπρεπε να ξαναχρησιμοποιήσουμε πολλή δουλειά που είχε ήδη γίνει για τη δημιουργία αναφορών.

Θα μπορούσαμε να ξεκινήσουμε τη σχεδίαση των πινάκων μας εξετάζοντας τις πιο σημαντικές υπάρχουσες αναφορές και επιλέγοντας τις πιο σημαντικές μετρήσεις και ιδιότητες. Στη συνέχεια θα μπορούσαμε να επαναπροσδιορίσουμε τον κώδικα που δημιούργησε αυτούς τους αριθμούς στις αναφορές, σε αγωγούς δεδομένων που έβγαλαν πιο αναλυτικές εγγραφές στο επιλεγμένο κατάστημα δεδομένων μας.

Αυτή η διαδικασία διήρκεσε λιγότερο από τρεις εβδομάδες. Στο τέλος, είχαμε μια αποθήκη δεδομένων που κάλυπτε ένα μεγάλο ποσοστό των διαδικασιών της εταιρείας και θα μπορούσε να χρησιμοποιηθεί για να επιταχύνει τα ερωτήματα των αναλυτών.

Επιλέξαμε το Redshift ως βάση δεδομένων μας. Χρησιμοποιούσαμε ήδη το Hive (TreasureData) για καταγραφή εφαρμογών, οπότε το χρησιμοποιήσαμε ξανά για την απόρριψη και τον υπολογισμό των νέων πινάκων μας. Το TreasureData έχει μια ενσωμάτωση Redshift, την οποία χρησιμοποιήσαμε για την αποστολή ακριβών αντιγράφων αυτών των πινάκων σε ένα σύμπλεγμα Redshift.

Ανάπτυξη εργαλείων Business Intelligence

Μέρος του καταστρώματος - πώληση της ιδέας της αγοράς εργαλείων BI εσωτερικά

Η αναφορά έγινε αρχικά μέσω email HTML, που στάλθηκαν από σενάρια python. Αυτό είναι πραγματικά πολύ αποτελεσματικό:

  1. Δεδομένου ότι αυτά ήταν μόνο σενάρια Python που έστειλαν δεδομένα μορφοποιημένα HTML, οι εργασίες αναφοράς θα μπορούσαν να ανατεθούν σε οποιονδήποτε μηχανικό της ομάδας.
  2. Δεν υπήρχε περιορισμός στον τρόπο με τον οποίο οι πίνακες και τα γραφήματα θα μπορούσαν να μορφοποιηθούν και να εμφανιστούν, σε αντίθεση με τις πιο άκαμπτες δομές που βρέθηκαν στο BI tooling. Η έκθεση θα μπορούσε να σχεδιαστεί ακριβώς για το σύστημα.

Αλλά υπήρχαν περιορισμοί, οι οποίοι καθιστούσαν δύσκολο να αναπτυχθεί αυτό το σύστημα:

  • Αυτές οι αναφορές ήταν δύσκολο να γραφτούν και να δοκιμαστούν - μερικές φορές χρειάζονται έως και μία ημέρα για να εκτελεστούν.
  • Δεν υπήρχαν αναλύσεις και φιλτράρισμα, οπότε διαφορετικές αναλυτικές προβολές για τα ίδια δεδομένα θα έπρεπε να συγκεντρωθούν σε πολλές αναφορές.
  • Η τροποποίηση αυτών των αναφορών με ακόμη και τη μικρότερη αλλαγή χρειάστηκε χρόνος καθώς η δοκιμή ήταν χρονοβόρα και με την πάροδο του χρόνου υπήρχε μια μεγάλη βάση κώδικα για συντήρηση.

Για να το επιλύσουμε αυτό, χρειαζόμασταν να αναπτύξουμε ένα εργαλείο επιχειρηματικής ευφυΐας, το οποίο χειρίστηκε τη γρήγορη οπτικοποίηση πάνω από μια αποθήκη δεδομένων.

Η εφαρμογή θα ήταν εύκολη. Οι σύγχρονες λύσεις SaaS που βασίζονται στο cloud είναι περισσότερο ή λιγότερο plug and play.

Ο αποκλειστής έλαβε έγκριση αγοράς. Πώς μπορείτε να πείσετε έναν υπεύθυνο λήψης αποφάσεων (τον ΚΟΤ μας), ότι χρειαζόμαστε να αγοράσουμε ένα εργαλείο για να επιταχύνουμε την αναφορά, όταν δεν έχει άμεση σύνδεση με κανένα από τα σημεία πόνου που αναφέρονται παραπάνω; Το μόνο που βλέπει είναι το τελικό αποτέλεσμα - αναφορές μέσω email. Και σε αυτόν, αυτό το σύστημα λειτούργησε καλά.

Όμως τα σημεία πόνου στην αναφορά υπήρχαν και κάθε μηχανικός που δούλεψε στις αναφορές μέσω email το ένιωθε. Τελικά είχα αρκετή αγορά στο μεσαίο επίπεδο διαχείρισης για να ξεκινήσω τη διαδικασία πώλησης.

Από την αρχή έως το τέλος, αυτή η διαδικασία απόκτησης για το Looker διήρκεσε περίπου δύο μήνες. Προκειμένου, ακολουθούν τα απαραίτητα βήματα:

  1. Μια παρουσίαση στον διευθυντή μου (Επικεφαλής πλατφόρμας) σχετικά με την πιθανή προστιθέμενη αξία του Looker, συμπεριλαμβανομένων εκτιμήσεων για αυξημένο χρόνο στο ταμπλό και αποθηκευμένη εργασία
  2. Λήψη αγορών από ενδιαφερόμενους σε επιχειρηματικές δραστηριότητες, με βάση το πόσο γρήγορα η Looker επρόκειτο να δημιουργήσει αναφορές για αυτούς
  3. Λήψη αγορών από τον Jack, τον επικεφαλής δεδομένων μας, με βάση την υποστήριξη από το 1 + 2
  4. Διαπραγμάτευση μιας δοκιμαστικής φάσης για το Looker, ώστε να μπορέσουμε να δημιουργήσουμε τους αρχικούς πίνακες ελέγχου (4 εβδομάδες)
  5. Χρησιμοποιώντας αυτόν τον χρόνο για να δημιουργήσετε ένα βασικό σύνολο ταμπλό για την εταιρεία (20 πίνακες ελέγχου)
  6. Παρουσίαση των δεδομένων από αυτήν τη δοκιμαστική φάση, ένα εκλεπτυσμένο μοντέλο για απόδοση επένδυσης (ROI) με βάση τον χρόνο που εξοικονομείται ανά πίνακα ελέγχου και παρουσίαση στον CTO για τελική έγκριση

Αυτό μπορεί να ακούγεται πολύ γραφειοκρατικό. Ωστόσο, η απόφαση για την ανάπτυξη ενός εργαλείου που χρησιμοποιείται σε ολόκληρη την εταιρεία πρέπει να εξεταστεί προσεκτικά. Αυτή η διαδικασία διασφαλίζει ότι ο αντίκτυπος έχει μελετηθεί, από την άποψη όλων των χρηστών που τελικά θα εξαρτηθούν από το σύστημα δεδομένων.

Παρουσιάζοντας ένα επιχείρημα βασισμένο σε απόδοση επένδυσης (ROI) που βασίζεται στην εξοικονόμηση κόστους στη μείωση του αριθμού και στη βελτίωση της απόδοσης έναντι της τιμής του Looker και του Redshift, καταφέραμε να προωθήσουμε προηγούμενες αντιρρήσεις σχετικά με την κατασκευή έναντι της αγοράς και τη χρήση εναλλακτικών δωρεάν εργαλείων.

Η υποδομή δεδομένων… ξαναχτίστηκε!

Με την εμφάνιση του Looker, είχαμε ξαναχτίσει επιτυχώς τα θεμέλια των αναλυτικών στοιχείων στο Wish. Από εδώ, θα μπορούσαμε να μειώσουμε τον αριθμό των χρημάτων και να αρχίσουμε να ικανοποιούμε τη ζήτηση για δεδομένα που έχουν καθυστερήσει τόσο πολύ στην εταιρεία. Ήταν ένα τεράστιο ορόσημο.

Για το υπόλοιπο άρθρο, θα μιλήσω για τα επόμενα βήματα. Πώς να κλιμακώσετε τις ομάδες μηχανικών δεδομένων και αναλυτών και πώς να προσλάβετε και να διαχειριστείτε για υψηλή απόδοση.

Για να συνεχίσετε την ανάγνωση, κάντε κλικ εδώ για την επόμενη ενότητα (Scaling Data Engineering).

Μετάβαση σε

  1. Μέρος 1 - Ανακατασκευή του Ιδρύματος
  2. Μέρος 2 - Μηχανική κλιμάκωσης δεδομένων
  3. Μέρος 3 - Ανάλυση δεδομένων κλιμάκωσης
  4. Μέρος 4 - Πρόσληψη

Ελάτε να δουλέψετε μαζί μας!

Οδηγώ την ομάδα δεδομένων της πλατφόρμας εμπόρων. Είμαστε η ομάδα που υποστηρίζει τα πάντα στην πλευρά των πωλητών στην αγορά - την πύλη που χρησιμοποιούν οι έμποροι για τη διαχείριση πωλήσεων και αποθέματος και βλέπουμε εάν συμμορφώνονται με τις πολιτικές μας. Διαθέτουμε στρατηγικά χαρακτηριστικά που περιλαμβάνουν το Wish Express (το πρόγραμμα 7 ημερών αποστολής) και το ProductBoost, τη διαφημιστική μας πλατφόρμα. Διαθέτουμε επίσης τον εκτιμητή αποστολής που αντιμετωπίζει ο χρήστης.

Ελάτε να συμμετάσχετε εάν ενδιαφέρεστε για μεγάλα ποσά ιδιοκτησίας. Αυτό σημαίνει ότι ως αναλυτές, θα έχετε αποφάσεις που επηρεάζουν την εταιρεία με μεγάλες διακυμάνσεις ως προς τα έσοδα (+ 1% ή περισσότερο). Ως μηχανικοί, θα έχετε στην κατοχή σας και θα δημιουργήσετε το σύστημα που υποστηρίζει κάθε δυνατότητα δεδομένων και πολιτική από την πλευρά του εμπόρου.

Χρειαζόμαστε αρκετές προσλήψεις σε κάθε ρόλο:

  • Αναλυτής δεδομένων / Ανώτερος αναλυτής δεδομένων Ιδιότητες πολιτικών, προγραμμάτων και προϊόντων. Ποσοτικοποιήστε το ανάποδα και το μειονέκτημα των αποφάσεων και οδηγήστε τους στην ολοκλήρωση.
  • Μηχανικός λογισμικού - Τα δεδομένα δεδομένων χρησιμοποιούνται σε μεγάλο βαθμό στην πύλη πωλητών. Δίνει δύναμη σε όλους τους πίνακες ελέγχου που αντιμετωπίζουν οι χρήστες και τη μηχανή πολιτικής μας που δίνει παραβάσεις σε εμπόρους με χαμηλή απόδοση. Βοηθήστε στη δημιουργία δυνατοτήτων δεδομένων και κλιμακώστε αυτό το σύστημα.
  • Ποσοτική αναλυτική εργασία για τις εκτιμήσεις αποστολής, μια δυνατότητα που αντιμετωπίζει ο χρήστης και ενημερώνει τους χρήστες για την εκτίμηση του πότε θα φτάσουν τα προϊόντα. Εργαστείτε σε χαρακτηριστικά κινδύνου και μειώστε την απάτη εμπόρου.
  • Όλοι οι άλλοι ρόλοι

Στείλτε μου email στο [email protected] για παραπομπή.