Ansluta till dataströmmar

Följande strömningstjänster stöds i Qlik Open Lakehouse-projekt. Händelsedata matas kontinuerligt in för att säkerställa tillgänglighet nära realtid för nedströms dataintegration, analys och AI, vilket möjliggör pipelines med låg latens som återspeglar den mest aktuella operativa aktiviteten.

Strömningstjänster som Apache Kafka och Amazon Kinesis tillhandahåller hållbara pipelines med hög genomströmning för att fånga operativa händelser när de inträffar. Till skillnad från filbaserade källor som förlitar sig på batchinmatning, levererar strömningskällor data kontinuerligt när händelser produceras, vilket möjliggör bearbetning nära realtid utan att vänta på att filer ska genereras eller schemaläggas. Producenter publicerar strukturerade eller semistrukturerade meddelanden som behåller sitt schema och stöder partitionering. Alla uppdateringar och borttagningar för samma post måste använda samma partitionsnyckel. Kafka och Kinesis garanterar ordning endast inom en enskild partition eller shard, inte över hela ämnet eller strömmen, så att använda en konsekvent partitionsnyckel säkerställer att ändringar för en given post bearbetas i rätt sekvens. Qlik stöder även Amazon S3 som en strömmande källa för kontinuerlig inmatning av händelsedata.

Strömmande inmatning kontra batchinmatning

Skillnaden mellan strömmande och batch-datakällor är följande:

• Med båda källorna matas händelser in effektivt varje minut, vilket stöder bearbetning med låg latens och analys i nära realtid.

• Med icke-strömmande källor sker först en fullständig laddning av befintlig data och sedan matas ändringar in. Du kan också ladda om den fullständiga laddningsdatan från källan.

• Med strömmande källor finns det ingen tydlig skillnad mellan initial laddning och senare händelser. Qlik kan hantera kvarhållning och stöder även partitioner.

I ett Qlik Open Lakehouse projekt kan strömningskällor endast användas med Strömmande mellanlagringsuppgift och Strömmande transformeringsuppgift:

• Strömmande data matas in med hjälp av en Strömmande mellanlagringsuppgift och istället för att bearbeta diskreta filer läser den Strömmande mellanlagringsuppgiften händelser när de anländer, mellanlagrar data i Amazon S3 och sparar händelser som Avro-filer. Denna metod bevarar schemautveckling, stöder komplexa datatyper som strukturer och ger effektiv lagring med optimerad frågeprestanda samtidigt som en kontinuerlig inmatningsmodell bibehålls.

• När du lägger till data från en strömmande källa läggs en strömtransformationsuppgift automatiskt till för varje datamängd som ska lagras i Iceberg-format. Alternativt kan strömtransformationsuppgiften användas för att standardisera strukturer, berika händelsenyttolaster eller anpassa data till nedströms förbrukningsmodeller.

• En dataspeglingsuppgift gör det möjligt att spegla datamängder från strömmande källor till molndatalager, vilket gör att nedströmsystem kan konsumera strömmande händelser utan att duplicera data. Mer information finns i Spegling av data till ett molndatalager.

Datatypsmappningar

Det ursprungliga källschemat baseras på ett urval av data som tagits före FÖRBEREDELSE-fasen när du skapar ditt pipelineprojekt, och schemautveckling hanteras vid läsning. Speglingsuppgifter och andra nedströmsuppgifter som inte stöder STRUCT och ARRAY använder en JSON-typ. Data kan parsas med SQL.

Följande datatypsmappningar gäller för alla datakällor som stöds, men varierar beroende på källfilstypen, och följande bör noteras:

• Datatyper härleds från ett urval av de data som läggs till. Om ett fält till exempel endast innehåller heltalsvärden i urvalet, skapas det som INT8 i strömmande mellanlagrings- och transformeringsuppgifterna. Om efterföljande data inkluderar flyttalsvärden med dubbel precision, innehåller mellanlagringsfilerna dessa värden; men i strömmande transformeringsuppgiften, om inställningen Ändra fältdatatyp är inställd på Ignorera, förblir kolumnen INT8 och flyttalsvärdena trunkeras. För att undvika oavsiktlig trunkering, se till att exempeldata innehåller hela intervallet av förväntade värden innan onboarding, eller konfigurera Ändra fältets datatyp till Stoppa uppgift under tidiga skeden och justera datatyper vid behov.

• Om ett fält läggs till en struct i källan, läggs det alltid till mellanlagringsmålet. För strömmande transformering tillämpas beteendet enligt det alternativ som valts i Inställningar för strömmande transformeringsuppgift > Schemautveckling > Lägg till fält i struct (Tillämpa på mål, Ignorera, Stoppa uppgift).

• Om ett fält saknas i en specifik post, eller om en array är tom, behandlas de som null.

• Om en datamängd plattas ut av en array, och en post anländer där den arrayen är tom eller null, skapar systemet en rad och det utplattade fältet är null. Det utesluts inte automatiskt. Om du vill utesluta dessa rader lägger du manuellt till ett filter, till exempel array_element IS NOT NULL.

• Datatyperna som visas i användargränssnittet återspeglar detaljnivån i den valda datauppsättningen. För utplattade arrayer visas datatypen för det enskilda elementet snarare än själva arraystrukturen.

• Ett nytt attribut kan inte läggas till i en struktur inom ett kapslat JSON-fält, endast på rotnivå.

• I strömmande transformeringsuppgifter stöds utplattning endast för en enda nivå av en array. När utplattning tillämpas på en flernivåarray, till exempel ARRAY<ARRAY<STRUCT>>, plattas endast den yttre arrayen ut, vilket resulterar i ARRAY<STRUCT> snarare än en helt utplattad STRUCT. Dessutom tillåter det nuvarande användargränssnittet att utplattning konfigureras endast på kolumnnivå. Som ett resultat tillämpar val av en flernivåarray implicit utplattning endast på den första arraynivån.

JSON

I JSON-filer bestämmer det numeriska värdet i källan måldatatypen:

• INT8 används för heltalsvärden som ryms inom det intervall för heltal som stöds och inte innehåller en bråkdel.

• REAL8 (DOUBLE) används när värdet innehåller en bråkdel (flyttalsnummer).

• STRING används när det numeriska värdet överskrider det maximala intervall för heltal som stöds.

Datatyper mappas på följande sätt:

CSV, TSV, REGEX, och SPLIT

Som standard matas alla källdatatyper in som en sträng. Använd alternativet, Inferera typer automatiskt, för att mappa käll- och måldatatyper enligt följande:

Parquet

Parquet-filer stöder fysiska och logiska datatyper. Fysiska datatyper definierar hur värden lagras på disk, till exempel INT32, DOUBLE eller BYTE_ARRAY. Logiska datatyper ger semantisk mening utöver den fysiska representationen, till exempel genom att identifiera om ett heltalsvärde representerar ett datum. När en logisk typ är kopplad till en Parquet-kolumn och stöds i Qlik Open Lakehouse (som anges nedan), använder Streaming-mellanlagringsuppgiften den logiska typen när målschemat definieras, snarare än den underliggande fysiska typen. Detta säkerställer att data tolkas korrekt, bevarar avsedd semantik som precision, skala och tidsmässig betydelse, och resulterar i mer exakta scheman när data skrivs till nedströmsformat.

Data som hämtas från Parquet-filer mappas enligt följande:

Avro

Följande mappningar gäller för Avro-filer med schemaregister.

ORC

Följande mappningar gäller för ORC-filer.

Begränsningar

Följande begränsningar gäller för alla datakällor:

• Om dina filer är av olika typer, vilket kan inträffa när de kommer från flera källor eller versioner, tar transformationsuppgiften som skapats med en enda exempelfil (till exempel under introduktionen) inte automatiskt hänsyn till dessa skillnader.

• Om du ändrar datatyperna i mellanlagringsuppgiften, till exempel för att du behöver hasha data, se till att transformationsdatatyperna matchar de nya datatyperna.

Källor som stöds