Žijeme v úžasnej dobe, kedy môžete rýchlo a jednoducho prepojiť niekoľko hotových open-source nástrojov, nastaviť ich s „vypnutým vedomím“ podľa rady stackoverflow, bez toho, aby ste sa zabárali do „viacerých písmen“ a spustiť ich do komerčnej prevádzky. A keď potrebujete aktualizovať/rozbaliť alebo niekto omylom reštartuje pár strojov – uvedomíte si, že sa začal nejaký obsedantný zlý sen, všetko sa dramaticky skomplikovalo na nepoznanie, niet cesty späť, budúcnosť je nejasná a bezpečnejšia, namiesto programovania chovať včely a robiť syr.
Nie nadarmo skúsenejší kolegovia s hlavami posiatymi chrobákmi, a teda už sivými, uvažujú o neuveriteľne rýchlom nasadení balíčkov „kontajnerov“ v „kockach“ na desiatkach serverov v „módnych jazykoch“ so zabudovanou podporou pre asynchrónne neblokujúce I/O, usmievaj sa skromne . A potichu pokračujú v opätovnom čítaní „man ps“, ponorení sa do zdrojového kódu „nginx“, až im krvácajú oči, a píšu, píšu, píšu unit testy. Kolegovia vedia, že to najzaujímavejšie príde, keď sa „toto všetko“ jedného dňa stane stávkou v noci na Silvestra. A pomôže im iba hlboké pochopenie podstaty unixu, zapamätaná tabuľka stavov TCP/IP a základné algoritmy triedenia a vyhľadávania. Priviesť systém späť k životu, keď zaznie zvonenie.
Ach áno, trochu som sa rozptýlil, ale dúfam, že sa mi podarilo sprostredkovať stav očakávania.
Dnes sa chcem podeliť o naše skúsenosti s nasadením pohodlného a lacného stacku pre DataLake, ktorý rieši väčšinu analytických úloh v spoločnosti pre úplne iné štrukturálne divízie.
Pred časom sme prišli na to, že spoločnosti čoraz viac potrebujú plody produktovej aj technickej analýzy (nehovoriac o čerešničke na torte v podobe strojového učenia) a aby sme pochopili trendy a riziká – musíme zbierať a analyzovať stále viac a viac metrík.
Základná technická analytika v Bitrix24
Pred niekoľkými rokmi, súčasne so spustením služby Bitrix24, sme aktívne investovali čas a zdroje do vytvorenia jednoduchej a spoľahlivej analytickej platformy, ktorá by pomohla rýchlo vidieť problémy v infraštruktúre a naplánovať ďalší krok. Samozrejme, bolo vhodné vziať si hotové nástroje, ktoré boli čo najjednoduchšie a najzrozumiteľnejšie. Výsledkom bolo, že nagios bol vybraný na monitorovanie a munin na analýzu a vizualizáciu. Teraz máme tisíce kontrol v nagios, stovky grafov v munin a naši kolegovia ich úspešne používajú každý deň. Metriky sú prehľadné, grafy prehľadné, systém funguje spoľahlivo už niekoľko rokov a pravidelne doň pribúdajú nové testy a grafy: keď uvádzame do prevádzky novú službu, pridávame niekoľko testov a grafov. Veľa štastia.
Prst na pulze – pokročilá technická analýza
Túžba dostávať informácie o problémoch „čo najrýchlejšie“ nás viedla k aktívnym experimentom s jednoduchými a zrozumiteľnými nástrojmi – pinba a xhprof.
Pinba отправляла нам в UDP-пакетиках статистику о скорости работы частей веб-страниц на PHP и можно было в режиме онлайн видеть в хранилище MySQL (c pinba идет свой движок MySQL для быстрой аналитики событий) короткий список проблем и реагировать на них. А xhprof в автоматическом режиме позволял собирать графы выполнения наиболее медленных PHP-страниц у клиентов и анализировать, что к этому могло привести — спокойно, налив чай или чего-нибудь покрепче.
Pred časom bola sada nástrojov doplnená o ďalší pomerne jednoduchý a zrozumiteľný engine založený na algoritme spätného indexovania, dokonale implementovaný v legendárnej knižnici Lucene - Elastic/Kibana. Jednoduchá myšlienka viacvláknového zaznamenávania dokumentov do inverzného indexu Lucene na základe udalostí v protokoloch a rýchleho prehľadávania pomocou delenia faziet sa ukázali ako skutočne užitočné.
Napriek pomerne technickému vzhľadu vizualizácií v Kibane s nízkoúrovňovými konceptmi ako „vedro“ „tečúce nahor“ a znovuobjaveným jazykom ešte nie úplne zabudnutej relačnej algebry, nám tento nástroj začal dobre pomáhať v nasledujúcich úlohách:
- Koľko chýb PHP mal klient Bitrix24 na portáli p1 za poslednú hodinu a ktoré? Pochopte, odpustite a rýchlo napravte.
- Koľko videohovorov sa uskutočnilo na portáloch v Nemecku za posledných 24 hodín, v akej kvalite a vyskytli sa nejaké problémy s kanálom/sieťou?
- Ako dobre funguje systémová funkčnosť (naše rozšírenie C pre PHP), skompilovaná zo zdroja v najnovšej aktualizácii služby a sprístupnená klientom? Existujú segfaulty?
- Zmestia sa údaje o zákazníkoch do pamäte PHP? Vyskytli sa nejaké chyby týkajúce sa prekročenia pamäte pridelenej procesom: „nedostatok pamäte“? Nájsť a neutralizovať.
Tu je konkrétny príklad. Napriek dôkladnému a viacúrovňovému testovaniu sa klientovi s veľmi neštandardným prípadom a poškodenými vstupnými údajmi objavila nepríjemná a neočakávaná chyba, zaznela siréna a začal sa proces rýchleho odstránenia:
Okrem toho vám kibana umožňuje organizovať upozornenia na zadané udalosti a v krátkom čase tento nástroj vo firme začali využívať desiatky zamestnancov z rôznych oddelení – od technickej podpory a vývoja až po QA.
Činnosť akéhokoľvek oddelenia v rámci spoločnosti sa stala pohodlnou na sledovanie a meranie - namiesto ručnej analýzy protokolov na serveroch stačí raz nastaviť protokoly analýzy a odoslať ich do elastického klastra, aby ste si mohli vychutnať napríklad rozjímanie v kibane. dashboard počet predaných dvojhlavých mačiatok vytlačených na 3D tlačiarni za posledný lunárny mesiac.
Základná obchodná analýza
Každý vie, že obchodná analytika v spoločnostiach často začína mimoriadne aktívnym používaním Excelu. Ale hlavné je, že to nekončí. Cloudová služba Google Analytics tiež prilieva olej do ohňa – rýchlo si zvyknete na dobré veci.
V našej harmonicky sa rozvíjajúcej spoločnosti sa tu a tam začali objavovať „proroci“ intenzívnejšej práce s väčšími dátami. Potreba hlbších a mnohostrannejších reportov sa začala objavovať pravidelne a vďaka úsiliu chalanov z rôznych oddelení sa pred časom podarilo zorganizovať jednoduché a praktické riešenie – kombinácia ClickHouse a PowerBI.
Pomerne dlho toto flexibilné riešenie veľmi pomáhalo, no postupne začalo dochádzať k pochopeniu, že ClickHouse nie je gumený a nedá sa z neho tak vysmievať.
Tu je dôležité dobre pochopiť, že ClickHouse, ako Druid, ako Vertica, ako Amazon RedShift (ktorý je založený na postgres), sú analytické nástroje optimalizované pre pomerne pohodlnú analýzu (súčty, agregácie, minimum-maximum podľa stĺpca a niekoľko možných spojení ), pretože organizované pre efektívne ukladanie stĺpcov relačných tabuliek, na rozdiel od MySQL a iných (riadkovo orientovaných) databáz, ktoré poznáme.
ClickHouse je v podstate len priestrannejšia „databáza“ s nie príliš pohodlným vkladaním bodov po bode (takto je zamýšľané, všetko je v poriadku), ale príjemnou analytikou a sadou zaujímavých výkonných funkcií na prácu s údajmi. Áno, môžete dokonca vytvoriť zhluk - ale chápete, že zatĺkanie klincov mikroskopom nie je úplne správne a začali sme hľadať iné riešenia.
Dopyt po pythone a analytikoch
Naša spoločnosť má veľa vývojárov, ktorí píšu kód takmer každý deň po dobu 10-20 rokov v PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash. Existuje aj veľa skúsených systémových administrátorov, ktorí zažili nejednu absolútne neuveriteľnú katastrofu, ktorá nezapadá do zákonov štatistiky (napríklad keď je väčšina diskov v raid-10 zničená silným úderom blesku). Za takýchto okolností dlho nebolo jasné, čo je „analytik pythonu“. Python je ako PHP, len názov je o niečo dlhší a v zdrojovom kóde interpreta je o niečo menej stôp látok, ktoré menia myseľ. Ako sa však vytváralo viac a viac analytických správ, skúsení vývojári začali čoraz viac chápať dôležitosť úzkej špecializácie na nástroje ako numpy, pandas, matplotlib, seaborn.
Rozhodujúcu úlohu s najväčšou pravdepodobnosťou zohralo náhle mdloby zamestnancov z kombinácie slov „logistická regresia“ a demonštrácia efektívneho reportingu veľkých dát pomocou, áno, áno, pyspark.
Apache Spark, jeho funkčná paradigma, na ktorú dokonale zapadá relačná algebra, a jeho schopnosti urobili taký dojem na vývojárov zvyknutých na MySQL, že potreba posilniť rady skúsenými analytikmi bola jasná ako deň.
Ďalšie pokusy Apache Spark/Hadoop vzlietnuť a čo nešlo celkom podľa scenára
Čoskoro sa však ukázalo, že so Sparkom nie je niečo systémovo úplne v poriadku, alebo si jednoducho treba lepšie umyť ruky. Ak bol zásobník Hadoop/MapReduce/Lucene vytvorený pomerne skúsenými programátormi, čo je zrejmé, ak sa bližšie pozriete na zdrojový kód v Jave alebo nápady Douga Cuttinga v Lucene, potom je Spark zrazu napísaný v exotickom jazyku Scala, čo je veľmi kontroverzný z hľadiska praktickosti a v súčasnosti sa nerozvíja. A pravidelný pokles výpočtov na klastri Spark v dôsledku nelogickej a málo transparentnej práce s alokáciou pamäte pre operácie redukcie (prichádza veľa kľúčov naraz) vytvoril okolo seba haló niečoho, čo má priestor na rast. Situáciu navyše zhoršilo veľké množstvo podivných otvorených portov, dočasné súbory rastúce na tých najnezrozumiteľnejších miestach a pekelné závislosti na jar – čo spôsobilo, že správcovia systému mali pocit, ktorý bol dobre známy z detstva: zúrivá nenávisť (alebo možno potrebovali si umyť ruky mydlom).
V dôsledku toho sme „prežili“ niekoľko interných analytických projektov, ktoré aktívne využívajú Apache Spark (vrátane Spark Streaming, Spark SQL) a ekosystém Hadoop (a tak ďalej a tak ďalej). Napriek tomu, že sme sa časom naučili „to“ celkom dobre pripravovať a monitorovať a „to“ prakticky náhle prestalo padať v dôsledku zmien v charaktere údajov a nevyváženosti jednotného hashovania RDD, chuť vziať si niečo už pripravené , aktualizované a spravované niekde v cloude boli čoraz silnejšie. V tom čase sme sa pokúsili použiť hotovú cloudovú zostavu Amazon Web Services - a následne sa pokúšal riešiť problémy pomocou nej. EMR je Apache Spark pripravený Amazonom s dodatočným softvérom z ekosystému, podobne ako zostavy Cloudera/Hortonworks.
Gumové ukladanie súborov na analýzu je naliehavá potreba
Skúsenosť s „varením“ Hadoop/Spark s popáleninami rôznych častí tela nebola zbytočná. Potreba vytvoriť jediné, lacné a spoľahlivé úložisko súborov, ktoré by bolo odolné voči zlyhaniu hardvéru a v ktorom by bolo možné ukladať súbory v rôznych formátoch z rôznych systémov a vytvárať efektívne a časovo nenáročné vzorky pre zostavy z týchto údajov, narastala. jasný.
Chcel som tiež, aby sa aktualizácia softvéru tejto platformy nezmenila na novoročnú nočnú moru čítaním 20-stranových stôp Java a analýzou kilometrových podrobných protokolov klastra pomocou servera Spark History Server a podsvietenej lupy. Chcel som mať jednoduchý a transparentný nástroj, ktorý nevyžadoval pravidelné potápanie pod kapotou, ak by sa štandardná požiadavka MapReduce vývojára prestala vykonávať, keď pracovník redukcie údajov vypadol z pamäte kvôli nie veľmi dobre zvolenému algoritmu rozdeľovania zdrojových údajov.
Je Amazon S3 kandidátom na DataLake?
Skúsenosti s Hadoop/MapReduce nás naučili, že potrebujeme škálovateľný, spoľahlivý súborový systém a nad ním škálovateľných pracovníkov, ktorí sa „približujú“ k údajom, aby ich netlačili cez sieť. Pracovníci by mali byť schopní čítať údaje v rôznych formátoch, ale pokiaľ možno, nemali by čítať nepotrebné informácie a mali by byť schopní ukladať údaje vopred vo formátoch vhodných pre pracovníkov.
Ešte raz základná myšlienka. Nie je žiadnou túžbou „nalievať“ veľké dáta do jediného klastrového analytického enginu, ktorý sa skôr či neskôr zadusí a budete ho musieť škaredo nastrúhať. Chcem ukladať súbory, iba súbory, v zrozumiteľnom formáte a vykonávať na ne efektívne analytické dotazy pomocou rôznych, ale zrozumiteľných nástrojov. A bude stále viac a viac súborov v rôznych formátoch. A je lepšie rozdrviť nie motor, ale zdrojové údaje. Potrebujeme rozšíriteľné a univerzálne DataLake, rozhodli sme sa...
Čo ak ukladáte súbory do známeho a dobre známeho škálovateľného cloudového úložiska Amazon S3 bez toho, aby ste si museli pripravovať vlastné kotlety od Hadoop?
Je jasné, že osobných údajov je „nízke“, ale čo s ostatnými údajmi, ak ich vytiahneme a „efektívne naložíme“?
Ekosystém Cluster-bigdata-analytics Amazon Web Services – veľmi jednoduchými slovami
Судя по нашему опыту работы с AWS, там давно и активно используется под разными соусами Apache Hadoop/MapReduce, например в сервисе DataPipeline (завидую коллегам, вот научились же его правильно готовить). Вот тут мы настроили бэкапы из разных сервисов из таблиц DynamoDB:
A už niekoľko rokov pravidelne bežia na zabudovaných klastroch Hadoop/MapReduce ako hodinky. „Nastav to a zabudni na to“:
Môžete sa tiež efektívne zapojiť do dátového satanizmu nastavením notebookov Jupiter v cloude pre analytikov a pomocou služby AWS SageMaker na trénovanie a nasadzovanie modelov AI do boja. U nás to vyzerá takto:
A áno, môžete si vyzdvihnúť laptop pre seba alebo pre analytika v cloude a pripojiť ho ku klastru Hadoop/Spark, urobiť výpočty a potom všetko zlikvidovať:
Naozaj vhodné pre individuálne analytické projekty a pre niektorých sme službu EMR úspešne použili na rozsiahle výpočty a analýzy. A čo systémové riešenie pre DataLake, bude fungovať? V tejto chvíli sme boli na pokraji nádeje a zúfalstva a pokračovali v hľadaní.
AWS Glue - úhľadne zabalené Apache Spark na steroidoch
Ukázalo sa, že AWS má svoju vlastnú verziu zásobníka „Hive/Pig/Spark“. Úloha Úľa, t.j. Katalóg súborov a ich typov v DataLake vykonáva služba „Data Catalog“, ktorá sa netají kompatibilitou s formátom Apache Hive. Do tejto služby musíte pridať informácie o tom, kde sa vaše súbory nachádzajú a v akom formáte sú. Údaje môžu byť nielen v s3, ale aj v databáze, ale to nie je predmetom tohto príspevku. Náš dátový adresár DataLake je usporiadaný takto:
Súbory sú zaregistrované, skvelé. Ak boli súbory aktualizované, spúšťame prehľadávače manuálne alebo podľa plánu, čím sa aktualizujú informácie o nich z jazera a uložia sa. Potom sa dajú dáta z jazera spracovať a výsledky niekam nahrať. V najjednoduchšom prípade nahrávame aj do s3. Spracovanie údajov je možné vykonať kdekoľvek, ale odporúčame vám nakonfigurovať spracovanie na klastri Apache Spark pomocou pokročilých funkcií prostredníctvom rozhrania AWS Glue API. V skutočnosti môžete použiť starý dobrý a známy kód pythonu pomocou knižnice pyspark a nakonfigurovať jeho vykonávanie na N uzloch klastra určitej kapacity s monitorovaním, bez toho, aby ste sa museli hrabať v útrobách Hadoopu a ťahať kontajnery docker-moker a eliminovať konflikty závislostí. .
Ešte raz jednoduchý nápad. Nie je potrebné konfigurovať Apache Spark, stačí napísať python kód pre pyspark, otestovať ho lokálne na pracovnej ploche a potom ho spustiť na veľkom klastri v cloude s uvedením, kde sú zdrojové údaje a kam umiestniť výsledok. Niekedy je to potrebné a užitočné a takto to nastavíme:
Ak teda potrebujete vypočítať niečo na klastri Spark pomocou údajov v s3, napíšeme kód v python/pyspark, otestujeme ho a veľa šťastia pre cloud.
A čo orchestrácia? Čo ak úloha padla a zmizla? Áno, navrhuje sa vytvoriť krásne potrubie v štýle Apache Pig a dokonca sme ich vyskúšali, ale zatiaľ sme sa rozhodli použiť našu hlboko prispôsobenú orchestráciu v PHP a JavaScript (chápem, existuje kognitívna disonancia, ale funguje to napr. rokov a bez chýb).
Formát súborov uložených v jazere je kľúčom k výkonu
Очень, очень важно понять еще два ключевых момента. Чтобы запросы по данным файлов в озере выполнялись максимально быстро и производительность не деградировала при добавлении новой информации, нужно:
- Ukladajte stĺpce súborov oddelene (aby ste nemuseli čítať všetky riadky, aby ste pochopili, čo je v stĺpcoch). Na tento účel sme vzali parketový formát s kompresiou
- Je veľmi dôležité rozdeliť súbory do priečinkov ako: jazyk, rok, mesiac, deň, týždeň. Motory, ktoré rozumejú tomuto typu shardingu, sa budú pozerať iba na potrebné priečinky bez toho, aby preosiali všetky údaje za sebou.
Týmto spôsobom v podstate rozložíte zdrojové dáta v najefektívnejšej forme pre analytické nástroje zavesené na vrchu, ktoré aj v rozbitých priečinkoch môžu selektívne zadávať a čítať iba potrebné stĺpce zo súborov. Údaje nemusíte nikam „vypĺňať“ (úložisko jednoducho praskne) – jednoducho ich múdro vložte do systému súborov v správnom formáte. Samozrejme, tu by malo byť jasné, že ukladanie veľkého súboru csv v DataLake, ktorý musí klaster najprv prečítať riadok po riadku, aby sa rozbalili stĺpce, nie je príliš vhodné. Zamyslite sa znova nad vyššie uvedenými dvoma bodmi, ak ešte nie je jasné, prečo sa to všetko deje.
AWS Athena - jack-in-the-box
A potom sme pri vytváraní jazera akosi náhodou narazili na Amazonskú Athénu. Zrazu sa ukázalo, že starostlivým usporiadaním našich obrovských protokolových súborov do častí priečinkov v správnom (parketovom) stĺpcovom formáte z nich môžete veľmi rýchlo robiť mimoriadne informatívne výbery a zostavovať zostavy BEZ klastra Apache Spark/Glue.
Motor Athena poháňaný dátami v s3 je založený na legendárnom - zástupca MPP (masívne paralelné spracovanie) rodiny prístupov k spracovaniu dát, pričom dáta tam, kde sú, od s3 a Hadoop až po Cassandru a bežné textové súbory. Stačí požiadať Athenu, aby vykonala SQL dotaz, a potom všetko „funguje rýchlo a automaticky“. Je dôležité poznamenať, že Athena je „inteligentná“, prechádza iba do potrebných rozbitých priečinkov a číta iba stĺpce potrebné v žiadosti.
Zaujímavá je aj cenotvorba žiadostí do Atheny. Platíme za . Tie. nie na počet strojov v klastri za minútu, ale... na skutočne naskenované dáta na 100-500 strojoch len údaje potrebné na dokončenie požiadavky.
A vyžiadaním si len potrebných stĺpcov zo správne nastrúhaných priečinkov sa ukázalo, že služba Athena nás stojí desiatky dolárov mesačne. Výborne, takmer zadarmo v porovnaní s analytikou klastrov!
Mimochodom, takto delíme naše údaje v s3:
Výsledkom bolo, že v krátkom čase začali úplne iné oddelenia v spoločnosti, od informačnej bezpečnosti až po analytiku, aktívne odosielať požiadavky do Atheny a rýchlo, v priebehu niekoľkých sekúnd, dostávali užitočné odpovede z „veľkých“ údajov počas pomerne dlhých období: mesiacov, pol roka atď. P.
Išli sme však ďalej a začali sme chodiť po odpovede do cloudu : analytik napíše SQL dotaz v známej konzole, ktorá na 100-500 strojoch „za groše“ odošle dáta do s3 a vráti odpoveď zvyčajne do niekoľkých sekúnd. Pohodlné. A rýchlo. Stále tomu nemôžem uveriť.
Výsledkom je, že keď sme sa rozhodli ukladať dáta v s3, v efektívnom stĺpcovom formáte a s rozumným rozdelením dát do priečinkov... dostali sme DataLake a rýchly a lacný analytický engine – zadarmo. A v spoločnosti sa stal veľmi populárnym, pretože... rozumie SQL a pracuje rádovo rýchlejšie ako pri spúšťaní/zastavovaní/nastavovaní klastrov. "A ak je výsledok rovnaký, prečo platiť viac?"
Žiadosť adresovaná Aténe vyzerá asi takto. Ak je to žiaduce, samozrejme, môžete vytvoriť dosť , ale obmedzíme sa na jednoduché zoskupovanie. Pozrime sa, aké kódy odpovedí mal klient pred niekoľkými týždňami v protokoloch webového servera a uistite sa, že neexistujú žiadne chyby:
Závery
Tým, že sme prešli, nehovoriac dlhou, ale strastiplnou cestou, neustálym primeraným hodnotením rizík a úrovne zložitosti a nákladov na podporu, sme našli riešenie pre DataLake a analytiku, ktoré nás neprestáva potešiť rýchlosťou aj nákladmi na vlastníctvo.
Ukázalo sa, že vybudovať efektívne, rýchlo a lacno na prevádzku DataLake pre potreby úplne iných oddelení spoločnosti je úplne v možnostiach aj skúsených vývojárov, ktorí nikdy nepracovali ako architekti a nevedia kresliť štvorce na štvorce s šípky a pozná 50 výrazov z ekosystému Hadoop.
Na začiatku cesty mi hlava triasla z množstva divokých zoologických záhrad otvoreného a uzavretého softvéru a chápania bremena zodpovednosti voči potomkom. Začnite budovať svoje DataLake z jednoduchých nástrojov: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., zbierajte spätnú väzbu a hlboko pochopte fyziku prebiehajúcich procesov. Všetko zložité a temné - dajte to nepriateľom a konkurentom.
Ak nechcete ísť do cloudu a chcete podporovať, aktualizovať a opravovať projekty s otvoreným zdrojovým kódom, môžete si vytvoriť schému podobnú našej lokálne na lacných kancelárskych strojoch s Hadoop a Presto navrchu. Hlavné je nezastavovať sa a napredovať, počítať, hľadať jednoduché a jasné riešenia a všetko sa určite podarí! Veľa šťastia všetkým a uvidíme sa znova!
Zdroj: hab.com