Trăim într-o perioadă uimitoare în care puteți conecta rapid și ușor mai multe instrumente open-source gata făcute, le puteți configura cu „conștiința oprită” conform sfatului stackoverflow, fără să vă adânciți în „mai multe litere” și să lansați ei în exploatare comercială. Și când trebuie să actualizați/extindeți sau cineva repornește accidental câteva mașini - vă dați seama că a început un fel de vis obsesiv obsesiv, totul s-a complicat dramatic dincolo de recunoaștere, nu există întoarcere, viitorul este vag și mai sigur, în loc să programați, creșteți albine și faceți brânză.
Nu degeaba colegii mai experimentați, cu capul presărat cu bug-uri și, prin urmare, deja gri, contemplând implementarea incredibil de rapidă a pachetelor de „containere” în „cuburi” pe zeci de servere în „limbi la modă” cu suport încorporat pentru I/O asincron neblocant, zâmbește modest. Și continuă să citească în tăcere „man ps”, să se adâncească în codul sursă „nginx” până le sângerează ochii și să scrie, să scrie, să scrie teste unitare. Colegii știu că cel mai interesant lucru va veni atunci când „toate acestea” într-o zi vor deveni mizate în noaptea de Revelion. Și vor fi ajutați doar de o înțelegere profundă a naturii Unix, a tabelului de stare TCP/IP memorat și a algoritmilor de bază de sortare-căutare. Pentru a readuce sistemul la viață în timp ce sunetul clopoțelului.
A, da, m-am distras puțin, dar sper că am reușit să transmit starea de anticipare.
Astăzi vreau să împărtășesc experiența noastră în implementarea unei stive convenabile și ieftine pentru DataLake, care rezolvă majoritatea sarcinilor analitice din companie pentru divizii structurale complet diferite.
Cu ceva timp în urmă, am ajuns la înțelegerea că companiile au nevoie din ce în ce mai mult de fructele analizei de produs și ale analizei tehnice (să nu mai vorbim de cireașa de pe tort sub formă de machine learning) și pentru a înțelege tendințele și riscurile - trebuie să colectăm și să analizăm din ce în ce mai multe valori.
Analiza tehnică de bază în Bitrix24
În urmă cu câțiva ani, simultan cu lansarea serviciului Bitrix24, am investit în mod activ timp și resurse în crearea unei platforme analitice simple și de încredere, care să ajute să vedem rapid problemele din infrastructură și să planificăm următorul pas. Desigur, era indicat să luați instrumente gata făcute, cât mai simple și de înțeles posibil. Ca urmare, nagios a fost ales pentru monitorizare și munin pentru analiză și vizualizare. Acum avem mii de verificări în nagios, sute de diagrame în munin, iar colegii noștri le folosesc cu succes în fiecare zi. Valorile sunt clare, graficele sunt clare, sistemul funcționează fiabil de câțiva ani și la acesta se adaugă în mod regulat noi teste și grafice: atunci când punem în funcțiune un nou serviciu, adăugăm mai multe teste și grafice. Noroc.
Finger on the Pulse - Analiză tehnică avansată
Dorința de a primi informații despre probleme „cât mai repede posibil” ne-a condus la experimente active cu instrumente simple și ușor de înțeles - pinba și xhprof.
Pinba ne-a trimis statistici în pachete UDP despre viteza de funcționare a părților paginilor web în PHP și am putut vedea online în stocarea MySQL (Pinba vine cu propriul motor MySQL pentru analiza rapidă a evenimentelor) o scurtă listă de probleme și răspuns la lor. Iar xhprof ne-a permis automat să colectăm grafice ale execuției celor mai lente pagini PHP de la clienți și să analizăm ce ar putea duce la asta - calm, turnând ceai sau ceva mai puternic.
Cu ceva timp în urmă, setul de instrumente a fost completat cu un alt motor destul de simplu și de înțeles bazat pe algoritmul de indexare inversă, implementat perfect în legendara bibliotecă Lucene - Elastic/Kibana. Ideea simplă a înregistrării cu mai multe fire a documentelor într-un index Lucene invers bazat pe evenimente din jurnale și o căutare rapidă prin ele folosind diviziunea fațetă s-a dovedit a fi cu adevărat utilă.
În ciuda aspectului destul de tehnic al vizualizărilor în Kibana cu concepte de nivel scăzut precum „găleată” „curgând în sus” și limbajul reinventat al algebrei relaționale încă neuitate complet, instrumentul a început să ne ajute bine în următoarele sarcini:
- Câte erori PHP a avut clientul Bitrix24 pe portalul p1 în ultima oră și care? Înțelegeți, iertați și corectați rapid.
- Câte apeluri video au fost efectuate pe portaluri din Germania în ultimele 24 de ore, cu ce calitate și au existat dificultăți cu canalul/rețeaua?
- Cât de bine funcționează funcționalitatea sistemului (extensia noastră C pentru PHP), compilată din sursă în cea mai recentă actualizare a serviciului și lansată clienților? Există defecte de segment?
- Datele clienților se potrivesc în memoria PHP? Există erori legate de depășirea memoriei alocate proceselor: „memorie lipsită”? Găsiți și neutralizați.
Iată un exemplu concret. În ciuda testării amănunțite și pe mai multe niveluri, clientul, cu un caz foarte nestandard și cu date de intrare deteriorate, a primit o eroare enervantă și neașteptată, a sunat o sirenă și a început procesul de remediere rapidă a acesteia:
În plus, kibana vă permite să organizați notificări pentru evenimente specificate, iar în scurt timp instrumentul din companie a început să fie folosit de zeci de angajați din diferite departamente - de la suport tehnic și dezvoltare până la QA.
Activitatea oricărui departament din cadrul companiei a devenit convenabil de urmărit și măsurat - în loc să analizați manual jurnalele de pe servere, trebuie doar să configurați jurnalele de parsare o dată și să le trimiteți la clusterul elastic pentru a vă bucura, de exemplu, de a contempla în kibana. tabloul de bord numărul de pisoi cu două capete vânduți imprimat pe o imprimantă 3-D pentru ultima lună lunară.
Analiza de bază a afacerilor
Toată lumea știe că analiza de afaceri în companii începe adesea cu utilizarea extrem de activă a, da, Excel. Dar principalul lucru este că nu se termină aici. Google Analytics bazat pe cloud adaugă, de asemenea, combustibil focului - începeți rapid să vă obișnuiți cu lucrurile bune.
În compania noastră în dezvoltare armonioasă, au început să apară ici și colo „profeți” de muncă mai intensă cu date mai mari. Nevoia de rapoarte mai aprofundate și cu mai multe fațete a început să apară în mod regulat, iar prin eforturile băieților din diferite departamente, cu ceva timp în urmă a fost organizată o soluție simplă și practică - o combinație de ClickHouse și PowerBI.
Pentru o perioadă destul de lungă, această soluție flexibilă a ajutat foarte mult, dar treptat a început să se înțeleagă că ClickHouse nu este cauciuc și nu poate fi batjocorit așa.
Aici este important să înțelegem bine că ClickHouse, ca Druid, ca Vertica, ca Amazon RedShift (care se bazează pe postgres), sunt motoare analitice optimizate pentru analize destul de convenabile (sume, agregări, minim-maxim pe coloană și câteva posibile îmbinări). ), deoarece organizat pentru stocarea eficientă a coloanelor de tabele relaționale, spre deosebire de MySQL și alte baze de date (orientate pe rând) cunoscute nouă.
În esență, ClickHouse este doar o „bază de date” mai încăpătoare, cu o inserare punct cu punct nu foarte convenabilă (așa este intenționată, totul este în regulă), dar o analiză plăcută și un set de funcții interesante și puternice pentru lucrul cu date. Da, puteți chiar să creați un cluster - dar înțelegeți că baterea cuielor cu un microscop nu este în întregime corectă și am început să căutăm alte soluții.
Cererea de python și analiști
Compania noastră are mulți dezvoltatori care scriu cod aproape în fiecare zi timp de 10-20 de ani în PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash. Există, de asemenea, mulți administratori de sistem cu experiență care au suferit mai mult de un dezastru absolut incredibil care nu se încadrează în legile statisticii (de exemplu, când majoritatea discurilor dintr-un raid-10 sunt distruse de un fulger puternic). În astfel de circumstanțe, pentru o lungă perioadă de timp nu a fost clar ce este un „analist python”. Python este ca PHP, doar că numele este puțin mai lung și există puțin mai puține urme de substanțe care modifică mintea în codul sursă al interpretului. Cu toate acestea, pe măsură ce erau create tot mai multe rapoarte analitice, dezvoltatorii experimentați au început să înțeleagă din ce în ce mai mult importanța specializării restrânse în instrumente precum numpy, panda, matplotlib, seaborn.
Rolul decisiv, cel mai probabil, l-a jucat leșinul brusc al angajaților din combinația cuvintelor „regresie logistică” și demonstrarea raportării eficiente a datelor mari folosind, da, da, pyspark.
Apache Spark, paradigma sa funcțională pe care algebra relațională se potrivește perfect și capacitățile sale au făcut o astfel de impresie asupra dezvoltatorilor obișnuiți cu MySQL, încât nevoia de a întări rândurile cu analiști experimentați a devenit clară ca ziua.
Alte încercări ale Apache Spark/Hadoop de a decola și ceea ce nu a mers tocmai conform scriptului
Cu toate acestea, curând a devenit clar că ceva nu era în regulă sistemic cu Spark sau pur și simplu era necesar să vă spălați mai bine mâinile. Dacă stiva Hadoop/MapReduce/Lucene a fost realizată de programatori destul de experimentați, ceea ce este evident dacă priviți îndeaproape codul sursă în Java sau ideile lui Doug Cutting în Lucene, atunci Spark, brusc, este scris în limbajul exotic Scala, care este foarte controversat din punct de vedere practic și în prezent nu se dezvoltă. Și scăderea obișnuită a calculelor pe clusterul Spark din cauza lucrului ilogic și nu foarte transparent cu alocare de memorie pentru operațiuni de reducere (multe chei sosesc odată) a creat un halou în jurul lui de ceva care are loc să crească. În plus, situația a fost agravată de un număr mare de porturi ciudate deschise, fișiere temporare care creșteau în locurile cele mai de neînțeles și un iad de dependențe de borcan - care i-au făcut pe administratorii de sistem să aibă un sentiment binecunoscut încă din copilărie: ură aprigă (sau poate trebuiau să se spele pe mâini cu săpun).
Drept urmare, am „supraviețuit” mai multor proiecte analitice interne care utilizează în mod activ Apache Spark (inclusiv Spark Streaming, Spark SQL) și ecosistemul Hadoop (și așa mai departe). În ciuda faptului că de-a lungul timpului am învățat să ne pregătim și să-l monitorizăm destul de bine, iar „el” practic a încetat să se prăbușească brusc din cauza modificărilor naturii datelor și a dezechilibrului hashing-ului RDD uniform, dorința de a lua ceva deja gata. , actualizat și administrat undeva în cloud a devenit din ce în ce mai puternic. În acest moment am încercat să folosim ansamblul cloud gata făcut al Amazon Web Services - și, ulterior, a încercat să rezolve probleme folosindu-l. EMR este Apache Spark pregătit de Amazon cu software suplimentar din ecosistem, la fel ca build-urile Cloudera/Hortonworks.
Stocarea fișierelor din cauciuc pentru analiză este o nevoie urgentă
Experiența de a „găti” Hadoop/Spark cu arsuri în diferite părți ale corpului nu a fost în zadar. Nevoia de a crea o unitate de stocare a fișierelor unică, ieftină și fiabilă, care să fie rezistentă la defecțiuni hardware și în care să fie posibilă stocarea fișierelor în diferite formate din diferite sisteme și realizarea de mostre eficiente și eficiente din timp pentru rapoartele din aceste date. iese din ce în ce mai clar.
De asemenea, mi-am dorit ca actualizarea software-ului acestei platforme să nu se transforme într-un coșmar de Anul Nou cu citirea urmelor Java de 20 de pagini și analizarea jurnalelor detaliate de un kilometru lungi ale clusterului folosind Spark History Server și o lupă iluminată din spate. Am vrut să am un instrument simplu și transparent, care să nu necesite scufundări regulate sub capotă, dacă cererea standard MapReduce a dezvoltatorului a încetat să se execute când lucrătorul de reducere a datelor a căzut din memorie din cauza unui algoritm de partiționare a datelor sursă nu foarte bine ales.
Este Amazon S3 un candidat pentru DataLake?
Experiența cu Hadoop/MapReduce ne-a învățat că avem nevoie de un sistem de fișiere scalabil, de încredere și de lucrători scalabili în plus, „apropiindu-se” mai mult de date pentru a nu transmite datele prin rețea. Lucrătorii ar trebui să poată citi datele în formate diferite, dar de preferință să nu citească informații inutile și să poată stoca datele în avans în formate convenabile pentru lucrători.
Încă o dată, ideea de bază. Nu există nicio dorință de a „turna” date mari într-un singur motor analitic de cluster, care mai devreme sau mai târziu se va sufoca și va trebui să le spargeți urât. Vreau să stochez fișiere, doar fișiere, într-un format ușor de înțeles și să efectuez interogări analitice eficiente asupra lor folosind instrumente diferite, dar ușor de înțeles. Și vor exista tot mai multe fișiere în diferite formate. Și este mai bine să fragmentați nu motorul, ci datele sursă. Avem nevoie de un DataLake extensibil și universal, am decis...
Ce se întâmplă dacă stocați fișiere în stocarea cloud scalabilă familiară și binecunoscută Amazon S3, fără a fi nevoie să vă pregătiți propriile cotlete de la Hadoop?
Este clar că datele personale sunt „scăzute”, dar cum rămâne cu alte date dacă le scoatem acolo și „le conducem eficient”?
Ecosistemul Cluster-bigdata-analytics al Amazon Web Services - în cuvinte foarte simple
Judecând după experiența noastră cu AWS, Apache Hadoop/MapReduce a fost folosit activ acolo de mult timp sub diverse sosuri, de exemplu în serviciul DataPipeline (i-i invidiez pe colegii mei, au învățat să-l pregătească corect). Aici am configurat copii de rezervă de la diferite servicii din tabelele DynamoDB:
Și rulează în mod regulat pe clustere Hadoop/MapReduce încorporate, cum ar fi un ceas de câțiva ani. „Setați-l și uitați-l”:
De asemenea, vă puteți implica eficient în satanismul datelor instalând laptop-uri Jupiter în cloud pentru analiști și folosind serviciul AWS SageMaker pentru a antrena și a implementa modele AI în luptă. Iată cum arată pentru noi:
Și da, puteți ridica un laptop pentru dvs. sau pentru un analist în cloud și îl puteți atașa la un cluster Hadoop/Spark, puteți face calculele și apoi puneți totul în picioare:
Cu adevărat convenabil pentru proiecte analitice individuale și pentru unele am folosit cu succes serviciul EMR pentru calcule și analize la scară largă. Dar o soluție de sistem pentru DataLake, va funcționa? În acest moment eram în pragul speranței și disperării și am continuat căutarea.
AWS Glue - Apache Spark bine ambalat pe steroizi
S-a dovedit că AWS are propria sa versiune a stivei „Hive/Pig/Spark”. Rolul lui Hive, i.e. Catalogul de fișiere și tipurile acestora în DataLake este realizat de serviciul „Catalog de date”, care nu ascunde compatibilitatea acestuia cu formatul Apache Hive. Trebuie să adăugați informații la acest serviciu despre unde se află fișierele dvs. și în ce format sunt acestea. Datele pot fi nu numai în s3, ci și în baza de date, dar nu acesta este subiectul acestei postări. Iată cum este organizat directorul nostru de date DataLake:
Fișierele sunt înregistrate, grozav. Dacă fișierele au fost actualizate, lansăm crawlerele fie manual, fie conform unui program, care vor actualiza informațiile despre ele din lac și le vor salva. Apoi datele din lac pot fi procesate și rezultatele încărcate undeva. În cel mai simplu caz, încărcăm și în s3. Procesarea datelor se poate face oriunde, dar se recomandă să configurați procesarea pe un cluster Apache Spark folosind capabilități avansate prin API-ul AWS Glue. De fapt, puteți lua codul python vechi și familiar, folosind biblioteca pyspark și configurați execuția acestuia pe N noduri ale unui cluster de o anumită capacitate cu monitorizare, fără a săpa în curajul Hadoop și a trage containerele docker-moker și a elimina conflictele de dependență. .
Încă o dată, o idee simplă. Nu este nevoie să configurați Apache Spark, trebuie doar să scrieți cod python pentru pyspark, să îl testați local pe desktop și apoi să îl rulați pe un cluster mare în cloud, specificând unde sunt datele sursă și unde să puneți rezultatul. Uneori, acest lucru este necesar și util și iată cum îl configuram:
Astfel, dacă trebuie să calculați ceva pe un cluster Spark folosind date în s3, scriem cod în python/pyspark, îl testăm și noroc în cloud.
Dar orchestrația? Ce se întâmplă dacă sarcina a căzut și a dispărut? Da, se propune să facem un pipeline frumos în stilul Apache Pig și chiar le-am încercat, dar deocamdată am decis să folosim orchestrația noastră profund personalizată în PHP și JavaScript (înțeleg, există disonanță cognitivă, dar funcționează, pt. ani și fără erori).
Formatul fișierelor stocate în lac este cheia performanței
Este foarte, foarte important să înțelegeți încă două puncte cheie. Pentru ca interogările privind datele fișierelor din lac să fie executate cât mai repede posibil și performanța să nu se degradeze atunci când se adaugă informații noi, trebuie să:
- Stocați coloanele de fișiere separat (pentru a nu fi necesar să citiți toate rândurile pentru a înțelege ce este în coloane). Pentru asta am luat formatul de parchet cu compresie
- Este foarte important să împărțiți fișierele în foldere precum: limbă, an, lună, zi, săptămână. Motoarele care înțeleg acest tip de sharding se vor uita doar la folderele necesare, fără a verifica toate datele la rând.
În esență, în acest fel, așezați datele sursă în cea mai eficientă formă pentru motoarele analitice agățate deasupra, care chiar și în folderele fragmentate pot introduce și citi selectiv doar coloanele necesare din fișiere. Nu trebuie să „umpleți” datele oriunde (stocarea va exploda pur și simplu) - puneți-le imediat cu înțelepciune în sistemul de fișiere în formatul corect. Desigur, ar trebui să fie clar aici că stocarea unui fișier csv uriaș în DataLake, care trebuie mai întâi citit linie cu linie de către cluster pentru a extrage coloanele, nu este foarte recomandabilă. Gândiți-vă din nou la cele două puncte de mai sus dacă nu este încă clar de ce se întâmplă toate acestea.
AWS Athena - jack-in-the-box
Și apoi, în timp ce cream un lac, am dat cumva accidental de Amazon Athena. Dintr-o dată s-a dovedit că, prin aranjarea cu atenție a fișierelor noastre jurnal uriașe în fragmente de foldere în formatul corect de coloană (parchet), puteți face foarte rapid selecții extrem de informative din ele și puteți construi rapoarte FĂRĂ, fără un cluster Apache Spark/Glue.
Motorul Athena alimentat de date în s3 se bazează pe legendarul - un reprezentant al familiei MPP (massive parallel processing) de abordări ale procesării datelor, preluând datele acolo unde se află, de la s3 și Hadoop la Cassandra și fișiere text obișnuite. Trebuie doar să îi cereți Athenei să execute o interogare SQL și apoi totul „funcționează rapid și automat”. Este important să rețineți că Athena este „inteligentă”, merge doar la folderele sharded necesare și citește doar coloanele necesare în cerere.
Prețul pentru cererile către Athena este, de asemenea, interesant. Plătim pentru . Acestea. nu pentru numărul de mașini din cluster pe minut, ci... pentru datele efectiv scanate pe 100-500 de mașini, doar datele necesare pentru a finaliza solicitarea.
Și solicitând doar coloanele necesare din folderele fragmentate corect, s-a dovedit că serviciul Athena ne costă zeci de dolari pe lună. Ei bine, grozav, aproape gratuit, în comparație cu analiza pe clustere!
Apropo, iată cum ne împărțim datele în s3:
Drept urmare, în scurt timp, departamente complet diferite ale companiei, de la securitatea informațiilor la analiză, au început să facă în mod activ solicitări către Athena și rapid, în câteva secunde, să primească răspunsuri utile de la date „mari” pe perioade destul de lungi: luni, jumătate de an etc. P.
Dar am mers mai departe și am început să mergem la nor pentru răspunsuri : un analist scrie o interogare SQL într-o consolă familiară, care pe 100-500 de mașini „pentru bănuți” trimite date către s3 și returnează un răspuns de obicei în câteva secunde. Confortabil. Și repede. încă nu-mi vine să cred.
Drept urmare, după ce am decis să stocăm datele în s3, într-un format de coloană eficient și cu împărțirea rezonabilă a datelor în foldere... am primit DataLake și un motor analitic rapid și ieftin - gratuit. Și a devenit foarte popular în companie, pentru că... înțelege SQL și funcționează ordine de mărime mai rapid decât prin pornirea/oprirea/configurarea clusterelor. „Și dacă rezultatul este același, de ce să plătești mai mult?”
O cerere către Athena arată cam așa. Dacă doriți, desigur, puteți forma suficient , dar ne vom limita la simpla grupare. Să vedem ce coduri de răspuns a avut clientul în urmă cu câteva săptămâni în jurnalele serverului web și să ne asigurăm că nu există erori:
Constatări
După ce am parcurs, ca să nu spunem o cale lungă, dar dureroasă, evaluând în mod constant în mod adecvat riscurile și nivelul de complexitate și costul suportului, am găsit o soluție pentru DataLake și analize care nu încetează să ne mulțumească atât prin viteza, cât și prin costul de proprietate.
S-a dovedit că construirea unui DataLake eficient, rapid și ieftin de operat pentru nevoile unor departamente complet diferite ale companiei este complet în competențele dezvoltatorilor cu experiență, care nu au lucrat niciodată ca arhitecți și nu știu cum să deseneze pătrate pe pătrate cu săgeți și cunoaște 50 de termeni din ecosistemul Hadoop.
La începutul călătoriei, capul meu s-a despărțit de numeroasele grădini zoologice sălbatice de software deschis și închis și de înțelegerea poverii responsabilității față de descendenți. Începeți să vă construiți DataLake din instrumente simple: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., culegând feedback și înțelegând profund fizica proceselor care au loc. Totul complex și tulbure - dă-l inamicilor și concurenților.
Dacă nu doriți să mergeți în cloud și vă place să susțineți, să actualizați și să corectați proiecte open-source, puteți construi o schemă similară cu a noastră la nivel local, pe mașini de birou ieftine, cu Hadoop și Presto pe deasupra. Principalul lucru este să nu te oprești și să mergi înainte, să numeri, să cauți soluții simple și clare și totul se va rezolva cu siguranță! Succes tuturor și ne revedem!
Sursa: www.habr.com