az elmúlt néhány évben sok beszélgetést folytattam a barátaimmal és kollégáimmal, akik csalódottak voltak az adatinfrastruktúra ökoszisztéma megfejthetetlenül összetett volta miatt. Bár nem olyan rossz, mint a front-end világ, a dolgok elég gyorsan változnak ahhoz, hogy létrehozzanak egy buzzword levest.

kezdőként nagyon nehéz eldönteni, hogy milyen eszközök vannak az Ön számára. Az Apache Foundation 38 projektet sorol fel a” Big Data ” részben, és ezek az eszközök rengeteg átfedésben vannak az általuk kezelt problémákkal. Például a Flink, a Samza, a Storm és a Spark Streaming “elosztott adatfolyam-feldolgozó motorok”, az Apex és a Beam “unify stream and batch processing”.

ebben a bejegyzésben remélem, hogy némi segítséget nyújt az opciók navigálásában az adatinfrastruktúra kiépítéséhez. Nagyjából ezeket a lépéseket követném ma, az elmúlt évtized tapasztalatai és az ezen a téren dolgozó kollégákkal folytatott beszélgetések alapján.

a projekt kezdetén valószínűleg csak azzal a céllal indul, hogy” betekintést nyerjen az adataimból”. Ennek leképezése bizonyos technológiákra rendkívül ijesztő. Valószínűleg nincs nagy értelme annak, hogy milyen eszközök népszerűek, mit jelent a “stream” vagy a “batch”, vagy egyáltalán szüksége van-e adatinfrastruktúrára.

ebben a bejegyzésben remélem, hogy néhány útmutatást, hogy segítsen, hogy le a földre gyorsan és kivonat értéket az adatokat. Erősen hiszek abban, hogy a dolgokat a lehető leghosszabb ideig egyszerűvé kell tenni, csak akkor vezetjük be a komplexitást, ha a skálázhatósághoz szükséges. Ez a bejegyzés ezt az ívet követi három szakaszban. Sok szempontból visszatükrözi az adatinfrastruktúra kiépítésének lépéseit, amelyeket az elmúlt években követtem.

ne feledje, hogy nincs egyetlen helyes út az adatinfrastruktúra építéséhez. Az ezt olvasó szakértők számára előnyben részesíthette az itt javasolt megoldások alternatíváit. Ez fantasztikus, és kiemeli a csodálatos eszközök sokféleségét, amelyekkel manapság rendelkezünk. Nagyon hosszú utat tettünk meg attól kezdve, hogy Hadoop MapReduce volt mindenünk.

tehát itt van a dolog: valószínűleg még nincs “nagy adat”. Majdnem 4 évvel később Chris Stucchio 2013-as cikke ne használja a Hadoopot még mindig pont. Ha kevesebb, mint 5 TB adata van, kezdje kicsiben. Ez megtakarítja a működési fejfájást olyan rendszerek fenntartásával, amelyekre még nincs szüksége. De hé, ha szereted a 3am tűz gyakorlatokat a munkahelyi kudarcokból, nyugodtan hagyja ki ezt a részt…

ellenkező esetben tartózkodjon az összes buzzword technológiától az elején, és két dologra összpontosítson: (1) Az adatok lekérdezhetővé tétele SQL-ben, és (2) A BI eszköz kiválasztása. Ezek lesznek a” Hello, World ” gerince az összes jövőbeli adatinfrastruktúrának.

minden az SQL-ben

ez nagyon fontos, mert feloldja az adatokat az egész szervezet számára. Ritka kivételtől eltekintve a legfélelmetesebb marketing emberek, akkor soha nem meggyőzni a nem technikai kollégák tanulni Kibana, grep néhány naplók, vagy használja a homályos szintaxis a NoSQL datastore.

az SQL hozzáférés biztosítása lehetővé teszi az egész vállalat számára, hogy önkiszolgáló elemzőkké váljon, így a már kifeszített mérnöki csapat kikerül a kritikus útról. Azt is bekapcsolja mindenki egy ingyenes QA csapat az adatokat. A “Hé, ezek a számok furcsán néznek ki…” felbecsülhetetlen értékű a hibák megtalálásához az adatokban, sőt a termékben is.

ha az elsődleges adattár egy relációs adatbázis, például PostgreSQL vagy MySQL, ez nagyon egyszerű. Csak állítson be egy olvasási replikát, rendelkezési hozzáférést, és minden készen áll.

az olyan NoSQL adatbázisokkal, mint az ElasticSearch, a MongoDB vagy a DynamoDB, több munkát kell tennie az adatok konvertálásához és egy SQL adatbázisba helyezéséhez. Ha új vagy az adatvilágban, ezt ETL csővezetéknek nevezzük. Kerülje el, hogy ezt saját maga építse fel, ha lehetséges, mivel a polcon kívüli megoldás bekötése sokkal olcsóbb lesz kis adatmennyiségekkel. A meglévő infrastruktúrától függően előfordulhat, hogy van egy felhő-ETL-szolgáltató, például szegmens, amelyet kihasználhat.

ha úgy találja, hogy meg kell építeni a saját adatvezetékek, tartsa őket rendkívül egyszerű az első. Írjon egy szkriptet, amely rendszeresen kiírja a frissítéseket az adatbázisból, és írja őket valahova, ahol lekérdezhető az SQL segítségével.

a történet ETLing adatok 3rd party források hasonló, mint a NoSQL adatbázisok. Használjon ETL-as-a-service provider-t, vagy írjon egy egyszerű szkriptet, és csak helyezze el adatait egy SQL-lekérdezhető adatbázisba.

állíts be egy gépet, ami futtatja az ETL szkriptjeidet napi cron-ként, és máris indulsz a versenyre.

BI eszköz

a jó BI eszköz fontos része az adatok megértésének. Néhány nagyszerű eszköz, amelyet figyelembe kell venni, a Chartio, a Mode Analytics és a Periscope Data — ezek bármelyikének nagyszerűen kell működnie ahhoz, hogy az elemzéseket a földről lehessen elérni. A legtöbb esetben ezeket az eszközöket közvetlenül az SQL-adatbázisra irányíthatja egy gyors konfigurációval, és közvetlenül az irányítópultok létrehozásába merülhet.

mindezt összefogva, itt van az adatinfrastruktúra “Hello, World” :

1. szakasz: a” Hello, World “kis adatvezeték

2. szakasz: nevezzük “közepes” adatnak

ezen a ponton néhány terabájtnál több lebeg, és a cron+script ETL nem egészen tart lépést. Talán már elszaporodott adattárolók, és van egy heterogén keveréke SQL és NoSQL backends. Lehet, hogy most van egy maroknyi harmadik fél is, akiktől adatokat gyűjt. Végül előfordulhat, hogy az ETL csővezetékeiben több szakasz kezdődik, a lépések közötti függőségekkel.

munkafolyamat-kezelés & automatizálás

ebben a szakaszban az első lépés a légáramlás beállítása az ETL csővezetékek kezelésére. Az Airflow lehetővé teszi, hogy rendszeres időközönként ütemezze a feladatokat, és kifejezze mind az időbeli, mind a logikai függéseket a feladatok között. Ez is egy remek hely az infrastruktúrában, hogy adjunk munkát újrapróbálkozások, monitoring & figyelmeztet a feladat hibák. Ez egy futó vicc, hogy minden indítás egy bizonyos méret felett írja a saját munkafolyamat-kezelőjét / feladatütemezőjét. Többek között a Spotify írta Luigi-t, a Pinterest pedig a flippert. Ezek azonban kevésbé lendületesek a közösségben, és hiányoznak bizonyos jellemzők a légáramlás tekintetében.

ETL csővezetékek építése

vállalkozása növekedésével az ETL csővezeték követelményei jelentősen megváltoznak. El kell kezdenie a skálázhatóbb infrastruktúra kiépítését, mert egyetlen szkript már nem vágja le. A célok valószínűleg kibővülnek azzal is, hogy egyszerűen lehetővé teszik az SQL hozzáférést, hogy más downstream munkákat támogassanak, amelyek ugyanazokat az adatokat dolgozzák fel.

végül az egyszerű csővezetékek nem méreteződnek

ezeknek a változó követelményeknek a kezeléséhez az ETL parancsfájlokat át kell alakítani egy fürtön elosztott feladatként történő futtatásra. A lehetséges megoldások száma itt teljesen lenyűgöző. Erősen ajánlom az Apache Spark-val kezdeni. A Spark hatalmas, nagyon aktív közösséggel rendelkezik, jól mérlegel, és meglehetősen könnyű felkelni és gyorsan futni. Az AWS – en futtathatja a Spark-ot az EMR használatával; a GCP-hez a Cloud Dataproc használatával. Ha lenyeli az adatokat egy relációs adatbázis, Apache Sqoop nagyjából a szabvány.

ezen a ponton az ETL infrastruktúrája úgy fog kinézni, mint a feladatok futószalagos szakaszai, amelyek megvalósítják a három ETL igét: adatok kinyerése forrásokból, az adatok standardizált formátumokká alakítása állandó tároláson, majd betöltése egy SQL-lekérdezhető adattárba.

adattárház

ebben a szakaszban az összes adat SQL-be történő felvétele továbbra is prioritás marad, de ez az az idő, amikor el akarja kezdeni egy “valódi” adattárház kiépítését.

azok számára, akik csak most kezdik el, a BigQuery használatát javasolnám. A BigQuery könnyen beállítható (csak JSON-ként tölthet be rekordokat), támogatja a beágyazott/összetett adattípusokat, és teljes mértékben felügyelt/szerver nélküli, így nincs több karbantartandó infrastruktúra. Mint sok ajánlásnál itt, a BigQuery alternatívái is rendelkezésre állnak: az AWS, a Redshift és az on-prem, a Presto. Erősen előnyben részesítem a BigQuery-t a vöröseltolódással szemben a szerver nélküli kialakítása, a megfelelő biztonság/auditálás konfigurálásának egyszerűsége és az összetett típusok támogatása miatt. Presto érdemes megfontolni, ha van egy kemény követelmény on-prem.

amikor az adattárház felállításán gondolkodik, kényelmes minta egy 2 lépcsős modell elfogadása, ahol a feldolgozatlan adatok közvetlenül egy táblázatba kerülnek, és egy második munka után ezeket az adatokat “tisztább” táblákká dolgozza fel.

kezelje ezeket a tisztább táblákat, mint lehetőséget arra, hogy kurált nézetet hozzon létre vállalkozásában. A vállalkozás minden kulcsfontosságú entitásához hozzon létre és készítsen egy táblázatot az összes olyan mutatóval/KPI-vel és dimenzióval, amelyet gyakran használ az entitás elemzéséhez. A “felhasználók” táblázat például olyan mutatókat tartalmazhat, mint a regisztrációs idő, a vásárlások száma, valamint olyan dimenziók, mint a földrajzi hely vagy a beszerzési csatorna.

mindezek végén az infrastruktúrának valahogy így kell kinéznie:

2. szakasz :a “közepes” adatvezeték

🚀 3. szakasz: Nagy

a megfelelő alapokkal a további növekedésnek nem kell fájdalmasnak lennie. Gyakran egyszerűen megteheti, ha hardvert dob a megnövekedett adatmennyiségek kezelésének problémájára.

ebben az időszakban a legnagyobb kihívást jelentő problémák gyakran nem csak a nyers skála, hanem a bővülő követelmények. Például talán támogatnia kell az A/B tesztelést, a gépi tanulási modelleket vagy a cső transzformált adatait egy ElasticSearch klaszterbe.

néhány dolog, amit érdemes megfontolni ebben a fázisban:

  • közel valós idejű: Valószínűleg nem lesz szüksége elosztott várólistára vagy közel valós idejű infrastruktúrára, csak sokkal később, mint gondolná. Nagyon sok bonyolultsággal jár az összes lehetséges meghibásodási mód kezeléséhez, ami korán nem éri meg. Miután a ROI kalkulusnak van értelme, próbálja ki a Kafka vagy a Cloud Pub/Sub alkalmazást.
  • skálázhatóság: egyetlen monolitikus Spark klaszter esetén szinte biztosan problémákba ütközik az erőforrások vitatása. Amikor megteszed, érdemes feltárni a teljesen rugalmas munkakör-hatókörű Szikraklasztereket.
  • Biztonság & Ellenőrzés: Előfordulhat, hogy egy bizonyos ponton részletesebb hozzáférési vezérlőket szeretne érvényesíteni az adattárház adataihoz. A BigQuery használata esetén adatkészlet-hozzáférést biztosíthat a Google csoportokhoz, és programozottan kezelheti ezt a hozzáférést a Telepítéskezelő segítségével. A BigQuery ellenőrzési naplókat is biztosít a felhasználói lekérdezések megértéséhez. Egyéb eszközök, mint például az Apache Knox és az Apache Sentry állnak rendelkezésre az on-prem biztonsági megoldásokhoz.
  • A/B tesztelés: a házon belüli A/B teszteléshez és a kísérletek támogatásához sajnos nincs sok off-the-shelf megoldás. Valószínűleg a legjobb megoldás az olyan Spark-feladatok csővezetékének kiépítése, amelyek táblákat töltenek be az adattárházában.
  • Gépi tanulás: a funkciók kibontásához további adatvezetékeket építhet a Spark-ban. Maguknak a modelleknek ismét kicsinek kell lenniük. A feldolgozott funkciók valószínűleg elég kicsiek ahhoz, hogy elférjenek egy gépen, így a modelleket a scikit-learn vagy a TensorFlow segítségével edzheti. Ha egy gép már nem elég, használhatja Spark MLlib vagy elosztott TensorFlow.

a jövő

izgalmas látni, mennyire javult az adatinfrastruktúra ökoszisztéma az elmúlt évtizedben. Hosszú utat tettünk meg a Hadoop-klaszterek és a torna bébiszitterétől, hogy az adatfeldolgozási logikánkat térképekké kényszerítsük, és a kínos Java-ban csökkentsük. Akkoriban az adatinfrastruktúra építése olyan volt, mintha egy felhőkarcolót próbálnánk felépíteni egy játékkalapács segítségével.

ma, van egy csodálatos sokszínűségét eszközök. A Spark egyértelműen dominált, mint a Hadoop MapReduce minden kereskedelmet helyettesítő jack; ugyanez történik a TensorFlow-val, mint gépi tanulási platformmal. Nagyon kevés kivételtől eltekintve manapság nem kell a semmiből építenie az infrastruktúrát vagy az eszközöket házon belül, és valószínűleg nem kell fizikai szervereket kezelnie. A felhőkarcoló már ott van, csak ki kell választania a festék színeit.

a szerver nélküli jövő-ez teljesen így lesz

előretekintve arra számítok, hogy az adatinfrastruktúra és az eszközök továbbra is a teljesen szerver nélküli platformok felé haladnak — a DataBricks most jelentette be a Spark ilyen ajánlatát. A kiszolgáló nélküli infrastruktúra lehetővé teszi az aggodalmak elegáns szétválasztását: a felhőszolgáltatók aggódhatnak a hardver, a devops és a szerszámok miatt, lehetővé téve a mérnökök számára, hogy azokra a problémákra összpontosítsanak, amelyek egyedülállóak (és azokhoz igazodnak). A jövő hardverhibák, ZooKeeper freakouts vagy fonal erőforrásokkal kapcsolatos problémák nélkül történik, és ez nagyon klassz.

Szerkesztés: linkek hozzáadása néhány korábbi bejegyzéshez, amelyet a Thumbtack adatinfrastruktúrájáról írtam:

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé.

lg