【DEA-C01】WEB問題集：データ運用とサポート編

WEB問題集

DEA-C01#1(data-operations)

Amazon Athena の主な特徴と適切な用途について、正しい説明はどれですか。

A. 専用のコンピュートクラスターを事前にプロビジョンし、ノード数を指定してクエリ実行する設計のサービスです
B. クエリ結果を Athena 専用ストレージに恒久保存する仕組みで、結果データの再利用と分析を行うサービスです
C. クエリエンジンとして Apache Hive のみをサポートし、Trino / Presto エンジンは非対応となるサービスです
D. S3 上のデータに対しサーバーレスで標準 SQL を実行できるインタラクティブなクエリサービスです

正解と解説ディスカッション 0

正解：D

正解の根拠

Amazon Athena は S3 上のデータに対しサーバーレスで標準 SQL (Trino / Presto ベース) を実行できるインタラクティブクエリサービスです。クラスター管理が不要で、スキャンしたデータ量に基づく従量課金 ($5 / TB スキャン) のため、アドホック分析や定期レポート用途で初期コストを抑えつつ柔軟に利用できます。Glue Data Catalog をメタストアとして利用する点も特徴です。

主要分析サービス比較

サービス	モデル	課金	用途
Athena	サーバーレス SQL	スキャン量 / TB	S3 アドホッククエリ
Redshift	クラスター DWH	ノード時間	定型 BI / 大規模分析
EMR	クラスター Hadoop/Spark	EC2 + EMR 料金	カスタム ETL

Athena クエリ例

SELECT customer_id, SUM(amount) AS total
FROM "datalake"."orders"
WHERE year = '2026' AND month = '05'
GROUP BY customer_id
ORDER BY total DESC
LIMIT 100;

不正解の理由

A: Athena はサーバーレスのため、クラスタープロビジョンやノード数の指定は不要となっています。
B: クエリ結果は指定した S3 バケットに保存される仕組みであり、Athena 専用の恒久ストレージは持ちません。
C: Athena のクエリエンジンは Trino / Presto ベースであるため、Hive 専用ということはありません。

参考：Amazon Athena とは

DEA-C01#2(data-operations)

ある企業では Athena のクエリ実行管理を強化し、ユーザーやチームごとに別々の料金管理・データスキャン上限・結果出力場所を設定したいと考えています。最も適切な機能はどれですか。

A. Athena Federated Query を有効化し、チームごとに別データソースに振分けることで料金を分離する設計にします
B. AWS IAM Group を活用し、チームごとに別 AWS Account を割当てて完全分離する運用方式に切替えます
C. Glue Data Catalog のデータベース単位で料金とスキャン量を別個に管理する設定を有効化する運用にします
D. Athena Workgroup をチームごとに作成し、料金タグ・スキャン上限・出力先 S3 を Workgroup 単位で分離します

正解と解説ディスカッション 0

正解：D

正解の根拠

Athena Workgroup はユーザー / チーム / アプリケーション単位で Athena 実行環境を論理分離する機能です。Workgroup ごとに料金タグ、Per-Query Limit / Per-Workgroup Limit、結果出力先 S3、暗号化設定、Result Reuse の有効化などを別個に設定できます。CloudWatch Alarm との連動でスキャン量超過時の通知も実装でき、本問のチーム別管理要件に最適となります。

Workgroup の主要設定項目

項目	設定内容	用途
Per-Query Limit	1 クエリ最大スキャン量 (MB)	暴走クエリ防止
Per-Workgroup Limit	期間累積スキャン量 (GB/TB)	月次予算管理
Result Configuration	結果出力先 S3 / 暗号化	チーム別保存場所
Cost Allocation Tag	請求書のタグ別集計	料金按分
Engine Version	Athena Engine v2/v3	機能セット選択

Workgroup 作成 CLI

aws athena create-work-group   --name marketing-wg   --configuration "ResultConfiguration={OutputLocation=s3://athena-results-marketing/},BytesScannedCutoffPerQuery=10737418240"

不正解の理由

A: Federated Query はデータソース横断のための機能で、料金管理用途には設計されていません。
B: アカウント分離はオーバーキルであり、運用負荷とコスト管理の複雑化が大きく増加します。
C: Glue Data Catalog はメタデータ管理機能であり、料金やスキャン上限の制御機能は持ちません。

参考：Athena Workgroup によるコスト管理

DEA-C01#3(data-operations)

Amazon Athena で定期的に実行する集計クエリの結果を、別のテーブル (S3 上の Parquet 形式) として保存したい場合、適切な SQL パターンはどれですか。

A. CREATE EXTERNAL TABLE 文で集計結果のテーブル定義のみ作成し、データ自体は元 SELECT を実行時に再計算する方式を取ります
B. CREATE TABLE AS SELECT (CTAS) 文で集計結果を Parquet 形式の新テーブルとして S3 に物理保存する方式を取ります
C. INSERT INTO のみで結果を蓄積する方式とし、テーブル構造は別途 CREATE TABLE で事前定義しておく運用にします
D. CREATE VIEW で論理ビューだけを定義し、物理的なデータ保存は行わない参照型の方式を一貫して採用します

正解と解説ディスカッション 0

正解：B

正解の根拠

Athena の CTAS (Create Table As Select) は、SELECT 結果を新しいテーブルとして物理保存する DDL 文です。出力フォーマット (Parquet / ORC / JSON / TEXTFILE)、圧縮コーデック (SNAPPY / GZIP)、パーティショニング、バケッティングなどを指定できるため、後続クエリのスキャン量を大幅に削減できます。定期レポート用の中間集計テーブルや、データ形式変換 (CSV → Parquet) のユースケースに最適です。

テーブル作成 SQL の比較

SQL	データ保存	用途
CREATE EXTERNAL TABLE	なし (スキーマのみ)	既存 S3 データへの参照
CREATE TABLE AS SELECT (CTAS)	あり (S3 に物理保存)	集計結果の物理化
INSERT INTO	あり (既存テーブルへ追記)	定期更新
CREATE VIEW	なし (論理ビュー)	クエリ抽象化

CTAS 例 (Parquet + パーティション)

CREATE TABLE sales_summary
WITH (
  format = 'PARQUET',
  parquet_compression = 'SNAPPY',
  partitioned_by = ARRAY['year', 'month'],
  external_location = 's3://my-bucket/sales-summary/'
)
AS SELECT customer_id, SUM(amount) total, year, month
FROM raw_sales
GROUP BY customer_id, year, month;

不正解の理由

A: CREATE EXTERNAL TABLE はスキーマ定義のみであり、SELECT 結果の物理保存はできません。
C: INSERT INTO は既存テーブルへの追記であり、初回作成時のスキーマ定義は別途必要です。
D: CREATE VIEW は論理ビューであるため、物理データは保存されず毎回再計算される設計です。

参考：Athena CTAS (Create Table As Select)

DEA-C01#4(data-operations)

Athena で複数のデータソース (S3 + RDS + DynamoDB 等) を横断したクエリを実行したい場合、最も適切な機能はどれですか。

A. Athena Federated Query を使用し、Lambda コネクタ経由で複数のデータソースに直接横断アクセスする構成にします
B. Glue ETL Job で全データを 1 度 S3 にコピーした後、Athena で結合する事前 ETL 方式の運用に切替えます
C. Redshift Spectrum で全データソースを統合し、Athena から Redshift 経由でアクセスする経由構成に切替えます
D. AWS Step Functions で各ソースへの個別クエリを並列実行し、結果を後続で結合する Workflow 構成にします

正解と解説ディスカッション 0

正解：A

正解の根拠

Athena Federated Query は Lambda ベースの Data Source Connector を介して、S3 以外のデータソース (RDS / DynamoDB / Redshift / DocumentDB / Snowflake / 各種 RDB / カスタムソース) に対し標準 SQL でクエリを発行できる機能です。事前 ETL なしに横断分析を実現できる点が大きな利点で、Connector は AWS 公式 / サードパーティ / 自作の選択肢があります。

Federated Query アーキテクチャ

レイヤ	コンポーネント	役割
クエリ層	Athena	SQL 解析・実行プラン生成
連携層	Lambda Data Source Connector	外部ソースとの橋渡し
データ層	RDS / DynamoDB / Redshift 等	実データ保持
結果層	S3 (Spill Bucket)	大規模結果の一時保存

Federated Query 例

SELECT s.order_id, s.amount, c.customer_name
FROM "AwsDataCatalog"."sales"."orders" s
JOIN "rds_connector"."customer_db"."customers" c
  ON s.customer_id = c.id
WHERE s.year = '2026';

不正解の理由

B: 事前 ETL はコピー時間と二重保存のコストが発生し、リアルタイム性も失われてしまう設計です。
C: Redshift Spectrum は Redshift から S3 を参照する機能であり、横断 SQL 用途とは目的が異なります。
D: Step Functions ベースの Workflow は実装負荷が高く、SQL の宣言的な利点も失われてしまいます。

参考：Athena Federated Query

DEA-C01#5(data-operations)

Amazon Athena でクエリパフォーマンスを最適化したい場合、最も効果的なテクニックを 3 つ選んでください。

（3つ選択）

A. Parquet / ORC 等の列指向フォーマットでデータを保存し、クエリ時のスキャン量を最小化する手法を採用します
B. 全データを 1 つの巨大 CSV ファイルに集約し、テーブルスキャン速度を高速化する単一ファイル化方式に切替えます
C. パーティショニング (date / region 等) を活用し、WHERE 句でのスキャン範囲を限定的に絞る設計に切替えます
D. 多数の小ファイルを統合し、最適サイズ (128MB〜1GB) のファイルに圧縮統合するファイルサイズ最適化を実施します
E. Athena Workgroup の Query Result Reuse をリセットし、毎回フルスキャンを強制する設定で運用に切替えます
F. Glue Data Catalog のテーブル統計を無効化し、Athena のクエリ最適化機能を意図的にオフにする運用に切替えます

正解と解説ディスカッション 0

正解：A, C, D

正解の根拠

Athena 性能最適化の代表的な 3 大施策は、(A) 列指向フォーマット (Parquet / ORC) でスキャン量を削減する、(C) パーティショニング (year/month/region 等) で WHERE 句のスキャン範囲を限定する、(D) 多数の小ファイルを 128MB〜1GB に統合して I/O オーバーヘッドを削減する、の 3 つです。これらは AWS 公式の Top 10 Performance Tuning Tips の中核を占める手法であり、組合せて適用することでクエリレイテンシとコストの両面で大幅な改善が期待できます。

Athena 最適化の効果と手段

施策	効果	実装手段
列指向フォーマット化	スキャン量 90% 削減	CTAS / Glue ETL で Parquet 化
パーティショニング	スキャン範囲限定	year=YYYY/month=MM のキー設計
ファイルサイズ最適化	I/O 効率向上	Glue ETL / Iceberg compaction
射影プッシュダウン	列読込み削減	SELECT 必要列のみ指定

パーティション設計サンプル

CREATE EXTERNAL TABLE logs (
  event_id string, message string
)
PARTITIONED BY (year string, month string, day string)
STORED AS PARQUET
LOCATION 's3://my-logs/parquet/';

MSCK REPAIR TABLE logs;
SELECT COUNT(*) FROM logs WHERE year='2026' AND month='05';

不正解の理由

B: 巨大単一 CSV はスキャン量が増加し、並列処理も効きにくいため性能を悪化させてしまいます。
E: Result Reuse のリセットは性能を意図的に下げる設定であり、最適化と逆方向のアプローチとなります。
F: テーブル統計の無効化はクエリオプティマイザの判断材料を失わせ、性能低下を招きます。

参考：Athena パフォーマンスチューニング