Considerazioni e limitazioni

Throughput: se si utilizza Direct PUT come fonte per fornire dati alle tabelle Apache Iceberg, il throughput massimo per flusso è 5 in tutti gli altri. MiB/second in US East (N. Virginia), US West (Oregon), and Europe (Ireland) Regions and 1 MiB/second Regioni AWS Se desideri inserire dati nelle tabelle Iceberg senza aggiornamenti ed eliminazioni e desideri un throughput più elevato per il tuo stream, puoi utilizzare il modulo Firehose Limits per richiedere un aumento del limite di throughput.

Puoi anche impostare il AppendOnly flag su True se desideri solo inserire dati e non eseguire aggiornamenti ed eliminazioni. Impostando il AppendOnly flag suTrue, Firehose si ridimensiona automaticamente in base alla velocità effettiva. Attualmente, è possibile impostare questo flag solo con l'CreateDeliveryStreamoperazione API.

Se uno stream Direct PUT subisce una limitazione a causa di volumi di acquisizione dati più elevati che superano la capacità di throughput di uno stream Firehose, Firehose aumenta automaticamente il limite di throughput dello stream fino a contenere la limitazione. A seconda dell'aumento del throughput e del throttling, Firehose potrebbe impiegare più tempo per aumentare la velocità di trasmissione di uno stream ai livelli desiderati. Per questo motivo, continua a riprovare i record di acquisizione dei dati non riusciti. Se prevedi che il volume di dati aumenti in caso di picchi improvvisi di grandi dimensioni o se il tuo nuovo stream richiede una velocità di trasmissione superiore al limite di throughput predefinito, richiedi di aumentare il limite di throughput.

S3 Transaction Per Second (TPS): per ottimizzare le prestazioni di S3, se utilizzi Kinesis Data Streams o Amazon MSK come origine, ti consigliamo di partizionare il record di origine utilizzando una chiave di partizione appropriata. In questo modo, i record di dati che vengono indirizzati alla stessa tabella Iceberg vengono mappati su una o più partizioni di origine note come shard. Se possibile, distribuisci i record di dati appartenenti a diverse tabelle Iceberg di destinazione in diverse. partitions/shards, so that you can use all the aggregate throughput available across all the partitions/shards of the source topic/stream

Colonne: per i nomi e i valori delle colonne, Firehose utilizza solo il primo livello di nodi in un JSON annidato a più livelli. Ad esempio, Firehose seleziona i nodi disponibili nel primo livello, incluso il campo di posizione. Affinché Firehose fornisca correttamente i nomi delle colonne e i tipi di dati di origine devono corrispondere a quelli delle tabelle di destinazione. In questo caso, Firehose prevede che nelle tabelle Iceberg sia presente una colonna del tipo di dati struct o map che corrisponda al campo di posizione. Firehose supporta 16 livelli di nidificazione. Di seguito è riportato un esempio di JSON annidato.

{
   "version":"2016-04-01",
   "deviceId":"<solution_unique_device_id>",
   "sensorId":"<device_sensor_id>",
   "timestamp":"2024-01-11T20:42:45.000Z",
   "value":"<actual_value>",
   "position":{
      "x":143.595901,
      "y":476.399628,
      "z":0.24234876
   }
} 

Se i nomi delle colonne o i tipi di dati non corrispondono, Firehose genera un errore e invia i dati al bucket di errore S3. Se tutti i nomi delle colonne e i tipi di dati corrispondono nelle tabelle di Apache Iceberg, ma nel record di origine è presente un campo aggiuntivo, Firehose salta il nuovo campo.

Un oggetto JSON per record: è possibile inviare solo un oggetto JSON in un record Firehose. Se aggregate e inviate più oggetti JSON all'interno di un record, Firehose genera un errore e invia i dati al bucket di errore S3. Se si aggregano record con KPL e si inseriscono dati in Firehose con Amazon Kinesis Data Streams come origine, Firehose si disaggrega automaticamente e utilizza un oggetto JSON per record.

Ottimizzazione della compattazione e dello storage: ogni volta che scrivi su Iceberg Tables utilizzando Firehose, esegue il commit e genera istantanee, file di dati e file eliminati. La presenza di molti file di dati aumenta il sovraccarico dei metadati e influisce sulle prestazioni di lettura. Per ottenere prestazioni di query efficienti, potresti prendere in considerazione una soluzione che acquisisca periodicamente file di dati di piccole dimensioni e li riscriva in file di dati di dimensioni inferiori. Questa procedura è chiamata compattazione. AWS Glue Data Catalog supporta la compattazione automatica delle tabelle Apache Iceberg. Per ulteriori informazioni, consulta la sezione Gestione della compattazione nella AWS Glue User Guide. Per ulteriori informazioni, consulta Compattazione automatica delle tabelle Apache Iceberg. In alternativa, è possibile eseguire il comando Athena Optimize per eseguire la compattazione manualmente. Per ulteriori informazioni sul comando Optimize, consulta Athena Optimize.

Oltre alla compattazione dei file di dati, è possibile ottimizzare il consumo di storage anche con l'istruzione VACUUM che esegue la manutenzione delle tabelle sulle tabelle Apache Iceberg, ad esempio la scadenza delle istantanee e la rimozione dei file orfani. In alternativa, è possibile utilizzarlo per supportare anche l'ottimizzazione gestita delle tabelle di AWS Glue Data Catalog Apache Iceberg rimuovendo automaticamente i file di dati, i file orfani e le istantanee con scadenza che non sono più necessarie. Per ulteriori informazioni, consulta questo post di blog sull'ottimizzazione dello storage delle tabelle Apache Iceberg.

Non supportiamo il codice sorgente Amazon MSK Serverless per Apache Iceberg Tables come destinazione.

Per un'operazione di aggiornamento, Firehose inserisce un file di eliminazione seguito da un'operazione di inserimento. L'inserimento di file eliminati comporta i costi di invio di Amazon S3.