Paano ginawang demokrasya ng BigQuery ng Google ang pagsusuri ng data. Bahagi 1

Hello, Habr! Ang pagpapatala para sa isang bagong stream ng kurso ay bukas ngayon sa OTUS Data Engineer. Bilang pag-asam sa pagsisimula ng kurso, tradisyonal kaming naghanda ng pagsasalin ng kawili-wiling materyal para sa iyo.

Araw-araw, mahigit isang daang milyong tao ang bumibisita sa Twitter upang malaman kung ano ang nangyayari sa mundo at talakayin ito. Ang bawat tweet at bawat iba pang aksyon ng user ay bumubuo ng isang kaganapan na magagamit para sa panloob na pagsusuri ng data ng Twitter. Daan-daang empleyado ang nagsusuri at nag-visualize sa data na ito, at ang pagpapabuti ng kanilang karanasan ay isang pangunahing priyoridad para sa Twitter Data Platform team.

Naniniwala kami na ang mga user na may malawak na hanay ng mga teknikal na kasanayan ay dapat na makatuklas ng data at magkaroon ng access sa mahusay na gumaganap na SQL-based na mga tool sa pagsusuri at visualization. Magbibigay-daan ito sa isang bagong grupo ng mga hindi gaanong teknikal na user, kabilang ang mga data analyst at product manager, na kumuha ng mga insight mula sa data, na magbibigay-daan sa kanila na mas maunawaan at magamit ang mga kakayahan ng Twitter. Ito ay kung paano namin i-demokratize ang data analytics sa Twitter.

Habang bumuti ang aming mga tool at kakayahan sa internal na data analytics, nakita namin ang pagbuti ng Twitter. Gayunpaman, mayroon pa ring puwang para sa pagpapabuti. Ang mga kasalukuyang tool tulad ng Scalding ay nangangailangan ng karanasan sa programming. Ang mga tool sa pagsusuri na batay sa SQL tulad ng Presto at Vertica ay may mga isyu sa pagganap sa sukat. Mayroon din kaming problema sa pamamahagi ng data sa maraming system nang walang patuloy na pag-access dito.

Noong nakaraang taon ay inihayag namin bagong pakikipagtulungan sa Google, kung saan inililipat namin ang mga bahagi ng aming imprastraktura ng data sa Google Cloud Platform (GCP). Napagpasyahan namin na ang mga tool ng Google Cloud Big Data ay maaaring makatulong sa amin sa aming mga inisyatiba upang gawing demokrasya ang analytics, visualization, at machine learning sa Twitter:

  • BigQuery: enterprise data warehouse na may SQL engine based Dremel, na sikat sa bilis, pagiging simple at nakakaya nito machine learning.
  • Data Studio: malaking data visualization tool na may mga feature ng collaboration na tulad ng Google Docs.

Sa artikulong ito, malalaman mo ang tungkol sa aming karanasan sa mga tool na ito: kung ano ang aming ginawa, kung ano ang aming natutunan, at kung ano ang aming susunod na gagawin. Magtutuon na kami ngayon sa batch at interactive na analytics. Tatalakayin natin ang real-time na analytics sa susunod na artikulo.

Kasaysayan ng Mga Tindahan ng Data ng Twitter

Bago sumisid sa BigQuery, sulit na ikwento nang maikli ang kasaysayan ng warehousing ng data sa Twitter. Noong 2011, isinagawa ang pagsusuri ng data ng Twitter sa Vertica at Hadoop. Ginamit namin ang Pig upang lumikha ng mga trabaho sa MapReduce Hadoop. Noong 2012, pinalitan namin ang Baboy ng Scalding, na mayroong Scala API na may mga benepisyo tulad ng kakayahang gumawa ng mga kumplikadong pipeline at kadalian ng pagsubok. Gayunpaman, para sa maraming data analyst at product manager na mas kumportable na magtrabaho sa SQL, ito ay isang medyo matarik na curve ng pag-aaral. Noong 2016, sinimulan naming gamitin ang Presto bilang isang interface ng SQL sa data ng Hadoop. Nag-aalok ang Spark ng interface ng Python, na ginagawa itong isang mahusay na pagpipilian para sa ad hoc data science at machine learning.

Mula noong 2018, ginamit namin ang mga sumusunod na tool para sa pagsusuri at visualization ng data:

  • Pagpapaso para sa mga conveyor ng produksyon
  • Scalding at Spark para sa ad hoc data analysis at machine learning
  • Vertica at Presto para sa ad hoc at interactive na pagsusuri sa SQL
  • Druid para sa mababang interactive, exploratory at mababang latency na access sa mga sukatan ng time series
  • Tableau, Zeppelin at Pivot para sa visualization ng data

Nalaman namin na habang nag-aalok ang mga tool na ito ng napakalakas na kakayahan, nahirapan kaming gawing available ang mga kakayahan na ito sa mas malawak na audience sa Twitter. Sa pamamagitan ng pagpapalawak ng aming platform sa Google Cloud, nakatuon kami sa pagpapasimple ng aming mga tool sa analytics para sa lahat ng Twitter.

BigQuery Data Warehouse ng Google

Naisama na ng ilang team sa Twitter ang BigQuery sa ilan sa kanilang mga pipeline ng produksyon. Gamit ang kanilang kadalubhasaan, sinimulan naming suriin ang mga kakayahan ng BigQuery para sa lahat ng kaso ng paggamit ng Twitter. Ang aming layunin ay mag-alok ng BigQuery sa buong kumpanya at gawing pamantayan at suportahan ito sa loob ng toolset ng Data Platform. Ito ay mahirap sa maraming kadahilanan. Kailangan naming bumuo ng isang imprastraktura upang mapagkakatiwalaang kumuha ng malalaking volume ng data, suportahan ang pamamahala ng data sa buong kumpanya, tiyakin ang wastong mga kontrol sa pag-access, at matiyak ang privacy ng customer. Kinailangan din naming gumawa ng mga system para sa paglalaan ng mapagkukunan, pagsubaybay, at mga chargeback upang epektibong magamit ng mga team ang BigQuery.

Noong Nobyembre 2018, naglabas kami ng alpha release ng BigQuery at Data Studio sa buong kumpanya. Nag-alok kami sa mga empleyado ng Twitter ng ilan sa aming pinakamadalas na ginagamit na mga spreadsheet na may nalinis na personal na data. Ang BigQuery ay ginamit ng mahigit 250 user mula sa iba't ibang team kabilang ang engineering, finance at marketing. Pinakabago, nagpapatakbo sila ng humigit-kumulang 8k na kahilingan, nagpoproseso ng humigit-kumulang 100 PB bawat buwan, hindi binibilang ang mga naka-iskedyul na kahilingan. Pagkatapos makatanggap ng napakapositibong feedback, nagpasya kaming sumulong at mag-alok ng BigQuery bilang pangunahing mapagkukunan para sa pakikipag-ugnayan sa data sa Twitter.

Narito ang isang high-level na diagram ng aming Google BigQuery data warehouse architecture.

Paano ginawang demokrasya ng BigQuery ng Google ang pagsusuri ng data. Bahagi 1
Kinokopya namin ang data mula sa mga nasa nasasakupan na Hadoop cluster patungo sa Google Cloud Storage (GCS) gamit ang internal na Cloud Replicator tool. Pagkatapos ay ginagamit namin ang Apache Airflow upang lumikha ng mga pipeline na gumagamit ng "bq_loadΒ» para mag-load ng data mula sa GCS papunta sa BigQuery. Ginagamit namin ang Presto para mag-query ng Parquet o Thrift-LZO na mga dataset sa GCS. Ang BQ Blaster ay isang internal Scalding tool para sa pag-load ng HDFS Vertica at Thrift-LZO na mga dataset sa BigQuery.

Sa mga sumusunod na seksyon, tinatalakay namin ang aming diskarte at kadalubhasaan sa mga lugar ng kadalian ng paggamit, pagganap, pamamahala ng data, kalusugan ng system, at gastos.

Dali ng paggamit

Nalaman namin na madali para sa mga user na magsimula sa BigQuery dahil hindi ito nangangailangan ng pag-install ng software at maa-access ito ng mga user sa pamamagitan ng intuitive na web interface. Gayunpaman, kailangang maging pamilyar ang mga user sa ilan sa mga feature at konsepto ng GCP, kabilang ang mga mapagkukunan gaya ng mga proyekto, dataset, at talahanayan. Bumuo kami ng mga materyal na pang-edukasyon at mga tutorial upang matulungan ang mga user na makapagsimula. Sa pagkakaroon ng pangunahing pag-unawa, naging madali sa mga user na mag-navigate sa mga set ng data, tingnan ang schema at data ng talahanayan, magpatakbo ng mga simpleng query, at makita ang mga resulta sa Data Studio.

Ang layunin namin para sa pagpasok ng data sa BigQuery ay i-enable ang tuluy-tuloy na pag-load ng mga HDFS o GCS dataset sa isang click. Isinaalang-alang namin Cloud Composer (pinamamahalaan ng Airflow) ngunit hindi namin ito nagamit dahil sa aming modelo ng seguridad na Pinaghihigpitang Pagbabahagi ng Domain (higit pa tungkol dito sa seksyong Pamamahala ng Data sa ibaba). Nag-eksperimento kami sa paggamit ng Google Data Transfer Service (DTS) para ayusin ang mga workload ng BigQuery. Bagama't mabilis na na-set up ang DTS, hindi ito flexible para sa pagbuo ng mga pipeline na may mga dependency. Para sa aming paglabas ng alpha, bumuo kami ng sarili naming framework ng Apache Airflow sa GCE at inihahanda ito upang gumana sa produksyon at magagawang suportahan ang mas maraming data source gaya ng Vertica.

Para gawing BigQuery ang data, gumagawa ang mga user ng mga simpleng pipeline ng data ng SQL gamit ang mga nakaiskedyul na query. Para sa mga kumplikadong multi-stage na pipeline na may mga dependency, plano naming gamitin ang alinman sa aming sariling Airflow framework o Cloud Composer kasama ng Cloud Dataflow.

Pagiging Produktibo

Idinisenyo ang BigQuery para sa mga pangkalahatang layunin na SQL query na nagpoproseso ng malaking halaga ng data. Hindi ito inilaan para sa mababang latency, mataas na throughput na mga query na kinakailangan ng isang transactional database, o para sa mababang latency na pagsusuri sa serye ng oras na ipinatupad Apache Druid. Para sa mga interactive na query sa analytics, inaasahan ng aming mga user ang mga oras ng pagtugon na wala pang isang minuto. Kinailangan naming idisenyo ang aming paggamit ng BigQuery upang matugunan ang mga inaasahang ito. Para makapagbigay ng predictable na performance para sa aming mga user, ginamit namin ang functionality ng BigQuery, na available sa mga customer sa isang flat fee basis na nagbibigay-daan sa mga may-ari ng proyekto na magreserba ng mga minimum na slot para sa kanilang mga query. Π‘Π»ΠΎΡ‚ Ang BigQuery ay isang unit ng computing power na kinakailangan para magsagawa ng mga query sa SQL.

Sinuri namin ang mahigit 800 query na nagpoproseso ng humigit-kumulang 1 TB ng data bawat isa at nalaman namin na ang average na oras ng pagpapatupad ay 30 segundo. Nalaman din namin na ang pagganap ay lubos na nakadepende sa paggamit ng aming slot sa iba't ibang proyekto at gawain. Kinailangan naming malinaw na ilarawan ang aming produksyon at ad hoc na mga reserbang slot upang mapanatili ang pagganap para sa mga kaso ng paggamit ng produksyon at online na pagsusuri. Malaki ang impluwensya nito sa aming disenyo para sa mga pagpapareserba ng slot at hierarchy ng proyekto.

Pag-uusapan natin ang tungkol sa pamamahala ng data, functionality at gastos ng mga system sa mga darating na araw sa ikalawang bahagi ng pagsasalin, ngunit ngayon ay iniimbitahan namin ang lahat na libreng live na webinar, kung saan maaari kang matuto nang detalyado tungkol sa kurso, pati na rin magtanong sa aming eksperto - Egor Mateshuk (Senior Data Engineer, MaximaTelecom).

Magbasa pa:

Pinagmulan: www.habr.com

Magdagdag ng komento