Ne jemi nĂ« njĂ« kohĂ« tĂ« jashtĂ«zakonshme, kur Ă«shtĂ« e mundur tĂ« lidhen shpejt dhe lehtĂ« disa mjete tĂ« gatshme open-source, t'i konfigurojmĂ« ato me 'ndĂ«rgjegje tĂ« fikur' sipas kĂ«shillave tĂ« stackoverflow, pa u pĂ«rfshirĂ« nĂ« 'shkronja tĂ« shumta', dhe tĂ« nisemi pĂ«r shfrytĂ«zim komercial. Dhe kur tĂ« vijĂ« koha pĂ«r t'u pĂ«rditĂ«suar/zgjeruar ose kur dikush tĂ« rinisĂ« disa makina â do tĂ« kuptojmĂ« se ka filluar njĂ« Ă«ndĂ«rr e keqe qĂ« morton, gjithçka u komplikuar papritur deri nĂ« njohje, nuk ka rrugĂ« prapa, e ardhmja Ă«shtĂ« e paqartĂ« dhe mĂ« e sigurt, nĂ« vend tĂ« programimit, do tĂ« kujdesim pĂ«r bletĂ«t dhe do tĂ« bĂ«jmĂ« djathĂ«.
Nuk Ă«shtĂ« rastĂ«si qĂ« kolegĂ«t mĂ« tĂ« pĂ«rvojshĂ«m, me kokĂ« tĂ« bardhĂ« nga gabimet dhe shpejtĂ«sinĂ« e jashtĂ«zakonshme tĂ« shpĂ«rndarjes sĂ« dyzimeve nĂ« 'kubikĂ«t' e serverĂ«ve tĂ« shumtĂ« nĂ« 'gjuhĂ«t moderne' me mbĂ«shtetje tĂ« integruar pĂ«r hyrje-dalje asinkrone dhe jo bllokuese â qeshin me modestinĂ« e tyre. Dhe vazhdojnĂ« nĂ« heshtje tĂ« rishikojnĂ« 'man ps', ngulmojnĂ« deri nĂ« pikim nĂ« burimet e 'nginx' dhe shkruajnĂ«-testojnĂ« pa fund. Kolektet e dinĂ« qĂ« gjĂ«rat mĂ« interesante do tĂ« ndodhin mĂ« vonĂ«, kur 'gjithĂ« kjo' njĂ« natĂ« do tĂ« bĂ«het njĂ« ngarkesĂ« nĂ«n NatĂ«n e Re. Dhe do t'u ndihmojĂ« vetĂ«m njĂ« kuptim i thellĂ« i natyrĂ«s sĂ« unix, njĂ« tabelĂ« e mĂ«suar gjithashtu pĂ«r gjendjet e TCP/IP dhe algoritmet e bazuar nĂ« renditje-kĂ«rkim.
Ah po, pak u shkëputa, por shpresoj se arrita të transmetoj gjendjen e pritjes.
Sot dua të ndaj përvojën tonë në vendosjen e një staku të përshtatshëm dhe të lirë për DataLake, i cili zgjidh shumicën e problemeve analitike në kompani për struktura të ndryshme.
Pak kohĂ« mĂ« parĂ« arritĂ«m nĂ« pĂ«rfundimin se kompanitĂ« kanĂ« nevojĂ« gjithnjĂ« e mĂ« shumĂ« pĂ«r informacionin nga analizat produktore dhe teknike (pa pĂ«rmendur kurorĂ«n nĂ« tortĂ« si machine learning) dhe pĂ«r tĂ« kuptuar trendet dhe rreziqet â Ă«shtĂ« e nevojshme tĂ« mbledhim dhe analizojmĂ« gjithnjĂ« e mĂ« shumĂ« metrika.
Analiza e bazës teknike në 'Bitrix24'
Disa vite mĂ« parĂ«, nĂ« tĂ« njĂ«jtĂ«n kohĂ« me nisjen e shĂ«rbimit 'Bitrix24', ne investuam aktivisht kohĂ« dhe burime nĂ« krijimin e njĂ« platforme analitike tĂ« thjeshtĂ« dhe tĂ« besueshme, e cila ndihmon pĂ«r tĂ« parĂ« shpejt problemet nĂ« infrastrukturĂ« dhe pĂ«r tĂ« planifikuar hapat e afĂ«rt. Sigurisht, ishte e preferueshme tĂ« merrnim mjete tĂ« gatshme dhe sa mĂ« tĂ« thjeshta dhe tĂ« kuptueshme. Si rezultat, u zgjodhĂ«n nagios pĂ«r monitorim dhe munin pĂ«r analitikĂ« dhe vizualizim. Tani kemi mijĂ«ra kontrollime nĂ« nagios, qindra grafika nĂ« munin dhe kolegĂ«t tanĂ« i pĂ«rdorin ato çdo ditĂ« me sukses. Metrikat janĂ« tĂ« kuptueshme, grafikat janĂ« tĂ« qarta, sistemi funksionon besueshĂ«m pĂ«r disa vite dhe vazhdimisht shtohen teste dhe grafe tĂ« reja: kur fusim njĂ« shĂ«rbim tĂ« ri nĂ« pĂ«rdorim â shtojmĂ« disa teste dhe grafika. NĂ« rruge tĂ« mbarĂ«.
Dora nĂ« puls â analitika e avancuar teknike
Deshira pĂ«r tĂ« marrĂ« informacionin pĂ«r problemet 'sa mĂ« shpejt' na çoi nĂ« eksperimente aktive me mjete tĂ« thjeshta dhe tĂ« qarta â pinba dhe xhprof.
Pinba na dĂ«rgonte statistika pĂ«r shpejtĂ«sinĂ« e funksionimit tĂ« pjesĂ«ve tĂ« faqeve web nĂ« PHP nĂ« paketat UDP dhe mundĂ«m tĂ« shihnim nĂ« mĂ«nyrĂ« live nĂ« depozitat MySQL (me pinba ka motorin e vet MySQL pĂ«r analitikĂ« tĂ« shpejtĂ« tĂ« ngjarjeve) njĂ« listĂ« tĂ« shkurtĂ«r problemesh dhe tĂ« reagojmĂ« ndaj tyre. Xhprof nĂ« mĂ«nyrĂ« automatike lejonte tĂ« grumbullonim grafikĂ«t e ekzekutimit tĂ« faqeve PHP mĂ« tĂ« ngadalta te klientĂ«t dhe tĂ« analizojmĂ« se çfarĂ« mund tĂ« kishte shkaktuar kĂ«tĂ« â qetĂ«sisht, duke pirĂ« çaj ose ndonjĂ« gjĂ« mĂ« tĂ« fortĂ«.
Pak kohĂ« mĂ« parĂ«, arsenali u pasurua me njĂ« motor tjetĂ«r relativisht tĂ« thjeshtĂ« dhe tĂ« kuptueshĂ«m tĂ« bazuar nĂ« algoritmin e indeksimit tĂ« invers dhe tĂ« zbatuar mirĂ« nĂ« bibliotekĂ«n legjendare Lucene â Elastic/Kibana. Ideja e thjeshtĂ« e regjistrimit nĂ« shumĂ« rave dokumentesh nĂ« indeksin e invers tĂ« Lucene mbi bazĂ«n e ngjarjeve nĂ« log tĂ« ndihmonte vĂ«rtet.
PavarĂ«sisht nga pamja teknike e vizualizimeve nĂ« Kibana me konceptet e ulĂ«ta tĂ« nivelit 'bucket' dhe gjuhĂ«n e ri-shpikur tĂ« algjebrĂ«s relacional â mjeti na ndihmoi shumĂ« nĂ« kĂ«to detyra:
- Sa gabime PHP kishte klienti Bitrix24 në portalin p1 për orën e kaluar dhe cilat? Të kuptoj dhe të reagoj shpejt.
- Sa video-thirrje u bënë në portalet në Gjermani për 24 orët e fundit, me cilësinë e cila ishte dhe a kishte ndonjë problem me kanalin/rete?
- Sa mirë funksionon funksionaliteti sistemor (zgjerimi ynë në C për PHP), i kompiluar nga burimet në përditësimin e fundit të shërbimit dhe i shpërndarë për klientët? A ka ndonjë segfault?
- A kanë të dhënat e klientëve vendosur në memorjen PHP? A ka ndonjë gabim për tejkalimin e memories të ndara për proceset: «jashtë memories»? Gjej dhe neutralizo.
Ja një shembull konkret. Pavarësisht testimit të kujdesshëm dhe shumënivelësh, një klienti i është shfaqur një gabim i bezdisshëm dhe befasues për një rast shumë të pazakontë dhe të dhëna hyrëse të dëmtuara; alarmi është ndezur dhe ka filluar procesi i riparimit të shpejtë:
PĂ«r mĂ« tepĂ«r, kibana lejon organizimin e njoftimeve pĂ«r ngjarje tĂ« caktuara dhe nĂ« njĂ« kohĂ« tĂ« shkurtĂ«r, ky mjet filloi tĂ« pĂ«rdorej nga dhjetĂ«ra punonjĂ«s nga departamente tĂ« ndryshme â nga mbĂ«shtetje teknike dhe zhvillim deri nĂ« QA.
Aktiviteti i çdo departamenti brenda kompanisĂ« Ă«shtĂ« bĂ«rĂ« i lehtĂ« pĂ«r t'u ndjekur dhe matur â nĂ« vend tĂ« analizave manuale tĂ« skedave nĂ« servera, mjafton tĂ« konfiguroni njĂ«herĂ« analizĂ«n e skedave dhe dĂ«rgimin e tyre nĂ« klasterin elastic, pĂ«r tĂ« shijuar, pĂ«r shembull, pamjen nĂ« panelin e kibana tĂ« numrit tĂ« koteleve me dy kryqe qĂ« janĂ« printuar me printer 3-d pĂ«r muajin e kaluar hĂ«nor.
Analitika bazë e biznesit
TĂ« gjithĂ« e dinĂ« se shpesh analitika e biznesit nĂ« kompanitĂ« fillon me njĂ« pĂ«rdorim jashtĂ«zakonisht aktiv, po, po, Excel. Por, mĂ« e rĂ«ndĂ«sishmja, Ă«shtĂ« qĂ« ajo tĂ« mos pĂ«rfundojĂ« atje. Vaj i ri i zjarrit Ă«shtĂ« edhe Google Analytics nĂ« re â nĂ« tĂ« mirat fillon tĂ« besohet shpejt.
NĂ« kompaninĂ« tonĂ« qĂ« po zhvillohet nĂ« harmoni, janĂ« shfaqur kĂ«tu e atje, «profetë» tĂ« punĂ«s mĂ« intensive me tĂ« dhĂ«na mĂ« tĂ« mĂ«dha. KĂ«rkesat pĂ«r raporte mĂ« tĂ« thella dhe mĂ« shumĂ« dimensionale kanĂ« filluar tĂ« shfaqen rregullisht dhe me pĂ«rpjekjet e djemve nga departamente tĂ« ndryshme, disa kohĂ« mĂ« parĂ« u organizua njĂ« zgjidhje e thjeshtĂ« dhe praktike â lidhja ClickHouse dhe PowerBI.
Kjo zgjidhje fleksibël ka ndihmuar mirë për një kohë të gjatë, por gradualisht ka filluar të kuptohet se ClickHouse nuk është elastik dhe nuk mund të abuzohet me të.
ĂshtĂ« e rĂ«ndĂ«sishme tĂ« kuptohet mirĂ« se ClickHouse, ashtu si Druid, si Vertica, si Amazon RedShift (i bazuar nĂ« postgres), janĂ« motorĂ« analitikĂ« tĂ« optimizuar pĂ«r analitikĂ« mjaft tĂ« rehatshme (shuma, agregime, minimum-maksimum pĂ«r kolonĂ« dhe ndonjĂ« gjĂ« e vogĂ«l pĂ«r bashkimi), pasi janĂ« tĂ« organizuara pĂ«r ruajtjen efektive tĂ« kolonave tĂ« tabelave relacionales, ndryshe nga MySQL i njohur dhe bazat e tjera tĂ« dhĂ«nash (me orientim rresht).
NĂ« thelb, ClickHouse Ă«shtĂ« thjesht njĂ« âbazĂ«â mĂ« e madhe e tĂ« dhĂ«nave, me njĂ« futje jo shumĂ« praktike tĂ« pikave (ashtu Ă«shtĂ« menduar, gjithçka Ă«shtĂ« nĂ« rregull), por me analitikĂ« tĂ« kĂ«ndshme dhe njĂ« grup funksionesh interesante dhe tĂ« fuqishme pĂ«r punĂ«n me tĂ« dhĂ«nat. Po, mund tĂ« krijoni njĂ« klaster â por, e dini, qĂ« tĂ« godasĂ«sh me njĂ« thikĂ« ndĂ«rtimore me mikroskopin nuk Ă«shtĂ« krejtĂ«sisht e saktĂ« dhe ne filluam tĂ« kĂ«rkojmĂ« zgjidhje tĂ« tjera.
Kërkesa për python dhe analitikët
Në kompaninë tonë ka shumë zhvillues që shkruajnë kod pothuajse çdo ditë për 10-20 vite në PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash. Po ashtu shumë administratori të sistemit me përvojë, që kanë përjetuar jo një katastrofë të pabesueshme që s'është e përshtatshme për ligjet e statistikës (për shembull, kur shumica e disqeve në raid-10 shkatërrohen nga goditjet e forta të një shkrepjeje). Në këto kushte për një kohë të gjatë nuk ishte e qartë se çfarë është «analisti në python». Python është si PHP, vetëm emri është pak më i gjatë dhe mbetjet e substancave që ndryshojnë vetëdijen janë pak më të vogla në kodin burimor të interpretuesit. Megjithatë, me krijimin e raporteve të reja analitike, zhvilluesit e përvojshëm filluan të kuptojnë rëndësinë e specializimit të ngushtë në mjete si numpy, pandas, matplotlib, seaborn.
Roli vendimtar, ndoshta, u luajt nga përgjumja e papritur e punonjësve nga kombinimi i fjalëve «regresioni logjistik» dhe demonstruar ndërtimin efektiv të raporteve mbi të dhëna voluminoze me ndihmën e, po, pyspark.
Apache Spark, paradigma e tij funksionale, në të cilën përshtatet shumë mirë algebra relasionale, dhe mundësitë e tij kanë bërë një përshtypje të madhe te zhvilluesit e zakonshëm me MySQL, saqë nevoja për të forcuar radhët me analistë të përvojshëm u bë e qartë si dita.
Përpjekjet e mëtejshme të Apache Spark/Hadoop për të fluturuar dhe ajo që nuk shkoi krejt siç ishte parashikuar
MegjithatĂ«, sĂ« shpejti u kuptua se diçka me Spark, duket, nuk ishte tamam ashtu si duhet, ose ndoshta duhej thjesht tĂ« lahej mĂ« mirĂ«. NĂ«se staku Hadoop/MapReduce/Lucene ishte zhvilluar nga programues mjaft tĂ« aftĂ«, e cila Ă«shtĂ« e qartĂ« nĂ«se shikon me vĂ«mendje burimin nĂ« Java ose idetĂ« e Doug Cutting nĂ« Lucene, atĂ«herĂ« Spark, papritur, Ă«shtĂ« shkruar nĂ« njĂ« gjuhĂ« shumĂ« tĂ« diskutueshme nĂ« aspektin e praktikĂ«s dhe qĂ« aktualisht nuk po zhvillohet, gjuhĂ«n eksotike Scala. RrĂ«zimet e rregullta tĂ« llogaritjeve nĂ« klasterin Spark pĂ«r shkak tĂ« menaxhimit jo tĂ« logjikshĂ«m dhe jo shumĂ« tĂ« qartĂ« tĂ« memories pĂ«r operacionet reduce (vijnĂ« shumĂ« çelĂ«sa tĂ« papritur) krijuan rreth tij njĂ« aurĂ« tĂ« diçkaje qĂ« ka ende hapĂ«sirĂ« pĂ«r tĂ« ecur pĂ«rpara. PĂ«r mĂ« tepĂ«r, situatĂ«n e pĂ«rkeqĂ«sonte numri i madh i porteve tĂ« hapura tĂ« çuditshme, skedarĂ«ve pĂ«rkohĂ«shtarĂ« qĂ« rriteshin nĂ« vende shumĂ« tĂ« pakuptueshme dhe varĂ«sive tĂ« jar-it â qĂ« shkaktonte tek administratorĂ«t sistemorĂ« njĂ« ndjenjĂ« tĂ« njohur tashmĂ« nga fĂ«mijĂ«ria: njĂ« urrejtje tĂ« thellĂ« (ndoshta duhej tĂ« lahej me sapun).
Si rezultat, ne "përsimë" disa projekte të brendshme analitike, duke përdorur aktivisht Apache Spark (përfshirë Spark Streaming, Spark SQL) dhe ekosistemin Hadoop (dhe e tjera). Megjithatë, me kalimin e kohës, mësuam të "përgatisim" këtë mjaft mirë dhe ta monitorojmë dhe "ajo" pothuajse nuk ndalonte më papritur të binte për shkak të ndryshimit të natyrës së të dhënave dhe disbalancës së shpërndarjes së barabartë të hash-it RDD, dëshira për të marrë diçka të gatshme, të azhurnuar dhe të administruar diku në cloud ishte duke u intensifikuar gjithnjë e më shumë. Në këtë kohë, provuam të përdornim një paketë cloud të gatshme nga Amazon Web Services - dhe, më pas, përpiqeshim të zgjidhnim detyra tashmë në të. EMR është një Apache Spark i përgatitur nga Amazon me softver shtesë nga ekosistema, pak si paketat e Cloudera/Hortonworks.
"Depo" elastike për analitikë - një nevojë urgjente
Eksperienca e "përgatitjes" së Hadoop/Spark me djegie të disa pjesëve të trupit nuk ka kaluar kot. Nevojë për krijimin e një depoje të vetme të besueshme dhe të lirë, e cila do të ishte e qëndrueshme ndaj aksidenteve harduerike dhe në të cilën mund të ruanim skedarë në formate të ndryshme nga sisteme të ndryshme dhe të bënim seleksione efektive dhe në një kohë të arsyeshme për raporte për këto të dhëna, u bë gjithnjë e më e qartë.
Po ashtu, ne dëshirojmë që përditësimi i softverit të kësaj platforme të mos kthehet në një makth nate festash me leximin e shënimeve dhe analizimin e kilometrave të logëve të detajuar të punës së klasterit me ndihmën e Spark History Server dhe një lupë me ndriçim. Dëshira ishte të kishim një mjet të thjeshtë dhe të qartë që nuk kërkonzh pak që të mendohet, nëse zhvilluesi s'mund të ekzekutojë një kërkesë standarde MapReduce për shkak të humbjes së të dhënave nga diga e punës gjatë ndarjes së të dhënave për shkak të një algoritmi të papërshtatshëm të ndarjes në fillim.
A mundet Amazon S3 të jetë një kandidat për DataLake?
Përvoja me Hadoop/MapReduce na ka mësuar se na nevojitet një sistem skedari të besueshëm dhe të shkallëzueshëm dhe punëtorë të shkallëzuar mbi të, "duke ardhur" më afër të dhënave, që të mos na duhet të dërgojmë të dhënat nëpër rrjet. Punëtorët duhet të jenë në gjendje të lexojnë të dhëna në formate të ndryshme, por, idealisht, pa lexuar informacion të panevojshëm dhe që të jetë e mundur të ruani të dhënat paraprakisht në formate të përshtatshme për punëtorët.
NjĂ« herĂ« tjetĂ«r â ideja kryesore. Nuk ka dĂ«shirĂ« tĂ« "ngarkohet" njĂ« sasi e madhe tĂ« dhĂ«nash nĂ« njĂ« motor analitik tĂ« centralizuar qĂ« do tĂ« mbytet herĂ«t apo vonĂ« dhe do tĂ« duhet tĂ« ndahet nĂ« mĂ«nyrĂ« tĂ« çrregullt. DĂ«shira Ă«shtĂ« tĂ« ruhen skedarĂ«, thjesht skedarĂ«, nĂ« njĂ« format tĂ« kuptueshĂ«m dhe tĂ« bĂ«hen kĂ«rkesa efektive analitike pĂ«rmes mjeteve tĂ« ndryshme, por tĂ« kuptueshme. Dhe numri i skedarĂ«ve nĂ« formate tĂ« ndryshme do tĂ« rritet gjithnjĂ« e mĂ« shumĂ«. Dhe mĂ« mirĂ« tĂ« ndahet jo motori, por tĂ« dhĂ«nat origjinale. KĂ«shtu, vendosĂ«m se na nevojitet njĂ« DataLake i shkallĂ«zueshĂ«m dhe universale...
ĂfarĂ« ndodh nĂ«se ruajmĂ« skedarĂ«t nĂ« njĂ« depo tĂ« njohur dhe tĂ« shkallĂ«zuar, Amazon S3, pa u marrĂ« me pĂ«rgatitjen e vetĂ« Hadoop-it?
E qartë, të dhënat personale "nuk lejohet", por a ka ndonjë mundësi që, nëse i nxjerrim ato dhe "të pastrojmë" efikasitetin?
Ekosistemi analitik i Amazon Web Services më klasteret e mëdhenj të të dhënave - në fjalë shumë të thjeshta
Sipas eksperiencës sonë me AWS, atje përdoret prej kohësh dhe aktivisht Apache Hadoop/MapReduce nën sos gjithnjë të ndryshme, për shembull në shërbimin DataPipeline (e kam xhelozi për kolegët, pse ata dinë ta përgatitin siç duhet). Këtu ne vendosëm backup nga shërbime të ndryshme nga tabelat DynamoDB:
Dhe ato kryhen rregullisht në klasterët e integruar Hadoop/MapReduce si orë tashmë për disa vite. "E vendosa dhe e harrova":
Gjithashtu, Ă«shtĂ« e mundur tĂ« angazhohesh nĂ« dataĆtanizĂ«m, duke ngritur Jupiter-notebooks pĂ«r analistĂ«t nĂ« cloud dhe duke pĂ«rdorur pĂ«r trajnimin dhe shpĂ«rndarjen e modeleve AI shĂ«rbimin AWS SageMaker. Ja se si duket kjo pĂ«r ne:
Po, mund të ngresh një laptop analitik në cloud dhe ta lidhësh atë me një klasër Hadoop/Spark, të bësh llogaritjet dhe më pas të "marrësh" të gjitha.
Në të vërtetë, është shumë e përshtatshme për projekte të veçanta analitike dhe për disa prej tyre kemi përdorur me sukses shërbimin EMR për llogaritje dhe analizë të mëdha. Si është situata për një zgjidhje sistematike për DataLake, a do t'ia dalim? Në atë moment ne ishim në prag të shpresës dhe dëshpërimit dhe vazhduam kërkimin.
AWS Glue â njĂ« Apache Spark i paketuar nĂ« mĂ«nyrĂ« tĂ« saktĂ« "nĂ« steroide"
Doli se AWS ka një version "të vetin" të stack-ut "Hive/Pig/Spark". Roli i Hive, pra, katalogu i skedarëve dhe llojeve të tyre në DataLake, e kryen shërbimi "Data catalog", i cili nuk fshihet nga përputhshmëria e saj me formatin Apache Hive. Në këtë shërbim duhet të shtosh informacionin se ku ndodhen skedarët dhe në cilin format janë. Të dhënat mund të jenë jo vetëm në s3, por edhe në një bazë të dhënash, por për këtë nuk do të flasim në këtë postim. Ja si është organizuar katalogu i të dhënave DataLake tek ne:
SkedarĂ«t janĂ« regjistruar, shkĂ«lqyer. NĂ«se skedarĂ«t janĂ« pĂ«rditĂ«suar â ekzekutojmĂ« manualisht ose sipas njĂ« orari crawlers, tĂ« cilĂ«t do tĂ« pĂ«rditĂ«sojnĂ« informacionin dhe do ta ruajnĂ«. MĂ« pas, tĂ« dhĂ«nat nga liqeni mund tĂ« pĂ«rpunohen dhe rezultatet mund tĂ« dĂ«rgohen diku. NĂ« rastin mĂ« tĂ« thjeshtĂ« â dĂ«rgojmĂ« gjithashtu nĂ« s3. PĂ«rpunimi i tĂ« dhĂ«nave mund tĂ« bĂ«het kudo, por rekomandohet tĂ« konfigurohet procesi i pĂ«rpunimit nĂ« njĂ« klasĂ«r Apache Spark duke pĂ«rdorur mundĂ«sitĂ« e avancuara pĂ«rmes API AWS Glue. NĂ« tĂ« vĂ«rtetĂ«, mund tĂ« marrĂ«sh kodin tradicional dhe tĂ« njohur nĂ« python duke pĂ«rdorur bibliotekĂ«n pyspark dhe ta konfiguroni pĂ«r ekzekutim nĂ« N noda tĂ« klasit me njĂ«farĂ« fuqie me monitorim, pa u nxjerrĂ« nĂ« detaje tĂ« Hadoop-it dhe pa u marrĂ« me konfliktet e varĂ«sive.
NjĂ« herĂ« tjetĂ«r â ide e thjeshtĂ«. Nuk ka nevojĂ« tĂ« konfigurosh Apache Spark, duhet vetĂ«m tĂ« shkruash kod nĂ« python pĂ«r pyspark, ta testosh atĂ« lokal nĂ« desktopin tĂ«nd dhe mĂ« pas ta ekzekutosh nĂ« njĂ« klasĂ«r tĂ« madh nĂ« cloud, duke specifikuar ku ndodhen tĂ« dhĂ«nat origjinale dhe ku tĂ« vendoset rezultati. Nsometimes, kjo Ă«shtĂ« e nevojshme dhe e dobishme dhe ja si e kemi konfiguruar tek ne:
Pra, nĂ«se nevojitet tĂ« bĂ«sh ndonjĂ« llogaritje nĂ« klastri Spark me tĂ« dhĂ«na nga s3 â shkruaj kodin nĂ« python/pyspark, testojeni dhe pĂ«rpara nĂ« cloud.
Dhe çfarĂ« me orkestrimin? ĂfarĂ« nĂ«se detyra dĂ«shton dhe humbet? Po, sugjerohet tĂ« krijosh njĂ« pipeline tĂ« bukur nĂ« stilin e Apache Pig dhe madje e provuam, por vendosĂ«m pĂ«r momentin tĂ« pĂ«rdorim orkestrimin tonĂ« tĂ« thellĂ« tĂ« personalizuar nĂ« PHP dhe JavaScript (e kuptoj, ndjen njĂ« disonancĂ« kognitive, por funksionon, pĂ«r vite me radhĂ« dhe pa gabime).
Formati i skedarĂ«ve tĂ« ruajtur nĂ« liqen â çelĂ«si pĂ«r performancĂ«
ĂĂ«shtje shumĂ«, shumĂ« e rĂ«ndĂ«sishme tĂ« kuptohet edhe dy pika kyçe. PĂ«r tĂ« siguruar qĂ« kĂ«rkesat pĂ«r tĂ« dhĂ«nat e skedarĂ«ve nĂ« liqen tĂ« realizohen sa mĂ« shpejt dhe qĂ« performanca tĂ« mos degradohet gjatĂ« shtimit tĂ« informacionit tĂ« ri, duhet:
- Kolonat e skedarëve të ruhen veçmas (nuk ka nevojë të lexosh të gjitha rreshtat për të kuptuar se çfarë ka në kolona). Për këtë morëm formatin parquet me kompresim.
- Shumë e rëndësishme është të ndahen skedarët në dosje në stilin: gjuhë, vit, muaj, ditë, javë. Motorët që e kuptojnë këtë lloj ndarjeje, do të shikojnë vetëm në dosjet e duhura, pa u marrë me të gjitha të dhënat një për një.
NĂ« thelb, nĂ« kĂ«tĂ« mĂ«nyrĂ«, ju ofroni tĂ« dhĂ«nat origjinale nĂ« mĂ«nyrĂ«n mĂ« efektive pĂ«r motorĂ«t analitikĂ« qĂ« janĂ« tĂ« aftĂ« tĂ« hyjnĂ« dhe tĂ« lexojnĂ« selektivisht vetĂ«m kolonat e nevojshme nga skedarĂ«t. Nuk ka nevojĂ« tĂ« "derdhni" tĂ« dhĂ«nat diku (ruajtja vetĂ«m do tĂ« bjerĂ«) â thjesht vendosni menjĂ«herĂ« nĂ« sistemin e skedarĂ«ve nĂ« formatin e duhur. Natyrisht, duhet tĂ« jetĂ« e qartĂ« se ruajtja e njĂ« skedari tĂ« madh csv nĂ« DataLake, tĂ« cilin duhet ta lexoni fillimisht rresht pĂ«r rresht nga klastri pĂ«r tĂ« nxjerrĂ« kolonat â nuk Ă«shtĂ« shumĂ« e arsyeshme. Rishikoni dy pikat e mĂ«sipĂ«rme nĂ«se ende nuk kuptoni pse Ă«shtĂ« e gjithĂ« kjo.
AWS Athena â "djalli" nĂ« kutinĂ« e duhanit
Dhe këtu, duke krijuar liqenin, ne, si të thuash, gjetëm Amazon Athena. Papritmas u zbulua se duke e organizuar me kujdes skedarët tanë të logëve të mëdha në formatin e duhur (parquet) sipas ndarjeve - mund të bëjmë seleksione shumë informative dhe të ndërtojmë raporte SHPEJT, pa pasur nevojë për klastra Apache Spark/Glue.
Motori Athena, qĂ« punon nĂ« tĂ« dhĂ«nat nĂ« s3, bazohet nĂ« legjendarin - pĂ«rfaqĂ«suesi i familjes MPP (procesim masiv paralel) tĂ« qasjeve pĂ«r pĂ«rpunimin e tĂ« dhĂ«nave, merr tĂ« dhĂ«nat aty ku janĂ«, nga s3 dhe Hadoop deri te Cassandra dhe skedarĂ« tekstualĂ« tĂ« thjeshtĂ«. Thjesht kĂ«rkoni qĂ« Athena tĂ« ekzekutojĂ« njĂ« SQL-query, dhe mĂ« pas gjithçka "punon shpejt dhe vetĂ«". ĂshtĂ« e rĂ«ndĂ«sishme tĂ« theksohet se Athena Ă«shtĂ« "e zgjuar", hyn vetĂ«m nĂ« dosjet e ndara tĂ« nevojshme dhe lexon vetĂ«m kolonat e nevojshme nĂ« query.
Kërkesat ndaj Athena po ashtu janë interesante. Ne paguajmë për . Pra, jo për numrin e makinave në klaster për minutë, por⊠për të dhënat që janë skanuar në 100-500 makina, të cilat janë vërtet të nevojshme për plotësimin e kërkesës.
Dhe duke kërkuar vetëm kolonat e nevojshme nga dosjet e sharduara siç duhet, u tregua se shërbimi Athena na kostonte disa dhjetra dollarë në muaj. E shkëlqyer, thuajse falas, krahasuar me analytikën në klastere!
Ja, si i shardojmë të dhënat tona në S3:
Si rezultat, për një kohë të shkurtër, në kompani, një gamë e gjerë ndarjesh, nga siguria informacionit deri te analiza, filluan të bëjnë kërkesa ndaj Athena dhe të marrin përgjigje të dobishme nga "të dhënat e mëdha" shpejt, brenda sekondave për periudha relativisht të gjata: muaj, gjysmëviti etj.
Por ne shkuam përtej dhe filluam të kërkojmë përgjigje në re : analisti në konsolën e njohur shkruan një kërkesë SQL, e cila në 100-500 makina "për pak" kërkon të dhënat në S3 dhe kthen përgjigjen zakonisht brenda disa sekondash. E rehatshme. Dhe shpejt. Akoma nuk e besojmë.
NĂ« fund, duke vendosur tĂ« ruajmĂ« tĂ« dhĂ«nat nĂ« S3, nĂ« njĂ« format kolonor efektiv dhe me shardim tĂ« arsyeshĂ«m tĂ« tĂ« dhĂ«nave nĂ« dosje⊠ne ndĂ«rtuam DataLake dhe njĂ« motor analitik tĂ« shpejtĂ« dhe tĂ« lirĂ« â falas. Dhe ai bĂ«ri shumĂ« popullor nĂ« kompani, pasi kupton SQL dhe punon shumĂ« mĂ« shpejt se pĂ«rmes nisjes/ststopjeve/konfigurimeve tĂ« klastereve. "NĂ«se rezultati Ă«shtĂ« i njĂ«jtĂ«, pse tĂ« paguash mĂ« shumĂ«?"
Një kërkesë ndaj Athena duket përafërsisht kështu. Nëse dëshiron, natyrisht, mund të formosh një kërkesë SQL mjaft , por ne do të kufizohemi në një grup të thjeshtë. Të shohim se cilat kode përgjigjesh kishte klienti disa javë më parë në log-ët e punës së serverit web dhe të sigurohemi që nuk ka gabime:
PĂ«rfundimet
Pas një rrugëtimi që nuk ishte i gjatë, por i dhimbshëm, duke vlerësuar vazhdimisht rrezikun, nivelin e kompleksitetit dhe koston e mbështetjes, ne gjendem zgjidhjen për DataLake dhe analitikën që na gëzon vazhdimisht me shpejtësinë dhe kostot e pronësisë.
Doli se ishte plotĂ«sisht e mundur tĂ« ndĂ«rtohet njĂ« DataLake efektiv, tĂ« shpejtĂ« dhe tĂ« lirĂ« pĂ«r nevojat e ndarjeve tĂ« ndryshme tĂ« kompanisĂ« â madje edhe pĂ«r zhvilluesit qĂ« nuk kanĂ« punuar kurrĂ« si arkitektĂ« dhe nuk dinĂ« tĂ« vizatojnĂ« katrorĂ« mbi katrorĂ« me thĂ«rrime dhe qĂ« dinĂ« 50 terma nga ekosistemi Hadoop.
NĂ« fillim tĂ« rrugĂ«s, koka na lĂ«vizte nga numri i madh i softuerĂ«ve tĂ« hapur dhe tĂ« mbyllur dhe duke kuptuar peshĂ«n e pĂ«rgjegjĂ«sisĂ« ndaj brezave tĂ« ardhshĂ«m. Thjesht filloni tĂ« ndĂ«rtoni DataLake tuaj nga veglat e thjeshta: nagios/munin -> elastic/kibana -> Hadoop/Spark/S3 âŠ, duke mbledhur reagimet dhe duke kuptuar thellĂ« fizikĂ«n e proceseve qĂ« ndodhin. Gjithçka qĂ« Ă«shtĂ« e ndĂ«rlikuar dhe e turbullt â lĂ«reni armikĂ«ve dhe konkurentĂ«ve.
NĂ«se nuk doni nĂ« re dhe e doni tĂ« mbani, pĂ«rditĂ«soni dhe aplikoni patch-e nĂ« projekte tĂ« hapura, mund tĂ« ndĂ«rtoni njĂ« skemĂ« tĂ« ngjashme me tonĂ«n lokal, nĂ« makina tĂ« lira zyrtare me Hadoop dhe Presto sipĂ«r. E rĂ«ndĂ«sishmja â mos ndaloni dhe ecni pĂ«rpara, llogaritni, kĂ«rkoni zgjidhje tĂ« thjeshta dhe çdo gjĂ« do tĂ« funksionojĂ«! Fat tĂ« mirĂ« tĂ« gjithĂ«ve dhe deri nĂ« takime tĂ« reja!
Burimi: habr.com
