Ni vivas en mirinda tempo, kiam vi povas rapide kaj facile konekti plurajn pretajn malfermfontajn ilojn, agordi ilin kun via "konscio malŝaltita" laŭ la konsilo de stackoverflow, sen enprofundiĝi en la "multoblajn literojn", kaj lanĉi. ilin en komercan operacion. Kaj kiam vi bezonas ĝisdatigi/vastigi aŭ iu hazarde restartigas kelkajn maŝinojn - vi rimarkas, ke ia obseda malbona revo komenciĝis, ĉio draste komplikiĝis nerekoneble, ne ekzistas returniĝo, la estonteco estas neklara kaj pli sekura, anstataŭ programi, bredu abelojn kaj faru fromaĝon.
Ne vane pli spertaj kolegoj, kun la kapoj ŝutitaj de cimoj kaj tial jam grizaj, pripensas la nekredeble rapidan disfaldiĝon de pakoj da "ujoj" en "kuboj" sur dekoj da serviloj en "modaj lingvoj" kun enkonstruita subteno por nesinkrona nebloka I/O, ridetu modeste. Kaj ili silente daŭre relegas "man ps", enprofundiĝas en la fontkodon "nginx" ĝis iliaj okuloj sangas, kaj skribas, skribas, verkas unutestojn. Kolegoj scias, ke la plej interesa afero venos kiam "ĉio ĉi" iutage fariĝos palisigita nokte en la silvestro. Kaj ili nur estos helpitaj de profunda kompreno de la naturo de Unikso, la parkerigita TCP/IP-ŝtattabelo kaj bazaj ordigo-serĉaj algoritmoj. Por revivigi la sistemon dum la sonoroj batas.
Ho jes, mi iom distriĝis, sed mi esperas, ke mi sukcesis transdoni la staton de antaŭĝojo.
Hodiaŭ mi volas kunhavigi nian sperton pri deplojado de oportuna kaj malmultekosta stako por DataLake, kiu solvas la plimulton de analizaj taskoj en la kompanio por tute malsamaj strukturaj dividoj.
Antaŭ iom da tempo, ni ekkomprenis, ke kompanioj ĉiam pli bezonas la fruktojn de kaj produkta kaj teknika analizo (por ne mencii la civiron sur la kuko en formo de maŝina lernado) kaj por kompreni tendencojn kaj riskojn - ni devas kolekti kaj analizi. pli kaj pli da metrikoj.
Baza teknika analizo en Bitrix24
Antaŭ pluraj jaroj, samtempe kun la lanĉo de la servo Bitrix24, ni aktive investis tempon kaj rimedojn por krei simplan kaj fidindan analizan platformon, kiu helpus rapide vidi problemojn en la infrastrukturo kaj plani la sekvan paŝon. Kompreneble, estis konsilinde preni pretajn ilojn, kiuj estis kiel eble plej simplaj kaj kompreneblaj. Kiel rezulto, nagios estis elektita por monitorado kaj munin por analizo kaj bildigo. Nun ni havas milojn da ĉekoj en nagios, centojn da leteroj en munin, kaj niaj kolegoj sukcese uzas ilin ĉiutage. La metrikoj estas klaraj, la grafikaĵoj estas klaraj, la sistemo funkcias fidinde dum pluraj jaroj kaj novaj testoj kaj grafikaĵoj estas regule aldonitaj al ĝi: kiam ni ekfunkciigas novan servon, ni aldonas plurajn testojn kaj grafikaĵojn. Bonŝancon.
Fingro sur la Pulso - Altnivela Teknika Analizo
La deziro ricevi informojn pri problemoj "kiel eble plej rapide" kondukis nin al aktivaj eksperimentoj per simplaj kaj kompreneblaj iloj - pinba kaj xhprof.
Pinba sendis al ni statistikojn en UDP-pakaĵoj pri la rapideco de funkciado de partoj de retpaĝoj en PHP, kaj ni povis vidi interrete en la MySQL-stokado (Pinba venas kun sia propra MySQL-motoro por rapida analizo de eventoj) mallongan liston de problemoj kaj respondi al ilin. Kaj xhprof aŭtomate permesis al ni kolekti grafikaĵojn pri la ekzekuto de la plej malrapidaj PHP-paĝoj de klientoj kaj analizi kio povus konduki al ĉi tio - trankvile, verŝante teon aŭ ion pli fortan.
Antaŭ iom da tempo, la ilaro estis replenigita per alia sufiĉe simpla kaj komprenebla motoro bazita sur la inversa indeksa algoritmo, perfekte efektivigita en la legenda Lucene-biblioteko - Elastic/Kibana. La simpla ideo de plurfadena registrado de dokumentoj en inversan Lucene-indekson bazitan sur eventoj en la protokoloj kaj rapida serĉo tra ili uzante faceta divido montriĝis vere utila.
Malgraŭ la sufiĉe teknika aspekto de bildigoj en Kibana kun malaltnivelaj konceptoj kiel "sitelo" "fluanta supren" kaj la reinventita lingvo de la ankoraŭ ne tute forgesita interrilata algebro, la ilo komencis bone helpi nin en la sekvaj taskoj:
- Kiom da PHP-eraroj havis la kliento Bitrix24 sur la p1-portalo en la lasta horo kaj kiuj? Komprenu, pardonu kaj rapide korektu.
- Kiom da videovokoj estis faritaj sur portaloj en Germanio en la antaŭaj 24 horoj, kun kia kvalito kaj ĉu estis malfacilaĵoj kun la kanalo/reto?
- Kiom bone funkcias la sistema funkcieco (nia C-etendo por PHP), kompilita el la fonto en la plej nova serva ĝisdatigo kaj lanĉita al klientoj? Ĉu estas segfaŭltoj?
- Ĉu klientdatenoj taŭgas en PHP-memoron? Ĉu estas eraroj pri superado de la memoro asignita al procezoj: "sen memoro"? Trovu kaj neŭtrigu.
Jen konkreta ekzemplo. Malgraŭ ĝisfunda kaj plurnivela testado, la kliento, kun tre nenorma kazo kaj difektitaj enigdatenoj, ricevis ĝenan kaj neatenditan eraron, sireno sonis kaj la procezo rapide ripari ĝin komenciĝis:
Aldone, kibana permesas organizi sciigojn por specifitaj eventoj, kaj en mallonga tempo la ilo en la kompanio komencis esti uzata de dekoj da dungitoj de diversaj fakoj - de teknika subteno kaj disvolviĝo ĝis QA.
La agado de iu fako ene de la kompanio fariĝis oportuna por spuri kaj mezuri - anstataŭ mane analizi protokolojn sur serviloj, vi nur bezonas agordi analizajn protokolojn unufoje kaj sendi ilin al la elasta areto por ĝui, ekzemple, kontempli en la kibano. panelo la nombro da venditaj dukapaj katidoj presitaj per 3-D presilo por la lasta luna monato.
Baza Komerca Analizo
Ĉiuj scias, ke komerca analizo en kompanioj ofte komenciĝas per ekstreme aktiva uzo de, jes, Excel. Sed la ĉefa afero estas, ke ĝi ne finiĝas tie. Google Analytics bazita en nubo ankaŭ aldonas brulaĵon al la fajro - vi rapide komencas alkutimiĝi al la bonaj aferoj.
En nia harmonie evoluanta kompanio, jen kaj jen "profetoj" de pli intensa laboro kun pli grandaj datumoj komencis aperi. La bezono de pli profundaj kaj multfacetaj raportoj komencis aperi regule, kaj per la klopodoj de uloj de malsamaj fakoj, antaŭ iom da tempo estis organizita simpla kaj praktika solvo - kombinaĵo de ClickHouse kaj PowerBI.
Dum sufiĉe longa tempo, ĉi tiu fleksebla solvo multe helpis, sed iom post iom komencis veni la kompreno, ke ClickHouse ne estas kaŭĉuko kaj ne povas esti mokita tiel.
Ĉi tie gravas bone kompreni, ke ClickHouse, kiel Druid, kiel Vertica, kiel Amazon RedShift (kiu baziĝas sur postgres), estas analizaj motoroj optimumigitaj por sufiĉe oportuna analizo (sumoj, agregaĵoj, minimumo-maksimumo laŭ kolumno kaj kelkaj eblaj kuniĝoj). ), ĉar organizita por efika stokado de kolumnoj de interrilataj tabeloj, male al MySQL kaj aliaj (vic-orientitaj) datumbazoj konataj de ni.
En esenco, ClickHouse estas nur pli ampleksa "datumbazo", kun ne tre oportuna punkto-post-punkta enmeto (tiel ĝi estas celita, ĉio estas en ordo), sed agrabla analizo kaj aro da interesaj potencaj funkcioj por labori kun datumoj. Jes, vi eĉ povas krei areton - sed vi komprenas, ke martelado de najloj per mikroskopo ne estas tute ĝusta kaj ni komencis serĉi aliajn solvojn.
Postulo pri python kaj analizistoj
Nia kompanio havas multajn programistojn, kiuj skribas kodon preskaŭ ĉiutage dum 10-20 jaroj en PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash. Estas ankaŭ multaj spertaj sistemadministrantoj, kiuj spertis pli ol unu absolute nekredeblan katastrofon, kiu ne kongruas kun la leĝoj de statistiko (ekzemple, kiam la plimulto de diskoj en raid-10 estas detruitaj de forta fulmo). En tiaj cirkonstancoj, dum longa tempo ne estis klare, kio estas "python-analizisto". Python estas kiel PHP, nur la nomo estas iom pli longa kaj estas iom malpli da spuroj de mensŝanĝaj substancoj en la fontkodo de la interpretisto. Tamen, ĉar pli kaj pli da analizaj raportoj estis kreitaj, spertaj programistoj komencis ĉiam pli kompreni la gravecon de mallarĝa specialiĝo en iloj kiel numpy, pandoj, matplotlib, seaborn.
La decida rolo, plej verŝajne, estis ludita de la subita sveno de dungitoj pro la kombinaĵo de la vortoj "loĝistika regreso" kaj la pruvo de efika raportado pri grandaj datumoj uzante, jes, jes, pyspark.
Apache Spark, ĝia funkcia paradigmo sur kiu rilata algebro perfekte konvenas, kaj ĝiaj kapabloj faris tian impreson sur programistoj alkutimiĝintaj al MySQL ke la bezono plifortigi la rangojn kun spertaj analizistoj iĝis klara kiel tago.
Pliaj provoj de Apache Spark/Hadoop ekflugi kaj kio ne iris tute laŭ la skripto
Tamen, baldaŭ evidentiĝis, ke io sisteme ne estas tute ĝusta ĉe Spark, aŭ simple necesas pli bone lavi viajn manojn. Se la stako Hadoop/MapReduce/Lucene estis farita de sufiĉe spertaj programistoj, kio estas evidenta se vi atente rigardas la fontkodon en Java aŭ la ideojn de Doug Cutting en Lucene, tiam Spark, subite, estas skribita en la ekzotika lingvo Scala, kiu estas tre polemika el la vidpunkto de praktikeco kaj nuntempe ne evoluas. Kaj la regula falo en kalkuloj sur la Spark-areo pro nelogika kaj ne tre travidebla laboro kun memor-atribuo por reduktaj operacioj (multaj ŝlosiloj alvenas samtempe) kreis aŭreolon ĉirkaŭ ĝi de io, kio havas lokon por kreski. Aldone, la situacio estis plimalbonigita de granda nombro da strangaj malfermitaj havenoj, provizoraj dosieroj kreskantaj en la plej nekompreneblaj lokoj kaj inferaj jardependecoj - kiuj kaŭzis al administrantoj de la sistemo havi unu senton, kiu estis konata de infanaĝo: furioza malamo (aŭ eble. ili devis lavi siajn manojn per sapo).
Kiel rezulto, ni "travivis" plurajn internajn analizajn projektojn, kiuj aktive uzas Apache Spark (inkluzive de Spark Streaming, Spark SQL) kaj la ekosistemon Hadoop (kaj tiel plu kaj tiel plu). Malgraŭ tio, ke kun la tempo ni lernis prepari kaj kontroli "ĝin" sufiĉe bone, kaj "ĝi" praktike ĉesis subite kraŝi pro ŝanĝoj en la naturo de la datumoj kaj la malekvilibro de uniforma RDD hashing, la deziro preni ion jam pretan. , ĝisdatigita kaj administrita ie en la nubo pli kaj pli fortiĝis. Ĝuste en ĉi tiu tempo ni provis uzi la pretan nuban asembleon de Amazon Web Services - kaj, poste, provis solvi problemojn uzante ĝin. EMR estas Apache Spark preparita de Amazon kun plia programaro de la ekosistemo, tre kiel Cloudera/Hortonworks-konstruaĵoj.
Konservado de kaŭĉukaj dosieroj por analizo estas urĝa bezono
La sperto pri "kuiri" Hadoop/Spark kun brulvundoj al diversaj partoj de la korpo ne estis vana. La bezono krei ununuran, malmultekostan kaj fidindan dosierstokadon, kiu estus rezistema al aparataj misfunkciadoj kaj en kiu eblus stoki dosierojn en malsamaj formatoj de malsamaj sistemoj kaj fari efikajn kaj tempefikajn specimenojn por raportoj de ĉi tiuj datumoj iĝis ĉiam pli. klara.
Mi ankaŭ volis, ke ĝisdatigo de la programaro de ĉi tiu platformo ne transformiĝu en novjaran koŝmaron per legado de 20-paĝaj Java-spuroj kaj analizo de kilometroj longaj detalaj protokoloj de la areto per Spark History Server kaj retroluma lupeo. Mi volis havi simplan kaj travideblan ilon, kiu ne postulis regulan plonĝadon sub la kapuĉo, se la norma peto MapReduce de la programisto ĉesis ekzekuti kiam la reduktita datumlaboristo falis el memoro pro ne tre bone elektita fonto-datuma sekcio-algoritmo.
Ĉu Amazon S3 estas kandidato por DataLake?
Sperto kun Hadoop/MapReduce instruis al ni, ke ni bezonas skaleblan, fidindan dosiersistemon kaj skaleblajn laboristojn sur ĝi, "proksimiĝantaj" al la datumoj por ne veturi la datumojn tra la reto. Laboristoj devus povi legi datumojn en malsamaj formatoj, sed prefere ne legi nenecesajn informojn kaj povi konservi datumojn anticipe en formatoj oportunaj por laboristoj.
Denove, la baza ideo. Ne estas deziro "verŝi" grandajn datumojn en ununuran aretan analizan motoron, kiu pli aŭ malpli frue sufokos kaj vi devos malbele disigi ĝin. Mi volas konservi dosierojn, nur dosierojn, en komprenebla formato kaj fari efikajn analizajn demandojn pri ili uzante malsamajn sed kompreneblajn ilojn. Kaj estos pli kaj pli da dosieroj en malsamaj formatoj. Kaj estas pli bone disrompi ne la motoron, sed la fontajn datumojn. Ni bezonas etendeblan kaj universalan DataLake, ni decidis...
Kio se vi stokas dosierojn en la konata kaj konata skalebla nuba stokado Amazon S3, sen devi prepari viajn proprajn kotletojn de Hadoop?
Estas klare, ke la personaj datumoj estas "malaltaj", sed kio pri aliaj datumoj se ni elprenas ĝin kaj "veturigas ĝin efike"?
Cluster-bigdata-analytics ekosistemo de Amazon Web Services - en tre simplaj vortoj
Juĝante laŭ nia sperto kun AWS, Apache Hadoop/MapReduce estas aktive uzata tie delonge sub diversaj saŭcoj, ekzemple en la servo DataPipeline (mi envias miajn kolegojn, ili lernis kiel ĝuste prepari ĝin). Ĉi tie ni starigas sekurkopiojn de malsamaj servoj de DynamoDB-tabloj:
Kaj ili funkcias regule sur enkonstruitaj Hadoop/MapReduce-aretoj kiel horloĝmekanismo ekde pluraj jaroj. "Agordu ĝin kaj forgesu ĝin":
Vi ankaŭ povas efike okupiĝi pri datuma satanismo instalante Jupiterajn tekkomputilojn en la nubo por analizistoj kaj uzante la AWS SageMaker-servon por trejni kaj deploji AI-modelojn en batalon. Jen kiel ĝi aspektas por ni:
Kaj jes, vi povas preni tekkomputilon por vi mem aŭ analizisto en la nubo kaj kunligi ĝin al Hadoop/Spark-grupo, fari la kalkulojn kaj poste najli ĉion:
Vere oportuna por individuaj analizaj projektoj kaj por iuj ni sukcese uzis la EMR-servon por grandskalaj kalkuloj kaj analizoj. Kio pri sistema solvo por DataLake, ĉu ĝi funkcios? En ĉi tiu momento ni estis sur la rando de espero kaj malespero kaj daŭrigis la serĉon.
AWS Glue - bonorde pakita Apache Spark sur steroidoj
Rezultis, ke AWS havas sian propran version de la stako "Hive/Pig/Spark". La rolo de Hive, t.e. La katalogo de dosieroj kaj iliaj specoj en DataLake estas farita de la servo "Data katalogo", kiu ne kaŝas sian kongruon kun la formato Apache Hive. Vi devas aldoni informojn al ĉi tiu servo pri kie troviĝas viaj dosieroj kaj en kia formato ili estas. La datumoj povas esti ne nur en s3, sed ankaŭ en la datumbazo, sed tio ne estas la temo de ĉi tiu afiŝo. Jen kiel nia data dosierujo DataLake estas organizita:
La dosieroj estas registritaj, bonega. Se la dosieroj estis ĝisdatigitaj, ni lanĉas kraŭlojn aŭ mane aŭ laŭ horaro, kiuj ĝisdatigos informojn pri ili el la lago kaj konservos ilin. Tiam la datumoj de la lago povas esti prilaboritaj kaj la rezultoj alŝutitaj ie. En la plej simpla kazo, ni ankaŭ alŝutas al s3. Datumtraktado povas esti farita ie ajn, sed oni sugestas, ke vi agordu la prilaboradon en Apache Spark-areo uzante altnivelajn kapablojn per la AWS Glue API. Fakte, vi povas preni la bonan malnovan kaj konatan python-kodon uzante la pyspark-bibliotekon kaj agordi ĝian ekzekuton sur N-nodoj de areto de iu kapablo kun monitorado, sen fosi en la intestojn de Hadoop kaj treni docker-moker ujojn kaj forigi dependeckonfliktojn. .
Denove, simpla ideo. Ne necesas agordi Apache Spark, vi nur bezonas skribi python-kodon por pyspark, testi ĝin loke sur via labortablo kaj poste ruli ĝin sur granda areto en la nubo, specifante kie estas la fontaj datumoj kaj kie meti la rezulton. Kelkfoje ĉi tio estas necesa kaj utila, kaj jen kiel ni agordas ĝin:
Tiel, se vi bezonas kalkuli ion sur Spark-areo uzante datumojn en s3, ni skribas kodon en python/pyspark, provas ĝin kaj bonŝancon al la nubo.
Kio pri la orkestrado? Kio se la tasko falis kaj malaperis? Jes, estas proponite fari belan dukton en la stilo Apache Pig kaj ni eĉ provis ilin, sed nuntempe ni decidis uzi nian profunde personigitan orkestradon en PHP kaj JavaScript (mi komprenas, estas kogna disonanco, sed ĝi funkcias, por jaroj kaj sen eraroj).
La formato de dosieroj stokitaj en la lago estas la ŝlosilo al agado
Estas tre, tre grave kompreni du pliajn ŝlosilajn punktojn. Por ke demandoj pri dosieraj datumoj en la lago estu plenumataj kiel eble plej rapide kaj ke la rendimento ne malboniĝos kiam novaj informoj estas aldonitaj, vi devas:
- Konservu kolumnojn de dosieroj aparte (por ke vi ne devas legi ĉiujn liniojn por kompreni kio estas en la kolumnoj). Por tio ni prenis la pargetan formaton kun kunpremado
- Estas tre grave dividi dosierojn en dosierujojn kiel: lingvo, jaro, monato, tago, semajno. Motoroj, kiuj komprenas ĉi tiun tipon de sharding, rigardos nur la necesajn dosierujojn, sen ekzameni ĉiujn datumojn en vico.
Esence, tiamaniere, vi aranĝas la fontajn datumojn en la plej efika formo por la analizaj motoroj penditaj supre, kiuj eĉ en fragmentaj dosierujoj povas selekteme eniri kaj legi nur la necesajn kolumnojn el dosieroj. Vi ne bezonas "plenigi" la datumojn ie ajn (la stokado simple krevos) - simple tuj saĝe metu ĝin en la dosiersistemon en la ĝusta formato. Kompreneble, ĉi tie devus esti klare, ke stoki grandegan csv-dosieron en DataLake, kiu unue devas esti legita linio post linio per la grapolo por ĉerpi la kolumnojn, ne estas tre konsilinda. Pripensu la suprajn du punktojn denove, se ankoraŭ ne estas klare, kial ĉio ĉi okazas.
AWS Athena - la fanto-en-la-skatolo
Kaj tiam, kreante lagon, ni iel hazarde renkontis Amazonon Atenon. Subite montriĝis, ke zorge aranĝante niajn grandegajn protokolojn en dosierujojn en la ĝusta (parketo) kolumnoformato, vi povas tre rapide fari ege informajn elektojn el ili kaj konstrui raportojn SEN, sen Apache Spark/Glue-grupo.
La Athena motoro funkciigita de datumoj en s3 baziĝas sur la legenda - reprezentanto de la MPP (masiva paralela prilaborado) familio de aliroj al datumtraktado, prenante datumojn kie ĝi kuŝas, de s3 kaj Hadoop ĝis Cassandra kaj ordinaraj tekstaj dosieroj. Vi nur bezonas peti al Athena ekzekuti SQL-demandon, kaj tiam ĉio "funkcias rapide kaj aŭtomate". Gravas rimarki, ke Athena estas "inteligenta", ĝi iras nur al la necesaj fragmentaj dosierujoj kaj legas nur la kolumnojn necesajn en la peto.
La prezoj por petoj al Athena ankaŭ estas interesa. Ni pagas por . Tiuj. ne por la nombro da maŝinoj en la areto por minuto, sed... por la datumoj fakte skanitaj sur 100-500 maŝinoj, nur la datumoj necesaj por plenumi la peton.
Kaj petante nur la necesajn kolumnojn el ĝuste fragmentitaj dosierujoj, montriĝis, ke la Athena servo kostas al ni dekojn da dolaroj monate. Nu, bonega, preskaŭ senpaga, kompare kun analizo pri grapoloj!
Cetere, jen kiel ni dividas niajn datumojn en s3:
Kiel rezulto, en mallonga tempo, tute malsamaj fakoj en la kompanio, de informa sekureco ĝis analizo, komencis aktive fari petojn al Athena kaj rapide, en sekundoj, ricevi utilajn respondojn de "grandaj" datumoj dum sufiĉe longaj periodoj: monatoj, duonjaro, ktp. P.
Sed ni iris plu kaj komencis iri al la nubo por respondi : analizisto skribas SQL-demandon en konata konzolo, kiu sur 100-500 maŝinoj "por pencoj" sendas datumojn al s3 kaj resendas respondon kutime en kelkaj sekundoj. Komforta. Kaj rapide. Mi ankoraŭ ne povas kredi ĝin.
Kiel rezulto, decidinte stoki datumojn en s3, en efika kolumna formato kaj kun akceptebla dividado de datumoj en dosierujojn... ni ricevis DataLake kaj rapidan kaj malmultekostan analizan motoron - senpage. Kaj li fariĝis tre populara en la kompanio, ĉar... komprenas SQL kaj funkcias grandordojn pli rapide ol per ekfunkciigo/haltigado/agordado de aretoj. "Kaj se la rezulto estas la sama, kial pagi pli?"
Peto al Atena aspektas kiel ĉi tio. Se vi volas, kompreneble vi povas formi sufiĉe , sed ni limigos nin al simpla grupigo. Ni vidu kiajn respondkodojn la kliento havis antaŭ kelkaj semajnoj en la retservilaj protokoloj kaj certigu, ke ne estas eraroj:
trovoj
Trairinte, por ne diri longan, sed doloran vojon, konstante adekvate taksante la riskojn kaj nivelon de komplekseco kaj kosto de subteno, ni trovis solvon por DataLake kaj analizo, kiu neniam ĉesas plaĉi al ni kaj rapidecon kaj koston de posedo.
Montriĝis, ke konstrui efikan, rapidan kaj malmultekostan por funkcii DataLake por la bezonoj de tute malsamaj fakoj de la kompanio estas tute ene de la kapabloj de eĉ spertaj programistoj, kiuj neniam laboris kiel arkitektoj kaj ne scias kiel desegni kvadratojn sur kvadratoj kun. sagojn kaj konas 50 terminojn el la ekosistemo Hadoop.
Komence de la vojaĝo, mia kapo disiĝis de la multaj sovaĝaj zooj de malfermita kaj fermita programaro kaj la kompreno de la ŝarĝo de respondeco al posteuloj. Nur komencu konstrui vian DataLake el simplaj iloj: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., kolektante komentojn kaj profunde kompreni la fizikon de la procezoj okazantaj. Ĉio kompleksa kaj malklara - donu ĝin al malamikoj kaj konkurantoj.
Se vi ne volas iri al la nubo kaj ŝatas subteni, ĝisdatigi kaj fliki malfermfontajn projektojn, vi povas konstrui skemon similan al la nia loke, sur malmultekostaj oficejaj maŝinoj kun Hadoop kaj Presto supre. La ĉefa afero estas ne halti kaj antaŭeniri, kalkuli, serĉi simplajn kaj klarajn solvojn, kaj ĉio certe funkcios! Bonŝancon al ĉiuj kaj ĝis revido!
fonto: www.habr.com