Lesen Sie den ersten Teil
Datenmanagement
Starke Data Governance ist der Hauptgrundsatz von Twitter Engineering. Während wir BigQuery in unsere Plattform implementieren, konzentrieren wir uns auf Datenerkennung, Zugriffskontrolle, Sicherheit und Datenschutz.
Für die Datenerkennung und -verwaltung haben wir unsere Datenzugriffsschicht (Data Access Layer, DAL ) erweitert, um Tools sowohl für lokale Daten als auch für Google Cloud-Daten bereitzustellen und unseren Benutzern eine einzige Schnittstelle und API bereitzustellen. Wenn sich der Google- Datenkatalog der allgemeinen Verfügbarkeit nähert, werden wir ihn in unsere Projekte aufnehmen, um Nutzern Funktionen wie die Spaltensuche bereitzustellen.
BigQuery erleichtert das Teilen und Zugreifen auf Daten, aber wir brauchten eine gewisse Kontrolle, um eine Datenexfiltration zu verhindern. Unter anderem haben wir zwei Funktionen ausgewählt:
- Domain-eingeschränkte Freigabe : Eine Beta-Funktion, die verhindert, dass Benutzer BigQuery-Datasets für Benutzer außerhalb von Twitter freigeben.
- VPC-Dienststeuerelemente : Ein Steuerelement, das die Datenexfiltration verhindert und erfordert, dass Benutzer aus bekannten IP-Bereichen auf BigQuery zugreifen.
Wir haben die Sicherheitsanforderungen für Authentifizierung, Autorisierung und Prüfung (AAA) wie folgt implementiert:
- Authentifizierung: Wir haben GCP-Benutzerkonten für Ad-hoc-Anforderungen und Dienstkonten für Arbeitsanforderungen verwendet.
- Autorisierung: Für jeden Datensatz ist ein Eigentümerdienstkonto und eine Gruppe von Lesern erforderlich.
- : BigQuery, , BigQuery .
Um sicherzustellen, dass die persönlichen Daten von Twitter-Benutzern ordnungsgemäß behandelt werden, müssen wir alle BigQuery-Datensätze registrieren, persönliche Daten mit Anmerkungen versehen, eine ordnungsgemäße Speicherung gewährleisten und von Benutzern gelöschte Daten löschen (bereinigen).
Wir haben die Google Cloud-API zur Verhinderung von Datenverlust überprüft , die maschinelles Lernen zum Klassifizieren und Bearbeiten sensibler Daten verwendet. Aufgrund der Genauigkeit haben wir uns jedoch für die manuelle Annotation des Datensatzes entschieden. Wir planen, die Data Loss Prevention API als Ergänzung zur benutzerdefinierten Annotation zu verwenden.
Auf Twitter haben wir vier Datenschutzkategorien für BigQuery-Datasets erstellt, die hier in absteigender Reihenfolge der Empfindlichkeit aufgeführt sind:
- . , .
- ( ) (Personally Identifiable Information — PII) . . , , , , .
- , . , .
- ( Twitter) Twitter.
Vor der Registrierung haben wir geplante Aufgaben verwendet, um BigQuery-Datasets aufzulisten und sie im Data Access Layer ( DAL ), dem Metadatenspeicher von Twitter, zu registrieren . Benutzer werden Datensätze mit Vertraulichkeitsinformationen sowie Aufbewahrungsfristen versehen. Beim Scrubben schätzen wir die Leistung und die Kosten von zwei Optionen: 1. Scrubben von Datasets in GCS mit Tools wie Scalding und Laden in BigQuery; 2. Verwenden von BigQuery DML-Operatoren. Wir werden wahrscheinlich eine Kombination beider Methoden verwenden, um die Anforderungen verschiedener Gruppen und Daten zu erfüllen.
Systemfunktionalität
Da es sich bei BigQuery um einen verwalteten Dienst handelt, war es nicht erforderlich, das SRE-Team von Twitter in das Systemmanagement oder die Aufgaben im Dienst einzubeziehen. Es war einfach, mehr Kapazität für Speicher und Computer bereitzustellen. Wir könnten Slot-Reservierungen ändern, indem wir Tickets im Google-Support erstellen. Wir haben herausgefunden, was verbessert werden könnte, z. B. Self-Service für die Slot-Zuweisung und bessere Überwachung von Dashboards, und diese Anfragen an Google weitergeleitet.
Die 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 zu einem festen Preis gekauft, um stabile monatliche Kosten zu erzielen, anstatt bei Bedarf für TB verarbeiteter Daten zu zahlen . Diese Entscheidung basierte auch auf dem Feedback von Benutzern, die vor jeder Anfrage nicht über die Kosten nachdenken wollten.
Das Speichern von Daten in BigQuery brachte zusätzlich zu den GCS-Kosten Kosten mit sich. Tools wie Scalding erfordern Datasets in GCS. Um auf BigQuery zugreifen zu können, mussten dieselben Datasets in das BigQuery Capacitor- Format geladen werden... Wir arbeiten an einer Scalding-Verbindung mit BigQuery-Datasets, die das Speichern von Datasets in GCS und BigQuery überflüssig macht.
In seltenen Fällen, in denen nur selten mehrere zehn Petabyte angefordert wurden, haben wir entschieden, dass das Speichern von Datasets in BigQuery nicht kosteneffektiv ist, und Presto verwendet, um direkt auf Datasets in GCS zuzugreifen. Zu diesem Zweck betrachten wir externe BigQuery-Datenquellen.
Nächste Schritte
Wir haben seit der Alpha-Veröffentlichung 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 den BigQuery-Speicher. Wir suchen nach Tools wie Looker und Apache Zeppelin zum Generieren von Berichten und Notizen zur Unternehmensqualität mithilfe von BigQuery-Datasets.
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 zu implementieren und Anfragen direkt an Google zu senden. Einige davon, wie der BigQuery Parquet Downloader, sind bereits von Google implementiert.
Hier sind einige unserer Feature-Anfragen mit hoher Priorität für Google:
- Tools zur einfachen Datenerfassung und Unterstützung des LZO-Thrift-Formats.
- Stündliche Segmentierung
- Verbesserungen der Zugriffssteuerung wie Tabellen-, Zeilen- und Spaltenberechtigungen.
- Externe BigQuery- Datenquellen mit Hive Metastore-Integration und Unterstützung für das LZO-Thrift-Format.
- Verbesserte Datenkatalogintegration in der BigQuery-Benutzeroberfläche
- Self-Service für die Zuweisung und Überwachung von Steckplätzen.
Fazit
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, mit denen wir dieses Ziel erreichen können, und im vergangenen Jahr BigQuery Alpha für das gesamte Unternehmen veröffentlicht.
Wir haben festgestellt, dass BigQuery-Abfragen einfach und effektiv sind. Wir haben Google-Tools für einfache Pipelines zum Empfangen und Transformieren von Daten verwendet, aber für komplexe Pipelines mussten wir unsere eigene Airflow-Infrastruktur erstellen. In der Datenverwaltung erfüllen die BigQuery-Services für Authentifizierung, Autorisierung und Prüfung unsere Anforderungen. Wir brauchten viel Flexibilität, um Metadaten zu verwalten und die Vertraulichkeit zu wahren, und wir mussten unsere eigenen Systeme erstellen. BigQuery war ein verwalteter Dienst und einfach zu bedienen. Die Anforderungskosten waren ähnlich wie bei vorhandenen Tools. Das Speichern von Daten in BigQuery hat zusätzlich zu den Kosten für GCS Kosten verursacht.
Insgesamt eignet sich BigQuery gut für die allgemeine SQL-Analyse. Wir sehen großes Interesse an BigQuery und arbeiten daran, mit BigQuery mehr Datensätze zu migrieren, mehr Teams zusammenzubringen und mehr Pipelines zu erstellen. Twitter verwendet eine Vielzahl von Daten, für die eine Mischung aus Tools wie Scalding, Spark, Presto und Druid erforderlich ist. Wir beabsichtigen, weiterhin auf unseren Datenanalysetools aufzubauen und unseren Benutzern klare Anleitungen zur optimalen Nutzung unserer Angebote zu geben.
Dankesworte
Ich möchte meinen Mitarbeitern und Teamkollegen Anjou Jha und Will Pascucci für ihre großartige Zusammenarbeit und harte Arbeit an diesem Projekt danken. Ich möchte mich auch bei den Ingenieuren und Managern mehrerer Teams bei Twitter und Google bedanken, die uns geholfen haben, sowie bei den Twitter-Nutzern von BigQuery, die wertvolles Feedback gegeben haben.
Wenn Sie an diesen Aufgaben arbeiten möchten, informieren Sie sich über unsere Stellenangebote im Data Platform-Team.
DWH-Datenqualität - Data Warehouse-Konsistenz