Wie Google BigQuery die Datenanalyse demokratisiert hat. Teil 2

Hallo, Habr! Der neue Kurs bei OTUS ist jetzt geöffnet. „Data Engineer“. Im Vorfeld des Kursstarts teilen wir weiterhin nützliche Materialien mit Ihnen.

Erste Teil lesen

Datenmanagement

Starke Datenverwaltung (Strong Data Governance) ist ein grundlegendes Prinzip von Twitter Engineering. Da wir BigQuery in unsere Plattform integrieren, konzentrieren wir uns auf die Datenerkennung, Zugriffssteuerung, Sicherheit und Datenschutz.

Um Daten zu erkennen und zu verwalten, haben wir unsere Datenzugriffsebene (Data Access Layer — DAL), um Werkzeuge sowohl für lokale Daten als auch für Google Cloud-Daten bereitzustellen und unseren Nutzern eine einheitliche Schnittstelle und API zu bieten. Während Google Data Catalog einen Weg zur Allgemeingültigkeit einschlägt, werden wir ihn in unsere Projekte integrieren, um den Nutzern Funktionen wie die Suche nach Spalten anzubieten.

BigQuery ermöglicht einen einfachen Datenaustausch und -zugriff, aber wir mussten dies bis zu einem gewissen Grad kontrollieren, um Datenexfiltration zu verhindern. Unter den anderen Werkzeugen haben wir uns für zwei Funktionen entschieden:

• Domain Restricted Sharing: eine Beta-Funktion, die es Nutzern untersagt, BigQuery-Datensätze mit Nutzern außerhalb von Twitter zu teilen.
• VPC Service Controls: eine Steuerung, die die Datenexfiltration verhindert und von Benutzern verlangt, auf BigQuery von bekannten IP-Adressbereichen zuzugreifen.

Wir haben die Anforderungen an Authentifizierung, Autorisierung und Auditing (AAA) wie folgt umgesetzt:

• Authentifizierung: Wir haben GCP-Benutzerkonten für Ad-hoc-Anfragen und Dienstkonten für Arbeitsanfragen verwendet.
• Autorisierung: Wir haben gefordert, dass jedes Datenset ein Dienstkonto als Eigentümer und eine Lesergruppe hat.
• Audit: Wir haben die Protokolle von BigQuery Stackdriver exportiert, die detaillierte Informationen über die Ausführung von Abfragen enthielten, in ein BigQuery-Dataset zum einfacheren Analysieren.

Um eine ordnungsgemäße Verarbeitung persönlicher Daten von Twitter-Nutzern sicherzustellen, müssen wir alle BigQuery-Datensätze anmelden, persönliche Daten annotieren, eine ordentliche Aufbewahrung sicherstellen und Daten löschen (bereinigen), die von Nutzern entfernt wurden.

Wir haben Google Cloud Data Loss Prevention API, der maschinelles Lernen zur Klassifizierung und Bearbeitung sensibler Daten verwendet, aber sich aufgrund der Genauigkeit für die manuelle Annotation des Datensatzes entschieden hat. Wir planen, die Data Loss Prevention API zu nutzen, um die benutzerdefinierte Annotation zu ergänzen.

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

• Hochsensibler Datensatz ist je nach Bedarf gemäß dem Prinzip der minimalen Privilegien verfügbar. Jeder Datensatz hat eine separate Gruppe von Lesern, und wir werden die Nutzung einzelner Konten überwachen.
• Datensätze mit mittlerer Sensitivität (einseitige Pseudonyme unter Verwendung von gesalzenem Hashing) enthalten keine persönlichen Informationen (Personally Identifiable Information – PII) und sind für eine größere Gruppe von Mitarbeitern zugänglich. Dies bietet einen guten Ausgleich zwischen Datenschutzüberlegungen und der Nützlichkeit der Daten. Dadurch können Mitarbeiter Analyseaufgaben durchführen, wie z.B. die Berechnung der Anzahl der Benutzer, die eine Funktion verwendet haben, ohne zu wissen, wer die tatsächlichen Benutzer sind.
• Datensätze mit niedriger Sensitivität enthalten alle Informationen, die den Benutzer identifizieren. Dies ist aus Datenschutzsicht ein guter Ansatz, kann jedoch nicht für die Analyse auf Benutzerebene verwendet werden.
• Öffentlich zugängliche Datensätze (außerhalb von Twitter veröffentlicht) sind für alle Twitter-Mitarbeiter zugänglich.

Was die Registrierung betrifft, so haben wir geplante Aufgaben verwendet, um die BigQuery-Datensätze aufzulisten und sie im Data Access Layer zu registrieren (DAL), Twitter-Metadaten-Repository. Nutzer werden Datensätze mit Informationen zur Vertraulichkeit annotieren und die Speicherfristen angeben. Bei der Bereinigung bewerten wir die Leistung und die Kosten von zwei Optionen: 1. Bereinigung von Datensätzen in GCS mit Tools wie Scalding und deren Upload nach BigQuery; 2. Verwendung von BigQuery DML-Operatoren. Wahrscheinlich werden wir eine Kombination beider Methoden nutzen, um die Anforderungen verschiedener Gruppen und Daten zu erfüllen.

Systemfunktionalität

Da BigQuery ein verwalteter Dienst ist, war es nicht nötig, das SRE-Team von Twitter in das Management der Systeme oder in Bereitschaftsdienste einzubeziehen. Es war einfach, große Kapazitäten sowohl für Speicherung als auch für Rechenleistung bereitzustellen. Wir konnten das Slot-Booking ändern, indem wir Tickets beim Google-Support erstellt haben. Wir haben festgestellt, dass wir beispielsweise das Self-Service für die Slot-Verteilung und die Verbesserung des Dashboards zur Überwachung optimieren könnten, und haben diese Anfragen an Google weitergeleitet.

Kosten

Unsere Vorabanalyse hat gezeigt, dass die Kosten für Anfragen bei BigQuery und Presto auf ähnlichem Niveau lagen. Wir haben Slots zu festen Preisen erworben. Preis, um eine stabile monatliche Kostenstruktur zu haben, anstatt zu zahlen auf Anfrage pro TB verarbeiteten Daten. Diese Lösung basierte auch auf dem Feedback von Nutzern, die nicht über Kosten nachdenken wollten, bevor sie jede Anfrage ausführten.

Die Speicherung von Daten in BigQuery führte zu zusätzlichen Kosten neben den GCS-Ausgaben. Werkzeuge wie Scalding erfordern Datensätze in GCS, und um auf BigQuery zuzugreifen, mussten wir die gleichen Datensätze im BigQuery-Format hochladen Capacitor. Wir arbeiten an der Verbindung von Scalding mit BigQuery-Datensätzen, um die Notwendigkeit zu beseitigen, Datensätze sowohl in GCS als auch in BigQuery zu speichern.

In seltenen Fällen, die nicht häufige Anfragen von mehreren Petabytes erforderten, entschieden wir, dass die Speicherung von Datensätzen in BigQuery nicht wirtschaftlich ist, und verwendeten Presto für den direkten Zugriff auf Datensätze in GCS. Dafür prüfen wir BigQuery External Data Sources.

Die nächsten Schritte

Seit der Veröffentlichung der Alpha-Version haben wir ein reges Interesse an BigQuery festgestellt. Wir fügen weitere Datensätze und mehr Teams zu BigQuery hinzu. Wir entwickeln Connectoren für Datenanalyse-Tools wie Scalding, um in das BigQuery-Speicher zu lesen und zu schreiben. Wir prüfen Tools wie Looker und Apache Zeppelin zur Erstellung von Unternehmensberichten zur Qualität und Notizen mit Hilfe von BigQuery-Datensätzen.

Die Zusammenarbeit mit Google war äußerst produktiv, und wir freuen uns, diese Partnerschaft fortzusetzen und auszubauen. Wir haben mit Google zusammengearbeitet, um unsere eigene Partner Issue Tracker, um Anfragen direkt an Google zu senden. Einige davon, wie der BigQuery Parquet Loader, wurden bereits von Google realisiert.

Hier sind einige unserer hochpriorisierten Funktionsanfragen an Google:

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

Fazit

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

Wir haben festgestellt, dass Abfragen 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 erstellen. Im Bereich des Datenmanagements erfüllen die Dienste von BigQuery unsere Anforderungen an Authentifizierung, Autorisierung und Auditierung. 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 Service, war einfach zu bedienen. Die Abfragekosten waren vergleichbar mit bestehenden Werkzeugen. Die Speicherung von Daten in BigQuery erhöhte die Kosten zusätzlich zu den Ausgaben für GCS.

Insgesamt funktioniert BigQuery gut für allgemeine SQL-Analysen. Wir verzeichnen ein starkes Interesse an BigQuery und arbeiten daran, mehr Datensätze zu übertragen, mehr Teams zu gewinnen und mehr Pipelines mit BigQuery zu erstellen. Twitter verwendet unterschiedliche Daten, für die eine Kombination von Tools wie Scalding, Spark, Presto und Druid erforderlich ist. Wir sind entschlossen, unsere Datenanalysetools weiter auszubauen und unseren Benutzern klare Empfehlungen zu geben, wie sie unser Angebot optimal nutzen können.

Dankesworte

Ich möchte meinen Mitautoren und Teamkollegen, Anju Dja und Will Pascucci, für ihre großartige Zusammenarbeit und harte Arbeit an diesem Projekt danken. Außerdem möchte ich den Ingenieuren und Managern mehrerer 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, schauen Sie sich unsere Stellenangebote im Data Platform-Team an.

Die Datenqualität im DWH – Konsistenz des Data Warehouses

Quelle: habr.com