Elame hämmastaval ajal, mil saate kiiresti ja lihtsalt ühendada mitu valmis avatud lähtekoodiga tööriista, seadistada need stackoverflow nõuannete kohaselt "teadvuse väljalülitamisega" ilma "mitmesse tähte" süvenemata ja käivitada. neid kommertskasutuseks. Ja kui teil on vaja värskendada/laiendada või keegi kogemata paar masinat taaskäivitab - saate aru, et on alanud mingi obsessiivne halb unenägu, kõik on muutunud tundmatuseni dramaatiliselt keeruliseks, tagasiteed pole, tulevik on ebamäärane ja turvalisem, programmeerimise asemel aretage mesilasi ja tehke juustu.
Pole asjata, et kogenumad kolleegid, kelle pea on vigadest pungil ja seetõttu juba hallid, kaaluvad „kuubikutes“ olevate „konteinerite“ pakkide uskumatult kiiret juurutamist kümnetes „moekates keeltes“ serverites, millel on sisseehitatud tugi asünkroonne mitteblokeeriv I/O, naerata tagasihoidlikult . Ja nad jätkavad vaikselt "man ps" uuesti lugemist, süvenevad "nginxi" lähtekoodi, kuni neil silmad verd jooksevad, ja kirjutavad, kirjutavad, kirjutavad ühikuteste. Kolleegid teavad, et kõige huvitavam saab olema siis, kui “see kõik” ühel päeval aastavahetuse öösel mängu saab. Ja neile aitab ainult sügav arusaam unixi olemusest, päheõpitud TCP/IP olekutabelist ja põhilistest sortimis-otsingu algoritmidest. Et süsteem uuesti ellu äratada, kui kellahelid löövad.
Ah jaa, ma läksin veidi segaseks, aga loodan, et suutsin ootuse seisu edasi anda.
Täna tahan jagada meie kogemust DataLake'i mugava ja odava pinu juurutamisel, mis lahendab enamiku ettevõtte analüütilistest ülesannetest täiesti erinevate struktuuriüksuste jaoks.
Mõni aeg tagasi jõudsime arusaamisele, et ettevõtted vajavad üha enam nii toote- kui ka tehnilise analüüsi vilju (rääkimata kirsist tordil masinõppe näol) ning trendide ja riskide mõistmiseks – tuleb koguda ja analüüsida. järjest rohkem mõõdikuid.
Põhiline tehniline analüüs Bitrix24-s
Mitu aastat tagasi, samaaegselt Bitrix24 teenuse käivitamisega, investeerisime aktiivselt aega ja ressursse lihtsa ja töökindla analüüsiplatvormi loomisesse, mis aitaks kiiresti näha infrastruktuuri probleeme ja planeerida järgmist sammu. Loomulikult oli soovitatav võtta valmis tööriistad, mis oleksid võimalikult lihtsad ja arusaadavad. Selle tulemusena valiti seireks nagios ning analüüsiks ja visualiseerimiseks munin. Nüüd on meil nagios tuhandeid tšekke, muninis sadu graafikuid ja meie kolleegid kasutavad neid edukalt iga päev. Mõõdikud on selged, graafikud on selged, süsteem on juba mitu aastat usaldusväärselt töötanud ning sellele lisandub regulaarselt uusi teste ja graafikuid: uue teenuse käiku panemisel lisame mitmeid teste ja graafikuid. Edu.
Sõrm pulsil – täiustatud tehniline analüüs
Soov saada teavet probleemide kohta "võimalikult kiiresti" viis meid aktiivsete katseteni lihtsate ja arusaadavate tööriistadega - pinba ja xhprof.
Pinba saatis meile UDP-pakettidena statistika PHP-s veebilehtede osade töökiiruse kohta ja saime veebis MySQL-i salvestusruumis (Pinbal on oma MySQL-i mootor kiireks sündmuste analüüsiks) näha lühikest probleemide loetelu ja reageerida neid. Ja xhprof lubas meil automaatselt koguda klientidelt kõige aeglasemate PHP lehtede täitmise graafikuid ja analüüsida, mis selleni viia võib - rahulikult teed valades või midagi kangemat.
Mõni aeg tagasi täiendati tööriistakomplekti teise üsna lihtsa ja arusaadava mootoriga, mis põhineb pöördindekseerimise algoritmil, mis on suurepäraselt rakendatud legendaarses Lucene'i raamatukogus - Elastic/Kibana. Lihtne idee mitme lõimega dokumentide salvestamiseks logide sündmuste põhjal pöördvõrdeliseks Lucene'i indeksiks ja nende kaudu tahkjaotuse abil kiire otsing osutus tõeliselt kasulikuks.
Hoolimata Kibana visualisatsioonide üsna tehnilisest väljanägemisest madala taseme mõistetega, nagu "ämber" "voogab üles" ja veel täielikult unustatud relatsioonialgebra uuesti leiutatud keelest, hakkas tööriist meid aitama järgmistes ülesannetes:
- Mitu PHP viga oli Bitrix24 kliendil viimase tunni jooksul p1 portaalis ja millised? Saage aru, andke andeks ja parandage kiiresti.
- Mitu videokõnet tehti Saksamaal portaalides eelneva 24 tunni jooksul, millise kvaliteediga ja kas kanali/võrguga oli probleeme?
- Kui hästi töötab süsteemi funktsionaalsus (meie C-laiendus PHP jaoks), mis on koostatud allikast uusimas teenusevärskenduses ja levitatud klientidele? Kas on segfaults?
- Kas kliendiandmed mahuvad PHP mällu? Kas protsessidele eraldatud mälu ületamisel on vigu: "mälu otsas"? Otsige üles ja neutraliseerige.
Siin on konkreetne näide. Vaatamata põhjalikule ja mitmetasandilisele testimisele sai väga ebastandardse korpuse ja kahjustatud sisendandmetega klient tüütu ja ootamatu vea, helises sireen ja selle kiire parandamise protsess algas:
Lisaks võimaldab kibana korraldada teavitusi teatud sündmuste kohta ning lühikese aja jooksul hakkasid ettevõttes tööriista kasutama kümned töötajad erinevatest osakondadest – alates tehnilisest toest ja arendusest kuni kvaliteedikontrollini.
Ettevõtte mis tahes osakonna tegevus on muutunud mugavaks jälgida ja mõõta – serverite logide käsitsi analüüsimise asemel tuleb logid üks kord seadistada ja need elastsesse klastrisse saata, et nautida näiteks kibanas mõtisklemist. armatuurlaud müüdud kahepealiste kassipoegade arv, mis on trükitud 3D-printeriga viimase kuukuu jooksul.
Põhiline ärianalüüs
Kõik teavad, et ärianalüütika algab ettevõtetes sageli äärmiselt aktiivsest, jah, Exceli kasutamisest. Kuid peamine on see, et see ei lõpe sellega. Õli lisab tulle ka pilvepõhine Google Analytics – hakkate heade asjadega kiiresti harjuma.
Meie harmooniliselt arenevas ettevõttes hakkas siin-seal ilmuma suuremate andmetega intensiivsema töö “prohveteid”. Regulaarselt hakkas tekkima vajadus põhjalikumate ja mitmetahulisemate aruannete järele ning läbi erinevate osakondade kuttide jõupingutuste organiseeriti mõni aeg tagasi lihtne ja praktiline lahendus - ClickHouse'i ja PowerBI kombinatsioon.
Päris pikka aega aitas see paindlik lahendus palju, kuid tasapisi hakkas tekkima arusaam, et ClickHouse pole kumm ja niisama mõnitada ei saa.
Siin on oluline hästi aru saada, et ClickHouse, nagu Druid, nagu Vertica, nagu Amazon RedShift (mis põhineb postgresil), on analüütilised mootorid, mis on optimeeritud üsna mugavaks analüüsiks (summad, agregatsioonid, miinimum-maksimum veergude kaupa ja mõned võimalikud liitumised). ), sest organiseeritud relatsioonitabelite veergude tõhusaks salvestamiseks, erinevalt MySQL-ist ja teistest meile teadaolevatest (ridadele orienteeritud) andmebaasidest.
Sisuliselt on ClickHouse lihtsalt mahukam "andmebaas", millel on mitte eriti mugav punkt-punkti sisestamine (nii see on mõeldud, kõik on ok), kuid meeldiva analüüsi ja hulga huvitavaid võimsaid funktsioone andmetega töötamiseks. Jah, saate isegi klastri luua, kuid saate aru, et naelte löömine mikroskoobiga pole täiesti õige ja hakkasime otsima muid lahendusi.
Nõudlus pythonite ja analüütikute järele
Meie ettevõttes on palju arendajaid, kes kirjutavad 10-20 aasta jooksul peaaegu iga päev koodi PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash keeles. Samuti on palju kogenud süsteemiadministraatoreid, kes on kogenud rohkem kui ühte täiesti uskumatut katastroofi, mis ei sobi statistika seadustega (näiteks kui suurem osa raid-10 kettaid hävib tugeva välgulöögi tõttu). Sellistes tingimustes polnud pikka aega selge, mis on "püütoni analüütik". Python on nagu PHP, ainult nimi on veidi pikem ja tõlgi lähtekoodis on veidi vähem jälgi meelt muutvatest ainetest. Kuna aga koostati üha rohkem analüütilisi aruandeid, hakkasid kogenud arendajad üha enam mõistma kitsa spetsialiseerumise tähtsust sellistele tööriistadele nagu numpy, pandas, matplotlib, seaborn.
Otsustavat rolli mängis tõenäoliselt töötajate äkiline minestamine sõnade "logistiline regressioon" kombinatsioonist ja suurte andmete tõhusa aruandluse demonstreerimine, kasutades jah, jah, pysparki.
Apache Spark, selle funktsionaalne paradigma, millele relatsioonialgebra sobib ideaalselt, ja selle võimalused jätsid MySQL-iga harjunud arendajatele niivõrd mulje, et vajadus tugevdada ridamisi kogenud analüütikutega sai selgeks päevaga.
Apache Sparki/Hadoopi edasised katsed õhku tõusta ja mis ei läinud päris skripti järgi
Peagi selgus aga, et Sparkiga pole süsteemselt midagi päris korras või oli lihtsalt vaja käsi paremini pesta. Kui Hadoop/MapReduce/Lucene pinu tegid üsna kogenud programmeerijad, mis on ilmselge, kui vaadata tähelepanelikult Java lähtekoodi või Doug Cuttingu ideid Lucene'is, siis äkki on Spark kirjutatud eksootilises keeles Scala, mis on praktilisuse seisukohast väga vastuoluline ja praegu ei arene. Ja Spark-klastri arvutuste regulaarne langus, mis on tingitud ebaloogilisest ja mitte väga läbipaistvast tööst mälu jaotusega vähendamise operatsioonide jaoks (saabub palju võtmeid korraga), on loonud selle ümber oreooli millegi suhtes, millel on ruumi kasvada. Lisaks raskendas olukorda suur hulk kummalisi avatud porte, kõige arusaamatumates kohtades kasvavad ajutised failid ja jar-sõltuvused – mis tekitas süsteemiadministraatoritel lapsepõlvest hästi tuntud tunde: äge vihkamine (või võib-olla neil oli vaja käsi seebiga pesta).
Selle tulemusena oleme "ellu jäänud" mitmed sisemised analüütilised projektid, mis kasutavad aktiivselt Apache Sparki (sh Spark Streaming, Spark SQL) ja Hadoopi ökosüsteemi (ja nii edasi ja nii edasi). Hoolimata sellest, et aja jooksul õppisime “seda” üsna hästi ette valmistama ja jälgima ning andmete olemuse muutumise ja ühtlase RDD räsimise tasakaalustamatuse tõttu “see” praktiliselt lakkas järsku kokku jooksmast, tekkis soov midagi juba valmis võtta. , uuendatud ja kuskil pilves hallatud muutus aina tugevamaks. Just sel ajal proovisime kasutada Amazon Web Servicesi valmis pilvekomplekti - ja seejärel püüdis selle abil probleeme lahendada. EMR on Apache Spark, mille on koostanud Amazon koos ökosüsteemi lisatarkvaraga, sarnaselt Cloudera/Hortonworksi konstruktsioonidele.
Analüütika jaoks on vaja kiiresti kasutada kummifailide salvestusruumi
Hadoopi/Sparki “küpsetamise” kogemus erinevate kehaosade põletustega ei olnud asjatu. Üha enam kasvas vajadus luua ühtne, odav ja töökindel failihoidla, mis oleks vastupidav riistvaratõrgetele ja kuhu oleks võimalik salvestada erinevatest süsteemidest pärit faile erinevates formaatides ning teha nendest andmetest aruannete jaoks tõhusaid ja ajasäästlikke näidiseid. selge.
Samuti soovisin, et selle platvormi tarkvara uuendamine ei muutuks uusaasta õudusunenäoks 20-leheküljeliste Java jälgede lugemise ja kilomeetripikkuste detailide klastri logide analüüsimisega Spark History Serveri ja taustvalgustusega suurendusklaasi abil. Tahtsin lihtsat ja läbipaistvat tööriista, mis ei nõuaks regulaarset kapoti alla sukeldumist, kui arendaja standardne MapReduce päring lakkas täitmast, kui andmete vähendamise töötaja mälust välja kukkus mitte eriti hästi valitud lähteandmete jaotusalgoritmi tõttu.
Kas Amazon S3 on DataLake'i kandidaat?
Hadoopi/MapReduce'i kogemus õpetas meile, et vajame skaleeritavat, usaldusväärset failisüsteemi ja selle peale skaleeritavaid töötajaid, kes "tuleksid" andmetele lähemale, et mitte juhtida andmeid üle võrgu. Töötajatel peaks olema võimalus lugeda andmeid erinevates vormingutes, kuid soovitavalt mitte lugeda mittevajalikku infot ning anda andmeid eelnevalt töötajatele sobivas vormingus salvestada.
Taaskord põhiidee. Ei taheta suurandmeid “valada” ühte klastri analüütilisse mootorisse, mis varem või hiljem lämbub ja sa pead need koledasti kildudeks kiskuma. Soovin salvestada faile, lihtsalt faile, arusaadavas vormingus ja teha nende kohta tõhusaid analüütilisi päringuid, kasutades erinevaid, kuid arusaadavaid tööriistu. Ja erinevas vormingus faile tuleb aina juurde. Ja parem on purustada mitte mootor, vaid lähteandmed. Me vajame laiendatavat ja universaalset DataLake'i, otsustasime...
Mis siis, kui salvestate failid tuttavasse ja tuntud skaleeritavasse pilvesalvestusse Amazon S3, ilma et peaksite Hadoopist ise kotlette valmistama?
On selge, et isikuandmeid on vähe, aga mis saab teistest andmetest, kui võtame need välja ja juhime neid tõhusalt?
Amazon Web Servicesi klastri-bigdata-analüütika ökosüsteem – väga lihtsate sõnadega
AWS-i kogemuse põhjal otsustades on Apache Hadoop/MapReduce olnud seal pikka aega aktiivselt kasutusel erinevate kastmete all, näiteks DataPipeline'i teenuses (kadestan kolleege, nad õppisid seda õigesti valmistama). Siin seadistame varukoopiad erinevatest teenustest DynamoDB tabelitest:
Ja need on juba mitu aastat jooksnud regulaarselt manustatud Hadoop/MapReduce klastrites nagu kellavärk. "Seadista ja unusta":
Samuti saate tõhusalt tegeleda andmete satanismiga, seadistades analüütikute jaoks pilves Jupiteri sülearvutid ja kasutades AWS SageMaker teenust tehisintellekti mudelite lahingus treenimiseks ja juurutamiseks. Meie jaoks näeb see välja järgmine:
Ja jah, võite võtta endale või analüütikule sülearvuti pilvest ja kinnitada selle Hadoopi/Sparki klastri külge, teha arvutused ja seejärel kõik kokku panna:
Tõeliselt mugav üksikute analüütiliste projektide jaoks ja mõne jaoks oleme edukalt kasutanud EMR-teenust suuremahuliste arvutuste ja analüüside tegemiseks. Kuidas on lood DataLake'i süsteemilahendusega, kas see töötab? Sel hetkel olime lootuse ja meeleheite piiril ning jätkasime otsinguid.
AWS Glue – korralikult pakendatud Apache Spark steroididel
Selgus, et AWS-il on "Taru/Siga/Säde" virnast oma versioon. Taru roll, s.o. Failide ja nende tüüpide kataloogi DataLake'is teostab teenus "Andmekataloog", mis ei varja oma ühilduvust Apache Hive vorminguga. Peate sellesse teenusesse lisama teavet selle kohta, kus teie failid asuvad ja millises vormingus need on. Andmed võivad olla mitte ainult s3-s, vaid ka andmebaasis, kuid see pole selle postituse teema. Meie DataLake'i andmekataloog on korraldatud järgmiselt.
Failid on registreeritud, suurepärane. Kui failid on uuendatud, käivitame kas käsitsi või graafiku alusel roomajad, mis uuendavad nende kohta järvest infot ja salvestavad need. Siis saab järve andmeid töödelda ja tulemused kuhugi üles laadida. Lihtsamal juhul laadime üles ka s3-sse. Andmetöötlust saab teha kõikjal, kuid on soovitatav konfigureerida töötlemine Apache Sparki klastris, kasutades AWS Glue API täiustatud võimalusi. Tegelikult saate pysparki teegi abil võtta vana hea ja tuttava pythoni koodi ja seadistada selle käivitamise teatud mahuga klastri N sõlmes koos jälgimisega, ilma et peaksite Hadoopi sisemustesse süvenema ja dokkijate-mokeri konteinereid lohistama ja sõltuvuskonflikte kõrvaldama. .
Taas üks lihtne idee. Apache Sparki pole vaja seadistada, tuleb lihtsalt kirjutada pysparki jaoks pythoni kood, seda kohapeal oma töölaual testida ja seejärel pilves suures klastris käivitada, täpsustades, kus on lähteandmed ja kuhu tulemus panna. Mõnikord on see vajalik ja kasulik ning me selle seadistame järgmiselt.
Seega, kui teil on vaja s3-s olevaid andmeid kasutades Spark-klastris midagi arvutada, kirjutame koodi python/pysparkis, testime seda ja edu pilvele.
Aga orkestratsioon? Mis siis, kui ülesanne kukub ja kaob? Jah, tehakse ettepanek teha ilus torujuhe Apache Pig stiilis ja me isegi proovisime neid, kuid praegu otsustasime kasutada oma sügavalt kohandatud orkestratsiooni PHP-s ja JavaScriptis (ma saan aru, on kognitiivne dissonants, kuid see töötab, aastat ja vigadeta).
Järves salvestatud failide formaat on jõudluse võti
On väga-väga oluline mõista veel kahte põhipunkti. Selleks, et päringud järve failiandmete kohta saaksid täidetud võimalikult kiiresti ja jõudlus uue teabe lisamisel ei halveneks, peate:
- Salvestage failide veerud eraldi (et te ei peaks veergude sisu mõistmiseks kõiki ridu lugema). Selleks võtsime parketi formaadi koos kompressiooniga
- Väga oluline on jagada failid sellistesse kaustadesse nagu keel, aasta, kuu, päev, nädal. Mootorid, mis mõistavad seda tüüpi jagamist, vaatavad ainult vajalikke kaustu, ilma kõiki andmeid järjest läbi sõelumata.
Põhimõtteliselt paigutate sel viisil kõige tõhusamal kujul lähteandmed üles riputatud analüütiliste mootorite jaoks, mis isegi killustatud kaustades saavad valikuliselt sisestada ja lugeda failidest ainult vajalikke veerge. Te ei pea andmeid kuskil "täitma" (mäluseade lihtsalt puruneb) - lihtsalt sisestage need kohe targalt õiges vormingus failisüsteemi. Muidugi peaks siin olema selge, et tohutu csv-faili salvestamine DataLake'i, mida klaster peab veergude ekstraktimiseks esmalt rida-realt läbi lugema, ei ole eriti soovitatav. Mõelge ülaltoodud kahele punktile uuesti, kui pole veel selge, miks see kõik juhtub.
AWS Athena – jack-in-the-box
Ja siis sattusime järve loomisel kuidagi kogemata Amazon Athena peale. Järsku selgus, et korrastades meie tohutud logifailid hoolikalt õiges (parketi) veeru formaadis kaustakildudeks, saab nendest väga kiiresti teha ülimalt informatiivseid valikuid ja koostada aruandeid ILMA, ilma Apache Spark/Glue klastrita.
S3 andmetel töötav Athena mootor põhineb legendaarsel - MPP (massiivne paralleeltöötlus) lähenemisviiside perekonna esindaja andmetöötlusele, võttes andmeid seal, kus need asuvad, alates s3-st ja Hadoopist kuni Cassandra ja tavaliste tekstifailideni. Peate lihtsalt paluma Athenal SQL-päringu käivitada ja siis kõik "töötab kiiresti ja automaatselt". Oluline on märkida, et Athena on "tark", see läheb ainult vajalikesse killustatud kaustadesse ja loeb ainult päringus vajalikke veerge.
Huvitav on ka Athena taotluste hinnakujundus. Me maksame . Need. mitte masinate arvu kohta klastris minutis, vaid... 100-500 masinal reaalselt skannitud andmete puhul ainult päringu täitmiseks vajalikke andmeid.
Ja õigesti killustatud kaustadest ainult vajalikke veerge küsides selgus, et Athena teenus maksab meile kümneid dollareid kuus. Noh, suurepärane, peaaegu tasuta, võrreldes klastrite analüüsiga!
Muide, siin on, kuidas me oma andmeid s3-s killustame:
Selle tulemusena hakkasid ettevõtte täiesti erinevad osakonnad, alates infoturbest ja lõpetades analüütikaga, lühikese aja jooksul aktiivselt Athenale päringuid tegema ja kiiresti, sekunditega, saama kasulikke vastuseid "suurtelt" andmetelt üsna pikkade perioodide jooksul: kuude jooksul, pool aastat jne P.
Kuid me läksime kaugemale ja hakkasime vastuseid otsima pilve : analüütik kirjutab tuttavas konsoolis SQL-päringu, mis 100-500 masinal “sentide eest” saadab andmed s3-le ja tagastab vastuse tavaliselt mõne sekundiga. Mugav. Ja kiiresti. Ma ei suuda seda siiani uskuda.
Selle tulemusena, olles otsustanud salvestada andmed s3-s, tõhusas veeruvormingus ja mõistliku andmete kaustadesse jaotamisega... saime DataLake'i ning kiire ja odava analüütilise mootori – tasuta. Ja ta sai ettevõttes väga populaarseks, sest... mõistab SQL-i ja töötab suurusjärgus kiiremini kui klastrite käivitamise/peatamise/seadistamisega. "Ja kui tulemus on sama, siis miks maksta rohkem?"
Taotlus Athenale näeb välja umbes selline. Soovi korral saab muidugi piisavalt vormida , kuid piirdume lihtsa rühmitamisega. Vaatame, millised vastusekoodid olid kliendil paar nädalat tagasi veebiserveri logides ja veendume, et tõrkeid poleks:
Järeldused
Olles läbinud, et mitte öelda pika, kuid valusa tee, hinnates pidevalt adekvaatselt riske ja tugiteenuste keerukuse taset ja maksumust, leidsime DataLake'i ja analüütika jaoks lahenduse, mis ei lakka meid rõõmustamas nii kiiruse kui ka omamiskuluga.
Selgus, et efektiivse, kiire ja odavalt opereeritava DataLake’i ehitamine ettevõtte täiesti erinevate osakondade vajadusteks on täiesti jõukohane isegi kogenud arendajatele, kes pole kunagi arhitektina töötanud ega oska ruutudele ruutudele joonistada. nooled ja tean Hadoopi ökosüsteemist 50 terminit.
Rännaku alguses läks mu pea lõhki paljudest metsikutest avatud ja suletud tarkvara loomaaedadest ning arusaamisest, milline on vastutuskoorem järglaste ees. Lihtsalt alustage oma DataLake'i ehitamist lihtsate tööriistade abil: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., kogudes tagasisidet ja mõistmaks põhjalikult toimuvate protsesside füüsikat. Kõik keeruline ja hägune – andke see vaenlastele ja konkurentidele.
Kui te ei soovi pilve minna ja teile meeldib avatud lähtekoodiga projekte toetada, värskendada ja parandada, saate meiega sarnase skeemi ehitada kohapeal, odavatel kontorimasinatel, mille peal on Hadoop ja Presto. Peaasi, et mitte peatuda ja edasi liikuda, arvestada, otsida lihtsaid ja selgeid lahendusi ning kõik saab kindlasti korda! Edu kõigile ja kohtumiseni!
Allikas: www.habr.com