Hej, Habr! Just nu Àr anmÀlan till den nya omgÄngen av kursen pÄ OTUS öppen. . I förberedelserna inför start av kursen har vi traditionellt förberett en översÀttning av ett intressant material för er.
Mer Àn hundra miljoner mÀnniskor besöker Twitter varje dag för att ta reda pÄ vad som hÀnder i vÀrlden och diskutera det. Varje tweet och varje annan anvÀndarÄtgÀrd genererar en hÀndelse som Àr tillgÀnglig för intern dataanalys pÄ Twitter. Hundratals anstÀllda analyserar och visualiserar dessa data, och att förbÀttra deras upplevelse Àr högsta prioritet för Twitter Data Platform-teamet.
Vi anser att anvÀndare med en bredd av tekniska fÀrdigheter ska kunna hitta data och fÄ tillgÄng till vÀlinarbetade verktyg för analys och visualisering baserat pÄ SQL. Detta skulle möjliggöra för en helt ny grupp anvÀndare med mindre teknisk bakgrund, inklusive dataanalytiker och produktledare, att extrahera insikter frÄn data, vilket hjÀlper dem att bÀttre förstÄ och utnyttja möjligheterna pÄ Twitter. SÄ demokratiserar vi dataanalys pÄ Twitter.
Medan vĂ„ra verktyg och möjligheter för intern dataanalys har förbĂ€ttrats har vi sett en förbĂ€ttring av Twitter-tjĂ€nsten. ĂndĂ„ finns det fortfarande utrymme för tillvĂ€xt. Nuvarande verktyg, sĂ„som Scalding, krĂ€ver programmeringskunskaper. SQL-baserade analysverktyg, sĂ„som Presto och Vertica, har prestandaproblem i stor skala. Vi har ocksĂ„ problem med att sprida data över flera system utan konstant tillgĂ„ng till dem.
Förra Äret tillkÀnnagav vi , dÀr vi flyttar delar av vÄr till Google Cloud Platform (GCP). Vi har kommit fram till att Googles verktyg kan hjÀlpa oss i vÄra initiativ för att demokratisera analys, visualisering och maskininlÀrning pÄ Twitter:
- : företagsdatabas med en SQL-motor baserad pÄ , som Àr kÀnd för sin hastighet, enkelhet och hanterar .
- ett verktyg för visualisering av big data med samarbetsfunktioner som i Google Docs.
I denna artikel fÄr du veta om vÄra erfarenheter med dessa verktyg: vad vi har gjort, vad vi har lÀrt oss och vad vi ska göra hÀrnÀst. Just nu fokuserar vi pÄ batch- och interaktiv analys. Realtidsanalys kommer vi att diskutera i nÀsta artikel.
Historien om datalager pÄ Twitter
Innan vi dyker djupare in i BigQuery Àr det vÀrt att kort sammanfatta historien om datalager pÄ Twitter. à r 2011 utfördes dataanalys pÄ Twitter med Vertica och Hadoop. För att skapa Hadoop's MapReduce jobb anvÀnde vi Pig. à r 2012 bytte vi ut Pig mot Scalding, som hade ett Scala API med fördelar som möjligheten att skapa komplexa flöden och enkel testning. Men för mÄnga dataanalytiker och produktchefer som kÀnde sig mer bekvÀma med SQL var detta en ganska brant inlÀrningskurva. UngefÀr 2016 började vi anvÀnda Presto som SQL-grÀnssnitt för Hadoop-data. Spark erbjöd ett Python-grÀnssnitt vilket gör det till ett bra val för ad hoc dataanalyser och maskininlÀrning.
FrÄn och med 2018 har vi anvÀnt följande verktyg för dataanalys och visualisering:
- Scalding för produktionsflöden
- Scalding och Spark för ad hoc dataanalys och maskininlÀrning
- Vertica och Presto för ad hoc och interaktiv SQL-analys
- Druid för liten interaktiv, utforskande och lÄglatens Ätkomst till tidsseriemetrik
- Tableau, Zeppelin och Pivot för datavisualisering
Vi upptÀckte att Àven om dessa verktyg erbjuder mycket kraftfulla funktioner, hade vi svÄrigheter med att göra dessa funktioner tillgÀngliga för en bredare publik pÄ Twitter. NÀr vi utvidgar vÄr plattform med Google Cloud, fokuserar vi pÄ att förenkla vÄra analysverktyg för hela Twitter.
BigQuery datalager frÄn Google
Flera team pÄ Twitter har redan inkluderat BigQuery i vissa av sina produktionsflöden. Genom att anvÀnda deras erfarenhet började vi utvÀrdera BigQuery:s kapabiliteter för alla anvÀndningsscenarier pÄ Twitter. VÄrt mÄl var att erbjuda BigQuery till hela företaget samt att standardisera och underhÄlla det inom ramen för verktygen pÄ Data Platform. Detta var besvÀrligt av mÄnga skÀl. Vi behövde utveckla en infrastruktur för tillförlitlig mottagning av stora datavolymer, stöd för datastyrning pÄ företagsnivÄ, sÀkerstÀllande av korrekt Ätkomstkontroll och skydd av kunders integritet. Vi var ocksÄ tvungna att skapa system för resursfördelning, övervakning och betalningsÄtervinning sÄ att teamen effektivt kunde anvÀnda BigQuery.
I november 2018 slÀppte vi alpha-versionen av BigQuery och Data Studio för hela företaget. Vi erbjöd Twitter-anstÀllda nÄgra av vÄra mest anvÀnda tabeller med rengjorda personuppgifter. Mer Àn 250 anvÀndare frÄn olika team, inklusive teknik, finans och marknadsföring, anvÀnde BigQuery. Nyligen genomförde de omkring 8 000 förfrÄgningar, vilket hanterade cirka 100 PB per mÄnad, utan att rÀkna med schemalagda förfrÄgningar. Efter att ha fÄtt mycket positiv feedback beslutade vi oss för att gÄ vidare och erbjuda BigQuery som en primÀr resurs för datainteraktion pÄ Twitter.
HÀr Àr en hög nivÄ av arkitekturdiagrammet för vÄrt datalager Google BigQuery.
Vi kopierar data frÄn lokala Hadoop-kluster till Google Cloud Storage (GCS) med hjÀlp av vÄrt interna verktyg Cloud Replicator. DÀrefter anvÀnder vi Apache Airflow för att skapa rörledningar som anvÀnder "" för att ladda data frÄn GCS till BigQuery. Vi anvÀnder Presto för att frÄga dataset Parquet eller Thrift-LZO i GCS. BQ Blaster Àr ett internt verktyg i Scalding för att ladda dataset HDFS Vertica och Thrift-LZO till BigQuery.
I de följande avsnitten kommer vi att diskutera vÄrt tillvÀgagÄngssÀtt och vÄra kunskaper om anvÀndarvÀnlighet, prestanda, datastyrning, systemens driftsÀkerhet och kostnad.
AnvÀndarvÀnlighet
Vi har upptĂ€ckt att det var lĂ€tt för anvĂ€ndarna att börja med BigQuery, eftersom det inte krĂ€vde programvaruinstallation och anvĂ€ndarna kunde fĂ„ Ă„tkomst via en intuitiv webbgrĂ€nssnitt. ĂndĂ„ behövde anvĂ€ndarna bekanta sig med vissa GCP-funktioner och dess koncept, inklusive resurser som projekt, dataset och tabeller. Vi har utvecklat utbildningsmaterial och handledningar för att hjĂ€lpa anvĂ€ndare att komma igĂ„ng. NĂ€r de fick en grundlĂ€ggande förstĂ„else blev det enkelt för anvĂ€ndarna att navigera i dataset, granska scheman och data i tabeller, utföra enkla förfrĂ„gningar och visualisera resultat i Data Studio.
VÄrt mÄl för datainmatningen i BigQuery var att sÀkerstÀlla en smidig inladdning av dataset HDFS eller GCS med ett klick. Vi övervÀgde (styrt Airflow), men vi kunne ikke bruke det pÄ grunn av vÄr sikkerhetsmodell «Domain Restricted Sharing» (les mer om dette i avsnittet «Datastyring» nedenfor). Vi eksperimenterte med Ä bruke Google Data Transfer Service (DTS) for Ä organisere lastoppgaver i BigQuery. Mens DTS ble satt opp raskt, var det ikke fleksibelt for Ä bygge pipelines med avhengigheter. For vÄr alfa-versjon opprettet vi vÄrt eget Apache Airflow-miljÞ i GCE og forbereder det til produksjon og muligheten til Ä stÞtte flere datakilder, som Vertica.
For Ä transformere data til BigQuery oppretter brukere enkle SQL-datapipelines ved hjelp av planlagte forespÞrseler. For komplekse flerstegs-pipelines med avhengigheter planlegger vi Ä bruke enten vÄr egen Airflow-infrastruktur eller Cloud Composer sammen med .
Performance
BigQuery er laget for generelle SQL-forespÞrseler som behandler store datamengder. Den er ikke designet for forespÞrseler med lav ventetid og hÞy gjennomstrÞmning, som kreves for transaksjonsdatabaser, eller for lav-latens analyse av tidsserier, implementert av . For interaktive analytiske forespÞrseler forventer brukerne vÄre en responstid pÄ under ett minutt. Vi mÄtte designe bruken av BigQuery slik at den oppfylte disse forventningene. For Ä sikre forutsigbar ytelse for vÄre brukere, brukte vi BigQuery-funksjonaliteten tilgjengelig for kunder med fast pris, som lar prosjektseierne reservere minimale slots for sine forespÞrseler. BigQuery er en enhet for beregningskraft som kreves for Ä utfÞre SQL-forespÞrseler.
Vi har analyserat mer Àn 800 förfrÄgningar som hanterar ungefÀr 1 TB data vardera och upptÀckte att den genomsnittliga exekveringstiden var 30 sekunder. Vi lÀrde oss ocksÄ att prestandan Àr starkt beroende av hur vÄr slot anvÀnds i olika projekt och uppgifter. Vi var tvungna att tydligt separera vÄra produktions- och ad hoc slot-reserver för att upprÀtthÄlla prestanda för produktionsanvÀndningssituationer och interaktiv analys. Detta pÄverkade i hög grad vÄr design för slot-reservering och projekt hierarki.
Om datastyrning, funktionalitet och kostnad för system kommer vi att prata mer om i de kommande dagarna i den andra delen av översĂ€ttningen, men just nu inbjuder vi alla intresserade till , dĂ€r man kan fĂ„ veta mer om kursen och Ă€ven stĂ€lla frĂ„gor till vĂ„r expert â Yegor Mateshchuk (Senior Data Engineer, MaximaTelecom).
LĂ€s mer:
KĂ€lla: habr.com
