Dit artikel is onderdeel van de themareeks BI & Techniek, bedoeld om de meer technische aspecten van BI voor het voetlicht te krijgen. Het is geschreven voor beheerders en ontwikkelaars binnen de BI, die zich afvragen hoe zij de steeds langer wordende doorlooptijden van de ETL batch in de hand kunnen houden.
Steeds meer en steeds sneller
Dashboards die 's ochtends om 7.00 uur landelijke verkoopcijfers tot en met de avond ervoor moeten tonen. Actueel inzicht in de winkelvoorraden vóórdat de winkels openen. Business Intelligence wordt vandaag de dag niet alleen breder en frequenter ingezet, maar de beschikbaarheid ervan is ook vanzelfsprekender geworden.
Er moet direct gestuurd kunnen worden op informatie die zojuist beschikbaar is gekomen. Ondanks de opkomst van tools en technieken voor directe analyses op bron-data, blijft de vraag naar datawarehouses met historische, gestructureerde gegevens ten behoeve van een up-to-date BI-omgeving onverminderd actueel. De verwerking van de groeiende hoeveelheid data en de toenemende vraag naar snellere informatie door managers, maakt dat er steeds meer gegevens in minder tijd moeten worden verwerkt.
De druk op de doorlooptijd van het laden van nieuwe data in het datawarehouse neemt daarmee toe. En de tijd dat het batch-window van 19.00 tot 7.00 uur het exclusieve domein van de ETL-batch was, ligt ver achter ons.
Opzet
Zonder in te gaan op specifieke oorzaken en al teveel in technische details te treden, wil ik de belangrijke oorzaken van een uit de hand lopende doorlooptijd van de ETL-batch in een aantal gebieden indelen:
-
te veel verplaatsingen van hoge volumes aan data en inefficiënte bewerkingen op de data.
-
hardware die te zwaar wordt belast waardoor tijdens de ETL-batch de verwerkingscapaciteit onevenredig wordt aangetast.
-
onbekendheid met de data en mogelijkheden van de ETL-tool.
Grote data-volumes
Breng het volume aan data dat door het ETL-proces loopt, zo vroeg mogelijk in het proces terug. Data-verplaatsingen en daarmee I/O zijn in veel gevallen een belangrijke boosdoener voor een slechte ETL-performance.
Selecteer om te beginnen alleen die data die nodig is voor de verwerking; filter, of liever nog, vermijd inlezen van rijen en kolommen die niet gebruikt worden in het proces. Een verdere stap hierin is het apart opslaan van zogenaamde 'hete' en 'koude' data, zodat data die vrijwel nooit wordt gebruikt ('koud') niet telkens wordt gelezen. Zorg dat het proces dat 'hete' en 'koude' data eventueel opnieuw indeelt, buiten het kritische batch-window loopt.
Splits waar mogelijk de te verwerken gegevens al vroeg in het proces op, naar later gebruik. Als ETL-deelprocessen A, B, C allen geïnteresseerd zijn in orders met status 'open' en alleen proces D ook in status 'closed', loont het de moeite op voorhand twee order-bestanden aan te maken, een order-open en een order-closed. Alleen proces D leest beide bestanden, de processen A, B en C lezen een veel kleinere set.
Indien de snelheid van de schijven of het netwerk en daarmee de I/O een belangrijke bottleneck is, kun je zelfs overwegen de data gecomprimeerd op te slaan. De CPU krijgt het dan weliswaar wat drukker, maar dat wordt vaak ruimschoots gecompenseerd door het feit dat je nog maar zo'n 10 procent van het data-volume van de schijf hoeft te lezen.
Hardware-benutting
Bereid waar mogelijk bestanden alvast voor, buiten het kritische batch-window. Alle bewerkingen die je al kunt doen voordat de nachtelijke ETL-batch losbrandt en die niet afhankelijk zijn van dat ene, laatste bronbestand dat nog om 23.00 uur arriveert, zijn mooi meegenomen. Je verkort daarmee sowieso de doorlooptijd van je kritische batchdeel en spreidt daarnaast de belasting van de server.
Benut de mogelijkheden van je ETL-tool bijvoorbeeld op het gebied van partitionering. Bij een goed gebruik van partitionering wordt de workload zo efficiënt mogelijk over alle beschikbare processoren verspreid. Ook bieden veel ETL-tools de mogelijkheid om bestanden vooraf in het geheugen te laden, zodat de grote bulk aan data daar snel tegenaan gehouden kan worden tijdens de ETL-batch.
Onbekendheid met ETL-tool en/of de bron-data
Vaak door onbekendheid met de ETL-tool of de data(-volumes) worden dure bewerkingen het proces 'binnengesleept'. Een sorteerfunctie is makkelijk op te nemen in het verwerkingsproces en werkt vermoedelijk prima op de testbestanden. Maar die 'sort' kan eenmaal in productie heel goed een vreselijke ETL-performance laten zien. Vermijd onnodig dure bewerkingen zoals een dergelijke sortering. Mocht je er echt niet onderuit kunnen komen, plan de sortering dan zodanig dat vervolg-processen daar baat bij hebben of kunnen volstaan met de veel voordeligere 'sortering binnen een groep'.
Conclusie
Naast toenemende data-volumes groeien ook de verwachtingen van de BI-gebruiker. De verwerking van grote hoeveelheden gegevens hoeft geen probleem te zijn als je er weloverwogen mee omgaat. Know your data; weet waar in het proces de volumes zitten. Daar ligt de sleutel voor een tijdige data verwerking binnen de BI-omgeving.
Blijf op de hoogte van nieuwe blogs binnen het thema BI & Techniek door je hier te abonneren. Meer informatie over Business Intelligence vanuit het perspectief van de manager? Download dan onderstaand ebook:
Dit blogartikel is geschreven door Ron Hoes