Adattárház és Data Lake építése az AWS-ben

Adattárház. Data tó. Tavi ház. Ha ezek közül a szavak közül egyik sem rezonál rád legalább egy kicsit, akkor a munkád nyilvánvalóan nem kapcsolódik az adatokhoz.

Ez azonban meglehetősen irreális feltevés lenne, hiszen ma már minden az adatokkal kapcsolatos. Vagy hogyan írják le ezt a vállalati vezetők:

  • Adatközpontú és adatvezérelt üzlet.
  • Adatok bárhol, bármikor, bárhogyan.

A Legfontosabb Eszköz

Úgy tűnik, az adatok egyre több vállalat legértékesebb eszközévé váltak. Emlékszem, a nagyvállalatok mindig sok adatot generáltak, gondoljunk terabájtnyi új adatra minden hónapban. Ez még 10-15 éve volt. Most azonban néhány napon belül könnyedén generálhat ekkora adatmennyiséget. Az ember megkérdezné, hogy valóban szükség van-e rá, még akkor is, ha ez olyan tartalom, amelyet bárki használni fog. És igen, biztosan nem 😃.

Nem minden tartalom lesz hasznos, és egyes részei nem is egyszer. Gyakran szemtanúja voltam a frontvonalon, ahogyan a vállalatok óriási mennyiségű adatot generálnak, hogy egy sikeres betöltés után használhatatlanná váljanak.

De ez már nem releváns. Az adattárolás – jelenleg a felhőben – olcsó, az adatforrások exponenciálisan nőnek, és ma már senki sem tudja megjósolni, mire lesz szüksége egy év múlva, ha új szolgáltatások kerülnek a rendszerbe. Ekkor még a régi adatok is értékessé válhatnak.

Ezért a stratégia a lehető legtöbb adat tárolása. De a lehető leghatékonyabb formában is. Így az adatok nem csak hatékonyan menthetők, hanem lekérdezhetők, újrafelhasználhatók vagy átalakíthatók és tovább terjeszthetők.

Nézzünk meg három natív módszert, hogyan lehet ezt elérni az AWS-en belül:

  • Athena Database – olcsó és hatékony, bár egyszerű módszer adattó létrehozására a felhőben.
  • Redshift Database – egy adattárház komoly felhőverziója, amely képes leváltani a jelenlegi helyszíni megoldások többségét, és nem képes utolérni az adatok exponenciális növekedését.
  • Databricks – az adattó és az adattárház egyetlen megoldásban való kombinációja, mindezen felül némi bónuszokkal.

Data Lake, az AWS Athena

Forrás: aws.amazon.com

Az adattó egy olyan hely, ahol gyorsan tárolhatja a bejövő adatokat strukturálatlan, félig strukturált vagy strukturált formában. Ugyanakkor nem számíthat arra, hogy ezek az adatok tárolásuk után módosulnak. Ehelyett azt akarja, hogy a lehető legatomosabbak és változatosabbak legyenek. Csak ez biztosítja a lehető legnagyobb újrafelhasználási lehetőséget a későbbi szakaszokban. Ha elveszítené az adatok atomi tulajdonságát közvetlenül az első adattóba történő betöltés után, akkor nincs mód arra, hogy ezt az elveszett információt visszaszerezze.

Az AWS Athena egy olyan adatbázis, amely közvetlenül az S3 tárolókönyökkel rendelkezik, és a háttérben nem futnak szerverfürtök. Ez azt jelenti, hogy ez egy igazán olcsó Data Lake szolgáltatás. A strukturált fájlformátumok, például a parketta vagy a vesszővel tagolt érték (CSV) fájlok tartják fenn az adatok szervezését. Az S3 vödör tartalmazza a fájlokat, és az Athena hivatkozik rájuk, amikor a folyamatok kiválasztják az adatokat az adatbázisból.

Az Athena nem támogatja az egyébként szabványnak tekintett funkciókat, például a frissítési utasításokat. Ezért kell az Athénát egy nagyon egyszerű lehetőségnek tekinteni. Másrészt segít megelőzni az atomi adattó módosítását egyszerűen azért, mert nem tudod 😐.

Támogatja az indexelést és a particionálást, ami alkalmassá teszi hatékony kiválasztási utasítások végrehajtására és logikailag különálló adattömbök létrehozására (például dátummal vagy kulcsoszlopokkal elválasztva). Vízszintesen is könnyen skálázható, mivel ez olyan bonyolult, mint új vödrök hozzáadása az infrastruktúrához.

  Hogyan lehet blokkolni a kulcsnaplózást a HP audio-illesztőprogramokkal az Elitebookokon

Érvek és ellenérvek

A figyelembe veendő előnyök:

  • Az a tény, hogy az Athena olcsó (csak S3 gyűjtőcsoportokból és használatonkénti SQL használati költségekből áll), a legjelentősebb előnyt jelenti. Ha megfizethető Data Lake-et szeretne építeni az AWS-ben, ez az.
  • Natív szolgáltatásként az Athena könnyen integrálható más hasznos AWS-szolgáltatásokkal, mint például az Amazon QuickSight adatvizualizáláshoz vagy az AWS Glue Data Catalog, hogy állandó strukturált metaadatokat hozzon létre.
  • A legjobb ad hoc lekérdezések futtatásához nagy mennyiségű strukturált vagy strukturálatlan adaton anélkül, hogy teljes infrastruktúrát kellene körülötte fenntartani.

A figyelembe veendő hátrányok:

  • Az Athena nem különösen hatékony az összetett kiválasztási lekérdezések gyors visszaküldésében, különösen akkor, ha a lekérdezések nem követik az adatmodell-feltevéseket arra vonatkozóan, hogyan tervezte az adatok lekérését az adattóból.
  • Ez egyben kevésbé rugalmassá teszi az adatmodell esetleges jövőbeni változásait illetően.
  • Az Athena nem támogat semmilyen további speciális funkcionalitást, és ha azt szeretné, hogy valami konkrét legyen a szolgáltatás része, akkor azt felül kell telepítenie.
  • Ha valamilyen fejlettebb megjelenítési rétegben várja a Data Lake adathasználatát, akkor gyakran az egyetlen választás, ha azt egy másik, erre a célra alkalmasabb adatbázisszolgáltatással kombinálja, mint például az AWS Aurora vagy az AWS Dynamo DB.

Cél és valós használati eset

Válassza az Athena lehetőséget, ha a cél egy egyszerű adattó létrehozása, fejlett adattárház-szerű funkciók nélkül. Így például ha nem számít komoly, nagy teljesítményű analitikai lekérdezésekre, amelyek rendszeresen futnak az adattón. Ehelyett az a prioritás, hogy egy egyszerű adattárolás-bővítéssel rendelkező, megváltoztathatatlan adatkészlet legyen.

Többé nem kell aggódnia a helyhiány miatt. Még az S3 tárolóhelyiség költsége is tovább csökkenthető egy adatéletciklus-politika megvalósításával. Ez alapvetően azt jelenti, hogy az adatokat különböző típusú S3-gyűjtőkön keresztül mozgatják, amelyek inkább archiválási célokat szolgálnak, lassabb visszaküldési idővel, de alacsonyabb költségekkel.

Az Athena nagyszerű tulajdonsága, hogy automatikusan létrehoz egy fájlt, amely az SQL-lekérdezés eredményének részét képező adatokból áll. Ezután elviheti ezt a fájlt, és bármilyen célra felhasználhatja. Jó választás tehát, ha sok lambda szolgáltatása van, és több lépésben dolgozza fel az adatokat. Minden lambda-eredmény automatikusan strukturált fájlformátumban lesz az eredmény, amely készen áll a további feldolgozáshoz.

Az Athena jó választás olyan helyzetekben, amikor nagy mennyiségű nyers adat érkezik a felhő infrastruktúrájába, és ezt nem kell feldolgoznia a betöltéskor. Ez azt jelenti, hogy csak gyors tárolásra van szüksége a felhőben, könnyen érthető szerkezetben.

Egy másik felhasználási eset az adatarchiválás céljára szolgáló dedikált terület létrehozása egy másik szolgáltatás számára. Ebben az esetben az Athena DB olcsó biztonsági mentési hellyé válna minden olyan adat számára, amelyre jelenleg nincs szüksége, de ez a jövőben változhat. Ezen a ponton már csak feldolgozza az adatokat, és továbbküldi.

Data Warehouse az AWS Redshifttől

Forrás: aws.amazon.com

Az adattárház egy olyan hely, ahol az adatokat nagyon strukturált módon tárolják. Könnyű betölteni és kihúzni. A cél az, hogy nagyszámú, nagyon összetett lekérdezést lehessen futtatni, sok táblát összetett csatlakozásokkal összekapcsolva. Különféle analitikai funkciók állnak rendelkezésre a különféle statisztikák kiszámításához a meglévő adatok alapján. A végső cél az, hogy a meglévő adatok felhasználásával jövőbeli előrejelzéseket és tényeket nyerjünk ki, amelyeket az üzleti életben hasznosíthatunk.

A Redshift egy teljes értékű adattárház rendszer. Hangolható és skálázható fürtszerverekkel – vízszintesen és függőlegesen, valamint a gyors, összetett lekérdezések visszaküldésére optimalizált adatbázis-tárolórendszerrel. Bár ma már szerver nélküli módban is futtatható a Redshift. Nincsenek fájlok az S3-on vagy bármi hasonlón. Ez egy szabványos adatbázis-fürtkiszolgáló, saját tárolási formátummal.

  Nagy frissítési gyakoriságú monitorra van szüksége irodai munkához?

Teljesítményfigyelő eszközökkel, valamint testreszabható műszerfali mérőszámokkal rendelkezik, amelyeket használhat és nézhet a teljesítmény finomhangolásához az Ön használati esetéhez. Az adminisztráció különálló műszerfalakon keresztül is elérhető. Némi erőfeszítést igényel, hogy megértsük az összes lehetséges szolgáltatást és beállítást, valamint azt, hogy ezek hogyan befolyásolják a fürtöt. De ennek ellenére sehol sem olyan bonyolult, mint korábban az Oracle szerverek adminisztrációja volt a helyszíni megoldások esetében.

Annak ellenére, hogy a Redshiftben különféle AWS-korlátok vannak, amelyek bizonyos határokat szabnak meg a napi használatban (például szigorú korlátozások az egyidejű aktív felhasználók vagy munkamenetek számára egy adatbázis-fürtben), az a tény, hogy a műveletek nagyon gyorsan végrehajtva bizonyos mértékig segít megkerülni ezeket a korlátokat.

Érvek és ellenérvek

A figyelembe veendő előnyök:

  • Natív AWS felhő adattárház szolgáltatás, amely könnyen integrálható más szolgáltatásokkal.
  • Központi hely a nagyon különböző forrásrendszerekből származó különféle típusú adatforrások tárolására, figyelésére és feldolgozására.
  • Ha valaha is szeretett volna egy szerver nélküli adattárházat a fenntartásához szükséges infrastruktúra nélkül, most megteheti.
  • Nagy teljesítményű elemzésekhez és jelentésekhez optimalizálva. A Data Lake megoldással ellentétben az összes bejövő adat tárolására erős relációs adatmodell áll rendelkezésre.
  • A Redshift adatbázismotor a PostgreSQL-ből származik, amely magas szintű kompatibilitást biztosít más adatbázisrendszerekkel.
  • Nagyon hasznos COPY és UNLOAD utasítások az adatok S3 tárolókból való be- és kirakodásához.

A figyelembe veendő hátrányok:

  • A Redshift nem támogatja nagy mennyiségű egyidejű aktív munkamenetet. A munkamenetek felfüggesztésre kerülnek, és sorban feldolgozásra kerülnek. Bár ez a legtöbb esetben nem jelent problémát, mivel a műveletek nagyon gyorsak, ez korlátozó tényező a sok aktív felhasználóval rendelkező rendszerekben.
  • Annak ellenére, hogy a Redshift számos olyan funkciót támogat, amelyek korábban már ismertek a kiforrott Oracle rendszerekből, még mindig nem ugyanazon a szinten. Előfordulhat, hogy a várt szolgáltatások némelyike ​​nem található meg (például a DB triggerek). Vagy a Redshift meglehetősen korlátozott formában támogatja őket (például a materializált nézetek).
  • Valahányszor fejlettebb egyéni adatfeldolgozási munkára van szüksége, azt a semmiből kell létrehoznia. Legtöbbször Python vagy Javascript kódnyelvet használ. Ez nem olyan természetes, mint a PL/SQL az Oracle rendszer esetében, ahol még a függvények és eljárások is az SQL lekérdezésekhez nagyon hasonló nyelvet használnak.

Cél és valós használati eset

A Redshift központi tárolója lehet az összes korábban a felhőn kívül élő adatforrásnak. Érvényesen helyettesíti a korábbi Oracle adattárház megoldásokat. Mivel ez is egy relációs adatbázis, az Oracle-ből való átállás még meglehetősen egyszerű művelet is.

Ha sok helyen léteznek olyan adattárház-megoldásai, amelyek nem igazán egységesek a megközelítés, a struktúra vagy az adatok feletti, közös folyamatok előre meghatározott halmaza tekintetében, akkor a Redshift nagyszerű választás.

Lehetőséget ad arra, hogy a különböző helyekről és országokból származó összes adattárház-rendszert egy fedél alá egyesítse. Továbbra is szétválaszthatja őket országonként, így az adatok biztonságban maradnak, és csak azok számára érhetők el, akiknek szükségük van rájuk. Ugyanakkor lehetővé teszi az összes vállalati adatot lefedő egységes raktári megoldás felépítését.

Egy másik eset lehet, ha a cél egy adattárház-platform építése önkiszolgáló szolgáltatások széleskörű támogatásával. Felfoghatja az egyes rendszerfelhasználók által felépített feldolgozási halmazként. Ugyanakkor ezek soha nem részei a közös platformmegoldásnak. Ez azt jelenti, hogy az ilyen szolgáltatások csak az alkotó vagy az általa meghatározott embercsoport számára maradnak elérhetők. A többi felhasználót semmilyen módon nem érintik.

Tekintse meg a Datalake és a Datawarehouse összehasonlítását.

  PowerPoint sablonok átméretezése

Lakehouse by Databricks az AWS-en

Forrás: databricks.com

A Lakehouse egy olyan kifejezés, amely valóban a Databricks szolgáltatáshoz kapcsolódik. Még ha nem is natív AWS-szolgáltatásról van szó, nagyon szépen él és működik az AWS-ökoszisztémán belül, és különféle lehetőségeket kínál más AWS-szolgáltatásokhoz való kapcsolódásra és integrációra.

A Databrick célja, hogy (korábban) nagyon különböző területeket kapcsoljon össze:

  • Megoldás strukturálatlan, félig strukturált és strukturált adatok Data Lake tárolására.
  • Megoldás adattárház strukturált és gyorsan elérhető lekérdezési adatokhoz (más néven Delta Lake).
  • Megoldás, amely támogatja az analitikát és a gépi tanulást a Data Lake-en keresztül.
  • Adatkezelés a fenti területek mindegyikéhez központosított adminisztrációval és készenléti eszközökkel a különböző típusú fejlesztők és felhasználók termelékenységének támogatására.

Ez egy közös platform, amelyet az adatmérnökök, SQL-fejlesztők és a gépi tanulással foglalkozó adattudósok egyszerre használhatnak. Mindegyik csoportnak van egy-egy eszközkészlete is, amelyeket a feladataik elvégzéséhez használhatnak.

A Databricks tehát egy mindenre kiterjedő megoldásra törekszik, és megpróbálja egyetlen megoldásban egyesíteni az adattó és az adattárház előnyeit. Ezen felül eszközöket biztosít a gépi tanulási modellek teszteléséhez és futtatásához közvetlenül a már beépített adattárolókon keresztül.

Érvek és ellenérvek

A figyelembe veendő előnyök:

  • A Databricks egy rendkívül méretezhető adatplatform. A munkaterhelés méretétől függően skálázódik, és ezt még automatikusan is teszi.
  • Ez egy együttműködési környezet adattudósok, adatmérnökök és üzleti elemzők számára. Ha mindezt ugyanabban a térben és együtt megtehetjük, nagy előny. Nemcsak szervezeti szempontból, hanem további költségeket is megtakarít, amelyek egyébként külön környezetekhez kellenek.
  • Az AWS Databricks zökkenőmentesen integrálható más AWS-szolgáltatásokkal, mint például az Amazon S3, az Amazon Redshift és az Amazon EMR. Ez lehetővé teszi a felhasználók számára, hogy könnyen átvigyenek adatokat a szolgáltatások között, és kihasználják az AWS felhőszolgáltatások teljes skáláját.

A figyelembe veendő hátrányok:

  • A Databrick-ek beállítása és kezelése bonyolult lehet, különösen azoknak a felhasználóknak, akik még nem ismerik a nagy adatfeldolgozást. Jelentős szintű technikai szakértelem szükséges ahhoz, hogy a legtöbbet kihozzuk a platformból.
  • Míg a Databricks költséghatékony a felosztó-kirovó árképzési modelljét tekintve, a nagyszabású adatfeldolgozási projektek esetében még mindig költséges lehet. A platform használatának költségei gyorsan összeadódnak, különösen, ha a felhasználóknak növelniük kell erőforrásaikat.
  • A Databricks számos előre elkészített eszközt és sablont kínál, de ez korlátozhatja azokat a felhasználókat, akiknek több testreszabási lehetőségre van szükségük. Előfordulhat, hogy a platform nem megfelelő azoknak a felhasználóknak, akik nagyobb rugalmasságot és nagyobb kontrollt igényelnek a nagy adatfeldolgozási munkafolyamataik felett.

Cél és valós használati eset

Az AWS Databricks a legmegfelelőbb olyan nagyvállalatok számára, amelyek nagyon nagy mennyiségű adatot tartalmaznak. Itt lefedheti a különböző külső rendszerekről származó különféle adatforrások betöltésének és kontextusba helyezésének követelményét.

Gyakran a követelmény valós idejű adatszolgáltatás. Ez azt jelenti, hogy attól kezdve, hogy az adatok megjelennek a forrásrendszerben, a folyamatoknak azonnal fel kell venniük, és azonnal vagy minimális késleltetéssel fel kell dolgozni és eltárolni az adatokat a Databricksben. Ha a késleltetés meghaladja a percet, az csaknem valós idejű feldolgozásnak minősül. Mindenesetre mindkét forgatókönyv gyakran elérhető a Databricks platformmal. Ez elsősorban az adapterek és valós idejű interfészek nagy mennyiségének köszönhető, amelyek számos más AWS natív szolgáltatáshoz csatlakoznak.

A Databricks könnyen integrálható az Informatica ETL rendszerekkel is. Amikor a szervezeti rendszer már széles körben használja az Informatica ökoszisztémát, a Databricks jól kompatibilis kiegészítője a platformnak.

Végső szavak

Mivel az adatmennyiség továbbra is exponenciálisan növekszik, jó tudni, hogy vannak olyan megoldások, amelyek hatékonyan megbirkózhatnak ezzel. Ami egykor rémálom volt az adminisztráció és a karbantartás, most nagyon kevés adminisztrációs munkát igényel. A csapat arra koncentrálhat, hogy értéket teremtsen az adatokból.

Igényeitől függően válassza ki a megfelelő szolgáltatást. Míg az AWS Databricks olyan dolog, amelyhez valószínűleg ragaszkodnia kell a döntés meghozatala után, a többi alternatíva sokkal rugalmasabb, még ha kevésbé képes is, különösen a szerver nélküli módok. Nagyon könnyű később áttérni egy másik megoldásra.