Jeden Tag besuchen über hundert Millionen Menschen Twitter, um herauszufinden und zu diskutieren, was in der Welt vor sich geht. Jeder Tweet und jede andere Benutzeraktion generiert ein Ereignis, das für die interne Datenanalyse auf Twitter verfügbar ist. Hunderte von Mitarbeitern analysieren und visualisieren diese Daten, und die Verbesserung ihrer Erfahrung hat für das Team der Twitter Data Platform höchste Priorität.
Wir glauben, dass Benutzer mit einem breiten Spektrum an technischen Fähigkeiten in der Lage sein sollten, Daten zu finden und Zugriff auf leistungsfähige SQL-basierte Analyse- und Visualisierungstools zu haben. Dies würde es einer völlig neuen Gruppe von Benutzern mit weniger technischen Vorurteilen, einschließlich Datenanalysten und Produktmanagern, ermöglichen, Informationen aus den Daten zu extrahieren, um die Leistungsfähigkeit von Twitter besser zu verstehen und zu nutzen. So demokratisieren wir die Twitter-Datenanalyse.
Da sich unsere Tools und Funktionen für die interne Datenanalyse verbessert haben, haben wir Verbesserungen beim Twitter-Dienst festgestellt. Es gibt jedoch noch Verbesserungspotenzial. Aktuelle Tools wie Scalding erfordern Programmiererfahrung. SQL-basierte Analysetools wie Presto und Vertica weisen große Leistungsprobleme auf. Wir haben auch das Problem, Daten auf mehrere Systeme zu verteilen, ohne ständig darauf zugreifen zu müssen.
Im vergangenen Jahr haben wir eine neue Partnerschaft mit Google angekündigt , die Teile unserer Dateninfrastruktur auf die Google Cloud Platform (GCP) verlagert. Wir sind zu dem Schluss gekommen, dass Google Cloud Big Data- Tools kann uns bei unseren Initiativen zur Demokratisierung von Analyse, Visualisierung und maschinellem Lernen auf Twitter helfen:
- BigQuery : Ein Enterprise Data Warehouse mit einer Dremel- basierten SQL-Engine , die für ihre Geschwindigkeit, Einfachheit und maschinelles Lernen bekannt ist .
- Data Studio: Ein Big-Data-Visualisierungstool mit Funktionen für die Zusammenarbeit wie Google Text & Tabellen.
In diesem Artikel erfahren Sie mehr über unsere Erfahrungen mit diesen Tools: Was wir getan haben, was wir gelernt haben und was wir als Nächstes tun werden. Wir werden uns nun auf Batch- und interaktive Analysen konzentrieren. Wir werden die Echtzeitanalyse im nächsten Artikel diskutieren.
Verlauf des Twitter-Datenspeichers
Bevor Sie in BigQuery eintauchen, sollten Sie die Geschichte der Twitter-Datenspeicherung kurz nacherzählen. Im Jahr 2011 wurde die Twitter-Datenanalyse in Vertica und Hadoop durchgeführt. Um MapReduce Hadoop-Jobs zu erstellen, haben wir Pig verwendet. 2012 haben wir Pig durch Scalding ersetzt, das über eine Scala-API verfügt, die Vorteile wie die Möglichkeit zur Erstellung komplexer Pipelines und die einfache Prüfung bietet. Für viele Datenanalysten und Produktmanager, die mit SQL besser vertraut waren, war dies jedoch eine steile Lernkurve. Um 2016 haben wir begonnen, Presto als SQL-Schnittstelle für Hadoop-Daten zu verwenden. Spark bot eine Python-Oberfläche an, die es zu einer guten Wahl für Ad-hoc-Data-Mining und maschinelles Lernen macht.
Seit 2018 verwenden wir folgende Tools zur Datenanalyse und -visualisierung:
- Verbrühung für Produktionsförderer
- Verbrühung und Funke für Ad-hoc-Datenanalyse und maschinelles Lernen
- Vertica und Presto für Ad-hoc- und interaktive SQL-Analysen
- Druide für geringen interaktiven, explorativen und latenzarmen Zugriff auf Zeitreihenmetriken
- Tableau, Zeppelin und Pivot zur Datenvisualisierung
Wir haben festgestellt, dass diese Tools zwar sehr leistungsstarke Funktionen bieten, wir jedoch Schwierigkeiten hatten, diese Funktionen einem breiteren Publikum auf Twitter zur Verfügung zu stellen. Während wir unsere Plattform mit Google Cloud erweitern, konzentrieren wir uns auf die Vereinfachung unserer Analysetools auf Twitter.
Google BigQuery Data Warehouse
Mehrere Teams auf Twitter haben BigQuery bereits in einige ihrer Produktionspipelines aufgenommen. Aufgrund ihrer Erfahrung haben wir begonnen, die Funktionen von BigQuery für alle Twitter-Anwendungsfälle zu evaluieren. Unser Ziel war es, BigQuery dem gesamten Unternehmen anzubieten und innerhalb der Data Platform-Toolbox zu standardisieren und zu unterstützen. Dies war aus vielen Gründen schwierig. Wir mussten die Infrastruktur so gestalten, dass große Datenmengen zuverlässig empfangen, das Datenmanagement im gesamten Unternehmen unterstützt, eine ordnungsgemäße Zugriffskontrolle und die Privatsphäre der Kunden gewährleistet werden. Wir mussten auch Systeme für die Ressourcenzuweisung, Überwachung und Rückbuchung erstellen, damit Teams BigQuery effektiv nutzen können.
Im November 2018 haben wir eine Alpha-Version von BigQuery und Data Studio für das gesamte Unternehmen veröffentlicht. Wir haben Twitter-Mitarbeitern einige unserer am häufigsten verwendeten Tabellen mit gelöschten persönlichen Daten angeboten. BigQuery wurde von über 250 Benutzern aus verschiedenen Teams verwendet, darunter Engineering, Finanzen und Marketing. Zuletzt wurden ungefähr 8.000 Anfragen ausgeführt, wobei ungefähr 100 PB pro Monat verarbeitet wurden, ausgenommen geplante Anfragen. Nachdem wir sehr positive Rückmeldungen erhalten hatten, beschlossen wir, BigQuery als unsere primäre Ressource für die Interaktion mit Daten auf Twitter anzubieten.
Hier ist ein Diagramm der allgemeinen Architektur unseres Google BigQuery Data Warehouse.
Wir kopieren Daten von lokalen Hadoop-Clustern mithilfe des internen Cloud Replicator-Tools in Google Cloud Storage (GCS). Anschließend erstellen wir mit Apache Airflow Pipelines, die " bq_load " zum Laden von Daten aus GCS in BigQuery verwenden. Wir verwenden Presto, um Parkett- oder Thrift-LZO-Datensätze in GCS abzufragen. BQ Blaster ist ein internes Scalding-Tool zum Laden von Vertica- und Thrift-LZO HDFS-Datasets in BigQuery.
In den folgenden Abschnitten werden wir unseren Ansatz und unser Wissen in den Bereichen Benutzerfreundlichkeit, Leistung, Datenmanagement, Systemzustand und Kosten erörtern.
Benutzerfreundlichkeit
Wir fanden es für Benutzer einfach, mit BigQuery zu beginnen, da keine Softwareinstallation erforderlich war und Benutzer über eine intuitive Weboberfläche darauf zugreifen konnten. Benutzer mussten sich jedoch mit einigen GCP-Funktionen und -Konzepten vertraut machen, einschließlich Ressourcen wie Projekten, Datensätzen und Tabellen. Wir haben Tutorials und Tutorials entwickelt, um Benutzern den Einstieg zu erleichtern. Mit diesem Grundverständnis können Benutzer problemlos in Datasets navigieren, Schema- und Tabellendaten anzeigen, einfache Abfragen ausführen und Ergebnisse in Data Studio visualisieren.
Unser Ziel bei der Dateneingabe in BigQuery war es, ein reibungsloses Laden von HDFS- oder GCS-Datensätzen mit einem Klick sicherzustellen. Wir betrachtenCloud Composer (von Airflow verwaltet), konnte es jedoch aufgrund unseres Sicherheitsmodells für die eingeschränkte Freigabe von Domänen nicht verwenden (mehr dazu im Abschnitt Datenverwaltung unten). Wir haben mit der Verwendung des Google Data Transfer Service (DTS) experimentiert, um BigQuery-Ladeaufgaben zu organisieren. Während DTS schnell eingerichtet werden konnte, war es für den Aufbau von Abhängigkeitspipelines nicht flexibel. Für unser Alpha haben wir unser eigenes Apache Airflow-Framework in GCE erstellt und bereiten es für die Produktion und die Fähigkeit vor, mehr Datenquellen wie Vertica zu unterstützen.
Um Daten in BigQuery umzuwandeln, erstellen Benutzer mithilfe geplanter Abfragen einfache Pipelines mit SQL-Daten. Für komplexe mehrstufige Abhängigkeitspipelines planen wir, entweder unser eigenes Airflow-Framework oder Cloud Composer zusammen mit Cloud Dataflow zu verwenden .
Performance
BigQuery wurde für allgemeine SQL-Abfragen entwickelt, die große Datenmengen verarbeiten. Es ist nicht für Abfragen mit geringer Latenz, hohem Durchsatz, die für eine Transaktionsdatenbank erforderlich sind, oder für die von Apache Druid implementierte Zeitreihenanalyse mit niedriger Latenz vorgesehen . Für interaktive analytische Abfragen erwarten unsere Benutzer eine Antwortzeit von weniger als einer Minute. Wir mussten die BigQuery-Nutzung so gestalten, dass diese Erwartungen erfüllt wurden. Um eine vorhersehbare Leistung für unsere Benutzer zu gewährleisten, haben wir BigQuery verwendet, eine Funktion, die Kunden pauschal zur Verfügung steht und es Projektbesitzern ermöglicht, Mindeststeckplätze für ihre Anfragen zu reservieren. SlotBigQuery ist eine Einheit der Rechenleistung, die zum Ausführen von SQL-Abfragen erforderlich ist.
Wir haben über 800 Abfragen analysiert, die jeweils etwa 1 TB Daten verarbeiten, und eine durchschnittliche Ausführungszeit von 30 Sekunden ermittelt. Wir haben auch gelernt, dass die Leistung in hohem Maße von der Verwendung unseres Slots in verschiedenen Projekten und Aufgaben abhängt. Wir mussten klar zwischen unseren Produktions- und Ad-hoc-Slot-Reserven unterscheiden, um die Leistung für Produktionsanwendungsfälle und interaktive Analysen aufrechtzuerhalten. Dies hat unser Design für Slot-Reservierungen und die Projekthierarchie stark beeinflusst.
Wir werden in den kommenden Tagen im zweiten Teil der Übersetzung über Datenmanagement, Funktionalität und Kosten von Systemen sprechen und laden jetzt alle zu einem kostenlosen Live-Webinar ein, , — (Senior Data Engineer, MaximaTelecom).