Garai harrigarrian bizi gara, prest dauden kode irekiko hainbat tresna azkar eta erraz konekta ditzakezunean, zure "kontzientzia itzalita" stackoverflow-en aholkuaren arabera konfiguratu ditzakezun, "letra anitzetan" sakondu gabe, eta abiarazi. merkataritza-funtzionamenduan jarri. Eta eguneratu/zabaldu behar duzunean edo norbaitek ustekabean makina pare bat berrabiarazten dituenean - konturatzen zara errealitatean amets gaizto obsesiboren bat hasi dela, dena bat-batean konplikatuagoa bihurtu da ezezagunaz, ez dago atzera bueltarik, etorkizuna lausoa da. eta seguruago, programatu beharrean, erleak hazi eta gazta egin.
Ez da ezertarako balio esperientziadun lankideek, burua akatsez josirik eta, beraz, jada grisa dutela, "edukiontzien" paketeak "kubo"tan hamaika zerbitzarietan "modako hizkuntzatan" barneratuta duten euskarria duten "edukiontzien" inplementazioa izugarri bizkortzen ari direla. I/O ez-blokeatzaile asinkronoak, irribarre xume. Eta isilean jarraitzen dute "man ps" berrirakurtzen, "nginx" iturburu-kodean sakontzen dute begiak odoldu arte, eta unitate-probak idazten, idazten, idazten. Lankideek badakite gauzarik interesgarriena Urtezahar gauean egun batean "hau guztia" jokoan jartzen denean etorriko dela. Eta unix-en izaera, memorizatutako TCP/IP egoera-taula eta oinarrizko ordenazio-bilaketa algoritmoak soilik lagunduko diete. Sistemari bizia itzultzeko txirrinek jotzen duten bitartean.
Hori bai, pixka bat distraitu nintzen, baina espero dut ikusmin egoera transmititzea lortu izana.
Gaur egun, DataLake-rako pila eroso eta merke bat zabaltzean gure esperientzia partekatu nahi dut, enpresaren zeregin analitiko gehienak egitura-dibisio guztiz desberdinetarako konpontzen dituena.
Duela denbora pixka bat, enpresek gero eta gehiago behar dituztela produktuaren eta analisi teknikoaren fruituak (ikaskuntza automatikoaren formako gozoa aipatzearren) eta joerak eta arriskuak ulertzeko: bildu eta aztertu behar ditugu. gero eta metrika gehiago.
Oinarrizko analisi teknikoa Bitrix24-n
Duela zenbait urte, Bitrix24 zerbitzua abiarazi zenarekin batera, denbora eta baliabideak aktiboki inbertitu genituen plataforma analitiko sinple eta fidagarria sortzeko, azpiegiturako arazoak azkar ikusten eta hurrengo urratsa planifikatzen lagunduko zuena. Noski, komeni zen prest egindako tresnak hartzea, ahalik eta errazenak eta ulergarrienak. Ondorioz, nagios aukeratu zen monitorizaziorako eta munin analitika eta bistaratzeko. Orain milaka egiaztapen ditugu nagioetan, ehunka grafiko munin, eta gure lankideek arrakastaz erabiltzen dituzte egunero. Neurri argiak dira, grafikoak argiak, sistemak hainbat urte daramatza modu fidagarrian funtzionatzen eta aldian-aldian proba eta grafiko berriak gehitzen zaizkio: zerbitzu berri bat martxan jartzen dugunean, hainbat proba eta grafiko gehitzen ditugu. Zorte on.
Finger on the Pulse - Analitika Tekniko Aurreratua
Arazoei buruzko informazioa "ahalik eta azkarren" jasotzeko nahiak tresna sinple eta ulergarriekin - pinba eta xhprof-ekin esperimentu aktiboetara eraman gintuen.
Pinbak UDP paketeetan estatistikak bidali zizkigun PHPn web orrien zatien funtzionamendu-abiadurari buruz, eta sarean ikusi ahal izan genuen MySQL biltegian (Pinba-k bere MySQL motor propioarekin dator gertaeren analisi azkarra egiteko) arazoen zerrenda labur bat eta erantzuteko. haiek. Eta xhprof-ek automatikoki aukera eman zigun bezeroengandik PHP orrialde motelenaren exekuzioaren grafikoak biltzeko eta zer ekar zezakeen aztertzeko: lasai, tea botaz edo zerbait indartsuagoa.
Duela denbora pixka bat, tresna-kutxa beste motor nahiko sinple eta ulergarri batekin osatu zen alderantzizko indexatzeko algoritmoan oinarrituta, ezin hobeto inplementatuta Lucene liburutegi mitikoan - Elastic/Kibana. Erregistroetako gertaeretan oinarritutako hari anitzeko dokumentuak hari anitzeko grabaketa eta alderantzizko indize batean grabatzeko ideia sinplea benetan erabilgarria izan da.
Kibanan bisualizazioen itxura nahiko teknikoa izan arren, "ontzia" "gorantz doa" bezalako kontzeptu baxuekin eta oraindik guztiz ahaztu gabeko harreman-aljebraren hizkuntza berrasmatuarekin, tresna ondo laguntzen hasi zitzaigun zeregin hauetan:
- Zenbat PHP akats izan ditu Bitrix24 bezeroak p1 atarian azken orduan eta zeintzuk? Ulertu, barkatu eta azkar zuzendu.
- Zenbat bideo-dei egin dira Alemaniako atarietan aurreko 24 orduetan, zein kalitaterekin eta zailtasunik egon al zen kanal/sarearekin?
- Zeinen ondo funtzionatzen du sistemaren funtzionaltasunak (gure C luzapena PHPrako), azken zerbitzuaren eguneratzean iturritik bilduta eta bezeroei zabaldutakoa? Ba al daude segakatsak?
- Bezeroaren datuak PHP memorian sartzen al dira? Akatsik al dago prozesuei esleitutako memoria gainditzean: "memoria gabe"? Aurkitu eta neutralizatu.
Hona hemen adibide konkretu bat. Maila anitzeko probak egin arren, bezeroak, kasu oso ez-estandar batekin eta sarrerako datu hondatuta, akats gogaikarri eta ustekabeko bat jaso zuen, sirena batek jo zuen eta azkar konpontzeko prozesua hasi zen:
Gainera, kibana-k jakinarazpenak antolatzeko aukera ematen du zehaztutako gertakarietarako, eta denbora gutxian enpresan tresnak hainbat sailetako dozenaka langilek erabiltzen hasi ziren - laguntza teknikotik eta garapenetik QA-raino.
Enpresako edozein sailen jarduera jarraitzeko eta neurtzeko erosoa bihurtu da - zerbitzarietako erregistroak eskuz aztertu beharrean, analisi-erregistroak behin konfiguratu eta kluster elastikora bidali besterik ez duzu egin behar, adibidez, kibanan kontenplatzeko. panela azken ilargi hilabetean 3D inprimagailuan inprimatutako bi buruko katutxoen kopurua.
Oinarrizko Enpresa Analitika
Denek daki enpresetako negozio-analisiak sarritan Excel-en erabilera oso aktiboarekin hasten direla. Baina gauza nagusia ez dela hor bukatzen da. Hodeian oinarritutako Google Analytics-ek ere erregaia gehitzen dio suari - azkar hasten zara gauza onetara ohitzen.
Harmonioki garatzen ari den gure enpresan, han eta hemen datu handiagoko lan intentsiboagoko "profetak" agertzen hasi ziren. Txosten sakonago eta askotarikoen beharra aldian-aldian agertzen hasi zen, eta sail ezberdinetako mutilen ahaleginaren bidez, duela denbora pixka bat irtenbide sinple eta praktiko bat antolatu zen: ClickHouse eta PowerBI-ren konbinazioa.
Denbora luzez, irtenbide malgu honek asko lagundu zuen, baina pixkanaka-pixkanaka ulertzea hasi zen ClickHouse ez dela goma eta ezin dela horrela iseka.
Hemen garrantzitsua da ondo ulertzea ClickHouse, Druid bezalakoa, Vertica bezalakoa, Amazon RedShift bezalakoa (postgres-en oinarritzen dena), analitika nahiko erosoetarako optimizatuta dauden motor analitikoak direla (batuketak, batuketak, zutabearen araberako gutxieneko-gehieneko eta elkarketa posible batzuk) ), zeren Erlazio-taulen zutabeen biltegiratze eraginkorrerako antolatuta, MySQL eta guk ezagutzen ditugun beste datu-base (errenara zuzendutakoak) ez bezala.
Funtsean, ClickHouse "datu-base" zabalagoa besterik ez da, puntuz puntu txertatzeko oso erosoa ez dena (horrela da asmoa, dena ondo dago), baina analitika atsegina eta datuekin lan egiteko funtzio indartsu interesgarrien multzoa. Bai, kluster bat ere sor dezakezu, baina ulertzen duzu mikroskopioarekin iltzeak mailukatzea ez dela guztiz zuzena eta beste irtenbide batzuk bilatzen hasi ginen.
Python eta analisten eskaria
Gure enpresak 10-20 urtez ia egunero kodea idazten duten garatzaile asko ditu PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash-en. Estatistikaren legeetan sartzen ez den hondamendi guztiz sinestezin bat baino gehiago bizi izan duten sistema-administratzaile esperientziadun asko ere badaude (adibidez, raid-10 bateko disko gehienak tximista indartsu batek suntsitzen dituenean). Halakoetan, denbora luzez ez zegoen argi zer zen "python analista" bat. Python PHP bezalakoa da, izena apur bat luzeagoa da eta adimena aldatzen duten substantzien aztarna apur bat gutxiago dago interpretearen iturburu-kodean. Hala ere, gero eta txosten analitiko gehiago sortu zirenez, esperientziadun garatzaileak gero eta gehiago ulertzen hasi ziren espezializazio estuaren garrantzia numpy, pandas, matplotlib, seaborn bezalako tresnetan.
Rol erabakigarria, ziurrenik, langileen bat-bateko zoramenak jokatu zuen "atzerabide logistikoa" hitzen konbinaziotik eta datu handiei buruzko txosten eraginkorraren erakustaldia, bai, bai, pyspark erabiliz.
Apache Spark-ek, harreman-aljebra ezin hobeto egokitzen den bere paradigma funtzionala eta bere gaitasunek halako inpresioa eragin zuten MySQL-ra ohituta zeuden garatzaileengan, non egun bezala argi geratu zen analista esperientziadunekin mailak sendotzeko beharra.
Apache Spark/Hadoop-en saiakera gehiago aireratzeko eta gidoiaren arabera guztiz joan ez dena
Hala ere, laster argi geratu zen Spark-ekin sistematikoki zerbait ez zegoela ondo, edo eskuak hobeto garbitzea beharrezkoa zela. Hadoop/MapReduce/Lucene pila eskarmentu handiko programatzaileek egin badute, eta hori begi-bistakoa da Java-ko iturburu-kodea arretaz begiratuz gero edo Doug Cutting-en Lucene-ko ideiak, orduan Spark, bat-batean, Scala hizkuntza exotikoan idatzita dago, hau da. oso eztabaidagarria praktikotasunaren ikuspuntutik eta gaur egun ez da garatzen. Eta Spark klusterrean egindako kalkuluen ohiko jaitsierak eragiketa murrizteko memoria esleipenarekin egindako lan ilogiko eta ez oso gardenaren ondorioz (gako asko aldi berean iristen dira) hazteko lekua duen zerbaiten haloa sortu du inguruan. Gainera, egoera larriagotu egin zen portu ireki bitxi ugarik, leku ulergaitzenetan hazten ziren aldi baterako fitxategiak eta jar menpekotasun infernu batek - eta horrek sistema-administratzaileei txikitatik ezaguna zen sentipen bat izatea eragin zuen: gorroto gogorra (edo beharbada eskuak xaboiarekin garbitu behar zituzten).
Ondorioz, Apache Spark (Spark Streaming, Spark SQL barne) eta Hadoop ekosistema (eta abar eta abar) aktiboki erabiltzen dituzten hainbat barne-proiektu analitiko "bizirik" ditugu. Denborarekin "hori" prestatzen eta monitorizatzen ikasi genuen arren, eta "hau" ia bat-batean huts egiteari utzi zion datuen izaera aldaketengatik eta RDD hashing uniformearen desoreka dela eta, dagoeneko prest dagoen zerbait hartzeko gogoa. , hodeiaren nonbait eguneratua eta administratua gero eta indartsuagoa zen. Une honetan saiatu ginen Amazon Web Services-en prest egindako hodei muntaia erabiltzen - eta, ondoren, problemak konpontzen saiatu zen hura erabiliz. EMR Amazonek prestatutako Apache Spark da ekosistemako software gehigarriarekin, Cloudera/Hortonworks-ek eraikitzen duen antzera.
Analitiketarako gomazko fitxategiak biltegiratzea premiazkoa da
Hadoop/Spark gorputzeko hainbat ataletan erredurarekin "sukaldatzeko" esperientzia ez zen alferrikakoa izan. Fitxategien biltegiratze bakarra, merke eta fidagarria sortzeko beharra, hardware-akatsen aurrean erresistentea izango zena eta sistema ezberdinetako fitxategiak formatu ezberdinetan gordetzea eta datu horietatik txostenak egiteko lagin eraginkorrak eta denbora-eraginkorrak egiteko aukera izango zena. argi.
Gainera, plataforma honen softwarea eguneratzea Urte Berriko amesgaizto bat bihurtu nahi nuen 20 orrialdeko Java arrastoak irakurriz eta klusterraren kilometro luzeko erregistro zehatzak aztertuz Spark History Server eta atzeko argiztatutako lupa erabiliz. Tresna sinple eta gardena izan nahi nuen, ez zuen ohiko urpekaritza behar kanpaia azpian garatzailearen MapReduce eskaera estandarra exekutatzen gelditu bazen, murrizketa-langilea memoriatik kanpo geratu zenean, ez oso ondo aukeratutako iturri-datuen zatiketa algoritmo batengatik.
Amazon S3 DataLakerako hautagaia al da?
Hadoop/MapReduce-rekin izandako esperientziak irakatsi zigun fitxategi-sistema eskalagarri eta fidagarri bat eta langile eskalagarriak behar ditugula horren gainean, datuetara "hurbilduz" datuak sarean zehar ez gidatzeko. Langileek datuak formatu ezberdinetan irakurtzeko gai izan behar dute, baina hobe ez irakurri behar ez den informazioa eta datuak aldez aurretik langileentzako erosoak diren formatuetan gordetzeko gai izan behar dute.
Beste behin, oinarrizko ideia. Ez dago datu handiak "isuri" nahi kluster motor analitiko bakarrera, lehenago edo beranduago ito egingo baitu eta itsusia zatitu beharko duzu. Fitxategiak, fitxategiak besterik ez, formatu ulergarri batean gorde nahi ditut eta horien gainean kontsulta analitiko eraginkorrak egin nahi ditut tresna desberdinak baina ulergarriak erabiliz. Eta formatu ezberdinetan gero eta fitxategi gehiago egongo dira. Eta hobe da motorra ez zatitzea, iturriko datuak baizik. DataLake hedagarri eta unibertsala behar dugu, erabaki genuen...
Zer gertatzen da fitxategiak Amazon S3 hodeiko biltegiratze eskalagarri ezagun eta ezagunean gordetzen badituzu, Hadoop-en zure txuletak prestatu beharrik gabe?
Argi dago datu pertsonalak βbaxuakβ direla, baina zer gertatzen da beste datu batzuk atera eta βeraginkortasunez gidatzenβ baditugu?
Amazon Web Services-en Cluster-bigdata-analytics ekosistema - hitz oso sinpleetan
AWSrekin dugun esperientzia ikusita, Apache Hadoop/MapReduce aktiboki erabiltzen da denbora luzez hainbat saltsatan, DataPipeline zerbitzuan adibidez (inbidia ematen diet nire lankideei, behar bezala prestatzen ikasi zuten). Hemen DynamoDB tauletatik zerbitzu ezberdinetako babeskopiak konfiguratzen ditugu:
Eta erlojupekoa bezalako Hadoop/MapReduce kluster txertatuetan aldizka exekutatzen ari dira orain dela hainbat urte. "Ezarri eta ahaztu":
Era berean, datuen satanismoan modu eraginkorrean parte hartu dezakezu Jupiter ordenagailu eramangarriak hodeian konfiguratuz analistak eta AWS SageMaker zerbitzua erabiliz AI ereduak borrokan entrenatzeko eta zabaltzeko. Hona hemen guretzat nolakoa den:
Bai, zuretzako edo analista bat hodeian eraman dezakezun ordenagailu eramangarri bat hartu eta Hadoop/Spark kluster batera lotu, kalkuluak egin eta dena iltzatu:
Benetan erosoa banakako proiektu analitikoetarako eta batzuentzat arrakastaz erabili dugu EMR zerbitzua eskala handiko kalkulu eta analisietarako. Zer gertatzen da DataLake-ren sistema-irtenbide batekin, funtzionatuko al du? Momentu honetan itxaropenaren eta etsipenaren atarian geunden eta bilaketarekin jarraitu genuen.
AWS Glue - Apache Spark esteroideetan ondo paketatuta
Agertu zen AWS-k "Hive/Pig/Spark" pilaren bertsio propioa duela. Hiveren rola, hau da. DataLake-n fitxategien katalogoa eta haien motak "Datu katalogoa" zerbitzuak egiten du, eta horrek ez du ezkutatzen Apache Hive formatuarekin duen bateragarritasuna. Zerbitzu honi informazioa gehitu behar diozu zure fitxategiak non dauden eta zein formatutan dauden. Datuak s3-n ez ezik, datu-basean ere egon daitezke, baina hori ez da mezu honen gaia. Hona hemen gure DataLake datuen direktorioa nola antolatzen den:
Fitxategiak erregistratuta daude, bikaina. Fitxategiak eguneratu badira, arakatzaileak abiarazten ditugu eskuz edo programazio batean, eta lakutik haiei buruzko informazioa eguneratu eta gordeko dute. Ondoren, lakuko datuak prozesatu eta emaitzak nonbait igo daitezke. Kasurik errazenean, s3-ra ere igotzen dugu. Datuak prozesatzea edonon egin daiteke, baina prozesatzea Apache Spark kluster batean konfiguratzea gomendatzen da gaitasun aurreratuak erabiliz AWS Glue APIaren bidez. Izan ere, python kode zahar eta ezaguna hartu dezakezu pyspark liburutegia erabiliz eta bere exekuzioa konfigura dezakezu monitorizazioarekin nolabaiteko gaitasuna duen kluster baten N nodoetan, Hadoop-en erraietan sartu gabe eta docker-moker edukiontziak arrastatu gabe eta menpekotasun gatazkak ezabatuz. .
Berriro ere, ideia sinple bat. Ez dago Apache Spark konfiguratu beharrik, python kodea idatzi besterik ez duzu behar pysparkerako, lokalean probatu zure mahaigainean eta gero exekutatu hodeiko kluster handi batean, iturburu datuak non dauden eta emaitza non jarri zehaztuz. Batzuetan hau beharrezkoa eta erabilgarria da, eta honela konfiguratzen da hemen:
Horrela, Spark kluster batean zerbait kalkulatu behar baduzu s3-ko datuak erabiliz, kodea idatziko dugu python/pyspark-en, probatu eta zorte on hodeiari.
Zer gertatzen da orkestrazioaz? Zer gertatuko litzateke zeregina erori eta desagertuko balitz? Bai, Apache Pig estiloan kanalizazio eder bat egitea proposatzen da eta probatu ere egin ditugu, baina oraingoz gure pertsonalizatutako orkestrazioa PHP eta JavaScript-en erabiltzea erabaki dugu (ulertzen dut, disonantzia kognitiboa dagoela, baina funtzionatzen du, urteak eta akatsik gabe).
Lakuan gordetako fitxategien formatua errendimendurako gakoa da
Oso-oso garrantzitsua da beste bi puntu gako ulertzea. Lakuko fitxategien datuei buruzko kontsultak ahalik eta azkarren egiteko eta informazio berria gehitzean errendimendua ez hondatzeko, honako hau egin behar duzu:
- Gorde fitxategien zutabeak bereizita (zutabeetan zer dagoen ulertzeko lerro guztiak irakurri beharrik ez izateko). Horretarako parket formatua konpresioarekin hartu dugu
- Oso garrantzitsua da fitxategiak karpetetan zatitzea: hizkuntza, urtea, hilabetea, eguna, astea. Zatiketa mota hau ulertzen duten motorrek beharrezko karpetak bakarrik aztertuko dituzte, datu guztiak segidan bahetu gabe.
Funtsean, modu honetan, iturburu-datuak formarik eraginkorrenean jartzen dituzu gainean zintzilik dauden motor analitikoetarako, karpeta zatituetan ere fitxategietatik beharrezko zutabeak hautatuz sartu eta irakur ditzakete. Ez duzu datuak inon "bete" behar (biltegiratzea besterik gabe lehertuko da) - berehala jarri behar duzu fitxategi-sisteman formatu egokian. Jakina, hemen argi utzi behar da DataLake-n csv fitxategi erraldoi bat gordetzea, lehenik klusterrak lerroz lerro irakurri behar duena zutabeak ateratzeko, ez dela oso komeni. Pentsa berriro goiko bi puntuetan, oraindik argi ez badago zergatik gertatzen den hori guztia.
AWS Athena - jack-in-the-box
Eta orduan, aintzira bat sortzean, nolabait ustekabean Amazon Athena topatu genuen. Bat-batean, kontu handiz gure erregistro-fitxategi handiak karpeta zatietan (parket) zutabe formatu egokian antolatuta, oso azkar egin ditzakezula hautapen oso informatiboak eta txostenak GABE sortu ditzakezu, Apache Spark/Glue klusterrik gabe.
s3-n datuek bultzatutako Athena motorra mitikoan oinarritzen da - Datuak prozesatzeko MPP (massive parallel processing) familiako ordezkari bat, datuak dauden tokian hartuta, s3 eta Hadoopetik Cassandra eta testu-fitxategi arruntetaraino. Athenari SQL kontsulta bat exekutatzeko eskatu behar diozu, eta gero dena "azkar eta automatikoki funtzionatzen du". Garrantzitsua da Athena "adimentsua" dela, beharrezko zatitutako karpetetara bakarrik joaten dela eta eskaeran behar diren zutabeak soilik irakurtzen dituela.
Athena-ri egindako eskaeren prezioa ere interesgarria da. Guk ordaintzen dugu . Horiek. ez minutuko klusterrean dagoen makina kopuruagatik, baizik eta... 100-500 makinetan benetan eskaneatutako datuetarako, eskaera betetzeko beharrezkoak diren datuak soilik.
Eta behar bezala zatitutako karpetetatik beharrezkoak diren zutabeak soilik eskatuz gero, Athena zerbitzuak hilabetean hamarnaka dolar kostatzen dizkigu. Beno, bikaina, ia doakoa, klusterren analisiekin alderatuta!
Bide batez, hona hemen gure datuak s3-n nola banatzen ditugun:
Ondorioz, denbora gutxian, enpresako sail guztiz desberdinak, informazioaren segurtasunetik hasi eta analitiketara, aktiboki eskaerak egiten hasi ziren Athenari eta azkar, segundotan, datu "handietatik" erantzun baliagarriak jasotzen aldi nahiko luzeetan: hilabeteak, urte erdi, etab. P.
Baina harago joan ginen eta erantzunen bila hodeira joaten hasi ginen : analista batek SQL kontsulta bat idazten du kontsola ezagun batean, zeinak 100-500 makinetan "zentimoengatik" datuak bidaltzen ditu s3-ra eta erantzun bat itzultzen du normalean segundo gutxitan. Eroso. Eta azkar. Oraindik ezin dut sinetsi.
Ondorioz, datuak s3-n gordetzea erabaki genuen, zutabe formatu eraginkor batean eta datuak karpetetan zentzuzko zatiketarekin... DataLake eta motor analitiko azkar eta merkea jaso genuen - doan. Eta oso ezaguna egin zen enpresan, zeren... SQL ulertzen du eta klusterrak abiarazi/gelditu/konfiguratuz baino azkarrago funtzionatzen du. "Eta emaitza berdina bada, zergatik ordaindu gehiago?"
Ateneari egindako eskaerak horrelako zerbait du. Nahi izanez gero, noski, nahikoa osatu dezakezu , baina taldekatze sinplera mugatuko gara. Ikus dezagun zer erantzun-kode zituen bezeroak duela aste batzuk web-zerbitzariaren erregistroetan eta ziurtatu errorerik ez dagoela:
Findings
Bide luzea, baina mingarria ez esatearren, arriskuak eta konplexutasun maila eta laguntzaren kostua etengabe behar bezala ebaluatuz, DataLake-rako eta analisirako irtenbide bat aurkitu dugu, bi abiadurarekin eta jabetza-kostuarekin gustura uzten ez gaituena.
Kontuan izan da DataLake eraginkorra, azkarra eta merkea eraikitzea konpainiako sail guztiz desberdinen beharretarako erabat arkitekto gisa lan egin ez duten eta laukietan karratuak marrazten ez dakiten garatzaile esperientziadunen gaitasunen barruan dagoela. geziak eta ezagutu Hadoop ekosistemako 50 termino.
Bidaiaren hasieran, nire burua software ireki eta itxietako zoo basatietatik zatitzen ari nintzen eta ondorengoekiko erantzukizunaren zama ulertzen nuen. Hasi zure DataLake tresna sinpleetatik eraikitzen: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., iritziak bilduz eta gertatzen ari diren prozesuen fisika sakonki ulertuz. Dena konplexua eta iluna - eman etsaiei eta lehiakideei.
Hodeira joan nahi ez baduzu eta kode irekiko proiektuak babestu, eguneratu eta adabaki nahi badituzu, gurearen antzeko eskema bat eraiki dezakezu lokalean, Hadoop eta Presto gainean dituzten bulegoko makina merkeetan. Gauza nagusia ez da gelditu eta aurrera egitea, zenbatu, irtenbide sinple eta argiak bilatzea eta dena ondo aterako da! Zorte on guztioi eta berriro arte!
Iturria: www.habr.com