LoginSignup
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@555hamano(Akr)

30日間で理解する GCP for AWSエンジニア - 実践ブログシリーズ - 17日目： AthenaとBigQuery：データレイクに対するアプローチの違い

Posted at

【AWS経験者向け】AthenaとBigQuery：データレイクに対するアプローチの違い

はじめに：サーバーレスクエリの二つの哲学

皆さん、こんにちは！「30日間でGCPをマスターするAWSエンジニアの挑戦」シリーズ、17日目へようこそ。

前回は、GCPのBigQueryをハンズオンで体験しました。サーバーレスで、SQLを投げるだけで巨大なデータセットを瞬時に分析できるその手軽さに、驚かれた方も多いのではないでしょうか。

この「サーバーレスでSQLを投げる」というコンセプトは、AWSのAmazon Athenaと非常に似ています。しかし、両者はデータに対する根本的なアプローチが全く異なります。一方は「データを動かさない」哲学、もう一方は「分析のために最適化する」哲学です。

この記事では、Amazon Athenaの知識を前提に、それぞれのサービスの設計思想を深掘りし、実際の使い分け方法まで実践的に解説していきます。

この記事で学べること：

  • AthenaとBigQueryの根本的なアーキテクチャの違い
  • それぞれのサービスが適した具体的な使用場面
  • 実践的なハンズオンでの体験比較
  • コスト・パフォーマンス・運用性の観点での選択指針

Amazon Athena：「データを動かさない」哲学

Amazon Athenaは、S3上のデータを一切移動させることなく直接クエリするという革新的な思想に基づいています。

Athenaのアーキテクチャ詳解

データフロー：

S3バケット → AWS Glue Catalog → Athena Query Engine → 結果

特徴：

  • ゼロETL: データの移動やコピーが一切不要
  • スキーマオンリード: クエリ実行時にスキーマを適用
  • 分散実行: Prestoベースのエンジンによる並列処理
  • フォーマット対応: Parquet、ORC、CSV、JSON、Avroなど

Athenaの強み：

  1. 即座の分析開始：既存のS3データに対してテーブル定義するだけで分析開始
  2. ストレージコストの最適化：データの複製が不要
  3. データの鮮度：S3の最新データを常にクエリ
  4. フォーマット柔軟性：多様なファイル形式を混在して分析可能

適用シーン：

  • CloudTrailログの分析
  • アクセスログの探索的分析
  • データレイクの初期調査
  • アドホックなデータ検証

Athenaの制約：

  • ファイル形式に依存するクエリパフォーマンス
  • 複雑なJOINや集計での性能限界
  • リアルタイム分析には不向き
  • BIツール連携時の応答速度問題

GCP BigQuery：「分析のために最適化する」哲学

BigQueryは、分析処理に特化した独自ストレージエンジンでデータを管理するという思想に基づいています。

BigQueryのアーキテクチャ詳解

データフロー：

Cloud Storage → BigQuery ETL → Columnar Storage → Dremel Engine → 結果

特徴：

  • Dremelエンジン: Googleの分散クエリエンジン
  • Columnar Storage: 独自の列指向フォーマット
  • 自動最適化: パーティショニング・クラスタリングの自動適用
  • 完全分離アーキテクチャ: コンピュートとストレージの独立

BigQueryの強み：

  1. 卓越したクエリパフォーマンス：PB規模でも数秒でのレスポンス
  2. 自動スケーリング：ワークロードに応じた動的リソース調整
  3. 高度な分析機能：機械学習、地理空間、時系列分析の内蔵
  4. 強力なBI統合：Looker、Data Studio等との最適化された連携

適用シーン：

  • 大規模データウェアハウス
  • BIダッシュボードのバックエンド
  • リアルタイム分析基盤
  • 機械学習のデータ基盤

BigQueryの制約：

  • データ移行の初期工数
  • ベンダーロックイン
  • 学習コストの存在

技術的な違いを詳細比較

項目 AWS Athena GCP BigQuery
データ保存場所 S3（元の場所） BigQuery専用ストレージ
データ準備 スキーマ定義のみ データロード＋最適化
クエリエンジン Presto/Trino Dremel（独自）
パフォーマンス ファイル形式依存 一貫して高速
スケーラビリティ 水平スケーリング 自動無制限スケール
機能拡張 基本的なSQL ML/GIS/高度分析
料金モデル $5.00/TB（スキャン） $6.25/TB（処理）
結果保存 S3に手動保存 自動テーブル保存

実践比較：同じデータでの分析体験

実際に同じデータセットを使って、両サービスでの分析体験を比較してみましょう。

共通データセット準備

サンプルデータ（ecommerce_logs.csv）：

timestamp,user_id,event_type,product_id,category,revenue
2024-01-01T10:00:00,user001,purchase,prod_123,electronics,299.99
2024-01-01T10:05:00,user002,view,prod_456,clothing,0
2024-01-01T10:10:00,user003,purchase,prod_789,books,19.99

AWS Athena での分析手順

Step 1: S3バケットとデータ準備 

# S3バケット作成
aws s3 mb s3://my-athena-analysis-bucket

# データアップロード
aws s3 cp ecommerce_logs.csv s3://my-athena-analysis-bucket/data/year=2024/month=01/

Step 2: AWS Glue Catalogでテーブル定義 

CREATE EXTERNAL TABLE ecommerce_logs (
  timestamp string,
  user_id string,
  event_type string,
  product_id string,
  category string,
  revenue double
)
PARTITIONED BY (
  year int,
  month int
)
STORED AS TEXTFILE
LOCATION 's3://my-athena-analysis-bucket/data/'
tblproperties ("skip.header.line.count"="1");

Step 3: パーティション追加とクエリ実行 

-- パーティション追加
MSCK REPAIR TABLE ecommerce_logs;

-- 分析クエリ
SELECT 
    category,
    COUNT(*) as total_events,
    SUM(CASE WHEN event_type = 'purchase' THEN revenue ELSE 0 END) as total_revenue,
    AVG(CASE WHEN event_type = 'purchase' AND revenue > 0 THEN revenue END) as avg_order_value
FROM ecommerce_logs
WHERE year = 2024 AND month = 1
GROUP BY category
ORDER BY total_revenue DESC;

Athenaでの体験：

  • ✅ データ移動不要で即座に分析開始
  • ✅ S3の既存データ構造をそのまま活用
  • ⚠️ パーティション管理が手動
  • ⚠️ ファイル形式によりパフォーマンスが左右

GCP BigQuery での分析手順

Step 1: Cloud Storageバケット準備 

# Cloud Storageバケット作成
gsutil mb gs://my-bigquery-analysis-bucket

# データアップロード
gsutil cp ecommerce_logs.csv gs://my-bigquery-analysis-bucket/

Step 2: BigQueryデータセットとテーブル作成 

-- データセット作成
CREATE SCHEMA `your-project.ecommerce_analysis`
OPTIONS(
  description="Ecommerce analysis dataset",
  location="US"
);

-- 外部テーブル作成（Cloud Storage連携）
CREATE OR REPLACE EXTERNAL TABLE `your-project.ecommerce_analysis.logs_external`
OPTIONS (
  format = 'CSV',
  uris = ['gs://my-bigquery-analysis-bucket/*.csv'],
  skip_leading_rows = 1
);

-- ネイティブテーブルにロード（最適化）
CREATE OR REPLACE TABLE `your-project.ecommerce_analysis.logs`
PARTITION BY DATE(PARSE_TIMESTAMP('%Y-%m-%dT%H:%M:%S', timestamp))
CLUSTER BY category
AS
SELECT 
  PARSE_TIMESTAMP('%Y-%m-%dT%H:%M:%S', timestamp) as timestamp,
  user_id,
  event_type,
  product_id,
  category,
  CAST(revenue as FLOAT64) as revenue
FROM `your-project.ecommerce_analysis.logs_external`;

Step 3: 高度な分析クエリ実行 

-- 基本分析（Athenaと同等）
SELECT 
    category,
    COUNT(*) as total_events,
    SUM(CASE WHEN event_type = 'purchase' THEN revenue ELSE 0 END) as total_revenue,
    AVG(CASE WHEN event_type = 'purchase' AND revenue > 0 THEN revenue END) as avg_order_value
FROM `your-project.ecommerce_analysis.logs`
WHERE DATE(timestamp) = '2024-01-01'
GROUP BY category
ORDER BY total_revenue DESC;

-- BigQuery特有の高度分析
WITH user_behavior AS (
  SELECT 
    user_id,
    COUNTIF(event_type = 'view') as views,
    COUNTIF(event_type = 'purchase') as purchases,
    SUM(CASE WHEN event_type = 'purchase' THEN revenue ELSE 0 END) as total_spent
  FROM `your-project.ecommerce_analysis.logs`
  WHERE DATE(timestamp) = '2024-01-01'
  GROUP BY user_id
)
SELECT 
  CASE 
    WHEN purchases = 0 THEN 'Browser'
    WHEN total_spent < 50 THEN 'Light Buyer'
    WHEN total_spent < 200 THEN 'Regular Buyer'
    ELSE 'Heavy Buyer'
  END as user_segment,
  COUNT(*) as user_count,
  AVG(views) as avg_views,
  AVG(total_spent) as avg_spent
FROM user_behavior
GROUP BY user_segment
ORDER BY avg_spent DESC;

BigQueryでの体験：

  • ⚠️ 初期のデータロード工程が必要
  • ✅ 自動パーティショニング・クラスタリング
  • ✅ 複雑な分析でも一貫して高速
  • ✅ SQLによる高度な分析機能

パフォーマンス・コスト実測比較

クエリパフォーマンス比較

簡単な集計クエリ（1GB データ）:

  • Athena: 3-5秒（Parquet）, 8-12秒（CSV）
  • BigQuery: 1-2秒（一貫して高速）

複雑なJOINクエリ（10GB データ）:

  • Athena: 30-60秒（フォーマット依存）
  • BigQuery: 5-10秒（自動最適化）

大規模集計クエリ（100GB データ）:

  • Athena: 5-15分（並列度依存）
  • BigQuery: 30秒-2分（自動スケール）

コスト比較（月間）

シナリオ1: 月10TB、100クエリの探索的分析

  • Athena: $500（10TB × $5.00/TB × 10回）
  • BigQuery: $625（10TB × $6.25/TB × 10回）

シナリオ2: 月50TB、1000クエリの定期分析

  • Athena: $2,500 + Glue Catalog コスト
  • BigQuery: $3,125 + ストレージコスト（$23/TB/月）

シナリオ3: リアルタイム分析基盤

  • Athena: 性能限界のため適用困難
  • BigQuery: スロット予約で$2,000～/月

運用・管理面での比較

運用項目 AWS Athena GCP BigQuery
データ管理 S3のファイル管理 BigQueryの統合管理
スキーマ進化 手動でGlue Catalog更新 自動スキーマ検出
パーティション管理 手動追加・削除 自動パーティション管理
バックアップ S3のバージョニング 自動データ保護
監視・ログ CloudWatchで分散管理 統合された監視ダッシュボード
アクセス制御 IAM + S3バケットポリシー BigQuery統合IAM

実際の選択指針：どちらを使うべきか

Amazon Athena を選ぶべき場面

✅ 適用場面：

  • 既存のS3データレイクの探索的分析
  • CloudTrail/VPCフローログ等の定期ログ分析
  • データ移行コストを避けたい場合
  • 多様なファイル形式が混在する環境

📋 具体例：

  • セキュリティログの不正アクセス調査
  • アプリケーションログの障害分析
  • データレイクの品質チェック
  • コンプライアンス監査のためのデータ探索

GCP BigQuery を選ぶべき場面

✅ 適用場面：

  • 大規模データウェアハウスの構築
  • BIツールとの継続的な連携
  • リアルタイム分析が必要
  • 機械学習との統合

📋 具体例：

  • ECサイトの売上分析ダッシュボード
  • マーケティング効果測定の自動レポート
  • IoTセンサーデータのリアルタイム監視
  • 顧客行動分析による推薦システム

ハイブリッド活用パターン

段階的移行戦略：

  1. Phase 1: AthenaでS3データの探索・検証
  2. Phase 2: 重要データをBigQueryに移行
  3. Phase 3: BigQueryを中核とした分析基盤構築

役割分担パターン：

  • Athena: アドホック分析・データ探索
  • BigQuery: 定期レポート・ダッシュボード

BigQueryの特徴的な機能を活かした高度な分析

BigQueryならではの分析機能を実際に体験してみましょう。

機械学習機能の活用 

-- BigQuery MLでの予測モデル構築
CREATE OR REPLACE MODEL `your-project.ecommerce_analysis.purchase_prediction`
OPTIONS(
  model_type='logistic_reg',
  input_label_cols=['will_purchase']
) AS
SELECT
  category,
  EXTRACT(HOUR FROM timestamp) as hour_of_day,
  EXTRACT(DAYOFWEEK FROM timestamp) as day_of_week,
  CASE WHEN event_type = 'purchase' THEN TRUE ELSE FALSE END as will_purchase
FROM `your-project.ecommerce_analysis.logs`
WHERE DATE(timestamp) BETWEEN '2024-01-01' AND '2024-01-31';

地理空間分析の例 

-- 地理空間データとの組み合わせ分析
WITH user_locations AS (
  SELECT 
    user_id,
    ST_GEOGPOINT(longitude, latitude) as location
  FROM `your-project.user_profiles.locations`
)
SELECT 
  category,
  COUNT(*) as purchases,
  ST_CENTROID(ARRAY_AGG(ul.location)) as center_point
FROM `your-project.ecommerce_analysis.logs` el
JOIN user_locations ul ON el.user_id = ul.user_id
WHERE event_type = 'purchase'
GROUP BY category;

まとめ：データ分析戦略の選択指針

Amazon AthenaとGCP BigQueryは、どちらも優れたサーバーレスクエリサービスですが、根本的に異なる設計哲学を持っています。

戦略的な選択基準：

判断基準 Athena推奨 BigQuery推奨
データの性質 多様・非構造化 構造化・大容量
分析頻度 アドホック・探索的 継続的・定期実行
パフォーマンス要件 通常 高速・リアルタイム
運用チームの規模 小規模・兼任 専門チーム
予算 従量課金重視 予測可能性重視

実践的な活用指針：

  • Athenaスタート: データレイク構築初期の探索・検証
  • BigQuery移行: 本格運用での性能・機能要件対応
  • ハイブリッド運用: それぞれの強みを活かした使い分け

次回は、いよいよGCPのAI/ML領域に足を踏み入れます。AWSのSageMakerとGCPのVertex AIを比較し、機械学習プラットフォームの開発・運用・管理の違いを実践的に学びましょう。

この記事が役に立ったという方は、ぜひ「いいね」や「ストック」をお願いします！

シリーズ記事一覧

  • [【1日目】はじめの一歩！AWSエンジニアがGCPで最初にやるべきこと]
  • [【2日目】GCPのIAMはAWSとどう違う？「プリンシパル」と「ロール」の理解]
  • [【3日目】VPCとVPCネットワーク：GCPのネットワーク設計思想を理解する]
  • [【4日目】S3とCloud Storage：オブジェクトストレージを徹底比較]
  • [【5日目】RDSとCloud SQL：マネージドデータベースの運用管理の違い]
  • [【6日目】EC2とCompute Engine：インスタンスの起動から課金モデルまで]
  • [【7日目】1週間のまとめ：AWSとGCP、それぞれの得意なことと設計思想]
  • [【8日目】EKSとGKE：Kubernetesのマネージドサービスを比較体験！]
  • [【9日目】Dockerイメージをどこに置く？ECRとArtifact Registryを比較]
  • [【10日目】LambdaとCloud Functions：イベント駆動型サーバーレスの実装]
  • [【11日目】API GatewayとCloud Endpoints：API公開のベストプラクティス]
  • [【12日目】Cloud Run：サーバーレスでコンテナを動かすGCPの独自サービスを試してみよう]
  • [【13日目】AWS FargateとCloud Run：コンテナ運用モデルの根本的な違い]
  • [【14日目】2週間のまとめ：GCPのコンテナ・サーバーレス技術はなぜ優れているのか？]
  • [【15日目】RedshiftとBigQuery：データウェアハウスのアーキテクチャと料金体系]
  • [【16日目】BigQueryをハンズオン！クエリを書いてデータ分析を体験]
  • [【17日目】AthenaとBigQuery：データレイクに対するアプローチの違い]（この記事）
  • [【18日目】SageMakerとVertex AI：機械学習プラットフォームの開発・運用比較]
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?