Wy libje yn in geweldige tiid wêryn jo fluch en maklik ferskate klearmakke iepen boarne-ark kinne ferbine, se ynstelle mei jo "bewustwêzen útskeakele" neffens it advys fan stackoverflow, sûnder te ferdjipjen yn 'e "meardere letters", en lansearje se yn kommersjele operaasje. En as jo moatte bywurkje / útwreidzje of immen per ongeluk in pear masines opnij opstart - jo realisearje dat der in soarte fan obsessive minne dream is begûn, alles is dramatysk yngewikkeld wurden sûnder werkenning, der is gjin weromkear, de takomst is vague en feiliger, ynstee fan programmearring, fokken bijen en do tsiis.
It is net foar neat dat mear betûfte kollega's, mei de holle besaaid mei bugs en dus al griis, de ongelooflijk snelle ynset fan pakken "containers" yn "kubes" op tsientallen servers yn "modieuze talen" mei ynboude stipe foar asynchrone net-blokkearjende I / O, glimkje beskieden. En se bliuwe stilend "man ps" opnij lêze, ferdjipje yn 'e "nginx" boarnekoade oant har eagen bloede, en skriuwe, skriuwe, skriuwe ienheidstests. Kollega's witte dat it meast nijsgjirrige ding sil komme as "dit alles" ien dei nachts op nijjiersnacht wurdt staked. En se sille allinich holpen wurde troch in djip begryp fan 'e aard fan unix, de memorisearre TCP / IP-statustabel en basis algoritmen foar sortearring-sykjen. Om it systeem wer ta libben te bringen as de klokken slaan.
Oh ja, ik waard in bytsje ôfliede, mar ik hoopje dat ik it slagge om de steat fan ferwachting oer te bringen.
Hjoed wol ik ús ûnderfining diele yn it ynsetten fan in handige en goedkeape stapel foar DataLake, dy't de mearderheid fan analytyske taken yn it bedriuw oplost foar folslein oare strukturele divyzjes.
In skoft lyn kamen wy ta it begryp dat bedriuwen hieltyd mear de fruchten nedich binne fan sawol produkt as technyske analytyk (om net te sprekken oer de kers op 'e taart yn' e foarm fan masine learen) en om trends en risiko's te begripen - wy moatte sammelje en analysearje mear en mear metrics.
Basis technyske analytyk yn Bitrix24
Ferskate jierren lyn, tagelyk mei de lansearring fan 'e Bitrix24-tsjinst, hawwe wy aktyf tiid en middels ynvestearre yn it meitsjen fan in ienfâldich en betrouber analytysk platfoarm dat soe helpe om fluch problemen yn' e ynfrastruktuer te sjen en de folgjende stap te plannen. Fansels wie it oan te rieden om klearmakke ark te nimmen dat sa ienfâldich en begryplik mooglik wie. As gefolch, nagios waard keazen foar tafersjoch en munin foar analytics en fisualisaasje. No hawwe wy tûzenen kontrôles yn nagios, hûnderten charts yn munin, en ús kollega's brûke se elke dei mei súkses. De metriken binne dúdlik, de grafiken binne dúdlik, it systeem wurket al ferskate jierren betrouber en der wurde geregeld nije tests en grafiken oan tafoege: as wy in nije tsjinst yn gebrûk meitsje, foegje wy ferskate tests en grafiken ta. Súkses.
Finger op 'e pols - Avansearre technyske analyze
De winsk om ynformaasje te krijen oer problemen "sa gau mooglik" late ús ta aktive eksperiminten mei ienfâldige en begryplike ark - pinba en xhprof.
Pinba stjoerde ús statistiken yn UDP-pakketten oer de snelheid fan wurking fan dielen fan websiden yn PHP, en wy koenen online sjen yn 'e MySQL-opslach (Pinba komt mei in eigen MySQL-motor foar rappe analyse fan eveneminten) in koarte list mei problemen en reagearje op harren. En xhprof hat ús automatysk tastien om grafiken te sammeljen fan 'e útfiering fan' e stadichste PHP-siden fan kliïnten en te analysearjen wat dit kin liede - rêstich, tee jitte of wat sterker.
In skoft lyn waard de toolkit oanfolle mei in oare frij ienfâldige en begryplike motor basearre op it omkearde yndeksearjende algoritme, perfekt ymplementearre yn 'e legindaryske Lucene-bibleteek - Elastic / Kibana. It ienfâldige idee fan multi-threaded opname fan dokuminten yn in omkearde Lucene-yndeks basearre op barrens yn 'e logs en in fluch sykjen troch har mei facetdieling die bliken echt nuttich te wêzen.
Nettsjinsteande it frijwat technyske uterlik fan fisualisaasjes yn Kibana mei begripen op leech nivo lykas "emmer" "oprinnend" en de opnij útfûne taal fan 'e noch net folslein fergetten relaasjealgebra, begon it ark ús goed te helpen yn' e folgjende taken:
- Hoefolle PHP-flaters hie de Bitrix24-kliïnt yn 'e lêste oere op it p1-portaal en hokker? Ferstean, ferjaan en fluch korrigearje.
- Hoefolle fideoproppen waarden yn 'e foargeande 24 oeren makke op portalen yn Dútslân, mei hokker kwaliteit en wiene d'r swierrichheden mei it kanaal / netwurk?
- Hoe goed wurket de systeemfunksjonaliteit (ús C-útwreiding foar PHP), gearstald út boarne yn 'e lêste tsjinstfernijing en útrol nei kliïnten? Binne der segfaults?
- Past klantgegevens yn PHP-ûnthâld? Binne d'r flaters oer it oertsjûgjen fan it ûnthâld dat is tawiisd oan prosessen: "út it ûnthâld"? Fyn en neutralisearje.
Hjir is in konkreet foarbyld. Nettsjinsteande yngeande testen op meardere nivo's krige de kliïnt, mei in heul net-standert saak en skansearre ynfiergegevens, in ferfelende en ûnferwachte flater, in sirene klonk en it proses om it fluch te reparearjen begon:
Derneist lit kibana jo notifikaasjes organisearje foar spesifisearre eveneminten, en yn in koarte tiid begon it ark yn it bedriuw te brûken troch tsientallen meiwurkers fan ferskate ôfdielingen - fan technyske stipe en ûntwikkeling oant QA.
De aktiviteit fan elke ôfdieling binnen it bedriuw is handich wurden om te folgjen en te mjitten - ynstee fan logs op servers manuell te analysearjen, moatte jo gewoan ien kear parsing-logs ynstelle en stjoere se nei it elastyske kluster om te genietsjen, bygelyks, te besjen yn 'e kibana dashboard it oantal ferkochte kittens mei twa hollen printe op 3-D printer foar de lêste moanne moanne.
Basic Business Analytics
Elkenien wit dat saaklike analytyk yn bedriuwen faak begjint mei ekstreem aktyf gebrûk fan, ja, Excel. Mar it wichtichste is dat it dêr net einiget. Wolken-basearre Google Analytics foeget ek brânstof ta oan it fjoer - jo begjinne gau te wennen oan it goede spul.
Yn ús harmonieus ûntwikkeljen bedriuw begûnen hjir en dêr "profeten" fan yntinsiver wurk mei gruttere gegevens te ferskinen. De needsaak foar mear yngeande en mearsidige rapporten begon regelmjittich te ferskinen, en troch de ynspanningen fan jonges út ferskate ôfdielingen waard in skoft lyn in ienfâldige en praktyske oplossing organisearre - in kombinaasje fan ClickHouse en PowerBI.
In hiel lange tiid holp dizze fleksibele oplossing in protte, mar stadichoan begon it begryp te kommen dat ClickHouse gjin rubber is en sa kin net bespot wurde.
Hjir is it wichtich om goed te begripen dat ClickHouse, lykas Druid, lykas Vertica, lykas Amazon RedShift (dy't basearre is op postgres), analytyske motoren binne optimalisearre foar frij handige analytiken (summen, aggregaasjes, minimum-maksimum per kolom en in pear mooglike joins) ), omdat organisearre foar effisjinte opslach fan kolommen fan relasjonele tabellen, yn tsjinstelling ta MySQL en oare (rige-rjochte) databases dy't ús bekend binne.
Yn essinsje is ClickHouse gewoan in rommere "database", mei net heul handige punt-foar-punt-ynfoegje (dat is hoe't it is bedoeld, alles is ok), mar noflike analytiken en in set fan nijsgjirrige krêftige funksjes foar it wurkjen mei gegevens. Ja, jo kinne sels in kluster meitsje - mar jo begripe dat it hammerjen fan spikers mei in mikroskoop net folslein korrekt is en wy begûnen te sykjen nei oare oplossingen.
Fraach nei python en analysts
Us bedriuw hat in protte ûntwikkelders dy't 10-20 jier hast elke dei koade skriuwe yn PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash. D'r binne ek in protte betûfte systeembehearders dy't mear as ien absolút ongelooflijke ramp meimakke hawwe dy't net passe yn 'e wetten fan statistiken (bygelyks as de mearderheid fan skiven yn in raid-10 wurdt ferneatige troch in sterke bliksem). Yn sokke omstannichheden wie it foar in lange tiid net dúdlik wat in "pythonanalytiker" wie. Python is lykas PHP, allinich de namme is wat langer en d'r binne wat minder spoaren fan geastferoarjende stoffen yn 'e boarnekoade fan' e tolk. Lykwols, as mear en mear analytyske rapporten waarden makke, betûfte ûntwikkelders begûn te begripen hieltyd mear it belang fan smelle spesjalisaasje yn ark lykas numpy, pandas, matplotlib, seaborn.
De beslissende rol, nei alle gedachten, waard spile troch de hommelse flauwjen fan meiwurkers út 'e kombinaasje fan' e wurden "logistyske regression" en de demonstraasje fan effektive rapportaazje oer grutte gegevens mei help fan, ja, ja, pyspark.
Apache Spark, har funksjonele paradigma wêrop relaasje algebra perfekt past, en har mooglikheden makken sa'n yndruk op ûntwikkelders dy't wend binne oan MySQL dat de needsaak om de rigen te fersterkjen mei betûfte analysten dúdlik waard as de dei.
Fierdere besykjen fan Apache Spark / Hadoop om ôf te nimmen en wat net hielendal gie neffens it skript
It waard lykwols al gau dúdlik dat der wat systemysk net hielendal goed wie mei Spark, of it wie gewoan nedich om de hannen better te waskjen. As de Hadoop/MapReduce/Lucene-stapel makke is troch frij betûfte programmeurs, wat fanselssprekkend is as jo goed nei de boarnekoade yn Java of de ideeën fan Doug Cutting yn Lucene sjogge, dan is Spark ynienen skreaun yn 'e eksoatyske taal Scala, dat is tige kontroversjeel út it eachpunt fan praktykens en is op it stuit net yn ûntwikkeling. En de reguliere delgong yn berekkeningen op 'e Spark-kluster troch ûnlogysk en net heul transparant wurk mei ûnthâldtawizing foar ferminderjen fan operaasjes (in protte kaaien komme tagelyk) hat in halo om it hinne makke fan eat dat romte hat om te groeien. Dêrnjonken waard de situaasje fergrutte troch in grut oantal frjemde iepen havens, tydlike bestannen dy't groeiden op 'e meast ûnbegryplike plakken en in hel fan jar-ôfhinklikens - wêrtroch't systeembehearders ien gefoel hawwe dat fan jongs ôf bekend wie: fûle haat (of miskien se moasten har hannen waskje mei sjippe).
As gefolch hawwe wy ferskate ynterne analytyske projekten "oerlibbe" dy't Apache Spark aktyf brûke (ynklusyf Spark Streaming, Spark SQL) en it Hadoop-ekosysteem (ensafuorthinne ensafuorthinne). Nettsjinsteande it feit dat wy yn 'e rin fan' e tiid learden om "it" goed te tarieden en te kontrolearjen, en "it" praktysk stoppe ynienen te crashen troch feroaringen yn 'e aard fan' e gegevens en it ûnbalâns fan unifoarme RDD-hashing, de winsk om wat al klear te nimmen , bywurke en administrearre earne yn 'e wolk groeide sterker en sterker. It wie op dit stuit dat wy besochten de klearmakke wolk-assemblage fan Amazon Web Services te brûken - en, letter, besocht te lossen problemen mei help fan it. EMR is Apache Spark taret troch Amazon mei ekstra software fan it ekosysteem, lykas Cloudera/Hortonworks builds.
Opslach fan rubberbestân foar analytiken is in driuwend ferlet
De ûnderfining fan "koken" Hadoop / Spark mei brânwûnen oan ferskate dielen fan it lichem wie net om 'e nocht. De needsaak om in inkele, goedkeape en betroubere bestân opslach te meitsjen dy't resistint wêze soe foar hardware-mislukkingen en wêryn it mooglik wêze soe om bestannen yn ferskate formaten fan ferskate systemen op te slaan en effisjinte en tiid-effisjinte samples te meitsjen foar rapporten fan dizze gegevens waard hieltyd mear opklearje.
Ik woe ek dat it bywurkjen fan de software fan dit platfoarm net feroare yn in nijjiersnachtmerje mei it lêzen fan 20-pagina Java-spoaren en it analysearjen fan kilometerlange detaillearre logs fan it kluster mei Spark History Server en in efterljochte fergrutglês. Ik woe in ienfâldich en transparant ark hawwe dat net regelmjittich dûke ûnder de motorkap nedich wie as it standert MapReduce-fersyk fan 'e ûntwikkelder stoppe út te fieren doe't de wurker fan' e fermindering fan gegevens út it ûnthâld foel troch in net heul goed keazen boarne data partitioning algoritme.
Is Amazon S3 in kandidaat foar DataLake?
Underfining mei Hadoop/MapReduce hat ús leard dat wy in skalberber, betrouber bestânsysteem nedich binne en skalberbere arbeiders boppe-op, "komme" tichter by de gegevens om de gegevens net oer it netwurk te riden. Arbeiders moatte gegevens yn ferskate formaten lêze kinne, mar leafst net oerstallige ynformaasje lêze en gegevens foarôf kinne opslaan yn formaten dy't handich binne foar arbeiders.
Nochris, it basis idee. D'r is gjin winsk om grutte gegevens yn in ienige kluster analytyske motor te "goaien", dy't ier of letter sil choke en jo sille it lelijk moatte sjitte. Ik wol bestannen opslaan, gewoan bestannen, yn in begryplik formaat en effektive analytyske fragen op har útfiere mei ferskate, mar begryplike ark. En d'r sille mear en mear bestannen yn ferskate formaten wêze. En it is better om net de motor te knipjen, mar de boarnegegevens. Wy hawwe in útwreide en universele DataLake nedich, besletten wy ...
Wat as jo bestannen opslaan yn 'e bekende en bekende skaalbere wolkopslach Amazon S3, sûnder jo eigen koteletten fan Hadoop te meitsjen?
It is dúdlik dat de persoanlike gegevens "leech" binne, mar hoe sit it mei oare gegevens as wy it derút nimme en "effektyf ride"?
Cluster-bigdata-analytics-ekosysteem fan Amazon Web Services - yn heul ienfâldige wurden
Nei ús ûnderfining mei AWS te oardieljen, wurdt Apache Hadoop/MapReduce dêr in lange tiid aktyf brûkt ûnder ferskate sauzen, bygelyks yn de DataPipeline-tsjinst (ik bin benijd op myn kollega's, se learden hoe't se it goed tariede). Hjir hawwe wy backups ynsteld fan ferskate tsjinsten fan DynamoDB-tabellen:
En se rinne al ferskate jierren regelmjittich op ynbêde Hadoop/MapReduce-klusters lykas klokwurk. "Set it en ferjit it":
Jo kinne ek effektyf meidwaan oan gegevens satanisme troch Jupiter-laptops yn 'e wolk yn te stellen foar analysten en de AWS SageMaker-tsjinst te brûken om AI-modellen te trenen en yn te setten yn 'e striid. Hjir is hoe't it der foar ús útsjocht:
En ja, jo kinne in laptop foar josels as in analist yn 'e wolk ophelje en it oan in Hadoop / Spark-kluster heakje, de berekkeningen dwaan en dan alles neilje:
Echt handich foar yndividuele analytyske projekten en foar guon hawwe wy de EMR-tsjinst mei súkses brûkt foar grutskalige berekkeningen en analytiken. Wat oer in systeemoplossing foar DataLake, sil it wurkje? Op dit stuit stiene wy op 'e râne fan hope en wanhoop en gongen it sykjen troch.
AWS Glue - netjes ferpakt Apache Spark op steroïden
It die bliken dat AWS in eigen ferzje hat fan 'e stapel "Hive / Pig / Spark". De rol fan Hive, d.w.s. De katalogus fan bestannen en har typen yn DataLake wurdt útfierd troch de tsjinst "Datacatalogus", dy't syn kompatibiliteit net ferberget mei it Apache Hive-formaat. Jo moatte ynformaasje tafoegje oan dizze tsjinst oer wêr't jo bestannen lizze en yn hokker formaat se binne. De gegevens kinne net allinnich yn s3, mar ek yn 'e databank, mar dat is net it ûnderwerp fan dizze post. Hjir is hoe't ús DataLake-gegevensmap is organisearre:
De bestannen binne registrearre, geweldich. As de bestannen binne bywurke, lansearje wy crawlers of mei de hân of op in skema, dy't ynformaasje oer har bywurkje fan 'e mar en bewarje se. Dan kinne de gegevens fan de mar ferwurke wurde en de resultaten earne opladen wurde. Yn it ienfâldichste gefal uploade wy ek nei s3. Gegevensferwurking kin oeral dien wurde, mar it wurdt suggerearre dat jo de ferwurking ynstelle op in Apache Spark-kluster mei avansearre mooglikheden fia de AWS Glue API. Yn feite kinne jo de goede âlde en fertroude python-koade nimme mei de pyspark-bibleteek en de útfiering dêrfan konfigurearje op N knopen fan in kluster fan wat kapasiteit mei tafersjoch, sûnder te graven yn 'e yngewanten fan Hadoop en docker-smoker-konteners te slepen en ôfhinklikenskonflikten te eliminearjen .
Nochris in ienfâldich idee. D'r is gjin need om Apache Spark te konfigurearjen, jo moatte gewoan python-koade foar pyspark skriuwe, it lokaal op jo buroblêd testje en it dan útfiere op in grut kluster yn 'e wolk, spesifisearje wêr't de boarnegegevens binne en wêr't it resultaat te pleatsen. Soms is dit needsaaklik en nuttich, en hjir is hoe't wy it ynstelle:
Dus, as jo wat moatte berekkenje op in Spark-kluster mei gegevens yn s3, skriuwe wy koade yn python/pyspark, test it, en goed gelok foar de wolk.
Hoe sit it mei de orkestraasje? Wat as de taak foel en ferdwûn? Ja, it wurdt foarsteld om in prachtige pipeline te meitsjen yn 'e Apache Pig-styl en wy hawwe se sels besocht, mar foar no hawwe wy besletten om ús djip oanpaste orkestraasje te brûken yn PHP en JavaScript (ik begryp, d'r is kognitive dissonânsje, mar it wurket, foar jier en sûnder flaters).
It formaat fan bestannen opslein yn 'e mar is de kaai foar prestaasjes
It is heul, heul wichtich om noch twa wichtige punten te begripen. Om fragen oer bestângegevens yn 'e mar sa rap mooglik út te fieren en prestaasjes net te degradearjen as nije ynformaasje wurdt tafoege, moatte jo:
- Bewarje kolommen fan bestannen apart (sadat jo net alle rigels hoege te lêzen om te begripen wat yn 'e kolommen stiet). Dêrfoar namen wy it parketformaat mei kompresje
- It is heul wichtich om bestannen yn mappen te splitsen lykas: taal, jier, moanne, dei, wike. Motoren dy't dit soarte fan sharding begripe, sille allinich nei de nedige mappen sjen, sûnder alle gegevens op in rige te siften.
Yn essinsje lizze jo op dizze manier de boarnegegevens yn 'e meast effisjinte foarm foar de analytyske motoren dy't boppe hingje, dy't sels yn skerpe mappen selektyf allinich de nedige kolommen fan bestannen kinne ynfiere en lêze. Jo hoege de gegevens net oeral te "folje" (de opslach sil gewoan barste) - set it gewoan fuortendaliks yn it bestânsysteem yn it juste formaat. Fansels moat it hjir dúdlik wêze dat it opslaan fan in enoarm csv-bestân yn DataLake, dat earst rigel foar rigel lêzen wurde moat troch it kluster om de kolommen te ekstrahearjen, net heul oan te rieden is. Tink nochris oer de boppesteande twa punten as it noch net dúdlik is wêrom dat allegear bart.
AWS Athena - de jack-in-the-box
En doe, by it meitsjen fan in mar, kamen wy op ien of oare manier per ongeluk Amazon Athena tsjin. Ynienen die bliken dat jo troch ús enoarme logbestannen foarsichtich te regeljen yn map-shards yn it juste (parket)kolomformaat, jo heul fluch ekstreem ynformative seleksjes fan kinne meitsje en rapporten Sûnder bouwe kinne, sûnder in Apache Spark/Glue-kluster.
De Athena-motor oandreaun troch gegevens yn s3 is basearre op de legindaryske - in fertsjintwurdiger fan 'e MPP-famylje (massive parallelle ferwurking) fan oanpak foar gegevensferwurking, it nimmen fan gegevens wêr't it leit, fan s3 en Hadoop oant Cassandra en gewoane tekstbestannen. Jo moatte Athena gewoan freegje om in SQL-query út te fieren, en dan wurket alles "rap en automatysk." It is wichtich om te notearjen dat Athena "tûk" is, it giet allinich nei de nedige skerpe mappen en lêst allinich de kolommen dy't nedich binne yn it fersyk.
De prizen foar oanfragen oan Athena binne ek ynteressant. Wy betelje foar . Dy. net foar it oantal masines yn it kluster per minút, mar ... foar de gegevens dy't eins scand binne op 100-500 masines, allinich de gegevens dy't nedich binne om it fersyk te foltôgjen.
En troch allinich de nedige kolommen oan te freegjen fan juste skerpe mappen, die bliken dat de Athena-tsjinst ús tsientallen dollars yn 'e moanne kostet. No, geweldich, hast fergees, fergelike mei analytiken op klusters!
Trouwens, hjir is hoe't wy ús gegevens yn s3 sjitte:
As gefolch, yn koarte tiid folslein ferskillende ôfdielingen yn it bedriuw, fan ynformaasjefeiligens oant analytyk, begon aktyf oanfragen oan Athena te meitsjen en fluch, yn sekonden, nuttige antwurden te ûntfangen fan "grutte" gegevens oer frij lange perioaden: moannen, in heal jier, ensfh. P.
Mar wy gongen fierder en begûnen te gean nei de wolk foar antwurden : in analist skriuwt in SQL-fraach yn in bekende konsole, dy't op 100-500 masines "foar pennies" gegevens stjoert nei s3 en jout in antwurd meastentiids yn in pear sekonden. Komfortabel. En fluch. Ik kin it noch net leauwe.
As gefolch hawwe wy besletten om gegevens op te slaan yn s3, yn in effisjint kolomformaat en mei ridlike sharding fan gegevens yn mappen ... wy krigen DataLake en in flugge en goedkeap analytyske motor - fergees. En hy waard tige populêr yn it bedriuw, omdat... begrypt SQL en wurket oarders fan grutte flugger as troch te begjinnen / stopjen / opsetten fan klusters. "En as it resultaat itselde is, wêrom dan mear betelje?"
In fersyk oan Athena sjocht der sa út. As jo wolle, kinne jo fansels genôch foarmje , mar wy sille ús beheine ta ienfâldige groepearring. Litte wy sjen hokker antwurdkoades de kliïnt in pear wike lyn hie yn 'e webserverlogs en soargje derfoar dat d'r gjin flaters binne:
befinings
Nei't wy trochgien binne, om net te sizzen in lang, mar pynlik paad, konstant adekwaat beoardielje de risiko's en it nivo fan kompleksiteit en kosten fan stipe, wy fûnen in oplossing foar DataLake en analytics dy't nea ophâldt te behagen ús mei sawol snelheid as kosten fan eigendom.
It die bliken dat it bouwen fan in effektyf, fluch en goedkeap te operearjen DataLake foar de behoeften fan folslein ferskillende ôfdielingen fan it bedriuw folslein binnen de mooglikheden is fan sels betûfte ûntwikkelders dy't noait as arsjitekten wurke hawwe en net witte hoe't se kwadraten op pleinen tekenje mei pylken en kenne 50 termen út it Hadoop-ekosysteem.
Oan it begjin fan 'e reis wie myn holle splitst fan' e protte wylde bistenparken fan iepen en sletten software en it begryp fan 'e lêst fan ferantwurdlikens foar neiteam. Begjin gewoan mei it bouwen fan jo DataLake fan ienfâldige ark: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., sammelje feedback en djip begryp fan 'e fysika fan' e prosessen dy't plakfine. Alles kompleks en tsjuster - jou it oan fijannen en konkurrinten.
As jo net nei de wolk wolle en graach iepenboarneprojekten stypje, bywurkje en patchje, kinne jo lokaal in skema bouwe dat fergelykber is mei ús, op goedkeape kantoarmasines mei Hadoop en Presto boppe. It wichtichste ding is net te stopjen en foarút te gean, rekkenje, sykje nei ienfâldige en dúdlike oplossingen, en alles sil perfoarst útkomme! Sterkte foar elkenien en oant sjen!
Boarne: www.habr.com