Datamängdsarkitektur i en Qlik Open Lakehouse

Strömmande källor har sin egen arkitektur i Qlik Open Lakehouse eftersom de inte kräver Data Movement gateway för att ladda data till mellanlagrings-bucket, utan drivs av lakehouse-klustret.

När du matar in data från filer som inkluderar ett datamönster i filnamnet, gör detta det möjligt för lakehouse-klustret att utföra riktade listoperationer i S3, vilket dramatiskt påskyndar tiden för att läsa fillistan. Dessutom kan Qlik Open Lakehouse förutsäga ankommande filer baserat på datummönstret. Datauppgiften för strömmande mellanlagring behöver inte lista hela bucket varje gång, utan kan istället begära filerna från S3 inom ett specifikt datumintervall. Att ha en mindre fillista leder till bättre prestanda. Den valfria inställningen Ta bort efter laddning kan användas för att bibehålla ett litet filantal. Ingen fullständig laddning utförs, de första posterna betraktas som infogade ändringar.

I en Qlik Open Lakehouse ersätter datauppgiften Streaming Transform lagringsuppgiften. Denna uppgift används för att transformera och lagra mellanlagrade data som Iceberg-tabeller. En Streaming Transform-uppgift kan endast läggas till efter en strömmande mellanlagringsuppgift. Streaming Transform-uppgiften stöder två lägen för att uppdatera poster:

• Endast tillägg: Lägger till nya poster utan att ändra befintliga data, och nyckelbegränsningar upprätthålls inte om dubblettposter anländer.

• Tillämpa ändringar (Sammanfoga): Uppdaterar befintliga poster och infogar nya poster baserat på nyckelfält. Detta läge ger dig möjlighet att använda en mjuk radering, eller behålla historiska data (Typ 2).

Streaming Transform-uppgiften är en målbaserad uppgift som mappar mellan källa och mål och inkluderar funktioner för schemautveckling. Den ger utökade transformeringsfunktioner inklusive uppackning av nästlade strukturer och utplattning av matriser. För mer information om de funktioner du kan använda i Streaming Transform-uppgiften, se Transformationsfunktioner.

När du matar in från en strömmande källa har du möjlighet att konfigurera Iceberg-partitionering, lagringshantering, sorteringskolumner, utgångstid för ögonblicksbild för att kontrollera lagringskostnader och optimera för frågeprestanda.

Mellanlagringstabeller

Följande rubrikfält läggs till i mellanlagringstabellerna. Dessa fält finns alltid i mellanlagringsdata, men som standard inte i nedströms transformering. Du kan lägga till fälten i transformeringen med hjälp av ett uttryck.

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 namnge det interna schemat med 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

Denna tabell innehåller fem partitioner i läget Tillämpa ändringar (Sammanfoga), 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. I läget Endast tillägg har tabellen inga partitioner och beter sig som Current-partitionen (ODS).

Den interna datamängden ä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, som var och en beskrivs nedan:

• Changes-partition – Inmatning i realtid

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

  • Genom att fungera som en rå ändringslogg ger partitionen ett komplett flöde av källaktivitet innan några transformeringar 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 matas 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 synlighet 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 sökning.

• 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å data är giltiga.

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

  • Prior-partitionen är tillgänglig när Behåll historiska poster och arkiv över ä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 slutförs.

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

Current-partition

Prior-partition

Changes-partition

Asset_state-partition

Reload-partition

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

Vyer

Alla skapade vyer uppdateras i nästan realtid. Följande vyer är tillgängliga för att förenkla sökning och rapportering:

Aktuell

Vyn Aktuell återspeglar det senaste tillståndet för data. Denna vy representerar en replik av källtabellen, uppdaterad i nästan 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 Historik-vy genereras i datatillgångsschemat för varje vald källtabell när Historik är aktiverat i datauppgiftens inställningar. Historik-vyn sammanfogar data från partitionerna Prior och Changes. 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 Historik-vyn: