Live cijfers: het doorzetten is makkelijk, het rekenen niet

Als mensen aan live cijfers denken, denken ze aan snelheid: hoe snel staat een nieuwe order in het dashboard? Dat is een terechte vraag, maar het is niet de moeilijkste. Een gewijzigde regel van het bronsysteem naar Azure brengen is techniek die je één keer goed moet bouwen. Het lastige begint daarna, als je met die regel wilt rekenen.

Eerst: heeft u het nodig?

Vaak niet. Voor sturen per dag, week en maand is een verversing per nacht ruim voldoende. Het Smart Data Platform doet dat standaard, en dat is al veel actueler dan wat de meeste organisaties gewend zijn.

Maar er zijn processen waar een dag te laat is. Een voorbeeld uit de vleesverwerking: daar komt de vraag binnen voordat duidelijk is wat er precies gesneden wordt en hoeveel dat weegt. Hoe eerder u weet wat u in huis heeft, hoe beter u vraag en aanbod op elkaar afstemt en hoe minder u verliest. Daarnaast ziet u live hoe de productie loopt. Blijft er ergens een haak hangen, dan ziet u dat meteen en niet de volgende ochtend.

Het transport bouwden we zelf

Om wijzigingen van een bronserver naar de database in Azure te krijgen, hebben we eerst replicatie van SQL Server gebruikt. Dat werkt, maar we wilden het in eigen beheer hebben. Daarom hebben we het transport zelf gebouwd, in drie lagen:

• Bij de bron staat een agent. Die draait op een machine die bij de database kan, ziet wat er veranderd is en stuurt alleen die regels door. De inloggegevens van de bron blijven op die machine. Bij SQL Server (vanaf versie 2015) gebruiken we change tracking; voor AS/400 werkt dat anders.
• In Azure staat een centrale regie. Die weet welke bronnen en tabellen meedoen, haalt de wijzigingen op en legt elke verwerkte wijziging vast in een logboek. Standaard kijkt hij elke vijf seconden of er iets nieuws is. Dat is instelbaar, want vaker kijken kost ook meer.
• De datamart verwerkt de wijziging tot een feit of een dimensie, met dezelfde opbouw als het datawarehouse.

Omdat het in lagen is opgebouwd, kunnen we een nieuwe bron toevoegen zonder de rest aan te passen. Staat de bron al in een database in Azure, dan is er zelfs geen agent nodig.

Waar het lastig wordt

Een nieuwe orderregel toevoegen aan een tabel is eenvoudig. Maar een rapport doet zelden alleen dat. Drie voorbeelden van vragen die bij live data ineens lastig worden:

Vergelijken met totalen. Het aandeel van één klant in de omzet verandert met elke order van elke andere klant. Wie dat steeds opnieuw over alle data uitrekent, krijgt een traag rapport.

Historie met begin- en einddatums. Verandert een klant van accountmanager, dan wilt u de oude omzet bij de oude accountmanager houden. In een nachtelijke verwerking zet je dat één keer per dag recht. Live moet dat bij elke wijziging kloppen.

“Wat was de stand een uur geleden?” Een vergelijking met het vorige uur of de vorige week vraagt om een vaste stand om tegen te rekenen, terwijl de data blijft binnenkomen.

Voor dit soort vragen zitten tussenstappen in het platform, bijvoorbeeld hulptabellen die een deel van het rekenwerk al hebben gedaan. Die zie je als gebruiker niet, maar ze bepalen of een live rapport snel blijft.

Dezelfde opbouw, dus één waarheid

Het belangrijkste uitgangspunt: live is geen tweede systeem naast het datawarehouse. Een datamart op live tabellen heeft dezelfde opbouw, met feiten en dimensies, als een datamart op de nachtelijke tabellen. Daardoor kunt u per onderwerp kiezen wat live moet en wat niet, zonder dat er twee versies van de omzet ontstaan.

Wilt u weten welke processen bij u live de moeite waard zijn? Op de pagina over het Smart Data Platform leest u hoe de Smart Live-module werkt, en in een gesprek kijken we samen waar het verschil maakt en waar niet.