AWS のデータ分析系サービスは、とにかく種類が多くて名前も似ています。
勉強していると「あれ、これって何のサービスだっけ？」となり、試験中にふと迷うこともありました。ここでは、直近で手こずったサービスを、復習メモも兼ねてゆっくり整理しておきます。
Kinesis Data Streams
Kinesis の問題で間違えやすいポイントは「スループット計算」と「保持期間」。
特に試験で迷ったのは、シャード＝並列度とスループットの単位というところ。
- 1 シャードの上限
- 書き込み：約 1,000 レコード or 1MB/秒
- 読み込み：2MB/秒
- ただし API のリトライとパーティションキーの偏りで実効値が変わる
ここをうっかり「Kinesis Firehose の自動スケーリング」と混同しがち。
Firehose はこっちが気にしなくても自動調整ですが、Streams は自分でシャードを増減します。
試験では「どちらがバッチ処理か？」「どちらがストリームの生レコードか？」を意識すると正誤判断しやすかったです。
Amazon Managed Service for Apache Flink
Flink の難しさは、とにかく「どこまでマネージドか」を間違えがちなところ。
- アプリケーションコードは自分で用意
- スケーリングは自動
- チェックポイント管理もやってくれる
つまり「Glue のようにノーコードでは動かない」。
ここを勘違いして「SQL ベースで処理するサービス」と誤解してしまい、試験で迷いました。
Flink は 複雑なストリーム処理のためのエンジン、という軸で覚えるとわかりやすいです。
Amazon TimeStream
IoT やメトリクスに強い時系列データベース。
間違えたポイントは、
「TTL（保持期間）とストレージ階層が自動で移動する」という仕様を忘れていたこと。
- メモリストア：高速検索
- マグネティックストア：長期保存、低コスト
DynamoDB と比較しそうになりますが、TimeStream は時系列に最適化されていて、クエリも専用の SQL 方言です。「監視データなら CloudWatch Logs でいいのでは？」と思いがちですが、分析前提の可視化なら TimeStream の方が有利。
Amazon Managed Service for Grafana
Grafana Cloud を AWS で簡単に動かすイメージ。
間違えたのは、Grafana と QuickSight を用途で混同しやすかった点。
- Grafana → 時系列データの可視化に強い
- QuickSight → BI ダッシュボード、ビジネス指標向け
試験では「時系列の可観測性ダッシュボードを作りたい」＝Grafana。
Amazon MWAA（Managed Workflows for Apache Airflow）
Airflow のマネージド版。
ミスしがちなのは、「Lambda や Glue ワークフローと混同してしまう」こと。
Airflow は DAG（依存関係付きのワークフロー）を使うので、バッチ処理の順番管理が主役。
さらに
- 実行基盤は自動管理だが
- Python ライブラリやプラグインなどは自分で管理
「全部自動でやってくれる」と思って間違えた問題もあったので反省。
Amazon QuickSight
間違えたポイントは SPICE と直接クエリの違い。
- SPICE：インメモリで速い、データ取り込み（キャッシュ）的
- Direct Query：毎回データソースに問い合わせる
試験では「頻繁に更新されるリアルタイム指標」＝Direct Query
「コスト最適化」「高速」＝SPICE
これで大体判断可能。
AWS Glue
Glue は領域が広すぎて、試験でも毎回混乱しがちなサービスです。
Data Catalog
ここを DynamoDB とか Hive メタストアと混同しがち。
中心にあるのは “メタデータ統合カタログ”。
Schema Registry
EventBridge Schema Registry と混同するミスあり。
Glue のは Kafka や Kinesis Data Streams の Avro スキーマを管理する方。
ワークフロー
Airflow と混同しやすい。
Glue のワークフローは「Glue Job や Crawler の実行順序管理」。Airflow ほど柔軟ではない。
Studio
ここを SageMaker Studio と間違えやすい。
Glue Studio は ETL の可視化と SQL ETL のためのもの。
Detect PII
Glue の識別情報検知機能。
Macie と混同しやすいが、Glue のは “カラムレベルの検知”。
Amazon AppFlow
SaaS から AWS にデータを安全に取り込むサービス。
Salesforce、Slack、S3 などのデータ連携。
間違えたのは、
「ETL の変換機能を期待してしまったこと」。
AppFlow は変換もできるが Glue のような本格 ETL ではない。
Amazon AppSync
GraphQL のマネージドサービス。
誤解しがちなのは、
「REST API の代わり」ではなく「GraphQL リゾルバで複数データソースを統合できる」ところ。
Data Engineer の観点だと、クライアントから動的に必要なデータだけ取ってくる API 層という理解で十分。
Amazon EMR
EMR で間違えやすいのは、ストレージ層の違いです。
HDFS データストア
- EMR クラスター内にだけ存在
- クラスター終了するとデータ消える
- 高速だが弾力性なし
EMRFS データストア
- S3 バックエンド
- 永続化できる
- ただし整合性の問題があり、EMRFS S3 Consistent View が存在
試験では
「長期保管」「スケーラブル」→ EMRFS
「高速性」→ HDFS
で判断できました。
Amazon Redshift / Redshift Serverless
Redshift は一問でも混乱すると連鎖で間違えるので要注意。
Data API（JDBC と比較する出題）
- Data API：SQL を HTTPS 経由で実行。クライアント不要
- JDBC/ODBC：ドライバ必須、持続的接続
「Lambda から簡単に扱いたい」＝Data API。
VACUUM
ここを忘れていて間違えました。
Redshift は列指向だが、行の削除や更新で空き領域が断片化する。
VACUUM はその再整理を行うメンテナンス。
Serverless では自動化が進んでいるので、クラシック版での出題が中心でした。
Amazon Athena
Athena でよく迷うのはワークグループ。
ワークグループ
- 「クエリ単位の請求管理」や「アクセス制御」を分ける仕組み
- チームごとにクエリ上限やコスト制限を設定する
試験ではガバナンス系の文脈でよく出てきます。
Amazon Lake Formation
湖を「安全に」運用するためのサービス。
迷ったのは
「Glue Data Catalog の権限管理との境界」。
Lake Formation は
- 列レベル
- 行レベル
- テーブル単位
などの粒度でアクセス制御ができる。
Glue だけではできない細かさなので、用途を切り分けるのが試験のポイント。
Apache Parquet / ORC と圧縮方式
ここは出題頻度が高いのに、誤差レベルの違いで混乱しがち。
Parquet
- 列指向
- 多くの AWS サービスが最適化（Athena/Redshift Spectrum）
- 汎用性高い
ORC
- Hive や EMR で相性が良い
- 圧縮効率が高く、読み取り最適化
圧縮（gzip vs snappy）
- gzip：圧縮率は高いが解凍が遅い
- snappy：解凍が速く、ETL や Athena に向く
試験での判断ポイントは、
「クエリ速度重視」＝snappy
「ストレージ節約」＝gzip
まとめ
データ系サービスは名前も機能も似ていて、境界を理解していないと試験で混乱します。
今回の復習で気づいたのは、
「サービスを単体ではなく、周辺サービスとの組み合わせで覚える方が間違えにくい」
ということでした。
コメントを残す