Nemrégiben volt szerencsém meghallgatni egy webinart a Cloudera szervezésében, amit az adattárház építés "nagymestere" Ralph Kimball tartott a Hadoopról (Building a Hadoop Data Warehouse: Hadoop 101 for EDW Professionals címmel). Szerencsére az előadást rögzítették, így akit érdekel, az visszanézheti itt (via Vimeo). Érdemes ellátogatni a Cloudera hivatalos oldalára is, ahol a videó mellett a bemutatott slide-ok és egyéb kapcsolódó anyagok is megtalálhatók. (A Cloudera az anyagok megtekintéséért elkér néhány adatot rólunk.)
Kimball egy nagyon izgalmas, ingoványos területről, a Hadoop és a “hagyományos” vállalati adattárházak viszonyáról beszélt, az adattárház-építők és a BI szakterület képviselői számára kifejezetten érdekes aspektusból. Szerintem mindenképpen érdemes megnézni a teljes előadást, a webinar bő egy óra, amiben van egy kis Cloudera marketing rész is a végén.
Az előadásnak lesz folytatása is május végén: EDW 101 for Hadoop Professionals címmel, ami a vállalati adattárházakról fog szólni, Hadoopban már jártas szakembereknek.
!SPOILER ALERT!
Habár tényleg érdemes megnézni a videót, az alábbiakban azért megpróbálom összefoglalni röviden az általam fontosnak vélt üzeneteket.
Kimball szerint a Hadoop, mint technológiai megoldás, olyan célok megvalósítására is alkalmas, ami megkerülhetetlenné teszi a vállalati adattárház infrastruktúrában. Ha felidézzük az adattárház-fejlesztés misszióját (amennyiben létezik ilyen), annak mindenképpen része olyan feladatok megoldása, mint az összes potenciális adatforrás, a teljes vállalati adatvagyon azonosítása (lehetőségeinkhez mérten), a használható és hozzáférhető elemek kiválasztása, melyekből majd logikailag centralizált adattárházat alkothassunk, annak érdekében, hogy hatásos kiaknázással támogassuk a jobb döntéshozatalt. Ha megfelelő távolságból nézzük ezeket a feladatokat, akkor a Hadoop ezen, alapelveinknek is tekinthető feladatokban segít azzal, hogy kiszélesíti az adattárház és az üzleti intelligencia határait.
A relációs adatbázisok hagyatéka
Az elmúlt évtizedekben a relációs adatbázis-kezelők látványosan sikeresnek bizonyultak, ezért valószínűleg a jövőben is szívesen fogjuk azokat használni. Kimball ugyanakkor azt állítja, hogy ezek az eszközök talán túl sikeresek is lettek.. túl sok mindent próbáltunk és próbálunk a mai napig megoldani a relációs adatbázisok segítségével. Kissé egysíkúvá is vált a gondolkodásunk. A relációs adatbázis-kezelők számára például szinte megkerülhetetlen akadályt jelentenek az új adattípusok, azok tárolása és feldolgozása, mégis próbálkozunk velük. A relációs adatbázisok nem képesek kezelni bizonyos új formátumokat, valamint nem bizonyulnak hatékony eszköznek nagyon nagy mennyiségű adat elemzési célú feldolgozására, és nem biztosítanak nagy (be)töltési és lekérdezési sebességet egyszerre. A múltban számtalan példa volt arra, hogy olyan adatokat erőltettünk adatbázisokba, amik nem feltétlenül valók oda, a Hadoopban ezzel szemben viszont olyan lehetőségek rejlenek, ami előrevetíti, hogy a jövő nem ebbe az irányba mutat.
Amit megszoktunk, nagyon megszerettünk a relációs adatbázis-kezelőkben, egyebek mellett, az a lekérdezési nyelvük. SQL vagy SQL-szerű nyelveket szeretnénk a továbbiakban is használni, a relációs adatbázisok korlátai nélkül. Kimball szerint erre jó megoldás lehet a Hadoop.
Hagyományos versus Hadoop adattárház
Kimball kiemelte, hogy a Hadoop DW (adattárház) a következő architekturális különbség miatt válhat valós alternatívává:
| Hagyományos DW | Hadoop DW | |
| adatbázis táblák | Tárolási réteg | HDFS fájlok |
| rendszer táblák | Metaadat réteg | HCatalog (Hive) |
| SQL lekérdező nyelv | Lekérdezési réteg | számtalan lekérdező motor |
Ha a relációs adatbázis-kezelők tárolási, metaadat és hozzáférési rétegeit vizsgáljuk, bármely gyártó termékeit is nézzük, azt látjuk, hogy ez a három réteg együtt, összecsomagolva működik megfelelően, míg a Hadoopban ezek a rétegek szeparáltak, nagyszerű módon mégis jól együttműködnek.
Látni kell, hogy az RDBMS-ek esetében ahhoz, hogy ebben a tökéletesen egybecsomagolt struktúrába bekerüljenek az adatok (majd lekérdezhetők legyenek), azokat előzetesen "ETL-ezni" kell. (Holott tudjuk, hogy ez az adatelemzési feladatok legköltségesebb része.) Ezzel szemben, habár a Hadoopban a három réteg elkülönült, a többszörös hozzáférési pontok segítségével a rétegek mégis könnyen átjárhatók. A számtalan nyílt forráskódú, közösség által fejlesztett valamint kereskedelmi alkalmazás egyaránt eléri ugyanazt az adattárolási réteget (a HDFS fájlrendszert). Ha ugyanis az adatainkat HDFS fájlrendszerbe másoljuk, azt a rendszer olyan fájlokban tárolja, amiket a magasabb rétegekben működő alkalmazások is használni tudnak. A metaadat rétegben meghatározott sémák, az előzőekhez analóg módon, szintén elérhetők a hozzáférési rétegben működő alkalmazások számára. Kimball előadásában ahhoz hasonlította ezt a csodálatos képességet, mintha például az Oracle közvetlenül hozzá tudna férni DB2-ben tárolt adatokhoz és fordítva.
A Hadoopban ráadásul nem szükséges jól strukturált táblák előzetes létrehozása ahhoz, hogy az adatokkal dolgozni tudjunk. Egy fájlra a metaadat rétegen meghatározunk egy (vagy több!) kezdetleges sémát, és a lekérdező alkalmazásaink számára azonnal feldolgozhatóvá válnak a fájlrendszerben tárolt adatok. Ráadásul léteznek olyan Hadoop ökoszisztémában működő alkalmazások is, amik lehetőséget biztosítanak arra, hogy az adatfeldolgozás során, "on-the-fly" határozzuk meg a sémát (a metaadat réteg kihagyásával), még több rugalmasságot biztosítva ezzel az elemzők számára. (szerk.) Fontos látni a jelentős különbséget: az adatok letárolásához nincs szükség idő- és erőforrásigényes ETL folyamatokra, az adatstruktúrák definiálására csak akkor kell időt szánnunk, amikor az adatokat éppen feldolgoznánk.
"Felfedező" DW/BI (Exploratory DW/BI)
Kimball a Hadoopot két fő felhasználási célból javasolja vállalati adattárház környezetben: úgynevezett "felfedező" BI-t támogató erőforrásként, valamint extrém nagyteljesítményű adattárház üzemeltetési környezeteként.
A Hadoop egy nagyszerű eszköz lehet a kezünkben ahhoz, hogy a divergens vállalati adatvagyonban "kutassunk", vizsgálódjunk vagy olyan előzetes elemzéseket készítsünk, amik eredményeként például döntést hozhatunk arról, hogy milyen adatokat, milyen formában töltsünk a hagyományos relációs adattárházunkba további üzleti felhasználásra. A lekérdező nyelvek segítségével még azelőtt hozzáférhetünk adatainkhoz, és elemezhetjük azokat, mielőtt bármilyen transzformációt (ETL) végeztünk volna rajtuk. Fejlesztési projektekben ezzel a képességgel jelentős kockázatokat is tudunk kezelni. (szerk.)
Nagyteljesítményű Hadoop adattárház
Kimball előadásában bemutat egy 100, átlagosnak mondható szerverekből összeállított klasztert. Elképesztő erőforrások és kapacitások állhatnak rendelkezésünkre egy Hadoop klaszterben, ráadásul fajlagosan jóval olcsóbban, mintha hasonló teljesítményt szuperszámítógépek segítségével próbálnánk elérni.
Mivel a Hadoop az adatokat fájlokban tárolja, így a lekérdezési sebességek hagyományos módon meg sem közelítik a relációs adatbázis-kezelőkben tapasztaltakat. A probléma áthidalására több módszert is kitaláltak: egyik közülük az úgynevezett "parquet columnar" fájlok alkalmazása. Ezek olvasásra optimalizált, meghatározott sémával rendelkező fájlok. Ezek a fájlok az oszlopos tárolás minden előnyével rendelkeznek, és 10-szer gyorsabb hozzáférést biztosítanak a sima fájlokhoz képest. Fontos megjegyezni, hogy továbbra is fájlokról beszélünk, viszont sémájuk módosítható és UPDATE típusú változtatás is lehetséges bennük.
Látni kell, hogy ez a megoldás nem azt jelenti, hogy párhuzamosan két különböző architektúrát kell felépítenünk a nagy teljesítményű és a felfedezési célú felhasználásra, ugyanis a parquet és standard fájlok egymás mellett vígan megélnek. A parquet fájlok létrehozásával mindössze kiválasztunk olyan adathalmazokat, amiket gyors válaszidővel szeretnénk elérni (akár ugyanazon alkalmazásokon keresztül, amikkel a standard fájlokat érjük el), az architektúra érintetlen marad. A parquet fájlok mellett továbbra is lehetőség marad a nyers fájlok elemzésére. Hogy egy adathalmaz mikor "érik meg" arra, hogy parquet formátumban történjen annak tárolása, azt valószínűleg az élet határozza meg. Ha a vállalati adatvagyonból az elemzők azonosítanak olyan adatforrásokat (felfedező tevékenységük során), amiket interaktív alkalmazásokban szeretnének felhasználni, úgy valószínűleg indokolt az adatokat ebben a formátumban (is) tárolni a továbbiakban. Az is elképzelhető, hogy taktikai okokból olyan döntés születik, hogy meglévő ETL folyamatokat (vagy azok egy részét) Hadoop környezetben kívánják a továbbiakban futtatni. Ez esetben a sémák már ismertek, tehát azokat alkalmazva a parquet fájlokban és a töltési folyamatokat áthozva a Hadoop környezetbe a relációs adattárház könnyen tehermentesíthető.
A teljesítmény további fokozására megoldást kínál még az Impala, ami további 10-szeres gyorsulást igér a Hive-hoz képest. Tehát egy ugyanazon lekérdezés Hive-val futtatva standard fájlon kb. 100-szor annyi ideig is eltarthat, mint Impalával futtatva parquet fájlon.
| Fájl formátum | Lekérdező alkalmazás | Futási idő |
| standard fájl | Hive | 100 s |
| standard fájl | Impala | 10 s |
| parquet fájl | Hive | 10 s |
| parquet fájl | Impala | 1 s |
A Hive és az Impala közti teljesítmény-különbséget az okozza, hogy míg a Hive tradicionális MapReduce eljárást futtat a klaszter node-jain, az Impala ezzel szemben intenzíven kihasználja a klaszter (jelentős) memória erőforrásait.
A Hive és az Impala is SQL-szerű lekérdezési nyelvvel rendelkezik, ami jelentősen megkönnyíti azok használatát a DW/BI szakemberek számára.
Miért használjunk Hadoop-ot az EDW részeként?
Kimball szerint ennek stratégiai és taktikai okai lehetnek:
Stratégiai
- ki kell nyitni az adattárház kapuit az új adattípusok számára
- új típusú elemzések lehetetlenek lesznek RDBMS-ben
- felfedező típusú üzleti intelligencia meghonosítása a szervezetben (Exploratory DW/BI)
- aktív arhívum működtetése (olcsó tárolás, viszont jóval hozzáférhetőbb, mint a szalagos)
- párhuzamos hozzáférés és adatfeldolgozás különböző eszközökkel ugyanazon az adaton
- vállalati adat hub szerepének betöltése
Taktikai
- csökkenő üzemeltetési költségek
- lehetőség lineáris skálázásra
- magasfokú megbízhatóság biztosítása
- SLA megfelelés biztosítása
Hadoop sorsával kapcsolatos jóslatok
Az előadás végén Kimball megfogalmazott néhány jóslatot is:
- A Hadoop DW a hagyományos adattárház egyenlő partnerévé válik.
- Hadoop lesz az új adatforrások és új típusú elemzések stratégiailag kijelölt környezete.
- Extrém mértékű adatdiverzitás fogja jellemezni a jövő Hadoop rendszereit.
- Számtalan specializált elemző eszköz fog megjelenni Hadoopra (jellemzően SQL kiegészítéssel).
- A Hadoop elhozza a valódi felfedező, kísérletező üzleti intelligencia korszakát.
- Komoly BI rendszerek kötelező összetevőjévé válik.
- Szalagos arhívumok helyére lép folyamatos aktív arhívumként szolgálva az adattárházat.
