Živimo u nevjerojatnom vremenu kada možete brzo i jednostavno spojiti nekoliko gotovih alata otvorenog koda, postaviti ih s "isključenom sviješću" prema savjetima stackoverflowa, bez zalaženja u "višestruka slova", i pokrenuti u komercijalni rad. A kad trebate ažurirati/proširiti ili netko slučajno ponovno pokrene par strojeva - shvatite da je započeo nekakav opsesivni loš san, sve se dramatično zakompliciralo do neprepoznatljivosti, nema povratka, budućnost je nejasna i sigurnija, umjesto programiranja, uzgajati pčele i raditi sir.
Nisu uzalud iskusniji kolege, s glavama išaranim greškama i stoga već sijedima, razmišljali o nevjerojatno brzom postavljanju paketa "kontejnera" u "kockama" na desecima poslužitelja na "pomodnim jezicima" s ugrađenom podrškom za asinkroni neblokirajući I/O, smiješi se skromno . I šutke nastavljaju ponovno čitati “man ps”, zadubljivati se u izvorni kod “nginxa” dok im oči ne prokrvare i pisati, pisati, pisati jedinične testove. Kolege znaju da će najzanimljivije biti kada “sve ovo” jednog dana postane ulog u noći na Staru godinu. A pomoći će im samo duboko razumijevanje prirode Unixa, memorirane TCP/IP tablice stanja i osnovnih algoritama sortiranja-pretraživanja. Vratiti sustav u život dok zvona udaraju.
O da, malo sam se rastresla, ali nadam se da sam uspjela prenijeti stanje iščekivanja.
Danas želim podijeliti naše iskustvo u postavljanju praktičnog i jeftinog paketa za DataLake, koji rješava većinu analitičkih zadataka u tvrtki za potpuno različite strukturne odjele.
Prije nekog vremena shvatili smo da tvrtke sve više trebaju plodove i proizvodne i tehničke analitike (da ne spominjemo šlag na torti u obliku strojnog učenja), a 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 s lansiranjem usluge Bitrix24, aktivno smo ulagali vrijeme i resurse u stvaranje jednostavne i pouzdane analitičke platforme koja bi pomogla brzo uočiti probleme u infrastrukturi i planirati sljedeći korak. Naravno, bilo je poželjno uzeti gotove alate koji su bili što jednostavniji i razumljiviji. Kao rezultat toga, nagios je odabran za praćenje, a munin za analitiku i vizualizaciju. Sada imamo tisuće čekova u nagiosima, stotine karata u muninu, a naši ih kolege uspješno koriste svaki dan. Mjerila su jasna, grafikoni pregledni, sustav radi pouzdano već nekoliko godina i redovito mu se dodaju novi testovi i grafikoni: kada pustimo novu uslugu u rad, dodamo nekoliko testova i grafikona. Sretno.
Pratite puls - napredna tehnička analitika
Želja za primanjem informacija o problemima "što je brže moguće" dovela nas je do aktivnih eksperimenata s jednostavnim i razumljivim alatima - pinba i xhprof.
Pinba nam je poslala statistiku u UDP paketima o brzini rada dijelova web stranica u PHP-u, a mogli smo vidjeti online u MySQL pohrani (Pinba dolazi s vlastitim MySQL motorom za brzu analizu događaja) kratki popis problema i odgovoriti na ih. A xhprof nam je automatski omogućio da prikupimo grafikone izvršavanja najsporijih PHP stranica od klijenata i analiziramo što bi moglo dovesti do toga - mirno, točenje čaja ili nešto jače.
Prije nekog vremena, alat je nadopunjen još jednim prilično jednostavnim i razumljivim motorom koji se temelji na algoritmu za obrnuto indeksiranje, savršeno implementiran u legendarnoj knjižnici Lucene - Elastic/Kibana. Jednostavna ideja o višenitnom snimanju dokumenata u inverzni Lucene indeks na temelju događaja u zapisima i brzom pretragom kroz njih pomoću podjele faseta pokazala se stvarno korisnom.
Unatoč prilično tehničkom izgledu vizualizacija u Kibani s konceptima niske razine poput "kante" koja "teče prema gore" i ponovnog izuma jezika još ne potpuno zaboravljene relacijske algebre, alat nam je počeo dobro pomagati u sljedećim zadacima:
- Koliko je PHP grešaka imao Bitrix24 klijent na p1 portalu u zadnjih sat vremena i kojih? Razumjeti, oprostiti i brzo ispraviti.
- Koliko je u protekla 24 sata obavljeno video poziva na portalima u Njemačkoj, koje kvalitete i je li bilo poteškoća s kanalom/mrežom?
- Koliko dobro funkcionira funkcionalnost sustava (naše C proširenje za PHP), kompajlirana iz izvora u najnovijem ažuriranju usluge i predstavljena klijentima? Postoje li segfaultovi?
- Slažu li se podaci o kupcima u PHP memoriju? Postoje li pogreške u vezi s prekoračenjem memorije dodijeljene procesima: "nema memorije"? Pronađite i neutralizirajte.
Evo konkretnog primjera. Unatoč temeljitom i višerazinskom testiranju, klijentu, s vrlo nestandardnim slučajem i oštećenim ulaznim podacima, pojavila se dosadna i neočekivana pogreška, oglasila se sirena i započeo je proces brzog otklanjanja:
Dodatno, kibana omogućuje organiziranje obavijesti za određene događaje, a u kratkom vremenu alat u tvrtki počeli su koristiti deseci zaposlenika iz različitih odjela – od tehničke podrške i razvoja do QA-a.
Aktivnost bilo kojeg odjela unutar tvrtke postalo je zgodno za praćenje i mjerenje - umjesto ručne analize zapisa na poslužiteljima, trebate samo jednom postaviti zapise parsiranja i poslati ih elastičnom klasteru kako biste uživali, na primjer, u razmišljanju u kibani nadzorna ploča broj prodanih dvoglavih mačića ispisan na 3-D printeru za prošli lunarni mjesec.
Osnovna poslovna analitika
Svima je poznato da poslovna analitika u tvrtkama često počinje iznimno aktivnim korištenjem, da, Excela. Ali glavna stvar je da tu nije kraj. Google Analytics temeljen na oblaku također dolijeva ulje na vatru - brzo se počinjete navikavati na dobre stvari.
U našoj tvrtki koja se skladno razvijala, tu i tamo su se počeli pojavljivati “proroci” intenzivnijeg rada s većim podacima. Redovito se počela javljati potreba za dubljim i višestranim izvješćima, a trudom momaka iz različitih odjela prije nekog vremena organizirano je jednostavno i praktično rješenje - kombinacija ClickHouse-a i PowerBI-a.
Dugo vremena je ovo fleksibilno rješenje puno pomoglo, ali postupno se počelo shvaćati da ClickHouse nije guma i da mu se ne može tako rugati.
Ovdje je važno dobro razumjeti da su ClickHouse, poput Druida, poput Vertice, poput Amazona RedShift (koji se temelji na postgresu), analitički motori optimizirani za prilično praktičnu analitiku (zbrojevi, agregacije, minimalno-maksimalno po stupcima i nekoliko mogućih spajanja ), jer organiziran za učinkovito pohranjivanje stupaca relacijskih tablica, za razliku od MySQL-a i drugih nama poznatih (redom orijentiranih) baza podataka.
U biti, ClickHouse je samo prostranija "baza podataka", s ne baš prikladnim umetanjem od točke do točke (tako je zamišljeno, sve je u redu), ali ugodnom analitikom i skupom zanimljivih moćnih funkcija za rad s podacima. Da, možete čak stvoriti klaster - ali znate da zakucavanje čavala mikroskopom nije sasvim ispravno i počeli smo tražiti druga rješenja.
Potražnja za pythonom i analitičarima
Naša tvrtka ima mnogo programera koji pišu kod gotovo svaki dan 10-20 godina u PHP-u, JavaScriptu, C#, C/C++, Javi, Go, Rust, Python, Bash. Postoje i mnogi iskusni administratori sustava koji su doživjeli više od jedne apsolutno nevjerojatne katastrofe koja se ne uklapa u zakone statistike (na primjer, kada je većina diskova u raid-10 uništena snažnim udarom groma). U takvim okolnostima, dugo vremena nije bilo jasno što je “python analitičar”. Python je poput PHP-a, samo je naziv malo dulji i ima malo manje tragova tvari koje mijenjaju um u izvornom kodu tumača. Međutim, kako se stvaralo sve više i više analitičkih izvješća, iskusni programeri počeli su sve više shvaćati važnost uske specijalizacije u alatima kao što su numpy, pandas, matplotlib, seaborn.
Presudnu ulogu je, najvjerojatnije, odigralo iznenadno padanje u nesvijest zaposlenika od spoja riječi “logistička regresija” i demonstracija učinkovitog izvještavanja o velikim podacima pomoću, da, da, pyspark.
Apache Spark, njegova funkcionalna paradigma u koju savršeno pristaje relacijska algebra i njegove mogućnosti ostavili su takav dojam na programere naviknute na MySQL da je potreba za jačanjem redova iskusnim analitičarima postala jasna kao dan.
Daljnji pokušaji uzleta Apache Spark/Hadoop i ono što nije išlo baš po scenariju
No, ubrzo se pokazalo da sa Sparkom nešto sistemski ne štima ili je jednostavno potrebno bolje oprati ruke. Ako su Hadoop/MapReduce/Lucene stog napravili prilično iskusni programeri, što je očito ako pažljivo pogledate izvorni kod u Javi ili ideje Douga Cuttinga u Luceneu, onda je Spark, odjednom, napisan na egzotičnom jeziku Scala, koji je vrlo kontroverzan s gledišta praktičnosti i trenutno se ne razvija. A redoviti pad kalkulacija na klasteru Spark zbog nelogičnog i ne baš transparentnog rada s dodjelom memorije za redukcijske operacije (mnogi ključevi stižu odjednom) stvorio je oko njega aureolu nečega što ima prostora za rast. Dodatno, situaciju je pogoršao velik broj čudnih otvorenih portova, privremenih datoteka koje rastu na najnerazumljivijim mjestima i paklenih ovisnosti o jar-u – zbog čega su administratori sustava imali jedan osjećaj dobro poznat iz djetinjstva: žestoka mržnja (ili možda trebali su oprati 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 ekosustav (i tako dalje i tako dalje). Unatoč činjenici da smo s vremenom naučili prilično dobro pripremiti i pratiti “to” i “to” se praktički prestalo iznenada rušiti zbog promjena u prirodi podataka i neravnoteže uniformnog RDD hashiranja, želja da se uzme nešto već spremno , ažuriran i administriran negdje u oblaku postajao je sve jači i jači. Upravo smo u to vrijeme pokušali upotrijebiti gotov sklop oblaka Amazon Web Services - i kasnije pokušao riješiti probleme pomoću njega. EMR je Apache Spark koji je pripremio Amazon s dodatnim softverom iz ekosustava, slično kao nadogradnje Cloudera/Hortonworks.
Gumena pohrana datoteka za analitiku je hitna potreba
Iskustvo "kuhanja" Hadoop/Spark s opeklinama na različitim dijelovima tijela nije bilo uzaludno. Potreba za stvaranjem jedinstvene, jeftine i pouzdane pohrane datoteka koja bi bila otporna na hardverske kvarove iu kojoj bi bilo moguće pohranjivati datoteke u različitim formatima iz različitih sustava te iz tih podataka praviti učinkovite i vremenski učinkovite uzorke za izvješća čisto.
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 analizom kilometarskih detaljnih zapisa klastera pomoću Spark History Servera i povećala s pozadinskim osvjetljenjem. Htio sam imati jednostavan i transparentan alat koji ne zahtijeva redovito ronjenje ispod haube ako se standardni MapReduce zahtjev programera prestane izvršavati kada reducirani podatkovni radnik ispadne iz memorije zbog ne baš dobro odabranog algoritma za particioniranje izvornih podataka.
Je li Amazon S3 kandidat za DataLake?
Iskustvo s Hadoop/MapReduce nas je naučilo da trebamo skalabilan, pouzdan datotečni sustav i skalabilne radnike povrh njega, koji "dolaze" bliže podacima kako ne bi prenosili podatke preko mreže. Radnici bi trebali moći čitati podatke u različitim formatima, ali po mogućnosti ne čitati nepotrebne informacije i biti u mogućnosti pohraniti podatke unaprijed u formatima pogodnim za radnike.
Još jednom, osnovna ideja. Nema želje da se veliki podaci "ulijevaju" u jedan klasterski analitički motor, koji će se prije ili kasnije ugušiti i morat ćete ga ružno razdvojiti. Želim pohraniti datoteke, samo datoteke, u razumljivom formatu i nad njima izvoditi učinkovite analitičke upite koristeći različite, ali razumljive alate. I bit će sve više datoteka u različitim formatima. I bolje je razdvojiti ne motor, već izvorne podatke. Trebamo proširivi i univerzalni DataLake, odlučili smo...
Što ako pohranjujete datoteke u poznatu i dobro poznatu skalabilnu pohranu u oblaku Amazon S3, bez potrebe da pripremate vlastite komade iz Hadoopa?
Jasno je da su osobni podaci "niski", ali što je s drugim podacima ako ih izvadimo i "učinkovito upravljamo"?
Cluster-bigdata-analytics ekosustav Amazon Web Services - vrlo jednostavnim riječima
Sudeći po našem iskustvu s AWS-om, Apache Hadoop/MapReduce se tamo već dugo aktivno koristi pod raznim umacima, na primjer u servisu DataPipeline (zavidim svojim kolegama, naučili su ga pravilno pripremiti). Ovdje postavljamo sigurnosne kopije iz različitih usluga iz DynamoDB tablica:
I redovito rade na ugrađenim Hadoop/MapReduce klasterima kao sat već nekoliko godina. "Postavi i zaboravi":
Također se možete učinkovito uključiti u podatkovni sotonizam postavljanjem prijenosnih računala Jupiter u oblak za analitičare i korištenjem usluge AWS SageMaker za obuku i implementaciju AI modela u bitku. Evo kako to kod nas izgleda:
I da, možete odabrati prijenosno računalo za sebe ili analitičara u oblaku i priključiti ga na Hadoop/Spark klaster, napraviti izračune i onda sve srediti:
Zaista prikladno za pojedinačne analitičke projekte, a za neke smo uspješno koristili uslugu EMR za velike izračune i analitiku. Što je sa sustavnim rješenjem za DataLake, hoće li funkcionirati? U ovom trenutku bili smo na rubu nade i očaja i nastavili potragu.
AWS Glue - uredno upakiran Apache Spark na steroidima
Ispostavilo se da AWS ima svoju verziju hrpe “Hive/Pig/Spark”. Uloga Košnice, t.j. Katalog datoteka i njihovih tipova u DataLakeu obavlja servis “Data catalog” koji ne skriva svoju kompatibilnost s formatom Apache Hive. Ovoj usluzi trebate dodati informacije o tome gdje se vaše datoteke nalaze i u kojem su formatu. Podaci mogu biti ne samo u s3, već iu bazi podataka, ali to nije tema ovog posta. Evo kako je organiziran naš DataLake direktorij podataka:
Datoteke su registrirane, super. Ako su datoteke ažurirane, ručno ili prema rasporedu pokrećemo alate za indeksiranje, koji će ažurirati informacije o njima iz jezera i spremiti ih. Zatim se podaci iz jezera mogu obraditi i rezultati negdje uploadati. U najjednostavnijem slučaju također uploadujemo na s3. Obrada podataka može se obaviti bilo gdje, ali se predlaže da konfigurirate obradu na Apache Spark klasteru koristeći napredne mogućnosti putem AWS Glue API-ja. Zapravo, možete uzeti dobri stari i poznati python kod pomoću biblioteke pyspark i konfigurirati njegovo izvođenje na N čvorova klastera određenog kapaciteta s nadzorom, bez kopanja po srži Hadoopa i povlačenja docker-moker kontejnera i eliminiranja sukoba ovisnosti .
Još jednom, jednostavna ideja. Nema potrebe konfigurirati Apache Spark, samo trebate napisati python kod za pyspark, testirati ga lokalno na radnoj površini i zatim pokrenuti na velikom klasteru u oblaku, navodeći gdje su izvorni podaci i gdje staviti rezultat. Ponekad je to potrebno i korisno, a evo kako to postavljamo:
Dakle, ako trebate izračunati nešto na Spark klasteru koristeći podatke u s3, mi pišemo kod u python/pyspark, testiramo ga i sretno u oblaku.
Što je s orkestracijom? Što ako zadatak padne i nestane? Da, predloženo je napraviti prekrasan cjevovod u stilu Apache Pig i čak smo ih isprobali, ali za sada smo odlučili koristiti našu duboko prilagođenu orkestraciju u PHP-u i JavaScriptu (razumijem, postoji kognitivna disonanca, ali funkcionira, za godine i bez grešaka).
Format datoteka pohranjenih u jezeru ključ je performansi
Vrlo je, vrlo važno razumjeti još dvije ključne točke. Kako bi se upiti o podacima datoteke u jezeru izvršili što je brže moguće i kako se izvedba ne bi smanjila kada se dodaju nove informacije, trebate:
- Pohranite stupce datoteka odvojeno (tako da ne morate čitati sve retke da biste razumjeli što je u stupcima). Za to smo uzeli format parketa s kompresijom
- Vrlo je važno podijeliti datoteke u mape kao što su: jezik, godina, mjesec, dan, tjedan. Motori koji razumiju ovu vrstu dijeljenja gledat će samo potrebne mape, bez prebiranja svih podataka u nizu.
U biti, na ovaj način postavljate izvorne podatke u najučinkovitijem obliku za analitičke motore obješene na vrhu, koji čak i u razdijeljenim mapama mogu selektivno ulaziti i čitati samo potrebne stupce iz datoteka. Ne morate nigdje "popuniti" podatke (skladište će jednostavno puknuti) - samo ih odmah mudro stavite u datotečni sustav u ispravnom formatu. Naravno, ovdje bi trebalo biti jasno da pohranjivanje ogromne csv datoteke u DataLake, koju klaster prvo mora pročitati red po red kako bi ekstrahirao stupce, nije baš preporučljivo. Ponovno razmislite o gornje dvije točke ako još nije jasno zašto se sve ovo događa.
AWS Athena - jack-in-the-box
A onda smo, stvarajući jezero, nekako slučajno naletjeli na amazonsku Atenu. Odjednom se pokazalo da pomnim raspoređivanjem naših golemih datoteka dnevnika u fragmente mapa u ispravnom (parketnom) formatu stupca, možete vrlo brzo napraviti izuzetno informativne odabire iz njih i izgraditi izvješća BEZ, bez Apache Spark/Glue klastera.
Athena motor pokretan podacima u s3 temelji se na legendarnom - predstavnik MPP (massive parallel processing) obitelji pristupa obradi podataka, uzimajući podatke tamo gdje leže, od s3 i Hadoopa 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 do potrebnih šardiranih mapa i čita samo stupce potrebne u zahtjevu.
Zanimljive su i cijene zahtjeva za Athenu. Mi plaćamo za . Oni. ne za broj strojeva u klasteru po minuti, nego... za podatke koji se stvarno skeniraju na 100-500 strojeva, samo podatke potrebne za dovršenje zahtjeva.
I traženjem samo potrebnih stupaca iz ispravno razdijeljenih mapa pokazalo se da nas usluga Athena košta desetke dolara mjesečno. Pa super, skoro besplatno, u usporedbi s analitikom na klasterima!
Usput, evo kako dijelimo svoje podatke u s3:
Kao rezultat toga, u kratkom vremenu, potpuno različiti odjeli u tvrtki, od informacijske sigurnosti do analitike, počeli su aktivno upućivati zahtjeve Atheni i brzo, u nekoliko sekundi, dobivati korisne odgovore iz “velikih” podataka tijekom prilično dugih razdoblja: mjeseci, pola godine itd. P.
Ali otišli smo dalje i počeli ići u oblak po odgovore : analitičar piše SQL upit u poznatoj konzoli, koja na 100-500 strojeva "za sitne pare" šalje podatke na s3 i vraća odgovor obično za nekoliko sekundi. Udobno. I to brzo. Još uvijek ne mogu vjerovati.
Kao rezultat toga, nakon što smo odlučili pohraniti podatke u s3, u učinkovitom stupčastom formatu i s razumnim dijeljenjem podataka u mape... dobili smo DataLake i brz i jeftin analitički mehanizam - besplatno. I postao je vrlo popularan u društvu, jer... razumije SQL i radi redove veličine brže nego kroz pokretanje/zaustavljanje/postavljanje klastera. "A ako je rezultat isti, zašto platiti više?"
Molba Ateni izgleda otprilike ovako. Po želji, naravno, možete formirati dovoljno , ali ćemo se ograničiti na jednostavno grupiranje. Pogledajmo koje je kodove odgovora klijent imao prije nekoliko tjedana u zapisnicima web poslužitelja i uvjerimo se da nema pogrešaka:
Zaključci
Prošavši, da ne kažem dug, ali bolan put, konstantno adekvatno procjenjujući rizike i razinu složenosti i cijene podrške, pronašli smo rješenje za DataLake i analitiku koje nas ne prestaje veseliti i brzinom i troškom vlasništva.
Pokazalo se da je izgradnja učinkovitog, brzog i jeftinog DataLakea za potrebe potpuno različitih odjela tvrtke u potpunosti unutar mogućnosti čak i iskusnih programera koji nikad nisu radili kao arhitekti i ne znaju crtati kvadrate na kvadratima s strelice i znati 50 pojmova iz Hadoop ekosustava.
Na početku puta glava mi se cijepala od brojnih divljih zooloških vrtova otvorenog i zatvorenog softvera i shvaćanja tereta odgovornosti prema potomcima. Jednostavno počnite graditi svoj DataLake pomoću 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 ići u oblak i volite podržavati, ažurirati i krpati projekte otvorenog koda, možete izgraditi shemu sličnu našoj lokalno, na jeftinim uredskim strojevima s Hadoopom i Presto na vrhu. Glavna stvar je ne stati i krenuti naprijed, brojati, tražiti jednostavna i jasna rješenja i sve će sigurno uspjeti! Sretno svima i vidimo se opet!
Izvor: www.habr.com