Ad hoc desktop analysis

Ad hoc desktop analysis is de eerste stap in de richting van de decentralisatie van operationele data. Begrippen als ODS en Data Warehousing worden belangrijk en langzaam maar zeker wordt een parallel systeem ontwikkeld die de informatiebehoeften van de gebruikers moet voeden. Dit artikel focust op het waarom van deze ontdubbeling en belangrijke gevolgen die ermee gepaard gaan, zoals scheduling en synchronisatie.

ODS

De beslissing om operationele data af te scheiden van het OLTP systeem wordt veelal genomen om technische redenen en is op zich een redelijk eenvoudige beslissing. Het nadenken over de architectuur is moeilijker, omdat die vooral afhankelijk is van de presentatie van de geëxtraheerde data.

Berusten de functionele doeleinden vooral in een vorm van operationele rapportering, weliswaar op een globaler niveau dan de schermopvragingen, dan zal men een zogenaamde Operational Data Store of ODS bouwen. Een ODS kan beschouwd worden als een kopie van de operationele omgeving, maar met informatie die beperkt is in de tijd. Ze laat toe om op hetzelfde niveau te rapporteren, maar in tegenstelling tot de oorspronkelijke database –ook wel het bronsysteem genoemd - blijft de data veel minder lang beschikbaar. In de praktijk wordt deze basisregel al te vaak over het hoofd gezien. Eenmaal de data overgenomen is vanuit het bronsysteem blijft ze meestal zitten. Om op lange termijn niet te vervallen in dezelfde probleemsituaties die de aanleiding waren voor het bouwen van de ODS, is het essentieel dat er voorzien wordt in een correcte archiveringsmethode. Dit wordt iets verder in dit boek in meer detail besproken.

Het aanleggen van een ODS is op technisch vlak in principe een eenvoudige operatie doordat de granaliteit van de data perfect overeenkomt met die van de data op het bronsysteem. Er kan dus op basis van creatie- en mutatie-informatie een perfecte record-to-record synchronisatie gebeuren tussen beide systemen. Hoewel de beschikbaarheid van de data enigszins beperkt wordt in de tijd, brengt deze hoge granaliteit toch de nodige beperkingen met zich mee. Elke rapportering op een hoger niveau zal de online groepering van data vragen, wat langere extractietijden met zich zal meebrengen. We kunnen dus stellen dat een ODS niet echt geschikt is voor analytische rapportering.

Data Warehouse

Wenst men toch die richting in te slaan, dan ontstaat er een nood aan de ontwikkeling van een data warehouse. Zoals vermeld is een data warehouse een blue print van de ondernemingsstructuur, dit in tegenstelling tot een ODS, die een blue print is van de databasestructuur. Binnen een data warehouse stapt men volledig af van het principe van operationeel rapporteren en zal men als het ware de OLTP structuur gaan kneden in functie van de informatiebehoeften. Hoewel de analytische mogelijkheden bij een dergelijke architectuur heel wat uitgebreider zijn, zal er – voor wat de data betreft - toch nog steeds gewerkt worden met een betrekkelijk laag niveau van detail. Die vereiste is het gevolg van de ad hoc aard van bepaalde vormen van rapportering, waar voordien niet altijd even duidelijk geweten is welke richting men wil inslaan. Meerdere pistes dienen dus voorhanden te zijn, wat een proces met zich meebrengt dat resulteert in meer data.

Interactie

Een ODS en een data warehouse kunnen naast elkaar bestaan, zelfs op dezelfde server, om elke vorm van rapportering mogelijk te maken. Het is aan de ICT-afdeling om het gecombineerde gebruik zo transparant mogelijk te maken voor de business user. Aangezien een ODS “gevoed“ wordt vanuit een 1 op 1 relatie met het OLTP systeem, is het perfect mogelijk om de geëxtraheerde data op haar beurt te gaan gebruiken voor het voeden van de data warehouse. Aangezien de ODS in principe minder data bevat dan het bronsysteem, en zijn locatie afgezonderd is van de operationele omgeving, is het zinloos om het OLTP systeem twee maal te belasten met dezelfde extractie. Het is veel eenvoudiger om de ODS te gebruiken als bronsysteem voor de data warehouse, vooral omdat de aggregatie die vereist is binnen de data warehouse veel sneller en efficiënter kan gerealiseerd worden via de ODS. Het is natuurlijk essentieel dat beide systemen dezelfde vorm van informatie bevatten.

Synchronisatie & scheduling

Het spreekt voor zich dat de data die beschikbaar gemaakt wordt binnen de informatieomgeving dient aan te sluiten met deze die zich binnen de OLTP tabellen bevindt. Ze moet met andere woorden gesynchroniseerd worden tussen de opgezette systemen.

Bij een ODS lijkt synchronisatie op zich een eenvoudige opdracht, doordat de granaliteit op beide systemen in principe perfect met elkaar aansluit. Deze eenvoud wordt weliswaar ontkracht door een mogelijk probleem van data delay – of datavertraging. Er dient gekozen te worden tussen een synchrone en een asynchrone verwerking van de transacties. Een synchrone verwerking impliceert dat elke transactie op het OLTP systeem meteen herhaald wordt op het tweede systeem, in dit geval op de ODS. De data is dus met een te negeren interval van enkele milliseconden identiek in de tabellen van beide systemen. Naar inhoud en beschikbaarheid toe lijkt dit heel interessant, ware het niet dat men tijdens de operationele dataverwerking afhankelijk wordt van twee systemen. Wederom zal de behoefte aan output de input gaan belemmeren en het is essentieel dat dit vermeden wordt. Een asynchrone verwerking vermijdt die dubbele afhankelijkheid, maar veroorzaakt wel een zekere vertraging in de beschikbaarheid van de data binnen de ODS. Indien we ervan uit gaan dat er na deze verwerking nog een operatie volgt naar de data warehouse toe, dan heeft men meteen te kampen met een dubbele vertraging. Het spreekt voor zich dat het bijwerken van een data warehouse steeds een asynchrone verwerking zal zijn, doordat de granaliteit noch de structuur een synchrone benadering mogelijk maken.

Asynchrone verwerkingen leiden tot scheduling, wat een belangrijk aspect is bij de bouw van een informatieomgeving. Alle taken – veelal jobs genoemd – zullen correct moeten verdeeld worden over de beschikbaarheid van het systeem. Indien de scheduling tool hierin voorziet dienen zoveel mogelijk afhankelijkheden ingebouwd te worden, zodat de kwaliteit en de consistentie van de data op elk ogenblik gegarandeerd kan blijven. We stellen ons even voor dat een oplaadprocedure van een data warehouse bestaat uit de verwerking van een file met factuurgegevens en uit een andere taak die een file verwerkt waarin de nieuwe klanten opgenomen zijn. Indien beide jobs zonder enige vorm van afhankelijk gescheduled worden is het perfect mogelijk dat er na eventuele problemen bij het opladen van de klanten plots factuurgegevens bestaan in de data warehouse die verwijzen naar klanten die nog niet in de dimensietabel werden opgenomen. Dit resulteert in join-condities die niet langer opgaan en het ontbreken van de factuurgegevens bij rapportering. Terwijl men er voor wat de facts betreft wel van uitgaat dat de data volledig bijgewerkt werd.

Data delay is onvermijdbaar bij asynchrone verwerkingen, het is dan ook niet onbelangrijk dat het niveau van de vertraging correct bepaald wordt. Veelal wordt een informatieomgeving die bedoeld is voor ad hoc of semi-operationele doeleinden dagelijks bijgewerkt, en dan vaak ’s nachts om de belasting van het bronsysteem zoveel mogelijk te beperken. Toch blijft het bepalen van de vertraging eerder afhankelijk van de informatiebehoeftes dan van het systeem. Het heeft geen zin om op een dagelijks niveau gegevens bij te werken die slechts wekelijks zullen gebruikt worden. In het geval van bulk loads, waarbij enorme hoeveelheden data moeten opgeladen worden, is een kleine vertraging wel aan te raden, zelfs indien de informatie slechts na een langere termijn gebruikt wordt. Deze incrementele verwerking wordt dan enkel doorgevoerd met de bedoeling het systeem te ontlasten.

Ook de inhoud van de data speelt een rol. Wanneer de onderneming slechts maandelijks factureert dient er geen dagelijkse job te bestaan die op zoek gaat naar nieuwe facturen, wanneer men weet dat die nooit kunnen bestaan. Scheduling is dus vooral het zoeken naar een correct compromis tussen de databehoeften en de systeemtechnische mogelijkheden. De consistentie van de data staat echter steeds centraal.