Pozdravljeni, Habr! Pri OTUS-u so trenutno odprte prijave za nov tečaj . V pričakovanju začetka tečaja še naprej z vami delimo uporabno gradivo.
Upravljanje s podatki
Močno upravljanje podatkov je temeljno načelo Twitter Engineeringa. Ko implementiramo BigQuery v našo platformo, se osredotočamo na odkrivanje podatkov, nadzor dostopa, varnost in zasebnost.
Za odkrivanje in upravljanje podatkov smo razširili naš sloj za dostop do podatkov na ) za zagotavljanje orodij tako za podatke na mestu uporabe kot za podatke Google Cloud, ki zagotavljajo enoten vmesnik in API za naše uporabnike. Kot Google napreduje v smeri splošne razpoložljivosti, ga bomo vključili v naše projekte, da bi uporabnikom zagotovili funkcije, kot je iskanje po stolpcu.
BigQuery olajša skupno rabo podatkov in dostop do njih, vendar smo morali imeti nekaj nadzora nad tem, da preprečimo izlivanje podatkov. Med drugimi orodji smo izbrali dve funkciji:
- : funkcija beta, ki uporabnikom preprečuje skupno rabo naborov podatkov BigQuery z uporabniki zunaj Twitterja.
- : Kontrolnik, ki preprečuje ekstrahiranje podatkov in od uporabnikov zahteva dostop do BigQuery z znanih obsegov naslovov IP.
Za varnost smo uvedli naslednje zahteve za preverjanje pristnosti, avtorizacijo in revizijo (AAA):
- Preverjanje pristnosti: Uporabili smo uporabniške račune GCP za ad hoc zahteve in storitvene račune za produkcijske zahteve.
- Pooblastilo: zahtevali smo, da ima vsak nabor podatkov lastniški servisni račun in skupino bralcev.
- Revizija: Izvozili smo dnevnike BigQuery stackdriver, ki so vsebovali podrobne informacije o izvajanju poizvedbe, v nabor podatkov BigQuery za enostavno analizo.
Da bi zagotovili pravilno ravnanje z osebnimi podatki uporabnikov Twitterja, moramo registrirati vse nabore podatkov BigQuery, označiti osebne podatke, vzdrževati ustrezno shranjevanje in izbrisati (postrgati) podatke, ki so jih izbrisali uporabniki.
Pogledali smo Google , ki uporablja strojno učenje za razvrščanje in urejanje občutljivih podatkov, vendar se je zaradi natančnosti odločil za ročno označevanje nabora podatkov. Za razširitev opombe po meri nameravamo uporabiti API za preprečevanje izgube podatkov.
Pri Twitterju smo ustvarili štiri kategorije zasebnosti za nabore podatkov v BigQueryju, ki so tukaj navedene v padajočem vrstnem redu glede na občutljivost:
- Zelo občutljivi nabori podatkov so po potrebi na voljo na podlagi načela najmanjših privilegijev. Vsak nabor podatkov ima ločeno skupino bralcev in spremljali bomo uporabo po posameznih računih.
- Srednje občutljivi nabori podatkov (enosmerni psevdonimi z uporabo soljenega zgoščevanja) ne vsebujejo osebno določljivih podatkov (PII) in so dostopni večji skupini zaposlenih. To je dobro ravnovesje med pomisleki glede zasebnosti in uporabnostjo podatkov. To omogoča zaposlenim, da izvajajo naloge analize, kot je izračun števila uporabnikov, ki so uporabili funkcijo, ne da bi vedeli, kdo so dejanski uporabniki.
- Nizko občutljivi nabori podatkov z vsemi podatki za identifikacijo uporabnika. To je dober pristop z vidika zasebnosti, vendar ga ni mogoče uporabiti za analizo na ravni uporabnika.
- Javni nabori podatkov (objavljeni zunaj Twitterja) so na voljo vsem zaposlenim v Twitterju.
Kar zadeva beleženje, smo uporabili načrtovana opravila za oštevilčenje naborov podatkov BigQuery in njihovo registracijo s plastjo za dostop do podatkov (), repozitorij metapodatkov Twitterja. Uporabniki bodo nabore podatkov označili z informacijami o zasebnosti in določili tudi obdobje hrambe. Kar zadeva čiščenje, ocenjujemo učinkovitost in stroške dveh možnosti: 1. Čiščenje naborov podatkov v GCS z orodji, kot je Scalding, in njihovo nalaganje v BigQuery; 2. Uporaba izjav BigQuery DML. Verjetno bomo uporabili kombinacijo obeh metod, da bi izpolnili zahteve različnih skupin in podatkov.
Funkcionalnost sistema
Ker je BigQuery upravljana storitev, ni bilo treba vključiti Twitterjeve ekipe SRE v upravljanje sistemov ali delovne naloge. Z lahkoto je bilo zagotoviti večjo zmogljivost za shranjevanje in računalništvo. Rezervacijo termina lahko spremenimo tako, da ustvarimo vstopnico z Googlovo podporo. Identificirali smo področja, ki bi jih lahko izboljšali, na primer samopostrežno dodeljevanje rež in izboljšave nadzorne plošče za spremljanje, in te zahteve poslali Googlu.
Stroški
Naša predhodna analiza je pokazala, da so bili stroški poizvedb za BigQuery in Presto na enaki ravni. Kupili smo reže za ceno, da imate stabilen mesečni strošek namesto plačila na TB obdelanih podatkov. Ta odločitev je temeljila tudi na povratnih informacijah uporabnikov, ki pred vsako zahtevo niso želeli razmišljati o stroških.
Shranjevanje podatkov v BigQuery je poleg stroškov GCS povzročilo tudi stroške. Orodja, kot je Scalding, zahtevajo nabore podatkov v GCS in za dostop do BigQuery smo morali naložiti iste nabore podatkov v format BigQuery . Delamo na povezavi Scalding z nabori podatkov BigQuery, ki bo odpravila potrebo po shranjevanju naborov podatkov v GCS in BigQuery.
Za redke primere, ki so zahtevali redke poizvedbe na desetine petabajtov, smo se odločili, da shranjevanje naborov podatkov v BigQuery ni stroškovno učinkovito, in uporabili Presto za neposreden dostop do naborov podatkov v GCS. Da bi to naredili, iščemo zunanje vire podatkov BigQuery.
Naslednji koraki
Od izdaje alfa smo opazili veliko zanimanja za BigQuery. V BigQuery dodajamo več naborov podatkov in več ukazov. Razvijamo priključke za orodja za analizo podatkov, kot je Scalding, za branje in pisanje v shrambo BigQuery. Iščemo orodja, kot sta Looker in Apache Zeppelin, za ustvarjanje poročil o kakovosti podjetja in zapiskov z uporabo naborov podatkov BigQuery.
Naše sodelovanje z Googlom je bilo zelo produktivno in z veseljem nadaljujemo in razvijamo to partnerstvo. Sodelovali smo z Googlom, da smo implementirali svoje za pošiljanje poizvedb neposredno Googlu. Nekatere med njimi, kot je nakladalnik BigQuery Parquet, je Google že implementiral.
Tukaj je nekaj naših zahtev za funkcije visoke prioritete za Google:
- Orodja za udoben sprejem podatkov in podporo za format LZO-Thrift.
- Urna segmentacija
- Izboljšave nadzora dostopa, kot so dovoljenja na ravni tabele, vrstice in stolpca.
- BigQuery z integracijo Hive Metastore in podporo za format LZO-Thrift.
- Izboljšana integracija kataloga podatkov v uporabniškem vmesniku BigQuery
- Samopostrežno dodeljevanje in spremljanje slotov.
Zaključek
Demokratizacija podatkovne analize, vizualizacije in strojnega učenja na varen način je glavna prednostna naloga ekipe Data Platform. Google BigQuery in Data Studio smo opredelili kot orodji, ki bi lahko pomagali doseči ta cilj, in lani izdali BigQuery Alpha za celotno podjetje.
Ugotovili smo, da so poizvedbe v BigQuery preproste in učinkovite. Za vnos in pretvorbo podatkov za preproste cevovode smo uporabili Googlova orodja, za zapletene cevovode pa smo morali zgraditi lastno ogrodje Airflow. V prostoru za upravljanje podatkov storitve BigQuery za avtentikacijo, avtorizacijo in revizijo izpolnjujejo naše potrebe. Za upravljanje metapodatkov in ohranjanje zasebnosti smo potrebovali večjo prilagodljivost in zgraditi lastne sisteme. BigQuery je bil kot upravljana storitev preprost za uporabo. Stroški poizvedbe so bili podobni obstoječim orodjem. Shranjevanje podatkov v BigQuery povzroča stroške poleg stroškov GCS.
Na splošno BigQuery dobro deluje za splošno analizo SQL. Opažamo veliko zanimanja za BigQuery in delamo na selitvi več naborov podatkov, vključitvi več ekip in izgradnji več cevovodov z BigQuery. Twitter uporablja različne podatke, ki zahtevajo kombinacijo orodij, kot so Scalding, Spark, Presto in Druid. Še naprej nameravamo krepiti naša orodja za analizo podatkov in našim uporabnikom zagotoviti jasne smernice o tem, kako najbolje uporabiti naše ponudbe.
Besede hvaležnosti
Rad bi se zahvalil svojima soavtorjema in soigralcema, Anju Jha in Willu Pascucciju, za njuno odlično sodelovanje in trdo delo pri tem projektu. Prav tako bi se rad zahvalil inženirjem in menedžerjem iz več ekip pri Twitterju in Googlu, ki so nam pomagali, ter uporabnikom BigQuery na Twitterju, ki so posredovali dragocene povratne informacije.
Če vas zanima delo pri teh težavah, si oglejte naše v ekipi Data Platform.
Vir: www.habr.com