Inställningar för mellanlagring i datasjö

Du kan konfigurera inställningar för datauppgiften för mellanlagring.

• Öppna mellanlagringsuppgiften och klicka på Inställningar i verktygsfältet.

Dialogrutan Inställningar: <Uppgift-Namn> öppnas. De tillgängliga inställningarna beskrivs nedan.

Allmänt

Uppdateringsmetod

Mellanlagringsuppgiften börjar alltid med en Fullständig laddning. När den Fullständiga laddningen har slutförts kan du hålla mellanlagrade data uppdaterad med någon av följande metoder:

Anteckning om informationDet går inte att ändra uppdateringsmetod när förberedelseåtgärden för mellanlagringsdatauppgiften har slutförts.

• Sammanställning av ändringsdata (CDC)

  Mellanlagrade data hålls uppdaterade med hjälp av tekniken CDC (Change Data Capture). CDC kanske inte stöds av alla datakällor. CDC samlar inte in DDL-åtgärder, till exempel namnbyte för kolumner eller ändringar av metadata.

  Om dina data även innehåller vyer eller tabeller som inte stöder CDC kommer två datapipelines att skapas. En pipeline med alla tabeller som stöder CDC, och en annan pipeline med alla andra tabeller och vyer som använder Läs in som uppdateringsmetod.

• Ladda igen

  Alla mellanlagrade data laddas från källan. Det här är användbart om din källa inte har stöd för CDC men kan användas med alla datakällor som stöds.

  Du kan schemalägga regelbundna laddningar.

  Anteckning om informationDen här inställningen är inte tillgänglig för kopplingar för förhandsgranskning av SaaS-applikationer. Kopplingar för förhandsgranskning anges med en -knapp, både i dialogrutan Skapa koppling och i onlinehjälpen.

Mapp som ska användas

Välj vilken mapp som ska användas när data mellanlagras i mellanlagringsområdet.

• Standardmapp

  Detta skapar en mapp med standardnamnet: <projektnamn>/<datauppgiftens namn>.

• Rotmapp

  Lagra data i lagringens rotmapp.

• Mapp

  Ange namnet på mappen som ska användas.

Datauppladdning

• Maximal filstorlek (MB)

  Den maximala storleken en fil kan nå innan den stängs. Mindre filer kan laddas upp snabbare (beroende på nätverket) och förbättrar prestandan när de används i kombination med alternativet parallell körning. Att belamra databasen med små filer anses emellertid generellt vara en dålig arbetsmetod.

  Anteckning om informationDen här inställningen är relevant för alla dataplattformar utom Qlik Cloud.

• Använd komprimering

  När detta är valt komprimeras CSV-filerna (med gzip) innan de laddas upp till Google BigQuery.

  Anteckning om information

  • Den här inställningen är endast relevant för Google BigQuery.
  • Kräver Gateway för dataflytt 2023.5.16 eller senare.

Metadata

LOB-kolumner

• Inkludera LOB-kolumner och begränsa kolumnstorlek till (KB):

  Du kan välja att inkludera LOB-kolumner i uppgiften och ställa in den maximala LOB-storleken. LOB:ar som är större än den maximala storleken kommer att trunkeras.

  Anteckning om informationNär du använder Azure Synapse Analytics som mål får den maximala LOB-storleken inte överstiga 7 MB.

Kontrolltabeller

Välj vilka av följande kontrolltabeller du vill ska skapas på målplattformen:

• Mellanlagringsstatus: Ger information om den aktuella mellanlagringsuppgiften, inklusive uppgiftsstatus, mängden minne som förbrukas av uppgiften, antal ändringar som ännu inte har tillämpats på dataplattformen och positionen i källslutpunkten från vilken Gateway för dataflytt för närvarande läser.
• Pausade tabeller: Ger en lista över pausade tabeller och anledningen till att de pausades.
• Mellanlagringshistorik: Ger information om uppgiftshistoriken, inklusive antal och volym av poster som bearbetats under en mellanlagringsuppgift, latens i slutet av en CDC-uppgift med mera.

• DDL-historik: Innehåller en historik över alla DDL-ändringar som stöds och som inträffade under en uppgift.

  DDL-historiktabellen stöds endast på följande målplattformar:

  • Databricks

  • Microsoft Fabric
  • Amazon Redshift
  • Om du använder Gateway för dataflytt, behöver följande mål version 2024.11.14 eller senare:
    • Amazon S3
    • Google Cloud-lagring
    • Snowflake
  • Kafka - Om du använder Gateway för dataflytt krävs version 2025.5.42 eller senare.
  • Om du använder Gateway för dataflytt, behöver följande mål version 2025.11.1 eller senare:
    • Google BigQuery
    • Google Cloud Alloy DB for PostgreSQL (via PostgreSQL-kopplingen)
    • Google Cloud SQL for PostgreSQL (via PostgreSQL-kopplingen)
    • Microsoft Azure Database for PostgreSQL (via PostgreSQL-kopplingen)
    • PostgreSQL

För en detaljerad beskrivning av var och en av kontrolltabellerna, se Kontrolltabeller

Fullständig laddning

Prestandajustering

• Maximalt antal tabeller att ladda parallellt: Ange det maximala antalet tabeller som ska laddas till målet samtidigt. Standardvärdet är 5.

• Tidsgräns för transaktionskonsekvens (sekunder): Ange antalet sekunder att vänta på att öppna transaktioner ska stängas innan åtgärden för fullständig laddning påbörjas. Standardvärdet är 600 (10 minuter). Den fullständiga laddningen startar när tidsgränsen har nåtts, även om det fortfarande finns öppna transaktioner.

  Anteckning om informationFör att replikera transaktioner som var öppna när den fullständiga laddningen startade men som bekräftades först efter att tidsgränsen nåddes, måste du ladda om måltabellerna.
• Bekräftelsefrekvens under fullständig laddning: Det maximala antalet händelser som kan överföras tillsammans. Standardvärdet är 10000.

När fullständig laddning har slutförts

Skapa primärnyckel eller unik: Välj det här alternativet om du vill fördröja skapandet av primärnyckeln eller det unika indexet på dataplattformen tills efter att den fullständiga laddningen har slutförts.

För initial laddning

När data flyttas från en SaaS-programkälla kan du ställa in hur den initiala fullständiga laddningen ska utföras.

Felhantering

Datafel

För datatrunkeringsfel: Välj vad du vill ska hända när en trunkering sker i en eller flera poster. Du kan välja något av följande från listan:

• Ignorera: Uppgiften fortsätter och felet ignoreras.
• Inaktivera tabell: Uppgiften fortsätter men data från tabellen med felposten flyttas till ett feltillstånd och dess data replikeras inte
• Stoppa uppgift: Uppgiften stoppas och manuellt ingrepp krävs.

För övriga datafel: Välj vad du vill ska hända när ett fel sker i en eller flera poster. Du kan välja något av följande från listan:

• Ignorera: Uppgiften fortsätter och felet ignoreras.
• Inaktivera tabell: Uppgiften fortsätter men data från tabellen med felposten flyttas till ett feltillstånd och dess data replikeras inte
• Stoppa uppgift: Uppgiften stoppas och manuellt ingrepp krävs.

Eskalera felhantering när övriga datafel når (per tabell) : Välj den här kryssrutan för att eskalera felhantering när antalet icke-trunkeringsdatafel (per tabell) når det angivna antalet: Giltiga värden är 1–10 000.

Eskaleringsåtgärd: Välj vad som ska hända när felhantering eskaleras. Observera att de tillgängliga åtgärderna beror på vilken åtgärd som väljs från listrutan För övriga datafel som beskrivs ovan.

• Inaktivera tabell (standard): Uppgiften fortsätter men data från tabellen med felposten flyttas till ett feltillstånd och dess data landed inte.

• Stoppa uppgift: Uppgiften stoppas och manuellt ingrepp krävs.

Tabellfel

Antal försök innan ett tabellfel returneras

Det här alternativet låter dig styra när principen för hantering av tabellfel ska utlösas. Som standard, efter att ett tabellfel uppstått, kommer tabellen att pausas eller uppgiften att stoppas (enligt den valda åtgärden) efter tre försök. Ibland uppstår ett tabellfel på grund av planerat underhåll av SaaS-applikationen. I dessa fall kanske standardantalet försök inte räcker för att underhållet ska slutföras innan principen för hantering av tabellfel utlöses. Detta beror också på uppgiftens schemaläggningsintervall, eftersom ett nytt försök kommer att utföras varje gång uppgiften körs. Så, till exempel, om du schemalägger en uppgift att köras varje timme och SaaS-applikationen tas offline för underhåll precis när uppgiften börjar köras, kommer standardinställningen med tre försök att tillåta att SaaS-applikationen är offline i upp till tre timmar utan att principen för hantering av tabellfel utlöses. Ett längre underhållsfönster skulle kräva att du ökar antalet försök (eller ändrar schemaläggningen) för att förhindra att principen för hantering av tabellfel utlöses.

Sammanfattningsvis, om du är medveten om att din SaaS-applikation genomgår periodiskt underhåll, är bästa praxis att öka antalet försök enligt schemaläggningen så att underhållet kan slutföras utan att principen för hantering av tabellfel utlöses.

När du stöter på ett tabellfel: välj något av följande från listrutan:

• Stänga av tabell (standard): uppgiften fortsätter men data från tabellen med felposten flyttas till ett feltillstånd och dess data replikeras inte.
• Stoppa uppgift : uppgiften stoppas och manuellt ingrepp krävs.

Eskalera felhantering när tabellfel når (per tabell): välj den här kryssrutan för att eskalera felhantering när antalet tillämpningskonflikter (per tabell) når det angivna antalet. Giltiga värden är 1–10 000.

Eskaleringspolicy: eskaleringspolicyn för tabellfel är inställd på Stoppa uppgift och kan inte ändras.

Miljö

• Maximalt antal nya försök: Välj det här alternativet och ange sedan det maximala antalet försök att utföra en uppgift igen när ett återställningsbart miljöfel inträffar. Efter att uppgiften har försökt utföras det angivna antalet gånger stoppas uppgiften och manuellt ingrepp krävs.

  För att aldrig försöka utföra uppgiften igen avmarkerar du kryssrutan eller anger "0".

  För att försöka utföra uppgiften ett oändligt antal gånger anger du "-1".

  • Mellanrum mellan försök (sekunder): Använd räknaren för att välja eller ange antalet sekunder som systemet väntar mellan försöken att utföra en uppgift.

    Giltiga värden är 0–2 000.

• Förläng intervallet mellan försök vid långa avbrott: Välj den här kryssrutan för att förlänga intervallet mellan försök vid långa avbrott. När det här alternativet är aktiverat fördubblas intervallet mellan varje försök tills Maximalt intervall nås (och fortsätter att försöka enligt det angivna maximala intervallet).
  • Maximalt intervall mellan försök (sekunder): Använd räknaren för att välja eller ange antalet sekunder för väntetiden mellan försöken att utföra en uppgift när alternativet Förläng intervallet för nytt försök vid långa avbrott är aktiverat. Giltiga värden är 0–2 000.

Justering av ändringsbearbetning

Justering av transaktionsavlastning

Avlasta pågående transaktioner till disk om:

Transaktionsdata behålls normalt i minnet tills det är fullständigt överfört till målet eller källan. Men transaktioner som är större än det tilldelade minnet eller inte överförs inom den angivna tidsgränsen kommer att avlastas till disk.

• Total minnesstorlek för alla transaktioner överskrider (MB): den maximala storleken som alla transaktioner kan uppta i minnet innan de avlastas till disk. Standardvärdet är 1024.
• Transaktionens varaktighet överskrider (sekunder): den maximala tiden som varje transaktion kan uppta i minnet innan de avlastas till disk. Varaktigheten beräknas från tiden som Qlik Talend Data Integration började registrera transaktionen. Standardvärdet är 60.

Batchjustering

Vissa av inställningarna på den här fliken

Inställningar som är relevanta för alla mål utom Qlik Cloud:

• Tillämpa batchade ändringar i intervaller:

• Mer än: Den minsta tid att vänta mellan varje tillämpning av batchändringar. Standardvärdet är 1.

  Om du ökar värdet för Mer än minskar frekvensen med vilken ändringar tillämpas på målet, samtidigt som batcharnas storlek ökar. Detta kan förbättra prestandan när ändringar tillämpas på måldatabaser som är optimerade för att bearbeta stora batchar.

• Mindre än: Den maximala tid att vänta mellan varje tillämpning av batchändringar (innan en tidsgräns deklareras). Med andra ord, den maximala acceptabla latensen. Standardvärdet är 30. Det här värdet bestämmer den maximala tid att vänta innan ändringarna tillämpas, efter att värdet för Större än har nåtts.

• Framtvinga tillämpning av en batch när bearbetningsminnet överstiger (MB): Den maximala mängd minne som ska användas för förbearbetning. Standardvärdet är 500 MB.

  För maximal batchstorlek ställer du in det här värdet på den högsta mängd minne du kan allokera till datauppgiften. Detta kan förbättra prestandan när ändringar tillämpas på måldatabaser som är optimerade för att bearbeta stora batchar.

• Tillämpa batchade ändringar på flera tabeller samtidigt: Om du väljer det här alternativet bör prestandan förbättras när ändringar från flera källtabeller tillämpas.

  • Maximalt antal tabeller: Det maximala antalet tabeller att tillämpa batchade ändringar på samtidigt. Standardvärdet är fem.

  Anteckning om informationDet här alternativet stöds inte när du använder Google BigQuery som din dataplattform.

• Begränsa antalet ändringar som tillämpas per ändringsbearbetningssats till: Välj det här alternativet för att begränsa antalet ändringar som tillämpas i en enda ändringsbearbetningssats. Standardvärdet är 10 000.

  Anteckning om informationDet här alternativet stöds endast när du använder Google BigQuery som din dataplattform.

Inställningar som endast är relevanta för Qlik Cloud:

• Maximalt antal ändringar per transaktion: Det minsta antalet ändringar som ska tas med i varje transaktion. Som standard är värdet 1000.

  Anteckning om information

  Ändringarna tillämpas i målet antingen när antalet ändringar är lika med eller större än värdet Minsta antalet ändringar per transaktion ELLER när värdet Maximal tid att samla transaktioner i batcher före tillämpning (sekunder) som beskrivs nedan nås, beroende på vilket som kommer först. Eftersom frekvensen av ändringar som tillämpas på målet styrs av dessa två parametrar kommer ändringar i källposterna eventuellt inte att återspeglas omedelbart i målposterna.

• Maxtid att samla transaktioner i batcher före tillämpning (sekunder): maxtiden för att samla transaktioner i batcher innan en tidsgräns överskrids. Som standard är värdet 1.

Intervall

• Läs ändringar varje (minuter)

  Ställ in intervallet mellan läsning av ändringar från källan i minuter. Det giltiga intervallet är 1 till 1440.

  Anteckning om information

  Det här alternativet är endast tillgängligt när:

  • Du använder Gateway för dataflytt
  • Du mellanlagrar data från SaaS-applikationskällor
  • Uppgiften är definierad med uppdateringsmetoden Change data capture (CDC)

Diverse justeringar

• Cachestorlek för satser (antal satser): Det maximala antalet förberedda satser som ska lagras på servern för senare körning (när ändringar tillämpas på målet). Standardvärdet är 50. Maxvärdet är 200.

• DELETE och INSERT när en primärnyckelkolumn uppdateras: För det här alternativet måste full kompletterande loggning vara aktiverat i källdatabasen.

Schemautveckling

Välj hur följande typer av DDL-ändringar i schemat ska hanteras. När du har ändrat inställningarna för schemautveckling måste du förbereda uppgiften igen. Tabellen nedan beskriver vilka åtgärder som är tillgängliga för de DDL-ändringar som stöds.

Teckenersättning

Du kan ersätta eller ta bort källtecken i måldatabasen och/eller du kan ersätta eller ta bort källtecken som inte stöds av en vald teckenuppsättning.

Byta ut eller radera källtecken

Använd tabellen Ersätt eller ta bort källtecken för att definiera ersättningar för specifika källtecken. Detta kan exempelvis vara användbart när Unicode-representationen av ett tecken är olika på käll- och målplattformarna. Exempelvis visas minustecknet i teckenuppsättningen Shift_JIS som U+2212 på Linux, men på Windows visas det som U+FF0D.

Ersätta eller ta bort källtecken som inte stöds av den valda teckenuppsättningen.

Använd tabellen Källtecken som inte stöds av teckenuppsättning för att definiera ett enda ersättningstecken för alla tecken som inte stöds av den valda teckenuppsättningen.

Fler alternativ

Dessa alternativ visas inte i gränssnittet eftersom de bara är relevanta för specifika versioner eller miljöer. Konfigurera därför inte dessa alternativ om du inte uttryckligen har blivit instruerad att göra det av Qlik Support eller om det står i produktdokumentationen.Qlik

För att ställa in ett alternativ kopierar du bara alternativet i fältet Lägg till funktionsnamn och klickar på Lägg till. Ställ sedan in värdet eller aktivera alternativet enligt de instruktioner du har fått.

Ladda datauppsättningssegment parallellt

Under fullständig laddning kan du påskynda laddningen av stora datauppsättningar genom att dela upp datauppsättningen i segment, som kommer att laddas parallellt. Tabeller kan delas upp efter dataintervall, alla partitioner, alla underpartitioner eller specifika partitioner.

Mer information finns i Parallell mellanlagring av datauppsättningssegment.

Schemalägga uppgifter

I följande användningsfall måste du definiera ett schemaläggningsintervall för att hålla måldata uppdaterade:

• Åtkomst till en datakälla utan Gateway för dataflytt
• Användning av en koppling för en SaaS-applikation som inte stöder inställningen Läs ändringar varje

Schemat bestämmer hur ofta måldatauppsättningarna ska uppdateras med ändringar i källdatauppsättningarna. Medan schemat bestämmer uppdateringsfrekvensen, bestämmer datauppsättningstypen uppdateringsmetoden. Om källdatauppsättningarna stöder CDC (Change data capture) kommer endast ändringarna i källdata att replikeras och tillämpas på motsvarande måltabeller. Om källdatauppsättningarna inte stöder CDC (till exempel vyer) kommer ändringar att tillämpas genom omladdning av alla källdata till motsvarande måltabeller. Om vissa av källdatauppsättningarna stöder CDC och andra inte gör det, skapas två separata underuppgifter: en för att ladda om de datauppsättningar som inte stöder CDC, och den andra för att fånga ändringarna i datauppsättningar som stöder CDC. I det här fallet, för att säkerställa datakonsekvens, rekommenderas det starkt att inte behålla samma schemaläggningsintervall för båda uppgifterna (om du bestämmer dig för att ändra uppdateringsfrekvensen i framtiden).

Information om minsta schemaläggningsintervall beroende på typ av datakälla och prenumerationsnivå finns i Minsta tillåtna schemaläggningsintervall.

Så här ändrar du schemaläggningen:

1. Öppna ditt dataprojekt och gör sedan något av följande:

   • I uppgiftsvyn klickar du på på datauppgiften och väljer Schemaläggning.
   • I pipeline-vyn klickar du på på datauppgiften och väljer Schemaläggning.
   • Öppna mellanlagringsuppgiften och klicka på verktygsfältsknappen Schemaläggning .
2. Ändra schemaläggningsinställningarna efter behov och klicka sedan på OK.

Köra en missad körning för en uppgift baserad på Gateway för dataflytt

Ibland kan ett nätverksproblem leda till att kopplingen till Gateway för dataflytt går förlorad. Om kopplingen till Gateway för dataflytt inte återställs före nästa schemalagda körning kommer inte dataaktiviteten att kunna köras som schemalagt. I sådana fall kan du välja om du vill köra en körning eller inte omedelbart efter att kopplingen har återställts.

Standardinställningarna för alla Gateway för dataflytt är definierade i aktivitetscentret Administration. Du kan åsidosätta dessa inställningar för enskilda uppgifter enligt beskrivningen nedan.

Gör så här

1. Öppna ditt projekt och gör sedan något av följande:

   • I uppgiftsvyn klickar du på på datauppgiften och väljer Schemaläggning.

   • I pipeline-vyn klickar du på på datauppgiften och väljer Schemaläggning.

   • Öppna datauppgiften och klicka på verktygsfältsknappen Schemaläggning .

   Dialogrutan Schemaläggning - <uppgift> öppnas.

2. Slå på Använd anpassade inställningar för den här uppgiften.

3. Längst ner i dialogrutan väljer du ett av följande alternativ för Kör missade schemalagda uppgifter.

   • Så snart som möjligt och sedan enligt schema om det är viktigt att köra en uppgift före nästa schemalagda instans

   • Enligt schema för att köra uppgiften vid nästa schemalagda instans

4. Spara dina inställningar.

Se även: Utförande av en uppgiftskörning efter ett missat schema.