Datasetarchitectuur in een Qlik Open Lakehouse
Wanneer u datasets genereert in een Qlik Open Lakehouse, worden opslagtabellen, wijzigingstabellen en weergaven automatisch gegenereerd door Qlik Talend Data Integration. U kunt query's uitvoeren op deze weergaven om toegang te krijgen tot actuele en historische gegevens die zijn opgeslagen in de open tabelindeling van Iceberg.
Een intuïtieve en begeleide gebruikersinterface helpt u bij het bouwen, modelleren en uitvoeren van datapijplijnen. U kunt automatisch schema's genereren voor operationele gegevensopslag (ODS) en historische gegevensopslag (HDS) zonder handmatig te coderen.
Architectuur voor een Qlik Open Lakehouse datapijplijn met behulp van Qlik Gegevensgateway - Gegevensverplaatsing. Gegevens komen in de tussenopslag in S3 en worden opgeslagen in een Iceberg open lakehouse. Optioneel kunnen tabellen, zoals hieronder weergegeven, worden gespiegeld naar een datawarehouse.
Schema's
Artefacten worden gegenereerd in een intern schema en een gegevenstaakschema.
-
Het intern schema bevat een fysieke tabel met meerdere partities.
-
Het gegevenstaakschema bevat de weergaven die u kunt gebruiken om de gegevens te consumeren.
Wanneer een schema is gekoppeld aan meer dan één gegevenstaak, moet elke gegevenstaak een uniek voorvoegsel gebruiken voor tabellen en weergaven. U kunt het voorvoegsel instellen in de instellingen van de gegevenstaak.
Alleen interne schema's worden gecontroleerd op naamconflicten. Voor andere schema's moet u ervoor zorgen dat er geen naamconflicten zijn in de tabelnamen. De best practice is om het intern schema dezelfde naam te geven als het gegevenstaakschema met _internal toegevoegd. Dit zorgt ervoor dat elke combinatie van schema en voorvoegsel uniek is.
Tabellen
Voor elke brontabel wordt een tabel gemaakt in het intern schema met het achtervoegsel _internal, met behulp van de indeling:
<INTERNAL_SCHEMA>.<TABLE_NAME>_internal
Deze tabel bevat vijf partities, die elk een specifiek doel dienen in de manier waarop de gegevens worden verwerkt en opgeslagen. Elke partitie maakt gebruik van een subset van de kolommen van de tabel op basis van de rol in de levenscyclus van de gegevens.
De interne dataset is gestructureerd om inkomende gegevens van uw bronsysteem efficiënt te beheren, waarbij realtime opname en historische tracering worden ondersteund. De gegevensstroom wordt beheerd via verschillende gespecialiseerde partities, die hieronder elk worden beschreven:
-
Changes partitie – Realtime opname
Alle wijzigingen van het bronsysteem (invoegingen, bijwerkingen en verwijderingen) worden eerst toegevoegd aan de Changes partitie.
-
De partitie fungeert als een onbewerkt wijzigingslogboek en biedt een volledige feed van bronactiviteit voordat er transformaties plaatsvinden.
-
Elke wijziging is getagd met een type (I, U of D), wat aangeeft hoe deze wordt verwerkt.
-
Gebeurtenissen worden vastgelegd vanaf de bron op het moment dat ze zich voordoen. De partitie wordt in bijna realtime bijgewerkt.
-
De Changes partitie is beschikbaar wanneer de volgende instellingen worden toegepast in de Lake tussenopslag gegevenstaak.
-
Op het tabblad Algemeen is de Updatemethode ingesteld op CDC.
-
Volledige lading is ingeschakeld.
-
-
-
Asset_state partitie - Voortgang bijhouden
Terwijl wijzigingen worden opgenomen, registreert de Asset_state partitie twee belangrijke tijdstempels:
-
Wanneer wijzigingen voor het laatst zijn toegevoegd aan de Changes partitie.
-
Wanneer wijzigingen voor het laatst zijn toegepast op de Current partitie.
Dit biedt volledige zichtbaarheid in de synchronisatiepijplijn en helpt bij het bewaken of oplossen van vertragingen.
-
-
Current partitie (ODS) – Nieuwste replica van de bron
Wijzigingen uit de Changes partitie worden periodiek toegepast op de Current partitie om een up-to-date, voor query's geoptimaliseerde kopie van de brongegevens te behouden.
-
Er wordt automatisch een achtergrondtaak uitgevoerd om die updates toe te passen. Dit is gebaseerd op het volume van de verzamelde wijzigingen, in plaats van op een vast schema.
-
De initiële volledige lading wordt rechtstreeks naar de Current partitie geschreven.
-
Deze partitie weerspiegelt de huidige status van de gegevens en is ontworpen voor efficiënte query's.
-
-
Prior partitie (HDS) – Historische gegevens
Wanneer een record wordt bijgewerkt of verwijderd in de Current partitie, wordt een kopie van de vorige versie naar de Prior partitie geschreven.
-
Records bevatten metagegevens, waaronder de wijzigingsgeschiedenis en het datumbereik waarin de gegevens geldig zijn.
-
Dit ondersteunt Type 2 langzaam veranderende dimensie (SCD2).
-
De Prior partitie is beschikbaar wanneer Historische records en archief van wijzigingsrecords behouden is ingeschakeld op het tabblad Algemeen van de instellingen voor de Opslag-gegevenstaak.
-
Wanneer een bijgewerkte versie van een record in de Current partitie komt, wordt het vorige record verplaatst naar de Prior partitie voor historische tracering.
-
-
Reload partitie
De Reload partitie fungeert als een tijdelijke staging-omgeving tijdens handmatige of geplande volledige herladingen:
-
Nieuwe gegevens worden eerst naar de Reload partitie geschreven.
-
Reguliere onderhoudstaken wissen alle wijzigingen die in behandeling zijn voordat ze worden gepauzeerd.
-
Gegevens worden vergeleken met de Current partitie en alleen de verschillen worden verplaatst naar de Current partitie.
-
De Reload partitie wordt gewist wanneer de bewerking is voltooid.
Dit proces zorgt voor minimale verstoring van de hoofddataset tijdens volledige herlaadbewerkingen.
-
Current partitie
| Veld | Type | Beschrijving |
|---|---|---|
| hdr__key_hash | VARBINARY (20) | Hash van alle primaire sleutels van records. Hash-indeling is SHA1. Kolommen worden gescheiden door een backspace-teken. |
| hdr__from_timestamp | TIMESTAMP |
Tijdstempel in UTC:
|
| hdr__operation | VARCHAR (1) |
Laatste bewerking van dit record.
|
| hdr__inserted_timestamp | TIMESTAMP | UTC-tijdstempel van de eerste keer dat de sleutel werd toegevoegd. Bij gebruik van volledige lading, de starttijd van de volledige lading. |
| hdr__modified_timestamp | TIMESTAMP | UTC-tijdstempel van wanneer de laatste update is uitgevoerd. |
Prior partitie
| Veld | Type | Beschrijving |
|---|---|---|
| hdr__key_hash | VARBINARY (20) | Hash van alle primaire sleutels van records. |
| hdr__from_timestamp | TIMESTAMP | Tijdstempel in UTC. |
| hdr__to_timestamp | TIMESTAMP | Tijdstempel in UTC. |
| hdr__operation | STRING (1) |
Laatste bewerking van dit record.
|
| hdr__was_current_from_timestamp | TIMESTAMP | Tijdstempel in UTC voor de eerste keer dat het record actueel was. |
| hdr__was_current_to_timestamp | TIMESTAMP | Tijdstempel in UTC voor de laatste keer dat het record actueel was. |
Changes partitie
| Veld | Type | Beschrijving |
|---|---|---|
| hdr__change_identifier | VARCHAR (50) |
De wijzigings-ID is een tekenreeks met twee delen:
|
| hdr__operation | VARCHAR (1) |
Laatste bewerking van dit record.
|
| hdr__timestamp | TIMESTAMP | Tijdstempel in UTC. |
| hdr__key_hash | BINARY (20) | Hash van alle primaire sleutels van records. |
| hdr__inserted_timestamp | TIMESTAMP | UTC-tijdstempel van het moment waarop de wijziging is verwerkt door Qlik. |
Asset_state partitie
| Veld | Type | Beschrijving |
|---|---|---|
| hdr__apply_change_identifier | VARCHAR (50) | De wijzigings-ID van de laatste wijziging die is toegepast op de Current partitie. |
| hdr__copy_change_identifier | VARCHAR (50) | De wijzigings-ID van de laatste wijziging die is toegevoegd aan de Changes partitie. |
Reload partitie
De kolommen die worden gebruikt door de Reload partitie zijn identiek aan de Current partitie.
Weergaven
Alle gemaakte weergaven worden in bijna realtime bijgewerkt. De volgende weergaven zijn beschikbaar om query's en rapportage te vereenvoudigen:
Current
De Current-weergave weerspiegelt de meest recente status van de gegevens. Deze weergave vertegenwoordigt een replica van de brontabel, bijgewerkt in bijna realtime. Het voegt gegevens samen uit de Current en Changes partities.
Naam: <EXTERNAL_SCHEMA>.[<PREFIX>]<TABLE_NAME>
Er worden geen koptekstkolommen toegevoegd aan de tabelstructuur.
History
Er wordt een History-weergave gegenereerd in het gegevensassetschema voor elke geselecteerde brontabel wanneer History is ingeschakeld in de instellingen van de gegevenstaak. De History-weergave voegt gegevens samen uit de Prior en Changes partities. Het biedt een volledige tijdlijn van wijzigingen, ideaal voor audits of historische analyses.
Naam: <EXTERNAL_SCHEMA>.[<PREFIX>]<TABLE_NAME>_<Suffix for history views>
De volgende koptekstvelden worden toegevoegd aan de History-weergave:
| Veld | Type | Beschrijving |
|---|---|---|
| hdr__key_hash | BINARY (20) | Hash van alle primaire sleutels van records. |
| hdr__from_timestamp | TIMESTAMP | Het tijdstempel waarop de wijziging plaatsvond in het bronsysteem. Dit weerspiegelt wanneer de gebruiker de wijziging oorspronkelijk heeft aangebracht. |
| hdr__to_timestamp | TIMESTAMP | Het tijdstempel waarop de wijziging werd teruggedraaid of bijgewerkt in het bronsysteem. |
| hdr__store | VARCHAR (10) |
Dit geeft aan waar het record zich bevindt:
|
| hdr__operation | STRING (1) |
Laatste bewerking van dit record.
|
| hdr__deleted | BIT | Geeft aan of het record zacht is verwijderd, gebaseerd op of hdr__operation D of d is. |
| hdr__was_current_from_timestamp | TIMESTAMP | De tijd (UTC) waarop deze rij in de Current partitie is gekomen. Dit is meestal wanneer de opslagtaak is uitgevoerd en de wijziging is toegepast. |
| hdr__was_current_to_timestamp | TIMESTAMP | De tijd (UTC) waarop de rij is verwijderd uit de Current tabel, bijvoorbeeld vanwege een nieuwere versie. |