Vi lever i en fantastisk tid, hvor man hurtigt og nemt kan kombinere flere fĂŠrdige open source-vĂŠrktĂžjer, konfigurere dem med »afslappet sind« efter rĂ„d fra stackoverflow, uden at dykke ned i »mange bogstaver«, og lancere dem kommercielt. Men nĂ„r der er behov for opdateringer/udvidelser, eller nogen utilsigtet genstarter et par maskiner â indser man, at man er i gang med en pĂ„trĂŠngende dĂ„rlig drĂžm, hvor alt pludselig er blevet uigenkendeligt kompliceret, der er ingen vej tilbage, fremtiden er tĂ„get, og det er sikrere at dyrke bier og lave ost end at programmere.
Det er ikke underligt, at mere erfarne kolleger, med et hĂ„r der allerede er grĂ„sprĂŠngt af fejl, betragter det utroligt hurtige udrulning af bunker til »containere« i »kubikere« pĂ„ dusinvis af servere med »moderne sprog« og indbygget stĂžtte til asynkron ikke-blokerende input/output â de smiler beskedent. Og de fortsĂŠtter stille med at lĂŠse »man ps«, fordeler blodet fra Ăžjnene over kildekoden til »nginx« og skriver-skriver-skriver unit tests. Kollegerne ved, at det mest interessante vil komme senere, nĂ„r »alt dette« engang bliver en natlig udfordring ved nytĂ„r. Og kun en dyb forstĂ„else af unix-natur, indlĂŠrt TCP/IP-tilstande og grundlĂŠggende sorterings-sĂžgealgoritmer vil hjĂŠlpe dem med at genoplive systemet til klangene af klokkerne.
Ă
h ja, jeg kom lidt vÊk fra emnet, men jeg hÄber, jeg formÄede at formidle en fÞlelse af forventning.
I dag vil jeg dele vores erfaring med at implementere en nem og omkostningseffektiv stak til DataLake, som lĂžser de fleste analytiske opgaver i virksomheden for helt forskellige afdelinger.
For noget tid siden kom vi til at forstĂ„, at virksomheder i stigende grad har brug for resultater fra bĂ„de produkt- og teknisk analyse (for ikke at nĂŠvne bĂŠrrene pĂ„ kagen i form af maskinlĂŠring), og for at forstĂ„ tendenser og risici â er det nĂždvendigt at indsamle og analysere flere og flere metrikker.
Basis teknisk analyse i »Bitrix24«
För flera Ă„r sedan, i samband med lanseringen av tjĂ€nsten «Bitrix24», investerade vi aktivt tid och resurser i att skapa en enkel och pĂ„litlig analysplattform som skulle hjĂ€lpa till att snabbt upptĂ€cka problem i infrastrukturen och planera nĂ€sta steg. SjĂ€lvklart önskade vi att anvĂ€nda fĂ€rdiga verktyg som var sĂ„ enkla och förstĂ„eliga som möjligt. Resultatet blev att nagios valdes för övervakning och munin för analys och visualisering. Nu har vi tusentals kontroller i nagios, hundratals diagram i munin och kollegor anvĂ€nder dem framgĂ„ngsrikt varje dag. Metrikerna Ă€r tydliga, diagrammen Ă€r klara, systemet har fungerat pĂ„litligt i flera Ă„r och ny tester och diagram lĂ€ggs regelbundet till: nĂ€r vi sĂ€tter en ny tjĂ€nst i drift â lĂ€gger vi till nĂ„gra tester och diagram. Lycka till.
HĂ„lla hand pĂ„ pulsen â utökad teknisk analys
Ănskan om att fĂ„ information om problem "sĂ„ snart som möjligt" har lett till aktiva experiment med enkla och förstĂ„eliga verktyg â pinba och xhprof.
Pinba skickade oss statistik i UDP-paket om hastigheten pĂ„ olika delar av webbplatserna i PHP, och vi kunde i realtid se en kort lista över problem i MySQL-lagret (pinba kommer med sin egen MySQL-motor för snabb hĂ€ndelseanalys) och reagera pĂ„ dem. Och xhprof möjliggjorde automatiskt insamling av exekveringsgrafer för de mest lĂ„ngsamma PHP-sidorna hos kunderna och analysera vad som kunde ha orsakat detta â lugnt, medan vi hĂ€llde upp te eller nĂ„got starkare.
För ett tag sedan utökades verktygsuppsĂ€ttningen med Ă€nnu en ganska enkel och förstĂ„elig motor baserad pĂ„ algoritmen för omvĂ€nd indexering, utmĂ€rkt implementerad i det legendariska biblioteket Lucene â Elastic/Kibana. Den enkla idĂ©n med flerdimensionell dokumentinspelning i Lucenes omvĂ€nda index baserat pĂ„ hĂ€ndelser i loggar och snabb sökning i dem med hjĂ€lp av facettering â visade sig verkligen vara anvĂ€ndbar.
Trots det ganska tekniska utseendet pĂ„ visualiseringarna i Kibana med "som flödar uppĂ„t" lĂ„g-nivĂ„ koncepter som "bucket" och det pĂ„nyttfödda sprĂ„ket av den fortfarande inte glömda relationella algebran â har verktyget verkligen hjĂ€lpt oss i följande uppgifter:
- Hur mÄnga PHP-fel har kunden Bitrix24 haft pÄ portalen p1 den senaste timmen och vilka? FörstÄ, förlÄta och snabbt ÄtgÀrda.
- Hur mÄnga videosamtal har genomförts pÄ portalerna i Tyskland under de senaste 24 timmarna, med vilken kvalitet och har det funnits nÄgra problem med kanalen/nÀtverket?
- Hur vÀl fungerar systemets funktionalitet (vÄr utvidgning i C för PHP), kompilerad frÄn kÀllkod i den senaste uppdateringen av tjÀnsten och distribuerad till kunderna? Finns det nÄgra segfaults?
- Lagrar PHP kunddata i minnet? Finns det nÄgra fel pÄ att överskrida den tilldelade minnesmÀngden: "utav minne"? Hitta och ÄtgÀrda.
HÀr Àr ett konkret exempel. Trots noggrann och flerdimensionell testning uppstod en frustrerande och ovÀntad fel hos en kund i ett mycket ovanligt fall med skadad indata, vilket ledde till att sirenen ljöd och processen för dess snabba fixning inleddes.
Dessutom gör Kibana det möjligt att organisera aviseringar baserade pĂ„ angivna hĂ€ndelser och pĂ„ kort tid började verktyget anvĂ€ndas av dussintals anstĂ€llda frĂ„n olika avdelningar â frĂ„n support och utveckling till QA.
Aktiviteten hos varje avdelning inom företaget har blivit lĂ€tt att spĂ„ra och mĂ€ta â istĂ€llet för manuell analys av loggar pĂ„ servrarna rĂ€cker det att en gĂ„ng stĂ€lla in loggparsing och skicka dem till elastic-klustret för att njuta av att till exempel betrakta antalet sĂ„lda tvĂ„huvudiga kattungar, tryckta pĂ„ 3D-skrivare under den senaste mĂ„naden.
GrundlÀggande affÀrsanalys
Alla vet att affĂ€rsanalys i företag ofta börjar med ett extremt aktivt anvĂ€ndande av, ja, ja, Excel. Men det viktigaste Ă€r att den inte slutar dĂ€r. Molnversionen av Google Analytics gör ocksĂ„ sitt för att tĂ€nda elden â man vĂ€njer sig snabbt vid det goda.
I vĂ„rt harmoniskt vĂ€xande företag har det börjat dyka upp "profeter" som arbetar med större data pĂ„ ett mer intensivt sĂ€tt. Det har regelbundet uppstĂ„tt behov av djupare och mer komplexa rapporter, och tack vare insatser frĂ„n olika avdelningar organiserades för ett tag sedan en enkel och praktisk lösning â en koppling mellan ClickHouse och PowerBI.
Under lÄng tid har denna flexibla lösning varit till stor hjÀlp, men alltmer har det blivit tydligt att ClickHouse inte Àr oÀndlig och bör inte missbrukas.
Det Àr viktigt att förstÄ att ClickHouse, precis som Druid, Vertica och Amazon RedShift (som Àr baserat pÄ Postgres), Àr analytiska motorer optimerade för ganska bekvÀm analys (summeringar, aggregeringar, minimum-maxiumum per kolumn och lite möjlighet till join), eftersom de Àr organiserade för effektiv lagring av kolumner i relationsdatabaser, till skillnad frÄn det vi kÀnner som MySQL och andra (rad-orienterade) databaser.
I grunden Àr ClickHouse bara en mer rymlig "databas", med inte sÀrskilt bekvÀm punktinsÀttning (det Àr avsiktligt, allt Àr okej), men med trevlig analys och en uppsÀttning intressanta kraftfulla funktioner för att arbeta med data. Ja, man kan till och med skapa en kluster - men du förstÄr att det inte Àr helt rÀtt att spika med ett mikroskop, och vi började leta efter andra lösningar.
EfterfrÄgan pÄ Python och analytiker
I vÄrt företag finns det mÄnga utvecklare som skriver kod nÀstan varje dag i 10-20 Är pÄ PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash. Det finns ocksÄ mÄnga erfarna systemadministratörer som har överlevt mer Àn en helt otrolig katastrof som inte passar in i statistikkens lagar (till exempel nÀr de flesta diskarna i RAID-10 förstörs vid en kraftig blixtnedslag). Under en lÄng tid var det oklart vad en "analytiker pÄ Python" egentligen innebÀr. Python Àr ju som PHP, bara med ett lite lÀngre namn och nÄgot fÀrre spÄr av substanser som förÀndrar medvetandet i kÀllkoden till tolken. Men allteftersom mÄnga nya analytiska rapporter skapades blev de erfarna utvecklarna fortfarande mer medvetna om vikten av smal specialisering inom verktyg som numpy, pandas, matplotlib, seaborn.
En avgörande roll spelades troligen av den plötsliga medvetslösheten hos anstÀllda vid kombinationen av orden "logistisk regression" och demonstrationen av effektiv rapportering pÄ stora datamÀngder med hjÀlp av, ja, pyspark.
Apache Spark, dess funktionella paradigmer, som passar perfekt med relationsalgebra och möjligheter, gjorde ett sÄdant intryck pÄ utvecklare som var vana vid MySQL, att behovet av att stÀrka bataljonsraderna med erfarna analytiker blev lika tydligt som dagen.
Fortsatta försök att Apache Spark/Hadoop skulle lyfta och vad som inte riktigt gick enligt planen
Det blev dock snart tydligt att det tydligen var nĂ„got systematiskt fel med Spark, eller sĂ„ behövde man bara tvĂ€tta hĂ€nderna bĂ€ttre. Om Hadoop/MapReduce/Lucene-stacken skapades av tillrĂ€ckligt erfarna programmerare, vilket Ă€r tydligt om man ser pĂ„ kĂ€llkoden i Java eller Douglas Cutting idĂ©er i Lucene, sĂ„ Ă€r Spark plötsligt skrivet i ett mycket omdiskuterat sprĂ„k sett ur praktisk synvinkel och som nu inte utvecklas, nĂ€mligen det exotiska sprĂ„ket Scala. Den regelbundna nedcrashningen av berĂ€kningarna pĂ„ Spark-klustret pĂ„ grund av ologisk och inte sĂ€rskilt genomskinlig hantering av minnesallokering för reduce-operationer (mĂ„nga nycklar kommer pĂ„ en gĂ„ng) har skapat en aura av nĂ„got som har stort potential att vĂ€xa. Dessutom förvĂ€rrades situationen av ett stort antal konstiga öppna portar, temporĂ€ra filer som vĂ€xte pĂ„ de mest oklara stĂ€llena och en massa jar-beroenden â vilket vĂ€ckte en bekant kĂ€nsla hos systemadministratörer: en intensiv avsky (kanske var det dags att tvĂ€tta sina hĂ€nder med tvĂ„l).
Vi "överlevde" som resultat flera interna analysprojekt som aktivt anvĂ€nde Apache Spark (inklusive Spark Streaming, Spark SQL) och Hadoop-ekosystemet (och sĂ„ vidare). Trots att vi med tiden lĂ€rde oss att "lagra" detta ganska vĂ€l och övervaka det, och "det" slutade praktiskt taget att plötsligt krascha pĂ„ grund av förĂ€ndringar i datakaraktĂ€ren och obalanserat jĂ€mnt hashning av RDD, blev lusten att fĂ„ nĂ„got fĂ€rdigt, uppdaterat och administrerat nĂ„gonstans i molnet allt starkare. Det var vid den tiden vi försökte anvĂ€nda en fĂ€rdig molnbaserad sammansĂ€ttning frĂ„n Amazon Web Services â och försökte dĂ€refter lösa uppgifter pĂ„ den. EMR Ă€r Amazons beredda Apache Spark med extra mjukvara frĂ„n ekosystemet, ungefĂ€r som Cloudera/Hortonworks-sammansĂ€ttningar.
Ett "gummiband" filsystem för analys â ett akut behov
Erfarenheten av att "lagra" Hadoop/Spark med brÀnnskador pÄ olika kroppsdelar har inte varit förgÀves. Behovet av att skapa ett enhetligt, kostnadseffektivt och pÄlitligt filsystem, som Àr motstÄndskraftigt mot hÄrdvarufel och dÀr man kan lagra filer i olika format frÄn olika system och göra effektiva och rimligt snabba urval av data för rapporter, har blivit allt tydligare.
Jag skulle ocksÄ vilja att programuppdateringen för denna plattform inte ska bli en mardröm likt en nyÄrsnatt, dÀr man stÄr och lÀser 20-sidiga Java-traces och analyserar kilometers lÄnga loggar frÄn klustret med hjÀlp av Spark History Server och ett förstoringsglas med belysning. Jag önskar mig ett enkelt och transparent verktyg som inte krÀver att man regelbundet dyker ner under huven, om en utvecklare inte lÀngre kan köra en standard MapReduce-frÄga pÄ grund av att arbetsminnet för reduce-data försvinner vid ett dÄligt valt partitionsalgoritm för de ursprungliga datan.
Ăr Amazon S3 en kandidat för DataLake?
Erfarenheten av att arbeta med Hadoop/MapReduce har lÀrt mig att det behövs ett skalbart och pÄlitligt filsystem, samt skalbara arbetare som "kommer" nÀrmare datan för att undvika att flytta data över nÀtverket. Arbetskraften mÄste kunna lÀsa data i olika format, men helst inte lÀsa onödig information och att man i förvÀg kan lagra data i format som Àr bekvÀma för arbetarna.
Ă terigen â huvudidĂ©n. Det finns ingen vilja att "lasta upp" stora data till en enda klusteranalysmotor som förr eller senare Ă€ndĂ„ kommer att sjunka och som mĂ„ste shardas pĂ„ ett fult sĂ€tt. Jag vill lagra filer, bara filer, i ett begripligt format och utföra effektiva analytiska frĂ„gor pĂ„ dem med olika, men begripliga verktyg. Och antalet filer i olika format kommer bara att öka. Det Ă€r bĂ€ttre att shard data snarare Ă€n motorn. Vi behöver en skalbar och universell DataLake, beslutade vi...
Vad hÀnder om vi lagrar filer i det vÀlkÀnda och mÄnga kÀnner till det skalbara molnlagringssystemet Amazon S3, istÀllet för att bryta ner det med Hadoop?
SjÀlvklart kan vi inte anvÀnda personuppgifter, men vad om vi flyttar andra data dit och "effektivt hanterar" dem?
Klyster-biggdata-analytisk ekosystem av Amazon Web Services â med mycket enkla ord
Enligt vÄr erfarenhet av att arbeta med AWS anvÀnds Apache Hadoop/MapReduce aktivt dÀr under olika former, till exempel i tjÀnsten DataPipeline (jag avundas mina kollegor som verkligen har lÀrt sig att förbereda den korrekt). HÀr har vi stÀllt in backup frÄn olika tjÀnster frÄn tabeller i DynamoDB:
Och de körs regelbundet pÄ inbyggda kluster av Hadoop/MapReduce som urverk redan i flera Är. "StÀll in och glöm":
Dessutom kan man effektivt syssla med datastanism genom att lansera Jupiter-notebooks i molnet för analytiker och anvÀnda dem för trÀning och driftsÀttning av AI-modeller i AWS SageMaker. SÄ hÀr ser det ut hos oss:
Och ja, man kan lansera en notebook i molnet för sig sjÀlv eller för analytikerna och koppla den till ett Hadoop/Spark-kluster, rÀkna och sedan 'spika' allt:
Det Àr verkligen bekvÀmt för enskilda analytiska projekt, och för vissa har vi framgÄngsrikt anvÀnt EMR-tjÀnsten för storskaliga berÀkningar och analyser. Men hur stÄr det till med ett systemlösning för DataLake, kommer det att fungera? Vid den tiden var vi pÄ grÀnsen mellan hopp och förtvivlan och fortsatte att söka.
AWS Glue â snyggt paketerad Apache Spark 'pĂ„ steroider'
Det visade sig att AWS har sin "egna" version av stacken "Hive/Pig/Spark". Hive:s roll, dvs. filkatalogen och dess typer i DataLake, utförs av tjÀnsten "Data catalog", som inte döljer sin kompatibilitet med formatet Apache Hive. I denna tjÀnst behöver man lÀgga till information om var dina filer ligger och vilket format de Àr i. Data kan ligga inte bara i s3, utan ocksÄ i en databas, men det Àr inte temat för detta inlÀgg. SÄ hÀr Àr vÄr data katalog för DataLake organiserad:
Filerna Ă€r registrerade, utmĂ€rkt. Om filerna har uppdaterats â startar vi antingen manuellt eller schemalagt crawlers som uppdaterar informationen om dem frĂ„n sjön och sparar. DĂ€refter kan data frĂ„n sjön bearbetas och resultaten exporteras nĂ„gonstans. I det enklaste fallet â exporteras ocksĂ„ till s3. Data kan bearbetas var som helst, men man föreslĂ„r att stĂ€lla in bearbetningsprocessen pĂ„ ett Apache Spark-kluster med utökade möjligheter genom AWS Glue API. I grund och botten kan man ta den gamla, kĂ€ra och vanliga koden i python med hjĂ€lp av biblioteket pyspark och stĂ€lla in dess körning pĂ„ N noder i ett kluster av viss kapacitet med övervakning, utan att grĂ€va i Hadoop:s inre och dra runt med docker-mock-kontainrar och lösa beroendeproblem.
Ă terigen â en enkel idĂ©. Det behövs ingen konfiguration av Apache Spark, man behöver bara skriva kod i python för pyspark, testa den lokalt pĂ„ skrivbordet och sedan köra den pĂ„ ett stort kluster i molnet, ange var de ursprungliga data ligger och var resultatet ska lĂ€ggas. Ibland Ă€r det behövligt och anvĂ€ndbart, och sĂ„ hĂ€r Ă€r det konfigurerat hos oss:
SĂ„, om man behöver göra berĂ€kningar pĂ„ Spark-klustret med data i s3 â skriver man kod i python/pyspark, testar och sen Ă€r det fritt fram till molnet.
Och hur stÄr det till med orkestreringen? Och om en uppgift faller bort? Ja, det föreslÄs att man gör en vacker pipeline i stil med Apache Pig och vi har till och med testat dem, men vi har valt att anvÀnda vÄr djupt anpassade orkestrering i PHP och JavaScript för tillfÀllet (jag förstÄr att detta kan skapa kognitiv dissonans, men det fungerar, Är efter Är utan fel).
Formatet pÄ de filer som lagras i sjön Àr nyckeln till prestanda
Det Àr mycket, mycket viktigt att förstÄ ytterligare tvÄ nyckelpunkter. För att dataförfrÄgningarna för filerna i sjön ska utföras sÄ snabbt som möjligt och för att prestandan inte ska försÀmras vid tillÀgg av ny information, mÄste man:
- Lagra kolumnerna i filerna separat (sÄ att man inte behöver lÀsa alla rader för att förstÄ vad som finns i kolumnerna). För detta har vi valt parquet-formatet med komprimering.
- Det Àr ocksÄ viktigt att shardera filerna i mappar i stil med: sprÄk, Är, mÄnad, dag, vecka. Motorer som förstÄr denna typ av sharding kommer endast att titta i de relevanta mapparna, utan att behöva grÀva igenom all data.
I grunden lĂ€gger ni pĂ„ det mest effektiva sĂ€ttet av de ursprungliga data för de analytiska motorer som kan gĂ„ selektivt in i de sharderade mapparna och lĂ€sa endast de nödvĂ€ndiga kolumnerna frĂ„n filerna. Ni behöver inte "ladda" data nĂ„gonstans (lagringen kommer att spricka) â bara lĂ€gg dem direkt smart i filsystemet i rĂ€tt format. SjĂ€lvklart ska det stĂ„ klart att det inte Ă€r sĂ€rskilt förnuftigt att lagra en stor csv-fil i DataLake, som först mĂ„ste lĂ€sas rad för rad av kluster för att extrahera kolumnerna â tĂ€nk pĂ„ de tvĂ„ ovan nĂ€mnda punkterna en gĂ„ng till om det Ă€r oklart varför allt detta.
AWS Athena â en "djĂ€vul" ur lĂ„dan
Och hÀr, nÀr vi skapar en sjö, snubblar vi förbi Amazon Athena. Plötsligt visar det sig att om man ordentligt lÀgger vÄra stora loggfiler i sharderade mappar i rÀtt (parquet) kolumnformat, kan man mycket snabbt göra extremt informativa urval och skapa rapporter UTAN, utan Apache Spark/Glue-kluster.
Athena-motorn, som arbetar med data i s3, Ă€r baserad pĂ„ den legendariska â en representant av MPP (massive parallel processing) familjen av databehandlingsmetoder som hĂ€mtar data dĂ€r den finns, frĂ„n S3 och Hadoop till Cassandra och vanliga textfiler. Man behöver bara be Athena att köra en SQL-frĂ„ga, och sedan "fungerar allt snabbt och av sig sjĂ€lv". Det Ă€r vĂ€rt att notera att Athena Ă€r "intelligent", gĂ„r bara till de nödvĂ€ndiga sharderade mapparna och lĂ€ser bara de kolumner som efterfrĂ„gas.
Priser för förfrÄgningar till Athena Àr ocksÄ intressanta. Vi betalar för . Det vill sÀga, inte för antalet maskiner i klustret per minut, utan... för de data som faktiskt har skannats pÄ 100-500 maskiner som behövs för att utföra förfrÄgan.
Genom att endast begÀra de nödvÀndiga kolumnerna frÄn rÀtt shardade mappar visade det sig att tjÀnsten Athena kostar oss nÄgra tiotals dollar per mÄnad. VÀldigt bra, nÀstan gratis, jÀmfört med analys pÄ kluster!
SÄ hÀr shardas vÄra data i S3:
Som ett resultat, pÄ kort tid, började helt olika avdelningar inom företaget, frÄn informationssÀkerhet till analys, aktivt göra förfrÄgningar till Athena och snabbt, pÄ sekunder, fÄ anvÀndbara svar frÄn "big data" för ganska lÄnga perioder: mÄnader, halvÄr och sÄ vidare.
Men vi gick vidare och började hÀmta svar i molnet : en analytiker skriver en SQL-frÄga i sin vanliga konsol, som "för en spottstyver" skannar data i S3 med 100-500 maskiner och ger tillbaka svaret vanligtvis pÄ nÄgra sekunder. BekvÀmt. Och snabbt. Det Àr fortfarande svÄrt att tro.
I slutĂ€ndan, efter att ha beslutat att lagra data i S3, i ett effektivt kolumnformat och med rimlig shardning av data i mappar... fick vi en DataLake och en snabb och billig analytisk motor â gratis. Den blev mycket populĂ€r inom företaget, eftersom den förstĂ„r SQL och arbetar mĂ„nga gĂ„nger snabbare Ă€n genom start/stopp/instĂ€llningar av kluster. "Och om resultatet Ă€r detsamma, varför betala mer?"
En förfrÄgan till Athena ser ut ungefÀr sÄ hÀr. Om sÄ önskas kan man givetvis formulera en ganska , men vi nöjer oss med en enkel gruppering. LÄt oss se vilka svarskoder kunden hade för nÄgra veckor sedan i loggarna frÄn webbserverns arbete och bekrÀfta att det inte finns nÄgra fel:
Slutsatser
Efter att ha gÄtt en vÀg som visserligen inte varit lÄng men smÀrtsam, dÀr vi stÀndigt har bedömt risker, svÄrighetsgrad och kostnad för stöd, har vi hittat en lösning för DataLake och analys som fortsÀtter att glÀdja oss bÄde med sin hastighet och Àgandekostnad.
Det visade sig att det Àr helt möjligt att bygga en effektiv, snabb och kostnadseffektiv DataLake för behoven hos helt olika avdelningar inom företaget, Àven för erfarna utvecklare som aldrig har arbetat som arkitekter och som inte kan rita fyrkanter och pilar, trots att de kÀnner till 50 termer inom Hadoop-ekosystemet.
I början av resan hade jag huvudvĂ€rk av de mĂ„nga galna zoos med öppen och stĂ€ngd programvara och ansvarskĂ€nslan gentemot framtida generationer. Börja helt enkelt bygga din DataLake med enkla verktyg: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3 âŠ, samla feedback och förstĂ„ de fysiska processerna djupt. Allt som Ă€r komplicerat och oklart â lĂ€mna Ă„t fiender och konkurrenter.
Om du inte vill anvÀnda molnet och Àlskar att stödja, uppdatera och patcha öppna projekt kan du bygga ett liknande system lokalt pÄ billiga kontorsmaskiner med Hadoop och Presto ovanpÄ. Huvudsaken Àr att inte stanna upp utan fortsÀtta framÄt, rÀkna, leta efter enkla och klara lösningar, sÄ kommer allt att ordna sig! Lycka till alla och vi ses snart igen!
KĂ€lla: habr.com
