Hej Habr! Anmälan till en ny kursström är öppen på OTUS just nu . I väntan på kursstart fortsätter vi att dela användbart material med dig.
Datahantering
Stark datastyrning är en kärnan i Twitter Engineering. När vi implementerar BigQuery i vår plattform fokuserar vi på dataupptäckt, åtkomstkontroll, säkerhet och integritet.
För att upptäcka och hantera data har vi utökat vårt dataåtkomstlager till ) för att tillhandahålla verktyg för både lokal och Google Cloud-data, vilket ger ett enda gränssnitt och API för våra användare. Som Google går mot allmän tillgänglighet kommer vi att inkludera det i våra projekt för att ge användarna funktioner som kolumnsökning.
BigQuery gör det enkelt att dela och komma åt data, men vi behövde ha viss kontroll över detta för att förhindra dataexfiltrering. Bland andra verktyg valde vi två funktioner:
- : Betafunktion för att förhindra användare från att dela BigQuery-datauppsättningar med användare utanför Twitter.
- : En kontroll som förhindrar dataexfiltrering och kräver att användare får åtkomst till BigQuery från kända IP-adressintervall.
Vi har implementerat krav på autentisering, auktorisering och revision (AAA) för säkerhet enligt följande:
- Autentisering: Vi använde GCP-användarkonton för ad hoc-förfrågningar och tjänstekonton för produktionsförfrågningar.
- Auktorisering: Vi krävde att varje datauppsättning hade ett ägartjänstkonto och en läsargrupp.
- Granskning: Vi exporterade BigQuery stackdriver-loggar, som innehöll detaljerad information om körning av frågor, till en BigQuery-datauppsättning för enkel analys.
För att säkerställa att Twitter-användares personuppgifter hanteras korrekt måste vi registrera alla BigQuery-datauppsättningar, kommentera personuppgifter, upprätthålla korrekt lagring och radera (skrapa) data som har raderats av användare.
Vi tittade på Google , som använder maskininlärning för att klassificera och redigera känslig data, men bestämde sig för att manuellt kommentera datasetet på grund av noggrannhet. Vi planerar att använda Data Loss Prevention API för att utöka den anpassade annoteringen.
På Twitter har vi skapat fyra sekretesskategorier för datauppsättningar i BigQuery, listade här i fallande känslighetsordning:
- Mycket känsliga datamängder görs tillgängliga vid behov baserat på principen om minsta privilegium. Varje datamängd har en separat grupp av läsare, och vi kommer att spåra användningen av enskilda konton.
- Datauppsättningar med medelhög känslighet (envägs-pseudonymer som använder saltad hashing) innehåller inte personligt identifierbar information (PII) och är tillgängliga för en större grupp anställda. Detta är en bra balans mellan integritetsproblem och datanytta. Detta gör att anställda kan utföra analysuppgifter, som att beräkna antalet användare som använt en funktion, utan att veta vilka de verkliga användarna är.
- Datauppsättningar med låg känslighet med all användaridentifierande information. Detta är ett bra tillvägagångssätt ur ett integritetsperspektiv, men kan inte användas för analys på användarnivå.
- Offentliga datauppsättningar (släppta utanför Twitter) är tillgängliga för alla Twitter-anställda.
När det gäller loggning använde vi schemalagda uppgifter för att räkna upp BigQuery-datauppsättningar och registrera dem med Data Access Layer (), Twitter-metadataförråd. Användare kommer att kommentera datauppsättningar med sekretessinformation och även ange en lagringsperiod. När det gäller rengöring utvärderar vi prestanda och kostnad för två alternativ: 1. Rensa datauppsättningar i GCS med hjälp av verktyg som Scalding och ladda dem i BigQuery; 2. Använda BigQuery DML-satser. Vi kommer sannolikt att använda en kombination av båda metoderna för att möta kraven från olika grupper och data.
Systemets funktionalitet
Eftersom BigQuery är en hanterad tjänst, fanns det inget behov av att involvera Twitters SRE-team i systemhantering eller skrivbordsuppgifter. Det var lätt att ge mer kapacitet för både lagring och datoranvändning. Vi kan ändra platsreservationen genom att skapa en biljett med Googles support. Vi identifierade områden som skulle kunna förbättras, till exempel självbetjäningsplatstilldelning och förbättringar av instrumentpanelen för övervakning, och skickade in dessa förfrågningar till Google.
Kostnad
Vår preliminära analys visade att frågekostnaderna för BigQuery och Presto låg på samma nivå. Vi köpte slots för pris för att ha en stabil månadskostnad istället för betalning per TB bearbetad data. Detta beslut baserades också på feedback från användare som inte ville tänka på kostnader innan de gjorde varje förfrågan.
Att lagra data i BigQuery medförde kostnader utöver GCS-kostnader. Verktyg som Scalding kräver datauppsättningar i GCS, och för att komma åt BigQuery var vi tvungna att ladda samma datauppsättningar i BigQuery-format . Vi arbetar på en Scalding-anslutning till BigQuery-datauppsättningar som eliminerar behovet av att lagra datauppsättningar i både GCS och BigQuery.
För sällsynta fall som krävde sällsynta frågor på tiotals petabyte beslutade vi att lagring av datauppsättningar i BigQuery inte var kostnadseffektivt och använde Presto för att få direkt åtkomst till datauppsättningar i GCS. För att göra detta tittar vi på BigQuery externa datakällor.
Nästa steg
Vi har sett ett stort intresse för BigQuery sedan alfasläppet. Vi lägger till fler datauppsättningar och fler kommandon till BigQuery. Vi utvecklar kopplingar för dataanalysverktyg som Scalding för att läsa och skriva till BigQuery-lagring. Vi tittar på verktyg som Looker och Apache Zeppelin för att skapa rapporter och anteckningar av företagskvalitet med hjälp av BigQuery-datauppsättningar.
Vårt samarbete med Google har varit mycket produktivt och vi är glada över att kunna fortsätta och utveckla detta partnerskap. Vi arbetade med Google för att implementera vår egen för att skicka frågor direkt till Google. Några av dem, som BigQuery Parkettlastaren, har redan implementerats av Google.
Här är några av våra högprioriterade funktionsförfrågningar för Google:
- Verktyg för bekväm datamottagning och stöd för LZO-Thrift-formatet.
- Timsegmentering
- Förbättringar av åtkomstkontroll som tabell-, rad- och kolumnnivåbehörigheter.
- BigQuery med Hive Metastore-integration och stöd för LZO-Thrift-formatet.
- Förbättrad datakatalogintegrering i BigQuerys användargränssnitt
- Självbetjäning för slottilldelning och övervakning.
Slutsats
Att demokratisera dataanalys, visualisering och maskininlärning på ett säkert sätt är en högsta prioritet för Data Platform-teamet. Vi identifierade Google BigQuery och Data Studio som verktyg som kan hjälpa till att uppnå detta mål och släppte BigQuery Alpha för hela företaget förra året.
Vi fann att frågor i BigQuery var enkla och effektiva. Vi använde Googles verktyg för att mata in och transformera data för enkla pipelines, men för komplexa pipelines var vi tvungna att bygga vårt eget Airflow-ramverk. I datahanteringsutrymmet möter BigQuerys tjänster för autentisering, auktorisering och granskning våra behov. För att hantera metadata och upprätthålla sekretess behövde vi mer flexibilitet och var tvungna att bygga våra egna system. BigQuery, som är en hanterad tjänst, var lätt att använda. Frågekostnader liknade befintliga verktyg. Att lagra data i BigQuery medför kostnader utöver GCS-kostnader.
Sammantaget fungerar BigQuery bra för generell SQL-analys. Vi ser ett stort intresse för BigQuery, och vi arbetar med att migrera fler datamängder, anställa fler team och bygga fler pipelines med BigQuery. Twitter använder en mängd olika data som kräver en kombination av verktyg som Scalding, Spark, Presto och Druid. Vi avser att fortsätta att stärka våra dataanalysverktyg och ge tydlig vägledning till våra användare om hur vi bäst använder våra erbjudanden.
Ord av tacksamhet
Jag vill tacka mina medförfattare och lagkamrater, Anju Jha och Will Pascucci, för deras fantastiska samarbete och hårda arbete med detta projekt. Jag skulle också vilja tacka ingenjörerna och cheferna från flera team på Twitter och Google som hjälpte oss och BigQuery-användarna på Twitter som gav värdefull feedback.
Om du är intresserad av att arbeta med dessa problem, kolla in vår i Dataplattformsteamet.
Källa: will.com