Hej, Habr! Lige nu er der åbent for tilmelding til et nyt hold af kurset hos OTUS. . Forud for kursets start fortsætter vi med at dele nyttigt materiale med jer.
Datahåndtering
Stærk datahåndtering (Strong Data Governance) — en grundlæggende princip i Twitter Engineering. Da vi implementerer BigQuery på vores platform, fokuserer vi på dataopdagelse, adgangskontrol, sikkerhed og privatliv.
For dataopdagelse og -styring har vi udvidet vores datatilgangsniveau (Data Access Layer — ), så vi kan give værktøjer til både lokale data og data fra Google Cloud, hvilket giver vores brugere en ensartet grænseflade og API. Efterhånden som Google går mod offentligheden, vil vi inkludere det i vores projekter for at give brugerne funktioner som søgning på kolonner.
BigQuery gør det nemt at dele data og få adgang til dem, men vi var nødt til at kontrollere dette til en vis grad for at forhindre datalækage. Blandt andre værktøjer valgte vi to funktioner:
- : en beta-funktion, der forhindrer brugere i at dele BigQuery-datasets med brugere udenfor Twitter.
- : en kontrolmekanisme, der forhindrer datalækage og kræver, at brugerne har adgang til BigQuery fra kendte IP-adresser.
Vi implementerede krav til autentifikation, autorisation og revision (AAA) for at sikre sikkerheden på følgende måde:
- Autentifikation: vi brugte GCP-bruger-konti til ad hoc forespørgsler og servicekonti til arbejdskrav.
- Autorisation: vi krævede, at hvert dataset havde en ejer-servicekonto og en læsegruppe.
- Revision: vi eksporterede logs fra BigQuery stackdriver, som indeholdt detaljerede oplysninger om forespørgselsudførelse, til et BigQuery dataset for nem analyse.
For at sikre korrekt behandling af personlige data fra Twitter-brugere, skal vi registrere alle BigQuery-datasæt, annotere personlige data, sikre korrekt opbevaring og slette (rens) data, der er blevet slettet af brugerne.
Vi overvejede Google , der bruger maskinlæring til klassificering og redigering af fortrolige oplysninger, men vi besluttede at gå med manuel annotering af datasættet på grund af nøjagtigheden. Vi planlægger at bruge Data Loss Prevention API til at supplere brugerens annotering.
I Twitter har vi oprettet fire fortrolighedskategorier for datasæt i BigQuery, angivet her i rækkefølge efter følsomhed:
- Højsensitive datasæt er tilgængelige efter behov baseret på princippet om mindst privilegium. Hvert datasæt har en særskilt gruppe læsere, og vi vil overvåge brugen af individuelle konti.
- Mellemsensitive datasæt (envejs pseudonymer ved brug af saltet hashing) indeholder ikke personlige oplysninger (Personally Identifiable Information — PII) og er tilgængelige for en større gruppe ansatte. Dette er en god balance mellem fortrolighedshensyn og dataanvendelighed. Det giver ansatte mulighed for at udføre analyser som at beregne antallet af brugere, der har brugt en funktion, uden at kende de egentlige brugere.
- Lavfølsomme datasæt med al information, der identificerer brugeren. Dette er en god tilgang med hensyn til fortrolighed, men det kan ikke anvendes til bruger niveau analyse.
- Offentlige datasæt (udgivet uden for Twitter) er tilgængelige for alle Twitter-ansatte.
Hvad angår registreringen, brugte vi planlagte opgaver til at liste datasæt i BigQuery og registrere dem i Data Access Layer (), Twitter's metadata-lager. Brugerne vil annotere datasæt med fortrolighedsinformation samt angive opbevaringsperioden. Hvad angår rengøring, vurderer vi ydeevne og omkostninger ved to muligheder: 1. Rengøring af datasæt i GCS ved hjælp af værktøjer som Scalding, og upload af dem til BigQuery; 2. Brug af BigQuery DML-operatører. Vi vil sandsynligvis bruge en kombination af begge metoder for at imødekomme kravene fra forskellige grupper og data.
Systemfunktionalitet
Da BigQuery er en håndteret tjeneste, var der ikke behov for at involvere SRE-teamet hos Twitter i systemadministration eller vagttjeneste. Det var nemt at sikre stor kapacitet både til lagring og beregning. Vi kunne ændre slotreservationer ved at oprette billetter til Google Support. Vi har identificeret, at vi kunne forbedre for eksempel selvbetjeningen til slotfordeling og forbedre dashboardet til overvågning, og vi har sendt disse anmodninger til Google.
Omkostninger
Vores indledende analyse viste, at omkostningerne ved forespørgsler for BigQuery og Presto var på samme niveau. Vi købte slots til pris for at have stabile månedlige omkostninger i stedet for at betale pr. TB behandlede data. Denne beslutning var også baseret på brugerfeedback, som ikke ønskede at tænke på omkostningerne, før de udførte hver forespørgsel.
Lagring af data i BigQuery medførte omkostninger ud over omkostningerne ved GCS. Værktøjer som Scalding kræver datasæt i GCS, og for at få adgang til BigQuery måtte vi uploade de samme datasæt i BigQuery-format. . Vi arbejder på at forbinde Scalding med BigQuery-datasæt, hvilket vil fjerne behovet for at gemme datasæt både i GCS og BigQuery.
For sjældne tilfælde, der krævede sporadiske forespørgsler på titusinder af petabytes, besluttede vi, at det ikke var økonomisk effektivt at gemme datasæt i BigQuery, og vi brugte Presto til direkte adgang til datasæt i GCS. Til dette ser vi på BigQuery External Data Sources.
Næste skridt
Vi har bemærket stor interesse for BigQuery siden udgivelsen af alpha. Vi tilføjer flere datasæt og flere teams til BigQuery. Vi udvikler connectores til dataanalyseværktøjer som Scalding for at læse og skrive til BigQuery-lagerrum. Vi overvejer værktøjer som Looker og Apache Zeppelin til at skabe virksomhedens rapporter om kvalitet og noter ved hjælp af BigQuery-datasæt.
Samarbejdet med Google har været meget produktivt, og vi ser frem til at fortsætte og udvikle dette partnerskab. Vi har arbejdet sammen med Google for at implementere vores egen , så vi direkte kan sende anmodninger til Google. Nogle af dem, såsom BigQuery Parquet-lifteren, er allerede implementeret af Google.
Her er nogle af vores højt prioriterede funktionsanmodninger til Google:
- Værktøjer til nem modtagelse af data og støtte til LZO-Thrift-formatet.
- Timebaseret segmentering
- Forbedringer inden for adgangskontrol, såsom tabel-, række- og kolonnebaserede tilladelser.
- BigQuery med integration og støtte til Hive Metastore for LZO-Thrift-formatet.
- Forbedret datakatalogintegration i BigQuery-brugergrænsefladen
- Selvbetjening til distribution og overvågning af slots.
Konklusion
Demokratisering af dataanalyse, visualisering og maskinlæring på en sikker måde er en højprioritet for Data Platform-teamet. Vi har identificeret Google BigQuery og Data Studio som værktøjer, der kan hjælpe med at nå dette mål, og vi lancerede sidste år BigQuery Alpha for hele virksomheden.
Vi har fundet, at forespørgsler i BigQuery var enkle og effektive. Til modtagelse og transformation af data brugte vi Googles værktøjer til enkle pipelines, men til komplekse pipelines var vi nødt til at opbygge vores egen Airflow-infrastruktur. I forhold til datastyring opfylder BigQuery-tjenesterne for autentifikation, autorisation og revision vores behov. For at håndtere metadata og overholde fortrolighed havde vi brug for større fleksibilitet og måtte oprette vores egne systemer. BigQuery, som er en administreret tjeneste, var nem at betjene. Omkostningerne ved forespørgsler var sammenlignelige med eksisterende værktøjer. Omkostningerne ved datalagring i BigQuery var ud over omkostningerne til GCS.
Generelt fungerer BigQuery godt til generel SQL-analyse. Vi bemærker stor interesse for BigQuery, og vi arbejder på at overføre flere datamængder, tiltrække flere teams og skabe flere pipelines med BigQuery. I Twitter bruges forskellige data, der kræver en kombination af værktøjer som Scalding, Spark, Presto og Druid. Vi har til hensigt at fortsætte med at udvide vores dataanalyseværktøjer og give klare anbefalinger til vores brugere om, hvordan de bedst muligt kan udnytte vores tilbud.
Ord af taknemmelighed
Jeg vil gerne takke mine medforfattere og teamkammerater, Anju Dja og Will Pascucci, for deres fantastiske samarbejde og hårde arbejde på dette projekt. Jeg vil også takke ingeniørerne og lederne fra flere hold hos Twitter og Google, som hjalp os og brugerne af BigQuery hos Twitter, for deres værdifulde feedback.
Hvis du er interesseret i at arbejde med disse opgaver, så tjek vores i Data Platform-teamet.
Kilde: habr.com
