Kā Google BigQuery demokratizēja datu analīzi. 1. daļa

Sveiks, Habr! Å obrÄ«d OTUS ir atvērta pieteikÅ”anās jaunai kursu straumei Datu inženieris. Gaidot kursu sākumu, tradicionāli esam sagatavojuÅ”i jums interesanta materiāla tulkojumu.

Katru dienu vairāk nekā simts miljonu cilvēku apmeklē Twitter, lai uzzinātu, kas notiek pasaulē un apspriestu to. Katrs tvÄ«ts un katra cita lietotāja darbÄ«ba Ä£enerē notikumu, kas ir pieejams Twitter iekŔējai datu analÄ«zei. Simtiem darbinieku analizē un vizualizē Å”os datus, un viņu pieredzes uzlaboÅ”ana ir Twitter datu platformas komandas galvenā prioritāte.

Mēs uzskatām, ka lietotājiem ar plaÅ”u tehnisko prasmju klāstu ir jāspēj atklāt datus un piekļūt labi veiktspējÄ«giem uz SQL balstÄ«tiem analÄ«zes un vizualizācijas rÄ«kiem. Tas ļautu pilnÄ«gi jaunai mazāk tehnisko lietotāju grupai, tostarp datu analÄ«tiÄ·iem un produktu vadÄ«tājiem, gÅ«t ieskatu no datiem, ļaujot viņiem labāk izprast un izmantot Twitter iespējas. Tādā veidā mēs demokratizējam datu analÄ«zi pakalpojumā Twitter.

Tā kā mÅ«su rÄ«ki un iekŔējās datu analÄ«zes iespējas ir uzlabojuŔās, mēs esam redzējuÅ”i, ka Twitter ir uzlabojies. Tomēr vēl ir vietas uzlabojumiem. PaÅ”reizējiem rÄ«kiem, piemēram, Scalding, ir nepiecieÅ”ama programmÄ“Å”anas pieredze. Uz SQL balstÄ«tiem analÄ«zes rÄ«kiem, piemēram, Presto un Vertica, ir liela mēroga veiktspējas problēmas. Mums ir arÄ« problēma ar datu izplatÄ«Å”anu vairākās sistēmās bez pastāvÄ«gas piekļuves tiem.

PagājuÅ”ajā gadā mēs paziņojām jauna sadarbÄ«ba ar Google, kuras ietvaros mēs nododam daļas no mÅ«su datu infrastruktÅ«ra pakalpojumā Google Cloud Platform (GCP). Esam secinājuÅ”i, ka Google Cloud rÄ«ki Big Datu var mums palÄ«dzēt ar mÅ«su iniciatÄ«vām, lai demokratizētu analÄ«zi, vizualizāciju un maŔīnmācÄ«Å”anos pakalpojumā Twitter:

  • BigQuery: uzņēmuma datu noliktava ar SQL dzinēju Dremel, kas ir slavena ar savu ātrumu, vienkārŔību un tiek galā ar maŔīnmācÄ«ba.
  • Datu centrs: lielu datu vizualizācijas rÄ«ks ar Google dokumentiem lÄ«dzÄ«gām sadarbÄ«bas funkcijām.

Å ajā rakstā jÅ«s uzzināsit par mÅ«su pieredzi ar Å”iem rÄ«kiem: ko mēs darÄ«jām, ko mēs uzzinājām un ko mēs darÄ«sim tālāk. Tagad mēs koncentrēsimies uz pakeÅ”u un interaktÄ«vo analÄ«zi. Nākamajā rakstā mēs apspriedÄ«sim reāllaika analÄ«zi.

Twitter datu veikalu vēsture

Pirms ienirt BigQuery, ir vērts Ä«si atstāstÄ«t Twitter datu noliktavas vēsturi. 2011. gadā Twitter datu analÄ«ze tika veikta Vertica un Hadoop. Mēs izmantojām Pig, lai izveidotu MapReduce Hadoop darbus. 2012. gadā mēs aizstājām Pig ar Scalding, kam bija Scala API ar tādām priekÅ”rocÄ«bām kā iespēja izveidot sarežģītus cauruļvadus un vieglu testÄ“Å”anu. Tomēr daudziem datu analÄ«tiÄ·iem un produktu vadÄ«tājiem, kuriem bija ērtāk strādāt ar SQL, tā bija diezgan stāva mācÄ«Å”anās lÄ«kne. Ap 2016. gadu mēs sākām izmantot Presto kā SQL saskarni Hadoop datiem. Spark piedāvāja Python saskarni, kas padara to par labu izvēli ad hoc datu zinātnei un maŔīnmācÄ«bai.

KopÅ” 2018. gada datu analÄ«zei un vizualizācijai esam izmantojuÅ”i Ŕādus rÄ«kus:

  • PlaucÄ“Å”ana ražoÅ”anas konveijeriem
  • Scalding un Spark ad hoc datu analÄ«zei un maŔīnmācÄ«bai
  • Vertica un Presto ad hoc un interaktÄ«vai SQL analÄ«zei
  • DruÄ«ds zemas interaktÄ«vas, izpētes un zema latentuma piekļuvei laikrindu metrikai
  • Tableau, Zeppelin un Pivot datu vizualizācijai

Mēs atklājām, ka, lai gan Å”ie rÄ«ki piedāvā ļoti jaudÄ«gas iespējas, mums bija grÅ«tÄ«bas padarÄ«t Ŕīs iespējas pieejamas plaŔākai Twitter auditorijai. PaplaÅ”inot savu platformu ar Google Cloud, mēs koncentrējamies uz mÅ«su analÄ«tikas rÄ«ku vienkārÅ”oÅ”anu visam Twitter.

Google BigQuery datu noliktava

Vairākas Twitter komandas jau ir iekļāvuÅ”as BigQuery dažos savos ražoÅ”anas cauruļvados. Izmantojot viņu zināŔanas, mēs sākām novērtēt BigQuery iespējas visos Twitter lietoÅ”anas gadÄ«jumos. MÅ«su mērÄ·is bija piedāvāt BigQuery visam uzņēmumam un standartizēt un atbalstÄ«t to datu platformas rÄ«kkopā. Tas bija grÅ«ti daudzu iemeslu dēļ. Mums bija jāizstrādā infrastruktÅ«ra, lai uzticami uzņemtu lielu datu apjomu, atbalstÄ«tu uzņēmuma mēroga datu pārvaldÄ«bu, nodroÅ”inātu pareizu piekļuves kontroli un klientu privātumu. Mums bija arÄ« jāizveido sistēmas resursu pieŔķirÅ”anai, uzraudzÄ«bai un atmaksai, lai komandas varētu efektÄ«vi izmantot BigQuery.

2018. gada novembrÄ« mēs izlaidām uzņēmuma BigQuery un Data Studio alfa versiju. Mēs esam piedāvājuÅ”i Twitter darbiniekiem dažas no mÅ«su visbiežāk izmantotajām izklājlapām ar notÄ«rÄ«tiem personas datiem. BigQuery ir izmantojuÅ”i vairāk nekā 250 lietotāju no dažādām komandām, tostarp inženierzinātņu, finanÅ”u un mārketinga komandām. Pavisam nesen viņi izpildÄ«ja aptuveni 8 100 pieprasÄ«jumu, apstrādājot aptuveni XNUMX PB mēnesÄ«, neskaitot plānotos pieprasÄ«jumus. SaņēmuÅ”i ļoti pozitÄ«vas atsauksmes, mēs nolēmām virzÄ«ties uz priekÅ”u un piedāvāt BigQuery kā primāro resursu mijiedarbÄ«bai ar datiem pakalpojumā Twitter.

Šeit ir mūsu Google BigQuery datu noliktavas arhitektūras augsta līmeņa diagramma.

Kā Google BigQuery demokratizēja datu analīzi. 1. daļa
Mēs kopējam datus no lokālajiem Hadoop klasteriem uz Google Cloud Storage (GCS), izmantojot iekŔējo mākoņa replikatora rÄ«ku. Pēc tam mēs izmantojam Apache Airflow, lai izveidotu cauruļvadus, kas izmanto "bq_loadĀ», lai ielādētu datus no GCS pakalpojumā BigQuery. Mēs izmantojam Presto, lai GCS vaicātu parquet vai Thrift-LZO datu kopām. BQ Blaster ir iekŔējs applaucÄ“Å”anas rÄ«ks HDFS Vertica un Thrift-LZO datu kopu ielādei BigQuery.

Nākamajās sadaļās mēs apspriežam savu pieeju un zināŔanas par lietoÅ”anas vienkārŔību, veiktspēju, datu pārvaldÄ«bu, sistēmas stāvokli un izmaksām.

LietoŔanas vienkārŔība

Mēs atklājām, ka lietotājiem bija viegli sākt darbu ar BigQuery, jo tam nebija nepiecieÅ”ama programmatÅ«ras instalÄ“Å”ana un lietotāji tai varēja piekļūt, izmantojot intuitÄ«vu tÄ«mekļa saskarni. Tomēr lietotājiem bija jāiepazÄ«stas ar dažām GCP funkcijām un koncepcijām, tostarp tādiem resursiem kā projekti, datu kopas un tabulas. Mēs esam izstrādājuÅ”i izglÄ«tojoÅ”us materiālus un apmācÄ«bas, lai palÄ«dzētu lietotājiem sākt darbu. IegÅ«stot pamatzināŔanas, lietotājiem bija viegli pārvietoties datu kopās, skatÄ«t shēmu un tabulu datus, izpildÄ«t vienkārÅ”us vaicājumus un vizualizēt rezultātus programmā Data Studio.

MÅ«su mērÄ·is datu ievadei BigQuery bija nodroÅ”ināt netraucētu HDFS vai GCS datu kopu ielādi ar vienu klikŔķi. Mēs apsvērām Mākoņu komponists (pārvalda Airflow), taču nevarējām to izmantot mÅ«su domēna ierobežotās koplietoÅ”anas droŔības modeļa dēļ (vairāk par to tālāk sadaļā Datu pārvaldÄ«ba). Mēs eksperimentējām ar Google datu pārsÅ«tÄ«Å”anas pakalpojuma (DTS) izmantoÅ”anu, lai organizētu BigQuery darba slodzi. Lai gan DTS tika ātri iestatÄ«ts, tas nebija elastÄ«gs, lai izveidotu cauruļvadus ar atkarÄ«bām. MÅ«su alfa laidienam esam izveidojuÅ”i savu Apache Airflow ietvaru GCE un gatavojam to darboties ražoÅ”anā un atbalstÄ«t vairāk datu avotu, piemēram, Vertica.

Lai pārveidotu datus par BigQuery, lietotāji izveido vienkārÅ”us SQL datu cauruļvadus, izmantojot ieplānotos vaicājumus. Sarežģītiem daudzpakāpju cauruļvadiem ar atkarÄ«bām mēs plānojam izmantot vai nu mÅ«su paÅ”u Airflow ietvaru vai Cloud Composer kopā ar Mākoņa datu plÅ«sma.

ŠŸŃ€Š¾ŠøŠ·Š²Š¾Š“ŠøтŠµŠ»ŃŒŠ½Š¾ŃŃ‚ŃŒ

BigQuery ir paredzēts vispārējas nozÄ«mes SQL vaicājumiem, kas apstrādā lielu datu apjomu. Tas nav paredzēts zema latentuma un lielas caurlaidÄ«bas vaicājumiem, kas nepiecieÅ”ami darÄ«jumu datu bāzei, vai ieviestai zema latentuma laikrindu analÄ«zei. Apache DruÄ«ds. Uz interaktÄ«viem analÄ«tikas vaicājumiem mÅ«su lietotāji sagaida, ka atbildes laiks ir mazāks par vienu minÅ«ti. Mums bija jāizstrādā BigQuery izmantoÅ”ana, lai tas atbilstu Ŕīm cerÄ«bām. Lai nodroÅ”inātu lietotājiem paredzamu veiktspēju, mēs izmantojām BigQuery funkcionalitāti, kas klientiem ir pieejama par fiksētu maksu, kas ļauj projektu Ä«paÅ”niekiem rezervēt minimālās vietas saviem vaicājumiem. Slots BigQuery ir skaitļoÅ”anas jaudas vienÄ«ba, kas nepiecieÅ”ama SQL vaicājumu izpildei.

Mēs analizējām vairāk nekā 800 vaicājumus, kas apstrādā aptuveni 1 TB datu katrā, un konstatējām, ka vidējais izpildes laiks bija 30 sekundes. Mēs arÄ« uzzinājām, ka veiktspēja ir ļoti atkarÄ«ga no mÅ«su slota izmantoÅ”anas dažādos projektos un uzdevumos. Mums bija skaidri jānorāda mÅ«su ražoÅ”anas un ad hoc laika niÅ”u rezerves, lai saglabātu veiktspēju ražoÅ”anas izmantoÅ”anas gadÄ«jumiem un tieÅ”saistes analÄ«zei. Tas lielā mērā ietekmēja mÅ«su laika niÅ”u rezervāciju un projektu hierarhiju.

Par datu pārvaldÄ«bu, funkcionalitāti un sistēmu izmaksām runāsim turpmākajās dienās tulkojuma otrajā daļā, bet tagad aicinām visus bezmaksas tieÅ”saistes vebinārs, kuras laikā varēsiet detalizēti uzzināt par kursu, kā arÄ« uzdot jautājumus mÅ«su ekspertam - Egoram MateÅ”ukam (MaximaTelecom vecākais datu inženieris).

Lasīt vairāk:

Avots: www.habr.com

Pievieno komentāru