Hallo, Habr! Momentan ist in OTUS die Anmeldung für einen neuen Kursstart geöffnet. . Im Vorfeld des Kursstarts haben wir traditionell eine interessante Übersetzung für Sie vorbereitet.
Jeden Tag besuchen über hundert Millionen Menschen Twitter, um zu erfahren, was in der Welt passiert, und um darüber zu diskutieren. Jeder Tweet und jede andere Benutzeraktion erzeugt ein Ereignis, das für die interne Datenanalyse bei Twitter verfügbar ist. Hunderte von Mitarbeitern analysieren und visualisieren diese Daten, und die Verbesserung ihrer Erfahrungen hat für das Team der Twitter Data Platform höchste Priorität.
Wir sind der Meinung, dass Benutzer mit einem breiten Spektrum an technischen Fähigkeiten in der Lage sein sollten, Daten zu finden und auf gut funktionierende SQL-basierte Analyse- und Visualisierungstools zuzugreifen. Dies würde ganz neuen Gruppen von Benutzern mit weniger technischem Hintergrund, einschließlich Datenanalysten und Produktmanagern, ermöglichen, Informationen aus Daten zu extrahieren, sodass sie die Möglichkeiten von Twitter besser verstehen und nutzen können. So demokratisieren wir die Datenanalyse bei Twitter.
Mit der Weiterentwicklung unserer Tools und Möglichkeiten zur internen Datenanalyse haben wir eine Verbesserung des Twitter-Dienstes erleben können. Dennoch gibt es noch viel Raum für Wachstum. Die aktuellen Tools wie Scalding erfordern Programmiererfahrung. SQL-basierte Analysewerkzeuge wie Presto und Vertica haben Leistungseinbußen in großem Maßstab. Außerdem haben wir das Problem, Daten über mehrere Systeme ohne ständigen Zugang zu verteilen.
Im letzten Jahr haben wir bekannt gegeben , im Rahmen derer wir Teile unserer auf die Google Cloud Platform (GCP) übertragen. Wir kamen zu dem Schluss, dass die Tools von Google Cloud uns bei unseren Initiativen zur Demokratisierung von Analyse, Visualisierung und maschinellem Lernen bei Twitter helfen können:
- : ein Enterprise-Datenspeicher mit einer SQL-Engine basierend auf , das für seine Geschwindigkeit und Einfachheit bekannt ist und mit .
- ein Tool zur Visualisierung von Big Data mit Funktionen zur Zusammenarbeit, ähnlich wie bei Google Docs.
In diesem Artikel erfahren Sie von unseren Erfahrungen mit diesen Tools: Was wir getan haben, was wir gelernt haben und was wir als Nächstes tun werden. Momentan konzentrieren wir uns auf Batch- und interaktive Analysen. Echtzeitanalysen werden wir im nächsten Artikel besprechen.
Die Geschichte der Data Warehouses bei Twitter
Bevor wir uns näher mit BigQuery befassen, ist es sinnvoll, kurz die Geschichte der Data Warehouses bei Twitter zu rekapitulieren. Im Jahr 2011 wurden Datenanalysen bei Twitter mit Vertica und Hadoop durchgeführt. Für die Erstellung von MapReduce-Jobs in Hadoop verwendeten wir Pig. Im Jahr 2012 ersetzten wir Pig durch Scalding, das eine Scala-API hatte und Vorteile wie die Möglichkeit bot, komplexe Pipelines zu erstellen und die Testbarkeit zu erleichtern. Dennoch war es für viele Datenanalysten und Produktmanager, die sich mit SQL wohler fühlten, eine ziemliche Lernkurve. Etwa im Jahr 2016 begannen wir, Presto als SQL-Schnittstelle für Hadoop-Daten zu verwenden. Spark bot eine Python-Schnittstelle, die es zu einer guten Wahl für ad-hoc-Datenanalysen und maschinelles Lernen macht.
Seit 2018 nutzten wir die folgenden Werkzeuge zur Datenanalyse und -visualisierung:
- Scalding für produktive Pipelines
- Scalding und Spark für ad-hoc Datenanalysen und maschinelles Lernen
- Vertica und Presto für ad-hoc und interaktive SQL-Analysen
- Druid für kleine interaktive, explorative Zugriffe mit geringer Latenz auf Zeitreihendaten
- Tableau, Zeppelin und Pivot zur Datenvisualisierung
Wir haben festgestellt, dass, obwohl diese Werkzeuge sehr leistungsstarke Funktionen bieten, wir Schwierigkeiten hatten, die Verfügbarkeit dieser Fähigkeiten einem breiteren Publikum bei Twitter zugänglich zu machen. Durch die Erweiterung unserer Plattform mit Google Cloud konzentrieren wir uns darauf, unsere Analysewerkzeuge für ganz Twitter zu vereinfachen.
Das BigQuery-Datenlager von Google
Mehrere Teams bei Twitter haben bereits BigQuery in einigen ihrer produktiven Pipelines integriert. Basierend auf ihren Erfahrungen begannen wir, die Möglichkeiten von BigQuery für alle Anwendungsfälle bei Twitter zu bewerten. Unser Ziel war es, BigQuery der gesamten Firma anzubieten und es im Rahmen des Data Platform-Toolsets zu standardisieren und zu unterstützen. Dies war aus vielen Gründen herausfordernd. Wir mussten eine Infrastruktur entwickeln, um große Datenmengen zuverlässig zu empfangen, die Datenverwaltung unternehmensweit zu unterstützen, angemessene Zugriffskontrollen zu gewährleisten und die Privatsphäre der Kunden zu sichern. Wir mussten auch Systeme zur Ressourcenverteilung, Überwachung und Abrechnung aufbauen, damit die Teams BigQuery effektiv nutzen konnten.
Im November 2018 haben wir die Alpha-Version von BigQuery und Data Studio für das gesamte Unternehmen veröffentlicht. Wir haben den Mitarbeitern von Twitter einige unserer am häufigsten verwendeten Tabellen mit bereinigten personenbezogenen Daten angeboten. Über 250 Benutzer aus verschiedenen Teams, darunter Ingenieure, Finanzen und Marketing, verwendeten BigQuery. Vor Kurzem führten sie etwa 8.000 Abfragen durch und verarbeiteten ungefähr 100 PB pro Monat, ohne die geplanten Anfragen zu zählen. Nach sehr positiven Rückmeldungen entschieden wir uns, weiterzugehen und BigQuery als primäre Ressource für die Dateninteraktion bei Twitter anzubieten.
Hier ist das hohe Architekturdiagramm unseres Google BigQuery-Datenlagers.
Wir kopieren Daten aus lokalen Hadoop-Clustern in Google Cloud Storage (GCS) mit einem internen Tool namens Cloud Replicator. Dann verwenden wir Apache Airflow, um Pipelines zu erstellen, die „“ verwenden, um Daten aus GCS in BigQuery zu laden. Wir nutzen Presto, um Datensätze im Parquet- oder Thrift-LZO-Format in GCS abzufragen. BQ Blaster ist ein internes Scalding-Tool zum Laden von Datensätzen von HDFS Vertica und Thrift-LZO in BigQuery.
In den folgenden Abschnitten werden wir unseren Ansatz und unser Wissen über Benutzerfreundlichkeit, Leistung, Datenmanagement, Systembetrieb und Kosten besprechen.
Benutzerfreundlichkeit
Wir haben festgestellt, dass es für die Benutzer einfach war, mit BigQuery zu beginnen, da keine Software installiert werden musste und die Benutzer über eine benutzerfreundliche Weboberfläche darauf zugreifen konnten. Dennoch mussten sich die Benutzer mit einigen Funktionen und Konzepten von GCP vertrautmachen, einschließlich Ressourcen wie Projekten, Datensätzen und Tabellen. Wir haben Schulungsmaterialien und Tutorials entwickelt, um den Benutzern den Einstieg zu erleichtern. Mit einem grundlegenden Verständnis fiel es den Benutzern leicht, sich durch die Datensätze zu navigieren, das Schema und die Daten der Tabellen anzuzeigen, einfache Abfragen durchzuführen und die Ergebnisse in Data Studio zu visualisieren.
Unser Ziel bezüglich der Dateneingabe in BigQuery war es, das Hochladen von HDFS- oder GCS-Datensätzen mit einem Mausklick zu ermöglichen. Wir haben „ (gesteuertes Airflow), aber wir konnten es aufgrund unseres Sicherheitsmodells „Domain Restricted Sharing“ nicht verwenden (mehr dazu im Abschnitt „Datenmanagement“ weiter unten). Wir haben mit Google Data Transfer Service (DTS) experimentiert, um Belastungsaufgaben in BigQuery zu organisieren. Während DTS schnell eingerichtet werden konnte, war es nicht flexibel genug, um Pipelines mit Abhängigkeiten zu erstellen. Für unsere Alpha-Version haben wir eine eigene Apache Airflow-Umgebung in GCE erstellt und bereiten sie auf die Produktion vor, um mehr Datenquellen wie Vertica zu unterstützen.
Um Daten in BigQuery zu transformieren, erstellen die Benutzer einfache SQL-Datenpipelines, indem sie geplante Abfragen verwenden. Für komplexe mehrstufige Pipelines mit Abhängigkeiten planen wir die Verwendung entweder unserer eigenen Airflow-Infrastruktur oder Cloud Composer zusammen mit .
Leistung
BigQuery ist für allgemeine SQL-Abfragen konzipiert, die große Datenmengen verarbeiten. Es ist nicht für niedrige Latenzzeiten und hohe Durchsatzraten geeignet, die für transaktionale Datenbanken erforderlich sind, oder für die Analyse von Zeitreihen mit niedriger Latenz, die mit . Für interaktive Analyseabfragen erwarten unsere Benutzer eine Reaktionszeit von weniger als einer Minute. Wir mussten die Nutzung von BigQuery so gestalten, dass sie diesen Erwartungen entspricht. Um eine vorhersehbare Leistung für unsere Benutzer zu gewährleisten, haben wir die Funktionen von BigQuery genutzt, die Kunden mit einer Pauschalzahlung zur Verfügung stehen, die es Projektinhabern ermöglicht, minimale Slots für ihre Abfragen zu reservieren. BigQuery ist eine Einheit der Rechenleistung, die erforderlich ist, um SQL-Abfragen auszuführen.
Wir haben über 800 Anfragen analysiert, die jeweils etwa 1 TB Daten verarbeiten, und festgestellt, dass die durchschnittliche Ausführungszeit 30 Sekunden betrug. Wir haben auch herausgefunden, dass die Leistung stark von der Nutzung unseres Slots in verschiedenen Projekten und Aufgaben abhängt. Wir mussten unsere Produktions- und Ad-hoc-Slotreserven klar voneinander abgrenzen, um die Leistung für produktive Nutzungsszenarien und interaktive Analysen aufrechtzuerhalten. Dies hatte einen erheblichen Einfluss auf unser Design für die Slotreservierung und die Projektstruktur.
Über Datenmanagement, Funktionalität und die Kosten der Systeme sprechen wir in den nächsten Tagen im zweiten Teil der Übersetzung, aber jetzt laden wir alle Interessierten ein zu , in dessen Rahmen Sie detaillierte Informationen zum Kurs erhalten und unserem Experten – Egor Mateschuk (Senior Data Engineer, MaximaTelecom) – Fragen stellen können.
Weiterlesen:
Quelle: habr.com
