Csodálatos időket élünk, amikor gyorsan és egyszerűen csatlakoztathatsz több kész nyílt forráskódú eszközt, beállíthatod őket „kikapcsolt tudattal” a stackoverflow tanácsai szerint, anélkül, hogy belemerülnél a „több betűbe”, és elindíthatod őket. kereskedelmi üzembe helyezik őket. És amikor frissíteni/bővíteni kell, vagy valaki véletlenül újraindít pár gépet - rájössz, hogy valamiféle rögeszmés rossz álom kezdődött, minden a felismerhetetlenségig drámaian bonyolulttá vált, nincs visszaút, a jövő homályos és biztonságosabb, programozás helyett méheket tenyészteni és sajtot csinálni.
Nem véletlen, hogy a tapasztaltabb kollégák hibákkal teleszórt fejjel, ezért már őszülve gondolkodnak azon, hogy hihetetlenül gyors „konténer”-csomagokat telepítsenek „kockákban” több tucat szerverre „divatos nyelveken”, beépített támogatással aszinkron, nem blokkoló I/O, mosolyogjon szerényen . És csendben folytatják a „man ps” újraolvasását, az „nginx” forráskódba mélyednek, amíg ki nem vérzik a szemük, és írnak, írnak, írnak egységteszteket. A kollégák tudják, hogy a legérdekesebb az lesz, ha egyszer szilveszter éjjel tétje lesz „mindeznek”. És csak a unix természetének, a memorizált TCP/IP állapottáblázatnak és az alapvető rendezési-keresési algoritmusoknak a mély ismerete segít nekik. Újra életre kelteni a rendszert, ahogy a harangjáték megszólal.
Ja igen, kicsit elkalandoztam, de remélem sikerült átadnom a várakozás állapotát.
Ma szeretném megosztani tapasztalatainkat egy kényelmes és olcsó DataLake stack telepítésével kapcsolatban, amely megoldja a vállalat analitikai feladatainak többségét teljesen eltérő szerkezeti részlegeknél.
Egy ideje arra jutottunk, hogy a vállalatoknak egyre nagyobb szükségük van mind a termék-, mind a technikai elemzés gyümölcsére (nem beszélve a hab a tortán a gépi tanulás formájában), valamint a trendek és kockázatok megértéséhez – össze kell gyűjtenünk és elemezni kell egyre több mérőszám.
Alapvető technikai elemzések a Bitrix24-ben
Néhány évvel ezelőtt, a Bitrix24 szolgáltatás elindításával egy időben aktívan időt és erőforrásokat fektettünk egy egyszerű és megbízható elemző platform létrehozásába, amely segít gyorsan látni az infrastruktúrában felmerülő problémákat és megtervezni a következő lépést. Természetesen célszerű volt a lehető legegyszerűbb és érthetőbb kész eszközöket venni. Ennek eredményeként a nagios-t választották a monitorozáshoz, a munint pedig az elemzéshez és a vizualizációhoz. Most már több ezer csekkünk van a nagiosban, több száz diagramunk a muninban, és kollégáink minden nap sikeresen használják ezeket. A mérőszámok egyértelműek, a grafikonok egyértelműek, a rendszer több éve megbízhatóan működik, és rendszeresen új tesztek, grafikonok kerülnek rá: egy új szolgáltatás üzembe helyezésekor több tesztet, grafikont adunk hozzá. Sok szerencsét.
Finger on the Pulse – Speciális műszaki elemzés
Az a vágy, hogy „a lehető leggyorsabban” információt kapjunk a problémákról, aktív kísérletekhez vezetett egyszerű és érthető eszközökkel - pinba és xhprof.
A Pinba UDP-csomagokban küldött nekünk statisztikát a weboldalak egyes részeinek működési sebességéről PHP-ben, és online a MySQL tárolóban (a Pinba saját MySQL motorral rendelkezik a gyors eseményelemzés érdekében) láthattunk egy rövid listát a problémákról és reagáltunk a problémákra. őket. Az xhprof pedig automatikusan lehetővé tette, hogy grafikonokat gyűjtsünk az ügyfelektől a leglassabb PHP-oldalak végrehajtásáról, és elemezzük, mi vezethet ehhez - nyugodtan, teát öntve vagy valami erősebbet.
Nemrég az eszköztárat egy másik meglehetősen egyszerű és érthető, fordított indexelési algoritmuson alapuló motorral egészítették ki, amelyet a legendás Lucene könyvtárban tökéletesen megvalósítottak - Elastic/Kibana. Nagyon hasznosnak bizonyult az az egyszerű ötlet, hogy több szálon rögzítsék a dokumentumokat egy inverz Lucene-indexbe a naplókban lévő események alapján, és gyors keresést végezzenek rajtuk a fazettaosztással.
Annak ellenére, hogy a Kibanában a vizualizációk meglehetősen technikai megjelenésűek olyan alacsony szintű fogalmakkal, mint a „vödör” „felfelé áramlik”, és a még nem teljesen feledésbe merült relációs algebra újra feltalált nyelve, az eszköz a következő feladatokban kezdett jó segítségünkre lenni:
- Hány PHP hibája volt a Bitrix24 kliensnek a p1 portálon az elmúlt órában, és melyek? Megérteni, megbocsátani és gyorsan kijavítani.
- Hány videohívás történt németországi portálokon az elmúlt 24 órában, milyen minőségben, és voltak-e nehézségek a csatornával/hálózattal?
- Mennyire működik jól a rendszer funkcionalitása (a PHP C-bővítménye), amelyet a forrásból a legújabb szolgáltatásfrissítésben fordítottunk le és terjesztünk ki az ügyfelek számára? Vannak segfaults?
- Az ügyféladatok beleférnek a PHP memóriájába? Vannak-e hibák a folyamatokhoz lefoglalt memória túllépésével kapcsolatban: „elfogyott a memória”? Keresse meg és semlegesítse.
Íme egy konkrét példa. Az alapos és többszintű tesztelés ellenére a nagyon nem szabványos házzal és sérült bemeneti adatokkal rendelkező kliens bosszantó és váratlan hibát kapott, megszólalt a sziréna, és megkezdődött a gyors javítás:
Ezenkívül a kibana lehetővé teszi az értesítések megszervezését meghatározott eseményekről, és rövid időn belül a vállalat eszközét több tucat alkalmazott kezdte használni a különböző részlegekről - a műszaki támogatástól és fejlesztéstől a minőségbiztosításig.
A vállalaton belüli bármely részleg tevékenysége kényelmesen követhető és mérhető - a szervereken lévő naplók manuális elemzése helyett csak egyszer be kell állítania a naplóelemzést, és el kell küldenie őket a rugalmas fürtbe, hogy élvezhesse például a kibanában való gondolkodást. műszerfalon az eladott kétfejű cicák száma 3D nyomtatóval az elmúlt holdhónapban.
Alapvető üzleti elemzések
Mindenki tudja, hogy az üzleti analitika a vállalatoknál gyakran az Excel rendkívül aktív használatával kezdődik, igen. De a lényeg az, hogy ez még nem ér véget. A felhőalapú Google Analytics is olajat ad a tűzre – gyorsan kezdi megszokni a jó dolgokat.
Harmonikusan fejlődő társaságunkban itt-ott megjelentek az intenzívebb, nagyobb adatokkal rendelkező munka „prófétái”. Rendszeresen megjelent az igény a mélyebb és sokrétűbb jelentések iránt, és a különböző részlegekről érkező srácok erőfeszítései révén néhány évvel ezelőtt egy egyszerű és praktikus megoldás született - a ClickHouse és a PowerBI kombinációja.
Elég sokáig sokat segített ez a rugalmas megoldás, de fokozatosan kezdett jönni a megértés, hogy a ClickHouse nem gumi és nem lehet így kigúnyolni.
Itt fontos jól megérteni, hogy a ClickHouse, akárcsak a Druid, akár a Vertica, akár az Amazon RedShift (amely a postgres-en alapul), meglehetősen kényelmes elemzésre optimalizált elemző motorok (összegek, aggregációk, minimum-maximum oszloponként és néhány lehetséges csatlakozás) ), mert a relációs táblák oszlopainak hatékony tárolására szervezett, ellentétben a MySQL-lel és más, általunk ismert (sororientált) adatbázisokkal.
Lényegében a ClickHouse csak egy tágasabb „adatbázis”, nem túl kényelmes pontonkénti beszúrással (így készült, minden rendben), de kellemes elemzésekkel és egy sor érdekes, hatékony funkcióval az adatokkal való munkavégzéshez. Igen, akár klasztert is létrehozhat – de megérti, hogy a szögek mikroszkóppal történő kalapálása nem teljesen helyes, és elkezdtünk más megoldásokat keresni.
A python és az elemzők iránti kereslet
Cégünknek számos fejlesztője van, akik 10-20 éven keresztül szinte minden nap írnak kódot PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash nyelven. Sok tapasztalt rendszeradminisztrátor is tapasztalt egynél több olyan, teljesen hihetetlen katasztrófát, amely nem illeszkedik a statisztika törvényeihez (például amikor a raid-10 lemezeinek többsége megsemmisül egy erős villámcsapás következtében). Ilyen körülmények között sokáig nem volt világos, mi az a „python elemző”. A Python olyan, mint a PHP, csak a név kicsit hosszabb, és valamivel kevesebb nyoma van tudatmódosító anyagoknak az értelmező forráskódjában. Ahogy azonban egyre több elemző jelentés készült, a tapasztalt fejlesztők egyre jobban megértették az olyan eszközök szűk szakterületének fontosságát, mint a numpy, panda, matplotlib, seaborn.
A döntő szerepet nagy valószínűséggel az alkalmazottak hirtelen elájulása játszotta a „logisztikai regresszió” szavak kombinációjából, valamint a nagy adatokról szóló hatékony jelentéstétel demonstrálása, igen, igen, pyspark segítségével.
Az Apache Spark, annak funkcionális paradigmája, amelyre a relációs algebra tökéletesen illeszkedik, és képességei olyan benyomást keltettek a MySQL-hez szokott fejlesztőkben, hogy napról napra világossá vált, hogy tapasztalt elemzőkkel kell erősíteni a sorokat.
Az Apache Spark/Hadoop további próbálkozásai a felszállásra, és ami nem egészen a forgatókönyv szerint ment
Hamar kiderült azonban, hogy valami rendszerszinten nem stimmel a Sparkkal, vagy csak jobban kell kezet mosni. Ha a Hadoop/MapReduce/Lucene stacket meglehetősen tapasztalt programozók készítették, ami nyilvánvaló, ha alaposan megnézzük a Java forráskódját vagy Doug Cutting ötleteit Lucene-ban, akkor a Spark hirtelen az egzotikus Scala nyelven íródott, ami nagyon ellentmondásos a gyakorlatiasság szempontjából, és jelenleg nem fejlődik. És a számítások rendszeres visszaesése a Spark-fürtön a redukciós műveletekhez szükséges memóriafoglalás logikátlan és nem túl átlátható munkája miatt (sok kulcs érkezik egyszerre) egy glóriát hozott létre körülötte valamivel, aminek van hova fejlődnie. Ráadásul a helyzetet súlyosbította a nagyszámú furcsa nyitott port, a legérthetetlenebb helyeken növekvő ideiglenes fájlok és a jar-függőségek pokolgépe – ami miatt a rendszergazdákban egy gyerekkorukból jól ismert érzés támadt: heves gyűlölet (vagy talán szappannal kellett kezet mosniuk).
Ennek eredményeként több belső elemző projektet „túléltünk”, amelyek aktívan használják az Apache Sparkot (beleértve a Spark Streaminget, a Spark SQL-t) és a Hadoop ökoszisztémát (és így tovább és így tovább). Annak ellenére, hogy az idő múlásával elég jól megtanultuk előkészíteni és figyelemmel kísérni az „ezt”, és az adatok természetében bekövetkezett változások és az egységes RDD-kivonat kiegyensúlyozatlansága miatt gyakorlatilag abbamaradt a hirtelen összeomlás, a vágy, hogy valami már készet vegyünk. , frissítve és valahol a felhőben adminisztrálva egyre erősebb lett. Ekkoriban próbáltuk használni az Amazon Web Services kész felhő-összeállítását - és ezt követően megpróbálta megoldani a problémákat a segítségével. Az EMR az Apache Spark, amelyet az Amazon készített az ökoszisztémából származó további szoftverekkel, hasonlóan a Cloudera/Hortonworks buildekhez.
Sürgősen szükség van az elemzésekhez használt gumifájltárolóra
A Hadoop/Spark „főzése” különböző testrészek égési sérüléseivel nem volt hiábavaló. Egyre inkább felmerült az igény egy olyan egységes, olcsó és megbízható fájltároló létrehozására, amely ellenáll a hardverhibáknak, és amelyben különböző rendszerekről különböző formátumú fájlokat lehet tárolni, és ezekből az adatokból hatékony és időtakarékos mintákat lehet készíteni a jelentésekhez. egyértelmű.
Azt is szerettem volna, hogy ennek a platformnak a szoftverfrissítése ne legyen újévi rémálom a 20 oldalas Java-nyomok leolvasásával és a klaszter kilométeres részletes naplóinak elemzésével a Spark History Server és egy háttérvilágítású nagyító segítségével. Egy egyszerű és átlátható eszközt szerettem volna, amely nem igényel rendszeres búvárkodást a motorháztető alatt, ha a fejlesztő szabványos MapReduce kérése leállt, amikor a redukciós adatkezelő kiesett a memóriájából egy nem túl jól megválasztott forrásadat-particionáló algoritmus miatt.
Az Amazon S3 a DataLake jelöltje?
A Hadoop/MapReduce tapasztalatai megtanították nekünk, hogy méretezhető, megbízható fájlrendszerre és ezen felül méretezhető dolgozókra van szükségünk, akik „közelebb jönnek” az adatokhoz, hogy ne a hálózaton keresztül továbbítsák az adatokat. A dolgozóknak képesnek kell lenniük különböző formátumú adatok olvasására, de lehetőleg ne olvassanak fölösleges információkat, és képesek legyenek előre tárolni az adatokat a munkavállalók számára kényelmes formátumban.
Még egyszer az alapötlet. Nincs vágy egyetlen klaszter elemző motorba "önteni" a nagy adatokat, ami előbb-utóbb kifullad, és csúnyán kell szilánkokra törni. Szeretnék fájlokat, pusztán fájlokat, érthető formátumban tárolni, és különböző, de érthető eszközökkel hatékony elemző lekérdezéseket végezni rajtuk. És egyre több fájl lesz különböző formátumban. És jobb, ha nem a motort, hanem a forrásadatokat tördeljük. Bővíthető és univerzális DataLake-re van szükségünk, úgy döntöttünk...
Mi a teendő, ha a fájlokat az ismert és jól ismert, méretezhető Amazon S3 felhőalapú tárolóban tárolja anélkül, hogy a Hadoopból kellene elkészítenie saját darabjait?
Egyértelmű, hogy a személyes adatok „kevés”, de mi a helyzet a többi adattal, ha kivesszük és „hatékonyan vezetjük”?
Az Amazon Web Services fürt-bigdata-analitikai ökoszisztémája – nagyon egyszerű szavakkal
Az AWS-sel kapcsolatos tapasztalatainkból ítélve az Apache Hadoop/MapReduce-t ott már régóta aktívan használják különféle szószok alatt, például a DataPipeline szolgáltatásban (irigylem a kollégáimat, megtanulták helyesen elkészíteni). Itt állítjuk be a biztonsági mentéseket a DynamoDB táblák különböző szolgáltatásaiból:
És már több éve rendszeresen futnak beágyazott Hadoop/MapReduce-fürtökön, mint az óramű. „Állítsd be és felejtsd el”:
Hatékonyan részt vehet az adatsátánizmusban is, ha Jupiter laptopokat állít be a felhőben az elemzők számára, és használja az AWS SageMaker szolgáltatást a mesterséges intelligencia modellek kiképzésére és bevetésére. Nálunk így néz ki:
És igen, felvehet egy laptopot magának vagy egy elemzőnek a felhőben, és csatlakoztathatja egy Hadoop/Spark-fürthöz, elvégezheti a számításokat, majd mindent leszögezhet:
Egyedi analitikai projektekhez igazán kényelmes, egyes esetekben pedig sikeresen alkalmaztuk az EMR szolgáltatást nagyszabású számításokhoz és elemzésekhez. Mi a helyzet a DataLake rendszermegoldásával, működni fog? Ebben a pillanatban a remény és a kétségbeesés határán voltunk, és folytattuk a keresést.
AWS Glue – szépen csomagolt Apache Spark szteroidokon
Kiderült, hogy az AWS-nek megvan a saját verziója a „Hive/Pig/Spark” veremről. Kaptár szerepe, i.e. A DataLake-ben található fájlok és típusaik katalógusát az „Adatkatalógus” szolgáltatás végzi, amely nem rejti véka alá az Apache Hive formátummal való kompatibilitását. Információkat kell hozzáadnia ehhez a szolgáltatáshoz arról, hogy hol találhatók a fájlok és milyen formátumban vannak. Az adatok nem csak s3-ban lehetnek, hanem az adatbázisban is, de ez nem ennek a bejegyzésnek a témája. A DataLake adatkönyvtárunk így van felszerelve:
A fájlok regisztrálva vannak, nagyszerű. Ha a fájlok frissítésre kerültek, akkor manuálisan vagy ütemezetten bejárókat indítunk, amelyek frissítik a tóról származó információkat és elmentik azokat. Ezután a tóból származó adatokat lehet feldolgozni, és az eredményeket feltölteni valahova. A legegyszerűbb esetben az s3-ba is feltöltjük. Az adatfeldolgozás bárhol elvégezhető, de azt javasoljuk, hogy a feldolgozást egy Apache Spark-fürtön konfigurálja az AWS Glue API-n keresztüli speciális képességekkel. Valójában a pyspark könyvtár segítségével használhatja a jó öreg és ismerős python kódot, és beállíthatja annak végrehajtását egy bizonyos kapacitású fürt N csomópontján megfigyeléssel anélkül, hogy beleásná magát a Hadoop zsigereibe, húzná a docker-moker konténereket és kiküszöbölné a függőségi konfliktusokat. .
Ismét egy egyszerű ötlet. Nem kell konfigurálni az Apache Sparkot, csak python kódot kell írnia a pysparkhoz, helyileg tesztelni kell az asztalon, majd futtatni egy nagy fürtön a felhőben, megadva, hogy hol vannak a forrásadatok, és hová kell tenni az eredményt. Néha ez szükséges és hasznos, és a következőképpen állítjuk be:
Így ha valamit ki kell számítania egy Spark-fürtön az s3-ban lévő adatok alapján, akkor a python/pysparkban kódot írunk, teszteljük, és sok sikert kívánunk a felhőnek.
Mi a helyzet a hangszereléssel? Mi van, ha a feladat elesik és eltűnik? Igen, azt javasolják, hogy készítsünk egy gyönyörű csővezetéket Apache Pig stílusban, és ki is próbáltuk őket, de most úgy döntöttünk, hogy a mélyen testreszabott hangszerelésünket használjuk PHP-ben és JavaScriptben (értem, van kognitív disszonancia, de működik, év és hiba nélkül).
A tóban tárolt fájlok formátuma a teljesítmény kulcsa
Nagyon-nagyon fontos, hogy megértsünk még két kulcsfontosságú pontot. Annak érdekében, hogy a tóban található fájladatokra vonatkozó lekérdezések a lehető leggyorsabban végrehajtódjanak, és a teljesítmény ne csökkenjen az új információk hozzáadásakor, a következőket kell tennie:
- A fájlok oszlopait külön tárolja (hogy ne kelljen minden sort elolvasnia ahhoz, hogy megértse, mi van az oszlopokban). Ehhez a tömörítéssel ellátott parketta formátumot választottuk
- Nagyon fontos, hogy a fájlokat olyan mappákba bontsa, mint: nyelv, év, hónap, nap, hét. Azok a motorok, amelyek megértik az ilyen típusú felosztást, csak a szükséges mappákat nézik, anélkül, hogy sorra át kellene szűrniük az összes adatot.
Lényegében így a leghatékonyabb formában rakod ki a forrásadatokat a tetejére akasztott elemző motorok számára, amelyek a szilánkos mappákban is csak a szükséges oszlopokat tudják szelektíven beírni és kiolvasni a fájlokból. Nem kell sehol „feltöltenie” az adatokat (a tárhely egyszerűen felrobban) - csak azonnal és bölcsen helyezze el a fájlrendszerbe a megfelelő formátumban. Természetesen itt világosnak kell lennie, hogy egy hatalmas csv fájl tárolása a DataLake-ben, amelyet először soronként be kell olvasnia a fürtnek az oszlopok kibontásához, nem nagyon tanácsos. Gondolja át még egyszer a fenti két pontot, ha még nem világos, miért történik mindez.
AWS Athena – a dobozban elhelyezett jack
Aztán egy tó létrehozása közben véletlenül rábukkantunk az Amazon Athénére. Hirtelen kiderült, hogy hatalmas naplófájljainkat gondosan, a megfelelő (parkettás) oszlopformátumban mappaszilánkokba rendezve nagyon gyorsan lehet belőlük rendkívül informatív kijelöléseket készíteni és riportokat készíteni NÉLKÜL, Apache Spark/Glue klaszter nélkül.
Az S3-ban adatokkal hajtott Athena motor a legendás - az MPP (massive párhuzamos feldolgozás) megközelítések családjának képviselője az adatfeldolgozásban, ahol az adatokat átveszi, az s3-tól és a Hadoop-tól a Cassandráig és a közönséges szövegfájlokig. Csak meg kell kérnie az Athénát, hogy hajtson végre egy SQL-lekérdezést, és akkor minden „gyorsan és automatikusan működik”. Fontos megjegyezni, hogy az Athena „okos”, csak a szükséges szilánkos mappákba megy, és csak a kérésben szükséges oszlopokat olvassa el.
Az Athena felé irányuló kérések árazása is érdekes. mi fizetünk . Azok. nem a fürtben lévő gépek percenkénti számára, hanem... a 100-500 gépen ténylegesen beszkennelt adatokra csak a kérés teljesítéséhez szükséges adatok.
És azzal, hogy csak a szükséges oszlopokat kértük le helyesen feldarabolt mappákból, kiderült, hogy az Athena szolgáltatás havonta több tíz dollárba kerül. Nos, nagyszerű, szinte ingyenes, a klasztereken végzett elemzésekhez képest!
Mellesleg, a következőképpen bontjuk fel adatainkat s3-ban:
Ennek eredményeként rövid időn belül a vállalat teljesen különböző részlegei, az információbiztonságtól az analitikáig, aktívan kérelmezték az Athénét, és gyorsan, másodpercek alatt hasznos válaszokat kaptak a „nagy” adatokból, meglehetősen hosszú időn keresztül: hónapokig, fél év stb. P.
De tovább mentünk, és elkezdtünk a felhőhöz menni válaszokért : egy elemző ír egy SQL lekérdezést egy ismerős konzolon, ami 100-500 gépen „fillérekért” küld adatokat az s3-nak, és általában néhány másodperc alatt visszaadja a választ. Kényelmes. És gyorsan. Még mindig nem hiszem el.
Ennek eredményeként, miután úgy döntöttünk, hogy s3-ban tároljuk az adatokat, hatékony oszlopos formátumban és az adatok ésszerű mappákba osztása mellett, megkaptuk a DataLake-et és egy gyors és olcsó elemző motort - ingyen. És nagyon népszerű lett a társaságban, mert... megérti az SQL-t, és nagyságrendekkel gyorsabban működik, mint a fürtök indításával/leállításával/beállításával. "És ha az eredmény ugyanaz, miért fizetne többet?"
Az Athénéhez intézett kérés valahogy így néz ki. Kívánságra természetesen formázhatunk is eleget , de az egyszerű csoportosításra szorítkozunk. Nézzük meg, milyen válaszkódokat tartalmazott az ügyfél néhány héttel ezelőtt a webszerver naplóiban, és győződjön meg arról, hogy nincsenek hibák:
Álláspontja
Ha nem is mondjuk egy hosszú, de fájdalmas úton jártunk, folyamatosan adekvát módon felmértük a támogatás kockázatait, bonyolultsági szintjét és költségeit, olyan megoldást találtunk a DataLake és az analitika számára, amely mind a gyorsasággal, mind a birtoklási költséggel mindig örömet okoz.
Kiderült, hogy egy hatékony, gyors és olcsón működtethető DataLake felépítése a cég teljesen különböző részlegeinek igényeire teljesen belefér még a tapasztalt fejlesztők lehetőségeibe is, akik soha nem dolgoztak építészként, és nem tudják, hogyan kell négyzeteket rajzolni a négyzetekre. nyilakat és 50 kifejezést ismer a Hadoop ökoszisztémából.
Az utazás elején hasadt a fejem a nyitott és zárt szoftverek sok vad állatkertjétől, valamint az utódok felelősségének megértésétől. Csak kezdje el a DataLake felépítését egyszerű eszközökkel: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., visszajelzéseket gyűjt, és mélyen megérti a zajló folyamatok fizikáját. Minden bonyolult és homályos – add oda ellenségeknek és versenytársaknak.
Ha nem szeretne a felhőbe menni, és szereti a nyílt forráskódú projekteket támogatni, frissíteni és javítani, a miénkhez hasonló sémát építhet helyben, olcsó irodai gépeken Hadoop és Presto tetején. A lényeg az, hogy ne állj meg és haladj előre, számolj, keress egyszerű és világos megoldásokat, és minden biztosan sikerülni fog! Sok sikert mindenkinek és viszontlátásra!
Forrás: will.com