Tere, Habr! Just nüüd on OTUS avatud uue kursuse ootenimekirjale Kursi algusele eelnevalt oleme traditsiooniliselt valmistanud teile tõlke huvitavast materjalist.
Iga päev külastab Twitterit üle saja miljoni inimese, et saada teada, mis maailmas toimub, ja arutada seda. Iga tweet ja iga teine kasutaja tegevus genereerib sündmuse, mis on kergesti kättesaadav Twitteri sisemiseks andmeanalüüsiks. Sajad töötajad analüüsivad ja visualiseerivad neid andmeid ning nende kogemuse parandamine on Twitteri andmeplatvormi meeskonna peamine prioriteet.
Usume, et kasutajad, kellel on laiahaardeline tehniline oskus, peaksid saama andmeid leida ja pääseda hästi töötavatele SQL-põhistele analüüsi- ja visualiseerimistööriistadele. See võimaldaks täiesti uuel kasutajagrupil, kelle tehnilised oskused on väiksemad, sealhulgas andmeanalüütikutel ja tootemeeskonna juhtidel, andmetest teavet tõmmata, võimaldades neil paremini mõista ja kasutada Twitteri võimalusi. Nii demokratiseerime me Twitteris andmeanalüüsi.
Meie andmeanalüüsi tööriistade ja võimaluste täiustamise käigus oleme olnud tunnistajaks Twitteri teenuse paranemisele. Siiski on veel ruumi kasvamiseks. Praegused tööriistad, nagu Scalding, nõuavad programmeerimiskogemust. SQL-põhised analüüsitööriistad, nagu Presto ja Vertica, kannatavad suurel skaalal jõudlusprobleemide all. Meil on ka probleem andmete levitamisega erinevatesse süsteemidesse ilma pideva juurdepäsuta neile.
Eelmisel aastal teatasime , mille käigus viime osa meie Google Cloud Platformile (GCP). Oleme jõudnud järeldusele, et Google Cloudi tööriistad võivad aidata meid meie algatustes andmeanalüüsi, visualiseerimise ja masinõppe demokratiseerimisel Twitteris:
- : ettevõtte andmehoidla, mille SQL-mootor põhineb , mis on tuntud oma kiirusest, lihtsusest ja suudab toime tulla .
- tööriist suurte andmete visualiseerimiseks, koos koostööfunktsioonidega, nagu Google Docsis.
Selles artiklis saate teada meie kogemustest nende tööriistadega: mida tegime, mida õppisime ja mida teeme edasi. Praegu keskendume tüüpkasutusele ja interaktiivsele analüütikale. Reaalajas analüütikat arutame järgmises artiklis.
Twitteri andmehoidlate ajalugu
Enne süveneda BigQuery'sse, tasub lühidalt üle vaadata Twitteri andmehoidlate ajalugu. Aastal 2011 töötas Twitteri andmeanalüüs Verticas ja Hadoopis. Hadoopi MapReduce'i tööde loomiseks kasutasime Pig'i. Aastal 2012 asendasime Pigi Scaldinguga, millel oli Scala API, mille eelised olid sellised nagu keerukate torujuhtmete loomise võimalus ja lihtsus testimise osas. Siiski, paljudele andmeanalüütikutele ja tootejuhtidele, kellele meeldis SQL'iga töötada, oli see piisavalt järsk õppimiskõver. Umbes 2016. aastal hakkasime kasutama Presto't SQL liidese jaoks Hadoopi andmetele. Spark pakkus Python'i liidest, mis teeb sellest hea valiku ad hoc andmeuuringute ja masinõppe jaoks.
Alates 2018. aastast oleme andmete analüüsimiseks ja visualiseerimiseks kasutanud järgmisi tööriistu:
- Scalding tootmisprotsesside jaoks
- Scalding ja Spark ad hoc andmeanalüüsiks ja masinõppe jaoks
- Vertica ja Presto ad hoc ja interaktiivseks SQL analüüsiks
- Druid väikese interaktiivsuse, uurimise ja madala latentsusega juurdepääsuks ajalooliste mõõdikute jaoks
- Tableau, Zeppelin ja Pivot andmete visualiseerimiseks
Oleme avastanud, et kuigi need tööriistad pakuvad väga võimsaid võimalusi, olime raskustes nende juurutamisega laiemale publikule Twitteris. Laiendades oma platvormi Google Cloudi abil, keskendume analüüsitööriistade lihtsustamisele kogu Twitteris.
Google'i BigQuery andmehoidla
Mõned meeskonnad Twitteris on juba integreerinud BigQuery mõnedesse oma tootmisprotsessidesse. Kasutades nende kogemusi, hakkasime hindama BigQuery võimalusi kõikide Twitteri kasutusjuhtude jaoks. Meie eesmärk oli pakkuda BigQuery'd kogu ettevõttele ning standardiseerida ja toetada seda Data Platformi tööriistade komplekti raames. See osutus mitmetel põhjustel keeruliseks. Me pidime välja töötama infrastruktuuri suurte andmehulkade usaldusväärseks vastuvõtmiseks, toetama kogu ettevõtte andmehalduse juhtimist, tagama nõuetekohase juurdepääsu kontrolli ja kliendiandmete privaatsuse. Samuti pidime looma süsteemid ressursside jaotamiseks, monitooringuks ja tasumisteks, et meeskonnad saaksid efektiivselt BigQuery'd kasutada.
Novembris 2018. aastal tutvustasime BigQuery ja Data Studio alpha-versiooni kogu ettevõttele. Pakkusime Twitteri töötajatele mõningaid meie enimkasutatud tabelitest puhastatud isikuandmetega. BigQuery'it kasutas üle 250 kasutaja erinevatest meeskondadest, sealhulgas inseneritehnika, rahanduse ja turunduse alal. Viimasel ajal sooritati umbes 8000 päringut, töödeldes umbes 100 PB kuus, välja arvatud plaanitud päringud. Saades positiivset tagasisidet, otsustasime edasi liikuda ja pakkuda BigQuery't peamise vahendina andmete haldamiseks Twitteris.
Siin on meie Google BigQuery andmehälli kõrgetasemeline arhitektuuriskeem.
Kopeerime andmed kohalikest Hadoop klastest Google Cloud Storage'i (GCS) kasutades sisemist tööriista Cloud Replicator. Seejärel kasutame Apache Airflow'd torujuhtmete loomiseks, mis kasutavad „“ andmete laadimiseks GCS'ist BigQuery'sse. Kasutame Presto't Parquet või Thrift-LZO andmehulkade pärimiseks GCS'is. BQ Blaster on sisemine Scalding tööriist, mis laadib HDFS Vertica ja Thrift-LZO andmehulgad BigQuery'sse.
Järk-järgult arutame meie lähenemist ja teadmisi kasutusmugavuse, jõudluse, andmete haldamise, süsteemi töökindluse ja kulude osas.
Kasutusmugavus
Oleme avastanud, et kasutajatel oli BigQuery'ga lihtne alustada, kuna see ei nõudnud tarkvara installimist ja kasutajad pääsesid sellele ligi intuitiivse veebiliidese kaudu. Siiski pidi kasutajad tutvuma mõne GCP funktsiooniga ja selle kontseptidega, sealhulgas selliste ressurssidega nagu projektid, andmehulgad ja tabelid. Oleme välja töötanud õppematerjale ja juhendeid, et aidata kasutajatel alustada. Põhiteadmiste omandamisega on kasutajatel lihtne navigeerida andmehulkade vahel, vaadata tabelite skeeme ja andmeid, teha lihtsaid päringuid ning visualiseerida tulemusi Data Studios.
Meie eesmärk andmete sisestamisel BigQuery'sse oli tagada sujuv andmehulkade laadimine HDFS'ist või GCS'ist ühe hiireklõpsuga. Me vaatlesime (hallatav Airflow), kuid ei saanud seda kasutada meie "Domain Restricted Sharing" turvamudeli tõttu (lisainfot leiate allpool jaotises "Andmete haldamine"). Katsetasime Google Data Transfer Service (DTS) kasutamist BigQuery koormuste ülesannete haldamiseks. Kuigi DTS oli kiiresti seadistatav, ei olnud see paindlik sõltuvustega torude loomiseks. Meie alfa versioonis lõime oma Apache Airflow keskkonna GCE-s ning valmistame seda ette tootmisse viimiseks ja rohkemate andmeallikate, näiteks Vertica, toetamiseks.
Andmete konverteerimiseks BigQuery-s loovad kasutajad lihtsaid SQL andmetorusid, kasutades ajastatud päringuid. Komplekssete mitmeastmeliste sõltuvustega torude jaoks plaanime kasutada kas meie enda Airflow infrastruktuuri või Cloud Composerit koos .
Tõhusus
BigQuery on loodud üldotstarbeliste SQL päringute jaoks, mis töötlevad suuri andmemahtusid. See ei ole mõeldud madala latentsuse ja kõrge läbilaskevõimega päringute jaoks, mis on vajalikud tehingupõhise andmebaasi jaoks, ega madala latentsusega ajalooliste andmete analüüsiks, mis on rakendatud . Interaktiivsete analüütiliste päringute jaoks ootavad meie kasutajad vastuseaega alla ühe minuti. Oleme pidanud projekteerima BigQuery kasutamise viisil, et see vastaks nende ootustele. Kasutajate jaoks usaldusväärse jõudluse tagamiseks oleme kasutanud BigQuery funktsionaalsust, mis on saadaval klientidele fikseeritud hinnaga, võimaldades projektide omanikel reserveerida oma päringute jaoks minimaalsed slotid. BigQuery on arvutusvõimsuse üksus, mis on vajalik SQL päringute täitmiseks.
Me oleme analüüsinud üle 800 päringu, mis töötlevad kokku umbes 1 TB andmeid, ning avastasime, et keskmine täitmis aeg oli 30 sekundit. Samuti selgus, et jõudlus sõltub meie sloti kasutamisest erinevates projektides ja ülesannetes. Olime sunnitud selgelt eristama meie tootmis- ja ad hoc slotide reserve, et tagada tootmisstsenaariumide täitmise jõudlus ja interaktiivne analüüs. See mõjutas väga tugevalt meie slotide broneerimise ja projektide hierarhiat.
Andmete haldamise, funktsionaalsuse ja süsteemide kulude teemadest räägime juba lähipäevil tõlke teises osas, kuid praegu kutsume kõiki soovijaid , mille käigus saab põhjalikult teada kursusest ja esitada küsimusi meie eksperdile — Jevgeni Matešukile (vanem andmeinsener, MaximaTelecom).
Loe edasi:
Allikas: habr.com
