Ένας πλήρης οδηγός για το πώς να σπάσει ο μονόλιθος δεδομένων.

Πώς να αντιμετωπίσετε το νέο μεγάλο στόχο στον κόσμο του λογισμικού.

Σπάστε το μονόλιθο δεδομένων!

Κίνητρο

Μονόλιθος δεδομένων

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

Έχω εργαστεί σε πολλά έργα (σε διαφορετικές εταιρείες) για τα τελευταία χρόνια και έχω δει ότι τα προβλήματα που προκαλούν τα μονολιθικά δεδομένα είναι παρόμοια:

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

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

Ο συνηθισμένος τρόπος να το κάνεις

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

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

Πώς να σπάσει ο μονόλιθος

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

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

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

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

Δεδομένα κατανεμημένη στρατηγική

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

Υποδομή δεδομένων ως πλατφόρμα

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

Στο άρθρο των ματιών δεδομένων από το blog του Martin Fowler (που γράφτηκε από τον πρώην συνεργάτη μου στο Thoughtworks Zhamak Dehghani) γράφουν κάποιες δυνατότητες που πρέπει να διαθέτει αυτή η υποδομή, μερικές από τις οποίες είναι: κλιμακούμενη αποθήκευση δεδομένων polyglot dig, έκδοση παραμέτρων δεδομένων, σχήμα δεδομένων, / ειδοποίηση / καταγραφή, μετρήσεις ποιότητας δεδομένων προϊόντων, διαχείριση δεδομένων, ασφάλεια και υπολογισμός και τοποθεσία.

Με αυτήν την πλατφόρμα δεδομένων, οι ομάδες (προγραμματιστές και επιστήμονες δεδομένων) πρέπει να φροντίζουν μόνο τι θέλουν να κάνουν με τα δεδομένα που παράγουν και πώς θα εξυπηρετούν αυτά τα δεδομένα σε άλλες ομάδες, όπως τώρα με το CircleCi ή Jenkins (οι ομάδες πρέπει μόνο να σκεφτούν πώς θέλουν να κάνουν το CI, όχι την υποδομή). Για παράδειγμα, σε αυτή την εικόνα, το Metaflow εξηγεί την υποδομή από την άποψη των επιστημόνων δεδομένων:

Εικόνα από τη μεταλλαγή

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

Σχέδιο δεδομένων ματιών από το ιστολόγιο του Martin Fowler

Εντάξει, OK OK ... Καταλαβαίνω την έννοια και όλα τα άλλα, αλλά ... Τι γίνεται με τη στρατηγική για την επίτευξη αυτού;

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

Θα μπορούσαμε να χρησιμοποιήσουμε πολλά εργαλεία και πλαίσια για να κάνουμε τους δικούς μας αγωγούς δεδομένων με κώδικα. Στην ομάδα μηχανικών της Packlink, αγαπάμε το GCP έτσι σε αυτήν την ανάρτηση πρόκειται να εξηγήσω αυτά τα πράγματα με την Airflow επειδή η πλατφόρμα Google έχει ένα click-and-play και πλήρως διαχειριζόμενη ορχήστρα ροής εργασιών ενσωματωμένη στο Airflow: Cloud Composer.

Θυμηθείτε ότι τα σημαντικά σημεία (το ίδιο όπως και στις υπηρεσίες είναι τα ίδια αν χρησιμοποιείτε CircleCI, Jenkins, κλπ.) Είναι οι ιδέες, το εργαλείο είναι μόνο ένας τρόπος για να επιτύχουμε τους στόχους μας. Άλλα καλά εργαλεία / πλαίσια είναι η Metaflow, Luigi, Prefect, Pinball. Αυτή τη στιγμή κάθε εταιρεία κατασκευάζει το δικό της πλαίσιο και όλα τα διαφορετικά, αλλά, επιμένοντας, το σημείο είναι η ιδέα και ότι κάθε ένα από αυτά είναι κώδικας. Στα επόμενα τμήματα περνάω:

  • Strangler πρότυπο: ως στρατηγική για την επίτευξη του.
  • Αγωγός δεδομένων: πώς πρέπει να είναι αυτός ο αγωγός;
  • Κωδικός: ο κωδικός που δοκιμάστηκε για να γράψει τον αγωγό.

Πρότυπο περιγράμματος

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

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

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

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

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

Αγωγός δεδομένων

Τα κύρια σημεία που πρέπει να έχει αυτός ο αγωγός είναι:

  • Συζητήσεις δεδομένων. Δεν μοιράζονται όλα τα δεδομένα που παράγονται από τις υπηρεσίες και δεν παράγονται όλα τα δεδομένα που παράγονται. Μερικές φορές πρέπει να κάνουμε μερικούς μετασχηματισμούς. Θα κάνουμε με τον κώδικα και όπως πάντα λέω, ο κώδικας είναι κωδικός έτσι πρέπει να εφαρμόζουμε πάντα τις βέλτιστες πρακτικές.
  • Έλεγχος σχήματος. Εάν θέλουμε να διασφαλίσουμε την ποιότητα των δεδομένων μας, πρέπει να χρησιμοποιήσουμε ένα σχήμα όταν το μοιραζόμαστε με άλλα μέρη της εταιρείας (υπηρεσίες, αναλυτικά στοιχεία κ.λπ.). Για παράδειγμα, έχουμε την ηλικία των ανθρώπων που θέλουμε να διασφαλίσουμε ότι αυτή η τιμή είναι ένας ακέραιος αριθμός και ότι η μέγιστη τιμή είναι ... 150; Μπορείτε να χρησιμοποιήσετε διαφορετικά συστήματα serialization δεδομένων για να το επιτύχετε, σας συνιστώ Πρωτόκολλα Buffer ή Avro. Με αυτό, τόσο ο παραγωγός όσο και ο καταναλωτής γνωρίζουν τι σημαίνει κάθε σημείο δεδομένων.
  • Εξαγωγή αμετάβλητων συνόλων δεδομένων ως προϊόντων. Κάθε υπηρεσία είναι υπεύθυνη να μοιραστεί τις πληροφορίες με τον οργανισμό. Το βέλτιστο είναι να μοιραστείτε τα αμετάβλητα σύνολα δεδομένων που εκδόθηκαν μέσω ενός μεσολαβητή ανταλλαγής μηνυμάτων όπως ο Kafka ή η pub / sub. Μια καλή δημοσίευση που μιλάει για δεδομένα ανταλλαγής σε κατανεμημένα συστήματα μπορεί να διαβάσει εδώ. Σημειώστε αυτό: τα δεδομένα, όπως μάθαμε και στον λειτουργικό προγραμματισμό, πρέπει να είναι αμετάβλητα και επίσης μας επιτρέπει να έχουμε όλη την ιστορία και να κάνουμε τις συγκεντρώσεις που απαιτούνται αργότερα χωρίς να τις σώσουμε.
  • Έκδοση δεδομένων / δεδομένων ως κωδικός. Όπως δημιουργήσαμε στον κώδικα, χρειαζόμαστε την έκδοση των συνόλων δεδομένων μας, ακόμη περισσότερο, θέλουμε τα δεδομένα ως κώδικα. Έχει κάποια πλεονεκτήματα: μπορούμε να αναπαράγουμε εύκολα σφάλματα, να χρησιμοποιήσουμε τα σύνολα δεδομένων στις δοκιμές μας και τους αγωγούς μας, πολλά οφέλη στη μηχανική μάθηση (περισσότερες πληροφορίες εδώ) και σίγουρα όλα τα καλά πράγματα που έχει ο κώδικας. Το DVC, ένα σύστημα ελέγχου δεδομένων δεδομένων και μοντέλων βασισμένο σε git, είναι η λύση για μένα ένα από τα καλύτερα εργαλεία στον κόσμο των δεδομένων.
DVC διαγράμματα σχετικά με τα δεδομένα και τα μοντέλα ως κωδικό και δεδομένα ανταλλαγής
  • Διακυβέρνηση δεδομένων και γενεαλογία. Αυτό είναι ένα από τα πιο σημαντικά σημεία για μένα στη γραμμή δεδομένων, αν θέλουμε να σπάσουμε το μονόλιθο δεδομένων. Πρώτα απ 'όλα, χρειαζόμαστε στην πλατφόρμα δεδομένων ένα εργαλείο για να το σώσουμε. Υπάρχουν κάποιες καλές εναλλακτικές λύσεις, αλλά θα προτείνω μόνο δύο: Lyft Ammundsen και εάν χρησιμοποιείτε το GCP, Κατάλογος Δεδομένων. Και οι δύο έχουν αυτόματη ανακάλυψη των δεδομένων. Το σημαντικό εδώ δεν είναι το εργαλείο, είναι και η ιδέα. Πρέπει να αποθηκεύσουμε στους αγωγούς μας την περιγραφή των δεδομένων που μοιράζουμε και τα μεταδεδομένα μέσω του API στο εργαλείο μας, όπως αυτή η βιβλιοθήκη κάνει στον Κατάλογο Δεδομένων και βάζει τα απαραίτητα για να έχει μια σωστή σειρά των δεδομένων. Χάρη σε αυτό, όλοι θα ξέρουν πού είναι τα δεδομένα, ποιος είναι ο ιδιοκτήτης, πώς είναι και τι σημαίνει κάθε αξία.
Διαχείριση δεδομένων με τον Lyft Ammundsen
  • Παρατηρησιμότητα. Πρέπει να κατανοήσουμε πώς λειτουργεί το σύστημά μας και θα το κάνουμε να λειτουργεί πάνω από τρία είδη επιπέδων: επίπεδο υποδομής, συμβάντα επιπέδου εργασίας και επίπεδο δεδομένων. Δημιουργήστε έναν πίνακα ελέγχου με σαφείς και χρήσιμες πληροφορίες. Αυτό είναι το κύριο σημείο. Κάνουμε πολύπλοκα συστήματα, οπότε πρέπει να έχουμε ένα ταμπλό μόνο με τις πιο σημαντικές πληροφορίες για να καταλάβουμε εύκολα αν τα συστήματά μας λειτουργούν σωστά. Με αυτό, όταν το πλοίο συμβαίνει, και αυτό θα γίνει, θα είστε ο πρώτος που θα το ανακαλύψετε. Ένα τυπικό σφάλμα στα δεδομένα είναι να ξεχνάμε τις σιωπηλές αποτυχίες. Εάν μια πηγή σταματήσει να παράγει νέα δεδομένα, πρέπει να γνωρίζουμε αυτό νωρίς γιατί ίσως τα μοντέλα μας, άλλες υπηρεσίες ή επιχειρήσεις, εξαρτώνται από αυτά τα δεδομένα σε υψηλό ποσοστό. Επιπλέον, χάρη σε έναν καλό αγωγό δεδομένων μπορούμε να επιτύχουμε μια αυτοματοποιημένη ανίχνευση ανωμαλιών, για παράδειγμα, όταν υπάρχουν λιγότερα γεγονότα σε μια χρονική περίοδο.
  • Ποιότητα δεδομένων. Δοκιμές, δοκιμές και περισσότερες δοκιμές. Εμείς δοκιμές. Και εκτός από τις δοκιμές στον κώδικα, χρειαζόμαστε κάποιες δοκιμές με δεδομένα. Για παράδειγμα, τι πιστεύετε για μια δοκιμή σε αυτόν τον αγωγό που μας συμβουλεύει αν θέτουμε περισσότερες παραγγελίες από τα προϊόντα; Φαίνεται λογικό και χρήσιμο, έτσι;
  • Πάρτε την κατάρτιση δεδομένων. Εάν εργάζεστε επίσης με μηχανική μάθηση και επειδή θέλουμε να κάνουμε τη ζωή των επιστημόνων μας δεδομένων, πρέπει να λάβετε τα δεδομένα εκπαίδευσης. Εδώ υπάρχουν πολλά κρίσιμα σημεία: δειγματοληψία σημαντικού βάρους, περικοπή των δεδομένων σε μικρότερες φέτες, ανώνυμα όλων των ευαίσθητων δεδομένων ... περισσότερες πληροφορίες εδώ.
  • Φροντίζουμε τους πελάτες μας, οπότε πρέπει να φροντίσουμε τα δεδομένα τους, οπότε χρειαζόμαστε πολλή ασφάλεια σε αυτό το τμήμα δεδομένων. Είναι σημαντικό να ανώνυμα όλα τα ευαίσθητα δεδομένα αν θέλουμε να συνεργαστούμε μαζί τους.

Ναι Juan πολύ όμορφο, αλλά ...

Εξαιρετικό προγραμματισμό στη διάσωση

Πρώτα απ 'όλα, θα συνεχίσουμε να ταιριάζουμε τα πάντα ως κώδικα, έτσι και τον αγωγό δεδομένων.

Με την προσέγγιση στραγγαλισμού και στην πρώτη επανάληψη, η λογική είναι η επαναχρησιμοποίηση μέρους της λογικής που έχουμε κάνει πριν και θα το κάνουμε με το TDD, όπως λέει το XP και η κοινή λογική μας.

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

Αν γνωρίζετε τη ροή αέρα, γνωρίζετε ότι υπάρχουν πολλοί χειριστές (python_operator, http_operator, bash_operator, mysql_operator και πολλά άλλα) ανάλογα με το είδος του κώδικα που θέλετε να τοποθετήσετε σε κάθε DAG. Αυτοί οι χειριστές έχουν κάποια προβλήματα. Το χειρότερο για μένα είναι ο περίπλοκος και άσχημος τρόπος για να τα ελέγξετε, επιπλέον, εάν χρησιμοποιείτε Python, θα έχετε ακούσει κάτι σχετικά με το χάος εξάρτησης. Με αυτούς τους χειριστές πρέπει να εγκαταστήσετε όλες τις εξαρτήσεις σε όλο το έργο, δεν χρειάζεται διαφορετική έκδοση αυτών και να χρησιμοποιήσετε την ίδια έκδοση του Python. Επιπλέον, είμαστε μια σύγχρονη εταιρεία και θέλουμε να έχουμε ένα πολυγλωσσικό σύστημα και να δοκιμάσουμε νέες γλώσσες!

Η λύση μου είναι να χρησιμοποιήσω, ενώ κάνουμε το μοτίβο στραγγαλισμού, τον χειριστή λιμένα, kubernetes_pod_operator. Εάν χρησιμοποιείτε το Google Composer, θα πρέπει να χρησιμοποιήσετε το Kubernetes και ποτέ τον GKEContainerOperator, καθώς αυτό μπορεί να οδηγήσει σε ανταγωνισμό πόρων. Με αυτούς τους χειριστές, ο κώδικας που θα εκτελεστεί σε κάθε DAG θα είναι σε ένα κοντέινερ (μπορεί να έχει κώδικα python, scala, java, Beam διεργασίες, Spark διεργασίες, ροές Kafka, σύνοψη, ό, τι μπορείτε να φανταστείτε ...) χρησιμοποιήστε το TDD στη γλώσσα που θέλετε και μπορείτε να επαναχρησιμοποιήσετε κάποιο από τον κώδικά σας. Οι δοκιμές μονάδας και οι δοκιμές ολοκλήρωσης γίνονται ... σχεδόν!

Πρέπει ακόμα να γράψουμε τον δικό μας κώδικα Airflow έτσι θα κάνουμε και το TDD για να το κάνουμε. Θα είναι το μέρος δοκιμής ορισμού, που περιλαμβάνεται στη δοκιμή μονάδας του τμήματος ροής αέρα. Πριν δείξω τον κώδικα θέλω να ευχαριστήσω τους Chandu Kavar και Sarang Shinde για τις αναρτήσεις σχετικά με τις στρατηγικές δοκιμών στη ροή του αέρα.

Έτσι, όπως κάνουμε TDD, πρώτα η μονάδα δοκιμάζει:

Αυτός είναι ο κώδικας παραγωγής του αγωγού που έχουμε δημιουργήσει με το TDD:

Αλλά η δοκιμή μονάδων δεν είναι αρκετή, στην Packlink Engineering γνωρίζουμε ότι οι δοκιμές είναι το πιο σημαντικό μέρος του κώδικα. Λοιπόν, ας πάμε με περισσότερες δοκιμές.

Τώρα είναι ώρα για δοκιμές ολοκλήρωσης στο τμήμα ροής αέρα (τα δοχεία έχουν τη δική τους μονάδα και τις δοκιμές ολοκλήρωσης). Με αυτήν την προσέγγιση, οι δοκιμές ενσωμάτωσης εδώ σχετίζονται με το Configure Airflow και το XComs που συνοπτικά είναι ο τρόπος της ροής του αέρα που πρέπει να μοιραζόμαστε πληροφορίες μεταξύ των εργασιών σε ένα DAG. Στο παράδειγμά μας, πρέπει να ελέγξουμε ότι οι πληροφορίες που είναι αποθηκευμένες στο packlink_hello_task είναι αυτές που λαμβάνονται από το stream_data_task:

Το τελευταίο μέρος των δοκιμών πυραμίδας είναι δοκιμές e2e. Στην πυραμίδα, οι δοκιμές e2e είναι πάντοτε στη μικρότερη πλευρά επειδή είναι πολύ ακριβές. Στην Airflow ίσως ακόμα περισσότερο. Μπορείτε να δείτε ένα καλό παράδειγμα εδώ: https://github.com/chandulal/airflow-testing. Δεν θα μπορούσα να το κάνω καλύτερα.

Συμπεράσματα

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

  • Ο κώδικας είναι κώδικας. Χρησιμοποιήστε πρακτικές XP.
  • Οι μονόλιθοι δεδομένων ως μονολιθικοί κώδικες έχουν παρόμοια προβλήματα.
  • Μοιραστείτε αμετάβλητα σύνολα δεδομένων ως προϊόντα.
  • Γνωρίστε την ημερομηνία σας, θέστε την αγάπη στη διακυβέρνηση δεδομένων. Όλοι στην εταιρεία πρέπει να είναι σε θέση να κατανοήσουν τα δεδομένα.
  • Σκότωμα συμβαίνει. Προσέξτε την προσοχή.
  • Κανείς δεν γνωρίζει καλύτερα από τους τομείς σχετικά με τα δεδομένα τους. Εφαρμόστε μια όραση DDD στα δεδομένα.
  • Οι κανόνες Packlink !.

Πόροι και σύνδεσμοι