SSIS 2008 újdonságok – továbbfejlesztett lookup komponens


Már nagyon vártam az új lookup transzformációt, hiszen volt egy olyan speciális adattárház töltő problémánk, amelyre a 2005-ös lookup task csak olyan teljesítménnyel adott megoldást, hogy az SSIS helyett inkább maradtunk a jó öreg TSQL-nél, és diszken lookupoltunk... Hogy mi volt ez mindjárt elmagyarázom, csak előtte nézzük meg mi a fene ez a „lookup" komponens

A lookup komponenst adattárházas környezetben a ténytáblák töltéséhez használjuk és elsődleges feladata a befelé jövő ténytábla sorokban szereplő természetes kulcsok kicserélésére azok mesterséges kulcs-páraikra. A TSQL-es fejlesztő kollegák ezt úgy szokták megétreni, hogy „Aha, ez egy JOIN amivel kicseréljük egyik oszlopunk tartalmát a másik táblában lévő oszlop tartalmára" Igen. Így is fel lehet fogni csak a joint az SSIS hozza létre nem az adatbázis-kezelőn.

Nézzük meg hogyan valósul meg gyakorlatban a lookup, azaz a természetes kulcsok kicserélése a mesterséges kulcsokra:

  • Beolvassuk a Lookup transzformáció gyorsító tárába a dimenzió táblákban található természetes, mesterséges kulcs párokat (Mit mire kell kicserélni. Pl.: 2008-05-07-et 20080507-re)
  • Elkezdjük felolvasni a fact tábla forrástáblájából a rekordokat, és ha találunk közte olyat, hogy 2008-05-07 akkor azt kicseréljük 20080507-re
  • Az így módosított rekordot beírjuk a ténytáblába

Lookup művelet az Integration Services Data Flow taszkjában

Lookup művelet az Integration Services Data Flow taszkjában

Így működik tehát a lookup. Most vegyük egy kicsit közelebbről is szemügyre az SSIS azon transzformációját (komponensét), amely megvalósítja a lookup-ot.

Megjegyzés: Amit mi itt pongyolán „lookup"-nak nevezünk, azt az adattárházas szakirodalom „surrogate key pipeline"-ként vagy „Surrogate key lookup"-ként említi.

Az Integration Services 2008 új lookup transzformációja

Az új lookup transzformáció két nagy újdonságot is tartalmaz: Az első, hogy a cache-t leválasztották a lookup transzformációról, a másik, hogy többé nem keresi a cache-ben azokat a kulcsokat, amiket egyszer már nem talált meg a dimenzió elemek között. Kezdjük az elsővel:

Megosztott gyorsítótár (cache)

A cache az a terület ahová betöltjük a természetes kulcs - mesterséges kulcs párokat. Tesszük ezt azért, hogy amikor jönnek be a nyers ténytábla sorok, akkor gyorsan és folyamatosan ki tudjuk keresni a memóriából (cache-ből) a mesterséges kulcsokat, ne kelljen mindig a lemezhez fordulni a keresés során.

A 2005-ös integration Services-ben a lookup transzformáció gyorsítótára magához a transzformációhoz tartozott (exkluzívan). Kívülről ezt a gyorsító tárat nem lehetett elérni, módosítani, és csak addig élt, amíg a transzformáció futott.

Az integration Services 2008-ban ez gyökeresen megváltozott, hiszen a cache-t elválasztották a transzformációtól így az külön tölthető, módosítható, törölhető, megosztható más csomagokkal, menthető a lemezre, ... egyszóval független életet él a lookup komponenstől:

Az SSIS 2008 megosztott cache architektúrája

Az SSIS 2008 megosztott cache architektúrája

Miért fontos, hogy ez a cache immáron független a lookup komponenstől?

Amíg a cache nem volt megosztva, akkor minden egyes lookup komponens feltöltötte a saját cache-ét, majd ha lefutott, akkor kiürítette. (Függetlenül attól, hogy az utána következő SSIS csomag vagy data flow taszk használná-e).

Tegyük fel, hogy van 10 ténytáblánk, mindegyiknek van dátum kulcsa. Minden ténytáblát egy SSIS csomag tölt, tehát összesen tíz csomagunk van. SSIS 2005-ben mind a 10 csomag elment a dimenzió táblába és onnan kiolvasta a természetes kulcs - mesterséges kulcs párokat, majd ha végzett a cserével, akkor ürítette a cache-t. Aztán jött a következő SSIS csomag elment a dimenzió táblába kiolvasta a természetes kulcs - mesterséges kulcs párokat, majd ürítette a cache-t. Ez így ment, míg mind a 10 csomag le nem futott.

Az SSIS 2008-ban írt csomagokkal elég ezt egyszer megtenni. Elég egyszer feltölteni a cache-t, és azt használni tudja minden SSIS csomag, és a betöltés végén a cache tartalmát üríthetjük, vagy kimenthetjük lemezre. Ez sok esetben jelentősen növeli majd a lookup transzformáció gyorsaságát.

Nem talált kulcsok gyorsító tára

A másik nagy újdonság a nem talált kulcsok gyorsítótára. Ha közvetlenül adatbázisból lookupolunk (nem használunk cache-t) akkor az SSIS 2008 képes rá, hogy azokat a kulcsokat, amelyeket nem talált meg a referencia táblában (esetünkben a dimenzió táblában) eltárolja a nem talált kulcsok gyorsító tárában. Így ha egy elemet egyszer nem talált és az újra megjelenik a bejövő sorokon, akkor nem megy vissza még egyszer a referencia táblába (dimenzió tábla) megkeresni a már egyszer meg nem talált elemet, hanem kiolvassa a „nem talált kulcsok" cache-ből, jelentősen megnövelve ezzel a lookup komponens sebességét

Egyéb újdonságok

Végre nem a hibaágra kell küldeni azokat a rekordokat, amelyek kulcsa nem található meg a referencia (dimenzió) táblában, hanem erre létrehoztak egy külön „Lookup No match output" outputot és az error ágat meghagyták arra, amire való. Ha nem tudok beszúrni egy sort, mert pl nem fér bele a céltáblába, akkor az megy az error ágra. De ha nem találok meg egy kulcsot a referencia táblában, akkor az már nem az error ágra megy, hanem a „Lookup No match output" outputra. Sirály.

Mi az, amit még mindig nem tud az új lookup komponens Sajnos a cache-t módosítani nem lehet, miután egy lookup elkezdte használni. Pedig nekünk pont ez hiányzott a 2005-ös verzióból. Nem annyira katasztrofális probléma ez, mint amilyennek elsőre látszik, de azért jó lett volna, ha ezt is megoldják, ha már hozzányúltak a komponenshez

Error: The cache is being read from component "Lookup" (60) and cannot be written to by component "Cache Transform"

Error: The cache is being read from component "Lookup" (60) and cannot be written to by component "Cache Transform"

Van ugyanis egy problémánk, amit úgy hívnak az adattárházas szakzsargonban, hogy korán érkező tényadatok problémája (Early Arriving Fact), amelyet úgy oldunk meg, hogy a ténytáblák töltése során a dimenzió táblát a ténytáblából is töltjük. Ha nem találunk meg egy kulcsot a dimenziótáblában, akkor azt beleírjuk a dimenzió táblába, ott kap egy új mesterséges kulcsot, majd ezt az új mesterséges kulcsot újra kilookupoljuk a dimenzió táblából. Ennek következtében kétszer kellett lookupolni.

Racionálisnak tűnik - és a lookup komponens kipróbálásáig hittem is benne - , hogy ha módosítható a cache, akkor a nem talált elemeket beírjuk a dimenzió táblába is és a cache-be is. így nem kéne két lookupot használni, mert a cache-ben ott van már a hiányzó kulcs így a következő hiányzó elemet már onnan ki tudnánk venni. De nem így van. A cache tényleg módosítható, de csak a amíg lookup transzformáción el nem kezdi használni.

Összefoglalás: Mindazonáltal a két fő újdonság, a megosztott cache, és a nem talált kulcsok gyorsítótára miatt fellépő teljesítménynövekedés épp elég ahhoz, hogy újragondoljuk: milyen esetben használjuk az SSIS lookup komponensét és milyen esetben bízzuk ezt a feladatot az adatbázis kezelőre.

Felhasznált irodalom:

Elválasztó

Már készül a következő cikk. Kérjen értesítést a megjelenéséről itt.

|

Szóljon hozzá!

Szabály: Legyen kedves, segítõkész és vállalja a nevét.
A mező tartalma nem nyilvános.
  • A web és email címek automatikusan linkekké alakulnak.
  • Engedélyezett HTML elemek: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • A sorokat és bekezdéseket automatikusan felismeri a rendszer.
ANTI SPAM
A robot regisztrációk elkerülésére.
Image CAPTCHA
Figyeljen a kis és nagybetűk használatára