Gyvename nuostabiu laiku, kai galite greitai ir lengvai prijungti kelis paruoštus atvirojo kodo įrankius, nustatyti juos „išjungus sąmonę“ pagal „stackoverflow“ patarimą, nesigilindami į „kelias raides“ ir paleisti. pradėti komercinę veiklą. O kai reikia atnaujinti/išplėsti arba kažkas netyčia perkrauna porą mašinų – supranti, kad prasidėjo kažkoks įkyrus blogas sapnas, viskas dramatiškai susikomplikavo neatpažįstamai, kelio atgal nėra, ateitis miglota ir saugesnė, vietoj programavimo veiskite bites ir gaminkite sūrius.
Ne veltui labiau patyrę kolegos, kurių galvos išmargintos klaidų ir todėl jau pilkos, svarsto apie neįtikėtinai greitą „konteinerių“ paketų „kubeliais“ diegimą dešimtyse serverių „madingomis kalbomis“ su integruotu asinchroninis neblokuojantis I/O, kukliai šypsokis . Ir jie tyliai toliau skaito „man ps“, gilinasi į „nginx“ šaltinio kodą, kol akys kraujuoja, ir rašo, rašo, rašo vienetų testus. Kolegos žino, kad įdomiausia bus tada, kai „visa tai“ vieną dieną taps įkalta Naujųjų metų naktį. Ir jiems padės tik gilus unix prigimties supratimas, įsiminta TCP/IP būsenų lentelė ir pagrindiniai rūšiavimo-paieškos algoritmai. Sugrąžinti sistemą į gyvenimą, kai skamba varpeliai.
O taip, šiek tiek išsiblašiau, bet tikiuosi, kad pavyko perteikti laukimo būseną.
Šiandien noriu pasidalinti patirtimi diegiant patogų ir nebrangų DataLake stacką, kuris išsprendžia daugumą analitinių užduočių įmonėje visiškai skirtingiems struktūriniams padaliniams.
Prieš kurį laiką supratome, kad įmonėms vis labiau reikia tiek produktų, tiek techninės analitikos vaisių (jau nekalbant apie vyšnią ant torto mašininio mokymosi forma), o norint suprasti tendencijas ir rizikas – reikia rinkti ir analizuoti. vis daugiau metrikų.
Pagrindinė techninė analizė „Bitrix24“.
Prieš keletą metų, kartu su Bitrix24 paslaugos paleidimu, aktyviai investavome laiką ir resursus kurdami paprastą ir patikimą analitinę platformą, kuri padėtų greitai pamatyti infrastruktūros problemas ir planuoti kitą žingsnį. Žinoma, buvo patartina pasiimti paruoštas priemones, kurios būtų kuo paprastesnės ir suprantamesnės. Dėl to stebėjimui buvo pasirinktas nagios, o analitikai ir vizualizacijai – munin. Dabar turime tūkstančius čekių „Nagios“, šimtus diagramų „munin“, o mūsų kolegos jais sėkmingai naudojasi kasdien. Metrika aiški, grafikai aiškūs, sistema jau kelerius metus veikia patikimai, nuolat pridedami nauji testai ir grafikai: kai pradedame veikti nauja paslauga, pridedame kelis testus ir grafikus. Sėkmės.
Pirštas ant pulso – pažangi techninė analizė
Noras gauti informaciją apie problemas „kuo greičiau“ paskatino mus aktyviai eksperimentuoti su paprastais ir suprantamais įrankiais - pinba ir xhprof.
Pinba atsiuntė mums statistiką UDP paketais apie interneto puslapių dalių veikimo greitį PHP, o mes matėme internete MySQL saugykloje (Pinba turi savo MySQL variklį greitam įvykių analizei) trumpą problemų sąrašą ir reaguoti į juos. O xhprof automatiškai leido iš klientų rinkti lėčiausių PHP puslapių vykdymo grafikus ir analizuoti, kas gali iki to privesti – ramiai, pilant arbatą ar ką nors stipresnio.
Prieš kurį laiką įrankių rinkinys buvo papildytas dar vienu gana paprastu ir suprantamu varikliu, paremtu atvirkštinio indeksavimo algoritmu, puikiai įdiegtu legendinėje Lucene bibliotekoje – Elastic/Kibana. Paprasta kelių gijų dokumentų įrašymo į atvirkštinį Lucene indeksą, pagrįstą įvykiais žurnaluose, idėja ir greita paieška juose naudojant aspektų padalijimą pasirodė tikrai naudinga.
Nepaisant gana techninės vizualizacijų išvaizdos Kibanoje su žemo lygio sąvokomis, tokiomis kaip „kibiras“, „tekantis aukštyn“, ir iš naujo išrasta dar ne visiškai pamirštos reliacinės algebros kalba, įrankis pradėjo mums puikiai padėti atliekant šias užduotis:
- Kiek PHP klaidų Bitrix24 klientas turėjo p1 portale per paskutinę valandą ir kokių? Suprask, atleisk ir greitai pataisyk.
- Kiek per pastarąsias 24 valandas per pastarąsias XNUMX valandas buvo skambinta į portalus Vokietijoje, kokia kokybe ir ar buvo kokių nors sunkumų su kanalu/tinklu?
- Kaip gerai veikia sistemos funkcionalumas (mūsų C plėtinys, skirtas PHP), sudarytas iš šaltinio naujausiame paslaugos naujinime ir pristatytas klientams? Ar yra gedimų?
- Ar klientų duomenys telpa į PHP atmintį? Ar yra klaidų, viršijančių procesams skirtą atmintį: „neužtenka atminties“? Raskite ir neutralizuokite.
Štai konkretus pavyzdys. Nepaisant kruopštaus ir kelių lygių testavimo, klientas su labai nestandartiniu korpusu ir sugadintais įvesties duomenimis gavo erzinančią ir netikėtą klaidą, suskambo sirena ir prasidėjo greitas jos taisymo procesas:
Be to, kibana leidžia organizuoti pranešimus apie nurodytus įvykius, o per trumpą laiką įmonėje esančiu įrankiu pradėjo naudotis dešimtys darbuotojų iš skirtingų padalinių – nuo techninio palaikymo ir plėtros iki kokybės užtikrinimo.
Bet kurio įmonės padalinio veiklą tapo patogu sekti ir matuoti – užuot rankiniu būdu analizuojant žurnalus serveriuose, tereikia vieną kartą nustatyti analizavimo žurnalus ir nusiųsti juos į elastingą klasterį, kad galėtumėte mėgautis, pavyzdžiui, mąstyti kibanoje. prietaisų skydelyje – parduotų dvigalvių kačiukų skaičius, atspausdintas 3D spausdintuvu per paskutinį mėnulio mėnesį.
Pagrindinė verslo analizė
Visi žino, kad verslo analitika įmonėse dažnai prasideda nuo itin aktyvaus, taip, Excel naudojimo. Bet svarbiausia, kad viskas tuo nesibaigtų. Debesis pagrįsta „Google Analytics“ taip pat įpila žibalo į ugnį – greitai pradedate priprasti prie gerų dalykų.
Mūsų darniai besivystančioje įmonėje šen bei ten ėmė pasirodyti intensyvesnio darbo su didesniais duomenimis „pranašai“. Nuolat ėmė atsirasti nuodugnesnių ir įvairesnių ataskaitų poreikis, o vaikinų iš skirtingų padalinių pastangomis prieš kurį laiką buvo suorganizuotas paprastas ir praktiškas sprendimas – ClickHouse ir PowerBI derinys.
Gana ilgą laiką šis lankstus sprendimas labai padėjo, bet pamažu ėmė aiškėti supratimas, kad ClickHouse nėra guminis ir iš jo taip tyčiotis negalima.
Čia svarbu gerai suprasti, kad ClickHouse, kaip Druid, kaip Vertica, kaip Amazon RedShift (kuris pagrįstas postgres), yra analitiniai varikliai, optimizuoti gana patogiai analizei (sumos, agregacijos, minimumas-maksimumas pagal stulpelius ir keletas galimų sujungimų). ), nes organizuotas efektyviam reliacinių lentelių stulpelių saugojimui, skirtingai nei MySQL ir kitos mums žinomos (į eilutes orientuotos) duomenų bazės.
Iš esmės ClickHouse tėra talpesnė „duomenų bazė“, su ne itin patogiu taškiniu įterpimu (taip ir skirta, viskas ok), bet malonia analitika ir aibė įdomių galingų funkcijų darbui su duomenimis. Taip, jūs netgi galite sukurti klasterį, bet jūs suprantate, kad kalti vinis mikroskopu nėra visiškai teisinga ir pradėjome ieškoti kitų sprendimų.
Pitono ir analitikų paklausa
Mūsų įmonėje dirba daug kūrėjų, kurie beveik kasdien 10-20 metų rašo kodą PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash kalbomis. Taip pat yra daug patyrusių sistemų administratorių, patyrusių ne vieną absoliučiai neįtikėtiną nelaimę, kuri neatitinka statistikos dėsnių (pavyzdžiui, kai didžioji dalis „Raid-10“ diskų yra sunaikinta stipraus žaibo smūgio). Tokiomis aplinkybėmis ilgą laiką nebuvo aišku, kas yra „pitono analitikas“. Python yra kaip PHP, tik pavadinimas yra šiek tiek ilgesnis ir interpretatoriaus šaltinio kode yra šiek tiek mažiau protą keičiančių medžiagų pėdsakų. Tačiau, kai buvo kuriama vis daugiau analitinių ataskaitų, patyrę kūrėjai pradėjo vis labiau suprasti siauros specializacijos svarbą tokiose priemonėse kaip numpy, pandos, matplotlib, seaborn.
Labiausiai tikėtina, kad lemiamą vaidmenį suvaidino staigus darbuotojų alpimas nuo žodžių junginio „logistinė regresija“ ir efektyvaus didelių duomenų ataskaitų teikimo demonstravimas, naudojant, taip, taip, pyspark.
Apache Spark, jos funkcinė paradigma, kuriai puikiai tinka reliacinė algebra, ir jos galimybės padarė tokį įspūdį kūrėjams, pripratusiems prie MySQL, kad būtinybė sustiprinti gretas patyrusiais analitikais tapo aišku kaip diena.
Kiti „Apache Spark“ / „Hadoop“ bandymai pakilti ir kas nepavyko pagal scenarijų
Tačiau netrukus paaiškėjo, kad kažkas sistemiškai ne taip su Spark, arba tiesiog reikia geriau nusiplauti rankas. Jei Hadoop/MapReduce/Lucene steką sukūrė gana patyrę programuotojai, o tai akivaizdu, jei atidžiai pažvelgsite į šaltinio kodą Java arba Dougo Cuttingo idėjas Lucene, tai staiga Spark parašyta egzotiška kalba Scala, kuri yra labai prieštaringas praktiškumo požiūriu ir šiuo metu nevyksta. Reguliarus „Spark“ klasterio skaičiavimų sumažėjimas dėl nelogiško ir nelabai skaidraus darbo su atminties paskirstymu sumažinimo operacijoms (daug klavišų ateina vienu metu) aplink jį sukūrė aureolę to, kas turi kur augti. Be to, situaciją apsunkino daugybė keistų atvirų prievadų, nesuprantamose vietose augantys laikinieji failai ir velniava jar priklausomybės, dėl kurių sistemos administratoriai apėmė vieną nuo vaikystės gerai žinomą jausmą: nuožmią neapykantą (o gal jiems reikėjo nusiplauti rankas su muilu).
Dėl to „išgyvenome“ keletą vidinių analitinių projektų, kuriuose aktyviai naudojamas „Apache Spark“ (įskaitant „Spark Streaming“, „Spark SQL“) ir „Hadoop“ ekosistema (ir taip toliau ir pan.). Nepaisant to, kad laikui bėgant išmokome gana gerai „tai“ pasiruošti ir stebėti, o dėl duomenų pobūdžio pasikeitimų ir vienodos RDD maišos disbalanso „jis“ praktiškai nustojo staiga strigti, atsirado noras pasiimti ką nors jau paruošto. , atnaujinta ir administruojama kažkur debesyje, stiprėjo ir stiprėjo. Būtent tuo metu bandėme naudoti paruoštą „Amazon Web Services“ debesies rinkinį - ir vėliau bandė išspręsti problemas naudodamiesi juo. EMR yra „Apache Spark“, kurią parengė „Amazon“ su papildoma programine įranga iš ekosistemos, panašiai kaip „Cloudera“ / „Hortonworks“ versijos.
Gumos failų saugykla analizei yra neatidėliotinas poreikis
Patirtis „virti“ Hadoop/Spark nudeginus įvairias kūno vietas nenuėjo veltui. Vis labiau iškilo poreikis sukurti vieną, nebrangią ir patikimą failų saugyklą, kuri būtų atspari aparatūros gedimams ir kurioje būtų galima saugoti skirtingų formatų failus iš skirtingų sistemų ir iš šių duomenų daryti efektyvius ir efektyvius ataskaitų pavyzdžius. aišku.
Taip pat norėjau, kad šios platformos programinės įrangos atnaujinimas nevirstų naujametiniu košmaru perskaičius 20 puslapių Java pėdsakus ir analizuojant kilometrų ilgio detalius klasterio žurnalus naudojant Spark History Server ir apšviestą didinamąjį stiklą. Norėjau turėti paprastą ir skaidrų įrankį, kuriam nereikėtų reguliariai nardyti po gaubtu, jei kūrėjo standartinė MapReduce užklausa nustotų vykdyti, kai duomenų mažinimo darbuotojas iškrito iš atminties dėl nelabai gerai pasirinkto šaltinio duomenų skaidymo algoritmo.
Ar „Amazon S3“ yra „DataLake“ kandidatas?
Patirtis su „Hadoop“ / „MapReduce“ išmokė mus, kad mums reikia keičiamo dydžio, patikimos failų sistemos ir keičiamo dydžio darbuotojų, kurie „priartėtų“ prie duomenų, kad nebūtų perduodami duomenys tinkle. Darbuotojai turėtų turėti galimybę skaityti duomenis įvairiais formatais, bet pageidautina neskaityti nereikalingos informacijos ir turėti galimybę iš anksto saugoti duomenis darbuotojams patogiais formatais.
Dar kartą pagrindinė mintis. Nėra noro „pilti“ didelių duomenų į vieną klasterinį analitinį variklį, kuris anksčiau ar vėliau užsprings ir teks negražiai suskaldyti. Noriu saugoti failus, tik failus, suprantamu formatu ir atlikti efektyvias analitines užklausas naudojant skirtingus, bet suprantamus įrankius. Ir bus vis daugiau įvairių formatų failų. Ir geriau susmulkinti ne variklį, o šaltinio duomenis. Mums reikia išplečiamo ir universalaus DataLake, nusprendėme...
Ką daryti, jei failus saugote žinomoje ir gerai žinomoje keičiamo dydžio debesies saugykloje „Amazon S3“, nereikės ruošti savo kotletų iš „Hadoop“?
Akivaizdu, kad asmens duomenų yra „mažas“, bet ką daryti su kitais duomenimis, jei juos išimsime ir „efektyviai valdysime“?
„Amazon Web Services“ klasterio-bigdata-analytics ekosistema – labai paprastais žodžiais
Sprendžiant iš mūsų patirties su AWS, ten Apache Hadoop/MapReduce jau seniai aktyviai naudojamas po įvairiais padažais, pavyzdžiui, DataPipeline servise (pavydžiu kolegoms, išmoko teisingai paruošti). Čia nustatome atsargines kopijas iš skirtingų paslaugų iš „DynamoDB“ lentelių:
Ir jie jau keletą metų reguliariai veikia įterptosiose „Hadoop“ / „MapReduce“ grupėse, kaip laikrodis. „Nustatykite ir pamirškite“:
Taip pat galite efektyviai įsitraukti į duomenų satanizmą, analitikams debesyje nustatydami Jupiter nešiojamuosius kompiuterius ir naudodami AWS SageMaker paslaugą mokydami ir diegdami dirbtinio intelekto modelius kovoje. Štai kaip mums tai atrodo:
Taip, galite pasiimti nešiojamąjį kompiuterį sau arba analitikui debesyje ir prijungti jį prie „Hadoop“ / „Spark“ klasterio, atlikti skaičiavimus ir viską nustatyti:
Tikrai patogu individualiems analitiniams projektams, o kai kuriems sėkmingai naudojome EMR paslaugą didelės apimties skaičiavimams ir analizei. O kaip su DataLake sistemos sprendimu, ar jis veiks? Šiuo metu buvome ant vilties ir nevilties slenksčio ir tęsėme paieškas.
AWS klijai – tvarkingai supakuoti Apache Spark ant steroidų
Paaiškėjo, kad AWS turi savo „Hive/Pig/Spark“ kamino versiją. Avilio vaidmuo, t.y. Failų ir jų tipų katalogą „DataLake“ atlieka „Duomenų katalogo“ paslauga, kuri neslepia savo suderinamumo su „Apache Hive“ formatu. Prie šios paslaugos turite pridėti informacijos apie tai, kur yra jūsų failai ir kokiu formatu jie yra. Duomenys gali būti ne tik s3, bet ir duomenų bazėje, tačiau tai nėra šio įrašo tema. Štai kaip sutvarkytas mūsų DataLake duomenų katalogas:
Failai registruoti, puiku. Jei failai buvo atnaujinti, rankiniu būdu arba pagal grafiką paleidžiame skaitytuvus, kurie atnaujins informaciją apie juos iš ežero ir išsaugos. Tada duomenis iš ežero galima apdoroti ir rezultatus kažkur įkelti. Paprasčiausiu atveju taip pat įkeliame į s3. Duomenų apdorojimas gali būti atliekamas bet kur, tačiau rekomenduojama sukonfigūruoti apdorojimą „Apache Spark“ klasteryje naudojant išplėstines galimybes per AWS Glue API. Tiesą sakant, galite paimti seną gerą ir pažįstamą python kodą naudodami pyspark biblioteką ir konfigūruoti jo vykdymą N tam tikros talpos klasterio mazguose su stebėjimu, nesigilindami į „Hadoop“ gelmes ir netempdami dokerių-mokerių konteinerių ir nepašalindami priklausomybės konfliktų. .
Dar kartą paprasta mintis. Nereikia konfigūruoti Apache Spark, tereikia parašyti pyspark python kodą, išbandyti jį vietoje savo darbalaukyje ir tada paleisti dideliame debesies klasteryje, nurodant, kur yra šaltinio duomenys ir kur dėti rezultatą. Kartais tai būtina ir naudinga, o štai kaip mes tai nustatome:
Taigi, jei jums reikia ką nors apskaičiuoti „Spark“ klasteryje naudojant s3 duomenis, mes įrašome kodą į python / pyspark, išbandome jį ir linkime sėkmės debesyje.
O kaip su orkestravimu? O jei užduotis nukrito ir dingo? Taip, siūloma sukurti gražų „Apache Pig“ stiliaus dujotiekį ir mes juos net išbandėme, bet kol kas nusprendėme naudoti savo giliai pritaikytą orkestravimą PHP ir JavaScript (suprantu, yra kognityvinis disonansas, bet tai veikia, metų ir be klaidų).
Ežere saugomų failų formatas yra raktas į našumą
Labai labai svarbu suprasti dar du pagrindinius dalykus. Kad užklausos dėl failų duomenų ežere būtų įvykdytos kuo greičiau ir našumas nepablogėtų, kai pridedama nauja informacija, turite:
- Failų stulpelius saugokite atskirai (kad nereikėtų skaityti visų eilučių, kad suprastumėte, kas yra stulpeliuose). Tam paėmėme parketo formatą su kompresija
- Labai svarbu suskirstyti failus į tokius aplankus kaip: kalba, metai, mėnuo, diena, savaitė. Varikliai, kurie supranta tokio tipo skaidymą, žiūrės tik į reikiamus aplankus, neperžiūrėdami visų duomenų iš eilės.
Iš esmės tokiu būdu efektyviausia forma išdėliojate pirminius duomenis viršuje pakabintiems analitiniams sistemoms, kurie net ir susmulkintuose aplankuose gali pasirinktinai įvesti ir iš failų nuskaityti tik reikiamus stulpelius. Jums nereikia niekur „užpildyti“ duomenų (saugykla tiesiog sprogs) - tiesiog iš karto protingai įdėkite juos į failų sistemą tinkamu formatu. Žinoma, čia turėtų būti aišku, kad „DataLake“ saugoti didžiulį csv failą, kurį klasteris pirmiausia turi perskaityti eilutę po eilutės, norint išgauti stulpelius, nėra labai patartina. Dar kartą pagalvokite apie du minėtus dalykus, jei dar neaišku, kodėl visa tai vyksta.
AWS Athena – lizdas dėžutėje
Ir tada, kurdami ežerą, kažkaip netyčia atsidūrėme Amazonės Atėne. Staiga paaiškėjo, kad kruopščiai sudėlioję mūsų didžiulius žurnalo failus į aplankų šukes teisingu (parketo) stulpelių formatu, galite labai greitai iš jų padaryti itin informatyvius pasirinkimus ir kurti ataskaitas BE, be Apache Spark/Glue klasterio.
Athena variklis, maitinamas s3 duomenimis, yra pagrįstas legendiniu - MPP (masyvus lygiagretus apdorojimas) šeimos požiūrių į duomenų apdorojimą atstovas, perimant duomenis ten, kur jie yra, nuo s3 ir Hadoop iki Cassandra ir įprastų tekstinių failų. Jums tereikia paprašyti „Athena“ įvykdyti SQL užklausą, o tada viskas „veikia greitai ir automatiškai“. Svarbu pažymėti, kad Athena yra „protinga“, ji eina tik į reikiamus susmulkintus aplankus ir skaito tik tuos stulpelius, kurių reikia užklausoje.
Įdomi ir užklausų Atėnei kainodara. Mes mokame už . Tie. ne mašinų skaičių klasteryje per minutę, o... faktiškai nuskaitytiems 100-500 aparatų duomenims tik užklausai užpildyti būtinus duomenis.
O iš teisingai susmulkintų aplankų paprašius tik reikiamų stulpelių, paaiškėjo, kad Atėnės paslauga per mėnesį mums kainuoja dešimtis dolerių. Na, puiku, beveik nemokama, palyginti su klasterių analize!
Beje, štai kaip mes suskaidome duomenis s3:
Dėl to per trumpą laiką visiškai skirtingi įmonės padaliniai – nuo informacijos saugos iki analitikos – pradėjo aktyviai teikti užklausas „Athena“ ir greitai, per kelias sekundes gauti naudingus atsakymus iš „didelių“ duomenų per gana ilgą laikotarpį: mėnesius, pusę metų ir tt P.
Bet mes nuėjome toliau ir pradėjome ieškoti atsakymų į debesį : analitikas parašo SQL užklausą pažįstamoje konsolėje, kuri 100-500 mašinų „už centus“ siunčia duomenis į s3 ir atsakymą grąžina dažniausiai per kelias sekundes. Patogus. Ir greitai. Vis dar negaliu patikėti.
Dėl to, nusprendę kaupti duomenis s3, efektyviu stulpelių formatu ir protingai suskirstant duomenis į aplankus... gavome DataLake ir greitą bei pigų analitinį variklį – nemokamai. Ir kompanijoje jis tapo labai populiarus, nes... supranta SQL ir veikia daug greičiau nei paleidus / sustabdydamas / nustatydamas grupes. „Ir jei rezultatas toks pat, kam mokėti daugiau?
Prašymas Atėnei atrodo maždaug taip. Jei norite, žinoma, galite suformuoti pakankamai , bet apsiribosime paprastu grupavimu. Pažiūrėkime, kokius atsakymo kodus klientas turėjo prieš kelias savaites žiniatinklio serverio žurnaluose ir įsitikinkite, kad nėra klaidų:
išvados
Nuėję, kad ne sakyčiau, ilgą, bet skausmingą kelią, nuolat adekvačiai vertindami riziką ir sudėtingumo lygį bei palaikymo kaštus, radome DataLake ir analytics sprendimą, kuris nenustoja džiuginti tiek greičiu, tiek nuosavybės kaina.
Paaiškėjo, kad sukurti efektyvų, greitą ir pigiai eksploatuojamą DataLake visiškai skirtingų įmonės padalinių reikmėms visiškai priklauso net patyrusiems kūrėjams, kurie niekada nedirbo architektais ir nemoka piešti kvadratų ant kvadratų. rodykles ir žino 50 terminų iš Hadoop ekosistemos.
Kelionės pradžioje galva plyšo nuo daugybės laukinių atviros ir uždaros programinės įrangos zoologijos sodų ir supratimo apie atsakomybės naštą palikuonims. Tiesiog pradėkite kurti savo DataLake naudodami paprastus įrankius: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., rinkdami atsiliepimus ir giliai suprasdami vykstančių procesų fiziką. Viskas sudėtinga ir miglota – atiduokite priešams ir konkurentams.
Jei nenorite eiti į debesį ir mėgstate palaikyti, atnaujinti ir pataisyti atvirojo kodo projektus, galite sukurti panašią į mūsų schemą vietoje, nebrangiuose biuro įrenginiuose su Hadoop ir Presto viršuje. Svarbiausia nesustoti ir judėti pirmyn, skaičiuoti, ieškoti paprastų ir aiškių sprendimų, ir viskas tikrai pavyks! Sėkmės visiems ir iki pasimatymo!
Šaltinis: www.habr.com