翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 考慮事項と制限事項
<a name="apache-iceberg-considerations"></a>

**注記**  
Firehose は、中国リージョン、アジアパシフィック (台北）、アジアパシフィック (マレーシア）、アジアパシフィック (ニュージーランド) AWS GovCloud (US) Regions、メキシコ (中部) [AWS リージョン](https://docs.aws.amazon.com/glossary/latest/reference/glos-chap.html?icmpid=docs_homepage_addtlrcs#region)を除くすべての で Apache Iceberg Tables を送信先としてサポートしています。

Apache Iceberg テーブルに対する Firehose のサポートには、次の考慮事項と制限があります。
+ **スループット** – **Direct PUT** をソースとして使用して Apache Iceberg テーブルにデータを配信する場合、ストリームあたりの最大スループットは、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド) リージョンでは 5 MiB/秒、その他のすべての AWS リージョンでは 1 MiB/秒になります。データを更新や削除をせずに Iceberg テーブルに挿入し、ストリームのスループットを増やしたい場合は、[Firehose の制限フォーム](https://support.console.aws.amazon.com/support/home#/case/create%3FissueType=service-limit-increase%26limitType=kinesis-firehose-limits)を使用して、スループットの上限の引き上げをリクエストできます。

  データの挿入のみで、更新や削除を行わない場合、`AppendOnly` フラグを `True` に設定することもできます。`AppendOnly` フラグを `True` に設定すると、Firehose はスループットに合わせて自動的にスケーリングします。現在、このフラグは [CreateDeliveryStream](https://docs.aws.amazon.com/firehose/latest/APIReference/API_CreateDeliveryStream.html) API オペレーションでのみ設定できます。

  データ取り込み量が多くなり、Firehose ストリームのスループットキャパシティを超えたために **Direct PUT** ストリームでスロットリングが発生した場合、Firehose はスロットリングが抑制されるまでストリームのスループットの上限を自動的に引き上げます。スループットの増加とスロットリングの状況によっては、Firehose がストリームのスループットを所望のレベルに引き上げるまでに時間がかかる場合があります。このため、失敗したデータ取り込みレコードの再試行を継続します。データ量が突発的に増加することが予想される場合、または新しいストリームでデフォルトのスループット制限よりも高いスループットが必要な場合は、スループットの上限の引き上げをリクエストしてください。
+ **S3 トランザクション/秒 (TPS) **– S3 パフォーマンスを最適化するためには、Kinesis Data Streams または Amazon MSK をソースとして使用している場合、適切なパーティションキーを使用してソースレコードをパーティション化することをお勧めします。このようにして、同じ Iceberg テーブルにルーティングされるデータレコードは、シャードと呼ばれる 1 つまたは複数のソースパーティションにマッピングされます。可能であれば、異なるターゲット Iceberg テーブルに含まれるデータレコードを異なるパーティション/シャードに分散させます。そうすることで、ソーストピック/ストリームのすべてのパーティション/シャードで使用できるすべての集約スループットを使用できるようになります。
+ **[列]** – 列名と値については、Firehose はマルチレベルでネストされた JSON の最初のレベルのノードのみを取得します。例えば、Firehose は、位置フィールドを含む最初のレベルで使用可能なノードを選択します。Firehose が正常に配信するには、ソースデータの列名とデータ型がターゲットテーブルの列名とデータ型と完全に一致している必要があります。この場合、Firehose は、データ型列が位置フィールドと一致するように、Iceberg テーブルで構築またはマッピングされていることを想定します。Firehose は 16 レベルのネストをサポートしています。ネストされた JSON の例を次に示します。

  ```
  {
     "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
     }
  }
  ```

  列名またはデータ型が一致しない場合、Firehose はエラーをスローし、データを S3 エラーバケットに配信します。すべての列名とデータ型が Apache Iceberg テーブルで一致しても、ソースレコードに追加のフィールドが存在している場合、Firehose は新しいフィールドをスキップします。
+ **レコードごとに 1 つの JSON オブジェクト** – 1 つの Firehose レコードに 1 つの JSON オブジェクトのみを送信できます。レコード内で複数の JSON オブジェクトを集約して送信すると、Firehose はエラーをスローし、データを S3 エラーバケットに配信します。[KPL](https://docs.aws.amazon.com/streams/latest/dev/kpl-with-firehose.html) でレコードを集約し、Amazon Kinesis Data Streams をソースとして Firehose にデータを取り込むと、Firehose はレコードごとに 1 つの JSON オブジェクトを自動的に集約解除して使用します。
+ **圧縮とストレージの最適化** – Firehose を使用して Iceberg テーブルに書き込むたびに、スナップショット、データファイル、および削除ファイルをコミットして生成します。データファイルの数が多いと、メタデータのオーバーヘッドが増加し、読み取りパフォーマンスに影響します。効率的なクエリパフォーマンスを実現するには、小さなデータファイルを定期的に取得し、それらをまとめて少数の大きなデータファイルに書き換えるソリューションを検討することをお勧めします。このプロセスは compaction と呼ばれます。 は、Apache Iceberg テーブルの自動圧縮 AWS Glue Data Catalog をサポートしています。詳細については、「*AWS Glue ユーザーガイド*」の「[Compaction management](https://docs.aws.amazon.com/glue/latest/dg/compaction-management.html)」を参照してください。詳細については、「[Automatic compaction of Apache Iceberg Tables](https://aws.amazon.com/blogs/aws/aws-glue-data-catalog-now-supports-automatic-compaction-of-apache-iceberg-tables/)」を参照してください。別の方法として、Athena Optimize コマンドを実行して、圧縮を手動で実行することも可能です。Optimize コマンドの詳細については、「[Athena Optimize](https://docs.aws.amazon.com/athena/latest/ug/optimize-statement.html)」を参照してください。

  データファイルの圧縮に加えて、スナップショットの有効期限や未参照ファイルの削除など、Apache Iceberg テーブルでテーブルメンテナンスを実行する [VACUUM](https://docs.aws.amazon.com/athena/latest/ug/vacuum-statement.html) ステートメントを使用して、ストレージの消費を最適化することもできます。または、 AWS Glue Data Catalog を使用して、データファイルや孤立したファイルを自動的に削除し、不要になったスナップショットを期限切れにすることで、Apache Iceberg テーブルのマネージドテーブル最適化をサポートすることもできます。詳細については、[Apache Iceberg テーブルのストレージ最適化](https://aws.amazon.com/blogs/big-data/the-aws-glue-data-catalog-now-supports-storage-optimization-of-apache-iceberg-tables/)に関するこのブログ記事を参照してください。
+ Apache Iceberg テーブルの送信先としての Amazon MSK Serverless ソースはサポートされていません。
+ 更新オペレーションの場合、Firehose は削除ファイルを配置し、その後に挿入オペレーションを実行します。削除ファイルを配置すると、Amazon S3 PUT 料金が発生します。
+ Firehose では、複数の Firehose ストリームを使用して同じ Apache Iceberg テーブルにデータを書き込むことは推奨されません。これは、Apache Iceberg が[オプティミスティック同時実行制御 (OCC)](https://iceberg.apache.org/docs/1.6.0/reliability/#concurrent-write-operations) に依存しているためです。複数の Firehose ストリームで 1 つの Iceberg テーブルへの同時書き込みを行おうとした場合、特定の時点でデータのコミットに成功するのは 1 つのストリームのみです。コミットに失敗した他のストリームはバックオフし、設定した再試行期間が終了するまでコミットオペレーションを再試行します。再試行期間が過ぎると、設定した Amazon S3 エラープレフィックスにデータと削除ファイルキー (Amazon S3 パス) が送信されます。
+ Firehose がサポートする現在の Iceberg Library バージョンは 1.5.2 です。
+ 暗号化されたデータを Amazon S3 Tables に配信するには、Firehose 設定ではなく、Amazon S3 Tables で AWS Key Management Service パラメータを設定する必要があります。暗号化されたデータを Amazon S3 Tables に配信するように Firehose で AWS Key Management Service パラメータを設定した場合、Firehose はこれらのパラメータを使用して暗号化することはできません。詳細については、「 [AWS KMS キーによるサーバー側の暗号化の使用](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-kms-encryption.html)」を参照してください。
+ Firehose ストリームは、Iceberg の GlueCatalog API を介して作成されたデータベースとテーブルへの配信のみをサポートします。Glue SDK を使用して作成されたデータベースやテーブルへの配信はサポートされていません。ハイフン (`-`) 文字は、Iceberg ライブラリのデータベース名とテーブル名ではサポートされていません。詳細については、Iceberg ライブラリでサポートされている [Glue Database Regex](https://github.com/apache/iceberg/blob/main/aws/src/main/java/org/apache/iceberg/aws/glue/IcebergToGlueConverter.java#L62) と [Glue Table Regex](https://github.com/apache/iceberg/blob/main/aws/src/main/java/org/apache/iceberg/aws/glue/IcebergToGlueConverter.java#L63]) を参照してください。
+ Firehose によって書き込まれたすべてのファイルは、レコードに存在するパーティションを使用して計算されます。これは、削除されたファイルにも適用されます。パーティション化されたテーブルに対するパーティション化されていない削除ファイルの書き込みなどのグローバル削除はサポートされていません。