Mikor használjunk stage területet?

Adattárházak és üzleti intelligencia rendszerek betöltését kétféleképpen is megvalósíthatjuk:

  1. A forrásrendszerek adatait először egy átmeneti - úgynevezett Stage - területre másoljuk, majd a Stage területről töltjük az adattárházba
  2. A forrásrendszerek adatait közvetlenül az adattárházba töltjük

Mindkét módszernek vannak előnyei és hátrányai. Amíg DTS-t, az SQL Server 2000 adat-transzformációs eszközét használtunk az adattárház feltöltésére, rendszerint használtunk stage területet. De mi a helyzet az Integration Services (SSIS) használata esetén?

Az SSIS új Data Flow szolgáltatásai révén, szinte minden adat-transzformációt meg tudunk valósítani a betöltés során, „on the fly”, a memóriában (pipeline), így elvileg feleslegessé válhatna az adatok átmeneti, stage területen történő tárolása. Elvileg. De nézzük meg, mit mutat a gyakorlat.

Mikor/miért használjunk stage területet?

A következőkben összeszedtem azokat az érveket, amelyek a stage használata mellett szólnak. Ezek:

1. Időkorlát

Az adattárházunkat vagy Üzleti intelligencia rendszerünket akkor tudjuk tölteni, amikor azok forrásrendszerei „alszanak”. Felhasználóik nem visznek fel új rendeléseket, nem állítanak ki számlákat, …

Képzeljük el, hogy ezen forrásrendszerek este nyolckor zárnak, az éjszakai mentések pedig éjfélkor indulnak. Van tehát összesen 4 óránk, hogy adataikat letöltsük. Ezért amilyen gyorsan csak lehet, letöltünk minden adatot a forrásrendszerekből egy átmeneti (stage) területre, majd ez követően töltjük be adattárházunkat (ezt a folyamatot ráérünk éjfél és reggel nyolc között megvalósítani)

2. Forrásrendszerek terhelésnek minimalizálása

Elképzelhető, hogy üzleti intelligencia rendszerünk egy részét naponta rendszeresen, vagy ad-hoc jelleggel tölteni kell. (Például napközbeni zárás után azonnal) Ez utóbbi esetben, olyan időpontban kell forrásrendszereinket lekérdezni, amikor azt annak felhasználói még javában használják. (Ilyenkor mennek az üzemeltetésre a telefonok, hogy „nem tudok lezárni egy számlát, mert olyan lassú a rendszer”, …)

Ezért ilyenkor is az a cél, hogy olyan kevés ideig használjuk a forrásrendszerek erőforrásait, amilyen röviden csak lehet.

3. Hálózati kapcsolatok fenntartásának minimalizálása

Távoli szerverek adatait kell feldolgoznunk, olyan hálózatokon, amelyek megszakadhatnak. Ilyenkor is cél, hogy minél rövidebb ideig használjuk a hálózatot. Nyerjük ki a szükséges információkat minél gyorsabban, aztán majd később átalakítjuk, betöltjük őket az adattárházba.

4. Újrafuttathatóság

Tegyük fel, hogy a betöltési folyamat programhiba miatt megszakad. Kijavítjuk a hibát, majd újrafuttatjuk a betöltő programot. Ha van stage területünk, akkor onnan, ha nincs akkor sajnos újra le kell válogatnunk forrásrendszereink adatait.

5. Forrásadatok archiválása

Gyakran előfordul, hogy a forrásadatokat, illetve azoknak adattárházba betöltött részét az újrafuttathatósági vagy archiválási okok miatt sokáig meg kell őriznünk. Ebben az esetben is először a stage területre töltjük az adatokat, majd innen archiváljuk és töltjük be az adattárházba

6. Integritás megőrzése

Elkezdjük adatainkat betölteni az adattárházba közvetlenül a forrásrendszerekből, amikor kiderül, hogy egyik forrásrendszerünket nem tudjuk elérni. Ott állunk egy félig feltöltött adattárházzal…

Nem fordulhat elő ilyen hiba, ha az adattárházunk feltöltését azután kezdjük meg, miután minden forrásadatot sikeren letöltöttünk a stage területre.

7. Eltérő frekvenciájú adatok bevárása

Egy adatpiac vagy adatkocka feltöltéshez olyan adatokra van szükségünk, amelyek naponta többször, naponta egyszer, hetente egyszer, …, különböző időpontokban keletkeznek. A heti adatokat hetente egyszer, a többi adatot naponta le fogjuk válogatni a forrásrendszerekből.

Stage terület használata nélkül nehéz lenne parkoltatni valahol a napi adatokat, majd a heti adat megérkezése után betölteni az egészet az adatpiacba

8. Fejlesztési szempontok

A szoftverek nagy részét már Indiában fejlesztik. Előbb utóbb hasonló sorsa fog jutni az adattárház fejlesztések egy része is. Felmérjük itthon az igényeket, leválogatjuk a forrásrendszerek adatait a stage területre, majd az igényeket a stage terület adataival együtt DVD-n, vagy más adathotdozón kiküldjük a fejlesztőknek. Aláírunk egy titoktartási megállapodást és kész. A fejlesztők stage területtől megírják a betöltőket, visszaküldik nekünk, mi pedig a stage letöltése után meghívjuk az adattárházat feltöltő programokat.

Ez most még utópiának tűnik, de a technika fejlődésével egyre inkább elválik a fejlesztés és használat helye. Ezelőtt három évvel még nekem is le kellett utaznom a vidéki üzleti intelligencia rendszerek fejlesztéséhez. Ma már csak felhívnak, elmondják az igényeket, én pedig távolról megvalósítom.

Az eddigi érvek mind amellett szóltak, hogy adatainkat ne töltsük közvetlenül adattárházba, hanem először válogassuk le őket egy úgynevezett Stage területre, majd innen töltsük őket az adattárházba.

Mikor/miért nem használunk stage területet?

Ritkán, de előfordulnak esetek, amikor nem használunk Stage területet, mert

  1. egyszerűbb mindent egy olyan SSIS Package-ben megírni, karbantartani, amely a leválogatástól kezdve a dimenzió betöltésig minden ETL folyamatot megvalósít.
  2. Stage terület használata nélkül a teljes betöltési folyamat rövidebb. (nem írunk diszkre, hanem mindent „on the fly”, a memóriában oldunk meg)

A fentiekből választ kaphattunk arra, hogy mikor szükséges Stage területet használnunk adattárházunk feltöltéséhez. Ha úgy döntöttük, hogy szükséges Stage területet használnunk, már csak azt kell tisztáznunk, hogy hol legyen a Stage, azaz hol állomásoztassuk a forrásrendszerek adatait. Fájl rendszerben, vagy adatbázisban? Illetve mikor használjunk fájl rendszert, és mikor használjunk adatbázist?

Hol legyen a stage?

Vizsgáljuk meg egy példán keresztül, hogy hol képezhetünk Stage területet. Tételezzük fel, hogy forrásadatainkat Informix adatbázisban, UNIX-on tároljuk. Ebben az esetben a Stage lehet:

  1. Informix adatbázisban a UNIX szerveren
  2. szövegfájlban a UNIX szerveren
  3. szövegfájlban a Windows szerveren (adattárház szervere)
  4. SQL adatbázisban a Windows szerveren

Mérlegelnünk kell, hogy mi a fontos számunkra: a forrásrendszerek lehető legkisebb terhelése, vagy a könnyebb, saját rendszeren belüli adatelérés.

Ha a cél, vagy a követelmény azt diktálja, hogy a lehető legkevesebb ideig terheljük a forrásrendszereket, akkor a Stage terület legyen minél közelebb a forrásrendszerhez, illetve annak adatstruktúrájához. Minden más esetben célszerű a Stage területet saját szerverünkön képezni.

Adatbázis vagy fájl?

Általánosan elmondható, hogy akkor érdemes a Stage terület adatait SQL adatbázisban tárolni, ha

  1. azok szükségesek a Lookup számára
  2. és az indexelés javít a Lookup hatásfokán.

Minden más esetben célszerű az adatokat SQL 2000 esetén szövegfájl, SQL 2005 esetén raw fájl formában tárolni. A raw fájl az Integration Services új fájlformátuma, amely rendkívül hatékony adatelérést tesz lehetővé. (A raw fájlformátumról bővebben a BI tippek és trükkök blog-ban olvashat )

Hány napot tároljunk a Stage-en?

Erre a kérdésre természetesen nincs egzakt válasz, de a tervezés során mindenképpen válaszolnunk kell rá. Mi befolyásolja a Stage-en tárolt napok számát?

  1. Milyen könnyen tudjuk leválogatni a forrásrendszer adatait. Elképzelhető például, hogy erre csak egyetlen egyszer van lehetőségünk. Ebben az esetben az összes napi adatra szükségünk van a stage-en.
  2. Hány napot kell összevárni. Lásd: Eltérő frekvenciájú adatok
  3. Hány nap alatt tudjuk kijavítani a betöltő programok hibáját. (ha három nap alatt akkor célszerű három napnyi adatot tárolni a Stage-en, ha csak egy hét alatt, akkor egy heti adatra lesz szükségünk)

Optimalizálás a teljes betöltési folyamat gyorsítására

A tanulmány kezdetén azt állítottuk, hogy először leválogatunk minden adatot a stage területre MAJD UTÁNA áttöltjük őket az adattárházba. De miért utána? Miért nem transzformálhatjuk őket PÁRHUZAMOSAN a stage területre töltéskor? Hiszen már minden ott van a memóriában? Miért ne lehetne memóriába olvasás után elágaztatni a feladatokat (multicast transformation) és az egyik szál töltené a Stage-et, a másik az adattárházat?

Vannak esetek, amikor a párhuzamos, stage és adattárház töltés nem valósítható meg, és vannak esetek, amikor igen. Ezt a fentiek figyelembe vételével (időkorlát, fejleszthetőség, …) nekünk kell eldöntenünk.

Ha akarunk használni stage területet, és a teljes betöltési idő (extract-transform-load) rövidségére kell optimalizálnunk a betöltést, akkor ez a módszer a legcélravezetőbb. Megvalósítása nem tartozik a legegyszerűbb feladatok közé, de az SQL Server 2005 Integration Servies (SSIS) szolgáltatása az eszközöket biztosítja a számunkra.

Felhasznált irodalom:

Kapcsolódó anyagok:

Kővári Attila - BI projekt

Új hozzászólás