Wanneer je je Microsoft BI & Analytics platform naar de cloud wilt brengen, is het verstandig om een goed ontwerp te maken, en zorgvuldig te evalueren welke componenten je zoal kunt gebruiken. Benieuwd naar wat er zoal verandert wanneer je je analytische data-platform naar de cloud brengt? 👇

Stel: je hebt een goed lopend Data Warehouse lopen in SQL Server. Er is jarenlang aan gewerkt, er zijn waardevolle inzichten, en de klanten zijn tevreden. Maar je denkt vooruit: je ziet nieuwe ontwikkelingen als streaming data. Nieuwe workloads uit Machine Learning-oplossingen. Nieuwe vragen vanuit empowered en data literate business users (pak je bullshit-bingo kaartje er maar bij). Dus is het hoog tijd te oriënteren op de cloud-omgeving. Want de vraag is inmiddels niet meer óf je naar de cloud gaat, maar hóe (en wanneer).

Hieronder een paar dingen waar je vooraf aan zou willen denken.

Aanleveringen, shares en Data Lakes

On-prem ontwerp van data-aanleveringen

Aanleveringen voor je Data Warehouse worden in een on-prem omgeving vaak op drie manieren gedaan:

• Push door een bron naar een landing zone (platte tabellen of fileshares)
• Pull vanuit een bron naar een landing zone (platte tabellen of fileshares)
• Pull vanuit een bron naar een staging area (bijv. vanaf een RDBMS naar een Data Warehouse, waarbij de datatypes behouden blijven)

Cloud-ontwerp van data-aanleveringen

Bij veel cloud-oplossingen wordt ervoor gekozen om de extractie vanuit je bronnen te scheiden van de processing binnen je analytische platform. Je krijgt dan twee fasen:

1. Extractie naar een Data Lake
2. Laden en processing van data die daadwerkelijk gebruikt gaat worden richting een DW (of andere analytics-oplossing)

Deze constructie biedt op architectuur-niveau enkele nieuwe mogelijkheden. Bijvoorbeeld dat andere oplossingen dan je Data Warehouse gebruik kunnen maken van dezelfde aanleveringen, zonder dat je een afhankelijkheid van je Data Warehouse creëert.

Impact van een Data Lake op je Data Warehouse-ontwerp

Gecombineerd met de andere eigenschappen van een Data Lake heeft dit echter ook impact op de inrichting van je Data Warehouse. Data Lakes als Azure Data Lake Storage (ADLS) hebben bijvoorbeeld onbeperkte data-opslag, tegen een lage prijs. Oude data hoef je niet direct te verwijderen, maar kun je ook eenvoudig op een andere storage tier zetten, waarmee de opslag goedkoper wordt.

Dit verandert de dynamiek bij het kiezen voor een oplossing. Traditioneel koos je er wellicht voor om data zo snel mogelijk binnen je database historisch op te slaan (in een "hist" of "raw" layer, of in een persistent staging area) en de aanleveringen beperkt te bewaren. Dat is bij een data lake niet per sé de beste keuze: Als de data (nog) geanalyseerd hoeft te worden, kan het goedkoper en flexibeler zijn om deze simpelweg binnen je Data Lake te laten staan.

Nieuwe workloads

Even een aanname: de migratie naar de cloud doe je vast niet omdat je verwacht dat de komende 10 jaar je tried-and-trusted Data Warehouse onveranderd zal blijven. Indien wel: blijf gezellig on-premises. In alle andere gevallen is het goed om alvast na te denken over nieuwe workloads.

Nieuwe bronnen

Steeds meer bronnen in je organisatie worden als dienst afgenomen (SaaS). Voorbeelden zijn Salesforce of Google Analytics. En niet alle SaaS-bronnen gaan mee met jouw voorwaarden. Denk aan zaken als integratie met je Active Directory (en de mogelijkheid om je service-accounts bepaalde toegang te verlenen), dumps en exports van data, toegang tot achterliggende databases, etc..

Je zult daarom goed moeten nadenken over hoe je deze data-aanlevering een plek geeft in je architectuur:

• Zijn er afspraken te maken met de leverancier, waarin zij de data via push aanleveren in een vooraf afgesproken formaat?
• Moet je met een bepaalde secret of certificate data ophalen op een locatie van de applicatie? Hoe ga je die veilig opslaan?
• Zijn volledige dumps van de data mogelijk? (Zowel performance-wise als qua toegang / volledigheid)
• Kun je überhaupt geautomatiseerd bij alle informatie die je eindklanten zien?
• Zijn er andere manieren om te integreren? Zitten hier extra kosten aan verbonden? (Bijv. egress-kosten)

Wanneer je voor je data afhankelijk bent van meerdere externe softwarepakketten, is de kans groot dat hun uitlevering van data niet per sé in jouw verwerkingswindow ligt. Het ontkoppelen van het ophalen van data (de klassieke "extract") van de laadprocessen is dan een belangrijk punt geworden. De coördinatie hiervan moet je dynamisch kunnen oplossen; SQL Agent gaat je hier niet voldoende bij helpen.

Streaming data en microservices

Allereerst krijg je op korte of lange termijn te maken met streaming data. Data-techneuten denken dan gelijk aan hippe IoT-oplossingen. Die zijn ook interessant, maar niet waar ik hier primair op doel. De uitdaging voor veel analytische oplossingen zal eerder liggen in applicaties met een microservices architectuur. Als je nog niet weet wat dat betekent: direct even opzoeken.

Steeds meer applicaties maken gebruik van een microservices architectuur. De impact voor een Analytics platform is dat een "echte" micro-services architectuur geen centrale database heeft waar alle services hun "state" heen schrijven. Dus je hebt opeens bronnen die je niet zomaar een dagelijkse "volledige" dump kunnen aanbieden. En daar moet je over nadenken.

Wanneer de applicatie met een microservices-architectuur al een gegeven is, kan je Analytics platform zelf een subscriber worden van diverse topics die de micro-services distribueren. Dus een adreswijziging van een klant wordt niet meer alleen naar het billing-systeem verzonden, maar ook naar jouw Analytics-omgeving. Het consistent in lijn krijgen van dit soort event streams kan echter een lastige klus zijn: als een adreswijziging in het CRM plaatsvindt, zou het zomaar kunnen dat een billing-systeem deze pas de volgende dag (of week?) verwerkt. Hoe weet je dan naar welk adres een factuur gestuurd is?

Liever ben je vroeg betrokken bij het ontwerp van nieuwe applicaties binnen een bedrijf. Zodat je in het voorbeeld hierboven aan het billing-systeem kunt doorgeven dat het voor jou heel veel meerwaarde oplevert als ze bij het verzenden van hun facturatie-event ook aangeven naar welk adres het gegaan is (of in elk geval met welke versie van de klantinformatie).

Data van streaming data en microservices verwerken

Hoe de data dan ook bij je aankomt, je moet in je architectuur verwerken hoe je deze gaat verwerken. Dat kun je op twee manieren doen:

1. Je verzamelt de events en verwerkt ze periodiek (zoals de "klassieke" daily load van je Data Warehouse). Dit geeft je vaak meer ruimte om data te schonen, te integreren over meerdere bronnen heen, etc.
2. Je verwerkt de events zodra ze binnenkomen. Dit geeft je het voordeel dat recente data snel beschikbaar is als stuurinformatie

In een moderne data-architectuur wordt hier vaak een lambda- of kappa-architectuur voor ingezet. Hierin is recente data snel beschikbaar (maar bijv. niet geïntegreerd, of met een foutmarge). Data die ouder is (bijvoorbeeld een dag, of een week) is dan ook daadwerkelijk door je schonings- en integratieprocessen heen geweest, en biedt een hoge kwaliteit en betrouwbaarheid.

Goed overzicht krijgen van de cloud-oplossingen?

BI Trainer.nl biedt diverse trainingen aan op het gebied van Azure en Data Platforms. Wil je een stevige oplossing neerzetten die op de toekomst voorbereid is? Dan kan het geen kwaad je daar eens een paar dagen in te verdiepen met één van de volgende trainingen:

Implementing an Azure Data Solution (DP-200)

In de training “Implementing an Azure Data Solution (DP-200)” krijg je als BI Engineer / Data Engineer in drie dagen een stevig hands-on overzicht van de verschillende oplossingen binnen het Azure Data Platform. Na afloop heb je een goed beeld van de verschillende oplossingen, en weet je wanneer je wat kunt inzetten. Ook heb je een stevige basis gelegd voor het eventueel behalen van de DP-200 Azure certificering.

Designing an Azure Data Solution (DP-201)

Als ervaren Data Engineer leg je in de training “Designing an Azure Data Solution (DP-201)” in twee dagen een stevig fundament voor het ontwerpen van oplossingen binnen het Azure Data Platform. Waar de DP-200 training met name kijkt naar de diverse oplossingen (de "tools" binnen het Azure Data Platform), gaat deze training meer over architectuur, referentie-architectuur en verschillende vormen van verwerking (batch vs. real-time).

Azure Solution Architect - Design (AZ-301)

Leer in de training "Azure Solution Architect - Design (AZ-301)" in vier dagen om als Azure Solution Architect stakeholders te adviseren en business requirements te vertalen in veilige, schaalbare en betrouwbare oplossingen. De training Azure Solution Architect gaat niet specifiek over het Azure Data Platform, maar kijkt op een iets hoger niveau naar de architectuur van je oplossingen binnen Azure. Hiermee krijg je de handvatten om de behoefte aan zowel Data Platform als andere oplossingen te vertalen naar een solide oplossing binnen Azure, waarbij je rekening houdt met de belangrijke zaken voor een cloud solution architectuur.