Inzicht over het gehele bedrijfsproces met een datawarehouse
Datawarehouses verzamelen gegevens uit alle hoeken en gaten van de organisatie. Op die manier geven ze inzicht over het hele bedrijfsproces en niet alleen over die stukken die toevallig door een software pakket geregistreerd worden. Traditionele datawarehouses worden niet meteen bevoorraad met nieuwe gegevens. Vaak verschijnen de nieuwe gegevens als bijvoorbeeld standen op maandbasis of dagbasis, zoals ‘Omzet oktober 2012’. Hiermee kun je prima een aantal voorgedefinieerde vragen beantwoorden over een langere periode.
Als niet alleen de standen worden vastgelegd, maar ook de individuele transacties, dan kunnen vragen worden beantwoord die niet altijd vooraf gedefinieerd hoeven te zijn. Als transacties worden geregistreerd, dan is het ook handig om te bestuderen of er kan worden overgestapt van sterschema’s en verwanten naar een meer relationeel opslagmodel, zoals data vault. Terzijde: data vault is een modelleringtechniek vooral voor datawarehouses die een genormaliseerd model als uitgangspunt heeft. In die zin delen data vault en Invantive Producer dezelfde concepten.
Real-time: bij elke tik van de klok nieuwe inzichten
Sommige bedrijfsprocessen hebben een relatief korte levenscyclus. Bijvoorbeeld het handelen in derivaten of het online verkopen van boeken. Als je in een dergelijk proces ook actuele gegevens wilt hebben uit het datawarehouse, dan kun je niet meer volstaan met het dagelijks of maandelijks bijwerken van het datawarehouse.
Je wilt juist actuele gegevens in het datawarehouse. Ik vind dit zelf een geweldig moment. De behoefte aan actuele gegevens in je datawarehouse betekent meestal dat het datawarehouse wordt ervaren als een factor met veel toegevoegde waarde.
Keihard real-time en vliegende trackballs
Vrijwel altijd zullen de gegevens niet ‘keihard’ real-time zijn, maar volgt het datawarehouse met een korte vertraging de situatie in het bedrijf. Afhankelijk van verwerkingssnelheid, technische mogelijkheden en gewenste vertraging kan dat heel weinig (paar seconden) zijn of juist wat langer (een dag).
Soms leg je jezelf hierbij ook een minimum op. Je wilt niet altijd de laatste gegevens, maar een ‘gedempte’ variant hiervan. Die demping wordt bijvoorbeeld in de grotendeels geautomatiseerde handel van bepaalde financiële producten bereikt door de handel stil te leggen als het dynamische evenwicht verstoord is.
Waarom wil je een minimum qua vertraging in het bijwerken van je datawarehouse voor demping? Mijn favoriete voorbeeld is een trackball met dynamische kracht terugkoppeling. Hiermee mocht ik tijdens mijn afstuderen onderzoeken doen. Op deze trackball met een doorsnede van ongeveer 5 centimeter zaten twee elektromotoren. De draairichting en koppel van die elektromotoren kun je met software beïnvloeden, maar voor de meer hardware-minded was er ook een potentiometer. Als ik zelf hieraan draaide, dan ging het dynamische terugkoppel systeem van de trackball zichzelf versterken. De trackball vloog na een klein duwtje letterlijk meters door de kamer. Ik heb mezelf toen ook maar een minimum opgelegd qua instelling van de potentiometer.
Omdat bedrijfsprocessen soms ook via het datawarehouse gekoppeld zijn, wil je niet dat ze elkaar gaan versterken. Je kunt natuurlijk een systeemanalyse maken qua interacties, maar dat is bij complexe bedrijfsprocessen geen sinecure. Als je begint met datawarehousing is het slimmer om onverwachte invloeden te dempen door de gegevens minder snel te verwerken.
Integere gegevens, ook bij real-time datawarehousing
Maar die gegevens moeten dan wel kloppen. Ze moeten onderling in een juiste relatie staan. Dus niet eerst een order registreren onder de klant met nummer 1234, en pas daarna de klant registreren. Want de totale omzet per klant sluit dan niet aan met de totale omzet. De gegevens moeten in de juiste volgorde beschikbaar komen in het datawarehouse. Dat lukt meestal wel; de meeste moderne systemen leggen de ingevoerde gegevens meteen vast in een nette database. En in de juiste volgorde verwerken lukt ook nog wel als de gegevens allemaal gesorteerd kunnen worden op basis van een tijdstempel, bijvoorbeeld als volgt:
- Tijdstip 15:13:43, systeem Klanten, klant 1234 opgevoerd
- Tijdstip 15:13:44, systeem Orders, de eerste order van klant 1234 opgevoerd
Om dit mogelijk te maken dienen alle aangeleverde transacties voorzien te zijn van een tijdstempel zoals in het voorbeeld.
Let op: als de aanlevering van één systeem tijdelijk stokt terwijl de rest blijft aanleveren, dan loopt het real-time karakter van je datawarehouse achteruit. Soms wordt dit als argument gebruikt om concessies te doen aan de integriteit van de gegevens. Persoonlijk vind ik dit een slechte oplossing. Als iedere gebruiker van het datawarehouse dit soort gegevensfouten in de gaten moet houden, dan vraagt het datawarehouse teveel van de gebruiker en biedt het onvoldoende toegevoegde waarde. Als je het datawarehouse gebruikt voor externe financiële verslaglegging kom je er namelijk niet onderuit om extra maatregelen te treffen in het controleraamwerk om deze tekortkoming te compenseren.
Tijdstempel voor een real-time datawarehouse
Het tijdstempel moet aan een aantal eigenschappen voldoen:
- Sorteerbaar volgens de werkelijkheid: je moet de transacties, onafhankelijk van het aanleverende systeem, kunnen sorteren op basis van het tijdstempel zodat ze dezelfde volgorde hebben als waarop ze in de werkelijkheid geregistreerd zijn.
- Herleidbaar naar de werkelijkheid van de gebruiker: van een tijdstempel moet je kunnen bepalen bij welk rapportagemoment hij hoort zoals weergegeven voor de gebruiker op bijvoorbeeld een klok aan de muur.
Een tijdstempel dat voldoet aan de eerste eis is bijvoorbeeld een bedrijfsbrede unieke transactieteller. Zo’n teller is, los van de technische problemen, lastig te herleiden naar de werkelijkheid van de gebruiker (de tweede eis).
Een tijdstempel in de vorm van een datum met tijd voldoet niet helemaal aan de eerste eis. Als meerdere transacties plaatsvinden binnen de grootste nauwkeurigheid van dit tijdstempel, dan is niet te achterhalen in welke volgorde ze zijn uitgevoerd. Zo’n tijdstempel met datum en tijd voldoet echter wel aan de tweede eis. De meeste gebruikers werken zelf hoogstens met een nauwkeurigheid van een seconde. De afspraken over wereldwijde tijdzones zorgen er voor dat je gemakkelijk tijden kunt omrekenen in beide richtingen.
Binnen Invantive Producer gebruiken we om deze redenen zelf een combinatie van een datum/tijdstempel (bijvoorbeeld h_datum_start) en een bedrijfsbrede transactieteller (bijvoorbeeld h_id of transacte_bijgewerkt).
Een bedrijfsbrede transactieteller is soms niet praktische realiseerbaar. Je kunt de noodzaak hiervan ook op een andere manier oplossen. Als je jezelf kunt beperken tot een vereiste nauwkeurigheid van bijvoorbeeld 50 milliseconden voor rapportages, dan is een bedrijfsbrede teller niet nodig. In plaats daarvan kun je volstaan met het zelf ordenen van alle transacties in een dergelijke tijdsperiode. Dat ordenen kan automatisch op basis van een genormaliseerd data model, bijvoorbeeld op basis van metadata zoals in een Invantive Producer repository. In bovenstaand voorbeeld voer je bijvoorbeeld eerst alle klantgegevens in het datawarehouse die toegevoegd zijn in de tijdsperiode en daarna pas de order. Ook een aanpak met ‘keep trying until all processed’ is mogelijk.
Het laatste probleem waar je tegenaan loopt is het tot stand brengen van een bedrijfsbreed datum/tijd stempel. Als je ook hier weer kunt volstaan met een nauwkeurigheid van pakweg 50 milliseconden, dan kun je prima uit de voeten met het NTP protocol (NTP: Network Time Protocol). Eventueel kan dit in combinatie met vergelijkbare concepten specifiek voor bepaalde operating systemen zoals Windows Time Service.
NTP: Network Time Protocol
Met NTP kun je de tijd synchroniseren met andere referenties. Meestal gebeurt dit op operating systeem niveau, zodat alle applicaties die op een server draaien hiervan plezier hebben. De synchronisatie is tot op gewisse mate nauwkeurig, bijvoorbeeld enkele tientallen milliseconden. Zo’n referentie voor de juiste tijd kan een ‘ultieme’ bron van de tijd voor het gehele bedrijf zijn of een collega-server waarmee je tot consensus probeert te komen qua gezamenlijke tijd. Maar normaliter probeer je te koppelen met de wereldtijd.
Een atoomklok is volgens NTP een ultieme bron voor de juiste wereldtijd. Afhankelijk van het aantal stappen die je eigen referentie heeft tot de atoomklok, wordt jouw aantal stappen gelijk aan diens aantal stappen plus 1. Iedere stap introduceert een klein meetfoutje. Het aantal stappen tot de ultieme referentie is daarom een indicatie van de nauwkeurigheid van de tijd. Bij NTP heet het aantal stappen ‘stratum’. In de praktijk heb je meestal een stratum ergens tussen 3 en 5; een stratum tussen 10 en het maximum 16 leidt in het algemeen tot een matige tot slechte synchronisatie van de tijd. Een uitgebreide uitleg over NTP is te vinden op http://www.ntp.org en op Wikipedia.