Ne jetojmë në një kohë të mahnitshme kur mund të lidhni shpejt dhe me lehtësi disa mjete të gatshme me burim të hapur, t'i vendosni ato me "vetëdijen tuaj të fikur" sipas këshillave të stackoverflow, pa u thelluar në "shkronjat e shumta" dhe t'i lansoni ato në funksionim tregtar. Dhe kur ju duhet të përditësoni/zgjeroni ose dikush rindiz aksidentalisht disa makina - kupton se një lloj ëndrre e keqe obsesive ka filluar, gjithçka është komplikuar në mënyrë dramatike përtej njohjes, nuk ka kthim prapa, e ardhmja është e paqartë dhe më e sigurt, në vend të programimit, rritni bletët dhe bëni djathë.
Jo më kot kolegët më me përvojë, me kokat e tyre të spërkatura me defekte dhe për këtë arsye tashmë gri, mendojnë vendosjen tepër të shpejtë të paketave të "kontejnerëve" në "kube" në dhjetëra serverë në "gjuhët e modës" me mbështetje të integruar për I/O jo-bllokuese asinkrone, buzëqeshni me modesti. Dhe ata në heshtje vazhdojnë të rilexojnë "man ps", gërmojnë në kodin burimor "nginx" derisa sytë e tyre të rrjedhin gjak dhe shkruajnë, shkruajnë, shkruajnë teste njësie. Kolegët e dinë se gjëja më interesante do të vijë kur "e gjithë kjo" një ditë të bëhet e rrezikuar natën në natën e Vitit të Ri. Dhe ata do të ndihmohen vetëm nga një kuptim i thellë i natyrës së unix-it, tabelës së memorizuar të gjendjes TCP/IP dhe algoritmeve bazë të klasifikimit-kërkimit. Për ta rikthyer sistemin në jetë ndërsa tingujt e tingujve godasin.
Oh po, u hutova pak, por shpresoj të kem arritur të përcjell gjendjen e pritjes.
Sot dua të ndaj përvojën tonë në vendosjen e një stack të përshtatshëm dhe të lirë për DataLake, i cili zgjidh shumicën e detyrave analitike në kompani për ndarje strukturore krejtësisht të ndryshme.
Disa kohë më parë, ne arritëm të kuptojmë se kompanitë gjithnjë e më shumë kanë nevojë për frytet e produktit dhe analitikës teknike (për të mos përmendur qershinë mbi tortë në formën e mësimit të makinerive) dhe për të kuptuar tendencat dhe rreziqet - ne duhet të mbledhim dhe analizojmë gjithnjë e më shumë metrikë.
Analiza teknike bazë në Bitrix24
Disa vite më parë, njëkohësisht me lançimin e shërbimit Bitrix24, ne investuam në mënyrë aktive kohë dhe burime në krijimin e një platforme analitike të thjeshtë dhe të besueshme që do të ndihmonte për të parë shpejt problemet në infrastrukturë dhe për të planifikuar hapin e ardhshëm. Sigurisht, këshillohej që të merrnin mjete të gatshme sa më të thjeshta dhe të kuptueshme. Si rezultat, nagios u zgjodh për monitorim dhe munin për analitikë dhe vizualizim. Tani kemi mijëra kontrolle në nagios, qindra tabela në munin dhe kolegët tanë i përdorin me sukses çdo ditë. Metrikat janë të qarta, grafikët janë të qartë, sistemi ka funksionuar në mënyrë të besueshme për disa vite dhe teste dhe grafikë të rinj shtohen rregullisht në të: kur vendosim një shërbim të ri në funksion, shtojmë disa teste dhe grafikë. Paç fat.
Finger on the Pulse - Analiza teknike e avancuar
Dëshira për të marrë informacion rreth problemeve "sa më shpejt të jetë e mundur" na çoi në eksperimente aktive me mjete të thjeshta dhe të kuptueshme - pinba dhe xhprof.
Pinba na dërgoi statistika në pako UDP në lidhje me shpejtësinë e funksionimit të pjesëve të faqeve të internetit në PHP, dhe ne mund të shihnim në internet në ruajtjen e MySQL (Pinba vjen me motorin e vet MySQL për analitikë të shpejtë të ngjarjeve) një listë të shkurtër problemesh dhe t'i përgjigjemi ato. Dhe xhprof na lejoi automatikisht të mbledhim grafikët e ekzekutimit të faqeve më të ngadalta PHP nga klientët dhe të analizojmë se çfarë mund të çojë në këtë - me qetësi, duke derdhur çaj ose diçka më të fortë.
Pak kohë më parë, paketa e veglave u plotësua me një motor tjetër mjaft të thjeshtë dhe të kuptueshëm bazuar në algoritmin e indeksimit të kundërt, i zbatuar në mënyrë të përsosur në bibliotekën legjendare Lucene - Elastic/Kibana. Ideja e thjeshtë e regjistrimit me shumë fije të dokumenteve në një indeks Lucene të kundërt bazuar në ngjarjet në regjistra dhe një kërkim i shpejtë përmes tyre duke përdorur ndarjen e aspekteve doli të ishte vërtet e dobishme.
Pavarësisht pamjes mjaft teknike të vizualizimeve në Kibana me koncepte të nivelit të ulët si "kovë" "duke rrjedhur lart" dhe gjuhën e rishpikur të algjebrës relacionale ende të pa harruar plotësisht, mjeti filloi të na ndihmojë mirë në detyrat e mëposhtme:
- Sa gabime PHP ka klienti Bitrix24 në portalin p1 në orën e fundit dhe cilat? Kuptoni, falni dhe korrigjoni shpejt.
- Sa video thirrje janë bërë në portale në Gjermani në 24 orët e mëparshme, me çfarë cilësie dhe a ka pasur vështirësi me kanalin/rrjetin?
- Sa mirë funksionon funksionaliteti i sistemit (zgjerimi ynë C për PHP), i përpiluar nga burimi në përditësimin më të fundit të shërbimit dhe i shpërndarë te klientët? A ka gabime?
- A përshtaten të dhënat e klientit në memorien PHP? A ka ndonjë gabim në lidhje me tejkalimin e memories së caktuar për proceset: "nga memoria"? Gjeni dhe neutralizoni.
Ja një shembull konkret. Megjithë testimin e plotë dhe me shumë nivele, klienti, me një rast shumë jo standard dhe të dhëna hyrëse të dëmtuara, mori një gabim të bezdisshëm dhe të papritur, u dëgjua një sirenë dhe filloi procesi i rregullimit të shpejtë:
Për më tepër, kibana ju lejon të organizoni njoftime për ngjarje të specifikuara, dhe në një kohë të shkurtër mjeti në kompani filloi të përdoret nga dhjetëra punonjës nga departamente të ndryshme - nga mbështetja teknike dhe zhvillimi te QA.
Aktiviteti i çdo departamenti brenda kompanisë është bërë i përshtatshëm për t'u gjurmuar dhe matur - në vend që të analizoni manualisht regjistrat në serverë, thjesht duhet të vendosni një herë regjistrat e analizimit dhe t'i dërgoni ato në grupin elastik për të shijuar, për shembull, duke menduar në kibana pulti numri i koteleve me dy koka të shitura të printuara në printer 3-D për muajin e fundit hënor.
Analiza bazë e biznesit
Të gjithë e dinë se analitika e biznesit në kompani shpesh fillon me përdorimin jashtëzakonisht aktiv të, po, Excel. Por gjëja kryesore është se nuk mbaron këtu. Google Analytics i bazuar në renë kompjuterike gjithashtu shton karburant në zjarr - shpejt filloni të mësoheni me gjërat e mira.
Në kompaninë tonë në zhvillim harmonik, aty-këtu filluan të shfaqen "profetë" të punës më intensive me të dhëna më të mëdha. Nevoja për raporte më të thella dhe të shumëanshme filloi të shfaqej rregullisht, dhe me përpjekjet e djemve nga departamente të ndryshme, disa kohë më parë u organizua një zgjidhje e thjeshtë dhe praktike - një kombinim i ClickHouse dhe PowerBI.
Për një kohë mjaft të gjatë, kjo zgjidhje fleksibël ndihmoi shumë, por gradualisht filloi të kuptohej se ClickHouse nuk është gome dhe nuk mund të tallen kështu.
Këtu është e rëndësishme të kuptohet mirë se ClickHouse, si Druid, si Vertica, si Amazon RedShift (i cili bazohet në postgres), janë motorë analitikë të optimizuar për analitika mjaft të përshtatshme (shuma, grumbullime, minimum-maksimum sipas kolonës dhe disa bashkime të mundshme ), sepse organizuar për ruajtjen efikase të kolonave të tabelave relacionale, ndryshe nga MySQL dhe bazat e të dhënave të tjera (të orientuara nga rreshtat) të njohura për ne.
Në thelb, ClickHouse është thjesht një "bazë e të dhënave" më e madhe, me futje jo shumë të përshtatshme pikë për pikë (kështu synohet, gjithçka është në rregull), por analitika të këndshme dhe një sërë funksionesh interesante të fuqishme për të punuar me të dhëna. Po, madje mund të krijoni një grup - por ju e kuptoni që goditja e thonjve me një mikroskop nuk është plotësisht e saktë dhe ne filluam të kërkojmë zgjidhje të tjera.
Kërkesa për python dhe analistë
Kompania jonë ka shumë zhvillues që shkruajnë kod pothuajse çdo ditë për 10-20 vjet në PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash. Ka gjithashtu shumë administratorë me përvojë të sistemit që kanë përjetuar më shumë se një fatkeqësi absolutisht të pabesueshme që nuk përshtatet me ligjet e statistikave (për shembull, kur shumica e disqeve në një bastisje-10 shkatërrohen nga një goditje e fortë rrufeje). Në rrethana të tilla, për një kohë të gjatë nuk ishte e qartë se çfarë ishte një "analist python". Python është si PHP, vetëm emri është pak më i gjatë dhe ka pak më pak gjurmë të substancave që ndryshojnë mendjen në kodin burimor të përkthyesit. Sidoqoftë, ndërsa u krijuan gjithnjë e më shumë raporte analitike, zhvilluesit me përvojë filluan të kuptojnë gjithnjë e më shumë rëndësinë e specializimit të ngushtë në mjete si numpy, pandas, matplotlib, seaborn.
Rolin vendimtar, ka shumë të ngjarë, e luajti zbehja e papritur e punonjësve nga kombinimi i fjalëve "regresion logjistik" dhe demonstrimi i raportimit efektiv për të dhëna të mëdha duke përdorur, po, po, pyspark.
Apache Spark, paradigma e tij funksionale mbi të cilën algjebra relacionale përshtatet në mënyrë të përsosur dhe aftësitë e saj lanë një përshtypje të tillë te zhvilluesit e mësuar me MySQL, saqë nevoja për të forcuar radhët me analistë me përvojë u bë e qartë si ditë.
Përpjekje të mëtejshme të Apache Spark/Hadoop për t'u ngritur dhe çfarë nuk shkoi plotësisht sipas skenarit
Sidoqoftë, shpejt u bë e qartë se diçka sistematikisht nuk ishte plotësisht në rregull me Spark, ose thjesht ishte e nevojshme të lani duart më mirë. Nëse rafti Hadoop/MapReduce/Lucene është bërë nga programues mjaft me përvojë, gjë që është e qartë nëse shikoni nga afër kodin burimor në Java ose idetë e Doug Cutting në Lucene, atëherë Spark, papritmas, shkruhet në gjuhën ekzotike Scala, e cila është shumë e diskutueshme nga pikëpamja e prakticitetit dhe aktualisht nuk po zhvillohet. Dhe rënia e rregullt e llogaritjeve në grupin Spark për shkak të punës së palogjikshme dhe jo shumë transparente me alokimin e memories për operacionet e reduktimit (shumë çelësa mbërrijnë menjëherë) ka krijuar një aureolë rreth tij të diçkaje që ka vend për t'u rritur. Për më tepër, situata u përkeqësua nga një numër i madh portash të çuditshme të hapura, skedarë të përkohshëm që rriteshin në vendet më të pakuptueshme dhe një ferr varësish - gjë që bëri që administratorët e sistemit të kishin një ndjenjë që ishte e njohur që nga fëmijëria: urrejtje e ashpër (ose ndoshta ata duhej të lanin duart me sapun).
Si rezultat, ne kemi "mbijetuar" disa projekte të brendshme analitike që përdorin në mënyrë aktive Apache Spark (përfshirë Spark Streaming, Spark SQL) dhe ekosistemin Hadoop (dhe kështu me radhë e kështu me radhë). Përkundër faktit se me kalimin e kohës mësuam ta përgatisim dhe monitorojmë "ajo" mjaft mirë, dhe "ajo" praktikisht pushoi së rrëzuari papritur për shkak të ndryshimeve në natyrën e të dhënave dhe çekuilibrit të hashimit uniform RDD, dëshira për të marrë diçka tashmë të gatshme. , i përditësuar dhe i administruar diku në re u bë gjithnjë e më i fortë. Ishte në këtë kohë që ne u përpoqëm të përdornim asamblenë e gatshme të cloud të Shërbimeve të Uebit të Amazon - dhe, më pas, u përpoq të zgjidhte problemet duke e përdorur atë. EMR është Apache Spark i përgatitur nga Amazon me softuer shtesë nga ekosistemi, njësoj si ndërtimet Cloudera/Hortonworks.
Ruajtja e skedarëve të gomës për analitikë është një nevojë urgjente
Eksperienca e “gatimit” të Hadoop/Spark me djegie në pjesë të ndryshme të trupit nuk ishte e kotë. Nevoja për të krijuar një ruajtje skedari të vetëm, të lirë dhe të besueshëm që do të ishte rezistent ndaj dështimeve të harduerit dhe në të cilin do të ishte e mundur të ruheshin skedarë në formate të ndryshme nga sisteme të ndryshme dhe të bënin mostra efikase dhe efikase në kohë për raportet nga këto të dhëna, u bë gjithnjë e më shumë. qartë.
Doja gjithashtu që përditësimi i softuerit të kësaj platforme të mos kthehej në një makth të Vitit të Ri me leximin e gjurmëve Java prej 20 faqesh dhe analizimin e regjistrave të detajuar kilometrikë të grupit duke përdorur serverin Spark History dhe një xham zmadhues me dritë prapa. Doja të kisha një mjet të thjeshtë dhe transparent që nuk kërkonte zhytje të rregullt nën kapuç nëse kërkesa standarde e zhvilluesit MapReduce ndalonte së ekzekutuari kur punonjësi i reduktimit të të dhënave ra nga memoria për shkak të një algoritmi jo shumë të zgjedhur të ndarjes së të dhënave burimore.
A është Amazon S3 një kandidat për DataLake?
Përvoja me Hadoop/MapReduce na mësoi se ne kemi nevojë për një sistem skedarësh të shkallëzuar, të besueshëm dhe punëtorë të shkallëzueshëm në krye të tij, që "u afrohen" më shumë të dhënave në mënyrë që të mos i kalojnë të dhënat në rrjet. Punëtorët duhet të jenë në gjendje të lexojnë të dhëna në formate të ndryshme, por mundësisht të mos lexojnë informacione të panevojshme dhe të jenë në gjendje të ruajnë të dhënat paraprakisht në formate të përshtatshme për punëtorët.
Edhe një herë, ideja bazë. Nuk ka dëshirë për të "derdhur" të dhëna të mëdha në një motor analitik të vetëm grupor, i cili herët a vonë do të mbytet dhe do t'ju duhet ta copëtoni atë në mënyrë të shëmtuar. Unë dua të ruaj skedarë, vetëm skedarë, në një format të kuptueshëm dhe të kryej pyetje analitike efektive mbi to duke përdorur mjete të ndryshme por të kuptueshme. Dhe do të ketë gjithnjë e më shumë skedarë në formate të ndryshme. Dhe është më mirë të copëtoni jo motorin, por të dhënat e burimit. Ne kemi nevojë për një DataLake të shtrirë dhe universale, vendosëm...
Po sikur të ruani skedarët në hapësirën e njohur dhe të mirënjohur të ruajtjes së shkallëzueshme të cloud Amazon S3, pa pasur nevojë të përgatisni prerjet tuaja nga Hadoop?
Është e qartë se të dhënat personale janë "të ulëta", por çfarë ndodh me të dhënat e tjera nëse i nxjerrim ato dhe "i drejtojmë në mënyrë efektive"?
Ekosistemi Cluster-bigdata-analitics i Shërbimeve të Uebit të Amazon - me fjalë shumë të thjeshta
Duke gjykuar nga përvoja jonë me AWS, Apache Hadoop/MapReduce është përdorur në mënyrë aktive atje për një kohë të gjatë nën salca të ndryshme, për shembull në shërbimin DataPipeline (i kam zili kolegët e mi, ata mësuan se si ta përgatisin saktë). Këtu kemi vendosur kopje rezervë nga shërbime të ndryshme nga tabelat DynamoDB:
Dhe ata kanë funksionuar rregullisht në grupe të integruara Hadoop/MapReduce si ora për disa vite. "Vendosni dhe harroni":
Ju gjithashtu mund të angazhoheni në mënyrë efektive në satanizmin e të dhënave duke vendosur laptopë Jupiter në cloud për analistët dhe duke përdorur shërbimin AWS SageMaker për të trajnuar dhe vendosur modelet e AI në betejë. Ja si duket për ne:
Dhe po, mund të merrni një kompjuter portativ për veten tuaj ose një analist në cloud dhe ta lidhni atë në një grup Hadoop/Spark, të bëni llogaritjet dhe më pas të vendosni gjithçka poshtë:
Vërtet i përshtatshëm për projekte individuale analitike dhe për disa ne kemi përdorur me sukses shërbimin EMR për llogaritjet dhe analitikën në shkallë të gjerë. Po në lidhje me një zgjidhje sistemi për DataLake, a do të funksionojë? Në këtë moment ishim në prag të shpresës dhe dëshpërimit dhe vazhduam kërkimin.
Ngjitës AWS - Apache Spark i paketuar mirë në steroid
Doli që AWS ka versionin e vet të pirgut "Hive/Pig/Spark". Roli i Hive, d.m.th. Katalogu i skedarëve dhe llojet e tyre në DataLake kryhet nga shërbimi “Data catalog”, i cili nuk e fsheh përputhshmërinë e tij me formatin Apache Hive. Duhet të shtoni informacion në këtë shërbim 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ë bazën e të dhënave, por kjo nuk është tema e këtij postimi. Ja se si është organizuar direktoria jonë e të dhënave DataLake:
Dosjet janë të regjistruara, shumë mirë. Nëse skedarët janë përditësuar, ne lëshojmë zvarritësit manualisht ose sipas një plani, i cili do të përditësojë informacionin rreth tyre nga liqeni dhe do t'i ruajë. Më pas të dhënat nga liqeni mund të përpunohen dhe rezultatet të ngarkohen diku. Në rastin më të thjeshtë, ne gjithashtu ngarkojmë në s3. Përpunimi i të dhënave mund të bëhet kudo, por sugjerohet që të konfiguroni përpunimin në një grup Apache Spark duke përdorur aftësi të avancuara përmes AWS Glue API. Në fakt, ju mund të merrni kodin e mirë të vjetër dhe të njohur të python duke përdorur bibliotekën pyspark dhe të konfiguroni ekzekutimin e tij në N nyje të një grupi me njëfarë kapaciteti me monitorim, pa gërmuar në zorrët e Hadoop dhe duke zvarritur kontejnerët docker-moker dhe duke eliminuar konfliktet e varësisë. .
Edhe një herë, një ide e thjeshtë. Nuk ka nevojë të konfiguroni Apache Spark, ju vetëm duhet të shkruani kodin python për pyspark, ta testoni atë lokalisht në desktopin tuaj dhe më pas ta ekzekutoni në një grup të madh në cloud, duke specifikuar se ku janë të dhënat burimore dhe ku të vendosni rezultatin. Ndonjëherë kjo është e nevojshme dhe e dobishme, dhe ja se si e konfigurojmë:
Kështu, nëse duhet të llogarisni diçka në një grup Spark duke përdorur të dhëna në s3, ne shkruajmë kodin në python/pyspark, e testojmë atë dhe i urojmë fat cloud.
Po për orkestrimin? Po sikur detyra të binte dhe të zhdukej? Po, propozohet të bëjmë një tubacion të bukur në stilin Apache Pig dhe madje i kemi provuar, por tani për tani vendosëm të përdorim orkestrimin tonë thellësisht të personalizuar në PHP dhe JavaScript (e kuptoj, ka disonancë njohëse, por funksionon, për vite dhe pa gabime).
Formati i skedarëve të ruajtur në liqen është çelësi i performancës
Është shumë, shumë e rëndësishme të kuptosh dy pika të tjera kryesore. Në mënyrë që pyetjet mbi të dhënat e skedarëve në liqen të ekzekutohen sa më shpejt që të jetë e mundur dhe performanca të mos degradohet kur shtohet informacion i ri, ju duhet:
- Ruani kolonat e skedarëve veçmas (në mënyrë që të mos keni nevojë të lexoni të gjitha rreshtat për të kuptuar se çfarë ka në kolona). Për këtë kemi marrë formatin e parketit me komprimim
- Është shumë e rëndësishme të ndani skedarët në dosje si: gjuha, viti, muaji, dita, java. Motorët që kuptojnë këtë lloj ndarjeje do të shikojnë vetëm dosjet e nevojshme, pa shoshitur të gjitha të dhënat me radhë.
Në thelb, në këtë mënyrë, ju vendosni të dhënat burimore në formën më efikase për motorët analitikë të varur në krye, të cilët edhe në dosjet e copëtuara mund të futin në mënyrë selektive dhe të lexojnë vetëm kolonat e nevojshme nga skedarët. Nuk ka nevojë të "mbushni" të dhënat askund (ruajtjen thjesht do të shpërthejë) - thjesht vendoseni menjëherë me mençuri në sistemin e skedarëve në formatin e duhur. Sigurisht, këtu duhet të jetë e qartë se ruajtja e një skedari të madh csv në DataLake, i cili fillimisht duhet të lexohet rresht pas rreshti nga grupi për të nxjerrë kolonat, nuk është shumë i këshillueshëm. Mendoni përsëri për dy pikat e mësipërme nëse nuk është ende e qartë pse po ndodh e gjithë kjo.
AWS Athena - jack-in-the-box
Dhe më pas, gjatë krijimit të një liqeni, disi rastësisht hasëm në Amazon Athena. Papritmas doli që duke i rregulluar me kujdes skedarët tanë të mëdhenj të regjistrave në copëza dosjesh në formatin e duhur të kolonës (parket), mund të bëni shumë shpejt zgjedhje jashtëzakonisht informuese prej tyre dhe të ndërtoni raporte PA, pa një grup Apache Spark/Glue.
Motori Athena i mundësuar nga të dhënat në s3 bazohet në legjendarin - një përfaqësues i familjes MPP (përpunimi masiv paralel) i qasjeve ndaj përpunimit të të dhënave, duke marrë të dhënat aty ku ndodhen, nga s3 dhe Hadoop te Cassandra dhe skedarët e zakonshëm të tekstit. Thjesht duhet t'i kërkoni Athenës të ekzekutojë një pyetje SQL dhe më pas gjithçka "funksionon shpejt dhe automatikisht". Është e rëndësishme të theksohet se Athena është "e zgjuar", shkon vetëm në dosjet e nevojshme të copëtuara dhe lexon vetëm kolonat e nevojshme në kërkesë.
Çmimi për kërkesat për Athena është gjithashtu interesant. Ne paguajmë për . ato. jo për numrin e makinave në grup në minutë, por... për të dhënat e skanuara në të vërtetë në 100-500 makina, vetëm të dhënat e nevojshme për të plotësuar kërkesën.
Dhe duke kërkuar vetëm kolonat e nevojshme nga dosjet e copëtuara saktë, rezultoi se shërbimi Athena na kushton dhjetëra dollarë në muaj. Epo, shkëlqyeshëm, pothuajse falas, krahasuar me analitikën në grupime!
Nga rruga, ja se si i ndajmë të dhënat tona në s3:
Si rezultat, në një kohë të shkurtër, departamente krejtësisht të ndryshme në kompani, nga siguria e informacionit te analitika, filluan të bënin në mënyrë aktive kërkesa tek Athena dhe shpejt, në sekonda, të merrnin përgjigje të dobishme nga të dhëna "të mëdha" për periudha mjaft të gjata: muaj, gjysmë viti, etj. P.
Por ne shkuam më tej dhe filluam të shkojmë në re për përgjigje : një analist shkruan një pyetje SQL në një tastierë të njohur, e cila në 100-500 makina "për qindarka" dërgon të dhëna në s3 dhe kthen një përgjigje zakonisht në disa sekonda. Të rehatshme. Dhe shpejt. Ende nuk mund ta besoj.
Si rezultat, pasi vendosëm të ruanim të dhënat në s3, në një format kolonë efikas dhe me ndarje të arsyeshme të të dhënave në dosje... morëm DataLake dhe një motor analitik të shpejtë dhe të lirë - falas. Dhe ai u bë shumë i njohur në kompani, sepse... kupton SQL dhe punon rendet e përmasave më shpejt sesa përmes nisjes/ndalimit/konfigurimit të grupimeve. "Dhe nëse rezultati është i njëjtë, pse të paguani më shumë?"
Një kërkesë drejtuar Athinës duket diçka si kjo. Nëse dëshironi, sigurisht, mund të formoni mjaftueshëm , por do të kufizohemi në grupim të thjeshtë. Le të shohim se çfarë kodesh përgjigje kishte klienti disa javë më parë në regjistrat e serverit në internet dhe sigurohuni që të mos ketë gabime:
Gjetjet
Duke kaluar, për të mos thënë një rrugë të gjatë, por të dhimbshme, duke vlerësuar vazhdimisht në mënyrë adekuate rreziqet dhe nivelin e kompleksitetit dhe koston e mbështetjes, gjetëm një zgjidhje për DataLake dhe analitikën që nuk pushon së kënaquri me shpejtësinë dhe koston e pronësisë.
Doli që ndërtimi i një DataLake efektiv, të shpejtë dhe të lirë për të operuar për nevojat e departamenteve krejtësisht të ndryshme të kompanisë është plotësisht brenda aftësive edhe të zhvilluesve me përvojë që nuk kanë punuar kurrë si arkitektë dhe nuk dinë të vizatojnë katrorë në sheshe me shigjeta dhe di 50 terma nga ekosistemi Hadoop.
Në fillim të udhëtimit, koka ime po ndahej nga shumë kopshte zoologjike të egra të softuerit të hapur dhe të mbyllur dhe të kuptuarit e barrës së përgjegjësisë ndaj pasardhësve. Thjesht filloni ndërtimin e DataLake tuaj nga mjete të thjeshta: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., duke mbledhur komente dhe duke kuptuar thellësisht fizikën e proceseve që ndodhin. Çdo gjë komplekse dhe e errët - jepjani armiqve dhe konkurrentëve.
Nëse nuk dëshironi të shkoni në renë kompjuterike dhe të pëlqeni të mbështesni, përditësoni dhe korrigjoni projekte me burim të hapur, mund të ndërtoni një skemë të ngjashme me tonën në nivel lokal, në makineritë e lira të zyrës me Hadoop dhe Presto në krye. Gjëja kryesore nuk është të ndaleni dhe të ecni përpara, të numëroni, të kërkoni zgjidhje të thjeshta dhe të qarta dhe gjithçka do të funksionojë patjetër! Fat të gjithëve dhe shihemi përsëri!
Burimi: www.habr.com