Ahhoz, hogy a DataLake koncepciót a megfelelő polcra tudjuk tenni szakmai eszköztárunkban, fontos egy kis elméleti kitekintéssel kezdeni. Amikor új adattárházak tervezésével foglalkozunk, alapvetően az Inmon féle, vagy a Kimball féle megközelítést vesszük alapul.
Kimball megközelítésében a társrendszerek által küldött adatokat dimenzionális megközelítéssel csillagsémában tároljuk, melyekből az adatok könnyen és gyorsan kiforgathatóak adatpiac szintre. Tehát ez a gyakorlat arra a kérdésre ad választ, hogy alkalmazásainkból miképpen tudunk a leghamarabb üzletileg riportálható formában adatot kinyerni, egyfajta bottom-up megközelítéssel. [1]
Inmon ezzel szemben azt képviseli, hogy adattárházunk elődleges célja a vállalati terminológia szerint feltett kérdések megválaszolása top-down megközelítésben, tehát nem az alkalmazásszintű adatok felhasználásában hisz. Teljesen mást jelenthet egy bank retail üzletágának az „ügyfél” kifejezés és mást egy wholesale, vagy éppen egy Corporate üzletágnak. Biztosítók esetén ilyen terminológiai nehézséget jelenthetnek a termékekhez kapcsolódó definíciók (élet, nem élet, kiegészítő biztosítások), melyeket egy Inmon szellemében felépített adattárháznál felsővezetői szinten definiálni szükséges.
Napjainkban azonban az informatika menedzsment háromszögében lényeges eltolódások tapasztalhatóak a rugalmasság és a rövid távú költséghatékonyság javára, ugyanakkor a jövőállóság kárára. Pontosan itt kapcsolódik be a Datalake koncepció, ahol:
Nem szempont a Kimball-i architektúrában megálmodott csillagsémás letárolás és az adatok relatíve könnyen, gyorsan kiforgatható megjelenítése, melyek DW szinten megfelelően normalizált adatokon alapulnak.
Nem szempont az Inmon-i egységes vállalati terminológiai szerinti adattárolás és riportolás, illetve az ezt megelőző társterületi együttműködés.
Egyetlen szempont az aktuális adatok letárolása, akármilyen – jellemzően forrásrendszeri –struktúrában, ezzel egy nagyon rövid távú projekt cél teljesítése, aminek stratégiai jelentősége jellemzően nincs (vagy ha van, akkor a jövőállóság drasztikusan sérül), de még középtávú fenntarthatósága is gyakran megkérdőjelezhető. A jövőállóság azért sérülhet könnyen, mert bizonyos előre nem tervezett, de aztán mégis szükségessé váló riporttok gyakran moshatnak össze alkalmazásspecifikus kifejezéseket a sokszor hasonló vállalati terminológiai szerinti kifejezésekkel. Egy egyszerű példán szemléltetve egy menedzsment riport tartalmaz magánszemélyekre és nem magánszemélyekre vonatkozó adatokat úgy, hogy az egységes vállalati terminológia szerint az egyéni vállalkozók a nem magánszemélyekhez tartoznak, míg alkalmazás szinten a magánszemélyekhez.
A fenti példa alapján láthatjuk, hogy a nagymúlti Inmon-i, vagy Kimball-i szellemben fejlesztett adattárházak iparági tapasztalatok szerint valós, hosszú távon is fenntartható üzleti értéket hordoznak. Olyan „raktárak”, melyek gyorsan költöztethetőek, átrendezhetőek, visszamenőleg is tudjuk vizsgálni „raktárkészletünk” változását. A DataLake szellemében épült modernkori adattárház azonban egy „tó”, ami elnyeli a régen nem használt Csepel-biciklit, vagy éppen a használt akkumulátort.
Bár a fenti példa alapján úgy tűnhet, hogy DataLake-et bevezetni sosem célszerű, ez korántsem igaz. Egy átlagos nagyvállalatnál történő alkalmazása során viszont érdemes mérlegelnünk a kevésbé szakmai síkon jelentkező hajtóerőket:
Azért szeretnénk e bevezetni, mert a társrendszeri ellenállással szemben nincs ütőkártyánk?
Fejlesztőink nem adattárházas közegben szocializálódtak, így egyfajta quick-win-ként tekintünk a DataLake koncepció alkalmazására?
Esetleg menedzsment határidő gyors és olcsó teljesítése során indulunk a kisebb ellenállás irányába?
Végül pedig lássuk, hogy melyeknek lehetnek a megfelelő helyzetek egy DataLake bevezetésére:
Olyan valós, de kevéssé előrelátható technológiai ok, ami szükségessé teszi a lépcsőzetes bevezetést (pl. kivezetés alatt álló komplex, monolitikus rendszer GDPR-megfelelése)
Valamely kiemelt stratégiai célunkhoz nagyszámú, de heterogén (strukturált, nem strukturált) adat azonnali gyűjtése szükséges, azonban a jelenben nem láthatók az igények a későbbi kiaknázással kapcsolatban (big data problémakör).
A DataLake-be kerülő adatokat felhasználjuk mesterséges intelligencia modellek betanítására (gépi tanulás), például előrejelző logikák fejlesztéséhez.
Folyamatosan érkező (streaming) adatok azonnali feldolgozása szükséges, amelyeknél az algoritmusok korábbi adatokon való újrafuttatása is szükséges.
Félő, hogy az utóbbi esetekkel fogunk ritkábban találkozni egy hagyományos nagyvállalatnál…
