Hei, Habr! Påmelding til en ny kursstrøm er åpen akkurat nå på OTUS . I påvente av kursstart fortsetter vi å dele nyttig materiale med deg.
Dataledelse
Sterk datastyring er et kjerneprinsipp i Twitter Engineering. Når vi implementerer BigQuery i plattformen vår, fokuserer vi på dataoppdagelse, tilgangskontroll, sikkerhet og personvern.
For å oppdage og administrere data har vi utvidet datatilgangslaget vårt til ) for å tilby verktøy for både lokale og Google Cloud-data, og tilby ett enkelt grensesnitt og API for brukerne våre. Som Google beveger seg mot generell tilgjengelighet, vil vi inkludere det i våre prosjekter for å gi brukerne funksjoner som kolonnesøk.
BigQuery gjør det enkelt å dele og få tilgang til data, men vi måtte ha litt kontroll over dette for å forhindre dataeksfiltrering. Blant andre verktøy valgte vi to funksjoner:
- : Betafunksjon for å hindre brukere i å dele BigQuery-datasett med brukere utenfor Twitter.
- : En kontroll som forhindrer dataeksfiltrering og krever at brukere får tilgang til BigQuery fra kjente IP-adresseområder.
Vi har implementert krav til autentisering, autorisasjon og revisjon (AAA) for sikkerhet som følger:
- Autentisering: Vi brukte GCP-brukerkontoer for ad hoc-forespørsler og tjenestekontoer for produksjonsforespørsler.
- Autorisasjon: Vi krevde at hvert datasett skulle ha en eiertjenestekonto og en lesergruppe.
- Revisjon: Vi eksporterte BigQuery stackdriver-logger, som inneholdt detaljert informasjon om utførelse av spørringer, til et BigQuery-datasett for enkel analyse.
For å sikre at Twitter-brukeres personopplysninger håndteres på riktig måte, må vi registrere alle BigQuery-datasett, kommentere personlige data, opprettholde riktig lagring og slette (skrape) data som har blitt slettet av brukere.
Vi så på Google , som bruker maskinlæring for å klassifisere og redigere sensitive data, men bestemte seg for å manuelt kommentere datasettet på grunn av nøyaktighet. Vi planlegger å bruke Data Loss Prevention API for å utvide den egendefinerte merknaden.
På Twitter har vi laget fire personvernkategorier for datasett i BigQuery, oppført her i synkende sensitivitetsrekkefølge:
- Svært sensitive datasett gjøres tilgjengelig etter behov basert på prinsippet om minste privilegium. Hvert datasett har en egen gruppe lesere, og vi vil spore bruk av individuelle kontoer.
- Datasett med middels sensitivitet (enveis pseudonymer som bruker saltet hashing) inneholder ikke personlig identifiserbar informasjon (PII) og er tilgjengelig for en større gruppe ansatte. Dette er en god balanse mellom personvernhensyn og dataverktøy. Dette lar ansatte utføre analyseoppgaver, for eksempel å beregne antall brukere som brukte en funksjon, uten å vite hvem de virkelige brukerne er.
- Datasett med lav sensitivitet med all brukeridentifikasjonsinformasjon. Dette er en god tilnærming fra et personvernperspektiv, men kan ikke brukes til analyser på brukernivå.
- Offentlige datasett (utgitt utenfor Twitter) er tilgjengelige for alle Twitter-ansatte.
Når det gjelder logging, brukte vi planlagte oppgaver til å telle opp BigQuery-datasett og registrere dem med datatilgangslaget (), Twitter-metadatalager. Brukere vil kommentere datasett med personverninformasjon og spesifisere også en oppbevaringsperiode. Når det gjelder rengjøring, evaluerer vi ytelsen og kostnadene for to alternativer: 1. Rensing av datasett i GCS ved hjelp av verktøy som Scalding og lasting av dem i BigQuery; 2. Bruke BigQuery DML-setninger. Vi vil sannsynligvis bruke en kombinasjon av begge metodene for å møte kravene til ulike grupper og data.
Systemfunksjonalitet
Fordi BigQuery er en administrert tjeneste, var det ikke nødvendig å involvere Twitters SRE-team i systemadministrasjon eller skrivebordsoppgaver. Det var enkelt å gi mer kapasitet til både lagring og databehandling. Vi kan endre plassreservasjonen ved å opprette en billett med Googles brukerstøtte. Vi identifiserte områder som kunne forbedres, for eksempel selvbetjent plasstildeling og dashbordforbedringer for overvåking, og sendte disse forespørslene til Google.
Koste
Vår foreløpige analyse viste at spørringskostnadene for BigQuery og Presto var på samme nivå. Vi kjøpte spilleautomater for pris for å ha en stabil månedlig kostnad i stedet for betaling per TB behandlede data. Denne avgjørelsen var også basert på tilbakemeldinger fra brukere som ikke ønsket å tenke på kostnadene før hver forespørsel.
Lagring av data i BigQuery ga kostnader i tillegg til GCS-kostnader. Verktøy som Scalding krever datasett i GCS, og for å få tilgang til BigQuery måtte vi laste de samme datasettene inn i BigQuery-format . Vi jobber med en Scalding-tilkobling til BigQuery-datasett som vil eliminere behovet for å lagre datasett i både GCS og BigQuery.
For sjeldne tilfeller som krevde sjeldne spørringer på titalls petabyte, bestemte vi oss for at lagring av datasett i BigQuery ikke var kostnadseffektivt, og brukte Presto for å få direkte tilgang til datasett i GCS. For å gjøre dette ser vi på BigQuery eksterne datakilder.
De neste trinnene
Vi har sett mye interesse for BigQuery siden alfa-utgivelsen. Vi legger til flere datasett og flere kommandoer til BigQuery. Vi utvikler koblinger for dataanalyseverktøy som Scalding for å lese og skrive til BigQuery-lagring. Vi ser på verktøy som Looker og Apache Zeppelin for å lage rapporter og notater av bedriftskvalitet ved hjelp av BigQuery-datasett.
Samarbeidet vårt med Google har vært veldig produktivt, og vi er glade for å fortsette og utvikle dette partnerskapet. Vi samarbeidet med Google for å implementere vår egen for å sende forespørsler direkte til Google. Noen av dem, for eksempel BigQuery Parkett-lasteren, er allerede implementert av Google.
Her er noen av våre høyprioriterte funksjonsforespørsler for Google:
- Verktøy for praktisk datamottak og støtte for LZO-Thrift-formatet.
- Timesegmentering
- Forbedringer av tilgangskontroll som tillatelser på tabell-, rad- og kolonnenivå.
- BigQuery med Hive Metastore-integrasjon og støtte for LZO-Thrift-formatet.
- Forbedret datakatalogintegrering i BigQuery-brukergrensesnittet
- Selvbetjening for slottildeling og overvåking.
Konklusjon
Demokratisering av dataanalyse, visualisering og maskinlæring på en sikker måte er en toppprioritet for Data Platform-teamet. Vi identifiserte Google BigQuery og Data Studio som verktøy som kan bidra til å nå dette målet, og ga ut BigQuery Alpha for hele selskapet i fjor.
Vi fant ut at søk i BigQuery var enkle og effektive. Vi brukte Google-verktøy for å innta og transformere data for enkle rørledninger, men for komplekse rørledninger måtte vi bygge vårt eget Airflow-rammeverk. På databehandlingsområdet oppfyller BigQuerys tjenester for autentisering, autorisasjon og revisjon våre behov. For å administrere metadata og opprettholde personvernet trengte vi mer fleksibilitet og måtte bygge våre egne systemer. BigQuery, som er en administrert tjeneste, var enkel å bruke. Spørringskostnadene lignet på eksisterende verktøy. Lagring av data i BigQuery medfører kostnader i tillegg til GCS-kostnader.
Totalt sett fungerer BigQuery bra for generell SQL-analyse. Vi ser stor interesse for BigQuery, og vi jobber med å migrere flere datasett, få flere team og bygge flere pipelines med BigQuery. Twitter bruker en rekke data som vil kreve en kombinasjon av verktøy som Scalding, Spark, Presto og Druid. Vi har til hensikt å fortsette å styrke våre dataanalyseverktøy og gi klar veiledning til våre brukere om hvordan de best kan bruke tilbudene våre.
Ord av takknemlighet
Jeg vil gjerne takke mine medforfattere og lagkamerater, Anju Jha og Will Pascucci, for deres gode samarbeid og harde arbeid med dette prosjektet. Jeg vil også takke ingeniørene og lederne fra flere team på Twitter og Google som hjalp oss og BigQuery-brukerne på Twitter som ga verdifull tilbakemelding.
Hvis du er interessert i å jobbe med disse problemene, sjekk ut vår i Dataplattform-teamet.
Kilde: www.habr.com