DEAデータストアの管理
あるデータエンジニアリングチームが Amazon S3 にクリックストリームデータを蓄積しています(数百億行、Parquet 形式)。以下の要件が新たに追加されました。
・複数の並行書き込みジョブ間での ACID トランザクション保証
・カラムの追加・削除・型変更を含むスキーマエボリューション
・特定時点のデータを参照するタイムトラベルクエリ
・Amazon Athena からのクエリ継続
既存の S3 データレイクアーキテクチャを最小限の変更で拡張するには、どのテーブル形式を採用すべきですか?
AApache Iceberg テーブル形式を採用し、AWS Glue Data Catalog に Iceberg テーブルを登録して Amazon Athena v3 エンジンでクエリする
✓ 正解
Apache IcebergはACIDトランザクション、スキーマエボリューション、タイムトラベルクエリをネイティブにサポートするオープンテーブル形式。Athena v3エンジンはIceberg対応でGlue Data Catalog経由で既存S3レイクに追加でき、要件をすべて最小変更で満たせる。
BAWS Glue ETL ジョブで Parquet ファイルを S3 に書き込み、AWS Glue Data Catalog でメタデータを管理する既存構成を維持する
Parquet+Glue Data Catalogの構成はスキーマメタデータ管理はできるが、複数ジョブ間のACIDトランザクション保証・タイムトラベルクエリ・カラム変更を含む安全なスキーマエボリューションの機能を持たない。
CAmazon Redshift Spectrum を使用して S3 の Parquet ファイルに対してクエリを実行し、Redshift 側でトランザクションを管理する
Redshift SpectrumはS3上のParquetへのクエリは可能だが、S3データレイクレベルでACIDトランザクションやテーブルのタイムトラベル機能を提供するものではなく要件を満たさない。また別途Redshiftクラスターが必要となる。
Dデータを Apache Avro 形式に変換して S3 に保存し、AWS Glue スキーマレジストリでスキーマ変更を管理する
Apache Avroは行指向のシリアライゼーション形式でスキーマ進化に優れるが、ACIDトランザクションやタイムトラベルクエリの機能は持たない。また既存Parquetデータの全変換が必要となり変更が最小限でないという点でも不適切。
解説
Apache Iceberg はデータレイク向けのオープンテーブル形式であり、以下の機能を提供します。
・ACIDトランザクション:スナップショットベースの楽観的並行制御により複数ジョブの同時書き込みでも整合性を保証
・スキーマエボリューション:カラムの追加・削除・名前変更・型変更(型の昇格)を安全に実施可能
・タイムトラベル:スナップショットIDまたはタイムスタンプで過去時点のデータを参照可能
・Athenaとの統合:Athena v3エンジンはIcebergネイティブ対応であり、Glue Data Catalogを介して既存のS3データレイクにIcebergテーブルを追加できるためアーキテクチャ変更が最小限で済みます。
選択肢BのGlue Data Catalogとparquetの既存構成はACID保証・タイムトラベル・安全なスキーマエボリューションを提供しません。
選択肢CのRedshift Spectrumは S3 Parquetをクエリできますが、ACIDトランザクションやテーブル形式のタイムトラベル機能をS3レイヤーで提供するものではありません。
選択肢DのApache Avroは行指向のシリアライゼーション形式でスキーマ進化には優れていますが、ACIDトランザクションやタイムトラベルクエリの機能は持ちません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDEAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →