Hur Google BigQuery demokratiserade datanalys. Del 2

Hej, Habr! Just nu är anmälan till den nya omgången av kursen på OTUS öppen. „Data Engineer“. Inför kursstarten fortsätter vi att dela med oss av nyttig information.

Läs första delen

Datastyrning

Stark datastyrning (Strong Data Governance) är en grundläggande princip för Twitter Engineering. När vi implementerar BigQuery på vår plattform fokuserar vi på datadetektering, åtkomstkontroll, säkerhet och integritet.

För datadetektering och hantering har vi utökat vårt datatillgångslager (Data Access Layer — DAL), för att tillhandahålla verktyg för både lokala data och Google Cloud-data, vilket ger ett enhetligt gränssnitt och API för våra användare. När Google Data Catalog blir mer tillgänglig, kommer vi att inkludera den i våra projekt för att ge användare funktioner såsom sökning efter kolumner.

BigQuery gör det enkelt att dela och få åtkomst till data, men vi behövde kontrollera detta till viss del för att förhindra dataläckage. Bland andra verktyg valde vi två funktioner:

• Domänbegränsad delning: en beta-funktion som förhindrar användare från att dela BigQuery-dataset med användare utanför Twitter.
• VPC-tjänstkontroller: en kontrollmekanism som förhindrar dataläckage och kräver att användare får åtkomst till BigQuery från kända IP-adressintervall.

Vi har implementerat autentisering, auktorisering och revision (AAA) för säkerhet på följande sätt:

• Autentisering: vi har använt GCP-användarkonton för ad hoc-förfrågningar och tjänstekonton för arbetsförfrågningar.
• Auktorisering: vi kräver att varje dataset har ett tjänkontoinnehav och en läsargrupp.
• Revision: vi exporterade BigQuery:s stackdrivrutinsloggar, som innehöll detaljerad information om frågetillämpningar, till ett BigQuery-dataset för enkel analys.

För att säkerställa korrekt hantering av personuppgifter från Twitter-användare måste vi registrera alla BigQuery-datasets, annotera personuppgifter, säkerställa lämplig lagring och radera (städa) data som har tagits bort av användare.

Vi övervägde Google Cloud Data Loss Prevention API, som använder maskininlärning för att klassificera och redigera konfidentiella data, men beslutade att gå med manuell annotering av datamängden på grund av noggrannheten. Vi planerar att använda Data Loss Prevention API för att komplettera användarannoteringen.

På Twitter har vi skapat fyra kategorier av konfidentialitet för datamängder i BigQuery, listade här i ordning efter känslighet:

• Högkänsliga datamängder är tillgängliga efter behov baserat på principen om minimiåtkomst. Varje datamängd har en separat läsartgrupp, och vi kommer att övervaka användningen av individuella konton.
• Datamängder med medelkänslighet (enkelsidiga pseudonymer med saltade hash) innehåller ingen personlig information (Personally Identifiable Information – PII) och är tillgängliga för en större grupp anställda. Detta ger en bra balans mellan sekretessöverväganden och användbarhet. Det gör att anställda kan utföra analysuppgifter, såsom att räkna antalet användare som har använt en funktion, utan att veta vilka som är de verkliga användarna.
• Datamängder med låg känslighet innehåller all information som identifierar användaren. Detta är en bra metod ur sekretessynpunkt, men den kan inte användas för analys på användarnivå.
• Offentliga datamängder (utgivna utanför Twitter) är tillgängliga för alla Twitter-anställda.

När det kommer till registrering använde vi schemalagda uppgifter för att lista datamängder i BigQuery och registrera dem i Data Access Layer (DAL), Twitter's metadata-lager. Användare kommer att annotera datamängder med sekretessinformation samt specificera lagringstid. När det kommer till rensning utvärderar vi prestanda och kostnad för två alternativ: 1. Rensning av datamängder i GCS med hjälp av verktyg som Scalding och laddning av dem i BigQuery; 2. Användning av BigQuery DML-operatörer. Vi kommer troligen att använda en kombination av båda metoderna för att möta behoven hos olika grupper och data.

Systemets funktionalitet

Eftersom BigQuery är en hanterad tjänst behövde SRE-teamet på Twitter inte kopplas in för att hantera systemen eller utföra driftuppgifter. Det var enkelt att säkerställa hög kapacitet både för lagring och beräkningar. Vi kunde justera slotreservationen genom att skapa biljetter till Google-supporten. Vi identifierade att vi kunde förbättra, till exempel självbetjäningen för slottdistribution och förbättra instrumentpanelen för övervakning, och vi vidarebefordrade dessa förfrågningar till Google.

Kostnad

Vår preliminära analys visade att kostnaden för förfrågningar för BigQuery och Presto var på samma nivå. Vi köpte slots till ett fast pris för att ha en stabil månadsavgift istället för att betala per begäran per TB bearbetad data. Detta beslut baserades också på feedback från användare som inte ville tänka på kostnaderna innan de gjorde varje förfrågning.

Datlagring i BigQuery medförde kostnader utöver kostnaderna för GCS. Verktyg som Scalding kräver att dataset finns i GCS, och för att få tillgång till BigQuery var vi tvungna att ladda upp samma dataset i BigQuery-format. Capacitor. Vi arbetar med att koppla samman Scalding med BigQuery-dataset, vilket skulle eliminera behovet av att lagra dataset både i GCS och BigQuery.

För sällsynta fall som krävde sällsynta förfrågningar på tiotals petabyte beslutade vi att lagring av dataset i BigQuery inte var kostnadseffektivt och använde Presto för direkt åtkomst till dataset i GCS. För detta ser vi på BigQuery External Data Sources.

Följande steg

Vi har noterat stort intresse för BigQuery sedan alfa-lanseringen. Vi lägger till fler dataset och fler team i BigQuery. Vi utvecklar kopplingar för dataanalysverktyg som Scalding för att läsa och skriva till BigQuery-lagringen. Vi överväger verktyg som Looker och Apache Zeppelin för att skapa företagsrapporter om kvalitet och anteckningar med hjälp av BigQuery-dataset.

Samarbetet med Google har varit mycket produktivt, och vi ser fram emot att fortsätta och utveckla detta partnerskap. Vi har arbetat med Google för att implementera vår egen Partner Issue Tracker, för att direkt skicka förfrågningar till Google. Vissa av dessa, som BigQuery Parquet-laddaren, har redan implementerats av Google.

Här är några av våra högprioriterade funktionsförfrågningar för Google:

• Verktyg för smidig datainhämtning och stöd för LZO-Thrift-formatet.
• Timbaserad segmentering
• Förbättringar inom åtkomstkontroll, såsom behörigheter på tabell-, rad- och kolumnnivå.
• BigQuery Externa datakällor med integration och stöd för Hive Metastore för LZO-Thrift-formatet.
• Förbättrad integration av datakatalog i BigQuery-användargränssnittet
• Självbetjäning för distribution och övervakning av slots.

Slutsats

Demokratisering av dataanalys, visualisering och maskininlärning på ett säkert sätt är en högsta prioritet för Data Platform-teamet. Vi har identifierat Google BigQuery och Data Studio som verktyg som kan hjälpa till att nå detta mål, och vi släppte BigQuery Alpha för hela företaget förra året.

Vi har funnit att förfrågningar i BigQuery var enkla och effektiva. För datainhämtning och transformation använde vi Googles verktyg för enkla rörledningar, men för mer komplexa rörledningar var vi tvungna att skapa vår egen Airflow-infrastruktur. Vad gäller datastyrning uppfyller BigQuerys tjänster för autentisering, auktorisering och granskning våra behov. För hantering av metadata och sekretesskrav behövde vi stor flexibilitet och var tvungna att bygga egna system. BigQuery, som en hanterad tjänst, var lätt att använda. Kostnaderna för förfrågningar var jämförbara med befintliga verktyg. Datastore i BigQuery medförde kostnader utöver kostnaderna för GCS.

Överlag fungerar BigQuery bra för allmän SQL-analys. Vi noterar stort intresse för BigQuery och arbetar med att migrera fler dataset, attrahera fler team och skapa fler rörledningar med BigQuery. På Twitter används olika data som kräver en kombination av verktyg som Scalding, Spark, Presto och Druid. Vi avser att fortsätta utveckla våra analysverktyg och ge klara rekommendationer till våra användare om hur man bäst använder våra erbjudanden.

Tackord

Jag vill tacka mina medförfattare och teamkollegor, Anju Dja och Will Pascucci, för deras fantastiska samarbete och hårda arbete i detta projekt. Jag vill också tacka ingenjörer och chefer från flera team på Twitter och Google som hjälpte oss och användarna av BigQuery på Twitter genom att ge värdefull feedback.

Om du är intresserad av att arbeta med dessa uppgifter, ta en titt på våra lediga tjänster i Data Platform-teamet.

Datakvalitet i DWH – konsistens i datalagringen

Källa: habr.com