Hoe Google se BigQuery data-analise gedemokratiseer het. Deel 2

Hallo, Habr! Inskrywing vir 'n nuwe kursusstroom is tans oop by OTUS Data Ingenieur. In afwagting van die begin van die kursus, gaan ons voort om nuttige materiaal met jou te deel.

Lees die eerste deel

Hoe Google se BigQuery data-analise gedemokratiseer het. Deel 2

Databestuur

Sterk databestuur is 'n kernbeginsel van Twitter Engineering. Terwyl ons BigQuery in ons platform implementeer, fokus ons op data-ontdekking, toegangsbeheer, sekuriteit en privaatheid.

Om data te ontdek en te bestuur, het ons ons datatoegangslaag uitgebrei na DAL) om nutsgoed vir beide op die perseel en Google Wolk-data te verskaf, wat 'n enkele koppelvlak en API vir ons gebruikers verskaf. As Google Data Katalogus na algemene beskikbaarheid beweeg, sal ons dit by ons projekte insluit om gebruikers van kenmerke soos kolomsoektog te voorsien.

BigQuery maak dit maklik om data te deel en toegang te verkry, maar ons moes 'n mate van beheer hieroor hê om data-eksfiltrasie te voorkom. Ons het onder andere twee funksies gekies:

  • Domeinbeperkte deling: Beta-kenmerk om te verhoed dat gebruikers BigQuery-datastelle met gebruikers buite Twitter deel.
  • VPC-dienskontroles: 'n Beheer wat data-eksfiltrasie voorkom en vereis dat gebruikers toegang tot BigQuery vanaf bekende IP-adresreekse moet kry.

Ons het verifikasie-, magtigings- en ouditvereistes (AAA) vir sekuriteit soos volg geïmplementeer:

  • Stawing: Ons het GCP-gebruikerrekeninge vir ad hoc-versoeke en diensrekeninge vir produksieversoeke gebruik.
  • Magtiging: Ons het vereis dat elke datastel 'n eienaardiensrekening en 'n lesergroep moet hê.
  • Ouditering: Ons het BigQuery-stapelbestuurder-logboeke, wat gedetailleerde inligting oor die uitvoering van navrae bevat, na 'n BigQuery-datastel uitgevoer vir maklike ontleding.

Om te verseker dat Twitter-gebruikers se persoonlike data behoorlik hanteer word, moet ons alle BigQuery-datastelle registreer, persoonlike data annoteer, behoorlike berging handhaaf en data wat deur gebruikers uitgevee is, uitvee (skraap).

Ons het na Google gekyk Cloud Data Loss Prevention API, wat masjienleer gebruik om sensitiewe data te klassifiseer en te wysig, maar het ten gunste daarvan besluit om die datastel met die hand te annoteer weens akkuraatheid. Ons beplan om die Data Loss Prevention API te gebruik om die pasgemaakte annotasie aan te vul.

Op Twitter het ons vier privaatheidskategorieë vir datastelle in BigQuery geskep, wat hier in dalende volgorde van sensitiwiteit gelys word:

  • Hoogs sensitiewe datastelle word beskikbaar gestel op 'n basis soos nodig gebaseer op die beginsel van minste bevoorregting. Elke datastel het 'n aparte groep lesers, en ons sal gebruik deur individuele rekeninge naspoor.
  • Medium sensitiwiteit datastelle (eenrigting skuilname wat gesoute hashing gebruik) bevat nie Persoonlik Identifiseerbare Inligting (PII) nie en is toeganklik vir 'n groter groep werknemers. Dit is 'n goeie balans tussen privaatheidskwessies en datanutsmiddel. Dit stel werknemers in staat om ontledingstake uit te voer, soos die berekening van die aantal gebruikers wat 'n kenmerk gebruik het, sonder om te weet wie die werklike gebruikers is.
  • Datastelle met lae sensitiwiteit met alle inligting wat gebruikers identifiseer. Dit is 'n goeie benadering vanuit 'n privaatheidsperspektief, maar kan nie vir gebruikersvlak-analise gebruik word nie.
  • Publieke datastelle (wat buite Twitter vrygestel word) is beskikbaar vir alle Twitter-werknemers.

Wat aanteken betref, het ons geskeduleerde take gebruik om BigQuery-datastelle op te som en dit te registreer met die Data Access Layer (DAL), Twitter-metadatabewaarplek. Gebruikers sal datastelle met privaatheidsinligting annoteer en ook 'n bewaringstydperk spesifiseer. Wat skoonmaak betref, evalueer ons die prestasie en koste van twee opsies: 1. Maak datastelle in GCS skoon deur nutsmiddels soos Scalding te gebruik en laai dit in BigQuery; 2. Gebruik BigQuery DML-stellings. Ons sal waarskynlik 'n kombinasie van beide metodes gebruik om aan die vereistes van verskillende groepe en data te voldoen.

Stelsel funksionaliteit

Omdat BigQuery 'n bestuurde diens is, was dit nie nodig om Twitter se SRE-span by stelselbestuur of lessenaarpligte te betrek nie. Dit was maklik om meer kapasiteit vir beide berging en rekenaar te verskaf. Ons kan die gleufbespreking verander deur 'n kaartjie met Google-ondersteuning te skep. Ons het areas geïdentifiseer wat verbeter kan word, soos selfdiensgleuftoewysing en kontroleskermverbeterings vir monitering, en het daardie versoeke by Google ingedien.

Koste

Ons voorlopige ontleding het getoon dat navraagkoste vir BigQuery en Presto op dieselfde vlak was. Ons het slots gekoop vir vasgestel prys om 'n stabiele maandelikse koste in plaas van betaling te hê op aanvraag per TB se verwerkte data. Hierdie besluit is ook gegrond op terugvoer van gebruikers wat nie aan koste wou dink voordat hulle elke versoek gerig het nie.

Die stoor van data in BigQuery het koste bykomend tot GCS-koste meegebring. Gereedskap soos Scalding vereis datastelle in GCS, en om toegang tot BigQuery te kry, moes ons dieselfde datastelle in BigQuery-formaat laai Kapasitor. Ons werk aan 'n Scalding-verbinding met BigQuery-datastelle wat die behoefte om datastelle in beide GCS en BigQuery te stoor sal uitskakel.

Vir seldsame gevalle wat ongereelde navrae van tientalle petagrepe vereis het, het ons besluit dat die stoor van datastelle in BigQuery nie koste-effektief was nie en het Presto gebruik om direk toegang tot datastelle in GCS te verkry. Om dit te doen, kyk ons ​​na BigQuery Eksterne Databronne.

Volgende stappe

Ons het baie belangstelling in BigQuery gesien sedert die alfa-vrystelling. Ons voeg meer datastelle en meer opdragte by BigQuery. Ons ontwikkel verbindings vir data-analise-nutsgoed soos Scalding om na BigQuery-berging te lees en te skryf. Ons kyk na nutsmiddels soos Looker en Apache Zeppelin vir die skep van ondernemingsgehalteverslae en -notas met behulp van BigQuery-datastelle.

Ons samewerking met Google was baie produktief en ons is bly om hierdie vennootskap voort te sit en te ontwikkel. Ons het saam met Google gewerk om ons eie te implementeer Vennoot Issue Trackerom navrae direk na Google te stuur. Sommige van hulle, soos die BigQuery Parket-laaier, is reeds deur Google geïmplementeer.

Hier is 'n paar van ons hoë prioriteit kenmerkversoeke vir Google:

  • Gereedskap vir gerieflike data-ontvangs en ondersteuning vir die LZO-Thrift-formaat.
  • Uurlikse segmentering
  • Toegangbeheerverbeterings soos tabel-, ry- en kolomvlaktoestemmings.
  • BigQuery Eksterne databronne met Hive Metastore-integrasie en ondersteuning vir die LZO-Thrift-formaat.
  • Verbeterde datakatalogus-integrasie in die BigQuery-gebruikerskoppelvlak
  • Selfdiens vir gleuftoewysing en monitering.

Gevolgtrekking

Die demokratisering van data-analise, visualisering en masjienleer op 'n veilige manier is 'n topprioriteit vir die Data Platform-span. Ons het Google BigQuery en Data Studio geïdentifiseer as nutsmiddels wat kan help om hierdie doelwit te bereik, en het verlede jaar BigQuery Alpha maatskappywyd vrygestel.

Ons het gevind dat navrae in BigQuery eenvoudig en doeltreffend is. Ons het Google-nutsgoed gebruik om data vir eenvoudige pyplyne in te neem en te transformeer, maar vir komplekse pyplyne moes ons ons eie Airflow-raamwerk bou. In die databestuurspasie voldoen BigQuery se dienste vir stawing, magtiging en ouditering aan ons behoeftes. Om metadata te bestuur en privaatheid te handhaaf, het ons meer buigsaamheid nodig gehad en moes ons ons eie stelsels bou. BigQuery, synde 'n bestuurde diens, was maklik om te gebruik. Navraagkoste was soortgelyk aan bestaande gereedskap. Om data in BigQuery te stoor, het koste bykomend tot GCS-koste.

Oor die algemeen werk BigQuery goed vir algemene SQL-analise. Ons sien baie belangstelling in BigQuery, en ons werk daaraan om meer datastelle te migreer, meer spanne aan te bring en meer pyplyne met BigQuery te bou. Twitter gebruik 'n verskeidenheid data wat 'n kombinasie van instrumente soos Scalding, Spark, Presto en Druid sal vereis. Ons beoog om voort te gaan om ons data-analise-nutsmiddels te versterk en duidelike leiding aan ons gebruikers te gee oor hoe om ons aanbiedinge die beste te gebruik.

Woorde van dankbaarheid

Ek wil graag my mede-outeurs en spanmaats, Anju Jha en Will Pascucci, bedank vir hul goeie samewerking en harde werk aan hierdie projek. Ek wil ook die ingenieurs en bestuurders van verskeie spanne by Twitter en Google bedank wat ons gehelp het en die BigQuery-gebruikers op Twitter wat waardevolle terugvoer gegee het.

As jy belangstel om aan hierdie probleme te werk, kyk na ons vakatures in die Data Platform-span.

Datakwaliteit in DWH - Datapakhuiskonsekwentheid

Bron: will.com

Voeg 'n opmerking