Hey Habr! Die Anmeldung für einen neuen Kurszweig ist ab sofort bei OTUS möglich . Im Vorfeld des Kursbeginns haben wir traditionell eine Übersetzung interessanter Inhalte für Sie vorbereitet.
Jeden Tag besuchen über hundert Millionen Menschen Twitter, um herauszufinden, was in der Welt vor sich geht, und um darüber zu diskutieren. Jeder Tweet und jede andere Benutzeraktion generiert ein Ereignis, das für die interne Datenanalyse innerhalb von Twitter zur Verfügung steht. Hunderte von Mitarbeitern analysieren und visualisieren diese Daten, und die Verbesserung ihrer Erfahrung hat für das Twitter Data Platform-Team 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 gut funktionierende SQL-basierte Analyse- und Visualisierungstools zu haben. Dies würde es einer ganz neuen Gruppe weniger technischer Benutzer, darunter Datenanalysten und Produktmanager, ermöglichen, Erkenntnisse aus den Daten zu gewinnen und so die Leistungsfähigkeit von Twitter besser zu verstehen und zu nutzen. So demokratisieren wir die Datenanalyse auf Twitter.
Da sich unsere Tools und Fähigkeiten zur internen Datenanalyse verbessert haben, konnten wir auch eine Verbesserung des Twitter-Dienstes beobachten. Allerdings gibt es noch Raum für Verbesserungen. Aktuelle Tools wie Scalding erfordern Programmiererfahrung. SQL-basierte Analysetools wie Presto und Vertica weisen in großem Umfang Leistungsprobleme auf. Wir haben auch ein Problem damit, Daten über mehrere Systeme zu verteilen, ohne ständigen Zugriff darauf zu haben.
Letztes Jahr haben wir es angekündigt , innerhalb derer wir Teile unserer übertragen auf der Google Cloud Platform (GCP). Wir kamen zu dem Schluss, dass Google Cloud-Tools kann uns bei unseren Initiativen zur Demokratisierung von Analyse, Visualisierung und maschinellem Lernen auf Twitter helfen:
- : Enterprise Data Warehouse mit SQL-Engine-Basis , das für seine Geschwindigkeit, Einfachheit und Handhabung bekannt ist .
- Big-Data-Visualisierungstool mit Kollaborationsfunktionen wie Google Docs.
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 konzentrieren uns nun auf Batch- und interaktive Analysen. Echtzeitanalysen werden im nächsten Artikel besprochen.
Die Geschichte der Data Warehouses auf Twitter
Bevor wir uns mit BigQuery befassen, lohnt es sich, noch einmal kurz die Geschichte der Data Warehouses auf Twitter zu erzählen. Im Jahr 2011 wurde eine Datenanalyse auf Twitter in Vertica und Hadoop durchgeführt. Um MapReduce Hadoop-Jobs zu erstellen, haben wir Pig verwendet. Im Jahr 2012 ersetzten wir Pig durch Scalding, das über eine Scala-API mit Vorteilen wie der Möglichkeit zur Erstellung komplexer Pipelines und einfacher Testbarkeit verfügte. Für viele Datenanalysten und Produktmanager, die sich mit SQL besser auskennen, war die Lernkurve jedoch recht steil. Etwa 2016 begannen wir, Presto als unser SQL-Frontend für Hadoop-Daten zu verwenden. Spark bot eine Python-Schnittstelle, die es zu einer guten Wahl für Ad-hoc-Datenwissenschaft und maschinelles Lernen macht.
Seit 2018 nutzen wir folgende Tools zur Datenanalyse und Visualisierung:
- Brühung für Produktionslinien
- 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 den Zugriff auf Zeitreihenmetriken mit geringem interaktivem, explorativem Zugriff und geringer Latenz
- 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 zugänglich zu machen. Durch die Erweiterung unserer Plattform mit Google Cloud konzentrieren wir uns auf die Vereinfachung unserer Analysetools für ganz Twitter.
Googles BigQuery Data Warehouse
Mehrere Teams bei Twitter haben BigQuery bereits in einige ihrer Produktionspipelines integriert. Mithilfe ihrer Erfahrung begannen wir, die Möglichkeiten von BigQuery für alle Twitter-Anwendungsfälle zu bewerten. Unser Ziel war es, BigQuery dem gesamten Unternehmen anzubieten und es innerhalb des Data Platform Toolkits zu standardisieren und zu unterstützen. Das war aus vielen Gründen schwierig. Wir mussten eine Infrastruktur entwickeln, um große Datenmengen zuverlässig zu empfangen, die unternehmensweite Datenverwaltung zu unterstützen, ordnungsgemäße Zugriffskontrollen sicherzustellen und die Privatsphäre der Kunden zu gewährleisten. Wir mussten auch Systeme für die Ressourcenzuweisung, Überwachung und Rückbuchungen erstellen, damit Teams BigQuery effektiv nutzen konnten.
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 zur Löschung persönlicher Daten angeboten. BigQuery wurde von über 250 Benutzern aus verschiedenen Teams verwendet, darunter Technik, Finanzen und Marketing. Zuletzt führten sie etwa 8 Anfragen durch und verarbeiteten etwa 100 PB pro Monat, geplante Anfragen nicht mitgerechnet. Nachdem wir sehr positives Feedback erhalten hatten, beschlossen wir, weiterzumachen und BigQuery als primäre Ressource für die Interaktion mit Daten auf Twitter anzubieten.
Hier ist ein Diagramm der High-Level-Architektur unseres Google BigQuery Data Warehouse.
Wir kopieren Daten von lokalen Hadoop-Clustern mit dem internen Cloud Replicator-Tool in Google Cloud Storage (GCS). Anschließend verwenden wir Apache Airflow, um Pipelines zu erstellen, die „» um Daten aus GCS in BigQuery zu laden. Wir verwenden Presto, um Parquet- oder Thrift-LZO-Datensätze in GCS abzufragen. BQ Blaster ist ein internes Scalding-Tool zum Laden von HDFS-Vertica- und Thrift-LZO-Datensätzen in BigQuery.
In den folgenden Abschnitten werden wir unseren Ansatz und unser Fachwissen in den Bereichen Benutzerfreundlichkeit, Leistung, Datenverwaltung, Systemzustand und Kosten diskutieren.
Benutzerfreundlichkeit
Wir haben festgestellt, dass der Einstieg in BigQuery für Benutzer einfach war, 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 einem grundlegenden Verständnis ist es für Benutzer einfach, in Datensätzen zu navigieren, Schema- und Tabellendaten anzuzeigen, einfache Abfragen auszuführen und Ergebnisse in Data Studio zu visualisieren.
Unser Ziel bei der Dateneingabe in BigQuery bestand darin, ein nahtloses Laden von HDFS- oder GCS-Datensätzen mit einem einzigen Klick zu ermöglichen. Wir betrachten (verwaltet von Airflow), konnten es jedoch aufgrund unseres Sicherheitsmodells „Domain Restricted Sharing“ nicht verwenden (mehr dazu im Abschnitt „Datenverwaltung“ weiter unten). Wir haben mit der Verwendung des Google Data Transfer Service (DTS) experimentiert, um BigQuery-Ladeaufgaben zu organisieren. Obwohl sich DTS schnell einrichten ließ, war es nicht flexibel für den Aufbau von Pipelines mit Abhängigkeiten. Für unsere Alpha-Version haben wir unsere eigene Apache Airflow-Umgebung in GCE erstellt und bereiten sie für die Produktion und die Fähigkeit zur Unterstützung weiterer Datenquellen wie Vertica vor.
Um Daten in BigQuery umzuwandeln, erstellen Benutzer mithilfe geplanter Abfragen einfache SQL-Datenpipelines. Für komplexe mehrstufige Pipelines mit Abhängigkeiten planen wir, entweder unser eigenes Airflow-Framework oder Cloud Composer zu verwenden .
Leistung
BigQuery ist für allgemeine SQL-Abfragen konzipiert, die große Datenmengen verarbeiten. Es ist nicht für die für eine Transaktionsdatenbank erforderlichen Abfragen mit geringer Latenz und hohem Durchsatz oder für die von ihr implementierte Zeitreihenanalyse mit geringer Latenz gedacht . Bei interaktiven Analyseabfragen erwarten unsere Nutzer eine Antwortzeit von weniger als einer Minute. Wir mussten den Einsatz von BigQuery so gestalten, dass er diese Erwartungen erfüllt. Um unseren Benutzern eine vorhersehbare Leistung zu bieten, haben wir die BigQuery-Funktionalität verwendet, die Kunden gegen eine feste Gebühr zur Verfügung steht und es Projektinhabern ermöglicht, Mindestslots für ihre Abfragen zu reservieren. BigQuery 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 verarbeiteten, und festgestellt, dass die durchschnittliche Ausführungszeit 30 Sekunden betrug. Wir haben auch gelernt, dass die Leistung stark von der Nutzung unseres Slots in verschiedenen Projekten und Aufgaben abhängt. Wir mussten unsere Produktions- und Ad-hoc-Slot-Reserven klar trennen, um die Leistung für Produktionsanwendungsfälle und interaktive Analysen aufrechtzuerhalten. Dies hat unser Design für Slotreservierungen und Projekthierarchien stark beeinflusst.
Wir werden in den kommenden Tagen im zweiten Teil der Übersetzung über Datenmanagement, Funktionalität und Kosten von Systemen sprechen und laden nun alle dazu ein Hier können Sie mehr über den Kurs erfahren und Fragen an unseren Experten Egor Mateshuk (Senior Data Engineer, MaximaTelecom) stellen.
Weiterlesen:
Source: habr.com