Hoe pak je een ETL-missie aan?

Enkele algemene ETL-tips

1. Overweeg om het op bestemming te organiseren (bijvoorbeeld alle code om de klantdimensie te produceren, leeft in dezelfde module, ongeacht de bron). Dit wordt ook wel onderwerpgeoriënteerde ETL genoemd. Het maakt het vinden van dingen veel gemakkelijker en vergroot de onderhoudbaarheid van uw code.

2. Als de SQL2000-database een puinhoop is, zult u waarschijnlijk merken dat SSIS-gegevensstromen een onhandige manier zijn om met de gegevens om te gaan. In de regel schalen ETL-tools slecht met complexiteit; ongeveer de helft van alle datawarehouse-projecten in financiële bedrijven wordt uitgevoerd met opgeslagen procedure-code als een expliciete architecturale beslissing - precies om deze reden. Als u een groot aantal code-insproc's moet plaatsen, overweeg dan om alle . te plaatsen van de code in sprocs.
   
   Voor een systeem met veel complexe scrubbing of transformaties, is een 100% sproc-benadering veel beter te onderhouden, omdat het de enige haalbare manier is om alle transformaties en bedrijfslogica op één plek te plaatsen. Met gemengde ETL/sproc-systemen moet je op meerdere plaatsen kijken om de hele transformatie te volgen, problemen op te lossen, fouten op te sporen of te wijzigen.

3. De sweet spot van ETL-tools is op systemen waar je een groter aantal gegevensbronnen hebt met relatief eenvoudige transformaties.

4. Maak de code testbaar, zodat je de componenten uit elkaar kunt halen en geïsoleerd kunt testen. Code die alleen kan worden uitgevoerd vanuit het midden van een complexe gegevensstroom in een ETL-tool, is veel moeilijker te testen.

5. Maak het data-extract dom met no-business-logica en kopieer het naar het verzamelgebied. Als je bedrijfslogica hebt verspreid over de extract- en transformatielagen, krijg je transformaties die niet geïsoleerd kunnen worden getest en die het moeilijk maken om bugs op te sporen. Als de transformatie wordt uitgevoerd vanuit een verzamelgebied, verminder dan de harde afhankelijkheid van het bronsysteem, waardoor de testbaarheid opnieuw wordt verbeterd. Dit is een bijzondere overwinning op op sproc gebaseerde architecturen omdat het een bijna volledig homogene codebasis mogelijk maakt.

6. Bouw een generieke, langzaam veranderende dimensie-handler of gebruik er een, indien beschikbaar. Dit maakt het eenvoudiger om deze functionaliteit te testen. Als dit unit-tested kan worden, hoeft de systeemtest niet alle hoekgevallen te testen, alleen of de gepresenteerde gegevens correct zijn. Dit is niet zo ingewikkeld als het klinkt - de laatste die ik schreef was ongeveer 600 of 700 regels T-SQL-code. Hetzelfde geldt voor alle generieke scrubfuncties.

7. Laad indien mogelijk incrementeel.

8. Instrumenteer uw code - laat het logboekinvoeren, mogelijk diagnostiek opnemen, zoals controletotalen of tellingen. Zonder dit is het oplossen van problemen bijna onmogelijk. Ook is het controleren van beweringen een goede manier om foutenafhandeling hiervoor te bedenken (telt rijen in gelijke rijen in b, is A:B-relatie echt 1:1).

9. Gebruik synthetische sleutels. Het gebruik van natuurlijke sleutels uit de bronsystemen verbindt uw systeem met de gegevensbronnen en maakt het moeilijk om extra bronnen toe te voegen. De sleutels en relaties in het systeem moeten altijd op één lijn liggen - geen nullen. Voor fouten, 'niet geregistreerd', maakt u een specifieke 'fout' of 'niet geregistreerde' vermelding in de dimensietabel en stemt hiermee overeen.

10. Als u een Operational Data Store bouwt (het onderwerp van menig religieuze oorlog), recycle dan niet de ODS-sleutels in de sterschema's. Doe in ieder geval mee op ODS-sleutels om dimensies te construeren, maar match op een natuurlijke sleutel. Dit stelt u in staat om de ODS willekeurig te laten vallen en opnieuw te creëren - mogelijk de structuur ervan te wijzigen - zonder de sterschema's te verstoren. Het hebben van deze mogelijkheid is een echte onderhoudswinst, omdat u op elk moment de ODS-structuur kunt wijzigen of een brute-force her-implementatie van de ODS kunt uitvoeren.

Punten 1-2 en 4-5 betekenen dat u een systeem kunt bouwen waarbij alle van de code voor een bepaald subsysteem (bijvoorbeeld een enkele dimensie of feitentabel) leeft op één en slechts één plaats in het systeem. Dit type architectuur is ook beter voor grotere aantallen gegevensbronnen.

Punt 3 is een tegenhanger van punt 2. In principe is de keuze tussen SQL- en ETL-tooling een functie van de transformatiecomplexiteit en het aantal bronsystemen. Hoe eenvoudiger de gegevens en hoe groter het aantal gegevensbronnen, hoe sterker het pleidooi voor een op tools gebaseerde aanpak. Hoe complexer de gegevens, hoe sterker het argument om over te stappen op een architectuur op basis van opgeslagen procedures. Over het algemeen is het beter om uitsluitend of bijna uitsluitend de een of de ander te gebruiken, maar niet beide.

Punt 6 maakt uw systeem gemakkelijker te testen. Het testen van SCD's of andere op wijzigingen gebaseerde functionaliteit is lastig, omdat u meer dan één versie van de brongegevens aan het systeem moet kunnen presenteren. Als u de functionaliteit voor wijzigingsbeheer verplaatst naar infrastructuurcode, kunt u deze afzonderlijk testen met testgegevenssets. Dit is een overwinning bij het testen, omdat het de complexiteit van uw systeemtestvereisten vermindert.

Punt 7 is een algemene prestatietip die u in acht moet nemen voor grote gegevensvolumes. Houd er rekening mee dat u mogelijk alleen incrementeel laden nodig heeft voor sommige delen van een systeem; voor kleinere referentietabellen en afmetingen heb je het misschien niet nodig.

Punt 8 is relevant voor elk headless proces. Als het 's nachts uit de hand loopt, wil je wat vechtkans om te zien wat er de volgende dag mis ging. Als de code niet goed registreert wat er aan de hand is en fouten opvangt, zal het veel moeilijker zijn om het probleem op te lossen.

Punt 9 geeft het datawarehouse een eigen leven. U kunt eenvoudig bronsystemen toevoegen en verwijderen wanneer het magazijn zijn eigen sleutels heeft. Magazijnsleutels zijn ook nodig om langzaam veranderende afmetingen te implementeren.

Punt 10 is een winst voor onderhoud en implementatie, aangezien de ODS kan worden geherstructureerd als u nieuwe systemen moet toevoegen of de kardinaliteit van een record moet wijzigen. Het betekent ook dat een dimensie vanaf meer dan één plaats in de ODS kan worden geladen (denk aan:handmatige boekhoudkundige aanpassingen toevoegen) zonder afhankelijk te zijn van de ODS-sleutels.