Hei Habr! Ilmoittautuminen uuteen kurssivirtaan on nyt auki OTUS:ssa . Kurssin alkua odotellessa jatkamme hyödyllisen materiaalin jakamista kanssasi.
Tiedonhallinta
Vahva tiedonhallinta on Twitter Engineeringin perusperiaate. Kun otamme BigQueryn käyttöön alustassamme, keskitymme tiedonhakuun, kulunvalvontaan, turvallisuuteen ja yksityisyyteen.
Tietojen löytämiseksi ja hallitsemiseksi olemme laajentaneet Data Access Layer -kerrokseen ) tarjotaksemme työkaluja sekä paikan päällä että Google Cloud -datalle tarjoamalla käyttäjillemme yhden käyttöliittymän ja API:n. Kuten Google on siirtymässä kohti yleistä saatavuutta, sisällytämme sen projekteihimme tarjotaksemme käyttäjille ominaisuuksia, kuten sarakehaun.
BigQuery tekee tietojen jakamisesta ja käyttämisestä helppoa, mutta meidän piti hallita tätä, jotta voimme estää tietojen suodattamisen. Muiden työkalujen joukossa valitsimme kaksi toimintoa:
- : Beta-ominaisuus, joka estää käyttäjiä jakamasta BigQuery-tietojoukkoja Twitterin ulkopuolisten käyttäjien kanssa.
- : Ohjain, joka estää tietojen suodattamisen ja edellyttää käyttäjien pääsyä BigQueryyn tunnetuilta IP-osoitealueilta.
Olemme ottaneet käyttöön todennus-, valtuutus- ja tarkastusvaatimukset (AAA) turvallisuutta varten seuraavasti:
- Todennus: Käytimme GCP-käyttäjätilejä ad hoc -pyyntöihin ja palvelutilejä tuotantopyyntöihin.
- Valtuutus: Vaadimme jokaisella tietojoukolla omistajapalvelutilin ja lukijaryhmän.
- Tarkastus: vietimme BigQuery-pinoohjainlokit, jotka sisälsivät yksityiskohtaisia kyselyn suoritustietoja, BigQuery-tietojoukoksi analysoinnin helpottamiseksi.
Twitterin käyttäjien henkilötietojen asianmukaisen käsittelyn varmistamiseksi meidän on rekisteröitävä kaikki BigQuery-tietojoukot, merkittävä henkilötietoihin, ylläpidettävä asianmukaista tallennusta ja poistettava (raavi) käyttäjien poistamat tiedot.
Katsoimme Googlea , joka luokittelee ja muokkaa arkaluontoisia tietoja koneoppimisen avulla, mutta päätti merkitä tietojoukon manuaalisesti tarkkuuden vuoksi. Aiomme käyttää Data Loss Prevention API -sovellusliittymää mukautetun merkinnän laajentamiseen.
Olemme Twitterissä luoneet BigQueryn tietojoukoille neljä tietosuojaluokkaa, jotka on lueteltu tässä alenevassa herkkyysjärjestyksessä:
- Erittäin arkaluonteiset tietojoukot asetetaan saataville tarpeen mukaan vähiten etuoikeuksien periaatteen mukaisesti. Jokaisella tietojoukolla on erillinen lukijaryhmä, ja seuraamme käyttöä yksittäisten tilien mukaan.
- Keskipitkän herkkyyden tietojoukot (yksisuuntaiset salanimet, joissa käytetään suolattua hajautustietoa) eivät sisällä henkilökohtaisia tunnistetietoja (PII), ja ne ovat suuremman joukon työntekijöitä saatavilla. Tämä on hyvä tasapaino yksityisyyteen liittyvien huolenaiheiden ja data-apuohjelman välillä. Tämän ansiosta työntekijät voivat suorittaa analyysitehtäviä, kuten laskea ominaisuutta käyttäneiden käyttäjien määrän, tietämättä keitä todelliset käyttäjät ovat.
- Matala herkkyys tietojoukot, joissa on kaikki käyttäjän tunnistetiedot. Tämä on hyvä lähestymistapa tietosuojan näkökulmasta, mutta sitä ei voida käyttää käyttäjätason analyysiin.
- Julkiset tietojoukot (julkaistaan Twitterin ulkopuolella) ovat kaikkien Twitterin työntekijöiden saatavilla.
Mitä tulee lokiin, käytimme ajoitettuja tehtäviä BigQuery-tietojoukkojen luettelemiseen ja niiden rekisteröimiseen Data Access Layeriin (), Twitterin metatietovarasto. Käyttäjät merkitsevät tietojoukkoja tietosuojatiedoilla ja määrittävät myös säilytysajan. Mitä tulee siivoukseen, arvioimme kahden vaihtoehdon suorituskyvyn ja kustannukset: 1. Tietojoukkojen puhdistaminen GCS:ssä käyttämällä työkaluja, kuten Scalding, ja lataamalla ne BigQueryyn; 2. BigQuery DML -lauseiden käyttäminen. Käytämme todennäköisesti molempien menetelmien yhdistelmää eri ryhmien ja tietojen vaatimusten täyttämiseksi.
Järjestelmän toiminnallisuus
Koska BigQuery on hallittu palvelu, Twitterin SRE-tiimiä ei tarvinnut ottaa mukaan järjestelmähallintaan tai työpöytätehtäviin. Sekä tallennus- että laskentakapasiteettia oli helppo tarjota lisää. Voisimme muuttaa paikkavarausta luomalla lipun Google-tuen kanssa. Tunnistimme alueet, joita voitaisiin parantaa, kuten itsepalvelupaikkojen jakaminen ja hallintapaneelin parannukset, ja lähetimme kyseiset pyynnöt Googlelle.
Maksaa
Alustava analyysimme osoitti, että BigQueryn ja Preston kyselykustannukset olivat samalla tasolla. Ostimme paikkoja varten hinta, jotta kuukausikustannukset ovat vakaat maksun sijaan per TB käsiteltyä dataa. Tämä päätös perustui myös palautteeseen käyttäjiltä, jotka eivät halunneet ajatella kustannuksia ennen jokaista pyyntöä.
Datan tallentaminen BigQueryyn toi kustannuksia GCS-kulujen lisäksi. Scaldingin kaltaiset työkalut vaativat datajoukkoja GCS:ssä, ja BigQueryn käyttäminen meidän piti ladata samat tietojoukot BigQuery-muotoon. . Työskentelemme Scalding-yhteyden luomiseksi BigQuery-tietosarjoihin, mikä poistaa tarpeen tallentaa datajoukkoja sekä GCS:ään että BigQueryyn.
Harvinaisissa tapauksissa, jotka vaativat harvoin kymmenien petatavujen kyselyitä, päätimme, että tietojoukkojen tallentaminen BigQueryyn ei ollut kustannustehokasta, ja käytimme Prestoa suoraan GCS:n tietojoukkojen käyttämiseen. Tätä varten tarkastelemme BigQueryn ulkoisia tietolähteitä.
РЎР »РµРґСѓСЋС ‰ РёРµ С € Р ° РіРё
Olemme nähneet paljon kiinnostusta BigQuerya kohtaan alfajulkaisun jälkeen. Lisäämme BigQueryyn lisää tietojoukkoja ja komentoja. Kehitämme liittimiä data-analytiikkatyökaluille, kuten Scaldingille, jotta voit lukea ja kirjoittaa BigQuery-tallennustilaan. Tarkastelemme työkaluja, kuten Looker ja Apache Zeppelin, joiden avulla voit luoda yrityslaaturaportteja ja -muistiinpanoja BigQuery-tietojoukkojen avulla.
Yhteistyömme Googlen kanssa on ollut erittäin hedelmällistä, ja olemme iloisia voidessamme jatkaa ja kehittää tätä kumppanuutta. Työskentelimme Googlen kanssa toteuttaaksemme omamme lähettääksesi kyselyitä suoraan Googlelle. Google on jo ottanut käyttöön osan niistä, kuten BigQuery Parquet -kuormaaja.
Tässä on joitain Googlelle tärkeimpiä ominaisuuspyyntöjämme:
- Työkalut kätevään tiedon vastaanottoon ja tuki LZO-Thrift-muodolle.
- Tuntikohtainen segmentointi
- Pääsynhallinnan parannukset, kuten taulukko-, rivi- ja saraketason käyttöoikeudet.
- BigQueryn Hive Metastore -integraatiolla ja LZO-Thrift-muodon tuella.
- Parannettu tietokatalogiintegraatio BigQuery-käyttöliittymässä
- Itsepalvelu paikkojen jakamiseen ja valvontaan.
Johtopäätös
Data-analytiikan, visualisoinnin ja koneoppimisen demokratisoiminen turvallisella tavalla on Data Platform -tiimin tärkein prioriteetti. Ymmärsimme Google BigQueryn ja Data Studion työkaluiksi, jotka voivat auttaa saavuttamaan tämän tavoitteen, ja julkaisimme BigQuery Alphan koko yrityksessä viime vuonna.
Havaitsimme BigQueryn kyselyt yksinkertaisiksi ja tehokkaiksi. Käytimme Googlen työkaluja tietojen keräämiseen ja muuntamiseen yksinkertaisia putkia varten, mutta monimutkaisia putkistoja varten meidän piti rakentaa oma Airflow-kehys. Tiedonhallintatilassa BigQueryn todennus-, valtuutus- ja auditointipalvelut vastaavat tarpeisiimme. Metatietojen hallinta ja yksityisyyden ylläpitäminen tarvitsimme lisää joustavuutta ja meidän piti rakentaa omat järjestelmämme. Hallitun palveluna BigQuery oli helppokäyttöinen. Kyselykustannukset olivat samanlaiset kuin olemassa olevat työkalut. Datan tallentaminen BigQueryyn aiheuttaa kustannuksia GCS-kulujen lisäksi.
Kaiken kaikkiaan BigQuery toimii hyvin yleisessä SQL-analyysissä. Kiinnostus BigQuerya kohtaan on suuri, ja pyrimme siirtämään lisää tietojoukkoja, tuomaan lisää tiimejä ja rakentamaan lisää putkia BigQueryn avulla. Twitter käyttää erilaisia tietoja, jotka vaativat yhdistelmän työkaluja, kuten Scalding, Spark, Presto ja Druid. Aiomme edelleen vahvistaa data-analytiikkatyökalujamme ja tarjota käyttäjillemme selkeää opastusta, kuinka tarjontaamme käytetään parhaiten.
Kiitollisuuden sanat
Haluan kiittää kirjoittajiani ja tiimitovereitani, Anju Jhaa ja Will Pascuccia, loistavasta yhteistyöstä ja kovasta työstä tämän projektin parissa. Haluan myös kiittää useiden Twitterin ja Googlen tiimien insinöörejä ja johtajia, jotka auttoivat meitä ja BigQueryn käyttäjiä Twitterissä, jotka antoivat arvokasta palautetta.
Jos olet kiinnostunut työskentelemään näiden ongelmien parissa, tutustu meidän Data Platform -tiimissä.
Lähde: will.com