Πώς το BigQuery της Google εκδημοκρατοποίησε την ανάλυση δεδομένων. Μέρος 2ο

Γεια σου, Χαμπρ! Οι εγγραφές για μια νέα ροή μαθημάτων είναι ανοιχτές αυτή τη στιγμή στο OTUS Μηχανικός Δεδομένων. Εν όψει της έναρξης του μαθήματος, συνεχίζουμε να μοιραζόμαστε χρήσιμο υλικό μαζί σας.

Διαβάστε το πρώτο μέρος

Πώς το BigQuery της Google εκδημοκρατοποίησε την ανάλυση δεδομένων. Μέρος 2ο

Διαχείριση δεδομένων

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

Για να ανακαλύψουμε και να διαχειριστούμε δεδομένα, έχουμε επεκτείνει το επίπεδο πρόσβασης δεδομένων στο DAL) για την παροχή εργαλείων τόσο για δεδομένα εσωτερικής εγκατάστασης όσο και για δεδομένα Google Cloud, παρέχοντας μια ενιαία διεπαφή και API για τους χρήστες μας. Ως Google Κατάλογος δεδομένων κινείται προς τη γενική διαθεσιμότητα, θα το συμπεριλάβουμε στα έργα μας για να παρέχουμε στους χρήστες λειτουργίες όπως η αναζήτηση στηλών.

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

Έχουμε εφαρμόσει απαιτήσεις ελέγχου ταυτότητας, εξουσιοδότησης και ελέγχου (AAA) για την ασφάλεια ως εξής:

  • Έλεγχος ταυτότητας: Χρησιμοποιήσαμε λογαριασμούς χρηστών GCP για ad hoc αιτήματα και λογαριασμούς υπηρεσίας για αιτήματα παραγωγής.
  • Εξουσιοδότηση: Απαιτούσαμε κάθε σύνολο δεδομένων να έχει έναν λογαριασμό υπηρεσίας κατόχου και μια ομάδα αναγνωστών.
  • Έλεγχος: Εξάγαμε αρχεία καταγραφής Stackdriver BigQuery, τα οποία περιείχαν λεπτομερείς πληροφορίες εκτέλεσης ερωτημάτων, σε ένα σύνολο δεδομένων BigQuery για εύκολη ανάλυση.

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

Κοιτάξαμε το Google Cloud Data Loss Prevention API, το οποίο χρησιμοποιεί μηχανική εκμάθηση για την ταξινόμηση και την επεξεργασία ευαίσθητων δεδομένων, αλλά αποφάσισε να σχολιάσει με μη αυτόματο τρόπο το σύνολο δεδομένων λόγω ακρίβειας. Σκοπεύουμε να χρησιμοποιήσουμε το Data Loss Prevention API για να ενισχύσουμε τον προσαρμοσμένο σχολιασμό.

Στο Twitter, δημιουργήσαμε τέσσερις κατηγορίες απορρήτου για σύνολα δεδομένων στο BigQuery, που παρατίθενται εδώ με φθίνουσα σειρά ευαισθησίας:

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

Όσον αφορά την καταγραφή, χρησιμοποιήσαμε προγραμματισμένες εργασίες για να απαριθμήσουμε σύνολα δεδομένων BigQuery και να τα καταχωρήσουμε στο επίπεδο πρόσβασης δεδομένων (DAL), αποθετήριο μεταδεδομένων Twitter. Οι χρήστες θα σχολιάσουν σύνολα δεδομένων με πληροφορίες απορρήτου και θα καθορίσουν επίσης μια περίοδο διατήρησης. Όσον αφορά τον καθαρισμό, αξιολογούμε την απόδοση και το κόστος δύο επιλογών: 1. Καθαρισμός συνόλων δεδομένων στο GCS χρησιμοποιώντας εργαλεία όπως το Scalding και φόρτωσή τους στο BigQuery. 2. Χρήση δηλώσεων DML BigQuery. Πιθανότατα θα χρησιμοποιήσουμε έναν συνδυασμό και των δύο μεθόδων για να ικανοποιήσουμε τις απαιτήσεις διαφορετικών ομάδων και δεδομένων.

Λειτουργικότητα συστήματος

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

Κόστος

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

Η αποθήκευση δεδομένων στο BigQuery έφερε κόστος επιπλέον του κόστους GCS. Εργαλεία όπως το Scalding απαιτούν σύνολα δεδομένων στο GCS και για να αποκτήσουμε πρόσβαση στο BigQuery έπρεπε να φορτώσουμε τα ίδια σύνολα δεδομένων σε μορφή BigQuery Πυκνωτής. Εργαζόμαστε σε μια σύνδεση Scalding με σύνολα δεδομένων BigQuery που θα εξαλείψει την ανάγκη αποθήκευσης συνόλων δεδομένων τόσο στο GCS όσο και στο BigQuery.

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

Επόμενα βήματα

Έχουμε δει μεγάλο ενδιαφέρον για το BigQuery από την κυκλοφορία του alpha. Προσθέτουμε περισσότερα σύνολα δεδομένων και περισσότερες εντολές στο BigQuery. Αναπτύσσουμε συνδέσμους για εργαλεία ανάλυσης δεδομένων όπως το Scalding για ανάγνωση και εγγραφή στο χώρο αποθήκευσης BigQuery. Εξετάζουμε εργαλεία όπως το Looker και το Apache Zeppelin για τη δημιουργία αναφορών και σημειώσεων εταιρικής ποιότητας χρησιμοποιώντας σύνολα δεδομένων BigQuery.

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

Ακολουθούν ορισμένα από τα αιτήματα υψηλής προτεραιότητας δυνατοτήτων μας για την Google:

  • Εργαλεία για εύκολη λήψη δεδομένων και υποστήριξη για τη μορφή LZO-Thrift.
  • Ωριαία τμηματοποίηση
  • Βελτιώσεις ελέγχου πρόσβασης, όπως δικαιώματα σε επίπεδο πίνακα, γραμμής και στήλης.
  • BigQuery Εξωτερικές πηγές δεδομένων με ενσωμάτωση Hive Metastore και υποστήριξη για τη μορφή LZO-Thrift.
  • Βελτιωμένη ενσωμάτωση καταλόγου δεδομένων στη διεπαφή χρήστη BigQuery
  • Self-service για κατανομή και παρακολούθηση θυρίδων.

Συμπέρασμα

Ο εκδημοκρατισμός της ανάλυσης δεδομένων, της οπτικοποίησης και της μηχανικής μάθησης με ασφαλή τρόπο αποτελεί κορυφαία προτεραιότητα για την ομάδα της πλατφόρμας δεδομένων. Προσδιορίσαμε το Google BigQuery και το Data Studio ως εργαλεία που θα μπορούσαν να βοηθήσουν στην επίτευξη αυτού του στόχου και κυκλοφόρησε το BigQuery Alpha σε όλη την εταιρεία πέρυσι.

Βρήκαμε ότι τα ερωτήματα στο BigQuery είναι απλά και αποτελεσματικά. Χρησιμοποιήσαμε εργαλεία της Google για την απορρόφηση και τη μετατροπή δεδομένων για απλούς αγωγούς, αλλά για πολύπλοκους αγωγούς έπρεπε να δημιουργήσουμε το δικό μας πλαίσιο ροής αέρα. Στον χώρο διαχείρισης δεδομένων, οι υπηρεσίες του BigQuery για έλεγχο ταυτότητας, εξουσιοδότηση και έλεγχο ανταποκρίνονται στις ανάγκες μας. Για να διαχειριστούμε τα μεταδεδομένα και να διατηρήσουμε το απόρρητο, χρειαζόμασταν μεγαλύτερη ευελιξία και έπρεπε να δημιουργήσουμε τα δικά μας συστήματα. Το BigQuery, ως διαχειριζόμενη υπηρεσία, ήταν εύκολο στη χρήση. Το κόστος αναζήτησης ήταν παρόμοιο με τα υπάρχοντα εργαλεία. Η αποθήκευση δεδομένων στο BigQuery συνεπάγεται κόστος επιπλέον του κόστους GCS.

Συνολικά, το BigQuery λειτουργεί καλά για γενική ανάλυση SQL. Βλέπουμε μεγάλο ενδιαφέρον για το BigQuery και εργαζόμαστε για τη μετεγκατάσταση περισσότερων συνόλων δεδομένων, τη δημιουργία περισσότερων ομάδων και τη δημιουργία περισσότερων γραμμών με το BigQuery. Το Twitter χρησιμοποιεί μια ποικιλία δεδομένων που απαιτούν συνδυασμό εργαλείων όπως το Scalding, το Spark, το Presto και το Druid. Σκοπεύουμε να συνεχίσουμε να ενισχύουμε τα εργαλεία ανάλυσης δεδομένων μας και να παρέχουμε σαφείς οδηγίες στους χρήστες μας σχετικά με τον καλύτερο τρόπο χρήσης των προσφορών μας.

Λόγια ευγνωμοσύνης

Θα ήθελα να ευχαριστήσω τους συν-συγγραφείς και τους συμπαίκτες μου, Anju Jha και Will Pascucci, για τη σπουδαία συνεργασία και τη σκληρή δουλειά τους σε αυτό το έργο. Θα ήθελα επίσης να ευχαριστήσω τους μηχανικούς και τους διευθυντές από διάφορες ομάδες του Twitter και της Google που μας βοήθησαν και τους χρήστες του BigQuery στο Twitter που παρείχαν πολύτιμα σχόλια.

Εάν ενδιαφέρεστε να εργαστείτε για αυτά τα προβλήματα, ανατρέξτε στο δικό μας κενές θέσεις στην ομάδα Data Platform.

Ποιότητα δεδομένων στο DWH - Συνέπεια αποθήκης δεδομένων

Πηγή: www.habr.com

Προσθέστε ένα σχόλιο