Gegevensverzamelingsarchitectuur in een Qlik Open Lakehouse
Wanneer u gegevensverzamelingen genereert in een Qlik Open Lakehouse, worden opslagtabellen, wijzigingstabellen en weergaven automatisch door Qlik Talend Data Integration gegenereerd. U kunt query's uitvoeren voor deze weergaven om toegang te krijgen tot actuele en historische gegevens die in een Iceberg open tabelindeling zijn opgeslagen.
Een intuïtieve en begeleide gebruikersinterface helpt u gegevenspijplijnen te bouwen, modelleren en uit te voeren. U kunt automatisch schema's voor operationele gegevensopslagplaatsen (ODS) en historische gegevensopslagplaatsen (HDS) genereren zonder handmatige codering.
Architectuur voor een Qlik Open Lakehouse-gegevenspijplijn met behulp van Qlik Gegevensgateway - Gegevensverplaatsing. De gegevens komen aan in S3 en worden opgeslagen in een Iceberg open lakehouse. Optioneel, zoals hieronder getoond, kunnen tabellen gespiegeld worden naar een datawarehouse.
Schema's
Artefacten worden gegenereerd in een intern schema en een gegevenstaakschema.
-
Het interne schema bevat een fysieke tabel met meerdere partities.
-
Het gegevenstaakschema bevat de weergaven die u kunt gebruiken om de gegevens te verbruiken.
Als een schema is gekoppeld met meer dan één gegevenstaak, moet voor elke gegevenstaak een uniek prefix voor tabellen en weergaven worden gebruikt. U kunt het prefix instellen in de instellingen van de gegevenstaak.
Alleen interne schema's worden gecontroleerd op naamgevingsconflicten. Voor overige schema's dient u ervoor te zorgen dat er geen naamgevingsconflicten zijn in de tabelnamen. De aanbevolen procedure is om het interne schema dezelfde naam te geven als het gegevenstaakschema met _internal daaraan toegevoegd. Dit zorgt ervoor dat iedere combinatie van schema en prefix uniek is.
Tabellen
Voor elke brontabel wordt een tabel aangemaakt in het interne schema met het suffix _internal, volgens de indeling:
<INTERNAL_SCHEMA>.<TABLE_NAME>_internal
Deze tabel bevat vijf partities, die elk een apart doel dienen in hoe de gegevens verwerkt en opgeslagen worden. Elke partitie maakt gebruik van een subset van de kolommen van de tabel op basis van de rol ervan in de gegevenslevenscyclus.
De interne gegevensverzameling is gestructureerd om inkomende gegevens van uw bronsysteem efficiënt te beheren, met ondersteuning voor opname in realtime en historische tracering. De gegevensstroom wordt beheerd via verschillende gespecialiseerde partities, die hieronder worden beschreven:
-
Changes-partitie – realtime opname
Alle wijzigingen van het bronsysteem — invoegingen, updates en verwijderingen — worden eerst toegevoegd aan de Changes-partitie.
-
De partitie werkt als een onbewerkt wijzigingslogboek en biedt een volledige feed van bronactiviteit voordat er transformaties plaatsvinden.
-
Elke wijziging wordt gelabeld met een type (I, U of D), wat aangeeft hoe het is verwerkt.
-
Gebeurtenissen worden vanaf de bron vastgelegd wanneer ze zich voordoen. De partitie wordt bijna in realtime bijgewerkt.
-
De Changes-partitie is beschikbaar wanneer de volgende instellingen worden toegepast in de gegevenstaak van lake-tussenopslag.
-
Op het tabblad Algemeen is de Bijwerkmethode ingesteld op CDC.
-
Volledige lading is ingeschakeld.
-
-
-
Asset_state-partitie - voortgang bijhouden
Als er 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 volledig inzicht in de synchronisatiepijplijn en helpt bij het bewaken of oplossen van vertragingen.
-
-
Current-partitie (ODS) - laatste replica van de bron
Wijzigingen van de Changes-partitie worden periodiek toegepast op de Current-partitie om een actuele, voor q uery's geoptimaliseerde kopie van de brongegevens te behouden.
-
Er wordt automatisch een achtergrondtaak uitgevoerd om deze updates toe te passen. Dit is gebaseerd op het volume van de samengevoegde wijzigingen, in plaats van een vast schema.
-
De aanvankelijke volledige lading wordt rechtstreeks naar de Current-partitie geschreven.
-
Deze partitie geeft de huidige staat van de gegevens weer en is ontworpen voor efficiënt opvragen.
-
-
Prior-partitie (HDS) – historische gegevens
Wanneer een record in de Current-partitie wordt bijgewerkt of verwijderd, wordt een kopie van de vorige versie naar de Prior-partitie geschreven.
-
Records bevatten metagegevens, waaronder de wijzigingsgeschiedenis en het datumbereik waarop de gegevens geldig zijn.
-
Type 2 slowly changing dimension (SCD2) wordt ondersteund.
-
De Prior-partitie is beschikbaar wanneer Historische records en archief met gewijzigde records behouden is ingeschakeld op het tabblad Algemeen van de instellingen voor de opslaggegevenstaak.
-
Wanneer een bijgewerkte versie van een record de Current-partitie binnenkomt, wordt de vorige record verplaatst naar de Prior-partitie voor historische tracering.
-
-
Reload-partitie
De Reload-partitie fungeert als een tijdelijke opslagplaats tijdens handmatige of geplande volledige ladingen:
-
Nieuwe gegevens worden eerst naar de Reload-partitie geschreven.
-
Regelmatige onderhoudstaken wissen alle in behandeling zijnde wijzigingen voordat ze gepauzeerd worden.
-
Gegevens worden vergeleken met de Current-partitie en alleen de verschillen worden naar de Current-partitie verplaatst.
-
De Reload-partitie wordt gewist wanneer de bewerking is voltooid.
Dit proces zorgt voor minimale verstoring van de hoofdgegevensverzameling tijdens volledige ladingen.
-
Current-partitie
| Veld | Type | Beschrijving |
|---|---|---|
| hdr__key_hash | VARBINARY (20) | Hash van alle primaire recordsleutels. 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 deze record.
|
| hdr__inserted_timestamp | TIMESTAMP | UTC-tijdstempel van de eerste keer dat de sleutel is toegevoegd. Bij het gebruik van volledige lading, de begintijd van de volledige lading. |
| hdr__modified_timestamp | TIMESTAMP | UTC-tijdstempel van het moment dat de laatste update is gemaakt. |
Prior-partitie
| Veld | Type | Beschrijving |
|---|---|---|
| hdr__key_hash | VARBINARY (20) | Hash van alle primaire recordsleutels. |
| hdr__from_timestamp | TIMESTAMP | Tijdstempel in UTC. |
| hdr__to_timestamp | TIMESTAMP | Tijdstempel in UTC. |
| hdr__operation | STRING (1) |
Laatste bewerking van deze record.
|
| hdr__was_current_from_tijdstempel | TIMESTAMP | Tijdstempel in UTC voor de eerste keer dat de record actueel was. |
| hdr__was_current_to_tijdstempel | TIMESTAMP | Tijdstempel in UTC voor de laatste keer dat de 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 deze record.
|
| hdr__timestamp | TIMESTAMP | Tijdstempel in UTC. |
| hdr__key_hash | BINARY (20) | Hash van alle primaire recordsleutels. |
| hdr__inserted_timestamp | TIMESTAMP | UTC-tijdstempel van het tijdstip waarop de wijziging werd verwerkt door Qlik. |
Asset_state-partitie
| Veld | Type | Beschrijving |
|---|---|---|
| hdr__apply_change_identifier | VARCHAR (50) | De wijzigings-id van de laatste wijziging die op de Current-partitie is toegepast. |
| hdr__copy_change_identifier | VARCHAR (50) | De wijzigings-id van de laatste wijziging die op de Current-partitie is toegepast. |
Reload-partitie
De kolommen die door de Reload-partitie worden gebruikt, zijn identiek aan die van de Current-partitie.
Weergaven
Alle gemaakte weergaven worden bijna in realtime bijgewerkt. De volgende weergaven zijn beschikbaar om query's en rapportage te vereenvoudigen:
Huidig
De weergave Huidig geeft de meest recente status van de gegevens weer. Deze weergave vertegenwoordigt een replica van de brontabel, die in bijna-realtime wordt bijgewerkt. Het voegt gegevens van de Current-partitie en Changes-partitie samen.
Naam: <EXTERNAL_SCHEMA>.[<PREFIX>]<TABLE_NAME>
Er worden geen koptekstkolommen toegevoegd aan de tabelstructuur.
Geschiedenis
Een weergave Geschiedenis wordt gegenereerd in het gegevensassetschema voor elke geselecteerde brontabel wanneer Geschiedenis is ingeschakeld in de gegevenstaakinstellingen. De weergave Geschiedenis voegt gegevens samen van de Prior- en Changes-partities. Het biedt een complete 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 weergave Geschiedenis.
| Veld | Type | Beschrijving |
|---|---|---|
| hdr__key_hash | BINARY (20) | Hash van alle primaire recordsleutels. |
| hdr__from_timestamp | TIMESTAMP | Het tijdstempel waarop de wijziging in het bronsysteem heeft plaatsgevonden. Dit geeft aan wanneer de gebruiker de wijziging oorspronkelijk heeft aangebracht. |
| hdr__to_timestamp | TIMESTAMP | Het tijdstempel van het moment waarop de wijziging in het bronsysteem ongedaan is gemaakt of is bijgewerkt. |
| hdr__store | VARCHAR (10) |
Dit geeft aan waar de record zich bevindt:
|
| hdr__operation | STRING (1) |
Laatste bewerking van deze record.
|
| hdr__deleted | BIT | Geeft aan of de record is verwijderd, gebaseerd op if hdr__operation is D of d. |
| hdr__was _current_from_timestamp | TIMESTAMP | De tijd (UTC) waarop deze rij de huidige partitie is binnengekomen.Dit is doorgaans wanneer de opslagtaak is uitgevoerd en de wijziging is toegepast. |
| hdr__was _current_to_timestamp | TIMESTAMP | De tijd (UTC) waarop de rij uit de Current-tabel is verwijderd, bijvoorbeeld vanwege een nieuwere versie. |