Steeds meer organisaties stellen zich de vraag hoe betrouwbaar hun huidige cloudprovider nog is. Denk aan geopolitieke risico’s, mogelijke overheidsingrepen of zorgen over ongewenste toegang tot data. Logische zorgen en precies daarom is een doordachte exitstrategie essentieel. In ons whitepaper Waarom een Datawarehouse exit strategie essentieel is zijn we ingegaan op het waarom. In dit whitepaper gaan we in op het hoe.
Waarom kan jij je datawarehouse nu niet verplaatsen?
De technologie die jij nu gebruikt om je datawarehouse mee te vullen en de data in op te slaan is niet geschikt om mee te nemen en bij een andere cloud provider te hosten. Als je nu Microsoft Azure gebruikt met Data Factory, dan kan je dat niet draaien in het Google Cloud Platform (GCP) of op Amazon (AWS). Zo geldt dat ook voor andere technologieën. Je hebt hier dus last van een vendor lock-in.
Goed dat je dit whitepaper leest zodat je weet hoe je met je datawarehouse de vendor lock-in gaat doorbreken.
Je datawarehouse verplaatsen is niet complex en risicovol
Waarschijnlijk denk je bij het verplaatsen van je datawarehouse naar een andere cloud provider aan nogal wat uitdagingen:
- Downtime: kan ik dan een tijd niet bij mijn data?
- Doorlooptijd: hoe lang gaat dit project wel niet duren?
- Kosten: hoeveel geld gaat de migratie en de nieuwe maandelijkse cloud ‘spend’ wel niet kosten?
- Omvang: moet ik dan ook alle rapportages ombouwen?
- Veiligheid: hoe veilig staat mijn data in die andere cloud?
Stel dat die risico’s allemaal helder in kaart gebracht worden door Datap en dat je zal zien dat alle risico’s goed beheerst kunnen worden, wat zou je dan tegenhouden om de stap te zetten? Hieronder lees je onze aanpak om jouw datawarehouse te verplaatsen. Benieuwd hoe dat er voor jou concreet uit ziet? Plan dan snel en eenvoudig een afspraak met ons.
In 7 stappen je datawarehouse verplaatsen
Welke stappen moet je zetten om je datawarehouse te verplaatsen?
- Inventarisatie
- Keuze maken nieuwe technologie
- Platform inrichten
- Data extractie opnieuw inrichten
- Migratie: Bestaande data naar nieuwe database kopiëren
- Validatie en datakwaliteit
- Rapportages en andere systemen koppelen aan nieuwe database
1. Inventarisatie
Het is belangrijk om eerst met een inventarisatie te beginnen. Bij de inventarisatie maak je een overzicht van alle onderdelen die je bij het migreren gaat raken. Dat overzicht is cruciaal omdat je daarmee grofweg de doorlooptijd kan bepalen en ook het testplan kan opstellen met daarin alle onderdelen die getest moeten worden.
2. Keuzes maken
In de basis zal je twee keuzes moeten maken:
- Welke locatie: kies je een cloud provider, of wil je zelf hosten?
- Welke databasetechnologie?
Je wilt vrijheid hebben om je datawarehouse en dataplatform te hosten bij de cloud provider van jouw voorkeur. De databasetechnologie en software die wij adviseren kan bij vrijwel alle cloudproviders draaien, of op jouw eigen server of zelfs op je laptop. Je kan er dan ook voor kiezen om nu alleen in te zetten op het vervangen van de ‘technologie’ en niet direct in te zetten op het vervangen van je cloud provider.
Op basis van de inventarisatie is het verstandig een keuze te maken tussen ofwel PostgreSQL als technologie, ofwel een Lakehouse oplossing. Voor de meeste bedrijven is PostgreSQL een uitstekende keuze.
3. Platform inrichten
Wanneer je besloten hebt welke (cloud) provider je kiest dan kan je beginnen met het inrichten van de database en bijbehorende software.
Als je het bij een bestaande cloud provider uitrolt dan is het een kwestie van de benodigde onderdelen in de portal aanklikken zodat je de benodigde software beschikbaar hebt. Een Europese cloud provider is natuurlijk ook een uitstekende optie. Je zal dan eerst een account aan moeten maken waarna je de benodigde componenten aan kan zetten.
Wanneer wij dataplatformen inrichten dan doen we dit grotendeels geautomatiseerd. We passen ‘Infrastructure as Code’ (IaC) toe. IaC wil zeggen dat wij de benodigde componenten volledig geautomatiseerd neerzetten op basis van scripts. De code om dat te doen is grotendeels generiek waardoor onze oplossing zowel in jouw huidige cloud uit te rollen is, als in een andere cloud, als ook op jouw eigen servers.
Wij adviseren om een oplossing te gebruiken die cloud agnostisch is. Dit komt voor ons neer op technologie die in een gecontaineriseerde omgeving kan draaien.
4. Data verwerken
Datap kiest voor dlt (data load tool) als framework om data mee op te halen uit bronsystemen. Het is gebaseerd op Python. Voor ETL software van de 3 grote cloud providers is specialistische kennis nodig. Door met Python te werken kan iedereen met Python ervaring met dlt aan de slag. Daarmee is er een grote groep professionals die kan ondersteunen om hiermee te werken.
dlt zorgt ervoor dat je zeer snel bronsystemen kan aansluiten, eenvoudig heel veel tabellen op kan halen en dat data extractie dus sterk geautomatiseerd is.
Voor de verdere verwerking van data naar je dashboards en rapportages zal veelal business logica toegevoegd moeten worden. Vervolgens is het een kwestie van de Transformaties programmeren en waar nodig de data wegschrijven. Zeker wanneer je voor PostgreSQL als technologie gekozen hebt, kunnen de meeste SQL functies die je nu in je huidige oplossing gebruikt, daar ook gebruikt worden.
5. Migratie
Bij de migratie wordt de bestaande data vanaf je huidige datawarehouse naar de nieuwe omgeving gemigreerd. Het eenvoudigst is om hier ook dlt voor te gebruiken zodat je de import in de nieuwe database zoveel mogelijk geautomatiseerd kan laten verlopen.
Wij adviseren om zoveel mogelijk incrementeel te werken. Dus niet eerst de hele ETL afmaken, maar wanneer een stuk ETL afgerond is, de benodigde data migreren zodat je het stuk van voor tot achteren kan testen. Het is daarna namelijk ook mogelijk om alvast te schaduwdraaien. Het testwerk van datgene dat al opgeleverd is loopt dan parallel met de onderdelen die nog in ontwikkeling zijn. Hierdoor wordt de doorlooptijd sterk ingekort.
6. Validatie en datakwaliteit
Uiteindelijk wil je weten of de data in het nieuwe datawarehouse 1 op 1 overeenkomt met data uit het oude datawarehouse.
De validatie en check op datakwaliteit zal je per tabel vast moeten stellen. Wij maken hiervoor een script waarin de volledige inhoud van alle kolommen van een tabel geaggregeerd wordt, zodat je dat met de oude en nieuwe tabel kan vergelijken. Bij eventuele verschillen zorgen we ervoor dat rij voor rij met elkaar vergeleken wordt. Bij verschillen zijn er twee mogelijkheden. De nieuwe situatie wijkt af, dan moet er blijkbaar wat aangepast worden in het laden en verwerken van de data. Of de nieuwe situatie is juist in tegenstelling tot de huidige situatie. Dan zorgt deze analyse voor de vastlegging van die conclusie. Hieronder de aandachtspunten waar je op moet letten bij de validatie:
- Totaal aantal rijen in de tabel.
- Aantal unieke waardes per kolom.
- Aantal NULL waardes per kolom.
- Minimale en maximale datum per kolom als het om datum/tijd gaat.
- Minimale en maximale lengte van een kolom als het om een tekstueel veld gaat.
- Minimale en maximale waarde en sum van de waardes als het om gehele of decimale getallen gaat.
Idealiter werk je met hashes / checksums. Deze functionaliteit zal wel ondersteund moeten worden door je database.
7. Rapportages
Je nieuwe datawarehouse komt nu 1 op 1 overeen met je oude datawarehouse. Je hebt nu de vrijheid om je datawarehouse te verplaatsen naar een andere cloud provider, naar eigen servers of eventueel zelfs je eigen laptop. Het enige wat je nog moet doen is het veranderen van de connecties in je rapportages. Het is verstandig om ieder rapport te checken om na te gaan of de situatie voor en na ook daar identiek is en of het rapport hetzelfde functioneert. Doordat je al een grondige controle hebt uitgevoerd op de onderliggende tabellen in je datawarehouse zal deze controle minder grondig hoeven te worden uitgevoerd.
Conclusie
Wij hebben meer dan 15 jaar ervaring in het uitrollen van en ontwikkelen in dataplatformen. Daardoor hebben wij de nodige migraties meegemaakt en uitgevoerd.
We kunnen de hele migratie dan ook voor je uit handen nemen en grotendeels fixed price uitvoeren. De enige variabele component is de inventarisatie. Doorgaans kost een inventarisatie 2 – 7 dagen. De output van deze inventarisatie bepaalt de scope voor de opdracht. Daarmee kunnen we gedurende het proces eenvoudig alle opgeleverde zaken afvinken en houden we met elkaar grip op de status en doorlooptijd.
Optioneel kunnen wij ook een uitwijktest uitvoeren. In een uitwijktest richten we dan bij een andere cloud provider een omgeving in en zorgen we ervoor dat een aantal tabellen en bronsystemen overgehaald worden. Daarmee weet jij zeker dat je daadwerkelijk vrij bent om op een later moment van cloud leverancier te veranderen. Het inrichten en uitvoeren van een uitwijktest duurt gemiddeld 5 dagen. Dit is afhankelijk van de precieze scope die we met elkaar afspreken.