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 informatikamenedzsment háromszögében lényeges eltolódások tapasztalhatóak a rugalmasság és a rövidtá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ógia 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övidtávú projektcé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ó riportok gyakran moshatnak össze alkalmazásspecifikus kifejezéseket a sokszor hasonló vállalati terminológia 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últú 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 melyek 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… 

 

 

 

forrás

[1] https://www.linkedin.com/pulse/kimball-vs-inmon-redux-bill-inmon-gatic/ 

[2] https://www.proquest.com/docview/214683052?sourcetype=Scholarly%20Journals 

[3] TEN D 05 Second Quarter For Data Warehouse Project Managers, Larissa Moss

[4] https://www.pmi.org/learning/library/leveraging-new-practice-standard-project-estimating-6222 

[5] https://www.gartner.com/en/articles/what-is-a-digital-immune-system-and-why-does-it-matter