日々の学習ログついでにまとめておく AWS データ系サービスたち

Data Engineer Associate の勉強を細々と続けて無事合格しました。
そこで今日は、自分が特に迷いやすかったところを、ゆるく整理してみました。

（ふとしたタイミングで見返すと、記憶の引き出しがすぐ開くのでおすすめ。）

---

---

AWS Glue と DataBrew

Glue はとにかく範囲が広くて、試験でも「Glue でできること」と「別サービスでやるべきこと」を混同しがちでした。

なぜ間違えたのか

理由ははっきりしていて、Glue の中にも

• Data Catalog
• Jobs
• Crawlers
• Studio
• DataBrew
  …など複数の機能があるからです。

特に DataBrew を「ノーコードの ETL」と捉えていると、Glue Studio（ノーコード ETL UI）との境界が曖昧になって混乱します。

なぜそうなるのか

アーキテクチャでの役割が違うためでした。

• DataBrew → データの「前処理・整形」のためのツール
• Glue ETL Jobs → 本番 ETL、ジョブ管理、スケジューリング
• Glue Studio → ETL を視覚的に組むためのエディタ

「現場のデータ整理」なら DataBrew、「本番のパイプライン」なら Glue Jobs。
これでようやく腑に落ちました。

---

Amazon Redshift / Redshift Serverless

データウェアハウスの中心でありながら、試験では Redshift のディストリビューションスタイルをよく取り違えてしまいました。

ディストリビューションスタイルの違い

• ALL
  • 小さなディメンションテーブルを全ノードにコピー
  • JOIN が高速
  • 大きいテーブルで使うと逆に遅い
• EVEN
  • 行を均等に分散
  • よく使われる標準スタイル
• KEY
  • 指定したキーで分散
  • JOIN キーを合わせると高速
• AUTO
  • Redshift が最適化してくれる
  • 助かるけど挙動はブラックボックス

なぜ間違えたのか

ALL を「小さいテーブル向け」と覚えていたものの、問題文のテーブルサイズを読み飛ばして誤答…
冷静に考えると、ALL は便利ですがコストも大きいので、使いどころは限られます。

Redshift Serverless の理解ポイント

Serverless は「スケールと料金を意識せず使える」タイプですが、
実は クラスターモードと内部構造は似ている ことを忘れがちでした。

• Data API 対応
• 暗号化やバックアップは自動
• WLM 設定が不要

Lambda やコンテナから動的にクエリするようなシナリオも非常に扱いやすいです。

---

---

Amazon Athena

Athena は使い勝手が良い反面、試験では「コスト管理」と「権限管理」を忘れがちでした。

ワークグループ

• クエリ単位の課金管理
• 制限・メトリクス・アクセス制御を分離
• 複数チームの利用で必須

これを「ただのフォルダ分け」と軽く見ていて間違えたことがあります。
ワークグループは Athena の運用に非常に重要な概念でした。

SPICE

QuickSight の話と混同しがちですが、SPICE は Athena とは別物で「QuickSight のインメモリエンジン」です。
リアルタイムなら Direct Query、パフォーマンスとコスト重視なら SPICE と判断できます。

---

Amazon Lake Formation

Lake Formation でよく迷ったのは、「Glue の権限」と「Lake Formation の権限」の境界です。

列レベル・行レベルのフィルタリング

Lake Formation は

• テーブル
• 列レベル
• 行レベル
  まで細やかにアクセスを制御できます。

なぜ間違えたのか

「Glue Data Catalog を使っているから、権限も Glue で設定する」と誤解していたためです。
実際は逆で、Lake Formation が全体のデータガバナンスを統括します。

「誰が・どの列まで見られるか」を一元管理するのは Lake Formation。
やっとこの構図が理解できました。

---

Parquet / ORC と gzip / snappy

データ形式と圧縮方式は、普段意識せず使ってしまうので試験で差がつきました。

Parquet と ORC の違い

• Parquet
  • 列指向
  • Athena / Redshift Spectrum と相性が良い
  • 汎用性が高い
• ORC
  • Hive 系に最適化
  • より高い圧縮と高速な読み取りが得意

圧縮方式

• gzip
  • 圧縮率は高い
  • 展開は遅い
  • コールドデータ向け
• snappy
  • 展開が速い
  • クエリの多いデータに向く
  • Athena や EMR でよく利用される

なぜ間違えたのか

「圧縮率＝性能」と思い込んでいたこと。
実際は、分析処理は「解凍速度」がボトルネックになることが多く、snappy が選ばれやすい理由もそこにあります。

---

---

まとめ

データエンジニアリング領域は、サービスの役割が似ているものも多く、何がどこまで担当するのかを誤解しやすいところがあります。
試験で実感したのは、「単語暗記よりも、各サービスの立ち位置を理解する方が圧倒的に強い」ということでした。

また忘れかけた頃に読み返して、記憶をあたためたいと思います。