Wie Googles BigQuery die Datenanalyse demokratisierte. Teil 2

Hey Habr! Die Anmeldung für einen neuen Kurszweig ist ab sofort bei OTUS möglich Dateningenieur. Im Vorfeld des Kursbeginns teilen wir weiterhin nützliches Material mit Ihnen.

Lesen Sie den ersten Teil

Wie Googles BigQuery die Datenanalyse demokratisierte. Teil 2

Datenmanagement

Starke Datenverwaltung ist das Kernprinzip von Twitter Engineering. Bei der Einbettung von BigQuery in unsere Plattform konzentrieren wir uns auf Datenerkennung, Zugriffskontrolle, Sicherheit und Datenschutz.

Um Daten zu entdecken und zu verwalten, haben wir unseren Data Access Layer erweitert – VON), um Tools sowohl für lokale als auch für Google Cloud-Daten bereitzustellen und unseren Benutzern eine einzige Schnittstelle und API bereitzustellen. Als Google Datenkatalog Da sich das System in Richtung allgemeiner Verfügbarkeit bewegt, werden wir es in unsere Projekte einbinden, um Benutzern Funktionen wie die Spaltensuche bereitzustellen.

Mit BigQuery ist es einfach, Daten zu teilen und darauf zuzugreifen, aber wir brauchten ein gewisses Maß an Kontrolle darüber, um die Datenexfiltration zu verhindern. Unter anderem haben wir uns für zwei Funktionen entschieden:

  • Domänenbeschränkte Freigabe: Eine Beta-Funktion, die verhindert, dass Benutzer BigQuery-Datensätze mit Benutzern außerhalb von Twitter teilen.
  • VPC-Dienstkontrollen: Ein Steuerelement, das die Datenexfiltration verhindert und erfordert, dass Benutzer über bekannte IP-Adressbereiche auf BigQuery zugreifen.

Wir haben die Sicherheitsanforderungen für Authentifizierung, Autorisierung und Prüfung (AAA) wie folgt umgesetzt:

  • Authentifizierung: Wir haben GCP-Benutzerkonten für Ad-hoc-Anfragen und Dienstkonten für Arbeitsanfragen verwendet.
  • Autorisierung: Wir verlangten, dass jeder Datensatz über ein Eigentümerdienstkonto und eine Lesergruppe verfügt.
  • Prüfung: Wir haben die BigQuery-Stackdriver-Protokolle, die detaillierte Informationen zur Abfrageausführung enthielten, zur einfachen Analyse in einen BigQuery-Datensatz exportiert.

Um sicherzustellen, dass die personenbezogenen Daten der Twitter-Nutzer ordnungsgemäß gehandhabt werden, müssen wir alle BigQuery-Datensätze registrieren, personenbezogene Daten mit Anmerkungen versehen, eine ordnungsgemäße Speicherung gewährleisten und von Nutzern gelöschte Daten löschen (bereinigen).

Wir haben bei Google nachgeschaut Cloud Data Loss Prevention-API, das maschinelles Lernen zum Klassifizieren und Bearbeiten vertraulicher Daten nutzt, sich jedoch aufgrund der Genauigkeit dafür entschieden hat, den Datensatz manuell zu kommentieren. Wir planen, die Data Loss Prevention API als Ergänzung zur benutzerdefinierten Anmerkung zu verwenden.

Bei Twitter haben wir vier Datenschutzkategorien für Datensätze in BigQuery erstellt, die hier in absteigender Reihenfolge der Vertraulichkeit aufgeführt sind:

  • Hochsensible Datensätze stehen nach dem Prinzip der geringsten Rechte bei Bedarf zur Verfügung. Jeder Datensatz verfügt über eine separate Gruppe von Lesern und wir verfolgen die Nutzung einzelner Konten.
  • Datensätze mittlerer Sensibilität (einseitige Aliase mit gesalzenem Hashing) enthalten keine personenbezogenen Daten (PII) und stehen einer größeren Gruppe von Mitarbeitern zur Verfügung. Es ist eine gute Balance zwischen Datenschutz- und Nützlichkeitserwägungen. Auf diese Weise können Mitarbeiter Analyseaufgaben durchführen, beispielsweise die Anzahl der Benutzer berechnen, die eine Funktion verwendet haben, ohne zu wissen, wer die tatsächlichen Benutzer sind.
  • Datensätze mit geringer Sensibilität und allen benutzeridentifizierenden Informationen. Aus Sicht des Datenschutzes ist dies ein guter Ansatz, kann jedoch nicht für eine Analyse auf Benutzerebene verwendet werden.
  • Öffentliche Datensätze (außerhalb von Twitter veröffentlicht) stehen allen Twitter-Mitarbeitern zur Verfügung.

Für die Registrierung haben wir geplante Aufgaben verwendet, um die BigQuery-Datensätze aufzuzählen und sie in der Datenzugriffsschicht zu registrieren (VON), das Twitter-Metadaten-Repository. Benutzer kommentieren Datensätze mit Datenschutzinformationen und geben einen Aufbewahrungszeitraum an. Was die Reinigung betrifft, bewerten wir die Leistung und Kosten von zwei Optionen: 1. Datensätze in GCS mit Tools wie Scalding extrahieren und in BigQuery laden 2. Verwenden von BigQuery-DML-Anweisungen. Wir werden wahrscheinlich eine Kombination beider Methoden verwenden, um den Anforderungen verschiedener Gruppen und Daten gerecht zu werden.

Systemfunktionalität

Da es sich bei BigQuery um einen verwalteten Dienst handelt, war es nicht erforderlich, das Twitter-SRE-Team in die Systemverwaltungs- oder Verwaltungsaufgaben einzubeziehen. Es war einfach, mehr Speicher- und Rechenkapazität bereitzustellen. Wir könnten Slotreservierungen ändern, indem wir Tickets beim Google-Support einreichen. Wir haben Bereiche identifiziert, die verbessert werden könnten, wie z. B. Self-Service für die Slot-Zuweisung und Verbesserungen am Überwachungs-Dashboard, und diese Anfragen an Google weitergeleitet.

Kosten

Unsere vorläufige Analyse ergab, dass die Kosten für Abfragen für BigQuery und Presto auf dem gleichen Niveau lagen. Wir haben Slots gekauft Fest Preis, um stabile monatliche Kosten zu haben, anstatt zu zahlen von Trebuwan pro TB verarbeiteter Daten. Diese Entscheidung basierte auch auf dem Feedback von Benutzern, die nicht vor jeder Anfrage über die Kosten nachdenken wollten.

Das Speichern von Daten in BigQuery verursachte zusätzlich zu den Kosten von GCS Kosten. Tools wie Scalding erfordern Datensätze in GCS, und um auf BigQuery zugreifen zu können, mussten wir dieselben Datensätze in das BigQuery-Format laden Kondensator. Wir arbeiten an einer Scalding-Verbindung zu BigQuery-Datensätzen, die das Speichern von Datensätzen sowohl in GCS als auch in BigQuery überflüssig macht.

Für seltene Fälle, in denen unregelmäßige Abfragen von mehreren zehn Petabyte erforderlich waren, entschieden wir, dass das Speichern von Datensätzen in BigQuery nicht kosteneffektiv war, und verwendeten Presto für den direkten Zugriff auf Datensätze in GCS. Dazu schauen wir uns die externen Datenquellen von BigQuery an.

Nächste Schritte

Wir haben seit der Veröffentlichung der Alpha ein großes Interesse an BigQuery festgestellt. Wir fügen BigQuery weitere Datensätze und Befehle hinzu. Wir entwickeln Konnektoren für Datenanalysetools wie Scalding zum Lesen und Schreiben in BigQuery-Speicher. Wir prüfen Tools wie Looker und Apache Zeppelin zum Erstellen von Berichten und Notizen in Unternehmensqualität mithilfe von BigQuery-Datensätzen.

Die Zusammenarbeit mit Google war sehr produktiv und wir freuen uns, diese Partnerschaft fortzusetzen und auszubauen. Wir haben mit Google zusammengearbeitet, um unser eigenes zu implementieren Partner Issue Trackerum Anfragen direkt an Google zu senden. Einige davon, wie zum Beispiel der BigQuery Parquet Loader, sind bereits von Google implementiert.

Hier sind einige unserer Funktionsanfragen mit hoher Priorität für Google:

  • Tools zur einfachen Datenerfassung und Unterstützung des LZO-Thrift-Formats.
  • Stündliche Segmentierung
  • Verbesserungen der Zugriffskontrolle, z. B. Berechtigungen auf Tabellen-, Zeilen- und Spaltenebene.
  • BigQuery Externe Datenquellen mit Hive Metastore-Integration und Unterstützung für das LZO-Thrift-Format.
  • Verbesserte Datenkatalogintegration in die BigQuery-Benutzeroberfläche
  • Self-Service zur Zuteilung und Überwachung von Slots.

Abschluss

Die sichere Demokratisierung von Datenanalyse, Visualisierung und maschinellem Lernen hat für das Data Platform-Team höchste Priorität. Wir haben Google BigQuery und Data Studio als Tools identifiziert, die dabei helfen können, dieses Ziel zu erreichen, und haben letztes Jahr BigQuery Alpha für das gesamte Unternehmen veröffentlicht.

Wir haben festgestellt, dass Abfragen in BigQuery einfach und effizient waren. Für einfache Pipelines haben wir die Tools von Google zum Erfassen und Transformieren von Daten verwendet, für komplexe Pipelines mussten wir jedoch unsere eigene Airflow-Infrastruktur erstellen. Im Bereich Datenmanagement erfüllen BigQuery-Dienste zur Authentifizierung, Autorisierung und Prüfung unsere Anforderungen. Um Metadaten zu verwalten und den Datenschutz zu wahren, brauchten wir viel Flexibilität und mussten unsere eigenen Systeme aufbauen. BigQuery war als verwalteter Dienst einfach zu bedienen. Die Anfragekosten waren ähnlich wie bei bestehenden Tools. Für das Speichern von Daten in BigQuery fallen zusätzlich zu denen von GCS Kosten an.

Im Allgemeinen eignet sich BigQuery gut für allgemeine SQL-Analysen. Wir sehen großes Interesse an BigQuery und arbeiten daran, mehr Datensätze zu migrieren, mehr Teams einzubinden und mehr Pipelines mit BigQuery aufzubauen. Twitter verwendet eine Vielzahl von Daten, die eine Kombination von Tools wie Scalding, Spark, Presto und Druid erfordern. Wir beabsichtigen, unsere Datenanalysetools weiter auszubauen und unseren Nutzern klare Anleitungen zur optimalen Nutzung unserer Angebote zu geben.

Worte der Dankbarkeit

Ich möchte meinen Mitarbeitern und Teamkollegen Anju Jha und Will Pascucci für ihre großartige Zusammenarbeit und harte Arbeit an diesem Projekt danken. Ich möchte auch den Ingenieuren und Managern mehrerer Teams bei Twitter und Google danken, die uns geholfen haben, sowie den BigQuery-Benutzern auf Twitter, die wertvolles Feedback gegeben haben.

Wenn Sie daran interessiert sind, an diesen Aufgaben mitzuarbeiten, schauen Sie sich bitte unsere an Stellenangebote im Data Platform-Team.

Datenqualität im DWH – Data Warehouse-Konsistenz

Source: habr.com

Kommentar hinzufügen