Hej, Habr! Tilmelding til en ny kursusstrøm er åben lige nu hos OTUS . I forventning om kursusstart deler vi fortsat brugbart materiale med dig.
Datastyring
Strong Data Governance er en kerne af Twitter Engineering. Når vi implementerer BigQuery i vores platform, fokuserer vi på dataopdagelse, adgangskontrol, sikkerhed og privatliv.
For at opdage og administrere data har vi udvidet vores dataadgangslag til ) for at levere værktøjer til både lokale og Google Cloud-data, hvilket giver en enkelt grænseflade og API til vores brugere. Som Google bevæger sig mod generel tilgængelighed, vil vi inkludere det i vores projekter for at give brugerne funktioner såsom kolonnesøgning.
BigQuery gør det nemt at dele og få adgang til data, men vi var nødt til at have en vis kontrol over dette for at forhindre dataeksfiltrering. Blandt andre værktøjer valgte vi to funktioner:
- : Betafunktion til at forhindre brugere i at dele BigQuery-datasæt med brugere uden for Twitter.
- : En kontrol, der forhindrer dataeksfiltrering og kræver, at brugere får adgang til BigQuery fra kendte IP-adresseområder.
Vi har implementeret godkendelses-, autorisations- og revisionskrav (AAA) for sikkerhed som følger:
- Godkendelse: Vi brugte GCP-brugerkonti til ad hoc-anmodninger og servicekonti til produktionsanmodninger.
- Godkendelse: Vi krævede, at hvert datasæt havde en ejerservicekonto og en læsegruppe.
- Revision: Vi eksporterede BigQuery stackdriver-logfiler, som indeholdt detaljerede oplysninger om udførelse af forespørgsler, til et BigQuery-datasæt for nem analyse.
For at sikre, at Twitter-brugeres personlige data håndteres korrekt, skal vi registrere alle BigQuery-datasæt, kommentere personlige data, opretholde korrekt opbevaring og slette (skrabe) data, der er blevet slettet af brugere.
Vi kiggede på Google , som bruger maskinlæring til at klassificere og redigere følsomme data, men besluttede sig for manuelt at annotere datasættet på grund af nøjagtigheden. Vi planlægger at bruge Data Loss Prevention API til at udvide den tilpassede annotering.
På Twitter har vi oprettet fire privatlivskategorier for datasæt i BigQuery, som er anført her i faldende følsomhedsrækkefølge:
- Meget følsomme datasæt stilles til rådighed efter behov baseret på princippet om mindste privilegium. Hvert datasæt har en separat gruppe af læsere, og vi sporer brugen af individuelle konti.
- Datasæt med medium følsomhed (en-vejs pseudonymer ved hjælp af saltet hashing) indeholder ikke personligt identificerbare oplysninger (PII) og er tilgængelige for en større gruppe medarbejdere. Dette er en god balance mellem privatlivsproblemer og dataværktøj. Dette giver medarbejderne mulighed for at udføre analyseopgaver, såsom at beregne antallet af brugere, der brugte en funktion, uden at vide, hvem de rigtige brugere er.
- Datasæt med lav følsomhed med alle brugeridentificerende oplysninger. Dette er en god tilgang fra et privatlivsperspektiv, men kan ikke bruges til analyse på brugerniveau.
- Offentlige datasæt (udgivet uden for Twitter) er tilgængelige for alle Twitter-medarbejdere.
Med hensyn til logning brugte vi planlagte opgaver til at opregne BigQuery-datasæt og registrere dem med Data Access Layer (), Twitter-metadatalager. Brugere vil annotere datasæt med privatlivsoplysninger og også angive en opbevaringsperiode. Hvad angår rengøring, evaluerer vi ydeevnen og omkostningerne ved to muligheder: 1. Rensning af datasæt i GCS ved hjælp af værktøjer som Scalding og indlæsning af dem i BigQuery; 2. Brug af BigQuery DML-sætninger. Vi vil sandsynligvis bruge en kombination af begge metoder for at opfylde kravene fra forskellige grupper og data.
System funktionalitet
Fordi BigQuery er en administreret tjeneste, var der ingen grund til at involvere Twitters SRE-team i systemadministration eller skrivebordsopgaver. Det var nemt at give mere kapacitet til både lagring og databehandling. Vi kunne ændre pladsreservationen ved at oprette en billet med Google-support. Vi identificerede områder, der kunne forbedres, såsom selvbetjeningspladsallokering og betjeningspanelforbedringer til overvågning, og indsendte disse anmodninger til Google.
Omkostninger
Vores foreløbige analyse viste, at forespørgselsomkostningerne for BigQuery og Presto var på samme niveau. Vi købte slots til pris for at have en stabil månedlig omkostning i stedet for betaling pr. TB behandlede data. Denne beslutning var også baseret på feedback fra brugere, som ikke ønskede at tænke på omkostningerne, før de fremsatte hver anmodning.
Lagring af data i BigQuery medførte omkostninger ud over GCS-omkostninger. Værktøjer som Scalding kræver datasæt i GCS, og for at få adgang til BigQuery var vi nødt til at indlæse de samme datasæt i BigQuery-format . Vi arbejder på en Scalding-forbindelse til BigQuery-datasæt, der vil eliminere behovet for at gemme datasæt i både GCS og BigQuery.
I sjældne tilfælde, der krævede sjældne forespørgsler på snesevis af petabyte, besluttede vi, at lagring af datasæt i BigQuery ikke var omkostningseffektivt og brugte Presto til at få direkte adgang til datasæt i GCS. For at gøre dette ser vi på BigQuerys eksterne datakilder.
Næste trin
Vi har set stor interesse for BigQuery siden alfa-udgivelsen. Vi tilføjer flere datasæt og flere kommandoer til BigQuery. Vi udvikler connectors til dataanalyseværktøjer som Scalding til at læse og skrive til BigQuery-lagring. Vi kigger på værktøjer som Looker og Apache Zeppelin til at oprette rapporter og noter af virksomhedskvalitet ved hjælp af BigQuery-datasæt.
Vores samarbejde med Google har været meget produktivt, og vi er glade for at fortsætte og udvikle dette partnerskab. Vi arbejdede sammen med Google om at implementere vores eget at sende forespørgsler direkte til Google. Nogle af dem, såsom BigQuery Parket loader, er allerede blevet implementeret af Google.
Her er nogle af vores højprioriterede funktionsanmodninger til Google:
- Værktøjer til bekvem datamodtagelse og understøttelse af LZO-Thrift-formatet.
- Timelig segmentering
- Adgangskontrolforbedringer såsom tilladelser på tabel-, række- og kolonneniveau.
- BigQuery med Hive Metastore-integration og understøttelse af LZO-Thrift-formatet.
- Forbedret datakatalogintegration i BigQuery-brugergrænsefladen
- Selvbetjening til slottildeling og overvågning.
Konklusion
Demokratisering af dataanalyse, visualisering og maskinlæring på en sikker måde er en topprioritet for Data Platform-teamet. Vi identificerede Google BigQuery og Data Studio som værktøjer, der kunne hjælpe med at nå dette mål, og udgav BigQuery Alpha for hele virksomheden sidste år.
Vi fandt, at forespørgsler i BigQuery var enkle og effektive. Vi brugte Google-værktøjer til at indtage og transformere data til simple pipelines, men til komplekse pipelines var vi nødt til at bygge vores egen Airflow-ramme. I dataadministrationsområdet opfylder BigQuerys tjenester til godkendelse, autorisation og revision vores behov. For at administrere metadata og bevare privatlivets fred havde vi brug for mere fleksibilitet og skulle bygge vores egne systemer. BigQuery, som er en administreret tjeneste, var nem at bruge. Forespørgselsomkostninger svarede til eksisterende værktøjer. Lagring af data i BigQuery medfører omkostninger ud over GCS-omkostninger.
Generelt fungerer BigQuery godt til generel SQL-analyse. Vi oplever stor interesse for BigQuery, og vi arbejder på at migrere flere datasæt, ansætte flere teams og bygge flere pipelines med BigQuery. Twitter bruger en række data, der kræver en kombination af værktøjer såsom Scalding, Spark, Presto og Druid. Vi agter at fortsætte med at styrke vores dataanalyseværktøjer og give klar vejledning til vores brugere om, hvordan vi bedst bruger vores tilbud.
Ord af taknemmelighed
Jeg vil gerne takke mine medforfattere og holdkammerater, Anju Jha og Will Pascucci, for deres gode samarbejde og hårde arbejde på dette projekt. Jeg vil også gerne takke ingeniørerne og lederne fra flere teams hos Twitter og Google, som hjalp os og BigQuery-brugerne på Twitter, som gav værdifuld feedback.
Hvis du er interesseret i at arbejde med disse problemer, så tjek vores i Data Platform-teamet.
Kilde: www.habr.com