Hej Habr! Aliĝo por nova kursfluo estas malfermita ĉe OTUS nun . Antaŭĝoje de la komenco de la kurso, ni daŭre kundividas utilan materialon kun vi.
Administrado de datumoj
Forta Datuma Regado estas kerna principo de Twitter Engineering. Dum ni efektivigas BigQuery en nian platformon, ni koncentriĝas pri datummalkovro, alirkontrolo, sekureco kaj privateco.
Por malkovri kaj administri datumojn, ni vastigis nian Datuman Alirtavolon al ) provizi ilojn por kaj surlokaj kaj Google Cloud datumoj, disponigante ununuran interfacon kaj API por niaj uzantoj. Kiel Guglo iras al ĝenerala havebleco, ni inkludos ĝin en niaj projektoj por provizi uzantojn per funkcioj kiel ekzemple kolumna serĉo.
BigQuery faciligas kunhavigi kaj aliri datumojn, sed ni bezonis havi iom da kontrolo pri tio por malhelpi datumojn eksfiltradon. Inter aliaj iloj, ni elektis du funkciojn:
- : Beta-funkcio por malhelpi uzantojn kunhavigi BigQuery-datumaron kun uzantoj ekster Twitter.
- : Kontrolo kiu malhelpas datumojn eksfiltradon kaj devigas uzantojn aliri BigQuery de konataj IP-adresintervaloj.
Ni efektivigis konfirmon, rajtigon kaj revizion (AAA) postulojn por sekureco jene:
- Aŭtentikigo: Ni uzis GCP-uzantkontojn por ad hoc petoj kaj servokontojn por produktadpetoj.
- Rajtigo: Ni postulis, ke ĉiu datumaro havu posedan servokonton kaj legantogrupon.
- Reviziado: Ni eksportis BigQuery-stackdriver-protokolojn, kiuj enhavis detalajn demandojn pri ekzekuto-informoj, en BigQuery-datumaron por facila analizo.
Por certigi, ke la personaj datumoj de uzantoj de Twitter estas ĝuste traktataj, ni devas registri ĉiujn BigQuery-datumojn, komenti personajn datumojn, konservi taŭgan stokadon kaj forigi (skrapi) datumojn forigitajn de uzantoj.
Ni rigardis Guglon , kiu uzas maŝinlernadon por klasifiki kaj redakti sentemajn datumojn, sed decidis en favoro de mane komentado de la datumaro pro precizeco. Ni planas uzi la Data Loss Prevention API por pliigi la kutiman komentarion.
Ĉe Twitter, ni kreis kvar privatecajn kategoriojn por datumaroj en BigQuery, listigitaj ĉi tie en malkreskanta sinsekvo:
- Tre sentemaj datenoj estas disponeblaj laŭbezone surbaze de la principo de malplej privilegio. Ĉiu datumaro havas apartan grupon de legantoj, kaj ni spuros uzadon per individuaj kontoj.
- Mezaj sentemaj datumaroj (unudirektaj pseŭdonimoj uzantaj salitan haŝon) ne enhavas Persone Identigeblajn Informojn (PII) kaj estas alireblaj por pli granda grupo de dungitoj. Ĉi tio estas bona ekvilibro inter privatecaj zorgoj kaj datuma utileco. Ĉi tio permesas al dungitoj plenumi analizajn taskojn, kiel kalkuli la nombron da uzantoj, kiuj uzis funkcion, sen scii kiuj estas la realaj uzantoj.
- Malaltaj sentemaj datenoj kun ĉiuj uzantidentigantaj informoj. Ĉi tio estas bona aliro el privateca perspektivo, sed ne povas esti uzata por uzantnivela analizo.
- Publikaj datumaroj (publikigitaj ekster Twitter) estas haveblaj al ĉiuj Twitter-dungitoj.
Koncerne al arbohakado, ni uzis planitajn taskojn por listigi BigQuery-datumaron kaj registri ilin kun la Datuma Alirtavolo (), Twitter metadatenoj deponejo. Uzantoj komentos datumarojn kun privatecaj informoj kaj ankaŭ precizigos konservan periodon. Koncerne purigadon, ni taksas la rendimenton kaj koston de du opcioj: 1. Purigi datenojn en GCS uzante ilojn kiel Scalding kaj ŝarĝante ilin en BigQuery; 2. Uzante BigQuery DML-deklarojn. Ni verŝajne uzos kombinaĵon de ambaŭ metodoj por plenumi la postulojn de malsamaj grupoj kaj datumoj.
Sistemfunkcieco
Ĉar BigQuery estas administrita servo, ne necesis impliki la SRE-teamon de Twitter en sistemo-administrado aŭ labortablo. Estis facile disponigi pli da kapacito por kaj stokado kaj komputado. Ni povus ŝanĝi la fendorezervadon kreante bileton kun Google-subteno. Ni identigis areojn, kiuj povus esti plibonigitaj, kiel memserva fendo-atribuo kaj plibonigoj de panelo por monitorado, kaj sendis tiujn petojn al Guglo.
kosto de
Nia prepara analizo montris, ke demandaj kostoj por BigQuery kaj Presto estis sur la sama nivelo. Ni aĉetis fendojn por prezo por havi stabilan monatan koston anstataŭ pago po TB de prilaboritaj datumoj. Ĉi tiu decido baziĝis ankaŭ sur sugestoj de uzantoj, kiuj ne volis pensi pri kostoj antaŭ ol fari ĉiun peton.
Stoki datumojn en BigQuery alportis kostojn aldone al GCS-kostoj. Iloj kiel Scalding postulas datumarojn en GCS, kaj por aliri BigQuery ni devis ŝargi la samajn datumarojn en BigQuery-formaton. . Ni laboras pri Scalding-konekto al BigQuery-datumseroj, kiu eliminos la bezonon stoki datumarojn en ambaŭ GCS kaj BigQuery.
Por maloftaj kazoj, kiuj postulis maloftajn demandojn de dekoj da petabajtoj, ni decidis, ke konservado de datumaroj en BigQuery ne estis kostefika kaj uzis Presto por rekte aliri datumajn arojn en GCS. Por fari tion, ni rigardas BigQuery Eksterajn Datumajn Fontojn.
Sekvaj paŝoj
Ni vidis multe da intereso pri BigQuery ekde la alfa-eldono. Ni aldonas pli da datumaroj kaj pli da komandoj al BigQuery. Ni disvolvas konektilojn por datum-analitikaj iloj kiel Scalding por legi kaj skribi al BigQuery-stokado. Ni rigardas ilojn kiel Looker kaj Apache Zeppelin por krei entreprenajn kvalitajn raportojn kaj notojn uzante BigQuery-datumaron.
Nia kunlaboro kun Guglo estis tre produktiva kaj ni ĝojas daŭrigi kaj disvolvi ĉi tiun partnerecon. Ni laboris kun Google por efektivigi nian propran sendi demandojn rekte al Guglo. Kelkaj el ili, kiel la BigQuery Parquet-ŝargilo, jam estis efektivigitaj de Guglo.
Jen kelkaj el niaj altprioritataj funkciopetoj por Guglo:
- Iloj por oportuna datumricevo kaj subteno por la formato LZO-Thrift.
- Hora segmentado
- Pliboniĝoj pri alirkontrolo kiel tabel-, vico- kaj kolumnnivelaj permesoj.
- bigquery kun Hive Metastore integriĝo kaj subteno por la LZO-Thrift formato.
- Plibonigita datuma katalogo-integriĝo en la uzantinterfaco de BigQuery
- Memservo por fendo-atribuo kaj monitorado.
konkludo
Demokratiigi datuman analizon, bildigon kaj maŝinlernadon en sekura maniero estas ĉefa prioritato por la teamo de Data Platform. Ni identigis Google BigQuery kaj Data Studio kiel iloj kiuj povus helpi atingi ĉi tiun celon, kaj publikigis BigQuery Alpha tutjare lastan jaron.
Ni trovis demandojn en BigQuery simplaj kaj efikaj. Ni uzis Guglo-ilojn por konsumi kaj transformi datumojn por simplaj duktoj, sed por kompleksaj duktoj ni devis konstrui nian propran Airflow-kadron. En la datumadministrada spaco, la servoj de BigQuery por aŭtentigo, rajtigo kaj revizio plenumas niajn bezonojn. Por administri metadatenojn kaj konservi privatecon, ni bezonis pli da fleksebleco kaj devis konstrui niajn proprajn sistemojn. BigQuery, estante administrita servo, estis facile uzebla. Demandkostoj estis similaj al ekzistantaj iloj. Stoki datumojn en BigQuery kaŭzas kostojn aldone al GCS-kostoj.
Ĝenerale, BigQuery funkcias bone por ĝenerala SQL-analizo. Ni vidas multe da intereso pri BigQuery, kaj ni laboras por migri pli da datumaj aroj, kunigi pli da teamoj kaj konstrui pli da duktoj kun BigQuery. Twitter uzas diversajn datumojn, kiuj postulos kombinaĵon de iloj kiel Scalding, Spark, Presto kaj Druid. Ni intencas daŭrigi plifortigi niajn datumajn analizajn ilojn kaj doni klaran gvidon al niaj uzantoj pri kiel plej bone uzi niajn ofertojn.
Dankemaj vortoj
Mi ŝatus danki miajn kunaŭtorojn kaj samteamanoj, Anju Jha kaj Will Pascucci, pro ilia bonega kunlaboro kaj laborego en ĉi tiu projekto. Mi ankaŭ ŝatus danki la inĝenierojn kaj administrantojn de pluraj teamoj ĉe Twitter kaj Guglo, kiuj helpis nin kaj la uzantojn de BigQuery en Twitter, kiuj donis valorajn rimarkojn.
Se vi interesiĝas pri labori pri ĉi tiuj problemoj, rigardu nian en la teamo de Data Platform.
fonto: www.habr.com