Inställningar för mellanlagring

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

• Databas

  Databas som ska användas i målet.

  Anteckning om informationDet här alternativet är inte tillgängligt vid mellanlagring av data till Qlik Cloud (via Amazon S3).

• Uppgiftsschema

  Du kan byta namn på schemat för mellanlagring av datauppgiften. Standardnamnet är mellanlagring.

  Anteckning om informationDet här alternativet är inte tillgängligt vid mellanlagring av data till Qlik Cloud (via Amazon S3).

• Standardversalisering av schemanamn

  Du kan ange standardversalisering för alla schemanamn. Om din databas är konfigurerad för att tvinga fram versalisering kommer detta alternativ inte att ha någon effekt.

• Prefix för alla tabeller och vyer

  Du kan ange prefix för alla tabeller och vyer som skapas av uppgiften.

  Anteckning om informationDet här alternativet är inte tillgängligt vid mellanlagring av data till Qlik Cloud (via Amazon S3).
  Anteckning om informationDu måste använda ett unikt prefix om du vill använda ett databasschema i flera datauppgifter.

• 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 Ladda om och jämför som uppdateringsmetod.

  • Ladda och jämför

    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.

• Laddningsmetod

  När du replikerar till ett Snowflake-mål kan du välja en av följande laddningsmetoder:

  • Massinläsning (standard)

    Om du väljer Massinläsning kan du, , ställa in laddningsparametrarna på fliken Datainläsning i .

  • Snowpipe Streaming

    Anteckning om information

    Snowpipe Streaming kommer endast att vara tillgänglig för urval om följande villkor är uppfyllda:

    • Uppdateringsmetoden Sammanställning av ändringsdata (CDC) är aktiverad.
    • Autentiseringsmekanismen i Snowflake-kopplingen är inställd på Nyckelpar.
    • Om du använder Data Movement gateway krävs version 2024.11.45 eller senare.

    Om du väljer Snowpipe Streaming, se till att du känner till begränsningarna och beaktanden när du använder den här metoden. Om du dessutom väljer Snowpipe Streaming och sedan byter till uppdateringsmetoden Reload and compare update, kommer laddningsmetoden automatiskt att växla tillbaka till Massinläsning.

  De främsta anledningarna till att välja Snowpipe Ström framför Massinläsning är

  • Mindre kostsamt: Eftersom Snowpipe Streaming inte använder Snowflake-lagret bör driftskostnaderna vara betydligt billigare, även om detta beror på ditt specifika användningsfall.

  • Minskad latenstid: Eftersom data strömmas direkt till måltabellerna (utan mellanlagring) bör replikering från datakällan till målet vara snabbare.

  Anteckning om tipsVid användning av Snowpipe Streaming kommer den första fullständiga laddningen att vara signifikant långsammare än Massinläsning. För att optimera inläsningen, i synnerhet för större datauppsättningar, är det bäst att använda Snowpipe Streaming tillsammans med parallellinläsningsfunktionen.

• Mapp att använda i mellanlagringsområdet

  För dataplattformar där ett mellanlagringsområde behövs (exempelvis Databricks och Azure Synapse Analytics) kan du välja vilken mapp som ska användas när data mellanlagras.

  • Standardmapp

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

  • Rotmapp

    Lagra data i lagringens rotmapp.

    Anteckning om informationDet här alternativet är bara tillgängligt vid mellanlagring av data till Qlik Cloud (via Amazon S3).

  • Mapp

    Ange namnet på mappen som ska användas.

• Ändra bearbetningsintervall

  Du kan ange intervallet mellan bearbetning av ändringar från källan.

  Anteckning om informationDet här alternativet är bara tillgängligt vid mellanlagring av data till Qlik Cloud (via Amazon S3).

• Proxyserver när gateway för Data Movement används

  Anteckning om informationDet här alternativet är bara tillgängligt när du kommer åt data via Data Movement gateway.

  Du kan välja att använda en proxyserver när Data Movement-gatewayen ansluter till molndatalagret och lagringsutrymmet.

  Mer information om att konfigurera Data Movement-gatewayen för användning med en proxyserver finns i Ställa in Qlik Cloud-klientorganisationen och en proxyserver.

  • Använda proxy för att ansluta till molndatalager

    Anteckning om informationTillgänglig när Snowflake, Google BigQuery och Databricks används.

  • Använd proxy för att ansluta till lagringsutrymme

    Anteckning om informationTillgänglig när Azure Synapse Analytics, Amazon Redshift och Databricks används.

Uppladdning av data

Vissa av inställningarna på den här fliken är endast relevanta för specifika målplattformar.

Relevant för alla dataplattformar utom Qlik Cloud och Snowflake

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.

Endast relevant för Google BigQuery

Använd komprimering

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

Relevant endast för Snowflake

På fliken Allmänt kan du välja om du vill läsa in data till Snowflake med Massinläsning eller Snowpipe Streaming. När Snowpipe Streaming är valt visas inte fliken Inläsning av data ). När Massinläsning är valt kommer följande inställningar att vara tillgängliga:

• Maximal filstorlek (MB): Relevant för den inledande fullständiga laddningen och CDC. Den maximala storleken en fil kan nå innan den laddas till målet. Om du får prestandaproblem kan du försöka justera den här parametern.

• Antal filer att ladda per batch: Relevant endast för den inledande fullständiga laddningen. Antalet filer som ska laddas i en enda batch. Om du får prestandaproblem kan du försöka justera den här parametern.

För en beskrivning av laddningsmetoderna Massinläsning och Snowpipe Streaming, se Allmänt.

Metadata

LOB-kolumner

• Inkludera LOB-kolumner och begränsa kolumnstorleken till (kB):

  Du kan välja att inkludera LOB-kolumner i uppgiften och ställa in maximal LOB-storlek. LOB:er som är större än maximal storlek kommer att trunkeras.

  Anteckning om informationNär Azure Synapse Analytics används som mål är den maximala LOB-storleken 7 MB.

Kontrolltabeller

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

• Mellanlagringsstatus: Tillhandahåller information om den aktuella mellanlagringsuppgiften inklusive uppgiftsstatus, mängden minne som förbrukas av uppgiften, antalet ändringar som ännu inte tillämpats på dataplattformen och positionen i källslutpunkten som Data Movement gateway läser in för tillfället.
• Inaktiverade tabeller: Tillhandahåller en lista med inaktiverade tabeller och anledningen till att de inaktiverades.
• Mellanlagringshistorik: Tillhandahåller information om uppgiftshistoriken, inklusive antalet och volymen med poster som bearbetas under mellanlagringsuppgifter, latensen på slutet av en CDC-uppgift med mera.

• DDL-historik: Innehåller en historik med alla DDL-ändringar som stöds som skedde under en uppgift.

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

  Anteckning om informationAmazon Redshift , Amazon S3, Google Cloud Storage och Snowflake kräver Data Movement gateway 2024.11.14 eller senare.

  • Databricks

  • Microsoft Fabric
  • Amazon Redshift
  • Amazon S3
  • Google Cloud-lagring
  • Snowflake

Se Kontrolltabeller för detaljerad beskrivning av alla kontrolltabeller.

Fullständig laddning

Finjustering av prestanda

• Maximalt antal tabeller som ska laddas parallellt: ange det maximala antalet tabeller som ska laddas till målet samtidigt. Som standard är värdet 5.

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

  Anteckning om informationFör att replikera transaktioner som var öppna när fullständig laddning startades men inte överfördes förrän efter att värdet för tidsgränsen nåddes måste du ladda om måltabellerna.
• Allokeringsfrekvens vid fullständig laddning: det maximala antalet händelser som kan överföras tillsammans. Som standard är värdet 10 000.

Efter slutförd fullständig laddning

Skapa primär nyckel eller unik: välj det här alternativet om du vill fördröja skapandet av primärnycklar eller unika index på målet tills efter 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.

Ändra finjustering av behandling

Optimering av avlastning av transaktioner

• 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.

Finjustering av batch

Vissa av inställningarna på den här fliken kanske inte är tillämpliga på alla mål eller målladdningsmetoder.

Inställningar som gäller alla mål utom Qlik Cloud och Snowflake när "Laddningsmetod" är "Snowpipe Streaming"

• Använd grupperade ändringar i intervall:

• Mer än: den kortaste tiden att vänta mellan varje tillämpning av batchändringar. Som standard är värdet 1.

  Om värdet Mer än ökas minskar frekvensen som ändringar tillämpas med på målet samtidigt som storleken på batcherna ökar. Det kan förbättra prestandan när ändringar tillämpas på måldatabaser som är optimerade för bearbetning av stora batcher.

• Mindre än: den längsta tiden att vänta mellan varje tillämpning av batchändringar (innan en tidsgräns överskriden deklareras). Med andra ord, den maximala acceptabla latensen. Som standard är värdet 30. Värdet avgör den maximala tiden att vänta innan ändringarna tillämpas efter att Större än-värdet har nåtts.

• Framtvinga tillämpning av en batch när bearbetningsminnet överskrider (MB): den maximala mängden minne som ska användas vid förbearbetning. Som standard är värdet 500 MB.

  Om du vill ha den maximala batchstorleken ställer du in det här värdet till den maximala mängden minne som du kan allokera till datauppgiften. Det kan förbättra prestandan när ändringar tillämpas på måldatabaser som är optimerade för bearbetning av stora batcher.

• Tillämpa batchade ändringar till flera tabeller samtidigt: att välja det här alternativet bör förbättra prestandan när ändringar tillämpas från flera olika källtabeller.

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

  Anteckning om informationDet här alternativet stöds inte när Google BigQuery används som 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 Som standard är värdet 10 000.

  Anteckning om informationDet här alternativet stöds bara när Google BigQuery används som dataplattform.

Inställningar som endast gäller Qlik Cloud och Snowflake när "Laddningsmetod" är "Snowpipe Streaming"

• 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 in ändringar var (minuter)

  Ställ in antal minuter för intervallet mellan inläsning av ändringar från källan. Giltigt intervall är 1 till 1 440.

  Anteckning om information

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

  • Använda Data Movement gateway
  • Mellanlagring av data från SaaS-programkällor
  • Uppgiften definieras med uppdateringsmetoden för Sammanställning av ändringsdata (CDC)

Diverse finjustering

• 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.

Utveckling av schema

Välj hur du ska hantera följande typer av DDL-ändringar i schemat. När du har ändrat inställningarna för schemautveckling måste du förbereda uppgiften på nytt. I tabellen nedan beskrivs vilka åtgärder som är tillgängliga för de DDL-ändringar som stöds.

Teckenbyte

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.

Parallell inläsning av datauppsättningssegment

Vid fullständig laddning kan du påskynda inläsningen av stora datauppsättningar genom att dela upp datauppsättningen i segment som läses in 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 CDC-uppgifter när du arbetar utan Data Movement gateway

Data Movement gateway stöds inte med en Qlik Talend Cloud Starter-prenumeration och är ett tillval med andra prenumerationsnivåer. När du arbetar utan Data Movement gateway håller du måldata uppdaterade genom att ställa in ett schemaläggningsintervall. Schemat avgör hur ofta måldatauppsättningen ska uppdateras med ändringar i källdatauppsättningen. Medan schemat bestämmer uppdateringsfrekvensen, bestämmer typen av datauppsättning 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 har stöd för CDC (till exempel Vyer) kommer ändringar att tillämpas genom att ladda alla källdata till motsvarande måltabeller. Om vissa av källdatauppsättningarna stöder CDC och andra inte, skapas två separata underuppgifter: en för att ladda om de datauppsättningar som inte stöder CDC, och den andra för att registrera ändringarna i datauppsättningar som stöder CDC. I det här fallet rekommenderas det starkt att du inte använder samma schemaläggningsintervall för båda uppgifterna (om du bestämmer dig för att ändra uppdateringsfrekvensen i framtiden) för att säkerställa datakonsistens.

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å knappen Schemaläggning i verktygsfältet.
2. Ändra schemaläggningsinställningarna efter behov och klicka sedan på OK.