Considerações e limitações

Throughput – Se você usar Direct PUT como fonte para entregar dados às tabelas do Apache Iceberg, o throughput máximo por fluxo será de 5 MiB/segundo nas regiões Leste dos EUA (Norte da Virgínia), Oeste dos EUA (Oregon) e Europa (Irlanda) e de 1 MiB/segundo em todas as outras Regiões da AWS. Se você quiser inserir dados nas tabelas do Iceberg sem atualizações e exclusões e quiser maior throughput para seu fluxo, use o formulário de limites do Firehose para solicitar um aumento do limite de throughput.

Você também pode definir o sinalizador AppendOnly como True se quiser apenas inserir dados e não realizar atualizações e exclusões. Ao definir o sinalizador AppendOnly como True, o Firehose é escalado automaticamente para corresponder ao throughput. Atualmente, você pode definir esse sinalizador somente com a operação da API CreateDeliveryStream.

Se um fluxo Direct PUT passar por controle de utilização devido a maiores volumes de ingestão de dados que excedam a capacidade de throughput de um fluxo do Firehose, o Firehose aumentará automaticamente o limite de throughput do fluxo até que o controle de utilização seja contido. Dependendo do aumento do throughput e do controle de utilização, o Firehose pode levar mais tempo para aumentar o throughput de um fluxo até os níveis desejados. Por esse motivo, tente novamente os registros de ingestão de dados com falha. Se você espera que o volume de dados aumente repentinamente em grandes quantidades ou se seu novo fluxo precisar de um throughput maior do que o limite de throughput padrão, solicite o aumento desse limite.

Transação do S3 por segundo (TPS) – Para otimizar o desempenho do S3, se você estiver usando o Kinesis Data Streams ou o Amazon MSK como origem, recomendamos particionar o registro de origem usando a chave de partição adequada. Dessa forma, os registros de dados roteados para a mesma tabela do Iceberg são mapeados para uma ou algumas partições de origem conhecidas como fragmentos. Se possível, distribua os registros de dados pertencentes a diferentes tabelas do Iceberg de destino em diferentes partições/fragmentos, para que você possa usar todo o throughput agregado disponível em todas as partições/fragmentos do tópico/fluxo de origem.

Colunas: para nomes e valores de colunas, o Firehose usa somente o primeiro nível de nós em um JSON aninhado de vários níveis. Por exemplo, o Firehose seleciona os nós que estão disponíveis no primeiro nível, incluindo o campo de posição. Os nomes das colunas e os tipos de dados de origem devem corresponder exatamente aos das tabelas de destino para que o Firehose entregue com êxito. Nesse caso, o Firehose espera que você tenha uma coluna de tipo de dados struct ou map em suas tabelas do Iceberg que corresponda ao campo de posição. O Firehose oferece suporte a 16 níveis de aninhamento. Veja a seguir um exemplo de JSON aninhado.

{
   "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 os nomes das colunas ou os tipos de dados não corresponderem, o Firehose gerará um erro e entregará os dados ao bucket de erros do S3. Se todos os nomes de colunas e tipos de dados corresponderem nas tabelas do Apache Iceberg, mas você tiver um campo adicional presente no registro da fonte, o Firehose ignorará o novo campo.

Um objeto JSON por registro: é possível enviar somente um objeto JSON em um registro do Firehose. Se você agregar e enviar vários objetos JSON dentro de um registro, o Firehose gerará um erro e entregará os dados ao bucket de erros do S3. Se você agregar registros com KPL e ingerir dados no Firehose com o Amazon Kinesis Data Streams como fonte, o Firehose automaticamente os desagregará e usará um objeto JSON por registro.

Otimização de compactação e armazenamento – Toda vez que você grava nas tabelas do Firehose, ele confirma e gera snapshots, arquivos de dados e arquivos de exclusão. Ter muitos arquivos de dados aumenta a sobrecarga de metadados e afeta a performance de leitura. Para obter a melhor performance de consulta, talvez você queira considerar uma solução que, periodicamente, pegue pequenos arquivos de dados e os grave novamente em um número menor de arquivos de dados maiores. Esse processo é chamado de compactação. O AWS Glue Data Catalog oferece suporte à compactação automática de suas tabelas do Apache Iceberg. Para obter mais informações, consulte Gerenciamento de compactação no Guia do usuário do AWS Glue. Para obter informações adicionais, consulte Automatic compaction of Apache Iceberg Tables. Como alternativa, você pode executar o comando Athena Optimize para realizar a compactação manualmente. Para obter mais informações sobre o comando Otimizar, consulte Athena Optimize.

Além da compactação dos arquivos de dados, você também pode otimizar o consumo de armazenamento com a instrução VACUUM, que realiza a manutenção das tabelas do Apache Iceberg, como a expiração de snapshots e a remoção do arquivo órfão. Como alternativa, é possível usar o AWS Glue Data Catalog, que também oferece suporte à otimização gerenciada de tabelas do Apache Iceberg removendo automaticamente os arquivos de dados, arquivos órfãos e snapshots expirados que não são mais necessários. Para obter mais informações, consulte esta postagem no blog sobre otimização de armazenamento de tabelas do Apache Iceberg.

Não oferecemos suporte à origem do Amazon MSK Serverless para as tabelas do Apache Iceberg como destino.

Para uma operação de atualização, o Firehose coloca um arquivo de exclusão seguido por uma operação de inserção. A inclusão de arquivos de exclusão incorre em cobranças do Amazon S3.

O Firehose não recomenda o uso de vários fluxos do Firehose para gravar dados na mesma tabela do Apache Iceberg. Isso ocorre porque o Apache Iceberg depende do Controle de simultaneidade otimista (OCC). Se vários fluxos do Firehose tentarem gravar em uma única tabela do Iceberg simultaneamente, somente um fluxo conseguirá confirmar os dados por vez. Os outros fluxos que falham na confirmação recuam e repetem a operação de confirmação até que expire a duração configurada para a nova tentativa. Quando a duração da nova tentativa expirar, os dados e as chaves do arquivo de exclusão (caminhos do Amazon S3) são enviados para o prefixo de erro configurado do Amazon S3.

A versão atual da biblioteca do Iceberg compatível com o Firehose é a versão 1.5.2.

Para entregar dados criptografados às tabelas do Amazon S3, você deve configurar os parâmetros do AWS Key Management Service nas tabelas do Amazon S3 e não na configuração do Firehose. Se você configurar os parâmetros do AWS Key Management Service no Firehose para a entrega de dados criptografados às tabelas do Amazon S3, o Firehose não poderá usar esses parâmetros para a criptografia. Para obter mais informações, consulte Utilização da criptografia no lado do servidor com chaves do AWS KMS.

Os fluxos do Firehose só oferecem suporte à entrega para bancos de dados e tabelas criados por meio da API GlueCatalog do Iceberg. A entrega para bancos de dados e tabelas criados por meio do Glue SDK não é suportada. Observe que um hífen (-) não é um caractere aceito para o banco de dados nem para o nome da tabela na biblioteca do Iceberg. Para obter mais detalhes, consulte o Regex do banco de dados do Glue e o Regex da tabela do Glue que são aceitos pela biblioteca do Iceberg.

Todos os arquivos gravados pelo Firehose são computados usando a partição presente no registro. Isso também se aplica aos arquivos excluídos. Não há suporte para exclusões globais, como gravar arquivos de exclusão não particionados em uma tabela particionada.