での Apache Iceberg のリファレンスアーキテクチャ AWS - AWS 規範ガイダンス

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

での Apache Iceberg のリファレンスアーキテクチャ AWS

このセクションでは、バッチ取り込みや、バッチとストリーミングのデータ取り込みを組み合わせたデータレイクなど、さまざまなユースケースでベストプラクティスを適用する方法の例を示します。

夜間のバッチ取り込み

この架空のユースケースでは、Iceberg テーブルがクレジットカード取引を毎晩取り込むとします。各バッチには増分更新のみが含まれており、ターゲットテーブルにマージする必要があります。1 年に数回、完全な履歴データを受信します。このシナリオでは、次のアーキテクチャと設定をお勧めします。

注: これは一例にすぎません。最適な設定は、データと要件によって異なります。

Data flow diagram showing raw storage to Amazon EMR and AWS Glue ETL, then to AWS Glue Data Catalog and data lake.

推奨事項:

  • Apache Spark タスクは 128 MB のチャンクでデータを処理するため、ファイルサイズ: 128 MB。

  • 書き込みタイプ: copy-on-writeこのガイドの前半で説明したように、このアプローチは、データが読み取り最適化方式で書き込まれるようにするのに役立ちます。

  • パーティション変数: 年/月/日。仮定のユースケースでは、最近のデータを最も頻繁にクエリしますが、過去 2 年間のデータに対して完全なテーブルスキャンを実行することがあります。パーティショニングの目的は、ユースケースの要件に基づいて高速読み取りオペレーションを促進することです。

  • ソート順: タイムスタンプ

  • データカタログ: AWS Glue Data Catalog

バッチ取り込みとほぼリアルタイムの取り込みを組み合わせたデータレイク

アカウントとリージョン間でバッチデータとストリーミングデータを共有するデータレイクを Amazon S3 にプロビジョニングできます。アーキテクチャ図と詳細については、 AWS ブログ記事「Apache Iceberg を使用してトランザクションデータレイクを構築する AWS Glue」と「 と AWS Lake Formation Amazon Athena を使用してクロスアカウントデータ共有」を参照してください。