Az adatok vállalati felhasználása napjainkban jellemzően folyamat-centrikus: adott egy üzleti funkció, egy folyamat, melynek működéséhez, valamint a kapcsolódó alkalmazásokhoz, elemzésekhez előzetesen azonosítják a megfelelőnek gondolt adatforrásokat, amiket különböző eljárások kivonatolják, transzformálják és betöltik (ETL) bizonyos előre definiált struktúrákba megfelelő rendszerességgel. A fenti folyamat bonyolultsága és erőforrás igényes volta miatt jellemző, hogy csak a fontos (vagy előzetesen fontosnak vélt) adatokkal dolgoznak, valamint kizárólag belső és jól strukturált adatforrásokra hagyatkoznak. A feldolgozandó adatok megfelelő időközönként így egyik rendszerből a másikba vándorolnak, ahol végül az adott üzleti funkció(k) számára szükséges kalkulációk megtörténhetnek. Ha infrastruktúrális szempontból vizsgáljuk ezt a működést, akkor a data-to-compute elv érvényesülését látjuk, magyarul a kalkulációkhoz, a számítási kapacitáshoz viszik az adatokat.
A napjainkban tapasztalható "adatrobbanás" miatt a jövő viszont nem ebbe az irányba mutat, lehetetlen küldetés lesz az adatok ilyen mértékű mozgatása változatlan frekvenciával. Ha egy vállalat elkötelezett az információ-centrikus működés iránt, a fenti struktúrán túlmutató megoldás felé kell elmozdulnia.
A Hadoop ökoszisztéma lehetőséget ad arra, hogy ezt a folyamat-centrikus megközelítést az úgynevezett információ (adat)-centrikus gondolkodás váltsa fel. Hadoop használata során nem az adatokat visszük a kalkulációkhoz, hanem fordítva, a kalkulációs feladatokat az adatokhoz. A Hadoop architektúra alapvető tulajdonsága a klaszteren belüli adatvándorlás minimalizálása, amit az ökoszisztéma alkalmazásai is kihasználnak. Azon vállalatok, amelyek felismerték, hogy a jó döntésekhez, a sikeres menedzsmenthez nem elégséges az adatvagyon egy-egy (szűk) szeletének elemzése, azok a rendelkezésükre álló összes adatot igyekszenek felhasználni a napi működésük során. Nem szorítkoznak csak a belső és strukturált adataikra, hanem intenzíven gyűjtenek külső forrásokból is, és bevonják elemzéseikbe a kevésbé jól strukturált adatokat is.
A hagyományos információs infrastruktúrák komoly problémákkal küzdenek:
- A hagyományos vállalati információs infrastrukturában a forrásadatok elérhetősége jelentősen korlátozott. Az adatok nem vesznek el persze, léteznek (pl. szalagos) arhívumok, amik tartalmukat tekintve akár megfelelő forrást is jelenthetnének különböző nagy volumenű elemzésekhez, viszont azok tárolási jellegükből fakadóan lényegében alkalmatlanok ilyen célú felhasználásra. Ezt a problémát elkerülvén, mondhatnánk, hogy tároljuk adatainkat hozzáférhetőbb helyen, például RDBMS-ben. A feladat részben megoldható is lenne, azonban nagyon költséges és semmiképpen sem univerzális megoldás. Nem tárolhatjuk tehát mindenünket relációs adatbázisban, ezért kénytelenek vagyunk szelekáltni. A szelektálást viszont akármennyire is akkurátusan tesszük, esélytelen, hogy valamit véletlenül hátra ne hagyjunk.
- Az adatokat előzetesen modellezni kell és formázni (transzformálni), még jóval a felhasználás előtt. Transzformálás során pedig elveszhetnek fontos információk.
- Az elemzés költségei hagyományos információs infrastruktúrában jelentősen megnövekednek. A meglévő alkalmazások korlátokat szabnak, mivel jellemzően magas kihasználtsággal működnek, és a korlátozott skálázhatóságuk miatt elképzelhető, hogy (belátható időn belül és indokolt költségszinten) nem lehetséges a funkcionalitásuk további bővítése: például új riport hozzáadása a meglévő BI rendszerhez, vagy újabb üzleti elemzések készítése. A fejlesztési ciklusidők az infrastruktúra bonyolódásával ráadásul folyamatosan hosszabbodnak, a BI csapat feladatlistája ezzel párhuzamosan növekszik, így az üzleti területektől érkező igények megvalósítása is egyre lassabb lesz, sok esetben egy üzleti problémára, kérdésre a megoldás olyan későn érkezik, hogy maga a kérdés már érvényét veszti. Persze idővel az üzleti igények, problémák is változnak, előfordulhat, hogy az üzleti területek nem is tudják (vagy nem is akarják) pontosan megfogalmazni kezdetben, hogy pontosan mely adatokat szeretnék, amíg nem látják és nem tudják értékelni az azokból kinyerhető információt. A BI csapat így az infrastruktúra korlátai és az üzleti igények között örlődve nem tudja biztosítani azt az agilitást, amit elvárnának tőle, presztízsét veszti, legrosszabb esetben akár a funkcióját is.
- A teljes infrastruktúra tehát olyan komplex lesz, hogy idővel elveszti alkalmazkodási képességét, képtelenné válik lekövetni a valós világ kihívásait. Az adatok rendszerek közti áramlása fenntarthatatlan méreteket ölt, rendszer-szintű problémákat okozva ezzel.
A fentiekre a Hadoop megoldást kínál:
- A Hadoop klaszter aktív arhívumként teljeskörű és valódi hozzáférést biztosíthat a teljes adatvagyonhoz (annak eredeti formájában), korlátlanul, bármilyen típusú adatforrásról is legyen szó. Akár az új "Staging Area"-ként is szolgálhat a vállalati információs infrastruktúrában.
- Hadoop az adatok egyetlen, autentikus forrásaként funkcionálhat, mindezt jelentős árelőnnyel. A tároláshoz nem szükséges előzetes adatelemzés, transzformációk elvégzése vagy struktúrák kialakítása, csak a HDFS-re másoljuk az adatokat, és azok attól kezdve rendelkezésre is állnak akár további feldolgozásra. Ha viszont elemezni szeretnénk az adatainkat, a klaszterben rejlő hatalmas erőforrásokat is kihasználhatjuk, és a szükséges transzformációkat nagyon gyorsan és olcsón elvégezhetjük az általunk kiválasztott adatokon. A nyers és feldolgozott adatok minden további nélkül tárolhatók akár egymás mellett is, támogatva azok "újrahasznosítását".
- Önkiszolgáló, felfedező jellegű BI szolgáltatást nyújthatunk a Hadoop klaszteren az elemzők számára, akik hozzáférhetnek olyan adatokhoz is, amik (még) nem elérhetők a vállalati adattárházakban. Schema-on-read képesség segítségével megspórolhatók olyan (akár utólag indokolatlannak bizonyult) strukturálási feladatok is, amik relációs adatbázisba töltés esetén elkerülhetetlenek. A felhasználók ilyen típusú tevékenysége során az új üzleti kérdésekre gyors válasz adható, a BI csapat feladatlistájának rövidülhet, az előzetes elemzések eredményeit felhasználva pedig a fejlesztési ciklusidők is csökkenthetők. A Hadoop szinte korlátlan lineáris skálázhatóságának köszönhetően a klaszter a terhelés növekedését is jól le tudja követni.
- Egyszerűsödik a információs architektúra, megszüntethetők a rendszerek közti fölösleges áttöltések. Az adatok (nyers és feldolgozott formában) rendelkezésre állnak a klaszterben bárki/bármely alkalmazás számára. Könnyen garantálható, hogy az azonos adatforrásra építő alkalmazások garantáltan ugyanabból az adathalmazból dolgozhassanak, elkerülve ezzel bizonyos váratlan, inkonzisztens, magyarázatra szoruló helyzeteket. A Hadooppal megvalósítható a valódi single-version-of-truth, úgy, hogy ezzel párhuzamosan BI szervezet agilitása is növelhető.
