SSIS komponensek Microsoft termékekben

Eddig nem tudtam, hogy az Integration Services-ből ismert

-          Fuzzy Lookup taszk segít a Bing Map-nek a beírt kérésekhez megtalálni a megfelelő koordinátákat,

-          a Fuzzy Grouping taszk segít a Bing Shopping-nak kiszűrni a duplikált termék neveket és leírásokat,

-          és a Data Profiling taszk segít a PowerPivotnak felfedezni a táblák közti kapcsolatot.

Néha nem, néha viszont elég hatékonyan működik az információáramlás a Microsofton belül ha figyelembe vesszük hogy a Bing Map, Bing Shopping és a PowerPivot fejlesztői ismerik az SSIS adattisztító szolgáltatásait…

Image002

Forrás: Microsoft Research: Data Cleaning

SSIS újdonságok: Visszavonás/Mégse (Undo/Redo)

Az SQL Server következő verziójában lehetőségünk lesz a betöltő csomagok szerkesztése közben végrehajtott műveletek visszavonására és a visszavont művelet visszavonására (Undo/Redo) Nagyjából úgy, ahogy az Officeban megszoktuk:

Image001

Nagyon hiányzott ez a funkció az Integration Services korábbi verzióiból. További infó: Undo, Redo, and new SSIS Toolbox Features

Balanced Data Distributorn

Az SQLCat-os fejlesztők készítettek egy SSIS komponenst, amellyel párhuzamosíthatók a transzformációk és ezzel - bizonyos esetekben – gyorsíthatóak a betöltések.

Image001

Maga a Balanced Data Distributor komponens nem soronként, hanem az SSIS pipeline-ba betöltött bufferenként párhuzamosít és elsősorban akkor lehet rá szükség, ha a betöltési folyamat szűk keresztmetszete nem az adatkinyerés, hanem a transzformáció, vagy az beszúrás a céladatbázisba.

Még nem próbáltam, de felírom magamnak ide, hogy ha egy bonyolult transzformáció lesz a szűk keresztmetszet, akkor ezzel a párhuzamosító komponenssel talán lehet gyorsítani a betöltéseket. További infó itt: The “Balanced Data Distributor” for SSIS

Betöltések gyorsítása: Derived column task bontással

A derived column taszk egy szinkron transzformációt megvalósító egység, így definíció szerint a taszk részfeladatokra történő bontásával nem tudunk párhuzamosítani, hiszen nem fog létrejönni új execution tree, és így minden egy szálon fog futni továbbra is. Na ez így bonyolult, úgyhogy inkább mutatok egy példát.

Tegyük fel, hogy adattárházat töltünk, és minden egyes adattárházba érkező sorthoz hozzáfűzünk két oszlopot. Az egyik tartalmazza, hogy melyik betöltéssel került be a rekord, a másik tartalmazza, hogy melyik forrásrendszerből érkezetett a rekord.

Definíció szerint nem érdemes két taszkban hozzáadni a bejövő rekordokhoz ezen azonosítókat, mert az SSIS nem párhuzamosan, hanem sorosan fogja őket végrehajtani. Ez igaz is. De az SQLCat-osok felfigyeltek arra, hogy egy Execution tree-n belül az SSIS képes egy execution tree-hez több puffert (max 5-öt forrásonként) is allokálni, így végső soron a szinkron transzformációk bontásával egy execution tree-n belül is lehet párhuzamosítani.

Ha tehát az alábbi derived column taszkot

Image001

Felbontjuk 4-5 derived column taszkra,

Image002

Akkor jelentősen, esetenként felére csökkenthető a betöltés időszükséglete. Érdekes.

Akiket érdekelnek a részletek az olvassa el az Increasing Throughput of Pipelines by Splitting Synchronous Transformations into Multiple Tasks című cikket. (De nem árt, ha előtte utánanéz az SSIS architektúrájának)

Honnan tudni, hogy hány sort dolgozott fel egy SSIS SQL task?

Eddig nem tudtam róla, hogy az Integration Services ExecuteSQL task-jában futó SQL utasítások által feldolgozott sorok számát az SSIS látja és tárolja is. Ha eddig az Execute SQL task által feldolgozott sorok számát vissza akartam kapni, akkor mindig tárolt eljárást írtam, ami visszaadta a sorok számát, amit aztán a ResultSet property használatával tudtam  kinyerni.

Csakhogy most találtam egy cikket, amely teljesen világosan leírja, hogy az SSIS-nek erre ott az ExecutionValue és egy ExecValueVariable tulajdonsága, melyek használatával a fenti hókuszpókusz nélkül is ki tudjuk olvasni az Execute SQL taskból a feldolgozott sorok számát. A hogyant lépésről lépésre leírja az Have you used the ExecutionValue and ExecValueVariable properties? című cikk.

Megdőlt az SSIS 1 terabájtos betöltési rekordja

Megdőlt az SSIS 1 terabájtos betöltési rekordja. Nem is kicsit. A korábbi 30 perc körüli betöltési idő most 10 perc alatt jár, ami 3,5 szörös teljesítménynövekedés. A megdöntő ETL eszköz az SSIS, a megdöntő gép egy Unisys masina. Mint az a 3,5 szörös teljesítménynövekedésből már sejthető, nem hagyományos hardverarchitektúrával állunk szemben:  A Unisys masinában SSD diszkek dolgoznak…

Integration Services tanulmány Oracle 10g adatok betöltéséhez

Letölthető egy 24 oldalas Integration Services tanulmány (angol), amely kifejezetten olyan szakembereknek szól, akik ORACLE adatbázisokból akarnak adatokat átemelni az SQL Serverbe. Bár a cikk külön nem tér ki az ORACLE és az SQL Server közti adattípus és egyéb eltérésekre, de lépésről lépésre bemutatja, hogy mit kell tenni az adatok átemeléséhez kezdve az ORACLE kliens telepítésétől az adatkonverziók megvalósításán át egészen az adatok beillesztéséig.

Az SQL Server 2008 R2 Integration Services (SSIS) újdonságai

Rövid bejegyzés következik, hiszen az SQL Server 2008 R2 Integration Services (SSIS) semmilyen eget rengető újdonságot nem tartalmaz az előző, 2008-as verzióhoz képest. Sőt. Néhány kisebb módosítást leszámítva a 2008-as, és a 2008 R2-es Integration Services tökéletesen egyforma. Ne keresse tehát a what's new in sql server 2008 R2 integration Services nevű dokumentumot, mert ha meg is találná, akkor sem találna benne semmi érdekeset J