Arkitektur för datauppsättningar i ett Qlik Open Lakehouse

När du genererar datauppsättningar i ett Qlik Open Lakehouse genereras lagringstabeller, ändringstabeller och vyer automatiskt av Qlik Talend Data Integration. Du kan ställa frågor till dessa vyer för att få tillgång till aktuella och historiska data som lagras i Icebergs öppna tabellformat.

Ett intuitivt och interaktivt användargränssnitt hjälper dig att bygga, modellera och köra datapipelines. Du kan automatiskt generera scheman för operativa datalager (ODS) och historiska datalager (HDS) utan manuell kodning.

Scheman

Artefakter genereras i ett internt schema och ett schema för datauppgifter.

• Det interna schemat innehåller en fysisk tabell med flera partitioner.

• Schemat för datauppgifter innehåller de vyer som du kan använda för att förbruka data.

  När ett schema är associerat till fler än en datauppgift måste varje datauppgift använda ett unikt prefix för tabeller och vyer. Du kan ställa in prefixet i inställningarna för datauppgifter.

Enbart interna scheman kontrolleras för namnkonflikter. För övriga scheman måste du säkerställa att det inte förekommer namnkonflikter i tabellnamnen. Bästa metoden är att ge det interna schemat samma namn som datauppgiftsschemat med _internal tillagt. Det säkerställer att alla schema- och prefixkombinationer är unika.

Tabeller

För varje källtabell skapas en tabell i det interna schemat med suffixet _internal, med formatet:

<INTERNAL_SCHEMA>.<TABLE_NAME>_internal

Denna tabell innehåller fem partitioner, som var och en tjänar ett distinkt syfte i hur data bearbetas och lagras. Varje partition utnyttjar en delmängd av tabellens kolumner baserat på dess roll i datalivscykeln.

Den interna datauppsättningen är strukturerad för att effektivt hantera inkommande data från ditt källsystem, med stöd för inmatning i realtid och historisk spårning. Dataflödet hanteras genom flera specialiserade partitioner, var och en beskriven nedan:

• Changes partition – inmatning i realtid

  Alla ändringar från källsystemet – inmatningar, uppdateringar och borttagningar – läggs först till i partitionen Changes.

  • Partitionen fungerar som en rå ändringslogg och ger ett komplett flöde av källaktivitet innan några omvandlingar sker.

  • Varje ändring är märkt med en typ (I, U eller D) som anger hur den behandlas.

  • Händelser fångas upp från källan när de inträffar. Partitionen uppdateras i nära realtid.

  • Partitionen Changes (Ändringar) är tillgänglig när följande inställningar tillämpas i datauppgiften för mellanlagring i datasjö.

    • På fliken Allmänt är Uppdateringsmetod inställd på CDC.

    • Fullständig laddning är aktiverad.

• Asset_state partition – uppföljning av framsteg

  När ändringar tas in loggar Asset_state-partitionen två viktiga tidsmarkörer:

  • När ändringar senast lades till i partitionen Changes.

  • När ändringar senast tillämpades i partitionen Current.

  Detta ger full insyn i synkroniseringens pipeline och hjälper till med övervakning eller felsökning av förseningar.

• Current partition (ODS) – senaste kopia av källan

  Ändringar från partitionen Changes tillämpas periodiskt på partitionen Current för att upprätthålla en aktuell, frågeoptimerad kopia av datakällan.

  • En bakgrundsuppgift körs automatiskt för att tillämpa dessa uppdateringar. Detta baseras på volymen av ackumulerade ändringar, snarare än på ett fast schema.

  • Den initiala fullständiga laddningen skrivs direkt till Current-partitionen.

  • Denna partition återspeglar det aktuella tillståndet för data och är utformad för effektiv frågeställning.

• Prior partition (HDS) – historiska data

  När en post uppdateras eller raderas i Current-partitionen skrivs en kopia av den tidigare versionen till Prior-partitionen. 

  • Poster innehåller metadata, inklusive ändringshistorik och det datumintervall då uppgifterna är giltiga.

  • Detta stöder långsamt förändrade dimensioner av typ 2 (SCD2).

  • Partitionen Prior är tillgänglig när Spara historiska poster och arkivering av ändringsposter är aktiverat på fliken Allmänt i inställningarna för lagringsdatauppgifter.

  • När en uppdaterad version av en post kommer in i Current-partitionen flyttas den tidigare posten till Prior-partitionen för historisk spårning.

• Reload partition

  Reload-partitionen fungerar som en tillfällig samlingsplats under manuella eller schemalagda fullständiga omladdningar:

  • Nya data skrivs först till Reload-partitionen.

  • Regelbundna underhållsåtgärder raderar alla väntande ändringar innan de pausas.

  • Data jämförs med Current-partitionen och endast skillnaderna flyttas till Current-partitionen.

  • Reload-partitionen raderas när operationen är slutförd.

  Denna process säkerställer minimal störning av huvuddatauppsättningen under fullständiga omladdningar.

Nuvarande partition

Tidigare partition

Changes partition

Asset_state partition

Reload partition

De kolumner som används av Reload-partitionen är identiska med Current-partitionen.

Vyer

Alla vyer som skapas uppdateras i nära realtid. Följande vyer finns tillgängliga för att förenkla frågor och rapportering:

Befintlig

Vyn Current visar den senaste statusen för data. Denna vy representerar en replik av källtabellen, uppdaterad i nära realtid. Den sammanfogar data från partitionerna Current och Changes.

Namn: <EXTERNAL_SCHEMA>.[<PREFIX>]<TABLE_NAME>

Inga rubrikkolumner läggs till i tabellstrukturen.

Historik

En Historikvy genereras i schemat för datatillgångar för varje vald källtabell om Historik är aktiverat i inställningarna för datauppgiften. Historikvyn sammanfogar data från partitionerna Prior och Changes. Det ger en fullständig tidslinje över förändringar, perfekt för revision eller historisk analys.

Namn: <EXTERNAL_SCHEMA>.[<PREFIX>]<TABLE_NAME>_<Suffix for history views>

Följande rubrikfält läggs till i historikvyn: