Cloudera kiváltása best practice

Projektek általános

El szeretnénk hagyni a clouderát, felépíteni a komponensekből önállóan - hue nélkül, spórolásból ugye.

Valakinek volt hasonsló projektje, bármi említésre méltó lessons learned?

  • 1006 megtekintés

( bazso | 2025. 03. 10., h – 11:53 )

Ha van a stack elemeire tényleg kiképzett és tapasztalt emberedből legalább 5 (törvényes minimum ha ügyeletet akarsz 7x24 működésre), akkor majd ők válaszolnak erre. A kérdésed alapján nincs ekkora képzett csapat, akkor viszont vagy nem fontos az adat/funkció (ekkor mindegy a választás, keress egy komplett disztrót, hogy ne neked kelljen összetesztelni), vagy spórolási opciónak tűnik az üzleti kockázat vállalása. Ez csak abban az esetben szokás, ha már pénzügyileg haldoklik a cég, és 19-re lapot húzni is jobb (esély, időnyerés), mint megállíthatatlanul földbe állni.

  1. Shit-in, shit-out. Bár jól hangzott, hogy simán hányd bele a struktúrálatlan adataidat és majd jó lesz, nem lett. Adat stratégia és némi tervezés/rendezés nem árt.
  2. Hype idején sokan beleugrottak, pedig az adat nem is volt big. Hint: ha párszáz TB alatt vagy, akkor valószínűleg ez a helyzet.
  3. Nagyon új típusú gondolkodás kellett hozzá, fejlesztők nehezen fogadták be, maradt niche technológia, amit viszont beépítettek sok könnyen használható dobozos eszközbe, így a nyers használat szükségessége maradt a különleges igényű nagy játékosoknak.
  4. Nem értenek hozzá 

Hát... de. Legalábbis az eredeti célja ez volt. Évtizedekig jól elvolt a világ vertikálisan skálázható relációs adatbázisokkal. Csak elértük, hogy már nincs akkora gép ami kezelni bír értelmes válaszidő mellett (vagy egyáltalán) annyi adatot amennyi keletkezik. Egy ideig a normál környezeteknek még ott volt az Oracle RAC, ami olvasásra szépen skálázódott, írásra viszont kb egy node sebességét hozta. De a Google és társai már akkor is szenvedtek, és létrehozták az első igen kompromisszumos, de legalább mind írás mind olvasás szempontjából lineárisan skálázódó big data rendszereket. Aztán ezek nyílt forrású kiadása és az, hogy a kisebb cégeknél is kezdett probléma lenni az adat mennyisége, berobbantotta ezt a piacot. Kicsit túl lett tolva a hype és mindenre és mindenkinek bigdata kellett, Közben a legtöbben rájöttek, hogy 

  • Nem, mégsem oldja meg a kuplerájt helyettünk
  • Lettek sokkal nagyobb diszkek és így már elférünk. SSD is elfogadható áron gyorsít annyit hogy már nem szoftverből kell körbedolgozni a hardvert.
  • Jó bigdata fejlesztő drága, nincs is annyi adatunk (lenne, csak drága tárolni, inkább nem is fontos)
  • Vehetek bigdata matricás dobozt, amit átlag fejlesztő sql-lel vagy egyéb igen hasonló módon el tud hajtani

És szépen be is dőlt ez a piac. Ma maradt a nagy felhőszolgáltóktól vásárolható szolgáltatás, nagyon keveseknek éri meg saját adatközpontban saját, szoftveresen összehúzott vasakon művelni ezt. Mert ugye amit korábban írtam. Ha nem fontos az adat, akkor minek, ha meg az, akkor jönnek az olyan kérdések hogy ebből hogyan lesz mentés és geo-redundáns kialakítás. 

Úgyhogy amikor ma azt mondod nem a méret a lényeg, valószínűleg az utolsó ponttal találkoztál: dobozos megoldás ami azt állítja magáról, hogy bigdata (is tud lenni). Persze vannak jó megoldások bennük, én is van, hogy szívesen veszem elő valamelyiket, de baromi ritkán van valóban szükség igazi bigdata megoldásra. 

+1, gyonyoruen leirtad.

Annyi, hogy pl. a mongo mar 10 eve, de ma mar kvazi minden komolyabb DB tud sharding-ot, es near-linear read-write horizontal scalinget. Tehat meg csak ubedraga ssd-vel kitomott, SPOF szerver se kell, lehet siman commodity hardverbol epiteni hazilag, minimalis tudassal egy hazi bigdata platformot.

Na persze a multi-homed, 100+Kreq/s mouse movement + click + tracking adatokat nem fogja tarolni, de az kb. orszagonkent par cegnek van csak.

A cloudera elonye, hogy *amikor* kell a cloud / scale, akkor viszont alad ad mindent, raadasul egyedulalloan kepes hybrid is mukodni, vagyis az infra egyik fele public, a masik fele on-prem k8s-ben van. Ez foleg az EUs adatvedelmi szabalyok miatt baromi hasznos tud lenni, meg ha felelem van a cegvezetesben az adatszivargastol. Illetve a masik, hogy mindenfele certification megvan, ami kis-kozepes-nagy businessnek tokmindegy, de enterprise / government szinten kb. mintha a kave lenne, annyira eletbevago.

Igen, a Cloudera jó. Sajnos a piac bedőlése őket is durván hazavágta, így a sok nagy névből a régiek közül már alig van náluk. 

Én enterprise esetében kb. azzal a kérdéssel szoktam eldönteni hogy kell-e rendes bigdata, hogy a storage központi-e, méretben és teljesítményben elég-e, és a compute hogyan/hány vason van virtualizálva. Ha pl. van 3 combos(nak gondolt) vmware szervered egy központi tárolóval, és ezen kéne a bigdata, akkor komoly elbeszélgetés következik arról, hogy tényleg át akarod-e rángatni a teljes adattartalmat egy elcseszett lekérdezéssel a SAN vagy rosszabb esetben LAN (NAS) madzagon, jól hazavágva az egész klaszter teljes I/O teljesítményét. Sajnos életből vett példa. Vas ma már nagy és olcsó, nem kirívó, hogy egy szerverben van 100+ core és TB fölötti memória. Egy szerver nem szerver, plusz manapság sok a szavazós cucc, így kell rögtön 3. Magyarországon ekkora kapacitás néhány 10 cégnek kell talán és ez bigdata témában a játszós lab környezet talán. Nemzetközi viszonylatban jobb a helyzet, de az EU szabályozás miatt a környéken azért nincs felesleges adatgyűjtés. Amerika és Ázsia persze más kérdés, ott a bigdata napi rutin a kis cégek esetében is, de azok meg inkább veszik felhőben, mert akkor a piacukkal együtt skálázható nem csak felfelé, hanem lefelé is, és ez ugye on-prem nincs meg, ott beruháztál baromi sokat, és ha rosszul tippelted a piacod, akkor az konkrét csőd. Igen, ha jól tippeltél, akkor meg lehet fikázni a cloud szolgáltatókat, hogy lám milyen okosan spóroltál sokat.

Mindennel egyetértek amit leírtál.

Mégis fenntartom, alapvetően a "tipikusan bigdata" (ból származó) módszerek alkalmazása egy más hozzáállás az adatokhoz és a lekérdezésekhez mint amit a tipikusan BCNF, ACID SQL-ben megszoktunk. És nem a méret a lényeg hogy x terabyte adat legyen.

Az (most már) egy "elkésett reakció" amikor egy tradicionálisan megtervezett és összerakott rendszerről kiderül hogy kinőtte az architektúrát és "át kell rakni bigdata-ba". Azt már kicsiben, eleve "bigdatásan" kellett volna elkezdeni.

Gábriel Ákos

Igen, ezért írtam hogy nem vagyok ellene, ha van bigdata értő fejlesztő, üzemeltető, adatelemző, akkor kifejezetten jó cucc. Kicsiben fura/feleslegesen bonyolult, de végülis működik. De ezek az emberek akkor érik meg, amikor már a bigdata nem csak egy opció hanem az egyetlen működő lehetőség.

( hzsolt94 v | 2025. 03. 10., h – 19:34 )

Szerkesztve: 2025. 03. 10., h – 19:34

Mire van szükségetek valójában a platformból? Impala? Hive? Solar? Kafka?

1:1 alternatívát esélytelen olcsóbban házon belül karbantartani - összerakni még csak-csak, de a karbantartás hiánya nagyon hamar fájni tud

A rendszer már 9 éve fejlesztés alatt áll, és igen, kezdetektől fogva számoltak masszív bejövő adatforgalommal.
A projekt huet kivéve használja a cloudera komponenseket.
Maga a szolgáltatás nagyon nagyon drága lett mára.

Persze, valószínűleg meg lehetett volna csinálni sqlben az egészet, de mára a rendszer adott és áttérni valami másra nem opció.
Az újrafejlesztés, párhuzamosan ügyemeltetni a régi, drága. Ennyi pénz nincs.

Ez szerintem megint egy jó pont arra hogy meg kell challengelni hogy az adott költségek mellett hoz-e annyi hasznot hogy megérje működtetni. Amit még tudtok csinálni hogy újratárgyaltok a Cloudera-val, mert ahogy meghallja bármelyik cég hogy váltani akartok, hirtelen tudnak sokkal kedvezőbb ajánlatokat is adni :D 

( sz332 v | 2025. 03. 11., k – 08:28 )

Én a másik oldalról fognám meg: el kell menni a bizniszhez és meg kell kérdezni hogy a "bigdata" rendszerben tárolt adatokból mit használnak valójában. Ha semmit, akkor lehet kukázni az egészet, ha minimálisat, akkor meg lehet egy sima SQL adatbázis és egy PowerBI hibátlanul megoldja. A data-s srácok imádnak maguknak munkát generálni, még akkor is, ha ennek üzleti értéke a minimálishoz közelít.

Ez teljesen oké, nekem ilyenkor a kérdésem mindig az, hogy ebből mi az amit használnak ÉS milyen értéket teremt? Az első kérdés azért fontos mert a data-sok olyanok mint a kis hörcsögök: minden adatot magukhoz akarnak gyűjteni, majd csak jó lesz valamire címmel, ami addig oké, amig a haszon nagyobb mint a költség.

Éppen ezért én azt kérdezném hogy tudjuk-e számszerűsíteni hogy milyen üzleti értéket teremt ez a képesség és rakjuk mellé ennek a költségét. Na, ez kb. Enterprise Architect-i feladat, lehet első körben őket keresném meg: srácok, találtunk egy ilyen helyzetet, mit csináljunk vele. Ha szerencsétek van akkor ráérnek és elviszik magukkal aztán mondanak valami okosat, például:

1, jó úgy ahogy van
2, kuka az egész
3, az adatok 99%-át kivágjuk és a maradékra elég lesz valami jóval egyszerűbb
4, kell minden, de olcsóbban

Vízió - stratégia - feasibility study...
Nagy kérdés hogy milyen adatból tudsz igazi információt csinálni - és az mennyit ér.

További nehezítés hogy egy csomó adat elveszik ha nem rakod el és abból utána már garantáltan nem tudsz információt (értéket) teremteni.
Meg ugye kinek mi az érték. 
Nekem megvan x évre visszamenőleg egy csomó mért hőmérséklet érték. Kinti, benti, fűtés állapota, stb.

Ha úgy ránézel nem ér semmit. Ha gépi tanulós rendszert akarsz betanítani ... na akkor mindjárt más a szitu.

Go, figure. 

Gábriel Ákos

Ahhoz, hogy PoC szintjén el tudd dönteni, hogy egy adatból lehet az üzlet számára értékes információt kinyerni, nem kell felépíteni egy teljes bigdata rendszert. Az akkor kell, amikor már tudod, hogy élesben X adatból Y információ kinyeréséhez nincs más mód, mint egy bigdata klaszter.

További nehezítés hogy egy csomó adat elveszik ha nem rakod el 

Az az adat, amire nincs szükség, nyugodtan vesszen el.

 

Nekem megvan x évre visszamenőleg egy csomó mért hőmérséklet érték. Kinti, benti, fűtés állapota, stb.

Ha úgy ránézel nem ér semmit. Ha gépi tanulós rendszert akarsz betanítani ... na akkor mindjárt más a szitu.

Nem biztos, hogy egy X évvel ezelőtti érték használható arra, hogy a mostani állapot alapján prediktálj. Mivel más volt X éve a környezet, öregedett a fűtésrendszer vagy épp felújítást csináltál stb. Az adat is elavul idővel, és értéktelen/elavult adaton tanítani egy gépi tanulásos rendszert hibára vezet.

Ugyanez igaz a többi mért adatra is, tök irreleváns, hogy X évvel ezelőtt milyenek voltak az adatok, ha te a jelenlegi adatokból akarsz információt kinyerni.
Egy gyár esetében is, tök irreleváns, hogy 5 évvel ezelőtt milyen módon működött a gyártás, és milyen információt lehetne onnan kinyerni - a fontos, hogy most mi van.

Gyár: amikor pár éves autókon kijön tömeges hiba, vissza kell tudnod vezetni mi okozta, és abból meg kell tudnod mondani pontosan kiket érint egy visszahívás. Nagyon nehéz jó kompromisszumot kötni abban mit gyűjtesz. A Google módszer (mindent is) a cégek 99%-ának drága és felesleges. De baromi rossz amikor rájössz mit kellett volna gyűjtened a múltban, hogy a ma kérdésére legyen válaszod. Konkrét példa: felhasználói profilok/trendek, ha ma kezdesz gyűjteni, 1 év múlva már nem nullán vagy, de igazán 2 év mire használható lesz. Amikor forró lesz a piac, közöld ezt a főnököddel, hogy eddig spóroltunk, a kérdése majd 2 év múlva lesz megválaszolva.

A traceability az más téma, mint a strukturálatlan adatok tömeges gyűjtése, mert hátha jó lesz majd valamire.

Amikor kialakítasz egy traceability adatgyűjtést, azt tervezeten/szervezetten teszed meg adott műszaki igényből kiindulva (a quality szól, hogy erre neki szüksége van már most, akkor is, ha termékvisszahívás még nem fordult elő), és a terméket és a gyártást követed le, és nem mondjuk minden gép PLC-jének minden memóriacelláját gyűjtöd értelmetlenül. Nem véletlenül vannak termelési mérnökök mint domain expertek, amikor kialakítasz egy traceability pipeline-t.

A traceability amúgy sem csak adatgyűjtés, az inkább nyilvántartás - mikor, melyik munkadarabbal a gyártási folyamat során mi történt. Nem csak strukturálatlanul toljuk be az adatot valami columnar store-ba.

Amikor forró lesz a piac, közöld ezt a főnököddel, hogy eddig spóroltunk

Pont fordítva, amíg csak gyűjtöd az adatot, de nincs belőle semmi profit, akkor nem spórolsz, hanem pazarolsz. Hát ha kiépítesz egy big data pipeline-t, akkor pont az van, hogy most költesz el folyamatosan egy csomó pénzt, amiből a jövőben TALÁN lesz majd kézzelfogható eredmény. És kiderül majd, hogy ja, hát az évente elköltöttp pártíz/százmillió forintos big data szerverek a cloudban gyűjtik az adatot, csak mondjuk annyi előnyünk lesz belőle, ami 8-10 év alatt hozza be az árát, akkor arra minden főnök azt fogja mondani, hogy bocsi, de nem adok pénzt a big data játszóteredre.

Nagyon jó pontok. Amit itt még hozzáadnék hogy azon is érdemes elgondolkodni hogy mennyire speciális az adat amit gyűjtünk, nem-e lehetne arra egy külső megoldást használni? Tipikus ilyen példa a fraud rendszerek, lehet sajátot építeni, de igazából sokkal egyszerűbb egy külső féllel elintéztetni az egészet és csak a core business-re fókuszálni. 

Hozzateszem, neha egeszen eszelos arakat kernek a "kulso felek".

Peldaul a google altal felvasarol recaptcha, ami nalunk pl. millios tetel lett volna evente (euroban) -- inkabb raallitottunk egy csapatot, hogy talaljanak valamit, mert meg az is olcsobb, mint kifizetni.

Sajnos hasonlo megfontolasok vezetnek sok helyen a cloud elhagyasahoz is -- foleg ha novekszik a koltseg, par millio euro / ev folott mar egyszeruen megeri megfizetni par foallasu embert es magadnak megoldani.

Ezen lehetne segiteni, de nem all erdekeben a piaci szereploknek.

( sibike | 2025. 03. 11., k – 14:35 )

Annó 2016-17 tájékán raktam össze kézzel a komponenseket. Igazából működött de elég nehézkes volt pl az upgrade. Aztán cloudare trainingen az oktató mesélte is, hogy sokan kezdték így, mert olcsóbb és meg lehet érteni a működését, de aztán sokan feladták, mert nagyon nehézkes volt üzemeltetni, és a cloudera nem volt ilyen mocsok drága mint manapság.

Azóta sajnos nem követem a big data vonalat, szóval simán lehet, hogy ezek manapság nem állják meg a helyüket.