Kako je Googleov BigQuery demokratizirao analizu podataka. 1. dio

Hej Habr! U OTUS-u su trenutno otvoreni upisi za novi tečaj Inženjer podataka. Ususret početku tečaja, tradicionalno smo za Vas pripremili prijevod zanimljivog materijala.

Svaki dan više od sto milijuna ljudi posjeti Twitter kako bi saznali što se događa u svijetu i raspravljali o tome. Svaki tweet i svaka druga radnja korisnika generira događaj koji je dostupan za internu analizu podataka unutar Twittera. Stotine zaposlenika analiziraju i vizualiziraju te podatke, a poboljšanje njihovog iskustva glavni je prioritet tima Twitter Data Platforma.

Vjerujemo da bi korisnici sa širokim rasponom tehničkih vještina trebali moći pronaći podatke i imati pristup dobro funkcionirajućim alatima za analizu i vizualizaciju koji se temelje na SQL-u. To bi omogućilo cijeloj novoj skupini manje tehničkih korisnika, uključujući analitičare podataka i voditelje proizvoda, da izvuku uvide iz podataka, omogućujući im da bolje razumiju i koriste snagu Twittera. Ovo je način na koji demokratiziramo analizu podataka na Twitteru.

Kako su se naši alati i mogućnosti za internu analizu podataka poboljšavali, vidjeli smo poboljšanje usluge Twitter. Međutim, još ima prostora za napredak. Trenutačni alati kao što je Scalding zahtijevaju programersko iskustvo. Alati za analizu koji se temelje na SQL-u kao što su Presto i Vertica imaju velikih problema s performansama. Također imamo problem s distribucijom podataka na više sustava bez stalnog pristupa istima.

Prošle godine smo najavili nova suradnja s Googleom, unutar kojeg prenosimo dijelove našeg podatkovna infrastruktura na Google Cloud Platform (GCP). Zaključili smo da Google Cloud alati Big Podaci može nam pomoći u našim inicijativama za demokratizaciju analize, vizualizacije i strojnog učenja na Twitteru:

  • BigQueryja: skladište podataka poduzeća sa SQL motorom Dremel, koji je poznat po svojoj brzini, jednostavnosti i nosi s strojno učenje.
  • podatkovni studio: alat za vizualizaciju velikih podataka sa značajkama suradnje poput Google dokumenata.

U ovom ćete članku naučiti o našem iskustvu s ovim alatima: što smo učinili, što smo naučili i što ćemo sljedeće učiniti. Sada ćemo se usredotočiti na skupnu i interaktivnu analitiku. O analitici u stvarnom vremenu bit će riječi u sljedećem članku.

Povijest skladišta podataka na Twitteru

Prije nego što zaronimo u BigQuery, vrijedi ukratko prepričati povijest skladišta podataka na Twitteru. U 2011. godini analiza Twitter podataka obavljena je u Vertici i Hadoopu. Za izradu MapReduce Hadoop poslova koristili smo Pig. Godine 2012. zamijenili smo Pig s Scaldingom, koji je imao Scala API s prednostima kao što su mogućnost stvaranja složenih cjevovoda i jednostavnost testiranja. Međutim, za mnoge analitičare podataka i voditelje proizvoda kojima je bilo ugodnije raditi sa SQL-om, to je bila prilično strma krivulja učenja. Otprilike 2016. počeli smo koristiti Presto kao naše SQL sučelje za Hadoop podatke. Spark je ponudio Python sučelje što ga čini dobrim izborom za ad hoc podatkovnu znanost i strojno učenje.

Od 2018. godine koristimo sljedeće alate za analizu i vizualizaciju podataka:

  • Pečenje za proizvodne linije
  • Scalding i Spark za ad hoc analizu podataka i strojno učenje
  • Vertica i Presto za ad hoc i interaktivnu SQL analizu
  • Druid za niskointeraktivan, istraživački pristup metrikama vremenskih serija s malom latencijom
  • Tableau, Zeppelin i Pivot za vizualizaciju podataka

Utvrdili smo da, iako ovi alati nude vrlo moćne značajke, imali smo poteškoća učiniti te značajke dostupnima široj publici na Twitteru. Proširujući našu platformu s Google Cloudom, fokusiramo se na pojednostavljenje naših analitičkih alata za cijeli Twitter.

Googleovo BigQuery skladište podataka

Nekoliko timova na Twitteru već je uključilo BigQuery u neke od svojih proizvodnih planova. Koristeći njihovo iskustvo, počeli smo procjenjivati ​​mogućnosti BigQueryja za sve slučajeve korištenja Twittera. Cilj nam je bio ponuditi BigQuery cijeloj tvrtki, te ga standardizirati i podržati unutar alata Data Platform. To je bilo teško iz mnogo razloga. Trebali smo razviti infrastrukturu za pouzdano primanje velikih količina podataka, podržati upravljanje podacima na razini cijele tvrtke, osigurati odgovarajuće kontrole pristupa i osigurati privatnost korisnika. Također smo morali stvoriti sustave za dodjelu resursa, nadzor i povrate kako bi timovi mogli učinkovito koristiti BigQuery.

U studenom 2018. izdali smo alfa izdanje BigQueryja i Data Studija za cijelu tvrtku. Osoblju Twittera ponudili smo neke od naših najčešće korištenih proračunskih tablica bez osobnih podataka. BigQuery je koristilo više od 250 korisnika iz različitih timova uključujući inženjering, financije i marketing. Nedavno su pokrenuli oko 8 zahtjeva, obrađujući oko 100 PB mjesečno, ne računajući zakazane zahtjeve. Nakon što smo primili vrlo pozitivne povratne informacije, odlučili smo krenuti naprijed i ponuditi BigQuery kao primarni resurs za interakciju s podacima na Twitteru.

Ovdje je dijagram visoke razine arhitekture našeg Google BigQuery skladišta podataka.

Kako je Googleov BigQuery demokratizirao analizu podataka. 1. dio
Kopiramo podatke iz lokalnih Hadoop klastera u Google Cloud Storage (GCS) pomoću internog alata Cloud Replicator. Zatim koristimo Apache Airflow za stvaranje cjevovoda koji koriste "bq_load» za učitavanje podataka iz GCS-a u BigQuery. Koristimo Presto za upite o skupovima podataka Parquet ili Thrift-LZO u GCS-u. BQ Blaster je interni Scalding alat za učitavanje skupova podataka HDFS Vertica i Thrift-LZO u BigQuery.

U sljedećim odjeljcima raspravljat ćemo o našem pristupu i stručnosti u jednostavnosti korištenja, performansama, upravljanju podacima, ispravnosti sustava i troškovima.

Jednostavnost upotrebe

Utvrdili smo da je korisnicima bilo jednostavno započeti s BigQueryjem jer nije zahtijevao instalaciju softvera i korisnici su mu mogli pristupiti putem intuitivnog web sučelja. Međutim, korisnici su se morali upoznati s nekim značajkama i konceptima GCP-a, uključujući resurse poput projekata, skupova podataka i tablica. Razvili smo upute i upute kako bismo pomogli korisnicima da počnu. Sa stečenim osnovnim razumijevanjem, korisnicima je jednostavno kretati se skupovima podataka, pregledavati podatke sheme i tablice, pokretati jednostavne upite i vizualizirati rezultate u Data Studiju.

Naš cilj s unosom podataka u BigQuery bio je omogućiti besprijekorno učitavanje HDFS ili GCS skupova podataka jednim klikom. Razmotrili smo Cloud Composer (upravlja Airflow), ali ga nismo mogli koristiti zbog našeg sigurnosnog modela "Dijeljenje ograničeno domenom" (više o tome u odjeljku Upravljanje podacima u nastavku). Eksperimentirali smo s upotrebom usluge Google Data Transfer Service (DTS) za organiziranje zadataka učitavanja BigQueryja. Iako se DTS brzo postavljao, nije bio fleksibilan za izgradnju cjevovoda s ovisnostima. Za naše alfa izdanje stvorili smo vlastito okruženje Apache Airflow u GCE-u i pripremamo ga za proizvodnju i mogućnost podrške za više izvora podataka kao što je Vertica.

Za pretvorbu podataka u BigQuery, korisnici stvaraju jednostavne SQL podatkovne kanale pomoću zakazanih upita. Za složene višestupanjske cjevovode s ovisnostima planiramo koristiti vlastiti okvir Airflow ili Cloud Composer zajedno s Protok podataka u oblaku.

Performanse

BigQuery je dizajniran za SQL upite opće namjene koji obrađuju velike količine podataka. Nije namijenjen za upite niske latencije, visoke propusnosti koje zahtijeva transakcijska baza podataka ili analizu vremenskih serija niske latencije koju implementira Apaški druid. Za interaktivne analitičke upite naši korisnici očekuju vrijeme odgovora kraće od jedne minute. Morali smo osmisliti upotrebu BigQueryja kako bismo ispunili ta očekivanja. Kako bismo osigurali predvidljivu izvedbu za naše korisnike, upotrijebili smo funkciju BigQuery, koja je korisnicima dostupna uz fiksnu naknadu, što vlasnicima projekata omogućuje rezerviranje minimalnih mjesta za svoje upite. prorez BigQuery je jedinica računalne snage potrebna za izvršavanje SQL upita.

Analizirali smo više od 800 upita od kojih je svaki obrađivao oko 1 TB podataka i otkrili da je prosječno vrijeme izvršenja bilo 30 sekundi. Također smo naučili da izvedba uvelike ovisi o korištenju našeg utora u raznim projektima i zadacima. Morali smo jasno razdvojiti naše proizvodne i ad hoc rezerve utora kako bismo održali performanse za slučajeve proizvodne upotrebe i interaktivnu analizu. To je uvelike utjecalo na naš dizajn rezervacija mjesta i hijerarhije projekta.

O upravljanju podacima, funkcionalnosti i cijeni sustava govorit ćemo sljedećih dana u drugom dijelu prijevoda, a sada pozivamo sve na besplatni webinar uživo, gdje možete saznati više o tečaju, kao i postaviti pitanja našem stručnjaku - Egoru Mateshuku (Senior Data Engineer, MaximaTelecom).

Čitaj više:

Izvor: www.habr.com

Dodajte komentar