Hallo, Habr! De inschrijving voor een nieuwe cursusstroom is momenteel geopend bij OTUS . Vooruitlopend op de start van de cursus hebben wij traditioneel een vertaling van interessant materiaal voor u klaargemaakt.
Elke dag bezoeken meer dan honderd miljoen mensen Twitter om te ontdekken wat er in de wereld gebeurt en daarover te praten. Elke tweet en elke andere gebruikersactie genereert een gebeurtenis die beschikbaar is voor de interne gegevensanalyse van Twitter. Honderden medewerkers analyseren en visualiseren deze gegevens, en het verbeteren van hun ervaring is een topprioriteit voor het Twitter Data Platform-team.
Wij zijn van mening dat gebruikers met een breed scala aan technische vaardigheden gegevens moeten kunnen ontdekken en toegang moeten hebben tot goed presterende, op SQL gebaseerde analyse- en visualisatietools. Hierdoor zou een hele nieuwe groep minder technische gebruikers, waaronder data-analisten en productmanagers, inzichten uit data kunnen halen, waardoor ze de mogelijkheden van Twitter beter zouden kunnen begrijpen en gebruiken. Dit is hoe we data-analyse op Twitter democratiseren.
Naarmate onze tools en interne data-analysemogelijkheden zijn verbeterd, hebben we Twitter ook zien verbeteren. Er is echter nog ruimte voor verbetering. Huidige tools zoals Scalding vereisen programmeerervaring. Op SQL gebaseerde analysetools zoals Presto en Vertica hebben prestatieproblemen op schaal. We hebben ook het probleem dat gegevens over meerdere systemen worden verspreid zonder dat er voortdurend toegang toe is.
Vorig jaar hebben wij het aangekondigd , waarbinnen we delen van ons overdragen op Google Cloud Platform (GCP). We zijn tot de conclusie gekomen dat Google Cloud-tools kan ons helpen met onze initiatieven om analytics, visualisatie en machinaal leren op Twitter te democratiseren:
- : bedrijfsdatawarehouse op basis van SQL-engine , dat bekend staat om zijn snelheid, eenvoud en bediening .
- big data-visualisatietool met Google Docs-achtige samenwerkingsfuncties.
In dit artikel leest u over onze ervaringen met deze tools: wat we hebben gedaan, wat we hebben geleerd en wat we hierna gaan doen. We zullen ons nu concentreren op batch- en interactieve analyses. We zullen realtime analyses bespreken in het volgende artikel.
Geschiedenis van Twitter-gegevensopslag
Voordat we in BigQuery duiken, is het de moeite waard om kort de geschiedenis van Twitter-datawarehousing te vertellen. In 2011 werd Twitter-data-analyse uitgevoerd in Vertica en Hadoop. We hebben Pig gebruikt om MapReduce Hadoop-taken te maken. In 2012 hebben we Pig vervangen door Scalding, dat een Scala API had met voordelen zoals de mogelijkheid om complexe pijpleidingen te creëren en het gemak van testen. Voor veel data-analisten en productmanagers die zich meer op hun gemak voelden bij het werken met SQL, was het echter een vrij steile leercurve. Rond 2016 zijn we Presto gaan gebruiken als SQL-interface voor Hadoop-gegevens. Spark bood een Python-interface aan, waardoor het een goede keuze is voor ad-hocdatawetenschap en machine learning.
Sinds 2018 gebruiken we de volgende tools voor data-analyse en visualisatie:
- Broeien voor productietransportbanden
- Scalding en Spark voor ad-hoc data-analyse en machine learning
- Vertica en Presto voor ad hoc en interactieve SQL-analyse
- Druïde voor lage interactieve, verkennende toegang met lage latentie tot tijdreeksstatistieken
- Tableau, Zeppelin en Pivot voor datavisualisatie
We ontdekten dat hoewel deze tools zeer krachtige mogelijkheden bieden, we moeite hadden deze mogelijkheden beschikbaar te maken voor een breder publiek op Twitter. Door ons platform uit te breiden met Google Cloud, richten we ons op het vereenvoudigen van onze analysetools voor heel Twitter.
Het BigQuery-datawarehouse van Google
Verschillende teams bij Twitter hebben BigQuery al in een aantal van hun productiepijplijnen opgenomen. Met behulp van hun expertise zijn we de mogelijkheden van BigQuery voor alle Twitter-gebruiksscenario's gaan evalueren. Ons doel was om BigQuery aan het hele bedrijf aan te bieden en te standaardiseren en te ondersteunen binnen de Data Platform-toolset. Dit was om vele redenen moeilijk. We moesten een infrastructuur ontwikkelen om op betrouwbare wijze grote hoeveelheden gegevens te verwerken, bedrijfsbreed gegevensbeheer te ondersteunen, goede toegangscontroles te garanderen en de privacy van klanten te waarborgen. We moesten ook systemen creëren voor de toewijzing van middelen, monitoring en terugboekingen, zodat teams BigQuery effectief konden gebruiken.
In november 2018 hebben we een bedrijfsbrede alfarelease van BigQuery en Data Studio uitgebracht. We hebben Twitter-medewerkers een aantal van onze meest gebruikte spreadsheets met opgeschoonde persoonlijke gegevens aangeboden. BigQuery is gebruikt door meer dan 250 gebruikers uit verschillende teams, waaronder engineering, financiën en marketing. Meest recent voerden ze ongeveer 8 verzoeken uit, waarbij ongeveer 100 PB per maand werd verwerkt, de geplande verzoeken niet meegerekend. Na zeer positieve feedback te hebben ontvangen, hebben we besloten verder te gaan en BigQuery aan te bieden als de belangrijkste bron voor interactie met gegevens op Twitter.
Hier ziet u een diagram op hoog niveau van onze Google BigQuery-datawarehouse-architectuur.
We kopiëren gegevens van lokale Hadoop-clusters naar Google Cloud Storage (GCS) met behulp van de interne Cloud Replicator-tool. Vervolgens gebruiken we Apache Airflow om pijpleidingen te maken die gebruikmaken van "» om gegevens uit GCS in BigQuery te laden. We gebruiken Presto om Parquet- of Thrift-LZO-gegevenssets in GCS op te vragen. BQ Blaster is een interne Scalding-tool voor het laden van HDFS Vertica- en Thrift-LZO-datasets in BigQuery.
In de volgende paragrafen bespreken we onze aanpak en expertise op het gebied van gebruiksgemak, prestaties, databeheer, systeemgezondheid en kosten.
Gebruiksgemak
We ontdekten dat het voor gebruikers gemakkelijk was om met BigQuery aan de slag te gaan, omdat er geen software-installatie voor nodig was en gebruikers er toegang toe hadden via een intuïtieve webinterface. Gebruikers moesten echter vertrouwd raken met enkele functies en concepten van GCP, waaronder bronnen zoals projecten, datasets en tabellen. We hebben educatief materiaal en tutorials ontwikkeld om gebruikers op weg te helpen. Nu ze meer basiskennis hadden, konden gebruikers gemakkelijk door datasets navigeren, schema- en tabelgegevens bekijken, eenvoudige query's uitvoeren en resultaten visualiseren in Data Studio.
Ons doel voor de gegevensinvoer in BigQuery was het naadloos laden van HDFS- of GCS-datasets met één klik mogelijk te maken. Wij hebben overwogen (beheerd door Airflow) maar konden het niet gebruiken vanwege ons Domain Restricted Sharing-beveiligingsmodel (meer hierover in het gedeelte Gegevensbeheer hieronder). We hebben geëxperimenteerd met het gebruik van Google Data Transfer Service (DTS) om BigQuery-productietaken te orkestreren. Hoewel DTS snel kon worden opgezet, was het niet flexibel voor het bouwen van pijpleidingen met afhankelijkheden. Voor onze alpha-release hebben we ons eigen Apache Airflow-framework in GCE gebouwd en bereiden we het voor om in productie te draaien en meer gegevensbronnen zoals Vertica te kunnen ondersteunen.
Om gegevens om te zetten in BigQuery maken gebruikers eenvoudige SQL-gegevenspijplijnen met behulp van geplande query's. Voor complexe meertrapspijplijnen met afhankelijkheden zijn we van plan om ons eigen Airflow-framework of Cloud Composer te gebruiken, samen met .
Производительность
BigQuery is ontworpen voor algemene SQL-query's waarbij grote hoeveelheden gegevens worden verwerkt. Het is niet bedoeld voor de zoekopdrachten met lage latentie en hoge doorvoer die vereist zijn door een transactionele database, of voor de geïmplementeerde tijdreeksanalyse met lage latentie . Voor interactieve analysevragen verwachten onze gebruikers een responstijd van minder dan één minuut. We moesten ons gebruik van BigQuery zo ontwerpen dat we aan deze verwachtingen konden voldoen. Om onze gebruikers voorspelbare prestaties te bieden, hebben we gebruik gemaakt van de BigQuery-functionaliteit, die beschikbaar is voor klanten op basis van een vast bedrag, waarmee projecteigenaren minimale slots kunnen reserveren voor hun zoekopdrachten. BigQuery is een eenheid van rekenkracht die nodig is om SQL-query's uit te voeren.
We hebben meer dan 800 zoekopdrachten geanalyseerd die elk ongeveer 1 TB aan gegevens verwerkten en ontdekten dat de gemiddelde uitvoeringstijd 30 seconden was. We hebben ook geleerd dat prestaties in hoge mate afhankelijk zijn van het gebruik van onze plek in verschillende projecten en taken. We moesten onze productie- en ad-hocslotreserves duidelijk afbakenen om de prestaties voor productiegebruik en online analyses op peil te houden. Dit heeft een grote invloed gehad op ons ontwerp voor slotreserveringen en projecthiërarchie.
We zullen de komende dagen in het tweede deel van de vertaling praten over gegevensbeheer, functionaliteit en kosten van systemen, maar nu nodigen we iedereen uit om , waarin u in detail over de cursus kunt leren en vragen kunt stellen aan onze expert - Egor Mateshuk (Senior Data Engineer, MaximaTelecom).
Lees verder:
Bron: www.habr.com