Elame imetabasel ajal, mil on võimalik kiiresti ja lihtsalt ühendada mitu valmis avatud tööriista, seadistada neid „välja lülitatud teadvusega“ stackoverflow'i nõuannete järgi, süvenemata „paljude tähtedesse“, ja käivitada need kommertskasutusse. Ja kui tuleb vajadus värskendada/katsetada või keegi kogemata mõned masinad taaskäivitab — siis mõista, et on alanud mingi pealetükkiv halb uni, kõik on järsku muutunud raskeaks ja äratuntamatuks, tagasiteed ei ole, tulevik on ebamugav ja turvalisem on hoopis mesilaste pidamine ning juustu valmistamine.
Kogenem, et kogenumad kolleegid, kellel on palju veateateid ja halliks muudetud juuksed, vaatavad hämmastavalt kiiret konteinerite kasutuselevõttu kümnetele serveritele moodsatesse keeltesse, millel on sisseehitatud asünkroonne mittesünroonimine — naeratavad tagasihoidlikult. Ja nad jätkavad vaikselt 'man ps' lugemist, uurivad 'nginx' algkoode, ning kirjutavad-kirjutavad-kirjutavad üksusteste. Kolleegid teavad, et kõige huvitavam on alles ees, kui 'kõik see' ühel ööl uue aasta eel tükkideks kukub. Ainult sügav arusaam Unix'i iseloomust, TCP/IP olekute tabelid ja põhilised sortimise-otsingu algoritmid saavad neid aidata, et kellade kõlades süsteemi ellu äratada.
Ah jah, natuke eksisin, aga loodetavasti suutsin edastada ootuse seisundi.
Täna tahan jagada oma kogemust mugava ja odava DataLake stacks'i juurutamisest, mis lahendab ettevõttes enamikku analüüsitöödest täiesti erinevates struktuuriüksustes.
Mingil aega tagasi mõistsime, et ettevõtetele on üha enam vajalikud nii toote- kui ka tehnilise analüüsi tulemused (rääkimata tordi peale pandud kirsist masinõppe näol) ja trendide ning riskide mõistmiseks tuleb koguda ja analüüsida üha rohkem meetrikaid.
Põhi tehniline analüüs «Bitrix24»-s
Mõned aastad tagasi, koos «Bitrix24» teenuse käivitamisega, investeerisime aktiivselt aega ja ressursse lihtsa ja usaldusväärse analüüsiplatvormi loomisse, mis aitaks kiiresti tuvastada infrastruktuuri probleeme ja kavandada järgmisi samme. Loomulikult sooviti kasutada olemasolevaid, maksimaalselt lihtsaid ja arusaadavaid tööriistu. Tulemuseks valiti nagios jälgimiseks ja munin analüüsi ja visualiseerimise jaoks. Nüüd on meil nagioses tuhandeid kontrolle, sadu graafikuid muninis ja kolleegid kasutavad neid igapäevaselt ja edukalt. Meetrikad on arusaadavad, graafikud selged, süsteem töötab usaldusväärselt juba mitu aastat ning seda täiendatakse regulaarselt uute testide ja graafikutega: kui viime uue teenuse kasutusele — lisame mõned testid ja graafikud. Head teed.
Käsi pulsil — laiendatud tehniline analüüs
Soov saada teavet probleemide kohta "nii kiiresti kui võimalik" viis meid aktiivsetesse katsetesse lihtsate ja arusaadavate tööriistadega — pinba ja xhprof.
Pinba edastas meile UDP-paketites statistikat PHP veebilehe elementide töökiirusest ja oli võimalik reaalajas näha MySQL andmebaasis (pinbabiga kaasas oma MySQL mootor kiireks sündmuste analüüsiks) lühikest probleemide nimekirja ning nendele reageerida. Xhprof võimaldas automaatselt koguda kõige aeglasemate PHP-lehtede käitusgraafikuid ja analüüsida, mis sellele võis kaasa aidata — rahulikult, samal ajal teed või midagi kangemat nautides.
Mõni aeg tagasi täiendati tööriistade komplekti veel ühe üsna lihtsa ja arusaadava mootori abil, mis põhineb vastupidise indekseerimise algoritmil, mis on suurepäraselt ellu viidud legendaarse Lucene'i raamatukogus — Elastic/Kibana. Lihtne mõte mitme lõimega dokumentide salvestamisest Lucene'i vastupidises indeksis logide sündmustel ning kiire otsimine nende vahel kasutades fasetset jagunemist - osutus tõeliselt kasulikuks.
Hoolimata Kibana visualiseerimise tehnilisest väljanägemisest, kus kasutatakse madala taseme mõisteid nagu 'bucket' ja usaldusväärset relatsioonilist algebral keelt, on see tööriist meid hästi toetanud järgmistes ülesannetes:
- Kui palju PHP vigu oli Bitrix24 kliendil portaalis p1 viimase tunni jooksul ja millised need olid? Saame aru, andestame ja parandame kiiresti.
- Kui palju video kõnesid tehti Saksamaa portaalides viimase 24 tunni jooksul, millise kvaliteediga need olid ning kas esines probleeme kanali/võrguga?
- Kui hästi töötab meie süsteemi funktsionaalsus (meie PHP jaoks C keeles kirjutatud laiendus), mis on kompileeritud allikatest viimases teenuseuuenduses ja klientidele välja antud? Kas segfault'e ei esine?
- Kas kliendiandmed mahtuvad PHP mälu? Kas esinevad veaülesanded mälupiiri ületamiseks: 'out of memory'? Leidke ja neutraliseerige.
Siin on konkreetne näide. Hoolimata põhjalikust ja mitmeastmelisest testimisest, tekkis kliendil ebatavalise juhtumi ja rikutud sisendandmetega tüütav ja ootamatu viga, kõlas sireen ja algas selle kiire parandamise protsess:
Lisaks võimaldab Kibana korraldada teatamisi määratletud sündmustest ning lühikese ajaga on tööriista hakanud kasutama kümned töötajad erinevatest osakondadest — alates tugiteenustest ja arendusest kuni QA-ni.
Iga osakonna aktiivsust ettevõtte sees on mugav jälgida ja mõõta — selle asemel, et analüüsida serverite logisid käsitsi, piisab logide parsimise ja nende saatmise seadistamisest Elastic klastrisse, et nautida näiteks Kibana juhtpaneelil kahepealiste kassipoegade müügi arvu vaatamist, mis on 3D-printeriga valmistatud eelmise kuu jooksul.
Põhiärianalüüs
Kõik teavad, et tihti algab ärianalüüs ettevõtetes äärmiselt aktiivse Exceli kasutamisega. Kuid mis kõige tähtsam, see ei tohiks seal lõppeda. Õli tulle valab veel hästi ka pilvepõhine Google Analytics — heaga harjub kiiresti.
Meie hästi arenevas ettevõttes on hakanud aeg-ajalt ilmuma "prohveteid", kes tegelevad suuremate andmete intensiivse töötlemisega. Üha enam on hakanud ilmnema vajadused sügavamate ja mitmekesiste aruannete järele ning erinevate osakondade inimeste jõupingutustega leiti mõni aeg tagasi lihtne ja praktiline lahendus — ClickHouse ja PowerBI ühendamine.
Pikka aega aitas see paindlik lahendus suurepäraselt, kuid järk-järgult hakkas selguma, et ClickHouse ei ole kummist ja sellega ei saa niisama teha, mida hing ihaldab.
Siin on oluline hästi mõista, et ClickHouse, nagu Druid, Vertica ja Amazon RedShift (mis põhineb PostgreSQL-il), on analüüsimootorid, mis on optimeeritud üsna mugavaks analüüsiks (kokkuvõtted, agregatsioonid, minimaalne-maksimaalne kolonni kaupa ja natuke liitumisi), kuna nad on korraldatud efektiivseks rikka andmete salvestamiseks, erinevalt tuntud MySQL-st ja teistest (rea-põhistest) andmebaasidest.
Sisuliselt on ClickHouse lihtsalt ruumikam andmebaas, mille punktipõhine sisestamine ei ole kõige mugavam (nii on see ette nähtud, kõik on korras), kuid millel on meeldiv analüütika ja hulk huvitavaid ja võimekaid funktsioone andmetega töötamiseks. Jah, klastrigi on võimalik luua — aga te mõistate, et naelte löömine mikroskoobiga ei ole just õige ning oleme hakanud otsima muid lahendusi.
Nõudlus python'i ja analüütikute järele
Meie ettevõttes on palju arendajaid, kes kirjutavad koodi peaaegu igapäevaselt juba 10–20 aastat PHP, JavaScripti, C#, C/C++, Java, Go, Rust, Pythoni, Bashiga. Samuti on meil palju kogenud süsteemihaldureid, kes on läbi elanud mitmeid täiesti uskumatuid katastroofe, mis ei sobi statistika seadustega (näiteks kui tugevast välkude löögist hävitatakse enamus kettasid RAID-10 konfiguratsioonis). Sellistes tingimustes jäi pikka aega arusaamatuks, mis on „Python analüütik“. Python on nagu PHP, lihtsalt natuke pikem nimi ja selles interpretaatori lähtekoodis on veidi vähem teadvust muutvaid aineid. Siiski, uusi analüütilisi aruandeid luues on kogenud arendajad järjest enam aru saanud kitsaste spetsialiseerumiste tähtsusest tööriistades nagu NumPy, pandas, matplotlib, seaborn.
Otsustavat rolli mängisid tõenäoliselt töötajate äkilised minestused sõnade «logistiline regressioon» kombinatsioonist ning efektiivsete aruannete koostamise demonstreerimine suurte andmete abil, jah, just pysparkiga.
Apache Spark, selle funktsionaalne paradigma, mis sobib suurepäraselt relatsioonilise algebraga ja selle võimalused on jätnud arendajatele, kes on harjunud MySQL-iga, nii sügava mulje, et vajadus tugevdada ridasid kogenud analüütikute abil on muutunud päevselgeks.
Edasi minekud Apache Spark/Hadoop'i tõusmiseks ja mis ei läinud päris plaani järgi.
Kuid peagi sai selgeks, et Sparkiga on ilmselt midagi süsteemselt valesti või tuleb lihtsalt paremini käsi pesta. Kui Hadoopi/MapReduce'i/Lucene'i stacki tegid piisavalt kogenud programmeerijad, mis on ilmselge, kui vaatad Java koodi või Doug Cutting'i ideid Lucenes, siis Spark on ootamatult kirjutatud väga küsitaval praktilisuse tasemel ja praegu mittearenenud eksootilisel keelel Scala. Ja regulaarne arvutuste kokkuvarisemine Spark klastris, mis tuleneb ebatavalistest ja mitte eriti läbipaistvatest mälu eraldamisest reduce operatsioonide jaoks (palju võtmeid tuleb korraga) — on loonud tema ümber aura milleski, millel on arenguruumi. Lisaks süvendas olukorda suur hulk kummalisi avatud porte, ajutisi faile, mis kasvasid kõige arusaamatutes kohtades ja jar-sõltuvus — mis tekitas süsteemiadministraatorites üht ja neile hästi tuttavat tunnet: metsikut viha (võib-olla oleks pidanud lihtsalt käsi seebiga pesema).
Oleme mitmeid siseseid analüütilisi projekte, mis kasutavad aktiivselt Apache Sparki (sh Spark Streaming, Spark SQL) ja Hadoopi ökosüsteemi, 'elusalt' üle elanud. Aja jooksul oleme õppinud seda päris hästi seadistama ja jälgima, ning 'see' on peaaegu lakkanud äkki kukkumast andmete iseloomu muutumise ja RDD ühtlase hash'imise tasakaalu rikkumise tõttu. Soov võtta midagi juba valmis, pidevalt uuendatavat ja haldatavat kusagil pilves, oli järjest tugevam. Just sel ajal proovisin kasutada valmis pilvesüsteemi Amazon Web Services — ja seejärel püüdsime juba seal probleeme lahendada. EMR on Amazoni poolt valmistatud Apache Spark koos täiendava tarkvaraga ökosüsteemist, umbes nagu Cloudera/Hortonworks kogumikud.
Analüütika jaoks 'kummist' failide salvestamine — terav vajadus
Hadoop/Spark'i "küpsetamise" kogemus erinevate kehaosade põletustega ei läinud raisku. Tekkis järjest selgem vajadus luua ühtne, soodne ja usaldusväärne failide salvestusruum, mis oleks vastupidav riistvararikketele ning kus saaks hoida faile erinevates formaatides erinevatest süsteemidest ning teha nende andmete põhjal efektiivseid ja mõistliku ajaga teostatavaid valikuid aruannete jaoks.
Samuti tahtsin, et selle platvormi tarkvarauuendus ei muutuks uue aasta ööde õudusunenäoks, kus tuleb lugeda 20-leheküljelisi Java jälgi ning analüüsida kilomeetriste üksikasjalike klastrilogide sisu Spark History Serveri ja luubi abil. Soovisime lihtsat ja läbipaistvat tööriista, mis ei nõuaks regulaarselt kapoti alla sukeldumist, kui arendaja standardne MapReduce päring ei hakka töötama, kui reductor'i mälu allalangevad andmed ei sobi valitud algandmete partitsioneerimise algoritmi korral.
Kas Amazon S3 on kandidaat DataLake'iks?
Töökogemus Hadoopi/MapReduce'iga on näidanud, et vajalik on skaleeritav ja usaldusväärne failisüsteem ning selle peale skaleeritavad töötlusprotsessid, mis „tulevad“ andmetele lähemale, et vältida andmete edastamist üle võrgu. Töötlusprotsessid peavad suutma lugeda andmeid erinevates formaatides, kuid oleks parem, kui nad ei loeks liigset teavet ja et andmeid saaks eelnevalt salvestada töötlejatele mugavates formates.
Veel kord — peamine idee. Ei ole soovi „laadida“ suuri andmeid ühte klastrisse analüütilisse mootorrattasse, mis varem või hiljem ikkagi lämbub ja mille tulemusena tuleb seda ebamugavalt jagada. Soov on hoida faile, lihtsalt faile, arusaadavas formaadis ja teha nende põhjal efektiivseid analüütilisi päringuid erinevate, kuid arusaadavate tööriistadega. Ja erinevates formaatides faile tuleb aina rohkem ja rohkem. Ja parem on jagada mitte mootorit, vaid lähteandmeid. Me vajame laienevat ja universaalset DataLake'i, otsustasime me...
Aga mis siis, kui hoida faile tuntud ja paljudele tuttavas skaleeritavas pilvehoidlas Amazon S3, selle asemel et tegeleda oma „hakkimise“ ettekandmisega Hadoopist?
Selge, isikuandmeid „ei saa“, aga kas muid andmeid saaks sinna viia ja „efektiivselt käitada“?
Amazon Web Servicesi klastrite suurandmete analüüsi ökosüsteem — lihtsate sõnadega.
Meie AWS-i kogemuse põhjal on seal juba ammu ja aktiivselt kasutuses Apache Hadoop/MapReduce erinevates vormides, näiteks DataPipeline'i teenuses (kaardun oma kolleegidele, nad on osanud seda korralikult seadistada). Siin oleme seadnud erinevate teenuste varukoopiad DynamoDB tabelitest:
Ja need täidetakse regulaarselt Hadoop/MapReduce sisseehitatud klastrites nagu kellavärk juba aastaid. "Seadista ja unusta":
Samuti on efektiivne tegeleda andmeanalüüsiga, käivitades analüütikutele pilves Jupyteri märkmikud ning kasutades AWS SageMakeri teenust AI mudelite koolitamiseks ja juurutamiseks. Nii see meil välja näeb:
Ja jah, analüütikule või endale võib käivitada pilves märkmiku ja ühendada selle Hadoop/Spark klastriga, arvutada ja pärast kõik "töötada".
See on tõeliselt mugav eraldi analüütiliste projektide jaoks ja mõnede jaoks oleme edukalt kasutanud EMR teenust mahukate arvutuste ja analüüside tegemiseks. Aga mida arvata süsteemsetest lahendustest DataLake'i jaoks, kas saaksime seda? Sel hetkel olime lootuse ja meeleheite piiril ning jätkasime otsingut.
AWS Glue — hoolikalt pakendatud Apache Spark "steroidide all."
Selgus, et AWS-is on olemas oma versioon Hive/Pig/Spark virnast. Hive'i rolli, s.t. failide ja nende tüüpide katalooge DataLakese, täidab teenus "Data catalog", mis ei peida oma ühilduvust Apache Hive formaadiga. Sellesse teenusesse tuleb lisada teave selle kohta, kus teie failid asuvad ja millises vormingus need on. Andmed võivad olla mitte ainult s3-is, vaid ka andmebaasis, kuid sellest postitusest ei räägi. Nii on meie DataLake'i andmekataloog korraldatud:
Failid on registreeritud, suurepärane. Kui failid on uuendatud, käivitame kas käsitsi või ajakava järgi crawler'id, mis värskendavad neist teavet järvele ning salvestavad selle. Edasi saab järve andmeid töödelda ja tulemusi kuhugi edastada. Kõige lihtsamal juhul laadime need samuti s3. Andmete töötlemist saab teha igal pool, kuid soovitatakse seadistada töötlemisprotsess Apache Spark klastris, kasutades laiendatud võimalusi AWS Glue API kaudu. Sisuliselt saab kasutada vana head ja tuttavat koodi pythonis librariga pyspark ning seadistada selle täitmine N nodas, millel on jälgimise võimalus, ilma et peaks süüvima Hadoop'i sisusse või tõmbama docker-konteinereid ning lahendama sõltuvuskonflikte.
Veel kord — lihtne idee. Apache Spark'i seadistamine ei ole vajalik, tuleb vaid kirjutada pythonis kood pyspark'ile, testida seda kohalikult töölaual ja seejärel käivitada suurtes klastrites pilves, märkides, kus algandmed asuvad ja kuhu tulemus salvestada. Mõnikord on see vajalik ja kasulik ning nii on see meil seadistatud:
Seega, kui on vaja midagi arvutada Spark-klusteris S3 andmete põhjal, siis kirjutame Python/PySpark koodi, testime ja lähememe julgelt pilve.
Aga mis orkestreerimisega? Ja kui ülesanne kokku kukkus? Jah, on soovitatud luua kena voog Apache Pigi stiilis ja me isegi proovisime neid, aga otsustasime kasutada oma sügavalt kohandatud orkestreerimist PHP ja JavaScriptis (ma mõistan, et tekkib kognitiivne dissonants, aga see töötab, juba aastaid ja ilma vigadeta).
Hoidla järvefailide formaat on võtmetähtsusega tulemuslikkusele.
On väga, väga oluline mõista veel kahte olulist punkti. Etandmepäringud failide kohta järves toimuksid võimalikult kiiresti ja et tulemuslikkus ei halveneks uue teabe lisamisel, tuleb:
- Failide veerud hoida eraldi (et ei peaks lugema kõiki ridu, et mõista, mis veergudes on). Selleks valisime parqueti formati koos tihendamisega.
- On väga oluline jagada faile kaustades stiilis: keel, aasta, kuu, päev, nädal. Mootorid, mis mõistavad seda tüüpi shardimist, vaatavad ainult vajalikesse kaustadesse, mitte ei läbi kõiki andmeid järjestikku.
Põhimõtteliselt paigutate selle meetodi abil algandmed kõige tõhusamal viisil, et analüüsida neid erinevate analüüsi mootorite poolt, mis suudavad sharded kaustadesse selektiivselt siseneda ja lugeda ainult vajalikke veerge. Andmete 'üleslaadimist' pole vajagi (sest salvestus lihtsalt plahvatab) — lihtsam on kohe mõistlikult paigutada need failisüsteemi õiges formaadis. Loomulikult on selge, et DataLake'is tohutu csv-faili hoidmine, mida tuleb terve rida haaval lugeda klastriga veergude ekstrahimiseks — ei ole väga mõistlik. Mõelge veel kord kahe eespool mainitud punkti üle, kui te pole veel aru saanud, miks seda kõike on vaja.
AWS Athena — nagu tulnukas karbist
Ja siin, järve luues, sattusime kuidagi juhuslikult Amazon Athenale. Ühtäkki selgus, et paigutades õigesse (parquet) veergude formaati meie tohutud logifailid shardide kaustadesse — saame neid kiiresti analüüsida ja luua aruandeid ILMA, ilma Apache Spark/Glue klastrita.
Athenat engine, mis töötab s3-s olevate andmete peal, põhineb legendaarse — MPP (massive parallel processing) lähenemise esindaja andmete töötlemiseks, mis toob andmed sealt, kus nad asuvad, alates s3 ja Hadoopist kuni Cassandra ja tavaliste tekstifailideni. Peab lihtsalt paluma Athenal SQL-päringut täita, ja edasi „töötab kõik kiiresti ja automaatselt“. Oluline on märkida, et Athena on „nutikas“, käib vaid vajalikelt shardeeritud kaustadelt ja loeb ainult vajaduspärased veerud päringus.
Athenale esitatud päringute tasustamine on samuti huvitav. Me maksame . St. mitte masinate arvu eest klastris minutis, vaid … tegelikult skaneeritud 100-500 masina ulatuses ainult selleks vajalikud andmed päringu täitmiseks.
Ja küsides ainult vajalikke veerge õigesti shardeeritud kaustadest, selgus, et Athena teenuse hind on meile paar kümmet dollarit kuus. No suurepärane, peaaegu tasuta võrreldes klastrite analüütikaga!
Siin on, muide, kuidas me oma andmeid s3-s shardeerime:
Lühikese ajaga on ettevõttes täiesti erinevad osakonnad, alates infotehnoloogiast kuni analüütikani, hakanud aktiivselt päringute esitamiseks Athena poole ja kiiresti, sekunditega, saama kasulikke vastuseid „suurtelt” andmetelt üsna pika aja jooksul: kuud, pool aastat jne.
Kuid me läksime kaugemale ja hakkasime vastuseid otsima pilvest : analüütik tavapärases konsoolis kirjutab SQL-päringu, mis 100–500 masinal „väikese hinnaga” kaevab andmeid s3-st ja toob vastuse tavaliselt välja sekundite jooksul. Mugav. Ja kiire. Siiani ei suuda uskuda.
Kokkuvõttes, otsustades hoida andmeid s3-s, efektiivses veergude formaadis ja mõistlike andmete jagamistega kaustade lõikes… saime DataLake'i ja kiire ja odava analüütilise mootori — tasuta. Ja sellest sai ettevõttes väga populaarne, kuna see mõistab SQL-i ja töötab kordades kiiremini kui klastrite käivitamine/peatamine/seadistamine. "Ja kui tulemus on sama, miks maksta rohkem?"
Päring Athena poole näeb välja umbes nii. Soovi korral võib loomulikult vormida piisavalt , kuid piirdume lihtsa rühmitamisega. Vaatame, millised vastuskoodid kliendil olid paar nädalat tagasi veebiserveri töölogides ja veendume, et vigu pole.
Järeldused
Pärast, ütleme, mitte just pikka, kuid valus teekonda, pidevalt riske ja keerukuse taset ning toetuse maksumust adekvaatselt hinnates, leidsime lahenduse DataLake'i ja analüüsi jaoks, mis on meid üllatanud nii kiiruselt kui ka omamiskulu poolest.
Selgus, et tõhus, kiire ja madala tööjõukuluga DataLake'i ehitamine erinevate ettevõtte osakondade vajaduste jaoks on täiesti teostatav isegi kogenud arendajate jaoks, kes pole kunagi töötanud arhitektidena, ei oska joonistada ruute ruutude peale koos nooltega ning tunnevad ainult 50 termini ekosüsteemist Hadoop.
Teekonna alguses valutas pea tohutu hulga avatud ja suletud tarkvara ning tulevaste põlvkondade ees seisva vastutuse koormast. Alustage oma DataLake'i loomist lihtsatest tööriistadest: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3 ..., kogudes tagasisidet ja sügavalt mõistes toimuvate protsesside füüsikat. Kõik keeruline ja segane andke vaenlastele ja konkurentidele.
Kui te ei soovi minna pilve ning armastate avatud projekte hallata, uuendada ja plaastritega katab, saab meie sarnase paigutuse kohapeal üles ehitada, odavatest kontorimasinatest Hadoopi ja Presto peal. Peamine on mitte peatuda ja edasi liikuda, arvestada, otsida lihtsaid ja selgeid lahendusi ning kõik kindlasti õnnestub! Kui teil on kõigile edu ja kohtumiseni!
Allikas: habr.com
