Sveiks, Habr! Šobrīd OTUS ir atvērta pieteikšanās jaunai kursu straumei . 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 , kuras ietvaros mēs nododam daļas no mūsu pakalpojumā Google Cloud Platform (GCP). Esam secinājuši, ka Google Cloud rīki 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:
- : uzņēmuma datu noliktava ar SQL dzinēju , kas ir slavena ar savu ātrumu, vienkāršību un tiek galā ar .
- 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.
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 "», 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 (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 .
Производительность
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. . 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. 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 , 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
