Amazon Redshift non supporterà più la creazione di nuove UDF Python a partire dal 1º novembre 2025. Se desideri utilizzare le UDF Python, creale prima di tale data. Le UDF Python esistenti continueranno a funzionare normalmente. Per ulteriori informazioni, consulta il post del blog
Importazione in streaming in una vista materializzata
In questo argomento viene descritto come utilizzare le viste materializzate per un rapido accesso ai dati in streaming.
L’importazione in streaming comporta l’importazione dei dati a bassa latenza e ad alta velocità dal flusso di dati Amazon Kinesis
In che modo i dati fluiscono da un servizio di streaming a Redshift
Consente di comprendere come funziona l’importazione in streaming e gli oggetti di database utilizzati nel processo. I dati fluiscono direttamente da un provider di flussi di dati a un cluster con provisioning Amazon Redshift o a un gruppo di lavoro Amazon Redshift serverless. Non esiste un’area di destinazione temporanea, come un bucket Amazon S3. Il cluster con provisioning o il gruppo di lavoro è il consumer del flusso. Nel database Redshift, i dati letti dal flusso finiscono in una vista materializzata. I dati vengono elaborati non appena arrivano. Ad esempio, i valori JSON possono essere consumati e mappati alle colonne di dati di una vista materializzata, con SQL. Quando la vista materializzata viene aggiornata, Redshift utilizza i dati dei shard di dati Kinesis allocati o delle partizioni Kafka fino a quando la vista non viene aggiornata con il flusso.
I casi d’uso per l’importazione in streaming di Amazon Redshift richiedono la gestione di dati generati continuamente e che devono essere elaborati entro un breve periodo, o latenza, dalla loro generazione. Questo si chiama comunemente analisi dei dati quasi in tempo reale. Le origini possono includere i dispositivi IT, i dispositivi di telemetria di sistema e i dati di clickstream di un sito web o un’applicazione occupati.
Best practice di analisi dei dati per il miglioramento delle prestazioni
Quando configuri l’importazione in streaming, sono disponibili opzioni per analizzare i dati in entrata. Le best practice possono includere l’esecuzione della logica aziendale o la formattazione all’arrivo dei dati. Consigliamo di seguire le best practice per evitare errori o perdite di dati. Queste derivano dai test interni e dall’assistenza dei clienti nella risoluzione dei problemi di configurazione e analisi.
Estrazione di valori dai dati in streaming: se utilizzi la funzione JSON_EXTRACT_PATH_TEXT nella definizione della vista materializzata per analizzare o suddividere i dati JSON in streaming, ciò può influire in modo significativo sulle prestazioni e sulla latenza. Per spiegare, per ogni colonna estratta con JSON_EXTRACT_PATH_TEXT, i dati JSON in entrata vengono analizzati di nuovo. Successivamente vengono eseguiti la conversione dei tipi di dati, il filtraggio e i calcoli della logica aziendale. Ciò significa, ad esempio, che, se estrai 10 colonne dai dati JSON, ogni record JSON viene analizzato 10 volte ed è inclusa la logica aggiuntiva. Ciò si traduce in una maggiore latenza di importazione. Un approccio alternativo che consigliamo consiste nell’utilizzare la funzione JSON_PARSE per convertire i record JSON nel tipo di dati SUPER di Redshift. Dopo che i dati in streaming arrivano nella vista materializzata, utilizza PartiQL per estrarre singole stringhe dalla rappresentazione SUPER dei dati JSON. Per ulteriori informazioni, consulta Esecuzione di query sui dati semistrutturati.
Inoltre tieni presente che JSON_EXTRACT_PATH_TEXT ha una dimensione massima dei dati di 64 KB. Pertanto, se un record JSON è più grande di 64 KB, l’elaborazione con JSON_EXTRACT_PATH_TEXT restituisce un errore.
Mappatura di un flusso Amazon Kinesis Data Streams o un argomento Amazon MSK a più viste materializzate: non consigliamo creare più viste materializzate per importare i dati da un singolo flusso o argomento. Questo perché ogni vista materializzata crea un consumer per ogni shard nel flusso di dati o nella partizione Kinesis nell’argomento Kafka. Ciò può comportare una limitazione o un superamento del throughput del flusso o dell’argomento. Inoltre può comportare costi più elevati perché importi gli stessi dati più volte. Quando configuri l’importazione in streaming, consigliamo di creare una vista materializzata per ogni flusso o argomento.
Se il caso d’uso richiede l’importazione di dati da un flusso KDS o da un argomento MSK in più viste materializzate, consulta AWS Big Data Blog
, in particolare Best practices to implement near-real-time analytics using Amazon Redshift Streaming Ingestion with Amazon MSK , prima di procedere.
Comportamento dell’importazione in streaming e tipi di dati
Nella tabella seguente sono descritti i dettagli del comportamento tecnico e i limiti di dimensione per vari tipi di dati. Consigliamo di acquisire dimestichezza prima di configurare una vista materializzata per l’importazione in streaming.
| Caratteristica o comportamento | Descrizione |
|---|---|
| Limite di lunghezza dell'argomento Kafka | Non è possibile utilizzare un nome di un argomento Kafka di lunghezza superiore a 128 caratteri (escluse le virgolette). Per ulteriori informazioni, consulta Nomi e identificatori. |
| Aggiornamenti e JOIN incrementali su una vista materializzata | La vista materializzata deve essere gestibile in modo incrementale. Non è possibile eseguire il ricalcolo completo per Kinesis o Amazon MSK perché per impostazione predefinita non conservano la cronologia dei flussi o degli argomenti per più di 24 ore o 7 giorni. È possibile impostare periodi di conservazione dei dati più lunghi in Kinesis o Amazon MSK. Tuttavia, ciò può comportare una manutenzione maggiore e costi superiori. Inoltre, al momento i JOIN non sono supportati nelle viste materializzate create su un flusso Kinesis o su un argomento Amazon MSK. Dopo aver creato una vista materializzata su un flusso o un argomento, è possibile creare un'altra vista materializzata da utilizzare per connettere la vista materializzata in streaming ad altre viste materializzate, tabelle o viste. Per ulteriori informazioni, consulta REFRESH MATERIALIZED VIEW. |
| Analisi dei record | L'importazione dati in streaming di Amazon Redshift non supporta l'analisi di record aggregati dalla Kinesis Producer Library (Concetti chiave KPL – Aggregazione). I record aggregati vengono importati, ma vengono archiviati come dati buffer del protocollo binario. (Consulta la sezione relativa ai Buffer di protocollo |
| Valori duplicati nelle intestazioni di Kafka | Il client consumer di streaming Amazon Redshift per argomenti Kafka proveniente da Amazon MSK, Confluent o Apache Kafka non supporta i valori duplicati nelle intestazioni degli argomenti Kafka. |
| Decompressione |
|
| Dimensione massima dei record | La dimensione massima di qualsiasi record che Amazon Redshift può importare da un servizio di streaming è 16.777.216 byte (16 MiB), la dimensione massima supportata dal tipo di dati VARBYTE in Amazon Redshift. Tuttavia Kinesis supporta solo una dimensione di record massima pari a 1.048.576 byte (1 MiB). Amazon MSK supporta una dimensione di record massima pari a 16.777.216 byte (16 MiB). Pertanto, per impostazione predefinita, le viste materializzate in streaming di Amazon Redshift create per un flusso di dati Kinesis impostano la dimensione della colonna dei tipi di dati VARBYTE su 1.048.576 byte (1 MiB) e le viste materializzate in streaming di Amazon Redshift create per un argomento Amazon MSK impostano la dimensione della colonna di dati VARBYTE su 16.777.216 byte (16 MiB). Per ulteriori informazioni sui limiti delle dimensioni Kinesis, consulta Quote e limiti nella Guida per gli sviluppatori del flusso di dati Amazon Kinesis. |
| Record che generano errori | Nei casi in cui un record non può essere importato in Redshift perché la dimensione dei dati supera quella massima, tale record viene ignorato. In questo caso, l'aggiornamento della vista materializzata ha comunque esito positivo e un segmento di ogni record che genera un errore viene scritto nella tabella di sistema SYS_STREAM_SCAN_ERRORS. Gli errori derivanti da logica di business, ad esempio un errore in un calcolo o un errore dovuto alla conversione di un tipo, non vengono ignorati. Testa attentamente la logica prima di aggiungerla alla definizione della vista materializzata. |
| Connettività privata multi-VPC di Amazon MSK | La connettività privata multi-VPC di Amazon MSK non è attualmente supportata per l’importazione in streaming Redshift. In alternativa puoi utilizzare il peering di VPC per connettere i VPC o AWS Transit Gateway per connettere i VPC e le reti on-premises tramite un hub centrale. Entrambi possono consentire a Redshift di comunicare con un cluster Amazon MSK o con Amazon MSK serverless in un altro VPC. |
| Aggiornamento automatico, utilizzo e attivazione | Le query di aggiornamento automatico per una o più viste materializzate vengono trattate come qualsiasi altro carico di lavoro dell’utente. L'aggiornamento automatico carica i dati dal flusso non appena arrivano. L'aggiornamento automatico può essere attivato in modo esplicito per una vista materializzata creata per l'importazione di dati in streaming. A tale scopo, specifica |
| Importazione in streaming e Amazon Redshift serverless | Le istruzioni per l’impostazione e la configurazione che si applicano all’importazione in streaming di Amazon Redshift su un cluster con provisioning si applicano anche all’importazione in streaming in Amazon Redshift serverless. È importante specificare il livello di RPU necessario per supportare l’importazione in streaming con l’aggiornamento automatico e altri carichi di lavoro. Per ulteriori informazioni consulta Fatturazione per Amazon Redshift Serverless. |
| Nodi Amazon Redshift in una zona di disponibilità diversa rispetto al cluster Amazon MSK | Quando configuri l’importazione in streaming, Amazon Redshift tenta di connettersi a un cluster Amazon MSK nella stessa zona di disponibilità, se è abilitato il riconoscimento del rack per Amazon MSK. Se tutti i nodi si trovano in zone di disponibilità diverse dal cluster Amazon Redshift, potrebbero venire applicati costi di trasferimento dei dati tra le zone di disponibilità. Per evitare che ciò si verifichi, mantieni almeno un nodo del cluster del broker Amazon MSK nella stessa zona di disponibilità del cluster con provisioning o del gruppo di lavoro Redshift. |
| Posizione dell’aggiornamento iniziale | Dopo avere creato una vista materializzata, l’aggiornamento iniziale comincia da |
| Formati dei dati | I formati di dati supportati sono limitati a quelli che possono essere convertiti da |
| Aggiunta di record a una tabella | Puoi eseguire Le operazioni
|
| Esecuzione di TRUNCATE o DELETE | Puoi rimuovere i record da una vista materializzata utilizzata per l’importazione in streaming, usando quanto segue:
Le operazioni
|
| Identificatori non minuscoli | Quando crei viste materializzate in streaming per argomenti di Streaming gestito da Amazon per Apache Kafka o il flusso di dati Kinesis che contengono identificatori non minuscoli, gli aggiornamenti automatici potrebbero non riuscire. Per risolvere il problema, procedi in uno dei seguenti modi:
NotaL’impostazione di Per ulteriori informazioni sugli identificatori con distinzione tra maiuscole e minuscole, consulta enable_case_sensitive_identifier. |
| Idempotenza |
Amazon Redshift garantisce che ogni record venga elaborato esattamente una volta durante l’importazione di dati da origini in streaming. Questa garanzia si applica a due tipi di origini: Amazon Kinesis (che utilizza identificatori di flussi, shard e numeri in sequenza) e Apache Kafka (che utilizza identificatori di argomento, partizione e offset), inclusi Streaming gestito da Amazon per Apache Kafka (Amazon MSK) e Confluent Cloud. |
