Kuidas Google'i BigQuery demokratiseerib andmeanalüüsi. Osa 2

Tere, Habr! Just nüüd on OTUS avatud uue kursuse ootenimekirjale „Andmeinsener“. Kursuse alguse eel jätkame kasulike materjalide jagamist.

Loe esimest osa

Andmete haldamine

Tugev andmete haldamine (Strong Data Governance) on Twitter Engineering'i põhialus. Kuna me rakendame BigQuery'd oma platvormil, keskendume andmete avastamisele, juurdepääsu kontrollimisele, turvalisusele ja privaatsusele.

Andmete avastamise ja haldamise jaoks oleme laiendanud oma andmejuurdepääsu taset (Data Access Layer — DAL), et pakkuda tööriistu nii kohalikule andmele kui ka Google Cloud'i andmetele, pakkudes meie kasutajatele ühtset liidest ja API-d. Kui Google Data Catalog liigub avalikustamise suunas, integreerime selle meie projektidesse, et pakkuda kasutajatele funktsioone, nagu veergude otsing.

BigQuery võimaldab andmeid kergesti jagada ja neile juurde pääseda, kuid meil oli mingil määral seda kontrollida, et vältida andmete lekkeid. Muuhulgas valisime kaks funktsiooni:

• Domeenikeelatud jagamine: beetaversioon, mis keelab kasutajatel jagada BigQuery andmekogusid kasutajatega, kes asuvad väljaspool Twitterit.
• VPC teenuse kontrollid: kontrollielement, mis takistab andmete lekkeid ja nõuab, et kasutajad pääseksid BigQuery'le juurde tuntud IP-aadresside vahemikest.

Selleks, et tagada turvalisus, oleme rakendanud autentimise, autoriseerimise ja auditi (AAA) nõuded järgmistel viisidel:

• Autentimine: oleme kasutanud GCP kasutajakontosid ad hoc päringute jaoks ja teenuste kontosid tööpäringute jaoks.
• Autoriseerimine: oleme nõudnud, et igal andmekogul oleks teenuse konto omanik ja lugejate grupp.
• Audit: oleme eksportinud BigQuery logide ajakava, mis sisaldas üksikasjalikku teavet päringute täitmise kohta, BigQuery andmekogusse analüüsi mugavuse huvides.

Kasutajate isikliku andmete nõuetekohase töötlemise tagamiseks peame registreerima kõik BigQuery andmekogud, annotaatorima isiklikud andmed, tagama nõuetekohase säilitamise ja kustutama (üheksasama) andmed, mis on kasutajate poolt kustutatud.

Olemitasime Google Cloud Data Loss Prevention API, mis kasutab masinõpet konfidentsiaalsete andmete klassifitseerimiseks ja redigeerimiseks, kuid otsustasime andmekogumi käsitsi annotatsiooni kasuks täpsuse tõttu. Kavatseme kasutada Andmekao Ennetamise API-d, et täiendada kasutaja annotatsiooni.

Twitteris oleme loonud neli konfidentsiaalsuse kategooriat BigQuery andmekogude jaoks, loetletud siin tundlikkuse vähenemise järjekorras:

• Kõrge tundlikkusega andmekogud on vajalikul juhul saadaval vähimate privileegide põhimõttel. Igal andmekogul on eraldi lugejate grupp, ja me jälgime individuaalsete kontode kasutamist.
• Keskmise tundlikkusega andmekogud (ühekordsed pseudonüümid soolatud räsi kasutades) ei sisalda isikuandmeid (Personally Identifiable Information — PII) ja on saadaval suuremale töötajate rühmale. See on hea tasakaal konfidentsiaalsuse ja andmete kasutusvõimaluste vahel. See võimaldab töötajatel teostada analüüsiülesandeid, näiteks arvutada, mitu kasutajat on funktsiooni kasutanud, teadmata, kes on tegelikud kasutajad.
• Madala tundlikkusega andmekogud sisaldavad kogu identifitseerivat teavet. See on hea lähenemine konfidentsiaalsuse seisukohalt, kuid seda ei saa kasutada kasutaja tasemel analüüsimiseks.
• Avalikud andmekogud (välja antud Twitteri väliselt) on kõigile Twitteri töötajatele kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti kergesti

Registreerimise osas kasutasime plaanitud ülesandeid BigQuery andmekogude loetlemiseks ja nende registreerimiseks Andmejuurdepääsu tasemele (DAL), Twitteri metainfode riiul. Kasutajad annotatsioonmisevad andmekogudele konfidentsiaalsuse teavet ning määravad säilitamise tähtaja. Andmete puhastamise osas hindame kahe variandi jõudlust ja kulusid: 1. Andmekogude puhastamine GCS-is selliste tööriistade nagu Scalding abil ja nende laadimine BigQuery-sse; 2. BigQuery DML operaatorite kasutamine. Tõenäoliselt kasutame mõlema meetodi kombinatsiooni erinevate rühmade ja andmete nõuete rahuldamiseks.

Süsteemi funktsionaalsus

Kuna BigQuery on hallatav teenus, polnud vaja Twitteri SRE meeskonda süsteemide haldamise või töövahetuste täitmisega seotud ülesannete jaoks kaasata. Suure salvestus- ja arvutusvõimekuse tagamine oli lihtne. Saime slotide reserveerimist muuta, luues Google'i tugipileteid. Oleme tuvastanud, et teatud valdkondi, nagu slotide jaotamise eneseabi ning järelevalve tööriista täiustamine, võiks parandada ja edastasime need ettepanekud Google'ile.

Hind

Meie esialgne analüüs näitas, et päringute maksumus BigQuery ja Presto osas oli samal tasemel. Me soetasime slotid fikseeritud hinna eest, et tagada stabiilne igakuine kulu, selle asemel, et maksta nõudmise järgi processed data per TB. See otsus põhines ka kasutajate tagasisidel, kes ei soovinud igat päringu sooritamise eel mõelda kuludele.

Andmete salvestamine BigQuery'sse tõi kaasa kulud GCS-i kuludele. Sellised tööriistad nagu Scalding nõuavad andmekogusid GCS-is ja BigQuery juurde pääsemiseks pidime laadima need samad andmekogud BigQuery formaati Capacitor. Me töötame selle nimel, et ühendada Scalding BigQuery andmekogudega, mis kõrvaldab vajaduse andmekogude salvestamiseks nii GCS-is kui ka BigQuery's.

Harvadel juhtudel, mis nõudsid harvade päringute tegemist kümnete petabaitide ulatuses, leidsime, et andmekogude salvestamine BigQuery'sse ei ole majanduslikult mõttekas ning kasutasime Presto't, et pääseda andmekogudele GCS-is. Selleks uurime BigQuery väliseid andmeallikaid.

Järgmised sammud

Oleme märganud suurt huvi BigQuery vastu alates alfa väljaandmisest. Me lisanud rohkem andmekogusid ja rohkem meeskondi BigQuery'sse. Töötame andmeanalüüsi tööriistade konnektorite väljatöötamise nimel, nagu Scalding, et lugeda ja kirjutada BigQuery salvestusse. Me vaatame selliseid tööriistu nagu Looker ja Apache Zeppelin, et luua äriaruandeid BigQuery andmekogude baasilt.

Koostöö Google'iga on olnud väga viljakas ja oleme rõõmsad, et saame jätkata ja edendada seda partnerlust. Oleme töötanud koos Google'iga, et rakendada meie oma Partner Issue Tracker, et otseselt Google'ile päringuid saata. Mõned neist, nagu BigQuery Parquet'i laadija, on Google juba ellu viinud.

Siin on mõned meie kõrgeima prioriteediga funktsioonisoovid Google'i jaoks:

• Tööriistad mugavaks andmete vastuvõtmiseks ja LZO-Thrift formaadi toetamine.
• Tunnipõhine segmentimine
• Parandused juurdepääsuhalduse valdkonnas, nagu tabeli, rea ja veeru taseme õigused.
• BigQuery Välistingimustes andmeallikad koos Hive Metastore'i integreerimise ja LZO-Thrift formaadi toetamisega.
• Parendatud andmekatalooge BigQuery kasutajaliideses
• Iseteenindus slotide jaotamiseks ja jälgimiseks.

Kokkuvõte

Andmete analüüsi, visualiseerimise ja masinõppe demokratiseerimine ohutult on Data Platformi meeskonna kõrgeim prioriteet. Oleme määratlenud Google BigQuery ja Data Studio tööriistad, mis võivad aidata selle eesmärgi saavutamisel, ja välja andnud eelmisel aastal BigQuery Alpha kogu ettevõttele.

Oleme leidnud, et päringud BigQuery-s olid lihtsad ja tõhusad. Andmete vastuvõtmiseks ja transformeerimiseks kasutasime Google'i tööriistu lihtsate torude jaoks, kuid keerukamate torude puhul pidime looma oma Airflow infrastruktuuri. BigQuery teenused autentimise, autoriseerimise ja auditi valdkonnas rahuldasid meie vajadusi. Metaandmete haldamiseks ja privaatsuse tagamiseks vajasime suurt paindlikkust ja pidime looma oma süsteemid. BigQuery, olles hallatav teenus, oli lihtne kasutada. Päringute kulud olid meie olemasolevate tööriistadega sarnased. Andmete salvestamine BigQuery-s tõi kaasa lisakulud GCS-i kuludele.

Kokkuvõttes töötab BigQuery hästi üldise SQL analüüsi jaoks. Märkame suurt huvi BigQuery vastu ning töötame selle nimel, et üle kanda rohkem andmehulkasid, kaasata rohkem meeskondi ja luua rohkem torusid BigQuery abil. Twitteris kasutatakse erinevaid andmeid, mille jaoks on vajalik selliste tööriistade nagu Scalding, Spark, Presto ja Druid kombinatsioon. Kavatseme jätkata oma andmeanalüüsi tööriistade arendamist ja anda oma kasutajatele selged soovitused, kuidas meie pakkumisi parimal viisil kasutada.

Tänu sõnad

Tahaksin tänada oma kaastöötajaid ja meeskonnakaaslasi, Anzhu Dja ja Willa Pascucci, nende suurepärase koostöö ja raske töö eest selle projekti kallal. Samuti tahaksin tänada insenere ja juhte mitmetest meeskondadest Twitteris ja Google'is, kes aitasid meid ja BigQuery kasutajaid Twitteris, pakkudes väärtuslikku tagasisidet.

Kui olete huvitatud nende ülesannete kallal töötamisest, tutvuge meie tööpakkumistega Data Platform meeskonnas.

Andmete kvaliteet DWH-is - andmehoidla konsistents.

Allikas: habr.com