Hei, Habr! Påmelding til en ny kursstrøm er åpen akkurat nå på OTUS . I påvente av kursstart har vi tradisjonelt utarbeidet en oversettelse av interessant materiale for deg.
Hver dag besøker mer enn hundre millioner mennesker Twitter for å finne ut hva som skjer i verden og diskutere det. Hver tweet og hver annen brukerhandling genererer en hendelse som er tilgjengelig for Twitters interne dataanalyse. Hundrevis av ansatte analyserer og visualiserer disse dataene, og å forbedre opplevelsen deres er en toppprioritet for Twitter Data Platform-teamet.
Vi mener at brukere med et bredt spekter av tekniske ferdigheter bør kunne oppdage data og ha tilgang til velytende SQL-baserte analyse- og visualiseringsverktøy. Dette vil tillate en helt ny gruppe mindre tekniske brukere, inkludert dataanalytikere og produktledere, å trekke ut innsikt fra data, slik at de bedre kan forstå og bruke Twitters muligheter. Slik demokratiserer vi dataanalyse på Twitter.
Etter hvert som våre verktøy og interne dataanalysefunksjoner har blitt bedre, har vi sett Twitter forbedres. Det er imidlertid fortsatt rom for forbedring. Nåværende verktøy som Scalding krever programmeringserfaring. SQL-baserte analyseverktøy som Presto og Vertica har ytelsesproblemer i stor skala. Vi har også problemet med å distribuere data på tvers av flere systemer uten konstant tilgang til det.
I fjor annonserte vi , som vi overfører deler av vår på Google Cloud Platform (GCP). Vi har konkludert med at Google Cloud-verktøy kan hjelpe oss med våre initiativer for å demokratisere analyser, visualisering og maskinlæring på Twitter:
- : bedriftsdatavarehus med SQL-motorbasert , som er kjent for sin hastighet, enkelhet og takler .
- big data visualiseringsverktøy med Google Docs-lignende samarbeidsfunksjoner.
I denne artikkelen vil du lære om vår erfaring med disse verktøyene: hva vi gjorde, hva vi lærte og hva vi skal gjøre videre. Vi vil nå fokusere på batch og interaktiv analyse. Vi vil diskutere sanntidsanalyse i neste artikkel.
Historien om Twitter-databutikker
Før du dykker inn i BigQuery, er det verdt å fortelle kort om historien til Twitter-datavarehus. I 2011 ble Twitter-dataanalyse utført i Vertica og Hadoop. Vi brukte Pig til å lage MapReduce Hadoop-jobber. I 2012 erstattet vi Pig med Scalding, som hadde en Scala API med fordeler som muligheten til å lage komplekse rørledninger og enkel testing. For mange dataanalytikere og produktledere som var mer komfortable med å jobbe med SQL, var det imidlertid en ganske bratt læringskurve. Rundt 2016 begynte vi å bruke Presto som et SQL-grensesnitt til Hadoop-data. Spark tilbød et Python-grensesnitt, som gjør det til et godt valg for ad hoc datavitenskap og maskinlæring.
Siden 2018 har vi brukt følgende verktøy for dataanalyse og visualisering:
- Skålding for produksjonstransportører
- Scalding og Spark for ad hoc dataanalyse og maskinlæring
- Vertica og Presto for ad hoc og interaktiv SQL-analyse
- Druid for lav interaktiv, utforskende og lav latenstilgang til tidsserieberegninger
- Tableau, Zeppelin og Pivot for datavisualisering
Vi fant ut at selv om disse verktøyene tilbyr svært kraftige funksjoner, hadde vi problemer med å gjøre disse mulighetene tilgjengelige for et bredere publikum på Twitter. Ved å utvide plattformen vår med Google Cloud, fokuserer vi på å forenkle analyseverktøyene våre for hele Twitter.
Googles BigQuery Data Warehouse
Flere team på Twitter har allerede innlemmet BigQuery i noen av produksjonsrørledningene sine. Ved å bruke deres ekspertise begynte vi å evaluere BigQuerys evner for alle brukstilfeller for Twitter. Målet vårt var å tilby BigQuery til hele selskapet og standardisere og støtte det innenfor Data Platform-verktøysettet. Dette var vanskelig av mange grunner. Vi trengte å utvikle en infrastruktur for pålitelig inntak av store datamengder, støtte bedriftsomfattende dataadministrasjon, sikre riktig tilgangskontroll og sikre kundenes personvern. Vi måtte også lage systemer for ressursallokering, overvåking og tilbakeføringer slik at teamene kunne bruke BigQuery effektivt.
I november 2018 ga vi ut en bedriftsomfattende alfaversjon av BigQuery og Data Studio. Vi har tilbudt Twitter-ansatte noen av våre mest brukte regneark med ryddet opp i personlige data. BigQuery har blitt brukt av over 250 brukere fra en rekke team, inkludert engineering, økonomi og markedsføring. Senest kjørte de rundt 8 100 forespørsler, behandlet rundt XNUMX PB per måned, ikke medregnet planlagte forespørsler. Etter å ha mottatt svært positive tilbakemeldinger, bestemte vi oss for å gå videre og tilby BigQuery som den primære ressursen for interaksjon med data på Twitter.
Her er et diagram på høyt nivå over Google BigQuery-datavarehusarkitekturen vår.
Vi kopierer data fra lokale Hadoop-klynger til Google Cloud Storage (GCS) ved å bruke det interne Cloud Replicator-verktøyet. Vi bruker deretter Apache Airflow for å lage rørledninger som bruker "» for å laste inn data fra GCS til BigQuery. Vi bruker Presto til å spørre Parquet- eller Thrift-LZO-datasett i GCS. BQ Blaster er et internt Scalding-verktøy for å laste HDFS Vertica og Thrift-LZO-datasett inn i BigQuery.
I de følgende delene diskuterer vi vår tilnærming og ekspertise innen områdene brukervennlighet, ytelse, dataadministrasjon, systemhelse og kostnader.
Brukervennlighet
Vi fant ut at det var enkelt for brukere å komme i gang med BigQuery fordi det ikke krevde programvareinstallasjon og brukere kunne få tilgang til det via et intuitivt nettgrensesnitt. Imidlertid måtte brukere bli kjent med noen av GCPs funksjoner og konsepter, inkludert ressurser som prosjekter, datasett og tabeller. Vi har utviklet undervisningsmateriell og opplæringsprogrammer for å hjelpe brukere med å komme i gang. Med en grunnleggende forståelse oppnådd, fant brukerne det enkelt å navigere i datasett, se skjema- og tabelldata, kjøre enkle spørringer og visualisere resultater i Data Studio.
Målet vårt for dataregistrering i BigQuery var å muliggjøre sømløs lasting av HDFS- eller GCS-datasett med ett klikk. Vi vurderte (administrert av Airflow), men klarte ikke å bruke den på grunn av sikkerhetsmodellen vår for domenebegrenset deling (mer om dette i avsnittet Databehandling nedenfor). Vi eksperimenterte med å bruke Google Data Transfer Service (DTS) for å organisere BigQuery-arbeidsbelastninger. Mens DTS var rask å sette opp, var den ikke fleksibel for å bygge rørledninger med avhengigheter. For alfa-utgivelsen vår har vi bygget vårt eget Apache Airflow-rammeverk i GCE og forbereder det til å kjøre i produksjon og kunne støtte flere datakilder som Vertica.
For å transformere data til BigQuery oppretter brukere enkle SQL-datapipelines ved hjelp av planlagte spørringer. For komplekse flertrinns rørledninger med avhengigheter, planlegger vi å bruke enten vårt eget Airflow-rammeverk eller Cloud Composer sammen med .
Производительность
BigQuery er designet for generelle SQL-spørringer som behandler store datamengder. Den er ikke ment for spørringene med lav latens og høy gjennomstrømning som kreves av en transaksjonsdatabase, eller for tidsserieanalyse med lav latens som er implementert . For interaktive analyseforespørsler forventer brukerne våre responstider på mindre enn ett minutt. Vi måtte utforme vår bruk av BigQuery for å møte disse forventningene. For å gi forutsigbar ytelse for brukerne våre, har vi utnyttet BigQuery-funksjonaliteten, tilgjengelig for kunder på en fast avgiftsbasis som lar prosjekteiere reservere minimumsplasser for spørringene sine. BigQuery er en enhet av datakraft som kreves for å utføre SQL-spørringer.
Vi analyserte over 800 spørringer som behandlet omtrent 1 TB med data hver, og fant ut at gjennomsnittlig utførelsestid var 30 sekunder. Vi har også lært at ytelse er svært avhengig av bruken av spilleautomaten vår i forskjellige prosjekter og oppgaver. Vi måtte tydelig avgrense produksjons- og ad hoc-reservene våre for å opprettholde ytelsen for produksjonsbruk og online-analyser. Dette påvirket i stor grad vårt design for plassreservasjoner og prosjekthierarki.
Vi vil snakke om datahåndtering, funksjonalitet og systemkostnader i løpet av de kommende dagene i andre del av oversettelsen, men nå inviterer vi alle til å , hvor du vil kunne lære i detalj om kurset, samt stille spørsmål til vår ekspert - Egor Mateshuk (Senior Data Engineer, MaximaTelecom).
Les mer:
Kilde: www.habr.com