Žijeme v úžasné době, kdy můžete rychle a snadno propojit několik hotových nástrojů s otevřeným zdrojovým kódem, nastavit je s „vypnutým vědomím“ podle rady stackoverflow, aniž byste se museli ponořit do „více písmen“ a spustit do komerčního provozu. A když potřebujete aktualizovat/rozšířit nebo někdo omylem restartuje pár strojů - uvědomíte si, že ve skutečnosti začal jakýsi obsedantní zlý sen, všechno se najednou zkomplikovalo k nepoznání, není cesty zpět, budoucnost je nejasná a bezpečnější, místo programování chovat včely a vyrábět sýr.
Ne nadarmo se zkušenější kolegové s hlavami obsypanými chybami a tudíž již šedivými, kteří uvažují o neuvěřitelně rychlém nasazení balíčků „kontejnerů“ v „kostkách“ na desítky serverů v „módních jazycích“ s vestavěnou podporou pro asynchronní neblokující I/O, skromně se usmívejte . A tiše pokračují v opětovném čtení „man ps“, ponořují se do zdrojového kódu „nginx“, až jim oči krvácejí, a píší, píší, píší unit testy. Kolegové vědí, že to nejzajímavější přijde, když se „toto všechno“ jednoho dne stane vsazenou nocí na Silvestra. A pomůže jim pouze hluboké pochopení podstaty unixu, zapamatovaná tabulka stavů TCP/IP a základní algoritmy třídění a vyhledávání. Přivést systém zpět k životu, když zazní zvony.
Ach ano, trochu jsem se rozptýlil, ale doufám, že se mi podařilo vyjádřit stav očekávání.
Dnes se chci podělit o naše zkušenosti s nasazením pohodlného a levného stacku pro DataLake, který řeší většinu analytických úkolů ve společnosti pro úplně jiné strukturální divize.
Před časem jsme pochopili, že společnosti stále více potřebují plody produktové i technické analýzy (nemluvě o třešničce na dortu v podobě strojového učení) a abychom porozuměli trendům a rizikům – musíme shromažďovat a analyzovat stále více a více metrik.
Základní technická analytika v Bitrix24
Před několika lety, současně se spuštěním služby Bitrix24, jsme aktivně investovali čas a zdroje do vytvoření jednoduché a spolehlivé analytické platformy, která by pomohla rychle vidět problémy v infrastruktuře a naplánovat další krok. Samozřejmě bylo vhodné vzít si hotové nástroje, které byly co nejjednodušší a srozumitelné. Výsledkem bylo, že nagios byl vybrán pro monitorování a munin pro analýzu a vizualizaci. Nyní máme tisíce kontrol v nagios, stovky grafů v munin a naši kolegové je úspěšně používají každý den. Metriky jsou jasné, grafy přehledné, systém funguje spolehlivě několik let a pravidelně do něj přibývají nové testy a grafy: když zprovozňujeme novou službu, přidáváme několik testů a grafů. Hodně štěstí.
Finger on the Pulse – pokročilá technická analýza
Touha dostávat informace o problémech „co nejrychleji“ nás vedla k aktivním experimentům s jednoduchými a srozumitelnými nástroji – pinba a xhprof.
Pinba nám poslal statistiky v UDP paketech o rychlosti provozu částí webových stránek v PHP a my jsme mohli vidět online v úložišti MySQL (Pinba přichází s vlastním MySQL enginem pro rychlou analýzu událostí) krátký seznam problémů a reagovat na jim. A xhprof nám automaticky umožnil sbírat od klientů grafy provádění nejpomalejších PHP stránek a analyzovat, co k tomu může vést - klidně zalévání čaje nebo něčeho silnějšího.
Před časem byla sada nástrojů doplněna o další poměrně jednoduchý a srozumitelný engine založený na algoritmu zpětného indexování, dokonale implementovaný v legendární knihovně Lucene - Elastic/Kibana. Jednoduchá myšlenka vícevláknového záznamu dokumentů do inverzního Lucene indexu na základě událostí v protokolech a rychlého prohledávání pomocí dělení fazet se ukázala jako opravdu užitečná.
Navzdory spíše technickému vzhledu vizualizací v Kibaně s nízkoúrovňovými koncepty jako „kbelík“ „tekoucí nahoru“ a znovuobjeveným jazykem ještě ne zcela zapomenuté relační algebry nám tento nástroj začal dobře pomáhat v následujících úkolech:
- Kolik chyb PHP měl klient Bitrix24 na portálu p1 za poslední hodinu a které? Pochopit, odpustit a rychle napravit.
- Kolik videohovorů bylo uskutečněno na portálech v Německu za předchozích 24 hodin, v jaké kvalitě a byly nějaké potíže s kanálem/sítí?
- Jak dobře funguje funkce systému (naše rozšíření C pro PHP), zkompilované ze zdroje v nejnovější aktualizaci služby a zavedené klientům? Existují segfaulty?
- Vejdou se zákaznická data do paměti PHP? Existují nějaké chyby týkající se překročení paměti přidělené procesům: „nedostatek paměti“? Najít a neutralizovat.
Zde je konkrétní příklad. Přes důkladné a víceúrovňové testování se klientovi s velmi nestandardním případem a poškozenými vstupními daty objevila nepříjemná a neočekávaná chyba, zazněla siréna a začal proces rychlé nápravy:
Kibana navíc umožňuje organizovat upozornění na zadané události a během krátké doby začaly nástroj ve firmě využívat desítky zaměstnanců z různých oddělení – od technické podpory a vývoje až po QA.
Činnost jakéhokoli oddělení v rámci společnosti se stala pohodlnější pro sledování a měření – místo ruční analýzy protokolů na serverech stačí jednou nastavit protokoly analýzy a odeslat je do elastického clusteru, abyste si mohli užít například rozjímání v kibaně. dashboard počet prodaných dvouhlavých koťat vytištěných na 3D tiskárně za poslední lunární měsíc.
Základní obchodní analytika
Každý ví, že obchodní analytika ve společnostech často začíná extrémně aktivním používáním, ano, Excelu. Ale hlavní je, že tím to nekončí. Cloudová Google Analytics také přilévá olej do ohně – rychle si zvyknete na dobré věci.
V naší harmonicky se rozvíjející firmě se tu a tam začali objevovat „proroci“ intenzivnější práce s většími daty. Potřeba hlubších a mnohostrannějších reportů se začala objevovat pravidelně a díky úsilí kluků z různých oddělení bylo před časem zorganizováno jednoduché a praktické řešení - kombinace ClickHouse a PowerBI.
Poměrně dlouhou dobu toto flexibilní řešení hodně pomáhalo, ale postupně začalo docházet k pochopení, že ClickHouse není gumový a nelze se mu tak vysmívat.
Zde je důležité dobře pochopit, že ClickHouse, jako Druid, jako Vertica, jako Amazon RedShift (který je založen na postgres), jsou analytické nástroje optimalizované pro poměrně pohodlnou analýzu (součty, agregace, minimum-maximum podle sloupců a několik možných spojení ), protože organizované pro efektivní ukládání sloupců relačních tabulek, na rozdíl od MySQL a jiných (řádkově orientovaných) databází nám známých.
ClickHouse je v podstatě jen prostornější „databáze“, s nepříliš pohodlným vkládáním bodu po bodu (tak je to myšleno, vše je v pořádku), ale příjemnou analytikou a sadou zajímavých výkonných funkcí pro práci s daty. Ano, můžete dokonce vytvořit shluk - ale chápete, že zatloukání hřebíků mikroskopem není úplně správné a začali jsme hledat jiná řešení.
Poptávka po pythonu a analyticích
Naše společnost má mnoho vývojářů, kteří píší kód téměř každý den po dobu 10-20 let v PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash. Existuje také mnoho zkušených systémových administrátorů, kteří zažili nejednu naprosto neuvěřitelnou katastrofu, která nezapadá do zákonů statistiky (například když je většina disků v raid-10 zničena silným úderem blesku). Za takových okolností dlouho nebylo jasné, co je „analytik krajty“. Python je jako PHP, jen název je o něco delší a ve zdrojovém kódu tlumočníka je o něco méně stop látek měnících mysl. Jak však bylo vytvářeno více a více analytických zpráv, zkušení vývojáři začali stále více chápat důležitost úzké specializace na nástroje jako numpy, pandas, matplotlib, seaborn.
Rozhodující roli nejspíše sehrálo náhlé omdlévání zaměstnanců ze spojení slov „logistická regrese“ a ukázka efektivního reportingu velkých dat pomocí, ano, ano, pyspark.
Apache Spark, jeho funkční paradigma, na které dokonale zapadá relační algebra, a jeho schopnosti udělaly takový dojem na vývojáře zvyklé na MySQL, že potřeba posílit řady zkušenými analytiky byla jasná jako den.
Další pokusy Apache Spark/Hadoop vzlétnout a co nešlo úplně podle scénáře
Brzy se však ukázalo, že se Sparkem není něco systémově úplně v pořádku, nebo je prostě potřeba si lépe umýt ruce. Pokud byl zásobník Hadoop/MapReduce/Lucene vytvořen poměrně zkušenými programátory, což je zřejmé, pokud se podíváte pozorně na zdrojový kód v Javě nebo nápady Douga Cuttinga v Lucene, pak je Spark náhle napsán v exotickém jazyce Scala, což je velmi kontroverzní z hlediska praktičnosti a v současnosti se nerozvíjí. A pravidelný propad výpočtů na clusteru Spark kvůli nelogické a nepříliš transparentní práci s alokací paměti pro operace snížení (dorazí mnoho klíčů najednou) vytvořil kolem sebe haló něčeho, co má kam růst. Situaci navíc zhoršovalo velké množství podivných otevřených portů, dočasné soubory rostoucí na těch nejnesrozumitelnějších místech a pekelné závislosti na jaru – což způsobilo, že správci systému měli pocit, který byl dobře známý z dětství: divoká nenávist (nebo možná potřebovali si umýt ruce mýdlem).
V důsledku toho jsme „přežili“ několik interních analytických projektů, které aktivně využívají Apache Spark (včetně Spark Streaming, Spark SQL) a ekosystém Hadoop (a tak dále a tak dále). Navzdory tomu, že jsme se postupem času naučili „to“ docela dobře připravovat a monitorovat a „to“ prakticky přestalo náhle padat kvůli změnám v charakteru dat a nevyváženosti jednotného hashování RDD, chuť vzít si něco již připraveného , aktualizované a spravované někde v cloudu sílily a sílily. V té době jsme se pokusili použít hotovou cloudovou sestavu Amazon Web Services - a následně se s jeho pomocí snažil řešit problémy. EMR je Apache Spark připravený Amazonem s dalším softwarem z ekosystému, podobně jako sestavení Cloudera/Hortonworks.
Gumové úložiště souborů pro analýzu je naléhavou potřebou
Zkušenost s „vařením“ Hadoop/Spark s popáleninami různých částí těla nebyla marná. Potřeba vytvořit jediné, levné a spolehlivé úložiště souborů, které by bylo odolné proti selhání hardwaru a ve kterém by bylo možné ukládat soubory v různých formátech z různých systémů a vytvářet z těchto dat efektivní a časově nenáročné vzorky pro sestavy Průhledná.
Také jsem chtěl, aby se aktualizace softwaru této platformy neproměnila v novoroční noční můru čtením 20stránkových stop Java a analýzou kilometrových podrobných protokolů clusteru pomocí serveru Spark History Server a podsvícené lupy. Chtěl jsem mít jednoduchý a transparentní nástroj, který nevyžadoval pravidelné potápění pod kapotou, pokud by se vývojářský standardní požadavek MapReduce přestal provádět, když pracovník redukce dat vypadl z paměti kvůli nepříliš dobře zvolenému algoritmu rozdělení zdrojových dat.
Je Amazon S3 kandidátem na DataLake?
Zkušenosti s Hadoop/MapReduce nás naučily, že potřebujeme škálovatelný, spolehlivý souborový systém a nad ním škálovatelné pracovníky, kteří se „přibližují“ k datům, aby je nepřenášeli přes síť. Zaměstnanci by měli být schopni číst data v různých formátech, ale pokud možno nečíst zbytečné informace a měli by být schopni ukládat data předem ve formátech vhodných pro pracovníky.
Ještě jednou základní myšlenka. Není touha „nalévat“ velká data do jediného clusterového analytického enginu, který se dříve či později zadusí a vy je budete muset ošklivě nastříhat. Chci ukládat soubory, pouze soubory, ve srozumitelném formátu a provádět na ně efektivní analytické dotazy pomocí různých, ale srozumitelných nástrojů. A bude stále více souborů v různých formátech. A je lepší skartovat ne engine, ale zdrojová data. Potřebujeme rozšiřitelné a univerzální DataLake, rozhodli jsme se...
Co když ukládáte soubory do známého a známého škálovatelného cloudového úložiště Amazon S3, aniž byste si museli připravovat vlastní kotlety od Hadoop?
Je jasné, že osobních údajů je „nízké“, ale co ostatní údaje, když je vyjmeme a „efektivně je nasměrujeme“?
Ekosystém Cluster-bigdata-analytics Amazon Web Services – velmi jednoduchými slovy
Soudě podle našich zkušeností s AWS se tam Apache Hadoop/MapReduce dlouhodobě aktivně používá pod různými omáčkami, například ve službě DataPipeline (závidím kolegům, naučili se to správně připravovat). Zde nastavujeme zálohy z různých služeb z tabulek DynamoDB:
A již několik let pravidelně běží na vestavěných clusterech Hadoop/MapReduce jako hodinky. „Nastav to a zapomeň na to“:
Do datového satanismu se můžete také efektivně zapojit nastavením notebooků Jupiter v cloudu pro analytiky a pomocí služby AWS SageMaker k výcviku a nasazení modelů umělé inteligence do bitvy. U nás to vypadá takto:
A ano, můžete si vyzvednout notebook pro sebe nebo pro analytika v cloudu a připojit ho ke clusteru Hadoop/Spark, provést výpočty a pak vše vypilovat:
Opravdu vhodné pro jednotlivé analytické projekty a u některých jsme službu EMR úspěšně použili pro rozsáhlé výpočty a analýzy. A co systémové řešení pro DataLake, bude fungovat? V tuto chvíli jsme byli na pokraji naděje a zoufalství a pokračovali v hledání.
AWS Glue - úhledně zabalené Apache Spark na steroidech
Ukázalo se, že AWS má svou vlastní verzi zásobníku „Hive/Pig/Spark“. Role Úlu, tzn. Katalog souborů a jejich typů v DataLake provádí služba „Data Catalog“, která se netají svou kompatibilitou s formátem Apache Hive. Do této služby musíte přidat informace o tom, kde se vaše soubory nacházejí a v jakém jsou formátu. Data mohou být nejen v s3, ale i v databázi, ale to není předmětem tohoto příspěvku. Zde je návod, jak je uspořádán náš datový adresář DataLake:
Soubory jsou registrované, skvělé. Pokud byly soubory aktualizovány, spustíme prohledávače buď ručně, nebo podle plánu, které o nich aktualizují informace z jezera a uloží je. Poté lze data z jezera zpracovat a výsledky někam nahrát. V nejjednodušším případě nahráváme i do s3. Zpracování dat lze provést kdekoli, ale doporučuje se nakonfigurovat zpracování na clusteru Apache Spark pomocí pokročilých funkcí prostřednictvím rozhraní AWS Glue API. Ve skutečnosti můžete vzít starý dobrý a známý python kód pomocí knihovny pyspark a nakonfigurovat jeho spuštění na N uzlech clusteru určité kapacity s monitorováním, aniž byste se museli vrtat do útrob Hadoop a přetahovat kontejnery docker-moker a eliminovat konflikty závislostí. .
Ještě jednou jednoduchý nápad. Není třeba konfigurovat Apache Spark, stačí napsat python kód pro pyspark, otestovat jej lokálně na ploše a poté jej spustit na velkém clusteru v cloudu s uvedením, kde jsou zdrojová data a kam umístit výsledek. Někdy je to nutné a užitečné, a takto to nastavíme:
Pokud tedy potřebujete něco vypočítat na clusteru Spark pomocí dat v s3, napíšeme kód v python/pyspark, otestujeme ho a cloudu přejeme hodně štěstí.
A co orchestrace? Co když úkol padl a zmizel? Ano, je navrženo vytvořit krásné potrubí ve stylu Apache Pig a dokonce jsme je vyzkoušeli, ale prozatím jsme se rozhodli použít naši hluboce přizpůsobenou orchestraci v PHP a JavaScriptu (chápu, existuje kognitivní disonance, ale funguje to např. let a bez chyb).
Formát souborů uložených v jezeře je klíčem k výkonu
Je velmi, velmi důležité porozumět dalším dvěma klíčovým bodům. Aby byly dotazy na data souboru v jezeře provedeny co nejrychleji a výkon se nesnížil po přidání nových informací, musíte:
- Ukládejte sloupce souborů odděleně (abyste nemuseli číst všechny řádky, abyste pochopili, co je ve sloupcích). K tomu jsme vzali parketový formát s kompresí
- Je velmi důležité rozdělit soubory do složek jako: jazyk, rok, měsíc, den, týden. Motory, které rozumí tomuto typu shardingu, se podívají pouze na potřebné složky, aniž by probíraly všechna data za sebou.
V podstatě tak rozložíte zdrojová data v nejúčinnější podobě pro analytické nástroje zavěšené navrchu, které i v rozbitých složkách mohou selektivně zadávat a číst pouze potřebné sloupce ze souborů. Data nemusíte nikam „vyplňovat“ (úložiště prostě praskne) – stačí je okamžitě moudře vložit do souborového systému ve správném formátu. Samozřejmě by zde mělo být jasné, že ukládání velkého csv souboru do DataLake, který musí cluster nejprve načíst řádek po řádku, aby bylo možné extrahovat sloupce, není příliš vhodné. Zamyslete se znovu nad výše uvedenými dvěma body, pokud ještě není jasné, proč se to všechno děje.
AWS Athena – jack-in-the-box
A pak jsme při vytváření jezera nějak náhodou narazili na Amazonskou Athénu. Najednou se ukázalo, že pečlivým uspořádáním našich obrovských souborů protokolů do úlomků složek ve správném (parketním) formátu sloupců z nich můžete velmi rychle provádět extrémně informativní výběry a sestavovat sestavy BEZ, bez clusteru Apache Spark/Glue.
Motor Athena poháněný daty v s3 je založen na legendárním - zástupce MPP (masivní paralelní zpracování) rodiny přístupů ke zpracování dat, přebírá data tam, kde leží, od s3 a Hadoop až po Cassandru a běžné textové soubory. Stačí požádat Athenu, aby provedla SQL dotaz, a pak vše „funguje rychle a automaticky“. Je důležité poznamenat, že Athena je „chytrá“, jde pouze do nezbytných složek a čte pouze sloupce potřebné v požadavku.
Zajímavá je také cena za požadavky na Athenu. Platíme za . Tito. ne pro počet strojů v clusteru za minutu, ale... pro data skutečně naskenovaná na 100-500 strojích pouze data nezbytná k dokončení požadavku.
A tím, že jsme ze správně skartovaných složek požadovali jen potřebné sloupce, ukázalo se, že nás služba Athena stojí desítky dolarů měsíčně. No, skvělé, téměř zdarma, ve srovnání s analytikou na clusterech!
Mimochodem, takto skartujeme naše data v s3:
Výsledkem bylo, že během krátké doby začala zcela jiná oddělení ve společnosti, od bezpečnosti informací po analytiku, aktivně zadávat požadavky na Athenu a rychle, během několika sekund, dostávat užitečné odpovědi z „velkých“ dat za poměrně dlouhá období: měsíce, půl roku atd. P.
Ale šli jsme dál a začali jsme chodit pro odpovědi do cloudu : analytik napíše SQL dotaz ve známé konzoli, která na 100-500 strojích „za haléře“ odešle data do s3 a vrátí odpověď obvykle během několika sekund. Komfortní. A rychle. Pořád tomu nemůžu uvěřit.
V důsledku toho, když jsme se rozhodli ukládat data v s3, v efektivním sloupcovém formátu a s rozumným sdílením dat do složek... dostali jsme DataLake a rychlý a levný analytický engine - zdarma. A ve společnosti se stal velmi oblíbeným, protože... rozumí SQL a pracuje řádově rychleji než prostřednictvím spouštění/zastavování/nastavení clusterů. "A když je výsledek stejný, proč platit víc?"
Žádost k Athéně vypadá asi takto. Pokud si to přejete, můžete samozřejmě tvořit dost , ale omezíme se na jednoduché seskupování. Podívejme se, jaké kódy odezvy měl klient před několika týdny v protokolech webového serveru a ujistěte se, že neexistují žádné chyby:
Závěry
Poté, co jsme prošli, neřkuli dlouhou, ale strastiplnou cestou, neustálým adekvátním hodnocením rizik a úrovně složitosti a nákladů na podporu, jsme našli řešení pro DataLake a analytiku, které nás nikdy nepřestane potěšit jak rychlostí, tak náklady na vlastnictví.
Ukázalo se, že vybudování efektivního, rychlého a levného provozu DataLake pro potřeby zcela jiných oddělení společnosti je zcela v možnostech i zkušených vývojářů, kteří nikdy nepracovali jako architekti a neumí kreslit čtverce na čtverce pomocí šipky a znát 50 termínů z ekosystému Hadoop.
Na začátku cesty se mi třepala hlava z mnoha divokých zoologických zahrad s otevřeným a uzavřeným softwarem a pochopením tíhy odpovědnosti vůči potomkům. Stačí začít budovat své DataLake z jednoduchých nástrojů: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., sbírat zpětnou vazbu a hluboce porozumět fyzice probíhajících procesů. Vše složité a temné – dejte to nepřátelům a konkurentům.
Pokud nechcete jít do cloudu a rádi podporujete, aktualizujete a opravujete projekty s otevřeným zdrojovým kódem, můžete si lokálně vytvořit schéma podobné našemu na levných kancelářských strojích s Hadoop a Presto navrch. Hlavní je nezastavovat se a jít dál, počítat, hledat jednoduchá a jasná řešení a vše se určitě podaří! Hodně štěstí všem a zase na viděnou!
Zdroj: www.habr.com