Στις αρχές Δεκεμβρίου, έκανα ένα μοιραίο λάθος και έκανα μια καμπή στη ζωή μου ως προγραμματιστής και μετακόμισα στην ομάδα Data Engineering (DE) της εταιρείας. Σε αυτό το άρθρο θα μοιραστώ κάποιες παρατηρήσεις που έκανα κατά τη διάρκεια δύο μηνών εργασίας στην ομάδα της ΔΕ.
Γιατί Μηχανική Δεδομένων;
Το ταξίδι μου στη ΔΕ ξεκίνησε το καλοκαίρι του 2019, όταν εμείς ας πάμε στο , και εκεί πέτυχα τη φώτιση. Άρχισα να ενδιαφέρομαι για το θέμα, να μελετώ αλγόριθμους και ακόμη και για αυτούς , και στη συνέχεια σκέφτηκε το εύρος της εφαρμογής και γρήγορα ανακάλυψε ότι η πρακτική εφαρμογή στην εταιρεία μας είναι κατανεμημένες βάσεις δεδομένων.
Τι ακριβώς κάνει η ομάδα μας; Εμείς, όπως όλα τα μοντέρνα αγόρια και κορίτσια, θέλουμε να γίνουμε εταιρεία με γνώμονα τα δεδομένα. Και για να γίνει αυτό εφικτό, πρέπει τουλάχιστον να δημιουργήσουμε μια αξιόπιστη εγκατάσταση αποθήκευσης, η οποία μπορεί να χρησιμοποιηθεί για τη δημιουργία οποιωνδήποτε αναφορών χρειάζεται η εταιρεία. Αλλά το πιο σημαντικό είναι ότι τα δεδομένα σε αυτήν την αποθήκευση πρέπει να είναι αξιόπιστα. Επιπλέον, χρησιμοποιώντας αυτά τα δεδομένα, πρέπει να είστε σε θέση να επαναφέρετε την κατάσταση του συστήματος τη στιγμή t. Όλα αυτά περιπλέκονται από το γεγονός ότι ζούμε σε έναν γενναίο νέο κόσμο μικροϋπηρεσιών και αυτή η ιδεολογία υπονοεί ότι κάθε υπηρεσία εφαρμόζει τη δική της μικρή λειτουργικότητα, η βάση δεδομένων της είναι δική της δουλειά και μπορεί να τη διαγράφει τουλάχιστον κάθε μέρα, αλλά στο ταυτόχρονα πρέπει να μπορούμε να λαμβάνουμε και να επεξεργαζόμαστε την κατάσταση της υπηρεσίας.
Εάν θέλετε να οδηγηθείτε σε δεδομένα, πρώτα γίνετε Οδηγοί συμβάντων
Όχι τόσο απλό. Τα συμβάντα είναι διαφορετικά και ο προγραμματιστής και ο μηχανικός δεδομένων τα βλέπουν διαφορετικά. Η συζήτηση για τα γεγονότα είναι ένα θέμα για ένα ξεχωριστό άρθρο, επομένως δεν θα υπεισέλθω σε αυτό εδώ. Επιπλέον, ένα τέτοιο άρθρο έχει ήδη κάποιον Μάρτιν Φάουλερ, δεν θα του αφαιρέσω τις δάφνες, ας γίνει κι αυτός διάσημος.
Γενικά, υπάρχουν πολλά να σκεφτούμε και γι' αυτό η περιοχή είναι ελκυστική. Συμβαίνει ότι στην εταιρεία μας, ένας Μηχανικός Δεδομένων είναι πολύ ευρύτερος τομέας ευθύνης από ένα άτομο που γράφει αγωγούς ETL/ELT (αν δεν ξέρετε τι σημαίνουν αυτές οι συντομογραφίες, ελάτε στο . Ως συμφραζόμενη διαφήμιση).
Ασχολούμαστε με την αρχιτεκτονική αποθήκευσης, τη μοντελοποίηση δεδομένων, θέματα που σχετίζονται με την ασφάλεια των δεδομένων και τους ίδιους τους αγωγούς, φυσικά. Πρέπει επίσης να βεβαιωθούμε ότι, αφενός, η παρουσία μας δεν είναι πολύ επιβαρυντική για τους προγραμματιστές προϊόντων και ότι πρέπει να αποσπώνται όσο το δυνατόν λιγότερο από τις απαιτήσεις μας όταν κόβουμε νέες δυνατότητες στο σύστημα, και από την άλλη, πρέπει να τα παρέχει βολικά τοποθετημένα σε δεδομένα αποθήκευσης για αναλυτές και ομάδα BI. Έτσι ζούμε.
Δυσκολίες κατά τη μετάβαση από την ανάπτυξη
Την πρώτη μου μέρα εργασίας, συνάντησα μια σειρά από δυσκολίες που θέλω να μοιραστώ μαζί σας.
1. Το πρώτο πράγμα που είδα ήταν η απουσία τουλινγκ και κάποιες πρακτικές. Πάρτε, για παράδειγμα, την κάλυψη κωδικών με δοκιμές. Έχουμε εκατοντάδες πλαίσια δοκιμών υπό ανάπτυξη. Όταν εργάζεστε με δεδομένα, όλα είναι πιο περίπλοκα. Ναι, μπορούμε να δοκιμάσουμε τους αγωγούς ETL σε δεδομένα δοκιμών, αλλά πρέπει να τα κάνουμε όλα χειροκίνητα και να αναζητήσουμε λύσεις για κάθε συγκεκριμένη περίπτωση. Ως αποτέλεσμα, η κάλυψη της δοκιμής είναι πολύ χειρότερη. Ευτυχώς, υπάρχει ένα άλλο επίπεδο ανατροφοδότησης με τη μορφή παρακολούθησης και αρχείων καταγραφής, αλλά αυτό απαιτεί ήδη να αντιδρούμε αντιδραστικά και όχι προληπτικά, κάτι που είναι εξοργιστικό και εκνευριστικό.
2. Ο κόσμος από την οπτική γωνία του DE δεν είναι καθόλου αυτό που φαίνεται σε έναν συνηθισμένο προγραμματιστή προϊόντων (καλά, φυσικά ο αναγνώστης δεν είναι έτσι, και τα ξέρει ήδη όλα, αλλά δεν το ήξερα και τώρα σκέφτομαι το επάνω). Ως προγραμματιστής, δημιουργώ τη δική μου microservice, βάζω τα δεδομένα στη [βάση δεδομένων της επιλογής σας], αποθηκεύω την πολιτεία μου εκεί, λαμβάνω κάτι με αναγνωριστικό και είναι εντάξει. Η εξυπηρέτηση είναι αργή, οι παραγγελίες προκαλούν σύγχυση, αυτό είναι όλο. Μου ζητούν να ψάξω για την πολιτεία μου σε άλλη υπηρεσία, οπότε θα ρίξω μια εκδήλωση σε κάποιο RabbitMQ και αυτό είναι. Και εδώ επιστρέψαμε ξανά στο θέμα των γεγονότων που περιγράφηκαν παραπάνω.
Αυτό που χρειάζεται η υπηρεσία για επιχειρησιακές εργασίες δεν μας ταιριάζει για ιστορικά δεδομένα, επομένως ξεκινά το ζήτημα της επανεξέτασης των συμβάσεων υπηρεσιών και της στενής συνεργασίας με τις ομάδες ανάπτυξης. Δεν μπορείτε καν να φανταστείτε πόσες ώρες μας πήρε για να συμφωνήσουμε: τι είδους Event Driven είναι στην εταιρεία μας.
3. Πρέπει να σκεφτείς με το κεφάλι σου. Όχι, δεν εννοώ ότι οι προγραμματιστές δεν σκέφτονται (αν και ποιος είμαι εγώ για να μιλήσω για όλους), είναι απλώς ότι στην ανάπτυξη προϊόντων πολύ συχνά έχετε ήδη κάποιο είδος αρχιτεκτονικής και κόβετε διαφορετικές ανακατώσεις από το ανεκτέλεστο. Φυσικά, αυτό απαιτεί προγραμματισμό και σκέψη, αλλά αυτό είναι έργο ροής, όπου το κύριο πρόβλημα είναι απλώς να το κάνουμε καλά και αποτελεσματικά.
Για εμάς, δεν είναι τόσο απλό, επειδή η μεταφορά διαφόρων στοιχείων του συστήματος από έναν ζεστό και άνετο μονόλιθο στον κόσμο της άγριας ζούγκλας μικροϋπηρεσιών δεν είναι τόσο απλή. Όταν η υπηρεσία ξεκινά να εκτοξεύει συμβάντα, πρέπει να επανεξετάσετε τη λογική για την πλήρωση του χώρου αποθήκευσης, επειδή τα δεδομένα φαίνονται πλέον διαφορετικά. Εδώ πρέπει να σκεφτείς πολύ και διεξοδικά, όχι πλέον ως προγραμματιστής, αλλά ως μηχανικός δεδομένων. Είναι μια συνηθισμένη ιστορία όταν περνάς μέρες με ένα σημειωματάριο και στυλό ή με έναν μαρκαδόρο στον πίνακα. Είναι πολύ δύσκολο, δεν μου αρέσει να σκέφτομαι, μου αρέσει και η παραγωγή.
4. Ίσως το πιο σημαντικό πράγμα είναι η ενημέρωση. Τι κάνουμε όταν μας λείπει η γνώση; Ποιος είπε το stackoverflow; Βγάλτε αυτό το άτομο από το δωμάτιο. Πηγαίνουμε να διαβάσουμε έγγραφα, βιβλία για το θέμα, και υπάρχει επίσης μια κοινότητα που οργανώνει φόρουμ, συναντήσεις και συνέδρια. Η τεκμηρίωση είναι εξαιρετική, αλλά δυστυχώς, μπορεί να είναι ελλιπής. Χρησιμοποιούμε το Cosmos DB σε μια σειρά από έργα. Καλή τύχη διαβάζοντας την τεκμηρίωση για αυτό το προϊόν. Τα βιβλία είναι η μόνη σωτηρία· ευτυχώς υπάρχουν και μπορούν να βρεθούν, περιέχουν πολλές θεμελιώδεις γνώσεις και πρέπει να διαβάζεις πολύ και συνεχώς. Το πρόβλημα όμως είναι στην κοινότητα.
Τώρα είναι δύσκολο να βρούμε τουλάχιστον ένα κατάλληλο συνέδριο ή συνάντηση στην περιοχή μας. Όχι, φυσικά, υπάρχουν πολλές συναντήσεις με τη λέξη Data, αλλά δίπλα σε αυτή τη λέξη υπάρχουν συνήθως περίεργες συντομογραφίες όπως ML ή AI. Έτσι, αυτό δεν είναι για εμάς, μιλάμε για το πώς να χτίσουμε εγκαταστάσεις αποθήκευσης και όχι για το πώς να λερώνουμε τον εαυτό μας με νευρώνες. Αυτοί οι χίπστερ έχουν καταλάβει τα πάντα. Ως αποτέλεσμα, είμαστε χωρίς κοινότητα. Παρεμπιπτόντως, εάν είστε Μηχανικός Δεδομένων και γνωρίζετε καλές κοινότητες, γράψτε στα σχόλια.
Συμπεράσματα και ανακοίνωση της συνάντησης
Με τι καταλήγουμε; Η πρώτη μου εμπειρία μου λέει ότι το να νιώθεις στη θέση ενός μηχανικού δεδομένων θα είναι χρήσιμο για κάθε προγραμματιστή. Μας επιτρέπει απλώς να βλέπουμε τα πράγματα διαφορετικά και να μην εκπλαγούμε όταν τα μάτια μας αιματώνονται όταν βλέπουμε πώς οι προγραμματιστές χειρίζονται τα δεδομένα τους. Έτσι, αν υπάρχει ΔΕ στην παρέα σας, απλά μιλήστε με αυτά τα παιδιά, θα μάθετε πολλά νέα πράγματα (για τον εαυτό σας).
Και τέλος η ανακοίνωση. Δεδομένου ότι είναι δύσκολο να βρούμε συναντήσεις για το θέμα μας κατά τη διάρκεια της ημέρας, αποφασίσαμε να κάνουμε τις δικές μας. Γιατί είμαστε χειρότεροι; Ευτυχώς έχουμε ένα καταπληκτικό και οι φίλοι μας από , οι οποίοι, όπως και εμείς, πιστεύουν ότι οι μηχανικοί δεδομένων στερούνται άδικα την προσοχή.
Με αυτήν την ευκαιρία, καλώ όλους όσους ενδιαφέρονται να έρθουν στην πρώτη μας συνάντηση της κοινότητας με τον πολλά υποσχόμενο τίτλο «DE or DIE», που θα πραγματοποιηθεί στις 27.02.2020 Φεβρουαρίου XNUMX στο γραφείο Dodo Pizza. Λεπτομέρειες στο .
Αν συμβεί κάτι, θα είμαι εκεί, μπορείτε να μου πείτε προσωπικά κατά πόσο κάνω λάθος με τους προγραμματιστές.
Πηγή: www.habr.com