Sveiki, Habr! Registracija į naują kursų srautą šiuo metu vyksta OTUS . Laukdami kursų pradžios tradiciškai paruošėme jums įdomios medžiagos vertimą.
Kasdien daugiau nei šimtas milijonų žmonių apsilanko „Twitter“, norėdami sužinoti, kas vyksta pasaulyje, ir tai aptarti. Kiekvienas tviteris ir kiekvienas kitas vartotojo veiksmas sukuria įvykį, kuris yra prieinamas Twitter vidinei duomenų analizei. Šimtai darbuotojų analizuoja ir vizualizuoja šiuos duomenis, o jų patirties gerinimas yra pagrindinis „Twitter“ duomenų platformos komandos prioritetas.
Manome, kad naudotojai, turintys įvairių techninių įgūdžių, turėtų sugebėti atrasti duomenis ir turėti prieigą prie gerai veikiančių SQL analizės ir vizualizacijos įrankių. Tai leistų visai naujai mažiau techninių vartotojų grupei, įskaitant duomenų analitikus ir produktų vadybininkus, gauti įžvalgų iš duomenų, kad jie galėtų geriau suprasti ir naudoti „Twitter“ galimybes. Taip mes demokratizuojame duomenų analizę „Twitter“.
Kadangi mūsų įrankiai ir vidinės duomenų analizės galimybės pagerėjo, „Twitter“ pagerėjo. Tačiau dar yra kur tobulėti. Dabartiniams įrankiams, pvz., Scalding, reikalinga programavimo patirtis. SQL pagrįsti analizės įrankiai, pvz., Presto ir Vertica, turi didelių našumo problemų. Taip pat turime problemų dėl duomenų paskirstymo keliose sistemose be nuolatinės prieigos prie jų.
Pernai paskelbėme , per kurią perduodame dalis mūsų „Google Cloud Platform“ (GCP). Padarėme išvadą, kad „Google Cloud“ įrankiai gali mums padėti įgyvendinant iniciatyvas demokratizuoti analizę, vizualizaciją ir mašininį mokymąsi „Twitter“:
- : įmonės duomenų saugykla su SQL varikliu , kuris garsėja savo greičiu, paprastumu ir susidoroja su .
- didelių duomenų vizualizavimo įrankis su į Google dokumentus panašiomis bendradarbiavimo funkcijomis.
Šiame straipsnyje sužinosite apie mūsų patirtį naudojant šiuos įrankius: ką mes padarėme, ko išmokome ir ką darysime toliau. Dabar sutelksime dėmesį į paketinę ir interaktyviąją analizę. Kitame straipsnyje aptarsime realaus laiko analizę.
„Twitter“ duomenų parduotuvių istorija
Prieš pasineriant į „BigQuery“, verta trumpai papasakoti „Twitter“ duomenų saugyklos istoriją. 2011 metais „Vertica“ ir „Hadoop“ buvo atlikta „Twitter“ duomenų analizė. Kurdami MapReduce Hadoop užduotis naudojome Pig. 2012 m. „Pig“ pakeitėme į „Scalding“, kuri turėjo „Scala“ API su tokiais pranašumais kaip galimybė kurti sudėtingus vamzdynus ir paprastas testavimas. Tačiau daugeliui duomenų analitikų ir produktų vadybininkų, kuriems buvo patogiau dirbti su SQL, tai buvo gana staigi mokymosi kreivė. Maždaug 2016 m. pradėjome naudoti „Presto“ kaip SQL sąsają „Hadoop“ duomenims. „Spark“ pasiūlė „Python“ sąsają, todėl tai yra geras pasirinkimas ad hoc duomenų mokslui ir mašininiam mokymuisi.
Nuo 2018 m. duomenų analizei ir vizualizavimui naudojome šiuos įrankius:
- Gamybos konvejerių nuplikymas
- Scalding ir Spark ad hoc duomenų analizei ir mašininiam mokymuisi
- Vertica ir Presto ad hoc ir interaktyviai SQL analizei
- Druidas, skirtas mažai interaktyviam, tiriamajam ir mažos delsos prieigai prie laiko eilučių metrikos
- Tableau, Zeppelin ir Pivot duomenų vizualizavimui
Mes nustatėme, kad nors šie įrankiai siūlo labai galingas galimybes, mums buvo sunku padaryti šias galimybes prieinamas platesnei „Twitter“ auditorijai. Išplėsdami savo platformą naudodami „Google Cloud“, daugiausia dėmesio skiriame analitikos įrankių supaprastinimui visame „Twitter“.
„Google“ „BigQuery“ duomenų saugykla
Kelios „Twitter“ komandos jau įtraukė „BigQuery“ į kai kuriuos savo gamybos vamzdynus. Naudodamiesi jų patirtimi, pradėjome vertinti „BigQuery“ galimybes visais „Twitter“ naudojimo atvejais. Mūsų tikslas buvo pasiūlyti „BigQuery“ visai įmonei ir standartizuoti bei palaikyti ją duomenų platformos įrankių rinkinyje. Tai buvo sunku dėl daugelio priežasčių. Mums reikėjo sukurti infrastruktūrą, kad būtų galima patikimai gauti didelius duomenų kiekius, palaikyti visos įmonės duomenų valdymą, užtikrinti tinkamą prieigos kontrolę ir užtikrinti klientų privatumą. Taip pat turėjome sukurti išteklių paskirstymo, stebėjimo ir mokėjimų grąžinimo sistemas, kad komandos galėtų efektyviai naudoti „BigQuery“.
2018 m. lapkričio mėn. išleidome visos įmonės „BigQuery“ ir „Data Studio“ alfa versijos leidimą. „Twitter“ darbuotojams pasiūlėme keletą dažniausiai naudojamų skaičiuoklių su išvalytais asmeniniais duomenimis. „BigQuery“ naudojo daugiau nei 250 vartotojų iš įvairių komandų, įskaitant inžineriją, finansus ir rinkodarą. Pastaruoju metu jie vykdė apie 8 tūkst. užklausų, apdorojo apie 100 PB per mėnesį, neskaitant suplanuotų užklausų. Gavę labai teigiamų atsiliepimų, nusprendėme judėti į priekį ir pasiūlyti „BigQuery“ kaip pagrindinį „Twitter“ sąveikos su duomenimis šaltinį.
Štai mūsų „Google BigQuery“ duomenų saugyklos architektūros aukšto lygio diagrama.
Kopijuojame duomenis iš vietinių „Hadoop“ grupių į „Google Cloud Storage“ (GCS) naudodami vidinį debesies replikatoriaus įrankį. Tada naudojame „Apache Airflow“, kad sukurtume vamzdynus, kurie naudoja „» įkelti duomenis iš GCS į „BigQuery“. Naudojame Presto, kad pateiktume užklausas dėl Parquet arba Thrift-LZO duomenų rinkinių GCS. „BQ Blaster“ yra vidinis nuplikymo įrankis, skirtas HDFS Vertica ir Thrift-LZO duomenų rinkiniams įkelti į „BigQuery“.
Tolesniuose skyriuose aptariame savo požiūrį ir patirtį naudojimo paprastumo, našumo, duomenų valdymo, sistemos būklės ir išlaidų srityse.
Lengva naudoti
Pastebėjome, kad naudotojams buvo lengva pradėti naudoti „BigQuery“, nes nereikėjo įdiegti programinės įrangos, o vartotojai galėjo ją pasiekti naudodami intuityvią žiniatinklio sąsają. Tačiau naudotojai turėjo susipažinti su kai kuriomis GSP funkcijomis ir koncepcijomis, įskaitant išteklius, pvz., projektus, duomenų rinkinius ir lenteles. Sukūrėme mokomąją medžiagą ir mokymo programas, kurios padės vartotojams pradėti. Turėdami pagrindinį supratimą, naudotojams buvo lengva naršyti duomenų rinkiniuose, peržiūrėti schemų ir lentelių duomenis, vykdyti paprastas užklausas ir vizualizuoti rezultatus „Data Studio“.
Mūsų tikslas įvesti duomenis į „BigQuery“ buvo užtikrinti sklandų HDFS arba GCS duomenų rinkinių įkėlimą vienu paspaudimu. Svarstėme (tvarko „Airflow“), tačiau negalėjome jo naudoti dėl riboto domeno bendrinimo saugos modelio (daugiau apie tai rasite toliau pateiktame skyriuje Duomenų valdymas). Eksperimentavome naudodami „Google“ duomenų perdavimo paslaugą (DTS), kad suderintume „BigQuery“ darbo krūvius. Nors DTS buvo sukurtas greitai, jis nebuvo lankstus statant vamzdynus su priklausomybėmis. Savo alfa versijos leidimui sukūrėme savo „Apache Airflow“ sistemą GCE ir ruošiame ją paleisti gamyboje ir palaikyti daugiau duomenų šaltinių, pvz., „Vertica“.
Norėdami paversti duomenis į „BigQuery“, naudotojai sukuria paprastus SQL duomenų srautus naudodami suplanuotas užklausas. Sudėtingiems daugiapakopiams vamzdynams su priklausomybėmis planuojame naudoti savo „Airflow“ sistemą arba „Cloud Composer“ kartu su .
Našumas
„BigQuery“ sukurtas bendrosios paskirties SQL užklausoms, kurios apdoroja didelius duomenų kiekius. Jis nėra skirtas mažo delsos, didelio pralaidumo užklausoms, kurių reikalauja operacijų duomenų bazė, arba mažai delsos laiko eilučių analizei. . Į interaktyvias analizės užklausas mūsų vartotojai tikisi trumpesnio nei vienos minutės atsakymo laiko. Turėjome sukurti „BigQuery“ naudojimą, kad atitiktume šiuos lūkesčius. Siekdami užtikrinti naudotojams nuspėjamą našumą, panaudojome „BigQuery“ funkciją, kuri klientams prieinama už fiksuotą mokestį, leidžiančią projektų savininkams rezervuoti minimalius laiko tarpsnius savo užklausoms. BigQuery yra skaičiavimo galios vienetas, reikalingas SQL užklausoms vykdyti.
Išanalizavome daugiau nei 800 užklausų, apdorojančių maždaug 1 TB duomenų, ir nustatėme, kad vidutinis vykdymo laikas buvo 30 sekundžių. Taip pat sužinojome, kad našumas labai priklauso nuo mūsų lizdo naudojimo įvairiuose projektuose ir užduotyse. Turėjome aiškiai apibrėžti savo gamybos ir ad hoc laiko tarpsnių rezervus, kad išlaikytume našumą gamybinio naudojimo atvejų ir internetinės analizės metu. Tai labai paveikė mūsų laiko tarpsnių rezervavimo dizainą ir projekto hierarchiją.
Apie duomenų valdymą, funkcionalumą ir sistemų kainą kalbėsime artimiausiomis dienomis antroje vertimo dalyje, tačiau dabar kviečiame visus , kurio metu galėsite išsamiai sužinoti apie kursą, taip pat užduoti klausimus mūsų ekspertui Egorui Mateshukui (vyresnysis duomenų inžinierius, MaximaTelecom).
Skaityti daugiau:
Šaltinis: www.habr.com