Me elame imeliselt ajal, mil on võimalik kiiresti ja lihtsalt ühendada mitu avatud tööriista, seadistada neid "teadvuseta" Stack Overflow'i näpunäidete järgi, süvenemata "pikadesse sõnadesse", ning käivitada neid äriliseks kasutamiseks. Ja kui on aeg uuendada/ülendada või keegi kogemata paar masinat taaskäivitab — mõista, et on alanud mingi kinnisidee halb uni, kõik on järsku keeruliseks muutunud, tagasiteed pole, tulevik on hägune ja turvalisem on programmimise asemel mesilasi kasvatada ja juustu teha.
Ei ole asjata, et kogenumad kolleegid, kellel on juba hallid juuksed vigade tõttu, vaatavad uskumatu kiiresti kokkupandud "konteinereid" soovitud "kuubikutes" kümnetes serverites "moekates keeltes", kus on integreeritud asünkroonne mitte-blokeeriv sisendi-väljundi toetus — alandlikult naeratavad. Ja vaikides jätkavad nad "man ps" lugemist, sukelduvad silmad veretuks "nginx" lähtekoodidesse ja kirjutavad-kirjutavad-kirjutavad üksusteste. Kolleegid teavad, et kõige huvitavam on ees, kui "kõik see" ühel öösel muundub uue aasta eel. Ja ainus, mis neid aitab, on sügav arusaam Unix'i olemusest, TCP/IP seisundite õppimisest ja põhiotsingu-sortimise algoritmidest. Et kellade löömisel süsteem jälle ellu äratada.
Ah jah, veidi kõrvale kaldusin, aga loodan, et olete suutnud edasi anda ootusärevuse seisundi.
Täna tahan jagada meie kogemust mugava ja odava DataLake tehnoloogia rakendamisest, mis lahendab enamikus ettevõttes erinevaid analüüsiülesandeid.
Mõni aeg tagasi mõistsime, et ettevõtted vajavad üha enam toote- ja tehnilise analüüsi vilju (rääkimata koogile pandud kirssidest machine learning'i näol) ning trendide ja riskide mõistmiseks — tuleb koguda ja analüüsida üha rohkem ja rohkem meetrikaid.
Põhiline tehniline analüüs "Bitrix24"-s
Mõned aastat 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 planeerida järgmisi samme. Loomulikult soovisime kasutada olemasolevaid, võimalikult lihtsate ja arusaadavate tööriistadega. Tulemusena valiti nagios jälgimiseks ja munin analüüsiks ja visualiseerimiseks. Nüüd on meil tuhandeid kontrolle nagioses, sadu graafikuid muninis ja kolleegid kasutavad neid igapäevaselt ja edukalt. Näidud on arusaadavad, graafikud selged, süsteem on juba mitu aastat usaldusväärselt töötanud ning sellele lisatakse pidevalt uusi teste ja graafikuid: kui käivitame uue teenuse, lisame mitmeid teste ja graafikuid. Head teed.
Käsi pulsil – ulatuslik tehniline analüütika
Soov saada teavet probleemidest «niipea kui võimalik» viis meid aktiivsete katseteni lihtsate ja arusaadavate tööriistadega – pinba ja xhprof.
Pinba saatis meile UDP-pakkides statistikat PHP veebilehe osade töökiirusest ning oli võimalik reaalajas näha MySQL hoidlas (pinba-ga kaasas on oma MySQL mootor kiirete sündmuste analüüsiks) lühikest probleemide nimekirja ning nendesse reageerida. Xhprof aga võimaldas automaatselt koguda info kõige aeglasemate PHP-lehtede täitmisgraafikute kohta ning analüüsida, mis sellele võis viia – rahulikult, tees kuumutades või midagi tugevamat.
Mõni aeg tagasi täiendati tööriistakasti veel ühe üsna lihtsa ja arusaadava mootoriga, mis põhineb tagasivõtualgoritmil, mis on suurepäraselt teostatud legendaarse Lucene’i raamatukogus – Elastic/Kibana. Lihtne mõte mitme lõimega dokumentide kirjutamisest Lucene’i pöördindeksisse logisündmuste alusel ja kiire otsing nende põhjal kasutades fasetilisi jagamisi – osutus tõeliselt kasulikuks.
Hoolimata suhteliselt tehnilisest väljanägemisest visualiseerimistest Kibanas koos «ülesse voolavatega» madala taseme mõistetega, nagu «bucket», ja uuesti leiutatud keele täiesti unustatud relatsiooni algebrast – on tööriist hakanud hästi aitama meid järgmistes ülesannetes:
- Kui palju oli klientide Bitrix24 PHP vigu p1 portaalis viimase tunni jooksul ja millised? Aru saada, andestada ja kiiresti parandada.
- Kui palju videokõnesid tehti Saksamaal portaalides viimase 24 tunni jooksul, millise kvaliteediga need olid ja kas esines probleeme kanali/võrguga?
- Kuidas toimib süsteemi funktsionaalsus (meie PHP jaoks C-s kirjutatud laiendus), mis on koostatakse lähtekoodidest teenuse viimases värskenduses ja klientidele tarnitud? Kas esineb segfault'e?
- Kas kliendi andmed salvestatakse PHP mällu? Kas esineb mälupiirangutega seotud vigu: „mälu otsas”? Leida ja kõrvaldada.
Siin on konkreetne näide. Mallet analüüsitakse ja muudetakse tugevalt, et korrigeerida klientide tegevust äärmiselt ebatavalistes olukordades, mis võivad olla kahjustatud sisendandmetega, ja see tõi kaasa ootamatu vea, mis nõudis kiiret parandamist:
Lisaks võimaldab Kibana korraldada teavitusi määratud sündmustest ja lühikese ajaga on sellest tööriistast saanud ettevõttes kümnete töötajate kasutatav, alates tugiteenustest ja arendamisest kuni QA-ni.
Iga osakonna tegevust ettevõttes on nüüd mugav jälgida ja mõõta — sadade serveri logide käsitsi analüüsimise asemel piisab logide parsimise ja saatmise seadistamisest elastic klastrisse, et nautida näiteks Kibana armatuurlauda, kus kuvatakse viimase kuu jooksul müüdud 3D-prinditud kahepea kasse.
Alustav ärianalüüs
Kõik teavad, et sageli algab ettevõtetes ärianalüüs äärmiselt aktiivsest Exceli kasutamisest. Kuid peamine on see, et see ei jääks ainult sinna. Google Analytics toob kahtlemata juurde head; heale harjub kiiresti.
Meie harmooniliselt arenevas ettevõttes hakkasid aeg-ajalt ilmuma „prohvetid”, kes soovitasid intensiivsemat töötlemist suuremate andmete üle. Järjest sagedamini ilmus vajadus süvitsi minevate ja mitmekesiste aruannete järele ning erinevate osakondade noorte jõupingutuste abil organiseeriti lihtne ja praktiline lahendus — ClickHouse ja PowerBI sidumine.
Pika aega aitas see paindlik lahendus suurepäraselt, kuid järk-järgult hakkas selguma, et ClickHouse ei ole elastne ja seda ei saa liiga palju koormata.
Siin on oluline hästi mõista, et ClickHouse, nagu ka Druid, Vertica ja Amazon RedShift (mis põhineb Postgresel), on analüüsimootorid, mis on optimeeritud üsna mugavaks analüüsiks (summad, agregatsioonid, vähemalt-maksimaalne veerus ja veidi saab ka liituda), kuna need on organiseeritud efektiivseks kolonniandmete hoidmiseks, erinevalt tuntud MySQL ja muudest (rida-orienteeritud) andmebaasidest.
Sisuliselt on ClickHouse lihtsalt suurem andmebaas, millel on mitte eriti mugav täppsisestamine (nii on plaanitud, kõik on okei), kuid meeldiv analüütika ja huvitavate võimsate andmetöötluse funktsioonide kogum. Jah, isegi klastrit saab luua — kuid te mõistate ju, et mitte ei pea naelutama küünega mikroskoobi abil ja me hakkasime otsima teisi lahendusi.
Nõudlus Python ja analüütikute järele
Meie ettevõttes on palju arendajaid, kes kirjutavad koodi peaaegu iga päev 10-20 aastat ja töötavad PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash keeles. Samuti on palju kogenud süsteemiadministraatoreid, kes on läbi elanud mitmeid uskumatuid katastroofe, mis ei mahu statistika seadustesse (nt, kui enamik kettaid hävitatakse RAID-10-s tugeva välguhammustuse tõttu). Sellistes tingimustes oli pikka aega ebaselge, mis on "Python analüütik". Python on ju nagu PHP, ainult nimi veidi pikem ja teadvust muutvaid aineid sisaldab interpreteerija lähtekoodis pisut vähem. Küll aga hakkasid kogenud arendajad, luues üha uusi analüütilisi aruandeid, üha sügavamalt mõistma kitsas spetsialiseerituse tähtsust sellistes tööriistades nagu numpy, pandas, matplotlib, seaborn.
Otsustavat rolli mängisid tõenäoliselt töötajate äkilised minestamised sõnade "logistiline regressioon" kombinatsiooni tõttu ja efektiivsete aruannete koostamise demonstreerimine suurte andmemasside põhjal, kasutades jah, jah, pyspark'i.
Apache Spark, selle funktsionaalne paradigma, millele rälja algebra sujuvalt sobib, ja võimalused avaldasid arendajatele, kes olid harjunud MySQL-iga, nii suurt muljet, et kogenud analüütikute rindade tugevdamise vajadus sai selgeks nagu päev.
Edasised katsed Apache Spark/Hadoop tõusta ja see, mis ei läinud sugugi plaanipäraselt
Kuid peagi sai selgeks, et Sparkiga on ilmselt midagi süsteemselt valesti või tuleks lihtsalt paremini käsi pesta. Kui Hadoop/MapReduce/Lucene'i raamistiku koostasid kogenud programmeerijad, mis on ilmselge, kui hoolikalt vaadata Java lähtekoodi või Doug Cutting'i ideid Lucenes, siis on Spark üllataval kombel kirjutatud väga vaieldavas ja praegu mitte arenevas eksootilises keeles Scala. Samuti põhjustas regulaarne arvutuste kokkuvarisemine Spark klastris loogika ja mitte väga läbipaistva mäluhaldamise tõttu reduce operatsioonide jaoks (palju võtmeid tuleb korraga) — tekitas selle ümber auriku, millel on veel kuhugi areneda. Täiendavalt süvendas olukorda suur hulk seletamatuid avatud porte, ajutisi faile, mis kasvasid kõige arusaamatutel kohtadel, ja jar-sõltuvusi — mis tekitas süsteemiadministraatorites tuttava ja halvasti alustatud tunde: raevukat viha (võib-olla oleks pidanud käsi seebi all pesema).
Me, tulemuseks, "ellujääme" mitu sisemist analüüsiprojekti, mis kasutavad aktiivselt Apache Spark'i (sealhulgas Spark Streaming, Spark SQL) ja Hadoopi ökosüsteemi (ja muud). Kuigi aja jooksul õppisime "seda" kenasti valmistama ja jälgima ning "see" lõpetas praktiliselt äkki kukkumise andmete olemuse muutumise ja RDD tasakaalustamatuse tõttu, grew desire to take something already prepared, updated, and managed somewhere in the cloud increasingly stronger. Just sel ajal proovime kasutada Amazon Web Services'i valmisseadet — ja hiljem püüdsime juba sellel probleemide lahendamiseks. EMR on Amazon'i valmistatud Apache Spark koos täiendava tarkvaraga ökosüsteemist, umbes nagu Cloudera/Hortonworks kogum.
"Kummine" andmehoidla analüütikaks — terav vajadus
Hadoop/Spark-i "valmistamise" kogemused kehavigastuste näol ei läinud raisku. Üha selgemaks tõusis vajadus luua odav ja usaldusväärne andmehoidla, mis oleks vastupidav riistvaraliste riketega ja kus saaks hoida faile erinevates formaatides erinevatest süsteemidest ning teha nende andmete kohta tõhusalt ja mõistliku ajaga aruandeid.
Samuti soovisime, et selle platvormi tarkvara värskendamine ei muutuks jõuluhäireteks, kus tuleb lugeda 20-leheküljelisi Java jälgimise teateid ja analüüsida kilomeetreid podisevaid klastrilogisid Spark History Serveri ja suurendusklaasi abil. Soovisime lihtsat ja läbipaistvat tööriista, mis ei nõua pidevat kapoti alla minemist, kui arendaja ei saa enam toimima standardset MapReduce päringut, kui vähendada andmete töödeldud töötluse mälust välja langemise tõttu pole liiga hästi valitud algandmete partitsioneerimise algoritmi.
Kas Amazon S3 on kandidaat DataLake'iks?
Töökogemus Hadoop/MapReduce'iga on õpetanud, et vajalik on skaleeritav usaldusväärne failisüsteem ja selle kohal skaleeritavad töötajad, kes „tulevad“ lähemale andmetele, et mitte suunata andmeid üle võrgu. Töötajad peavad oskama andmeid lugeda erinevates vormingutes, kuid eelistatult mitte lugema liigset teavet ning et oleks võimalik eelnevalt salvestada andmeid töötajatele mugavates vormingutes.
Veel kord — põhjusidea. Ei ole soovi „laadida“ suurandmeid ühte klastrianalüüsi mootori, mis varem või hiljem igal juhul sisse kukub ja tuleb see inetult jaotada. Soovime hoida faile, lihtsalt faile, arusaadavas vormingus ja teha nendega tõhusate analüütikaküsimustega, kasutades erinevaid, kuid arusaadavaid tööriistu. Ja faile erinevates vormingutes tuleb üha enam ja enam. Ja parem on jaotada mitte mootorit, vaid algandmeid. Me vajame laiendatavat ja universaalset DataLake'i, otsustasime...
Aga mis siis, kui salvestada faile tuttavas ja paljudele tuntud skaleeritavas pilvehoidlas Amazon S3, mitte vaevates oma enda Hadoop'i valmistamisega?
Selge, isikuandmed ei ole lubatud, aga mis siis teiste andmetega, kui need sinna viia ja „efektiivselt töödelda“?
Klastrite-suurandmete-analüüsi ekosüsteem Amazon Web Services — väga lihtsate sõnadega
Kuna meie kogemus AWS-iga näitab, et seal on juba ammu ja aktiivselt erinevate kastete all kasutatud Apache Hadoop/MapReduce'i, näiteks teenuses DataPipeline (kadedustan kolleege, nad oskavad seda õigesti valmistada). Siin oleme seadistanud varukoopiad erinevatest teenustest tabelitest DynamoDB:
Ja need käivitatakse regulaarselt sisseehitatud Hadoop/MapReduce klastrites nagu kellad juba mitu aastat. „Seadista ja unusta“:
Samuti saab tõhusalt tegeleda andmeanalüüsiga, käivitades analüütikute jaoks Jupiteri sülearvutid pilves ning kasutades AI mudelite õpetamiseks ja juurutamiseks AWS SageMaker teenust. Niiviisi see meie puhul välja näeb:
Ja jah, saate endale või analüütikule pilves sülearvuti seadistada ning siduda selle Hadoop/Spark klastriga, teha arvutusi ja kõik see siis "likvideerida":
See on tõeliselt mugav üksikute analüüsiprojektide jaoks ja mõnedel juhtudel oleme edukalt kasutanud EMR teenust ulatuslike arvutuste ja analüüside tegemiseks. Aga kuidas on lood süsteemse lahendusega DataLake'i jaoks, kas see õnnestub? Sel hetkel olime lootuse ja meeleheidete piiril ning jätkasime otsingut.
AWS Glue on hoolikalt pakitud Apache Spark "steroididega".
Selgus, et AWS-il on "oma" versioon „Hive/Pig/Spark“ stacks. Hive'i rolli, s.t. failide ja nende tüüpide katalooge DataLake's, täidab teenus „Data catalog“, mis ei varja oma ühilduvust Apache Hive vorminguga. Sellesse teenusesse tuleb lisada teave selle kohta, kus teie failid asuvad ja millises formaadis nad on. Andmed võivad olla mitte ainult s3-s, vaid ka andmebaasis, aga sellest ei räägi me selles postituses. Niiviisi 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 crawlers, mis uuendavad teavet ja salvestavad selle järve kohta. Edasi saab järvest andmeid töödelda ning tulemusi kuhugi välja laadida. Kõige lihtsamal juhul — laadime välja samuti s3-sse. Andmete töötlemist saab teha kuskil, kuid soovitatakse korraldada töötlemisprotsess Apache Spark klasstris, kasutades AWS Glue kaudu laialdasi võimalusi. Sisuliselt saab kasutada vana head ja tuttavat python koodi koos pyspark raamatukoguga ning seadistada selle täitmine N sõlmes teatud võimsusega klastris, jälgimisega, ilma et oleks vaja süüvida Hadoopi toimimisprotsessidesse või vedada Docker konteinerite keerukusi ning lahendada sõltuvusprobleeme.
Kordus — lihtne idee. Ei ole vaja seadistada Apache Spark'i, peate vaid kirjutama koodi pythonis pyspark jaoks, testima seda kohapeal töölaual ja seejärel käivitama suurel pilvekaldal, märkides ära, kus asuvad algandmed ja kuhu paigutada tulemus. Mõnikord on see vajalik ja kasulik ning niiviisi on see meie juures seadistatud:
Seega, kui on vaja midagi arvutada Spark klastris andmete jaoks s3-s — kirjutame python/pyspark koodi, testime ja suundume pilve.
Aga orkestreerimisega? Ent kui ülesanne langeb ja kaob? Jah, pakutakse ilusat torujuhet Apache Pigi stiilis ja me proovime neid, kuid otsustasime seni kasutada oma sügavalt kohandatud orkestreerimist PHP ja JavaScriptiga (ma saan aru, et see tekitab kognitiivset dissonantsi, kuid see töötab, aastaid ja tõrgeteta).
Järvede failide vorming on võtmetähtsusega jõudluse osas
On väga, väga oluline mõista veel kahte võtmeaspekti. Et andmefailide päringud järves toimuksid maksimaalselt kiiresti ja jõudlus ei halveneks uue teabe lisamisel, on vajalik:
- Hoidke failide veerud eraldi (et ei peaks lugema kõiki ridu, et mõista, mis veergudes on). Selleks kasutasime kokku surutud parquet formaati.
- On väga oluline jagada failid kaustadesse järgmiselt: keel, aasta, kuu, päev, nädal. Mootorid, mis mõistavad seda jagamisviisi, vaatavad ainult vajalikke kaustu, mitte ei läbi kõiki andmeid järjest.
Sisuliselt panete te sellisel viisil algandmed välja kõige tõhusamal viisil analüütilistele mootoritele, mis oskavad valikuliselt siseneda jagatud kaustadesse ja lugeda failidest ainult vajalikke veerge. Andmeid ei pea kuhugi «laadima» (sest salvestuskoht lihtsalt puruneb) — pange need kohe mõistlikult failisüsteemi õiges formaadis. Loomulikult peab olema selge, et tohutu csv-faili hoidmine DataLake'is, mille jaoks peab esmalt kõik read klastri poolt läbi lugema, et veerge välja tõmmata — ei ole kuigi otstarbekas. Mõelge veel kord kahele ülaltoodud punktile, kui see ei ole veel selge, miks see kõik vajalik on.
AWS Athena — „deemon” karbist
Ja siin, luues järve, sattusime, märkamatult, Amazon Athengale. Ühtäkki selgus, et hoolikalt jagades oma tohutud žurnaalifailid õigesse (parquet) veerguvormingusse, saab nende üle väga kiiresti teha äärmiselt informatiivseid valikuid ja koostada aruandeid ILMA, ilma Apache Spark/Glue klastri kasutamiseta.
Athena mootor, mis töötab andmetega s3-s, põhineb legendaarse — esindaja MPP (massive parallel processing) andmetöötluse lähenemistest, mis toob andmed sealt, kus need asuvad, alates s3 ja Hadoopist kuni Cassandra ja tavaliste tekstifailideni. Pead lihtsalt paluma Athenal SQL-päringut teha ja kõik „töötab kiiresti ja iseseisvalt“. Oluline on märkida, et Athena on „tark“, ta käib ainult vajalikest sharditud kaustadest ja loeb ainult päringus vajalikud veerud.
Athena päringute hindamine toimub samuti huvitaval viisil. Me maksame . See tähendab, et ei maksustata klastris olevate masinate arvu minutis, vaid… ainult tegelikult skaneeritud 100-500 masina andmete eest, mis on vajalikud päringu täitmiseks.
Kuna küsime ainult vajalikke veerge õigete sharditud kaustade hulgast, siis osutus, et Athena teenus maksab meile kümneid dollareid kuus. Imeline, peaaegu tasuta, võrreldes klastrite analüüsiga!
Näiteks, kuidas me oma andmeid s3-s shardime:
Tulemuseks oli see, et lühikese aja jooksul hakkasid ettevõtte täiesti erinevad osakonnad, alates infotehnoloogia turvast kuni analüüsini, aktiivselt Athena poole pöörduma ja kiiresti, sekunditega, saama kasulikke vastuseid „suurtest“ andmetest üsna pikemate perioodide jaoks: kuud, poolaasta jne.
Kuid me läksime kaugemale ja hakkasime vastuseid saama pilvest : analüütik kirjutab tuttavas konsoolis SQL-päringu, mis „mugavalt ja odavalt“ kaevab andmeid s3-st 100-500 masina ulatuses ja tagastab vastuse tavaliselt sekundite jooksul. Mugav. Ja kiire. Siiani ei suuda uskuda.
Lõpuks, pärast otsust andmed s3-s hoida, tõhusas veergude formaadis ja mõistliku andmete shardimisega kaustades… saime DataLake’i ja kiire ning odava analüüsimootor — tasuta. See sai ettevõttes väga populaarseks, kuna mõistab SQL-i ja töötab kordades kiiremini kui klastrite käivitamise/peatamise/seadmise korral. „Ja kui tulemus on sama, miks maksta rohkem?“
Päring Athena jaoks näeb välja umbes selline. Kui soovite, saate loomulikult koostada piisavalt , kuid piirdume lihtsa rühmitamisega. Vaatame, millised vastuste koodid olid kliendil mõned nädalad tagasi veebiserveri logides ja veendume, et vigu pole:
Järeldused
Läbinud pikka, kuid valulikku teed, pidevalt riske ja keerukuse taset ning toetuse maksumust õigesti hinnates, leidsime lahenduse DataLake'ile ja analüütikale, mis ei lakka meid rõõmustamast oma kiiruselt ja omamise kuludelt.
Selgus, et tõhus, kiire ja odavalt kasutatav DataLake erinevate ettevõtte osakondade vajaduste jaoks on täiesti jõukohane isegi kogenud arendajatele, kes ei ole kunagi töötanud arhitektidena ega oska joonistada ruute ruutude peale koos noolte ja viiekümne terminiga Hadoopi ökosüsteemist.
Teel alguses lõi pead kokku paljude ulmeliste avatud ja suletud tarkvarade „loomaaedade” ja vastutustunde koorma tõttu järeltulevate põlvede ees. Alustage oma DataLake'i ehitamist lihtsatest tööriistadest: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3 …, kogudes tagasisidet ja sügavalt mõistes toimingute füüsikat. Kõik keeruline ja hägune andke vaenlastele ja konkurentidele.
Kui te ei soovi pilve ja armastate avatud projekte hooldada, värskendada ja parandada, on sarnase meie skeemi ehitamine kohapeal, odavatel büroomasinatel, Hadoopi ja Presto peal, võimalik. Peamine on mitte peatuda ja edasi liikuda, arvestada, otsida lihtsaid ja selgeid lahendusi, ning kõik tuleb kindlasti välja! Kogu edu ja senimaani!
Allikas: habr.com
