Kuidas Google'i BigQuery andmeanalüüsi demokratiseeris. 1. osa

Tere, Habr! Uute kursuste voogu registreerimine on OTUS-es praegu avatud Andmeinsener. Kursuse alguse ootuses oleme traditsiooniliselt koostanud teile huvitava materjali tõlke.

Iga päev külastab Twitterit rohkem kui sada miljonit inimest, et teada saada, mis maailmas toimub, ja arutada seda. Iga säuts ja iga teine ​​kasutaja toiming genereerib sündmuse, mis on Twitteri sisemise andmeanalüüsi jaoks saadaval. Sajad töötajad analüüsivad ja visualiseerivad neid andmeid ning nende kogemuste parandamine on Twitteri andmeplatvormi meeskonna peamine prioriteet.

Usume, et laiaulatuslike tehniliste oskustega kasutajad peaksid suutma andmeid avastada ja neil peaks olema juurdepääs hästitoimivatele SQL-põhistele analüüsi- ja visualiseerimistööriistadele. See võimaldaks täiesti uuel vähem tehnilistel kasutajatel, sealhulgas andmeanalüütikutel ja tootejuhtidel, hankida andmetest teadmisi, võimaldades neil Twitteri võimalusi paremini mõista ja kasutada. Nii demokratiseerime andmeanalüütika Twitteris.

Kuna meie tööriistad ja sisemised andmeanalüüsi võimalused on paranenud, oleme näinud Twitteri paranemist. Siiski on veel arenguruumi. Praegused tööriistad, nagu Scalding, nõuavad programmeerimiskogemust. SQL-põhistel analüüsitööriistadel, nagu Presto ja Vertica, on jõudlusprobleeme laialdaselt. Meil on ka probleem andmete levitamisel mitme süsteemi vahel ilma neile pideva juurdepääsuta.

Eelmisel aastal teatasime uus koostöö Google'iga, mille raames edastame osad meie andmeinfrastruktuur Google Cloud Platformis (GCP). Jõudsime järeldusele, et Google Cloud tööriistad Big andmed võib aidata meil oma algatustega demokratiseerida analüütikat, visualiseerimist ja masinõpet Twitteris:

  • suur päring: ettevõtte andmeladu koos SQL-mootori baasil Dremel, mis on kuulus oma kiiruse, lihtsuse ja toimetuleku poolest masinõpe.
  • Data Studio: suurte andmete visualiseerimise tööriist koos Google Docsi sarnaste koostööfunktsioonidega.

Sellest artiklist saate teada meie kogemustest nende tööriistadega: mida me tegime, mida õppisime ja mida me järgmisena teeme. Nüüd keskendume partii- ja interaktiivsele analüüsile. Järgmises artiklis käsitleme reaalajas analüütikat.

Twitteri andmepoodide ajalugu

Enne BigQuerysse sukeldumist tasub lühidalt jutustada Twitteri andmeladustamise ajaloost. 2011. aastal viidi läbi Twitteri andmete analüüs Verticas ja Hadoopis. Kasutasime MapReduce Hadoopi töökohtade loomiseks Pig'i. 2012. aastal asendasime Pig Scaldinguga, millel oli Scala API eelistega, nagu võimalus luua keerulisi torujuhtmeid ja testimise lihtsus. Paljudele andmeanalüütikutele ja tootejuhtidele, kellel oli SQL-iga mugavam töötada, oli see aga üsna järsk õppimiskõver. 2016. aasta paiku hakkasime kasutama Prestot SQL-i liidesena Hadoopi andmetele. Spark pakkus Pythoni liidest, mis teeb sellest hea valiku ad hoc andmeteaduse ja masinõppe jaoks.

Alates 2018. aastast oleme andmete analüüsimiseks ja visualiseerimiseks kasutanud järgmisi tööriistu:

  • Tootmiskonveierite põletamine
  • Scalding ja Spark ad hoc andmete analüüsiks ja masinõppeks
  • Vertica ja Presto ad hoc ja interaktiivse SQL analüüsi jaoks
  • Druiid madala interaktiivse, uurimusliku ja madala latentsusega juurdepääsuks aegridade mõõdikutele
  • Tableau, Zeppelin ja Pivot andmete visualiseerimiseks

Leidsime, et kuigi need tööriistad pakuvad väga võimsaid võimalusi, oli meil raskusi nende võimaluste laiemale publikule Twitteris kättesaadavaks tegemisega. Laiendades oma platvormi Google Cloudiga, keskendume oma analüüsitööriistade lihtsustamisele kogu Twitteri jaoks.

Google'i BigQuery andmeladu

Mitmed Twitteri meeskonnad on BigQuery juba mõnda oma tootmistorusse lisanud. Nende teadmisi kasutades hakkasime hindama BigQuery võimalusi kõigi Twitteri kasutusjuhtude jaoks. Meie eesmärk oli pakkuda BigQueryt kogu ettevõttele ning standardida ja toetada seda andmeplatvormi tööriistakomplektis. See oli raske mitmel põhjusel. Meil oli vaja välja arendada infrastruktuur, mis võimaldab usaldusväärselt neelata suuri andmemahtusid, toetada kogu ettevõtte andmehaldust, tagada korralik juurdepääsu kontroll ja tagada klientide privaatsus. Samuti pidime looma ressursside eraldamise, jälgimise ja tagasimaksete süsteemid, et meeskonnad saaksid BigQueryt tõhusalt kasutada.

2018. aasta novembris andsime välja kogu ettevõtet hõlmava BigQuery ja Data Studio alfaversiooni. Oleme Twitteri töötajatele pakkunud mõnda meie kõige sagedamini kasutatavat arvutustabelit puhastatud isikuandmetega. BigQueryt on kasutanud üle 250 kasutaja erinevatest meeskondadest, sealhulgas inseneri-, finants- ja turundusmeeskondadest. Viimasel ajal esitasid nad umbes 8 100 päringut, töödeldes umbes XNUMX PB kuus, arvestamata ajastatud päringuid. Pärast väga positiivse tagasiside saamist otsustasime liikuda edasi ja pakkuda BigQueryt Twitteris andmetega suhtlemise peamise ressursina.

Siin on meie Google BigQuery andmelao arhitektuuri kõrgetasemeline diagramm.

Kuidas Google'i BigQuery andmeanalüüsi demokratiseeris. 1. osa
Kopeerime andmeid kohapealsetest Hadoopi klastritest Google Cloud Storage'i (GCS), kasutades sisemist Cloud Replicatori tööriista. Seejärel kasutame Apache Airflow'i torujuhtmete loomiseks, mis kasutavad "bq_load» andmete laadimiseks GCS-ist BigQuerysse. Kasutame GCS-is Parketi või Thrift-LZO andmekogumite päringute tegemiseks Prestot. BQ Blaster on sisemine põletustööriist HDFS Vertica ja Thrift-LZO andmekogumite laadimiseks BigQuerysse.

Järgmistes jaotistes käsitleme oma lähenemisviisi ja teadmisi kasutuslihtsuse, jõudluse, andmehalduse, süsteemi tervise ja kulude valdkonnas.

Kasutusmugavus

Leidsime, et kasutajatel oli BigQueryga alustamine lihtne, kuna see ei nõudnud tarkvara installimist ja kasutajad pääsesid sellele ligi intuitiivse veebiliidese kaudu. Kasutajad pidid aga tutvuma mõne GCP funktsiooni ja kontseptsiooniga, sealhulgas ressurssidega, nagu projektid, andmestikud ja tabelid. Oleme välja töötanud õppematerjale ja õpetusi, mis aitavad kasutajatel alustada. Omandatud põhiteadmiste tõttu leidsid kasutajad, et Data Studios on andmekogumites navigeerimine, skeemi ja tabeliandmete vaatamine, lihtsate päringute käitamine ja tulemuste visualiseerimine lihtne.

Meie eesmärk BigQuerysse andmete sisestamisel oli võimaldada HDFS- või GCS-andmekomplektide sujuv laadimine ühe klõpsuga. Me kaalusime Pilvehelilooja (haldab Airflow), kuid ei saanud seda kasutada meie domeeni piiratud jagamise turbemudeli tõttu (selle kohta leiate teavet allpool jaotisest Andmehaldus). Katsetasime Google'i andmeedastusteenuse (DTS) kasutamist BigQuery töökoormuste korraldamiseks. Kuigi DTS-i seadistamine oli kiire, ei olnud see sõltuvustega torujuhtmete ehitamiseks paindlik. Oleme oma alfaversiooni jaoks loonud GCE-s oma Apache Airflow raamistiku ja valmistame seda ette tootmiseks ja toetama rohkem andmeallikaid, nagu Vertica.

Andmete BigQueryks teisendamiseks loovad kasutajad ajastatud päringute abil lihtsaid SQL-i andmekonveierid. Keeruliste mitmeastmeliste sõltuvustega torujuhtmete jaoks kavatseme kasutada kas oma Airflow raamistikku või Cloud Composerit koos Pilvandmevoog.

Производительность

BigQuery on loodud üldotstarbeliste SQL-päringute jaoks, mis töötlevad suuri andmemahtusid. See ei ole ette nähtud tehingute andmebaasi nõutavate madala latentsusaja ja suure läbilaskevõimega päringute jaoks ega rakendatud madala latentsusega aegridade analüüsi jaoks. Apache Druid. Interaktiivsete analüütikapäringute puhul ootavad meie kasutajad vastuseaega alla ühe minuti. Nendele ootustele vastamiseks pidime BigQuery kasutamise kavandama. Oma kasutajatele prognoositava jõudluse pakkumiseks kasutasime BigQuery funktsioone, mis on klientidele saadaval kindla tasu alusel, mis võimaldab projektiomanikel reserveerida oma päringute jaoks minimaalseid teenindusaegu. Pesa BigQuery on SQL-päringute täitmiseks vajalik arvutusvõimsuse ühik.

Analüüsisime üle 800 päringu, millest igaüks töötles ligikaudu 1 TB andmeid, ja leidsime, et keskmine täitmisaeg oli 30 sekundit. Samuti saime teada, et jõudlus sõltub suuresti meie pesa kasutamisest erinevates projektides ja ülesannetes. Pidime selgelt piiritlema oma tootmis- ja ad hoc teenindusaegade reservid, et säilitada jõudlus tootmiskasutusjuhtumite ja veebianalüüside jaoks. See mõjutas suuresti meie kujundust teenindusaegade broneerimiseks ja projekti hierarhiat.

Andmehaldusest, süsteemide funktsionaalsusest ja maksumusest räägime lähipäevil tõlke teises osas, kuid nüüd kutsume kõiki üles tasuta otseülekanne veebiseminar, mille käigus saate kursuse kohta üksikasjalikult õppida, samuti esitada küsimusi meie eksperdile Egor Mateshukile (MaximaTelecomi vanemandmeinsener).

Loe rohkem:

Allikas: www.habr.com

Lisa kommentaar