Hej, Habr! Tilmelding til en ny kursusstrøm er åben lige nu hos OTUS . I forventning om kursets start har vi traditionelt udarbejdet en oversættelse af interessant materiale til dig.
Hver dag besøger mere end hundrede millioner mennesker Twitter for at finde ud af, hvad der sker i verden, og diskutere det. Hvert tweet og hver anden brugerhandling genererer en begivenhed, der er tilgængelig for Twitters interne dataanalyse. Hundredvis af medarbejdere analyserer og visualiserer disse data, og at forbedre deres oplevelse er en topprioritet for Twitter Data Platform-teamet.
Vi mener, at brugere med en bred vifte af tekniske færdigheder skal kunne opdage data og have adgang til velfungerende SQL-baserede analyse- og visualiseringsværktøjer. Dette ville give en helt ny gruppe af mindre tekniske brugere, inklusive dataanalytikere og produktchefer, mulighed for at udtrække indsigt fra data, hvilket giver dem mulighed for bedre at forstå og bruge Twitters muligheder. Sådan demokratiserer vi dataanalyse på Twitter.
Efterhånden som vores værktøjer og interne dataanalysefunktioner er blevet forbedret, har vi set Twitter blive bedre. Der er dog stadig plads til forbedringer. Nuværende værktøjer som Scalding kræver programmeringserfaring. SQL-baserede analyseværktøjer såsom Presto og Vertica har ydeevneproblemer i stor skala. Vi har også problemet med at distribuere data på tværs af flere systemer uden konstant adgang til det.
Sidste år annoncerede vi , inden for hvilken vi overfører dele af vores på Google Cloud Platform (GCP). Vi har konkluderet, at Google Cloud-værktøjer kan hjælpe os med vores initiativer til at demokratisere analyser, visualisering og maskinlæring på Twitter:
- : virksomhedsdatavarehus med SQL-motorbaseret , som er berømt for sin hurtighed, enkelhed og håndterer .
- big data visualiseringsværktøj med Google Docs-lignende samarbejdsfunktioner.
I denne artikel vil du lære om vores erfaring med disse værktøjer: hvad vi gjorde, hvad vi lærte, og hvad vi vil gøre næste gang. Vi vil nu fokusere på batch og interaktive analyser. Vi vil diskutere realtidsanalyser i den næste artikel.
Historien om Twitter Data Stores
Før du dykker ned i BigQuery, er det værd at kort fortælle historien om Twitter-data warehousing. I 2011 blev Twitter-dataanalyse udført i Vertica og Hadoop. Vi brugte Pig til at oprette MapReduce Hadoop-job. I 2012 erstattede vi Pig med Scalding, som havde en Scala API med fordele såsom evnen til at skabe komplekse pipelines og let at teste. Men for mange dataanalytikere og produktchefer, der var mere komfortable med at arbejde med SQL, var det en ret stejl indlæringskurve. Omkring 2016 begyndte vi at bruge Presto som en SQL-grænseflade til Hadoop-data. Spark tilbød en Python-grænseflade, som gør den til et godt valg til ad hoc datavidenskab og maskinlæring.
Siden 2018 har vi brugt følgende værktøjer til dataanalyse og visualisering:
- Skoldning til produktionstransportører
- Scalding og Spark til ad hoc dataanalyse og maskinlæring
- Vertica og Presto til ad hoc og interaktiv SQL-analyse
- Druid til lav interaktiv, udforskende og lav latensadgang til tidsseriemålinger
- Tableau, Zeppelin og Pivot til datavisualisering
Vi fandt ud af, at selvom disse værktøjer tilbyder meget kraftfulde muligheder, havde vi svært ved at gøre disse muligheder tilgængelige for et bredere publikum på Twitter. Ved at udvide vores platform med Google Cloud fokuserer vi på at forenkle vores analyseværktøjer for hele Twitter.
Googles BigQuery Data Warehouse
Flere teams hos Twitter har allerede indarbejdet BigQuery i nogle af deres produktionspipelines. Ved at bruge deres ekspertise begyndte vi at evaluere BigQuerys muligheder for alle Twitter-brugssager. Vores mål var at tilbyde BigQuery til hele virksomheden og standardisere og understøtte det inden for dataplatformens værktøjssæt. Dette var svært af mange grunde. Vi var nødt til at udvikle en infrastruktur til pålideligt at indtage store mængder data, understøtte virksomhedsdækkende dataadministration, sikre korrekt adgangskontrol og sikre kundernes privatliv. Vi var også nødt til at skabe systemer til ressourceallokering, overvågning og tilbageførsler, så teams kunne bruge BigQuery effektivt.
I november 2018 udgav vi en virksomhedsdækkende alfaudgivelse af BigQuery og Data Studio. Vi har tilbudt Twitter-medarbejdere nogle af vores mest brugte regneark med ryddede personlige data. BigQuery er blevet brugt af over 250 brugere fra en række forskellige teams, herunder teknik, økonomi og marketing. Senest kørte de omkring 8 anmodninger, behandlede omkring 100 PB om måneden, ikke medregnet planlagte anmodninger. Efter at have modtaget meget positiv feedback besluttede vi at gå videre og tilbyde BigQuery som den primære ressource til at interagere med data på Twitter.
Her er et diagram på højt niveau over vores Google BigQuery-datavarehusarkitektur.
Vi kopierer data fra lokale Hadoop-klynger til Google Cloud Storage (GCS) ved hjælp af det interne Cloud Replicator-værktøj. Vi bruger derefter Apache Airflow til at skabe rørledninger, der bruger "» for at indlæse data fra GCS til BigQuery. Vi bruger Presto til at forespørge Parquet- eller Thrift-LZO-datasæt i GCS. BQ Blaster er et internt skoldningsværktøj til at indlæse HDFS Vertica og Thrift-LZO datasæt i BigQuery.
I de følgende afsnit diskuterer vi vores tilgang og ekspertise inden for områderne brugervenlighed, ydeevne, datastyring, systemsundhed og omkostninger.
Brugervenlighed
Vi fandt ud af, at det var nemt for brugerne at komme i gang med BigQuery, fordi det ikke krævede softwareinstallation, og brugerne kunne få adgang til det via en intuitiv webgrænseflade. Brugerne skulle dog blive fortrolige med nogle af GCP's funktioner og koncepter, herunder ressourcer såsom projekter, datasæt og tabeller. Vi har udviklet undervisningsmaterialer og selvstudier for at hjælpe brugerne med at komme i gang. Med en opnået grundlæggende forståelse fandt brugerne det nemt at navigere i datasæt, se skema- og tabeldata, køre enkle forespørgsler og visualisere resultater i Data Studio.
Vores mål for dataindtastning i BigQuery var at muliggøre problemfri indlæsning af HDFS- eller GCS-datasæt med et enkelt klik. Vi overvejede (administreret af Airflow), men kunne ikke bruge det på grund af vores Domain Restricted Sharing-sikkerhedsmodel (mere om dette i afsnittet Data Management nedenfor). Vi eksperimenterede med at bruge Google Data Transfer Service (DTS) til at orkestrere BigQuery-arbejdsbelastninger. Selvom DTS var hurtig at konfigurere, var den ikke fleksibel til at bygge pipelines med afhængigheder. Til vores alfa-udgivelse har vi bygget vores egen Apache Airflow-ramme i GCE og forbereder den til at køre i produktion og være i stand til at understøtte flere datakilder såsom Vertica.
For at transformere data til BigQuery opretter brugere simple SQL-datapipelines ved hjælp af planlagte forespørgsler. Til komplekse flertrinsrørledninger med afhængigheder planlægger vi at bruge enten vores egen Airflow-ramme eller Cloud Composer sammen med .
Ydelse
BigQuery er designet til generelle SQL-forespørgsler, der behandler store mængder data. Det er ikke beregnet til forespørgsler med lav latens, høj gennemløb, der kræves af en transaktionsdatabase, eller til den implementerede tidsserieanalyse med lav latens . For interaktive analyseforespørgsler forventer vores brugere svartider på mindre end et minut. Vi var nødt til at designe vores brug af BigQuery for at leve op til disse forventninger. For at give vores brugere en forudsigelig ydeevne, har vi udnyttet BigQuery-funktionaliteten, som er tilgængelig for kunderne på et fast gebyr, som giver projektejere mulighed for at reservere minimumspladser til deres forespørgsler. BigQuery er en enhed af computerkraft, der kræves for at udføre SQL-forespørgsler.
Vi analyserede over 800 forespørgsler, der behandlede ca. 1 TB data hver, og fandt ud af, at den gennemsnitlige udførelsestid var 30 sekunder. Vi lærte også, at ydeevne er meget afhængig af brugen af vores slot i forskellige projekter og opgaver. Vi var nødt til klart at afgrænse vores produktions- og ad hoc-slotreserver for at opretholde ydeevnen for produktionsbrugssager og onlineanalyse. Dette påvirkede i høj grad vores design til pladsreservationer og projekthierarki.
Vi taler om datastyring, funktionalitet og systemomkostninger i de kommende dage i anden del af oversættelsen, men nu inviterer vi alle til at , hvor du vil være i stand til at lære detaljeret om kurset, samt stille spørgsmål til vores ekspert - Egor Mateshuk (Senior Data Engineer, MaximaTelecom).
Læs mere:
Kilde: www.habr.com