Wie BigQuery von Google die Datenanalyse demokratisiert hat. Teil 2

Hallo, Habr! Momentan ist in OTUS die Anmeldung für einen neuen Kursstart geöffnet. „Data Engineer“. Im Vorfeld des Kursstarts teilen wir weiterhin nützliche Materialien mit Ihnen.

Ersten Teil lesen

Datenmanagement

Starkes Datenmanagement (Strong Data Governance) ist ein Grundprinzip der Twitter-Technik. Da wir BigQuery in unsere Plattform integrieren, konzentrieren wir uns auf die Datenerkennung, den Zugangskontroll, Sicherheit und Datenschutz.

Um Daten zu erkennen und zu verwalten, haben wir unsere Zugriffsebene (Data Access Layer – DAL) erweitert, um sowohl für lokale Daten als auch für Google Cloud-Daten Werkzeuge bereitzustellen, wodurch unseren Nutzern eine einheitliche Schnittstelle und API zur Verfügung steht. Während Google Data Catalog in Richtung Öffentlichkeit geht, werden wir es in unsere Projekte einbinden, um Funktionen wie die Spaltensuche bereitzustellen.

BigQuery ermöglicht es, Daten einfach zu teilen und darauf zuzugreifen, aber wir mussten dies bis zu einem gewissen Grad kontrollieren, um Datenexfiltration zu verhindern. Unter anderen Tools haben wir zwei Funktionen ausgewählt:

• Domain-restricted sharing: eine Beta-Funktion, die es Nutzern untersagt, BigQuery-Datasets mit Nutzern außerhalb von Twitter zu teilen.
• VPC Service Controls: ein Steuerungselement, das die Datenexfiltration verhindert und von Nutzern verlangt, auf BigQuery von bekannten IP-Adressbereichen aus zuzugreifen.

Wir haben die Anforderungen an Authentifizierung, Autorisierung und Audit (AAA) zur Gewährleistung der Sicherheit wie folgt implementiert:

• Authentifizierung: Wir haben GCP-Benutzerkonten für Ad-hoc-Abfragen und Dienstkonten für Arbeitsabfragen verwendet.
• Autorisierung: Wir haben gefordert, dass jedes Dataset ein Dienstkontokonto des Eigentümers und eine Lesergruppe hat.
• Audit: Wir haben die Stackdriver-Protokolle von BigQuery exportiert, die detaillierte Informationen über die Abfrageausführung enthalten, in ein BigQuery-Dataset zur einfachen Analyse.

Um den ordnungsgemäßen Umgang mit persönlichen Daten der Twitter-Nutzer zu gewährleisten, müssen wir alle BigQuery-Datasets registrieren, persönliche Daten kennzeichnen, eine angemessene Speicherung aufrechterhalten und Daten, die von Nutzern gelöscht wurden, entfernen (bereinigen).

Wir haben das Google Cloud Data Loss Prevention API betrachtet., das maschinelles Lernen zur Klassifizierung und Bearbeitung vertraulicher Daten nutzt, aber sich entschieden hat, aufgrund der Genauigkeit eine manuelle Annotation des Datensatzes vorzunehmen. Wir planen, die Data Loss Prevention API zu verwenden, um die Benutzerannotation zu ergänzen.

Bei Twitter haben wir vier Kategorien der Vertraulichkeit für Datensätze in BigQuery erstellt, die hier in absteigender Reihenfolge der Sensitivität aufgelistet sind:

• Hochsensible Datensätze sind nach Bedarf auf der Basis des Prinzips der minimalen Berechtigungen verfügbar. Jeder Datensatz hat eine separate Gruppe von Lesern, und wir werden die Nutzung einzelner Konten überwachen.
• Datensätze mittlerer Sensitivität (einseitige Pseudonyme mit gesalzenem Hashing) enthalten keine persönlichen Informationen (Personally Identifiable Information – PII) und sind einer größeren Gruppe von Mitarbeitern zugänglich. Dies stellt einen guten Ausgleich zwischen Datenschutz und Nützlichkeit der Daten dar. Es ermöglicht Mitarbeitern, Analyseaufgaben durchzuführen, wie z. B. die Berechnung der Anzahl der Nutzer, die eine Funktion verwendet haben, ohne zu wissen, wer die tatsächlichen Nutzer sind.
• Datensätze mit niedriger Sensitivität enthalten alle Informationen zur Identifizierung des Nutzers. Dies ist ein guter Ansatz aus datenschutzrechtlicher Sicht, kann jedoch nicht für Analysen auf Nutzerbasis verwendet werden.
• Öffentliche Datensätze (die außerhalb von Twitter veröffentlicht wurden) sind für alle Twitter-Mitarbeiter zugänglich.

Was die Registrierung betrifft, haben wir geplante Aufgaben verwendet, um die Datensätze in BigQuery aufzulisten und sie im Data Access Layer (DAL), dem Metadaten-Speicher von Twitter, zu registrieren. Nutzer werden die Datensätze mit Informationen zum Datenschutz annotieren und auch die Speicherfrist angeben. Was die Bereinigung betrifft, prüfen wir die Leistungsfähigkeit und Kosten von zwei Optionen: 1. Bereinigung von Datensätzen in GCS mit Tools wie Scalding und deren Hochladen in BigQuery; 2. Verwendung von DML-Operatoren in BigQuery. Wahrscheinlich werden wir eine Kombination beider Methoden verwenden, um den Anforderungen verschiedener Gruppen und Daten gerecht zu werden.

Funktionalität des Systems

Da BigQuery ein verwalteter Dienst ist, war es nicht notwendig, das SRE-Team von Twitter in das Systemmanagement oder die Ausführung von Bereitschaftsdiensten einzubeziehen. Es war einfach, sowohl für die Speicherung als auch für das Rechnen eine große Kapazität bereitzustellen. Wir konnten die Slotreservierungen ändern, indem wir Tickets im Google-Support erstellt haben. Wir haben festgestellt, dass wir Verbesserungen vornehmen könnten, wie zum Beispiel Self-Service zur Verteilung von Slots und eine Verbesserung des Dashboards zur Überwachung, und haben diese Anfragen an Google weitergeleitet.

Kosten

Unsere erste Analyse hat ergeben, dass die Kosten für Abfragen bei BigQuery und Presto auf einem ähnlichen Niveau lagen. Wir haben Slots zu festen Preisen erworben, um eine stabile monatliche Kostenstruktur zu haben, anstatt nach Nutzung pro TB verarbeiteten Daten zu bezahlen. Diese Entscheidung basierte auch auf dem Feedback der Nutzer, die nicht über die Kosten nachdenken wollten, bevor sie jede Abfrage ausführen.

Die Speicherung von Daten in BigQuery brachte zusätzliche Kosten neben den Ausgaben für GCS. Werkzeuge wie Scalding erfordern Datensätze in GCS, und um auf BigQuery zuzugreifen, mussten wir dieselben Datensätze im BigQuery-Format hochladen. Capacitor. Wir arbeiten daran, Scalding mit BigQuery-Datensätzen zu verbinden, was die Notwendigkeit beseitigen würde, Datensätze sowohl in GCS als auch in BigQuery zu speichern.

Für seltene Fälle, die nicht häufige Anfragen an Dutzende von Petabyte erforderten, haben wir entschieden, dass die Speicherung von Datensätzen in BigQuery wirtschaftlich nicht sinnvoll ist, und haben Presto für den direkten Zugriff auf die Datensätze in GCS verwendet. Dafür sehen wir uns BigQuery External Data Sources an.

Nächste Schritte

Wir haben seit der Alpha-Veröffentlichung ein großes Interesse an BigQuery festgestellt. Wir fügen mehr Datensätze und mehr Teams in BigQuery hinzu. Wir entwickeln Connectoren für Datenanalysetools wie Scalding, um in BigQuery zu lesen und zu schreiben. Wir betrachten Werkzeuge wie Looker und Apache Zeppelin, um Unternehmensberichte über Qualität und Notizen unter Verwendung von BigQuery-Datensätzen zu erstellen.

Die Zusammenarbeit mit Google war sehr produktiv, und wir freuen uns, diese Partnerschaft fortzusetzen und weiterzuentwickeln. Wir haben mit Google zusammengearbeitet, um unseren eigenen Partner Issue Tracker, einzuführen, um Anfragen direkt an Google zu senden. Einige davon, wie der BigQuery Parquet Uploader, wurden bereits von Google umgesetzt.

Hier sind einige unserer hochpriorisierten Anfragen für Funktionen von Google:

• Werkzeuge für den bequemen Datenaustausch und Unterstützung des LZO-Thrift-Formats.
• Stündliche Segmentierung
• Verbesserungen im Bereich des Zugriffsmanagements, wie Berechtigungen auf Tabellen-, Zeilen- und Spaltenebene.
• BigQuery Externe Datenquellen mit Integration und Unterstützung von Hive Metastore für das LZO-Thrift-Format.
• Verbesserte Integration des Datenkatalogs in die Benutzeroberfläche von BigQuery
• Self-Service zur Verteilung und Überwachung von Slots.

Fazit

Die Demokratisierung von Datenanalyse, Visualisierung und maschinellem Lernen auf sichere Weise hat für das Data Platform-Team höchste Priorität. Wir haben Google BigQuery und Data Studio als Werkzeuge identifiziert, die uns bei der Erreichung dieses Ziels unterstützen können, und haben im letzten Jahr BigQuery Alpha für das gesamte Unternehmen veröffentlicht.

Wir haben festgestellt, dass Anfragen in BigQuery einfach und effizient waren. Für den Empfang und die Transformation von Daten haben wir Google-Werkzeuge für einfache Pipelines verwendet, aber für komplexe Pipelines mussten wir unsere eigene Airflow-Infrastruktur aufbauen. Im Bereich Datenmanagement erfüllen die BigQuery-Dienste unsere Anforderungen an Authentifizierung, Autorisierung und Auditing. Für das Management von Metadaten und die Einhaltung der Datenschutzbestimmungen benötigten wir mehr Flexibilität und mussten eigene Systeme entwickeln. BigQuery als verwalteter Dienst war einfach zu bedienen. Die Abfragekosten waren vergleichbar mit bestehenden Werkzeugen. Die Datenspeicherung in BigQuery verursachte zusätzliche Kosten neben den Ausgaben für GCS.

Insgesamt funktioniert BigQuery gut für allgemeine SQL-Analysen. Wir verzeichnen großes Interesse an BigQuery, und wir arbeiten daran, mehr Datensätze zu migrieren, mehr Teams zu gewinnen und mehr Pipelines mit BigQuery zu erstellen. Bei Twitter werden verschiedene Daten verwendet, für die eine Kombination von Werkzeugen wie Scalding, Spark, Presto und Druid erforderlich ist. Wir beabsichtigen, unsere Datenanalysewerkzeuge weiter auszubauen und unseren Nutzern klare Empfehlungen zu geben, wie sie unsere Angebote optimal nutzen können.

Dankesworte

Ich möchte meinen Co-Autoren und Teamkollegen, Anzhu Dja und Will Pascucci, für ihre hervorragende Zusammenarbeit und harte Arbeit an diesem Projekt danken. Ich möchte auch den Ingenieuren und Managern aus mehreren Teams bei Twitter und Google danken, die uns und den Nutzern von BigQuery bei Twitter wertvolles Feedback gegeben haben.

Wenn Sie an der Arbeit an diesen Aufgaben interessiert sind, werfen Sie einen Blick auf unsere Stellenangebote im Data Platform-Team.

Die Datenqualität im DWH – Konsistenz des Datenschatzes

Quelle: habr.com