Kako je Googleov BigQuery demokratizovao analizu podataka. Dio 1

Zdravo, Habr! Upis za novi stream kursa je trenutno otvoren na OTUS-u Data Engineer. Ususret početku kursa, tradicionalno smo za vas pripremili prevod zanimljivog materijala.

Svaki dan više od sto miliona ljudi posjeti Twitter kako bi saznali šta se dešava u svijetu i razgovarali o tome. Svaki tvit i svaka druga radnja korisnika generiše događaj koji je dostupan za internu analizu podataka Twitter-a. Stotine zaposlenih analiziraju i vizualiziraju ove podatke, a poboljšanje njihovog iskustva je glavni prioritet tima Twitter Data Platforme.

Vjerujemo da bi korisnici sa širokim spektrom tehničkih vještina trebali biti u mogućnosti da otkriju podatke i da imaju pristup dobro izvedenim alatima za analizu i vizualizaciju zasnovanim na SQL-u. Ovo bi omogućilo potpuno novoj grupi manje tehničkih korisnika, uključujući analitičare podataka i menadžere proizvoda, da izvuku uvide iz podataka, omogućavajući im da bolje razumiju i koriste mogućnosti Twittera. Ovako demokratiziramo analizu podataka na Twitteru.

Kako su se naši alati i mogućnosti interne analize podataka poboljšali, vidjeli smo da se Twitter poboljšava. Međutim, još uvijek ima prostora za poboljšanje. Trenutni alati poput Scalding zahtijevaju iskustvo u programiranju. Alati za analizu zasnovani na SQL-u, kao što su Presto i Vertica, imaju velike probleme sa performansama. Imamo i problem distribucije podataka na više sistema bez stalnog pristupa njima.

Prošle godine smo najavili nova saradnja sa Google-om, u okviru koje prenosimo dijelove našeg infrastrukturu podataka na Google Cloud platformi (GCP). Zaključili smo da Google Cloud alati Veliki podaci može nam pomoći s našim inicijativama za demokratizaciju analitike, vizualizacije i mašinskog učenja na Twitteru:

  • bigquery: poslovno skladište podataka sa baziranom na SQL mašini Dremel, koji je poznat po svojoj brzini, jednostavnosti i snalaženju mašinsko učenje.
  • Data Studio: alat za vizualizaciju velikih podataka sa funkcijama za saradnju poput Google dokumenata.

U ovom članku ćete saznati o našem iskustvu sa ovim alatima: šta smo uradili, šta smo naučili i šta ćemo sledeće uraditi. Sada ćemo se fokusirati na grupnu i interaktivnu analitiku. O analitici u realnom vremenu raspravljat ćemo u sljedećem članku.

Istorija Twitter prodavnica podataka

Pre nego što uđemo u BigQuery, vredi ukratko ispričati istoriju skladištenja podataka na Twitter-u. U 2011. godini izvršena je analiza podataka Twitter-a u Vertici i Hadoop-u. Koristili smo Pig za kreiranje MapReduce Hadoop poslova. Godine 2012. zamijenili smo Pig sa Scalding, koji je imao Scala API sa prednostima kao što su mogućnost kreiranja složenih cevovoda i jednostavnost testiranja. Međutim, za mnoge analitičare podataka i menadžere proizvoda kojima je bilo ugodnije raditi sa SQL-om, to je bila prilično strma kriva učenja. Otprilike 2016. počeli smo koristiti Presto kao SQL sučelje za Hadoop podatke. Spark je ponudio Python interfejs, što ga čini dobrim izborom za ad hoc nauku o podacima i mašinsko učenje.

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

  • Operenje za proizvodne transportere
  • Scalding i Spark za ad hoc analizu podataka i mašinsko učenje
  • Vertica i Presto za ad hoc i interaktivnu SQL analizu
  • Druid za nizak interaktivni, istraživački pristup metrikama vremenskih serija sa malim kašnjenjem
  • Tableau, Zeppelin i Pivot za vizualizaciju podataka

Otkrili smo da iako ovi alati nude veoma moćne mogućnosti, imali smo poteškoća da ove mogućnosti učinimo dostupnim široj publici na Twitteru. Proširujući našu platformu pomoću Google Cloud-a, fokusiramo se na pojednostavljenje naših analitičkih alata za cijeli Twitter.

Googleovo BigQuery skladište podataka

Nekoliko timova na Twitteru je već uključilo BigQuery u neke od svojih proizvodnih procesa. Koristeći njihovu stručnost, počeli smo procjenjivati ​​mogućnosti BigQueryja za sve slučajeve upotrebe Twittera. Naš cilj je bio ponuditi BigQuery cijeloj kompaniji te ga standardizirati i podržati u sklopu alata Data Platform. Ovo je bilo teško iz više razloga. Trebali smo da razvijemo infrastrukturu za pouzdano preuzimanje velikih količina podataka, podršku za upravljanje podacima u cijeloj kompaniji, osiguravanje pravilne kontrole pristupa i osiguranje privatnosti korisnika. Takođe smo morali da kreiramo sisteme za alokaciju resursa, praćenje i povraćaj sredstava kako bi timovi mogli efikasno da koriste BigQuery.

U novembru 2018. izdali smo alfa izdanje BigQuery i Data Studio za cijelu kompaniju. Zaposlenicima Twitter-a ponudili smo neke od naših najčešće korištenih tabela sa očišćenim ličnim podacima. BigQuery je koristilo preko 250 korisnika iz raznih timova, uključujući inženjering, finansije i marketing. Nedavno su pokretali oko 8k zahtjeva, obrađujući oko 100 PB mjesečno, ne računajući zakazane zahtjeve. Nakon što smo dobili veoma pozitivne povratne informacije, odlučili smo da krenemo naprijed i ponudimo BigQuery kao primarni resurs za interakciju s podacima na Twitteru.

Evo dijagrama visokog nivoa naše arhitekture Google BigQuery skladišta podataka.

Kako je Googleov BigQuery demokratizovao analizu podataka. Dio 1
Kopiramo podatke iz lokalnih Hadoop klastera u Google Cloud Storage (GCS) koristeći interni alat Cloud Replicator. Zatim koristimo Apache Airflow za kreiranje cjevovoda koji koriste "bq_load» za učitavanje podataka iz GCS-a u BigQuery. Koristimo Presto za upite za parket ili Thrift-LZO skupove podataka u GCS-u. BQ Blaster je interni alat Scalding za učitavanje HDFS Vertica i Thrift-LZO skupova podataka u BigQuery.

U sljedećim odjeljcima raspravljamo o našem pristupu i stručnosti u oblastima lakoće upotrebe, performansi, upravljanja podacima, zdravlja sistema i troškova.

Jednostavnost upotrebe

Otkrili smo da je korisnicima bilo lako započeti s BigQueryjem jer nije zahtijevao instalaciju softvera i korisnici su mu mogli pristupiti putem intuitivnog web sučelja. Međutim, korisnici su morali da se upoznaju sa nekim karakteristikama i konceptima GCP-a, uključujući resurse kao što su projekti, skupovi podataka i tabele. Razvili smo obrazovne materijale i tutorijale kako bismo pomogli korisnicima da počnu. Sa stečenim osnovnim razumijevanjem, korisnicima je bilo lako kretati se skupovima podataka, pregledavati šeme i podatke tablice, pokretati jednostavne upite i vizualizirati rezultate u Data Studiju.

Naš cilj za unos podataka u BigQuery bio je omogućiti neometano 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 za ograničeno dijeljenje domena (više o tome u odjeljku Upravljanje podacima ispod). Eksperimentirali smo s korištenjem Google Data Transfer Service (DTS) za orkestriranje BigQuery radnih opterećenja. Iako se DTS brzo postavljao, nije bio fleksibilan za izgradnju cjevovoda s ovisnostima. Za naše alfa izdanje, izgradili smo vlastiti okvir Apache Airflow u GCE-u i pripremamo ga za pokretanje u proizvodnji i biti u mogućnosti podržati više izvora podataka kao što je Vertica.

Za transformaciju podataka u BigQuery, korisnici kreiraju jednostavne SQL kanale podataka koristeći zakazane upite. Za složene višestepene cevovode sa zavisnostima, planiramo da koristimo ili naš sopstveni okvir Airflow ili Cloud Composer zajedno sa Cloud Dataflow.

Produktivnost

BigQuery je dizajniran za SQL upite opće namjene koji obrađuju velike količine podataka. Nije namijenjen za upite niske latencije, velike propusnosti koje zahtijeva transakcijska baza podataka ili za implementiranu analizu vremenskih serija male latencije Apache Druid. Za upite interaktivne analitike, naši korisnici očekuju vrijeme odgovora manje od jedne minute. Morali smo dizajnirati našu upotrebu BigQueryja kako bismo ispunili ova očekivanja. Kako bismo pružili predvidljive performanse za naše korisnike, iskoristili smo BigQuery funkcionalnost, dostupnu korisnicima uz fiksnu naknadu koja omogućava vlasnicima projekata da rezervišu minimalna mjesta za svoje upite. Utor BigQuery je jedinica računarske snage potrebne za izvršavanje SQL upita.

Analizirali smo preko 800 upita koji obrađuju otprilike 1 TB podataka svaki i otkrili da je prosječno vrijeme izvršenja 30 sekundi. Također smo naučili da performanse u velikoj mjeri ovise o korištenju našeg slota u različitim projektima i zadacima. Morali smo jasno razgraničiti naše rezerve proizvodnje i ad hoc slotova kako bismo održali performanse za slučajeve upotrebe u proizvodnji i online analizu. To je uvelike utjecalo na naš dizajn za rezervacije slotova i hijerarhiju projekta.

O upravljanju podacima, funkcionalnosti i cijeni sistema ćemo narednih dana govoriti u drugom dijelu prijevoda, ali sada pozivamo sve da besplatni webinar uživo, tokom kojeg ćete moći detaljno da saznate o kursu, kao i da postavite pitanja našem stručnjaku - Egoru Matešuku (Senior Data Engineer, MaximaTelecom).

Čitaj više:

izvor: www.habr.com

Dodajte komentar