Dataset-arkitektur i en Qlik Open Lakehouse

När du genererar dataset i en Qlik Open Lakehouse genereras lagringstabeller, ändringstabeller och vyer automatiskt av Qlik Talend Data Integration. Du kan ställa frågor mot dessa vyer för att komma åt aktuella och historiska data som lagras i Iceberg open table-format.

Ett intuitivt och väglett användargränssnitt hjälper dig att bygga, modellera och köra data-pipelines. 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 datauppgiftsschema.

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

• Datauppgiftsschemat innehåller de vyer som du kan använda för att konsumera data.

  När ett schema är associerat med mer än en datauppgift måste varje datauppgift använda ett unikt prefix för tabeller och vyer. Du kan ställa in prefixet i datauppgiftens inställningar.

Endast interna scheman kontrolleras för namnkonflikter. För andra scheman måste du se till att det inte finns några namnkonflikter i tabellnamnen. Bästa praxis är att ge det interna schemat samma namn som datauppgiftsschemat med _internal tillagt. Detta säkerställer att varje kombination av schema och prefix är unik.

Tabeller

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

<INTERNAL_SCHEMA>.<TABLE_NAME>_internal

Den här tabellen innehåller fem partitioner, som var och en har ett specifikt syfte för hur data bearbetas och lagras. Varje partition utnyttjar en delmängd av tabellens kolumner baserat på dess roll i datalivscykeln.

Det interna datasetet är strukturerat för att effektivt hantera inkommande data från ditt källsystem, med stöd för inläsning i realtid och historisk spårning. Dataflödet hanteras genom flera specialiserade partitioner, som var och en beskrivs nedan:

• Changes-partition – Inläsning i realtid

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

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

  • Varje ändring taggas med en typ (I, U eller D), vilket indikerar hur den bearbetas.

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

  • Changes-partitionen är tillgänglig när följande inställningar tillämpas i datauppgiften för Lake-mellanlagring.

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

    • Fullständig laddning är aktiverad.

• Asset_state-partition - Spåra förlopp

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

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

  • När ändringar senast tillämpades på Current-partitionen.

  Detta ger full insyn i synkroniserings-pipelinen och hjälper till med övervakning eller felsökning av fördröjningar.

• Current-partition (ODS) – Senaste repliken av källan

  Ändringar från Changes-partitionen tillämpas regelbundet på Current-partitionen för att upprätthålla en uppdaterad, frågeoptimerad kopia av källdata.

  • En bakgrundsuppgift körs automatiskt för att tillämpa dessa uppdateringar. Detta baseras på volymen av ackumulerade ändringar, snarare än 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ågekörning.

• Prior-partition (HDS) – Historiska data

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

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

  • Detta stöder Type 2 slowly changing dimension (SCD2).

  • Prior-partitionen är tillgänglig när Behåll historiska poster och arkiv med ändringsposter är aktiverat på fliken Allmänt i inställningarna för lagringsdatauppgiften.

  • 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 ett tillfälligt mellanlagringsområde under manuella eller schemalagda fullständiga omladdningar:

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

  • Regelbundna underhållsuppgifter raderar eventuella 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 åtgärden är slutförd.

  Denna process säkerställer minimal störning av huvuddatasetet under fullständiga omladdningsåtgärder.

Current-partition

Prior-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ästan realtid. Följande vyer är tillgängliga för att förenkla frågekörning och rapportering:

Current

Current-vyen återspeglar det senaste tillståndet för data. Denna vy representerar en replik av källtabellen, uppdaterad i nästan realtid. Den slår samman data från Current- och Changes-partitionerna.

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

Inga rubrikkolumner läggs till i tabellstrukturen.

History

En History-vy genereras i datatillgångsschemat för varje vald källtabell när History är aktiverat i datauppgiftens inställningar. History-vyn slår samman data från Prior- och Changes-partitionerna. Den ger en komplett tidslinje över ändringar, idealisk för granskning eller historisk analys.

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

Följande rubrikfält läggs till i History-vyn: