Hei Habr! Ilmoittautuminen uuteen kurssivirtaan on nyt auki OTUS:ssa . Ennen kurssin alkua olemme perinteisesti valmistaneet sinulle käännöksen mielenkiintoisesta materiaalista.
Joka päivä yli sata miljoonaa ihmistä vierailee Twitterissä selvittääkseen, mitä maailmassa tapahtuu, ja keskustellakseen siitä. Jokainen twiitti ja mikä tahansa muu käyttäjän toiminta luo tapahtuman, joka on käytettävissä Twitterin sisäiseen data-analyysiin. Sadat työntekijät analysoivat ja visualisoivat näitä tietoja, ja heidän kokemuksensa parantaminen on Twitter Data Platform -tiimin tärkein tavoite.
Uskomme, että käyttäjien, joilla on laaja valikoima teknisiä taitoja, pitäisi pystyä löytämään tietoa ja heillä on pääsy hyvin toimiviin SQL-pohjaisiin analyysi- ja visualisointityökaluihin. Tämä antaisi kokonaan uudelle ryhmälle vähemmän teknisiä käyttäjiä, mukaan lukien data-analyytikot ja tuotepäälliköt, poimia tiedoista oivalluksia, mikä antaisi heille mahdollisuuden ymmärtää ja käyttää Twitterin tehoa paremmin. Näin demokratisoimme data-analyysin Twitterissä.
Kun työkalumme ja kykymme sisäiseen data-analyysiin ovat parantuneet, olemme nähneet Twitter-palvelun parantuneen. Parantamisen varaa on kuitenkin vielä. Nykyiset työkalut, kuten Scalding, vaativat ohjelmointikokemusta. SQL-pohjaisilla analyysityökaluilla, kuten Presto ja Vertica, on suuria suorituskykyongelmia. Meillä on myös ongelma tietojen jakamisessa useisiin järjestelmiin ilman jatkuvaa pääsyä niihin.
Viime vuonna ilmoitimme , jonka sisällä siirrämme osia Google Cloud Platformissa (GCP). Päätimme, että Google Cloud -työkalut voi auttaa meitä hankkeissamme analyysin, visualisoinnin ja koneoppimisen demokratisoimiseksi Twitterissä:
- : yrityksen tietovarasto, jossa on SQL-moottori , joka on kuuluisa nopeudestaan, yksinkertaisuudestaan ja selviytymisestä .
- Big Datan visualisointityökalu, jossa on yhteistyöominaisuuksia, kuten Google Docs.
Tässä artikkelissa opit kokemuksistamme näistä työkaluista: mitä olemme tehneet, mitä olemme oppineet ja mitä teemme seuraavaksi. Keskitymme nyt eräanalytiikkaan ja interaktiiviseen analytiikkaan. Reaaliaikaista analytiikkaa käsitellään seuraavassa artikkelissa.
Tietovarastojen historia Twitterissä
Ennen kuin sukeltaa BigQueryyn, kannattaa lyhyesti kertoa tietovarastojen historia Twitterissä. Vuonna 2011 Twitter-dataanalyysi suoritettiin Verticassa ja Hadoopissa. MapReduce Hadoop -töiden luomiseen käytimme Pig. Vuonna 2012 korvasimme Pigin Scaldingilla, jossa oli Scala API, jonka edut, kuten kyky luoda monimutkaisia putkia ja helppo testata. Kuitenkin monille data-analyytikoille ja tuotepäälliköille, jotka olivat mukavampia työskennellä SQL:n kanssa, se oli melko jyrkkä oppimiskäyrä. Vuoden 2016 tienoilla aloimme käyttää Prestoa SQL-käyttöliittymänä Hadoop-datalle. Spark tarjosi Python-käyttöliittymän, joka tekee siitä hyvän valinnan ad hoc -tietotieteeseen ja koneoppimiseen.
Vuodesta 2018 lähtien olemme käyttäneet seuraavia työkaluja tietojen analysointiin ja visualisointiin:
- Palovamma tuotantolinjoille
- Scalding ja Spark ad hoc -datan analytiikkaan ja koneoppimiseen
- Vertica ja Presto ad hoc - ja interaktiiviseen SQL-analyysiin
- Druidi tarjoaa vähän interaktiivista, tutkivaa ja matalan latenssin pääsyä aikasarjamittareihin
- Tableau, Zeppelin ja Pivot tietojen visualisointiin
Olemme havainneet, että vaikka nämä työkalut tarjoavat erittäin tehokkaita ominaisuuksia, meillä on ollut vaikeuksia saada nämä ominaisuudet saataville laajemmalle yleisölle Twitterissä. Laajentamalla alustaamme Google Cloudilla keskitymme yksinkertaistamaan analytiikkatyökalujamme koko Twitterissä.
Googlen BigQuery Data Warehouse
Useat Twitterin tiimit ovat jo sisällyttäneet BigQueryn joihinkin tuotantoputkiin. Heidän kokemuksensa perusteella aloimme arvioida BigQueryn mahdollisuuksia kaikissa Twitterin käyttötapauksissa. Tavoitteenamme oli tarjota BigQuery koko yritykselle sekä standardoida ja tukea sitä Data Platform -työkalupakin avulla. Tämä oli vaikeaa monesta syystä. Meidän piti kehittää infrastruktuuri suurten tietomäärien luotettavaa vastaanottamista varten, tukea yrityksen laajuista tiedonhallintaa, varmistaa asianmukainen pääsynhallinta ja varmistaa asiakkaiden yksityisyys. Meidän piti myös luoda järjestelmiä resurssien allokointia, seurantaa ja takaisinperintöjä varten, jotta tiimit voisivat käyttää BigQueryä tehokkaasti.
Marraskuussa 2018 julkaisimme BigQueryn ja Data Studion alfajulkaisun koko yritykselle. Olemme tarjonneet joitain eniten käytetyistä henkilötiedoillamme tyhjennetyistä laskentataulukoistamme Twitterin henkilökunnalle. BigQueryä on käyttänyt yli 250 käyttäjää eri tiimeistä, mukaan lukien suunnittelu-, rahoitus- ja markkinointitiimeistä. Viimeksi he suorittivat noin 8 100 pyyntöä ja käsittelivät noin XNUMX PB:tä kuukaudessa ilman ajoitettuja pyyntöjä. Saatuamme erittäin myönteistä palautetta päätimme edetä ja tarjota BigQueryn ensisijaiseksi resurssiksi Twitterin datan käsittelyyn.
Tässä on kaavio Google BigQuery -tietovarastomme korkean tason arkkitehtuurista.
Kopioimme tiedot paikallisista Hadoop-klustereista Google Cloud Storageen (GCS) sisäisen Cloud Replicator -työkalun avulla. Luomme sitten Apache Airflow -putkistoja, jotka käyttävät "» ladataksesi tietoja GCS:stä BigQueryyn. Käytämme Prestoa kyselyyn Parquet- tai Thrift-LZO-tietosarjoista GCS:ssä. BQ Blaster on sisäinen Scalding-työkalu HDFS Vertica- ja Thrift-LZO-tietojoukon lataamiseen BigQueryyn.
Seuraavissa osioissa käsittelemme lähestymistapaamme ja asiantuntemustamme käytön helppouden, suorituskyvyn, tiedonhallinnan, järjestelmän kunnon ja kustannusten suhteen.
Helppokäyttöinen
Huomasimme, että käyttäjien oli helppo aloittaa BigQueryn käyttö, koska se ei vaatinut ohjelmiston asennusta ja käyttäjät pääsivät käyttämään sitä intuitiivisen verkkokäyttöliittymän kautta. Käyttäjien piti kuitenkin tutustua joihinkin GCP-ominaisuuksiin ja -konsepteihin, mukaan lukien resurssit, kuten projektit, tietojoukot ja taulukot. Olemme kehittäneet opetusohjelmia ja opetusohjelmia auttamaan käyttäjiä pääsemään alkuun. Saatujen perusymmärrysten ansiosta käyttäjien on helppo navigoida tietojoukkoja, tarkastella skeeman ja taulukon tietoja, suorittaa yksinkertaisia kyselyitä ja visualisoida tuloksia Data Studiossa.
Tavoitteemme BigQueryn tietojen syöttämisessä oli tarjota HDFS- tai GCS-tietojoukkojen saumaton lataus yhdellä napsautuksella. Mietimme (joita hallinnoi Airflow), mutta emme voineet käyttää sitä "Domain Restricted Sharing" -tietoturvamallimme vuoksi (lisätietoja alla olevassa Tiedonhallinta-osiossa). Kokeilimme Google Data Transfer Servicen (DTS) käyttöä BigQuery-lataustehtävien järjestämiseen. Vaikka DTS:n käyttöönotto oli nopeaa, se ei ollut joustava riippuvaisten putkien rakentamiseen. Alfajulkaisuamme varten olemme luoneet oman Apache Airflow -ympäristön GCE:hen ja valmistelemme sitä tuotantoa varten ja kykyä tukea muita tietolähteitä, kuten Verticaa.
Muuntaakseen tiedot BigQueryksi käyttäjät luovat yksinkertaisia SQL-tietoputkia ajoitettujen kyselyjen avulla. Monimutkaisissa monivaiheisissa putkissa, joissa on riippuvuuksia, aiomme käyttää joko omaa Airflow-kehystä tai Cloud Composeria yhdessä .
Suorituskyky
BigQuery on suunniteltu yleiskäyttöisiin SQL-kyselyihin, jotka käsittelevät suuria tietomääriä. Sitä ei ole tarkoitettu tapahtumatietokannan vaatimiin alhaisen latenssin, suuren suorituskyvyn kyselyihin tai alhaisen latenssin aikasarjaanalyysiin, jonka . Interaktiivisille analyyttisille kyselyille käyttäjämme odottavat alle minuutin vastausajan. Meidän piti suunnitella BigQueryn käyttö vastaamaan näihin odotuksiin. Voidaksemme tarjota käyttäjillemme ennakoitavissa olevaa suorituskykyä olemme käyttäneet BigQuery-toimintoa, joka on asiakkaiden käytettävissä kiinteällä maksulla, jonka avulla projektien omistajat voivat varata vähimmäispaikkoja pyyntöihinsä. BigQuery on laskentatehon yksikkö, joka tarvitaan SQL-kyselyjen suorittamiseen.
Analysoimme yli 800 kyselyä, jotka käsittelivät kukin noin 1 Tt dataa ja havaitsimme, että keskimääräinen suoritusaika oli 30 sekuntia. Opimme myös, että suorituskyky riippuu suuresti slottimme käytöstä erilaisissa projekteissa ja tehtävissä. Meidän piti erottaa selkeästi tuotanto- ja ad hoc -paikkareservimme, jotta suorituskyky säilyisi tuotantokäyttötapauksissa ja interaktiivisessa analyysissä. Tämä vaikutti suuresti suunnitteluimme lähtövarausten ja projektihierarkioiden suhteen.
Puhumme tiedonhallinnasta, järjestelmien toimivuudesta ja kustannuksista lähipäivinä käännöksen toisessa osassa, ja nyt kutsumme kaikki , jossa voit oppia lisää kurssista sekä esittää kysymyksiä asiantuntijallemme - Egor Mateshukille (Senior Data Engineer, MaximaTelecom).
Lue lisää:
Lähde: will.com