Živimo u nevjerovatnom vremenu kada možete brzo i jednostavno povezati nekoliko gotovih alata otvorenog koda, podesiti ih sa „isključenom svijesti“ prema savjetu stackoverflow-a, bez udubljivanja u „više slova“, i pokrenuti ih u komercijalni rad. A kada treba da ažurirate/proširite ili neko slučajno restartuje par mašina - shvatite da je u stvarnosti počeo neki opsesivni loš san, sve se odjednom zakomplikovalo do neprepoznatljivosti, nema povratka, budućnost je nejasna i sigurnije, umjesto programiranja, uzgajati pčele i raditi sir.
Nije uzalud što iskusnije kolege, glave posute greškama i samim tim već sijedih, razmišljaju o nevjerovatno brzom postavljanju paketa "kontejnera" u "kocke" na desetine servera na "modnim jezicima" s ugrađenom podrškom za asinhroni neblokirajući I/O, skromno se nasmiješi. I u tišini nastavljaju da čitaju „man ps“, udubljuju se u „nginx“ izvorni kod sve dok im oči ne prokrvare, i pišu, pišu, pišu jedinične testove. Kolege znaju da će najzanimljivije doći kada "sve ovo" jednog dana bude ukovano noću u novogodišnjoj noći. A pomoći će im samo duboko razumijevanje prirode unix-a, memorisana TCP/IP tabela stanja i osnovni algoritmi za sortiranje i pretraživanje. Da se sistem vrati u život dok se zvono oglasi.
O da, malo sam se omestio, ali nadam se da sam uspeo da prenesem stanje iščekivanja.
Danas želim podijeliti naše iskustvo u implementaciji prikladnog i jeftinog steka za DataLake, koji rješava većinu analitičkih zadataka u kompaniji za potpuno različite strukturne odjele.
Prije nekog vremena došli smo do shvaćanja da kompanijama sve više trebaju plodovi i proizvodne i tehničke analitike (da ne spominjemo šlag na tortu u vidu mašinskog učenja) i da bismo razumjeli trendove i rizike – moramo prikupljati i analizirati sve više i više metrika.
Osnovna tehnička analitika u Bitrix24
Prije nekoliko godina, istovremeno sa lansiranjem usluge Bitrix24, aktivno smo ulagali vrijeme i resurse u kreiranje jednostavne i pouzdane analitičke platforme koja bi pomogla da se brzo sagledaju problemi u infrastrukturi i isplanira sljedeći korak. Naravno, bilo je preporučljivo uzeti gotove alate koji su bili što jednostavniji i razumljiviji. Kao rezultat toga, nagios je izabran za praćenje, a munin za analitiku i vizualizaciju. Sada imamo hiljade čekova u nagiosima, stotine karata u muninu, a naše kolege ih svakodnevno koriste uspješno. metrike su jasne, grafikoni jasni, sistem radi pouzdano već nekoliko godina i redovno mu se dodaju novi testovi i grafovi: kada puštamo u rad novi servis, dodajemo nekoliko testova i grafikona. Sretno.
Prst na pulsu - napredna tehnička analitika
Želja da dobijemo informacije o problemima „što je brže moguće“ dovela nas je do aktivnih eksperimenata sa jednostavnim i razumljivim alatima - pinba i xhprof.
Pinba nam je slala statistiku u UDP paketima o brzini rada dijelova web stranica u PHP-u, a mogli smo vidjeti online u MySQL skladištu (Pinba dolazi sa vlastitim MySQL motorom za brzu analizu događaja) kratku listu problema i odgovore na njima. A xhprof nam je automatski omogućio da prikupimo grafikone izvršavanja najsporijih PHP stranica od klijenata i analiziramo šta bi moglo dovesti do toga - mirno, sipanje čaja ili nešto jače.
Prije nekog vremena, komplet alata je dopunjen još jednim prilično jednostavnim i razumljivim motorom baziranim na algoritmu obrnutog indeksiranja, savršeno implementiranom u legendarnoj Lucene biblioteci - Elastic/Kibana. Jednostavna ideja višenitnog snimanja dokumenata u inverzni Lucene indeks na temelju događaja u zapisnicima i brzog pretraživanja kroz njih pomoću podjele faseta pokazala se stvarno korisnom.
Unatoč prilično tehničkom izgledu vizualizacija u Kibani s konceptima niskog nivoa poput „kante“ „teče prema gore“ i ponovo izmišljenog jezika još ne potpuno zaboravljene relacijske algebre, alat nam je počeo dobro pomagati u sljedećim zadacima:
- Koliko PHP grešaka je klijent Bitrix24 imao na p1 portalu u zadnjih sat vremena i koje? Shvatite, oprostite i brzo ispravite.
- Koliko je video poziva obavljeno na portalima u Njemačkoj u prethodna 24 sata, s kojim kvalitetom i da li je bilo poteškoća sa kanalom/mrežom?
- Koliko dobro funkcionira sistemska funkcionalnost (naša C ekstenzija za PHP), kompajlirana iz izvora u najnovijem ažuriranju usluge i predstavljena klijentima? Postoje li segfaulti?
- Da li se podaci korisnika uklapaju u PHP memoriju? Ima li grešaka u vezi prekoračenja memorije dodijeljene procesima: „nedostaje memorije“? Pronađite i neutralizirajte.
Evo konkretnog primjera. Uprkos detaljnom i višeslojnom testiranju, klijent je, sa vrlo nestandardnim kućištem i oštećenim ulaznim podacima, dobio dosadnu i neočekivanu grešku, oglasila se sirena i započeo je proces brzog otklanjanja iste:
Dodatno, kibana vam omogućava da organizujete obaveštenja za određene događaje, a za kratko vreme alat u kompaniji počelo je da koristi desetine zaposlenih iz različitih sektora – od tehničke podrške i razvoja do QA.
Aktivnost bilo kojeg odjela unutar kompanije postalo je zgodno za praćenje i mjerenje - umjesto ručnog analiziranja dnevnika na serverima, potrebno je samo jednom postaviti raščlanjivanje dnevnika i poslati ih u elastični klaster kako biste uživali, na primjer, u kontemplaciji u kibani kontrolna tabla broj prodanih dvoglavih mačića odštampan na 3-D štampaču za posljednji lunarni mjesec.
Osnovna poslovna analitika
Svi znaju da poslovna analitika u kompanijama često počinje izuzetno aktivnom upotrebom, da, Excela. Ali najvažnije je da se tu ne završava. Google Analytics bazirana na oblaku također dolijeva ulje na vatru – brzo se počinjete navikavati na dobre stvari.
U našoj kompaniji koja se skladno razvija, tu i tamo su počeli da se pojavljuju „proroci“ intenzivnijeg rada sa većim podacima. Potreba za detaljnijim i višestrukim izvještajima počela se redovno pojavljivati, a zalaganjem momaka iz različitih odjela prije nekog vremena organizirano je jednostavno i praktično rješenje – kombinacija ClickHouse i PowerBI.
Dosta dugo je ovo fleksibilno rješenje puno pomagalo, ali postepeno je počelo shvaćanje da ClickHouse nije gumena i ne može se tako ismijavati.
Ovdje je važno dobro razumjeti da su ClickHouse, poput Druida, poput Vertice, poput Amazona RedShift (koji je baziran na postgresu), analitički motori optimizirani za prilično zgodnu analitiku (zbirovi, agregacije, minimum-maksimum po stupcu i nekoliko mogućih spajanja ), jer organizovan za efikasno skladištenje kolona relacionih tabela, za razliku od MySQL-a i drugih nama poznatih baza podataka (orijentisanih na redove).
U suštini, ClickHouse je samo prostranija „baza podataka“, sa ne baš zgodnim umetanjem tačke po tačku (tako je zamišljeno, sve je ok), ali prijatnom analitikom i skupom zanimljivih moćnih funkcija za rad sa podacima. Da, čak možete stvoriti klaster - ali razumijete da zabijanje eksera mikroskopom nije sasvim ispravno i počeli smo tražiti druga rješenja.
Potražnja za pitonom i analitičarima
Naša kompanija ima mnogo programera koji skoro svaki dan pišu kod 10-20 godina u PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash. Postoji i mnogo iskusnih sistem administratora koji su doživjeli više od jedne apsolutno nevjerovatne katastrofe koja se ne uklapa u zakone statistike (na primjer, kada je većina diskova u raid-10 uništena jakim udarom groma). U takvim okolnostima, dugo vremena nije bilo jasno šta je „pajton analitičar“. Python je kao PHP, samo što je ime malo duže i ima malo manje tragova supstanci koje mijenjaju um u izvornom kodu interpretatora. Međutim, kako se stvaralo sve više analitičkih izvještaja, iskusni programeri su počeli sve više shvaćati važnost uske specijalizacije u alatima kao što su numpy, pandas, matplotlib, seaborn.
Odlučujuću ulogu je, najvjerovatnije, odigrala iznenadna nesvjestica zaposlenih od kombinacije riječi “logistička regresija” i demonstracija efikasnog izvještavanja o velikim podacima koristeći, da, da, pyspark.
Apache Spark, njegova funkcionalna paradigma na koju se relaciona algebra savršeno uklapa, i njegove mogućnosti ostavile su takav utisak na programere naviknute na MySQL da je potreba za jačanjem redova iskusnim analitičarima postala jasna kao dan.
Dalji pokušaji Apache Spark/Hadoop-a da uzleti i ono što nije išlo sasvim po scenariju
Međutim, ubrzo je postalo jasno da sa Sparkom nešto sistemski nije u redu, ili je jednostavno bilo potrebno bolje oprati ruke. Ako su Hadoop/MapReduce/Lucene stek napravili prilično iskusni programeri, što je očigledno ako se pažljivo pogleda izvorni kod u Javi ili ideje Douga Cuttinga u Luceneu, onda je Spark, odjednom, napisan na egzotičnom jeziku Scala, koji je vrlo kontroverzan sa stanovišta praktičnosti i trenutno se ne razvija. A redoviti pad kalkulacija na Spark klasteru zbog nelogičnog i ne baš transparentnog rada s dodjelom memorije za operacije redukcije (mnogo ključeva stiže odjednom) stvorio je oko njega oreol nečega što ima prostora za rast. Dodatno, situaciju je pogoršavao veliki broj čudnih otvorenih portova, privremeni fajlovi koji su rasli na najnerazumljivijim mestima i paklene zavisnosti od jar-a - zbog čega su administratori sistema imali jedan osećaj koji je bio poznat od detinjstva: žestoku mržnju (ili možda morali su da operu ruke sapunom).
Kao rezultat toga, "preživjeli" smo nekoliko internih analitičkih projekata koji aktivno koriste Apache Spark (uključujući Spark Streaming, Spark SQL) i Hadoop ekosistem (i tako dalje i tako dalje). Unatoč činjenici da smo s vremenom naučili prilično dobro pripremiti i pratiti “to” i “to” je praktički prestalo naglo rušiti zbog promjena u prirodi podataka i neravnoteže ujednačenog RDD heširanja, želja da uzmemo nešto već spremno , ažuriran i administriran negdje u oblaku postajao je sve jači i jači. U to vrijeme smo pokušali koristiti gotovi cloud sklop Amazon Web Services - i, nakon toga, pokušao da reši probleme koristeći ga. EMR je Apache Spark koji je pripremio Amazon s dodatnim softverom iz ekosistema, slično kao Cloudera/Hortonworks build.
Gumeno skladištenje datoteka za analitiku je hitna potreba
Iskustvo “kuvanja” Hadoopa/Sparka sa opekotinama na raznim dijelovima tijela nije bilo uzaludno. Potreba za stvaranjem jedinstvenog, jeftinog i pouzdanog skladišta datoteka koji bi bio otporan na hardverske kvarove i u kojem bi bilo moguće pohranjivati datoteke u različitim formatima iz različitih sistema i praviti efikasne i vremenski efikasne uzorke za izvještaje iz ovih podataka postajala je sve izraženija. jasno.
Također sam želio da se ažuriranje softvera ove platforme ne pretvori u novogodišnju noćnu moru s čitanjem Java tragova od 20 stranica i analiziranjem kilometarskih detaljnih dnevnika klastera koristeći Spark History Server i lupu s pozadinskim osvjetljenjem. Želio sam imati jednostavan i transparentan alat koji ne zahtijeva redovno ronjenje ispod haube ako programerov standardni MapReduce zahtjev prestane da se izvršava kada radnik smanjenja podataka ispadne iz memorije zbog ne baš dobro odabranog algoritma za particioniranje izvornih podataka.
Da li je Amazon S3 kandidat za DataLake?
Iskustvo sa Hadoop/MapReduce naučilo nas je da nam je potreban skalabilan, pouzdan sistem datoteka i skalabilni radnici povrh njega, koji će se „približiti“ podacima kako ne bi prenosili podatke preko mreže. Radnici bi trebali biti u mogućnosti čitati podatke u različitim formatima, ali poželjno je da ne čitaju nepotrebne informacije i da mogu unaprijed pohraniti podatke u formatima koji su pogodni za radnike.
Još jednom, osnovna ideja. Nema želje da se veliki podaci „sipaju“ u jedan analitički motor klastera, koji će se prije ili kasnije ugušiti i morat ćete ga ružno razbiti. Želim da skladištim datoteke, samo datoteke, u razumljivom formatu i obavljam efikasne analitičke upite na njima koristeći različite, ali razumljive alate. I biće sve više datoteka u različitim formatima. I bolje je dijeliti ne motor, već izvorne podatke. Potreban nam je proširiv i univerzalni DataLake, odlučili smo...
Šta ako pohranjujete datoteke u poznatom i dobro poznatom skalabilnom oblaku za pohranu Amazon S3, a da ne morate sami pripremati svoje komade iz Hadoopa?
Jasno je da su lični podaci „niski“, ali šta je sa ostalim podacima ako ih izvadimo i „efikasno upravljamo“?
Cluster-bigdata-analytics ekosistem Amazon Web Services - vrlo jednostavnim riječima
Sudeći po našem iskustvu sa AWS-om, Apache Hadoop/MapReduce se tamo već duže vreme aktivno koristi pod raznim sosovima, na primer u servisu DataPipeline (zavidim kolegama, naučili su kako da ga pravilno pripreme). Ovdje postavljamo sigurnosne kopije različitih servisa iz DynamoDB tabela:
I već nekoliko godina redovno rade na ugrađenim Hadoop/MapReduce klasterima kao sat. “Podesi i zaboravi”:
Takođe možete efikasno da se bavite satanizmom podataka postavljanjem Jupiter laptopa u oblaku za analitičare i korišćenjem usluge AWS SageMaker za obuku i implementaciju AI modela u borbu. Evo kako to kod nas izgleda:
I da, možete pokupiti laptop za sebe ili analitičara u oblaku i priključiti ga na Hadoop/Spark klaster, izvršiti proračune i onda sve zakucati:
Zaista zgodno za pojedinačne analitičke projekte, a za neke smo uspješno koristili EMR uslugu za velike proračune i analitiku. Šta je sa sistemskim rješenjem za DataLake, hoće li raditi? U ovom trenutku bili smo na ivici nade i očaja i nastavili smo potragu.
AWS Glue - uredno upakovan Apache Spark na steroidima
Ispostavilo se da AWS ima svoju verziju "Hive/Pig/Spark" steka. Uloga košnice, tj. Katalog datoteka i njihovih tipova u DataLake-u obavlja servis „Katalog podataka“, koji ne krije svoju kompatibilnost sa formatom Apache Hive. Ovoj usluzi morate dodati informacije o tome gdje se nalaze vaši fajlovi i u kom su formatu. Podaci mogu biti ne samo u s3, već iu bazi podataka, ali to nije tema ovog posta. Evo kako je naš DataLake direktorij podataka organiziran:
Fajlovi su registrovani, odlično. Ako su fajlovi ažurirani, pokrećemo pretraživače ručno ili po rasporedu, koji će ažurirati informacije o njima iz jezera i pohraniti ih. Tada se podaci iz jezera mogu obraditi i rezultati negdje postaviti. U najjednostavnijem slučaju, također prenosimo na s3. Obrada podataka se može obaviti bilo gdje, ali se predlaže da konfigurirate obradu na Apache Spark klasteru koristeći napredne mogućnosti putem AWS Glue API-ja. U stvari, možete uzeti stari dobri i poznati Python kod koristeći pyspark biblioteku i konfigurirati njegovo izvršavanje na N čvorova klastera određenog kapaciteta uz praćenje, bez kopanja po utrobi Hadoop-a i povlačenja docker-moker kontejnera i eliminacije sukoba ovisnosti .
Još jednom, jednostavna ideja. Nema potrebe da konfigurišete Apache Spark, samo trebate napisati python kod za pyspark, testirati ga lokalno na radnoj površini i zatim ga pokrenuti na velikom klasteru u oblaku, navodeći gdje su izvorni podaci i gdje staviti rezultat. Ponekad je ovo neophodno i korisno, a evo kako to postavljamo:
Stoga, ako trebate izračunati nešto na Spark klasteru koristeći podatke u s3, pišemo kod u python/pyspark, testiramo ga i sretno oblaku.
Šta je sa orkestracijom? Šta ako je zadatak pao i nestao? Da, predloženo je da se napravi prekrasan pipeline u stilu Apache Pig i čak smo ih isprobali, ali za sada smo odlučili da koristimo našu duboko prilagođenu orkestraciju u PHP-u i JavaScriptu (razumijem, postoji kognitivna disonanca, ali radi, jer godine i bez grešaka).
Format datoteka pohranjenih u jezeru je ključ performansi
Vrlo, veoma je važno razumjeti još dvije ključne tačke. Da bi se upiti o podacima datoteke u jezeru izvršili što je brže moguće i da se performanse ne bi pogoršale kada se dodaju nove informacije, potrebno je:
- Čuvajte kolone datoteka odvojeno (tako da ne morate čitati sve redove da biste razumjeli šta se nalazi u kolonama). Za to smo uzeli format parketa sa kompresijom
- Veoma je važno podijeliti fajlove u foldere kao što su: jezik, godina, mjesec, dan, sedmica. Motori koji razumiju ovu vrstu dijeljenja će gledati samo potrebne mape, bez pregledavanja svih podataka u nizu.
U suštini, na ovaj način izvorne podatke postavljate u najefikasnijem obliku za analitičke mašine okačene na vrh, koje čak iu razdijeljenim folderima mogu selektivno unositi i čitati samo potrebne kolone iz datoteka. Ne morate nigdje "puniti" podatke (skladištenje će jednostavno puknuti) - samo ih odmah mudro stavite u sistem datoteka u ispravnom formatu. Naravno, ovdje treba biti jasno da pohranjivanje ogromne csv datoteke u DataLake, koju klaster mora prvo pročitati red po red kako bi izdvojio kolone, nije baš preporučljivo. Ponovo razmislite o gornje dvije tačke ako još nije jasno zašto se sve ovo dešava.
AWS Athena - jack-in-the-box
A onda, dok smo stvarali jezero, nekako smo slučajno naišli na Amazonsku Atenu. Odjednom se pokazalo da pažljivim sređivanjem naših ogromnih log fajlova u fragmente foldera u ispravnom (parketnom) formatu kolone, možete vrlo brzo napraviti izuzetno informativne selekcije iz njih i praviti izvještaje BEZ, bez Apache Spark/Glue klastera.
Athena motor pokretan podacima u s3 baziran je na legendarnom - predstavnik MPP (massive paralelne obrade) porodice pristupa obradi podataka, uzimajući podatke tamo gdje leže, od s3 i Hadoop-a do Cassandre i običnih tekstualnih datoteka. Samo trebate zamoliti Athenu da izvrši SQL upit, a onda sve "radi brzo i automatski". Važno je napomenuti da je Athena “pametna”, ide samo u potrebne razdijeljene mape i čita samo kolone potrebne u zahtjevu.
Zanimljiva je i cijena za zahtjeve Ateni. Mi plaćamo . One. ne za broj mašina u klasteru u minuti, već... za podatke koji su stvarno skenirani na 100-500 mašina, samo podaci potrebni za završetak zahtjeva.
I traženjem samo potrebnih kolona iz ispravno podijeljenih foldera, pokazalo se da nas usluga Athena košta desetine dolara mjesečno. Pa, odlično, skoro besplatno, u poređenju sa analitikom na klasterima!
Usput, evo kako dijelimo naše podatke u s3:
Kao rezultat toga, za kratko vrijeme, potpuno različiti odjeli u kompaniji, od informacione sigurnosti do analitike, počeli su aktivno upućivati zahtjeve Ateni i brzo, u sekundi, dobijati korisne odgovore iz „velikih“ podataka u prilično dugim periodima: mjeseci, pola godine itd. P.
Ali otišli smo dalje i počeli da idemo u oblak po odgovore : analitičar piše SQL upit u poznatoj konzoli, koja na 100-500 mašina "za peni" šalje podatke na s3 i vraća odgovor obično za nekoliko sekundi. Udoban. I brzo. Još uvijek ne mogu vjerovati.
Kao rezultat toga, odlučivši da podatke pohranjujemo u s3, u efikasnom kolonskom formatu i sa razumnim dijeljenjem podataka u foldere... dobili smo DataLake i brz i jeftin analitički mehanizam - besplatno. I postao je veoma popularan u kompaniji, jer... razumije SQL i radi redove veličine brže nego kroz pokretanje/zaustavljanje/postavljanje klastera. “A ako je rezultat isti, zašto plaćati više?”
Zahtjev Ateni izgleda otprilike ovako. Po želji, naravno, možete formirati dovoljno , ali ćemo se ograničiti na jednostavno grupisanje. Pogledajmo koje je kodove odgovora klijent imao prije nekoliko sedmica u logovima web servera i provjerimo da nema grešaka:
nalazi
Prošavši, da ne kažem dug, ali bolan put, konstantno adekvatno procjenjujući rizike i nivo složenosti i cijene podrške, pronašli smo rješenje za DataLake i analitiku koje nas ne prestaje oduševljavati brzinom i cijenom vlasništva.
Pokazalo se da je izgradnja efikasnog, brzog i jeftinog za rad DataLake-a za potrebe potpuno različitih odjela kompanije u potpunosti u mogućnostima čak i iskusnih programera koji nikada nisu radili kao arhitekti i ne znaju crtati kvadrate na kvadratima sa strelice i znaju 50 pojmova iz Hadoop ekosistema.
Na početku putovanja glava mi se cijepala od brojnih divljih zooloških vrtova otvorenog i zatvorenog softvera i razumijevanja tereta odgovornosti prema potomcima. Samo počnite graditi svoj DataLake od jednostavnih alata: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., prikupljajući povratne informacije i duboko razumijevajući fiziku procesa koji se odvijaju. Sve složeno i mutno - dajte neprijateljima i konkurentima.
Ako ne želite da idete u oblak i volite da podržavate, ažurirate i krpite projekte otvorenog koda, možete izgraditi šemu sličnu našoj lokalno, na jeftinim uredskim mašinama sa Hadoop i Presto na vrhu. Glavna stvar je ne stati i ići naprijed, računati, tražiti jednostavna i jasna rješenja i sve će sigurno uspjeti! Sretno svima i vidimo se opet!
izvor: www.habr.com