Inleiding
In vrijwel elke organisatie waar gestart wordt met het introduceren van business intelligence, moet er een keuze gemaakt worden: Hebben we nu wel of geen data warehouse nodig voor de realisatie van BI oplossingen?
Een ander geval waarin eerder gemaakte keuzen nogmaals tegen het licht worden gehouden, is dat u werkt in een organisatie waar al diverse BI oplossingen gerealiseerd zijn, en waar u op het punt bent gekomen voor een evaluatie.
Zoals binnen elk vakgebied zijn er trends en ontwikkelingen gaande die nader beschouwd kunnen worden. Binnen het vakgebied business intelligence & data warehousing spelen de volgende:
- Snellere time-to-market: In een hoger tempo BI oplossingen opleveren.
- Data virtualisatie: Is het nog nodig om fysiek data te verplaatsen?
- In-memory oplossingen: Kunnen we door meer data in-memory te zetten sneller data beschikbaar krijgen?
Keuze wel of geen data warehouse
In relatie tot deze vragen wordt de keuze wel of geen data warehouse realiseren als onderdeel van een BI oplossing ook onder de loep genomen.
Om te bepalen of dit kan, lijkt het ons verstandig om stil te staan bij waarom we met data warehouses zijn begonnen. Daarbij nemen we de definitie opgesteld door Bill Inmon als leidraad:
A data warehouse is a:
- Subject oriented
- Integrated
- Non-volatile and
- Time variant
collection of data in support of management’s decision making process.
Uit deze definitie willen we de begrippen “non-volatile” en “integrated” halen. Non-volatile heeft te maken met het in historisch perspectief (de bril van toen of de bril van nu) kunnen kijken naar de data. Dit is vandaag de dag nog niet altijd mogelijk voor elke applicatie.
Integrated slaat op het feit dat een organisatie niet 1 bron (ERP) gebruikt, dus altijd vanuit verschillende bronnen data moet halen en op elkaar moet kunnen “plotten” (masterdata, een ander onderwerp behandeld in een separate white paper).
Met de huidige stand van de techniek kunnen we steeds niet zonder een data warehouse. Niet om data snel genoeg te kunnen integreren, en ook niet om het hoofd te bieden aan met de bril van het verleden naar de data te kunnen kijken.
En alhoewel het geen maatgevend criterium is, vrijwel elke grote BI softwareleverancier heeft in zijn architectuur nog steeds een prominente plaats ingeruimd voor een data warehouse.
4 fasen architectuur
We hebben een keuze gemaakt. We nemen in onze architectuur een data warehouse op. In welke vorm doen we dit dan? En hoe beantwoorden we de vragen op het gebied van de trends en ontwikkelingen? We richten een data warehouse in volgens onderstaande figuur.
Laag 1: staging area
In de eerste laag worden de gegevens die relevant zijn voor inladen in het data warehouse tijdelijk opgeslagen.
Optioneel is een inhoudelijke datacontrole om de kwaliteit van de ingelezen gegevens te beoordelen voordat deze verder worden verwerkt.
Alle data die in de staging area is ingeladen, moet compleet verwerkt kunnen worden.
Laag 2: historical data area of bron dw
In laag 2 worden de ruwe gegevens uit de bron opgeslagen, en worden alle wijzigingen bijgehouden door een geldig van – t/m vast te leggen. Deze laag vormt het geheugen op het gebied van data.
Laag 3: business dw
In deze laag gebruiken we een (generiek) business data model. Dit kan een data model gemodelleerd in derde normaalvorm (3NF) of als data vault.
Verder zorgen we dat we geen terminologie meer gebruiken die bronspecifiek is.
Tot slot passen we transformatieregels toe om bronspecifieke gegevens conform business definities te maken.
Laag 4: data marts of dimensionele laag
De laatste laag bevat gegevens die voor business users gemakkelijk toegankelijk zijn. De gegevens worden opgeslagen in een dimensioneel model, de manier van vastleggen zoals Kimball deze ooit heeft bedacht.
ELT
Bij de keuze voor een 4 fasen architectuur is er impliciet gekozen voor ELT. De ruwe gegevens worden pas betekenisvol gemaakt binnen het data warehouse. Zoals hierboven is aangegeven gebeurt dat tussen laag 2 en 3.
Snellere “time to market”
Een data warehouse inrichten zoals hiervoor Is beschreven lijkt in schril contrast te staan met de roep om een snellere “time to market”. Op zich is dat waar. Het enige voorbehoud dat we hierbij willen maken is door strikte toepassing van het stappenplan door eenmalig een bepaalde actie uit te voeren, we kunnen komen tot standaardisatie van de uitwerking.
En standaardisatie draagt bij tot automatisering van werkzaamheden. Ofwel: We zijn in staat met de moderne hulpmiddelen die ons ter beschikking staan ETL code te genereren (data warehouse automation), waardoor we sneller en met constante kwaliteit de realisatie van een data warehouse kunnen bewerkstelligen.
Opties voor data virtualisatie
Data virtualisatie is een trend waarmee we voorkomen dat gegevens fysiek van tabel naar tabel worden gekopieerd vanuit de ene laag naar de andere.
In de hiervoor beschreven opzet van het data warehouse kunnen we door data virtualisatie ervoor zorgen dat de benodigde tijd voor ontwikkeling en beheren van ETL/ELT code wordt beperkt.
In elk geval in de vierde laag is data virtualisatie mogelijk. Immers, de gegevens zijn al beschikbaar in laag 3 in de definities en terminologie zoals de “business” deze wenst. Er vindt slechts een omvorming plaats naar een dimensioneel model om de gegevens gemakkelijker opvraagbaar te maken.
Met veel inspanning is het wellicht ook mogelijk om data virtualisatie toe te passen in laag 3. Praktisch gezien wordt dit lastig, want het aspect data integratie moet qua complexiteit niet onderschat worden. En met data integratie bedoelen we dan gelijke definities (metadata en transformaties) en gelijke inhoud (master data).
Nooit of te nimmer is het aan te raden om data virtualisatie toe passen op laag 1 of 2 vanwege de ruwheid van de data. Indien u rechtstreeks data uit een bron haalt voor analyses en niet fysiek opslaat, dan is uw bi oplossing afhankelijk geworden van de beschikbaarheid van de bron. Dit is ten zeerste af te raden.
In-memory oplossingen
De andere trend die we in het begin hebben benoemd is het toepassen van in-memory oplossingen. In cloud oplossingen voor databases zien we deze trend steeds meer toegepast.
Op zichzelf biedt die al mogelijkheden om de snelheid van gegevensverwerking te verhogen. Gekoppeld aan data virtualisatie is het een zeer snel tandem.
Maar ook hier geldt dat er een plaats moet zijn waarbij data fysiek wordt opgeslagen en beschikbaar is voor analysedoeleinden.
Conclusie
Data warehouses zijn vandaag de dag nog steeds nodig. Robuustheid is een groot goed. In kleine stappen ruwe data transformeren ook.
Kortere ontwikkeltijden en snelheid tijdens verwerking kunnen we bereiken door middel van data virtualisatie bij de data marts (laag 4), in-memory oplossingen na laag 2, en ETL codegeneratie.