Ne jetojmĂ« nĂ« njĂ« kohĂ« tĂ« jashtĂ«zakonshme, kur mund tĂ« lidhen shpejt dhe lehtĂ«sisht disa mjete tĂ« gatshme tĂ« hapura, t'i konfigurojmĂ« ato me "dijeni tĂ« çaktivizuar" sipas kĂ«shillave nga stackoverflow, pa u shqetĂ«suar pĂ«r "shumĂ« shkronja", dhe ta nisni atĂ« nĂ« pĂ«rdorim tregtar. Por kur do tĂ« vijĂ« koha tĂ« pĂ«rditĂ«sohet/zgjerohet ose ndokush rastĂ«sisht tĂ« rindezĂ« disa makina â do tĂ« kuptoni se ka filluar njĂ« makth i ngjashĂ«m me njĂ« Ă«ndĂ«rr, gjithçka Ă«shtĂ« pĂ«rtej njohjes, rrugĂ« e kthimit s'ka, e ardhmja Ă«shtĂ« e paqartĂ« dhe mĂ« e sigurt, pĂ«rveç programimit, tĂ« rritni bletĂ« dhe tĂ« bĂ«ni djathĂ«.
Nuk Ă«shtĂ« rastĂ«si qĂ« kolegĂ«t mĂ« tĂ« pĂ«rvojshĂ«m, me koke tĂ« bardhĂ« nga gabimet e shumta, duke vĂ«zhguar shpĂ«rthimin e pabesueshĂ«m tĂ« grupeve tĂ« "kontejnerĂ«ve" nĂ« "kubikĂ«" nĂ« dhjetra servera nĂ« "gjuhĂ« tĂ« modĂ«s" me mbĂ«shtetje tĂ« integruar pĂ«r hyrje/ dalje asinkrone dhe jo-bllokuese â buzĂ«qeshin modestisht. Dhe nĂ« heshtje vazhdojnĂ« tĂ« rishikojnĂ« "man ps", pĂ«rpiqen deri nĂ« gjakderdhje nga sytĂ« nĂ« kodin burimor tĂ« "nginx" dhe shkruajnĂ«-shkruajnĂ«-shkruajnĂ« teste njĂ«sie. KolegĂ«t e dinĂ« se gjĂ«ja mĂ« interesante do tĂ« ndodhĂ« mĂ« vonĂ«, kur "tĂ« gjitha kĂ«to" njĂ« natĂ« do tĂ« kthehen nĂ« njĂ« telash pĂ«r natĂ«n e Vitit tĂ« Ri. Dhe do t'i ndihmojĂ« vetĂ«m njohja e thellĂ« e natyrĂ«s sĂ« unix-it, tabela e mĂ«suar e gjendjeve TCP/IP dhe algoritmet themelore tĂ« renditjes-kĂ«rkimit.
Ah po, ndoshta u nisa pak larg, por shpresoj se kam arritur të transmetoj ndjenjën e pritjes.
Sot dua të ndaj përvojën tonë në zhvillimin e një staku të lehtë dhe të përballueshëm për DataLake, që zgjidh shumicën e problemeve analitike në kompani për strukturat e ndryshme organizative.
Disa kohĂ« mĂ« parĂ« arritĂ«m tĂ« kuptojmĂ« se kompanitĂ« kanĂ« nevojĂ« gjithnjĂ« e mĂ« shumĂ« pĂ«r frytet e analitikĂ«s produktive dhe teknike (pa e pĂ«rmendur kĂ«rcellin mbi tortĂ« nĂ« formĂ«n e machine learning) dhe pĂ«r tĂ« kuptuar trendet dhe rreziqet â nevojitet tĂ« grumbullojmĂ« dhe analizojmĂ« gjithnjĂ« e mĂ« shumĂ« metrika.
Analitika themelore teknike në "Bitrix24"
Disa vjet mĂ« parĂ«, nĂ« tĂ« njĂ«jtĂ«n kohĂ« me nisjen e shĂ«rbimit 'Bitrix24', ne investedh kontribuoi pak kohĂ« dhe burime nĂ« krijimin e njĂ« platforme analitike tĂ« thjeshtĂ« dhe tĂ« besueshme, e cila do tĂ« ndihmonte nĂ« mĂ«nyrĂ« tĂ« shpejtĂ« qĂ« tĂ« shiheshin problemet nĂ« infrastrukturĂ« dhe tĂ« planifikoheshin hapat e ardhshĂ«m. Natyrisht, mjetet preferoheshin t'i merrnim 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 verifikime nĂ« nagios, qindra grafikĂ« nĂ« munin dhe kolegĂ«t tanĂ« i pĂ«rdorin ato çdo ditĂ« me sukses. Metodikat janĂ« tĂ« qarta, grafikĂ«t janĂ« tĂ« kuptueshĂ«m, sistemi punon besueshĂ«m pĂ«r disa vjet tani dhe rregullisht shtohen teste dhe grafikĂ« tĂ« rinj: fillojmĂ« njĂ« shĂ«rbim tĂ« ri â shtojmĂ« disa teste dhe grafikĂ«. NĂ« njĂ« rrugĂ« tĂ« mbarĂ«.
Dora mbi puls â analitika teknike e avancuar
DĂ«shira pĂ«r tĂ« marrĂ« informacion mbi problemet 'sa mĂ« shpejt qĂ« tĂ« jetĂ« e mundur' na çoi nĂ« eksperimentime aktive me mjete tĂ« thjeshta dhe tĂ« kuptueshme â pinba dhe xhprof.
Pinba na dĂ«rgonte statistikĂ«n nĂ« UDP-paketat pĂ«r shpejtĂ«sinĂ« e funksionimit tĂ« pjesĂ«ve tĂ« faqeve tĂ« web-it nĂ« PHP dhe ishte e mundur tĂ« shihnim nĂ« kohĂ« reale nĂ« depozita MySQL (pinba vjen me motorin e saj MySQL pĂ«r analitikĂ« tĂ« shpejtĂ« tĂ« ngjarjeve) njĂ« listĂ« tĂ« shkurtĂ«r tĂ« problemeve dhe tĂ« reagonim ndaj tyre. Xhprof nĂ« mĂ«nyrĂ« automatike lejonte grumbullimin e grafikĂ«ve tĂ« ekzekutimit tĂ« faqeve mĂ« tĂ« ngadalta PHP tĂ« klientĂ«ve dhe tĂ« analizohej se çfarĂ« mund tĂ« kishte çuar nĂ« kĂ«tĂ« â qetĂ«sisht, duke pirĂ« çaj ose diçka mĂ« tĂ« fortĂ«.
Disa kohĂ« mĂ« parĂ«, mjetet e punĂ«s u plotĂ«suan me njĂ« tjetĂ«r motor tĂ« thjeshtĂ« dhe tĂ« kuptueshĂ«m nĂ« bazĂ« tĂ« algoritmit tĂ« indeksimit invers, i realizuar mjaft mirĂ« nĂ« bibliotekĂ«n legjendare Lucene â Elastic/Kibana. Ideja e thjeshtĂ« e regjistrimit shumĂ«-faqesh tĂ« dokumenteve nĂ« indeksin e kthyer Lucene nĂ« bazĂ« tĂ« ngjarjeve nĂ« log dhe kĂ«rkimit tĂ« shpejtĂ« pĂ«r to duke pĂ«rdorur ndarjen e fasetave â vĂ«rtet ishte e dobishme.
Pavarësisht pamjes mjaft teknike të vizualizimeve në Kibana me konceptet e nivelit të ulët 'bucket' dhe një gjuhë të rinovuar të algjebrës relacione, instrumenti na ndihmoi mirë në detyrat e mëposhtme:
- Sa gabime PHP kishte klienti Bitrix24 në portalin p1 gjatë orës së fundit dhe çfarë? Kuptoni, falni dhe rregulloni shpejt.
- Sa u bënë thirrje video në platforma në Gjermani gjatë 24 orëve të fundit, me cila cilësi dhe a kishte vështirësi me kanalin/rete?n?
- Sa mirë funksionon funksionaliteti sistematik (shtesa jonë në C për PHP), e ndërtuar nga burimi në përditësimin më të fundit të shërbimit dhe shpërndarë për klientët? A ka segfaults?
- A ruhen të dhënat e klientëve në memorien PHP? A ka gabime që tejkalojnë memorjen e ndarë për proceset: "jashtë memorie"? Gjejini dhe ndaloni.
Ja një shembull konkret. Pavarësisht testimeve të kujdesshme dhe shumë-niveli, një klient përballi një gabim të padëshiruar dhe të papritur në një rast shumë të pazakontë dhe me të dhëna hyrëse të dëmtuara, filloi alarmi dhe procesi për ta rregulluar shpejt atë:
PĂ«r mĂ« tepĂ«r, Kibana mundĂ«son organizimin e njoftimeve pĂ«r ngjarje tĂ« caktuara dhe brenda njĂ« kohe tĂ« shkurtĂ«r, shumica e punonjĂ«sve nga departamente tĂ« ndryshme â nga mbĂ«shtetje teknike dhe zhvillimi deri nĂ« QA â filluan tĂ« pĂ«rdorin kĂ«tĂ« mjet.
Aktiviteti i çdo dege brenda kompanisĂ« u bĂ« lehtĂ« i ndjekshĂ«m dhe i matshĂ«m â nĂ« vend tĂ« analizĂ«s manuale tĂ« log-eve nĂ« serverĂ«, mjafton qĂ« njĂ«herĂ« tĂ« konfiguroni parsing-un e log-eve dhe dĂ«rgimin e tyre nĂ« klasterin elastic, pĂ«r tĂ« shijuar, pĂ«r shembull, numrin e katĂ«rmijĂ«sht tĂ« koteleve dy-koka, tĂ« printuara nĂ« 3-d printer pĂ«r muajin e kaluar hĂ«nor.
Analitika e biznesit bazë
TĂ« gjithĂ« dinĂ« se shpesh analitika e biznesit nĂ« kompani fillon me pĂ«rdorimin ekstrem tĂ« Excel-it. Por, mĂ« e rĂ«ndĂ«sishmja, Ă«shtĂ« qĂ« tĂ« mos pĂ«rfundojĂ« aty. Pushtimi i Google Analytics nĂ« re gjithashtu kontribuon nĂ« kĂ«tĂ« â nisin tĂ« bĂ«hesh tĂ« shkĂ«lqyer me tĂ«.
NĂ« kompaninĂ« tonĂ«, e cila po zhvillohet nĂ« mĂ«nyrĂ« harmonike, filluan tĂ« shfaqen herĂ« pas here "profetĂ«" tĂ« punĂ«s mĂ« intensive me tĂ« dhĂ«na mĂ« tĂ« mĂ«dha. KĂ«rkesat pĂ«r raporte mĂ« thellĂ«sisht dhe shumĂ«dimensionale u shfaqĂ«n 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 fleksibile ndihmoi shumĂ« gjatĂ« njĂ« periudhe tĂ« gjatĂ«, por gradualisht filloi tĂ« kuptohej se ClickHouse â nuk Ă«shtĂ« elastik dhe nuk mund tĂ« keqinterpretohet.
ĂshtĂ« e rĂ«ndĂ«sishme tĂ« kuptoni mirĂ« se ClickHouse, si Druid, si Vertica, si Amazon RedShift (i cili bazohet nĂ« Postgres), janĂ« motorĂ« analitikĂ«, tĂ« optimizuar pĂ«r njĂ« analizĂ« mjaft tĂ« thjeshtĂ« (shuma, agregime, minimum-maksimum pĂ«r kolonĂ« dhe ndonjĂ«herĂ« mund tĂ« bĂ«hen bashkime), pasi janĂ« organizuar pĂ«r ruajtjen efikase tĂ« kolonave tĂ« tabelave relacionale, nĂ« ndryshim nga MySQL dhe databazat e tjera (me orientim rresht).
NĂ« thelb, ClickHouse Ă«shtĂ« thjesht njĂ« «baza» tĂ« dhĂ«nash mĂ« e madhe, me njĂ« inserim tĂ« pikĂ«zuar jo shumĂ« tĂ« pĂ«rshtatshĂ«m (Ă«shtĂ« menduar kĂ«shtu, gjithçka Ă«shtĂ« nĂ« rregull), por me njĂ« analizĂ« tĂ« kĂ«ndshme dhe njĂ« grup interesant tĂ« funksioneve tĂ« fuqishme pĂ«r punĂ«n me tĂ« dhĂ«nat. Po ashtu, mund tĂ« krijoni njĂ« klaster â por, e kuptoni, tĂ« godasĂ«sh me hammer njĂ« gozhdĂ« me mikroskop nuk Ă«shtĂ« krejtĂ«sisht e duhur dhe ne filluam tĂ« kĂ«rkojmĂ« zgjidhje tĂ« tjera.
Kërkesa për Python dhe analitikët
Në kompaninë tonë ka shumë zhvillues, të cilët shkruajnë kod pothuajse çdo ditë për 10-20 vjet në PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash. Po ashtu, ka shumë administatorë të sistemeve me eksperiencë, që kanë përjetuar jo një, por disa katastrofa të pabesueshme, që nuk përfshihen në ligjet e statistikës (për shembull, kur shkatërrohen shumica e disqeve në RAID-10 nga një goditje e fortë vetëtimash). Në këto kushte, për një kohë të gjatë ka qenë e paqartë se çfarë është një «analist në Python». Python është si PHP, vetëm emri është pak më i gjatë dhe ndotësit e substancave që ndryshojnë mendjen në kodin burimor të interpretorit janë pak më të pakët. Megjithatë, me krijimin e raporteve gjithnjë e më analitike, zhvilluesit e eksperiencës kanë filluar të kuptojnë rëndësinë e specializimit të ngushtë në mjetet si numpy, pandas, matplotlib, seaborn.
Roli vendimtar, me siguri, ka qenë një ndihmë e papritur nga fjetja e punonjësve nga kombinimi i fjalëve «regresioni logjistik» dhe demonstrimi i ndërtimit të raporteve efikase mbi të dhëna voluminoze me anë të pyspark.
Apache Spark, paradigmat e tij funksionale, mbi të cilat bazohet shumë mirë algebra relacional, pati një impakt të tillë te zhvilluesit që ishin mësuar me MySQL, saqë nevoja për të forcuar radhët me analistë të njohur u bë e qartë si dita.
Tentativat e mëtejshme të Apache Spark/Hadoop për të fluturuar dhe se çfarë nuk shkoi krejtësisht sipas skenarit
MegjithatĂ«, sĂ« shpejti u bĂ« e qartĂ« se me Spark, duket se diçka nuk ishte sistematikisht nĂ« rregull ose thjesht duhen larĂ« mĂ« mirĂ« duar. NĂ«se stoku Hadoop/MapReduce/Lucene ishte zhvilluar nga programues tĂ« mjaftueshĂ«m tĂ« pĂ«rvojshĂ«m, çka Ă«shtĂ« evidente nĂ«se shikon me vĂ«mendje kodin burimor nĂ« Java ose idetĂ« e Doug Cutting nĂ« Lucene, atĂ«herĂ« Spark, papritur, Ă«shtĂ« shkruar nĂ« njĂ« gjuhĂ« tĂ« diskutueshme nga pikĂ«pamja e praktikĂ«s dhe tani nuk po zhvillohet, gjuha ekzotike Scala. PĂ«rdorimi i rregullt tĂ« llogaritjeve nĂ« pĂ«rbĂ«rjen Spark pĂ«r shkak tĂ« punĂ«sjo tĂ« paqartĂ« dhe jo shumĂ« transparente me ndarjen e memories pĂ«r operacionet e reduktimit (vijnĂ« shumĂ« çelĂ«sa menjĂ«herĂ«) â krijoi rreth tij njĂ« aurĂ« tĂ« diçkaje qĂ« ka hapĂ«sirĂ« pĂ«r tĂ« u rritur. ShtesĂ«, situata u pĂ«rkeqĂ«sua nga numri i madh i porteve tĂ« çuditshme tĂ« hapura, skedarĂ«ve temporarĂ« qĂ« rriteshin nĂ« vende tĂ« paqartĂ« dhe varĂ«sive jar â qĂ« shkaktonte ndjenja tĂ« njohura tek administruesit e sistemit: njĂ« urrejtje e fortĂ« (ndoshta do tĂ« duhej tĂ« lahnin duar me sapun).
Ne, pĂ«r pasojĂ«, kemi "kanosur" disa projekte analitike tĂ« brendshme qĂ« pĂ«rdorin aktivisht Apache Spark (pĂ«rfshirĂ« Spark Streaming, Spark SQL) dhe ekosistemin Hadoop (dhe tĂ« tjera). MegjithĂ«se me kalimin e kohĂ«s mĂ«suam ta pĂ«rgatisim dhe monitorojmĂ« mjaft mirĂ« dhe "ato" praktikisht ndaluan tĂ« bien papritur pĂ«r shkak tĂ« ndryshimit tĂ« natyrĂ«s sĂ« tĂ« dhĂ«nave dhe disbalancĂ«s sĂ« heshimit tĂ« barabartĂ« RDD, dĂ«shira pĂ«r tĂ« marrĂ« diçka tĂ« gatshme, tĂ« pĂ«rditĂ«suar dhe tĂ« administruar paktĂ« diku nĂ« cloud u intensifikua gjithnjĂ« e mĂ« shumĂ«. PikĂ«risht nĂ« kĂ«tĂ« kohĂ«, provuam tĂ« pĂ«rdornim njĂ« ndĂ«rtim cloud tĂ« gatshĂ«m nga Amazon Web Services â dhe, mĂ« vonĂ«, pĂ«rpiqeshim tĂ« zgjidhim detyrat nĂ« tĂ«. EMR Ă«shtĂ« njĂ« Apache Spark i pĂ«rgatitur nga Amazon me softuer shtesĂ« nga ekosistemi, diçka si ndĂ«rtimet Cloudera/Hortonworks.
"Ruajtja e skedarĂ«ve" pĂ«r analitikĂ« â njĂ« nevojĂ« e ngutshme
Eksperienca e "gatimit" të Hadoop/Spark me djegie të ndryshme trupore nuk kaloi kot. Nevoja për të krijuar një depo të vetme të lirë dhe të besueshme u bë gjithnjë e më e qartë, e cila do të ishte e qëndrueshme ndaj depozitave të pajisjeve dhe ku mund të ruajmë skedarë në formate të ndryshme nga sisteme të ndryshme dhe të bëjmë për këto të dhëna zgjedhje efektive dhe që realizohen në kohë të arsyeshme për raporte.
Gjithashtu, doja që azhurnimi i softuerit të kësaj platforme të mos kthehej në një makth të natës së Vitit të Ri me leximin e shënimeve 20-faqëshe të Java dhe analizimin e kilometrave të detajeve të logëve të punës së klasterit me ndihmën e Spark History Server dhe një lupë me ndriçim. Doja të kishim një mjet të thjeshtë dhe transparent, që nuk kërkon një zhytje të rregullt nën kapak, nëse kërkuesi ndalon së ekzekutuari një kërkesë standarde MapReduce kur ndodhin humbjet e memories së punonjësit të të dhënave të reduktimit për shkak të një algoritmi jo shumë të përshtatshëm të ndarjes së të dhënave origjinale.
Amazon S3 â njĂ« kandidat pĂ«r DataLake?
Eksperienca me Hadoop/MapReduce më mësoi se nevojitet një sistem i qëndrueshëm skedarësh që është gjithashtu i shkallëzueshëm dhe sipër tij punëtorë të shkallëzueshëm, "duke ardhur" afër të dhënave, në mënyrë që të mos lëvizin të dhënat përmes rrjetit. Punonjësit duhet të jenë në gjendje të lexojnë të dhënat në formate të ndryshme, por, sa më mirë, të mos lexojnë informacione të panevojshme, dhe që të mund të ruajnë të dhënat paraprakisht në formate të përshtatshme për punonjësit.
NjĂ«herĂ« tjetĂ«r â ideja kryesore. Nuk kam dĂ«shirĂ« tĂ« "ngarkoj" tĂ« dhĂ«na tĂ« mĂ«dha nĂ« njĂ« motor analitik klasterik tĂ« vetĂ«m, i cili do tĂ« dĂ«shpĂ«rohet dhe do tĂ« duhet ta ndajmĂ« nĂ« mĂ«nyrĂ« tĂ« pakĂ«ndshme. Dua tĂ« ruaj skedarĂ«, thjesht skedarĂ«, nĂ« njĂ« format tĂ« kuptueshĂ«m dhe tĂ« ekzekutimin e kĂ«rkesave efektive analitike nĂ« mĂ«nyrĂ« tĂ« ndryshme, por edhe tĂ« kuptueshme. Dhe numri i skedarĂ«ve nĂ« formate tĂ« ndryshme do tĂ« jetĂ« gjithnjĂ« e mĂ« i madh. Dhe do tĂ« ishte mĂ« mirĂ« tĂ« ndahej jo motori, por tĂ« dhĂ«nat origjinale. Na nevojitet njĂ« DataLake i zgjerueshĂ«m dhe universale, vendosĂ«m ne...
ĂfarĂ« nĂ«se ruajmĂ« skedarĂ«t nĂ« njĂ« depo tĂ« njohur dhe tĂ« shkallĂ«zuar tĂ« njohur tĂ« Amazon S3, pa u marrĂ« me pĂ«rgatitjen e vet tĂ« pllakave nga Hadoop?
E qartĂ«, tĂ« dhĂ«nat personale ânuk lejohetâ, por tĂ« dhĂ«nat e tjera nĂ«se i nxjerrim atje dhe i âpĂ«rpunojmĂ« me efektivitetâ?
Ekosistemi analitik tĂ« dhĂ«nave tĂ« mĂ«dha tĂ« Amazon Web Services â me fjalĂ« shumĂ« tĂ« thjeshta
Duke u bazuar në përvojën tonë me AWS, aty përdoret prej kohësh dhe me intensitet Apache Hadoop/MapReduce nën forma të ndryshme, për shembull në shërbimin DataPipeline (i ziliqem kolegëve, ata e dinë ta përgatisin siç duhet). Këtu kemi vendosur backup nga shërbime të ndryshme nga tabelat DynamoDB:
Dhe ato janë duke u ekzekutuar rregullisht në klasteret e integruara Hadoop/MapReduce si orët për disa vite. "Përgatite dhe harroje":
Po ashtu, mund të angazhoheni në datasciencë në mënyrë efektive duke ngritur notebook-ët Jupiter për analistët në cloud dhe duke përdorur shërbimin AWS SageMaker për trajnim dhe vendosjen e modeleve AI në përdorim. Ja si duket kjo në ne:
Dhe, po, mund të ngresh për vete ose për analistët një notebook në cloud dhe ta lidhësh atë me klasterin Hadoop/Spark, të bësh llogaritje dhe pastaj 'të përfundosh' gjithçka:
Vërtetë e përshtatshme për projekte analitike të veçanta dhe për disa prej tyre kemi përdorur me sukses shërbimin EMR për kalkulime dhe analitika të mëdha. Por çfarë do të thotë për një zgjidhje sistematike për DataLake, do të funksionojë? Në atë moment ishim në prag të shpresës dhe dëshpërimit dhe vazhduam kërkimin.
AWS Glue â njĂ« Apache Spark i paketuar me kujdes 'nĂ« steroide'
Doli se AWS ka një version të tijin të stack-ut 'Hive/Pig/Spark'. Rolii i Hive, dmth, katalogu i skedarëve dhe tipeve të tyre në DataLake, ekzekutohet nga shërbimi 'Data catalog', i cili nuk e fsheh kompatibilitetin e tij me formatin Apache Hive. Në këtë shërbim duhen shtuar informacione se ku ndodhen skedarët tuaj dhe në çfarë formati 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 flasim në këtë postim. Ja si është organizuar katalogu i dhënave DataLake për ne:
SkedarĂ«t janĂ« regjistruar, shkĂ«lqyeshĂ«m. NĂ«se skedarĂ«t janĂ« pĂ«rditĂ«suar â aktivizojmĂ« manualisht ose sipas njĂ« skeduli crawlers, tĂ« cilĂ«t do tĂ« pĂ«rditĂ«sojnĂ« informacionin mbi ta nga liqeni dhe do ta ruajnĂ«. MĂ« pas, tĂ« dhĂ«nat nga liqeni mund tĂ« pĂ«rpunohen dhe rezultatet diku tĂ« skadohen. NĂ« rastin mĂ« tĂ« thjeshtĂ« â skadojmĂ« gjithashtu nĂ« s3. PĂ«rpunimi i tĂ« dhĂ«nave mund tĂ« bĂ«het kudo, por ofrohet qĂ« tĂ« konfigurohet procesi i pĂ«rpunimit nĂ« klasterin Apache Spark duke pĂ«rdorur funksionalitetet e avancuara pĂ«rmes API AWS Glue. NĂ« thelb, mund tĂ« marrim kodin e vjetĂ«r tĂ« njohur nĂ« python duke pĂ«rdorur bibliotekĂ«n pyspark dhe tĂ« konfigurojmĂ« ekzekutimin e tij nĂ« N nodet e klasterit tĂ« ndonjĂ« fuqie me monitorim, pa gĂ«rmim nĂ« thellĂ«sitĂ« e Hadoop dhe transportim tĂ« kontejnerĂ«ve docker-mokers dhe eliminimi i konflikteve tĂ« varĂ«sisĂ«.
Edhe njĂ« herĂ« â njĂ« ide e thjeshtĂ«. Nuk Ă«shtĂ« e nevojshme tĂ« konfigurohet Apache Spark, duhet vetĂ«m tĂ« shkruhet kodi nĂ« python pĂ«r pyspark, ta testosh lokal nĂ« desktop dhe pastaj ta aktivizosh nĂ« njĂ« klaster tĂ« madh nĂ« cloud, duke treguar ku ndodhen tĂ« dhĂ«nat burimore dhe ku duhet tĂ« vendoset rezultati. NdonjĂ«herĂ« kjo Ă«shtĂ« e nevojshme dhe e dobishme dhe ja si Ă«shtĂ« konfiguruar pĂ«r ne:
KĂ«shtu, nĂ«se kemi nevojĂ« tĂ« bĂ«jmĂ« njĂ« kalkulim nĂ« klasterin Spark mbi tĂ« dhĂ«nat nĂ« s3 â shkruajmĂ« kodin nĂ« python/pyspark, e testojmĂ« dhe shkojmĂ« nĂ« rrugĂ«n e mirĂ« nĂ« cloud.
ĂfarĂ« ndodhi me orkestrimin? ĂfarĂ« bĂ«het nĂ«se njĂ« detyrĂ« dĂ«shton dhe humb? Po, propozohet tĂ« krijohet njĂ« pipeline tĂ« bukur nĂ« stilin e Apache Pig dhe madje edhe ne e provuam atĂ«, por vendosĂ«m tĂ« pĂ«rdorim orkestrimin tonĂ« tĂ« thellĂ« tĂ« personalizuar nĂ« PHP dhe JavaScript (e kuptoj, ka 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Ă«n
ĂshtĂ« shumĂ«, shumĂ« e rĂ«ndĂ«sishme tĂ« kuptojmĂ« edhe dy momente kyçe. PĂ«r t'u siguruar qĂ« kĂ«rkesat pĂ«r tĂ« dhĂ«nat e skedarĂ«ve nĂ« liqen tĂ« zbatohen sa mĂ« shpejt tĂ« jetĂ« e mundur dhe performanca tĂ« mos degradohet gjatĂ« shtimit tĂ« informacionit tĂ« ri, nevojitet:
- Të ruajmë kolonat e skedarëve veçmas (për të mos qenë e nevojshme të lexojmë të gjitha rreshtat për të kuptuar se çfarë ka në kolona). Për këtë, ne morëm formatin parquet me kompresim
- ĂshtĂ« shumĂ« e rĂ«ndĂ«sishme tĂ« shardojmĂ« skedarĂ«t nĂ« dosje si: gjuha, viti, muaji, dita, java. MotorĂ«t qĂ« kuptojnĂ« kĂ«tĂ« lloj shardimi do tĂ« shikojnĂ« vetĂ«m nĂ« dosjet e nevojshme, pa e pĂ«rzgjedhur tĂ« gjithĂ« informacionin njĂ«lloj.
Shkurtimisht, nĂ« kĂ«tĂ« mĂ«nyrĂ«, ju nxirrni tĂ« dhĂ«nat origjinale nĂ« formĂ«n mĂ« efikase pĂ«r motorĂ«t analitikĂ« qĂ« e dinĂ« si tĂ« hyjnĂ« selektivisht nĂ« dosjet e sharduara dhe tĂ« lexojnĂ« vetĂ«m kolonat e nevojshme nga skedarĂ«t. Nuk Ă«shtĂ« nevoja tĂ« "derdhni" tĂ« dhĂ«nat diku (magazina do tĂ« shpĂ«rthejĂ«) â thjesht vendosini menjĂ«herĂ« nĂ« sistemin e skedarĂ«ve nĂ« formatin e duhur. Natyrisht, kĂ«tu duhet tĂ« jetĂ« e qartĂ« se ruajtja e njĂ« CSV tĂ« madh nĂ« DataLake, i cili duhet tĂ« lexohet rresht pĂ«r rresht nga klasteri pĂ«r tĂ« nxjerrĂ« kolonat â nuk Ă«shtĂ« shumĂ« e arsyeshme. Mendoni pĂ«rsĂ«ri mbi dy pikat e mĂ«sipĂ«rme nĂ«se nuk e kuptoni ende pse Ă«shtĂ« e gjitha kjo.
AWS Athena â "djalli" nga kutia
Dhe kĂ«tu, duke krijuar liqenin, ne, nĂ« njĂ« mĂ«nyrĂ«, hasĂ«m nĂ« Amazon Athena. Papritur u zbulua se duke grumbulluar me kujdes nĂ« dosjet e sharduara nĂ« formatin e duhur (parquet) skedarĂ«t tanĂ« tĂ« mĂ«dhenj tĂ« logjeve â mund tĂ« bĂ«jmĂ« shumĂ« shpejt zgjedhje shumĂ« informuese dhe tĂ« ndĂ«rtojmĂ« raporte PA, pa klasterin Apache Spark/Glue.
Motori Athena, qĂ« punon me tĂ« dhĂ«nat nĂ« s3, bazohet nĂ« legjendĂ«n â njĂ« pĂ«rfaqĂ«sues i familjes MPP (procesimi masiv paralel) tĂ« qasjes pĂ«r pĂ«rpunimin e tĂ« dhĂ«nave, duke marrĂ« tĂ« dhĂ«nat aty ku ndodhen, nga s3 dhe Hadoop te Cassandra dhe skedarĂ«t e zakonshĂ«m tekstualĂ«. Thjesht duhet tĂ« kĂ«rkosh nga Athena tĂ« ekzekutojĂ« njĂ« kĂ«rkesĂ« SQL, dhe pastaj gjithçka "funksionon shpejt dhe vetĂ«". ĂshtĂ« e rĂ«ndĂ«sishme tĂ« theksohet se Athena Ă«shtĂ« "e mençur", shkon vetĂ«m nĂ« dosjet e nevojshme tĂ« ndara dhe lexon vetĂ«m kolonat e nevojshme nĂ« kĂ«rkesĂ«.
Tarifat për kërkesat në Athena janë gjithashtu interesante. Ne paguajmë për . Pra, jo për numrin e serverëve në klaster çdo minutë, por⊠për të dhënat që janë realisht skanuar në 100-500 serverë që janë vetëm të nevojshme për të përmbushur kërkesën.
Dhe duke kërkuar vetëm kolonat e nevojshme nga dosjet e duhura të ndara, rezultoi se shërbimi Athena na kushton vetëm disa dhjetëra dollarë në muaj. Well, përshtatshme, thuajse falas, krahasuar me analizën në klasterë!
Ja, si i ndajmë të dhënat tona në s3:
Si pasojë, brenda një kohe të shkurtër, në kompani janë bërë kërkesa aktive në Athena nga departamente të ndryshme, nga siguria informative te analiza, dhe ato marrin shpejt, brenda sekondash, përgjigje të dobishme nga "të dhënat e mëdha" për periudha mjaft të gjera: muaj, gjysmë viti etj.
Por ne shkuam më tej dhe filluam të kërkojmë përgjigje në cloud : analisti në konsolën e tij të zakonshme shkruan një kërkesë SQL, e cila "me pak para" kërkon të dhënat në s3 në 100-500 serverë dhe kthen përgjigjen zakonisht brenda disa sekondash. E ndihmon. Dhe është shpejt. Akoma nuk e besojmë.
NĂ« pĂ«rfundim, pas vendimit pĂ«r tĂ« ruajtur tĂ« dhĂ«nat nĂ« s3, nĂ« njĂ« format efikas kolĂłnar dhe me ndarje tĂ« arsyeshme tĂ« tĂ« dhĂ«nave nĂ« dosje⊠ne morĂ«m DataLake dhe njĂ« mekanizĂ«m analitik tĂ« shpejtĂ« dhe tĂ« lirĂ« â falas. Dhe ai u bĂ« shumĂ« popullor nĂ« kompani, pasi kupton SQL dhe punon shumĂ« mĂ« shpejt, sesa pĂ«rmes ndjekjeve/njohjeve/konfigurimeve tĂ« klasterĂ«ve. "E nĂ«se rezultati Ă«shtĂ« i njĂ«jtĂ«, pse tĂ« paguani mĂ« shumĂ«?"
Një kërkesë në Athena duket më pak kështu. Nëse dëshiron, sigurisht, mund të formosh një , por ne do të kufizohemi në një grupim të thjeshtë. Le të shohim se cilat kode përgjigjesh kishte klienti disa javë më parë në log-at e punës së serverit web dhe të sigurohemi që nuk ka gabime:
PĂ«rfundimet
Pas duke kaluar nëpër një rrugë që nuk ishte e gjatë, por e dhimbshme, duke vlerësuar vazhdimisht rrezikun dhe nivelin e vështirësisë dhe koston e mbështetjes, gjetëm zgjidhjen për DataLake dhe analizën që na gëzon vazhdimisht me shpejtësinë dhe kostot e zbatimit.
Doli se ndërtimi i një DataLake efektiv, të shpejtë dhe me kosto të ulët për nevojat e një numri të ndryshëm njësish brenda kompanisë - është plotësisht i realizueshëm edhe për zhvilluesit e përvojshëm, të cilët nuk kanë punuar kurrë si arkitektë dhe nuk dinë të vizatojnë katrorë mbi katrorë me shigjeta dhe të njohin 50 terma nga ekosistemi Hadoop.
NĂ« fillim tĂ« rrugĂ«s, koka mĂ« dhembte nga shumica e zvarranikĂ«ve tĂ« çmendur tĂ« software-it tĂ« hapur dhe tĂ« mbyllur dhe nga ndjenja e pĂ«rgjegjĂ«sisĂ« pĂ«r brezat e ardhshĂ«m. Thjesht filloni tĂ« ndĂ«rtoni DataLake-in tuaj me mjete tĂ« thjeshta: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3 âŠ, duke mbledhur feedback dhe duke e kuptuar thellĂ« fizikĂ«n e proceseve qĂ« ndodhin. Ădo gjĂ« qĂ« Ă«shtĂ« e komplikuar dhe e paqartĂ« - lini pĂ«r armiqtĂ« dhe konkurentĂ«t.
Nëse nuk dëshironi të shkoni në cloud dhe preferoni të mbështesni, përditësoni dhe aplikoni patches në projekte të hapura, mund të ndërtoni një skemë të ngjashme me tonën lokal, në makina të lira zyre me Hadoop dhe Presto përmbi. E rëndësishme është të mos ndaloni dhe të ecni përpara, të llogaritni, të kërkoni zgjidhje të thjeshta dhe të qarta dhe gjithçka do të dalë në vend! Fat të mirë të gjithëve dhe deri në takimin e ardhshëm!
Burimi: habr.com
