Hej Habr! Anmälan till en ny kursström är öppen på OTUS just nu . I väntan på kursstart har vi traditionellt förberett en översättning av intressant material åt dig.
Varje dag besöker över hundra miljoner människor Twitter för att ta reda på vad som händer i världen och diskutera det. Varje tweet och alla andra användaråtgärder genererar en händelse som är tillgänglig för intern dataanalys inom Twitter. Hundratals anställda analyserar och visualiserar denna data, och att förbättra deras upplevelse är en högsta prioritet för Twitter Data Platform-teamet.
Vi anser att användare med ett brett spektrum av teknisk kompetens ska kunna hitta data och ha tillgång till väl fungerande SQL-baserade analys- och visualiseringsverktyg. Detta skulle göra det möjligt för en helt ny grupp av mindre tekniska användare, inklusive dataanalytiker och produktchefer, att extrahera insikter från datan, vilket gör det möjligt för dem att bättre förstå och använda Twitters kraft. Det är så vi demokratiserar dataanalys på Twitter.
I takt med att 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. Det finns dock fortfarande utrymme för förbättringar. Aktuella verktyg som Scalding kräver programmeringserfarenhet. SQL-baserade analysverktyg som Presto och Vertica har prestandaproblem i stor skala. Vi har också problem med att distribuera data över flera system utan konstant tillgång till det.
Förra året meddelade vi , inom vilken vi överför delar av vår på Google Cloud Platform (GCP). Vi drog slutsatsen att Google Cloud-verktyg kan hjälpa oss i våra initiativ för att demokratisera analys, visualisering och maskininlärning på Twitter:
- : företagsdatalager med SQL-motorbaserat , som är känd för sin snabbhet, enkelhet och klarar av .
- visualiseringsverktyg för big data med samarbetsfunktioner som Google Docs.
I den här artikeln kommer du att lära dig om vår erfarenhet av dessa verktyg: vad vi har gjort, vad vi har lärt oss och vad vi kommer att göra härnäst. Vi kommer nu att fokusera på batch och interaktiv analys. Realtidsanalys kommer att diskuteras i nästa artikel.
Historien om datalager på Twitter
Innan du dyker in i BigQuery är det värt att kort berätta historien om datalager på Twitter. 2011 gjordes dataanalys på Twitter i Vertica och Hadoop. För att skapa MapReduce Hadoop-jobb använde vi Pig. 2012 ersatte vi Pig med Scalding, som hade ett Scala API med fördelar som möjligheten att skapa komplexa pipelines och enkel testning. Men för många dataanalytiker och produktchefer som var mer bekväma med att arbeta med SQL var det en ganska brant inlärningskurva. Runt 2016 började vi använda Presto som vårt SQL-gränssnitt för Hadoop-data. Spark erbjöd ett Python-gränssnitt som gör det till ett bra val för ad hoc-datavetenskap och maskininlärning.
Sedan 2018 har vi använt följande verktyg för dataanalys och visualisering:
- skållning för produktionslinjer
- 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 låg interaktiv, utforskande och låg latensåtkomst till tidsseriemätningar
- Tableau, Zeppelin och Pivot för datavisualisering
Vi har upptäckt att även om dessa verktyg erbjuder mycket kraftfulla funktioner, har vi haft svårt att göra dessa funktioner tillgängliga för en bredare publik på Twitter. Genom att utöka vår plattform med Google Cloud fokuserar vi på att förenkla våra analysverktyg för hela Twitter.
Googles BigQuery Data Warehouse
Flera team på Twitter har redan inkluderat BigQuery i några av sina produktionspipelines. Med hjälp av deras erfarenhet började vi utvärdera möjligheterna med BigQuery för alla Twitter-användningsfall. Vårt mål var att erbjuda BigQuery till hela företaget och att standardisera och stödja det inom Data Platform toolkit. Detta var svårt av många anledningar. Vi behövde utveckla en infrastruktur för att tillförlitligt ta emot stora mängder data, stödja företagsomfattande datahantering, säkerställa korrekt åtkomstkontroll och säkerställa kundernas integritet. Vi var också tvungna att skapa system för resursallokering, övervakning och återkrav så att teamen kunde använda BigQuery effektivt.
I november 2018 släppte vi en alfaversion av BigQuery och Data Studio för hela företaget. Vi har erbjudit några av våra mest använda personliga data-rensade kalkylblad till Twitter-personal. BigQuery har använts av över 250 användare från olika team inklusive teknik, ekonomi och marknadsföring. Senast körde de cirka 8 100 förfrågningar, bearbetade cirka XNUMX PB per månad, utan att räkna med schemalagda förfrågningar. Efter att ha fått mycket positiv feedback bestämde vi oss för att gå vidare och erbjuda BigQuery som den primära resursen för att interagera med data på Twitter.
Här är ett diagram över högnivåarkitekturen i vårt Google BigQuery-datalager.
Vi kopierar data från lokala Hadoop-kluster till Google Cloud Storage (GCS) med det interna Cloud Replicator-verktyget. Vi använder sedan Apache Airflow för att skapa pipelines som använder "» för att ladda data från GCS till BigQuery. Vi använder Presto för att fråga Parquet- eller Thrift-LZO-datauppsättningar i GCS. BQ Blaster är ett internt skållningsverktyg för att ladda HDFS Vertica och Thrift-LZO-datauppsättningar i BigQuery.
I följande avsnitt kommer vi att diskutera vårt tillvägagångssätt och vår expertis när det gäller användarvänlighet, prestanda, datahantering, systemtillstånd och kostnader.
Användarvänlighet
Vi upptäckte att det var lätt för användare att komma igång med BigQuery eftersom det inte krävde någon programvaruinstallation och användare kunde komma åt det via ett intuitivt webbgränssnitt. Användare behövde dock bli bekanta med några av GCP-funktionerna och koncepten, inklusive resurser som projekt, datauppsättningar och tabeller. Vi har utvecklat tutorials och tutorials för att hjälpa användare att komma igång. Med en grundläggande förståelse är det lätt för användare att navigera i dataset, visa schema- och tabelldata, köra enkla frågor och visualisera resultat i Data Studio.
Vårt mål med datainmatning i BigQuery var att ge sömlös laddning av HDFS- eller GCS-datauppsättningar med ett enda klick. Vi övervägde (hanteras av Airflow) men kunde inte använda det på grund av vår "Domain Restricted Sharing" säkerhetsmodell (mer om detta i avsnittet Datahantering nedan). Vi experimenterade med att använda Google Data Transfer Service (DTS) för att organisera BigQuery-laddningsuppgifter. Även om DTS var snabb att installera, var den inte flexibel för att bygga pipelines med beroenden. För vår alfa-release har vi skapat vår egen Apache Airflow-miljö i GCE och förbereder den för produktion och möjligheten att stödja fler datakällor som Vertica.
För att omvandla data till BigQuery skapar användare enkla SQL-datapipelines med hjälp av schemalagda frågor. För komplexa flerstegspipelines med beroenden planerar vi att använda antingen vårt eget Airflow-ramverk eller Cloud Composer tillsammans med .
Производительность
BigQuery är designat för allmänna SQL-frågor som bearbetar stora mängder data. Den är inte utformad för den låg latens, höga genomströmningsförfrågningar som krävs av en transaktionsdatabas, eller den implementerade analysen av tidsserier med låg latens . För interaktiva analytiska frågor förväntar våra användare en svarstid på mindre än en minut. Vi var tvungna att utforma användningen av BigQuery för att möta dessa förväntningar. För att tillhandahålla förutsägbar prestanda för våra användare har vi använt BigQuery-funktionalitet, som är tillgänglig för kunder till en fast avgift, vilket gör att projektägare kan reservera minimiplatser för sina önskemål. BigQuery är en enhet för datorkraft som krävs för att exekvera SQL-frågor.
Vi analyserade över 800 frågor som bearbetade cirka 1 TB data var och fann att den genomsnittliga exekveringstiden var 30 sekunder. Vi lärde oss också att prestanda är starkt beroende av användningen av vår slot i olika projekt och uppgifter. Vi var tvungna att tydligt separera våra produktions- och ad hoc-slotreserver för att upprätthålla prestanda för produktionsanvändningsfall och interaktiv analys. Detta påverkade i hög grad vår design för platsreservationer och projekthierarkier.
Vi kommer att prata om datahantering, funktionalitet och systemkostnader under de kommande dagarna i den andra delen av översättningen, och nu uppmanar vi alla att , där du kan lära dig mer om kursen, samt ställa frågor till vår expert - Egor Mateshuk (Senior Data Engineer, MaximaTelecom).
Läs mer:
Källa: will.com