トップ > Amazon Quick Suite > 【Athena不要】Amazon S3とAmazon Quick Suiteだけで超ミニマム構成のデータ分析基盤を作る

【Athena不要】Amazon S3とAmazon Quick Suiteだけで超ミニマム構成のデータ分析基盤を作る

Amazon Quick Suite
記事タイトルとURLをコピーする

さとうです。

Amazon QuickSightがAmazon Quick Suiteにリブランディングされて「Quick Sight」になりましたが、これと同時にQuick Sightのデータセットも新しいUIが用意されて機能が大幅に強化されたことを皆さんはご存知でしょうか（以後Amazonは省略します）。

aws.amazon.com

この新しいデータセット機能を活用するとS3とQuick SuiteだけでAthenaすらいらない超ミニマムなデータ分析基盤が構成できるかもしれない！という記事です。

新しくなったデータセット機能について

できること

そもそもデータセットとは、Quick Sight上でデータソースとして取り込んだデータのフィールド名の成型や型定義など、事前のデータ成型を行うための機能です。

従来はデータ型の調整に使うといった用途が中心だったように思いますが、新しいUIが導入されてからはSQLのUNIONやJOINなどの込み入った処理もGUIから視覚的に設定できるようになり、技術者以外にも非常に使いやすい機能になりました。

視覚的に加工処理を並べることができる

一部の加工機能を使うにはSPICEへのデータの取り込みが必要ですが、「ロードコードでマテリアライズドビューを定義できる機能」というのがイメージとしては近いでしょうか。

以下にあるように、10種の加工機能をローコードツールのような使い勝手で視覚的に使用することができます。

https://docs.aws.amazon.com/ja_jp/quicksuite/latest/userguide/data-prep-steps.htmldocs.aws.amazon.com

No. 機能名 機能
1 データ型を変更 データの型を変更
2 参加（結合） テーブルAとテーブルBを結合
3 列を選択 フィールドの取捨選択
4 計算された列を追加 計算されたフィールドを追加
5 フィルター データを特定条件でフィルタ
6 付加（連結） テーブルAにテーブルBを挿入
7 集計 フィールドの値の集約
8 列の名前を変更 フィールドの名前を変更
9 ピボット データをピボットする
10 ピボット解除 データのピボットを解除する

※日本語のUIからそのまま引用していますが、一部日本語が不自然で「参加」は「結合（JOIN）」、付加は「連結（UNION）」の意味ですね。

できないこと

レガシーエクスペリエンス（旧UI）からの過渡期なので、完全に下方互換性があるわけではありません。いくつかサポートされていないデータソースや機能があります（順次対応予定とのことです）。

https://docs.aws.amazon.com/ja_jp/quicksuite/latest/userguide/unsupported-features.htmldocs.aws.amazon.com

例として地理空間のデータ型がサポートされていないようなので、郵便番号を地理空間データ型にして地図にマッピングするような視覚化は新しいデータセットだとまだできないようです。

Quick Suiteだけでデータマートが作れる時代に？

この新しいデータセットですが、SPICEと組み合わせると実質的にマテリアライズドビューのような振る舞いをするので、一通り触った後に「 S3とQuick Suiteだけでデータマートが作れてしまうのでは？」とふと思いました。

Quick SuiteはS3を直接データソースにすることができるので、加工機能をQuick Suiteに持たせることができればAthenaさえ不要になるかもしれません。

Quick Suiteに流し込む前の文字コード統一や成型などのクレンジング処理は外側で必要かもしれませんが、テーブル結合や集計などのデータマートを作る上で基本的な処理は揃っているように思えます。ローコードでデータマートをオンデマンドに作成できるとしたら、ビジネス部門のユーザにとっては魅力的な選択肢ですよね。

従来型のミニマム構成との比較

ミニマムなデータ分析基盤（Data Ware House=DWH）をAWSネイティブで構築する場合、AthenaとS3の組み合わせでサーバレス型の疑似的なDWHとする構成が有名です。

構成図にすると以下のようになりますが、AthenaとS3のほかに更新ジョブを制御するStep FunctionsとEventBridge、メタデータを保存するためのGlue Data Catalogとスキーマ検出用のCrawler... など実用レベルで運用しようとするとサービスの組み合わせが必要です。データマートの保存形式（ParquetやS3 Tables）なども検討が必要でしょうか。

構成要素が意外と多くなる

Quick Suiteだけの超ミニマム構成

Quick Suiteの組み込み機能だけで構成しようとするとこうなります。いかにシンプルになるかが伝わると思います。

S3とQuick Suiteがあれば大丈夫

実際に作って使ってみる

サンプルデータをデータソースとして登録する

Webサービスのアクセスログテーブル（トランザクションデータ）とユーザ一覧テーブル（マスタデータ）を用意し、このテーブルを内部結合した上で会員ランクと年代値別の滞在時間の平均を集計する加工処理をしたいとします。

加工のイメージは画像の通りです。

以下の通りサンプルデータを用意しました。ランダム生成なので特に規則性はありません。

access_log.csv

log_id,timestamp,user_id,page_url,duration
58443d01a0e643609114979641dbbf87,2026-01-01 19:55:27,4359ce25,/search,187
4eaf432b58b54e6c81eb8dea57d60255,2026-01-01 15:40:26,2f0515d2,/cart,74
502ac8a5ca75426e8ba53c92d4c8e7b4,2026-01-01 01:53:58,756c01f5,/home,79
...

users.csv

user_id,gender,age_group,membership,pref
2c7d7eea,Other,20s,Basic,福井県
66a6d398,Male,40s,Basic,山梨県
94ce1dc4,Male,50s,Premium,滋賀県
...

access_log.csvについては日次のトランザクションデータとして、2026-01-01~2026-01-03までの3日分のデータを用意してS3上に以下のように配置します。

manifests/access_logs.json
manifests/users.json
mst/users.csv
trx/access_logs/year=2026/month=01/day=01/access_logs.csv
trx/access_logs/year=2026/month=01/day=02/access_logs.csv
trx/access_logs/year=2026/month=01/day=03/access_logs.csv

日付をHive形式で記載していますが、Quick Suite自体はHive形式を認識しないので特に意味や効果はありません。ただし後述するマニフェストファイルでデータソースの取り込み範囲を制御するため規則的な配置にすることは重要です。

manifests/にあるJSONはQuick Suiteでデータソースとして認識させるためのマニフェストファイルで、以下のように記載しています。

access_logs.jsonは前方一致でmonth=01/以下にあるファイル全てがデータソースとして取り込まれます。

access_logs.json

{
    "fileLocations": [
        {
            "URIPrefixes": [
                "s3://<バケット名>/trx/access_logs/year=2026/month=01/"
            ]
        }
    ],
    "globalUploadSettings": {
        "format": "CSV",
        "delimiter": ",",
        "containsHeader": "true"
    }
}

users.json

{
    "fileLocations": [
        {
            "URIs": [
                "s3://<バケット名>/mst/users.csv"
            ]
        }
    ],
    "globalUploadSettings": {
        "format": "CSV",
        "delimiter": ",",
        "containsHeader": "true"
    }
}

https://docs.aws.amazon.com/ja_jp/quicksuite/latest/userguide/supported-manifest-file-format.htmldocs.aws.amazon.com

これらのファイルをS3に配置した後、Quick Suiteのデータセット→データソース→データソースを作成→Amazon S3から登録すればデータソースの準備は完了です。

データセットで加工処理を定義する

実際に新しいデータセットで加工処理を作成してみましょう。

Quick Suiteのデータセット→データセットを作成からデータソースとして先ほど作成したaccess_logsを指定した後、データの編集/プレビューからデータセットの画面に移動します（S3データソースはSPICEの利用が前提なので、SPICEの購入が必要）。

現在は新旧UIが併存している状態なので、旧UIで表示される場合は右上の新しいエクスペリエンスに切り替えるから新しいデータセットに切り替えてください。。

詳細な操作方法は割愛しますが、以下のように加工処理を定義しました。

左側のブレードのデータを追加から、最初に選択したデータソース以外にも、別のデータソースやデータセットを追加することができます。S3をデータソースにする場合、デフォルトで全てのカラムが文字列にキャストされるので明示的に型変換が必要になる点にも注意しましょう。

分析とダッシュボードで可視化する

分析でグラフを定義すると、問題なく加工後のデータセットを表示することができました。

2026-01-01~2026-01-03まで3日分のデータが表示できていますね！

データを増量して更新する

S3に以下のデータを追加します。mst/users.csvについては増分に合わせて上書きで更新します。

trx/access_logs/year=2026/month=01/day=04/access_logs.csv
mst/users.csv

アップロード後、データセットの設定画面に移動して今すぐ更新をクリックしてSPICEの更新をトリガーします。更新はスケジュールして定時実行することも可能です。

SPICEの更新完了後、再びダッシュボードを見ると2026-01-04のデータが反映されていることがわかりますね。

CSVファイルの連携について

CSVファイルは手動でアップロードすることを前提としていましたが、連携方法についても整理しておきたいと思います。

基本的にはS3に成形されたCSVファイルを配置するのみですので、バッチ処理で自動連携するような処理方法も可能です。

方法 プル/プッシュ ユースケース
SFTP(AWS Transfer Family使用)で転送 プッシュ 既存のSFTPサーバを使用できる場合
AWS CLIで転送 プッシュ 対象システムが少数の場合
JDBCドライバやSCPでシステムから直接ファイルを取得 プル システムに直接取得が必要な場合

制約

SPICE利用量に注意

本構成ではSPICE領域にDWHに相当するデータを保存することを前提としているため、SPICEの利用量は必然的に大きくなります。

SPICEの容量はデータセットで最終的に出力されるテーブルの容量に基づき課金されるため、不要な列をカットしたりグルーピングして出力量を少量にすればSPICEの消費量も少なくすることができます。

容量については必ずしもファイルの容量と同一とならず、以下に記載の計算式でSPICEの消費量が計算されるので注意しましょう。

https://docs.aws.amazon.com/ja_jp/quicksuite/latest/userguide/spice.html#spice-capacity-formuladocs.aws.amazon.com

パーティショニングと処理単位がデータセットに依存する

例えば今回の構成で使用したアクセスログのようなトランザクションデータを日次で取り込む場合、加工処理は都度マニフェストファイルに合致するファイルの数だけ全量行われるため、データの増量に比例して処理時間とSPICEの使用量は大きくなります。

マニフェストファイルを定期的に更新して取り込み範囲を制御するなど運用上の考慮が必用です。

SQLと比較するとGUIの自由度はまだ低め

ローコード系の宿命で、直接SQLを書く場合と比較して自由度の面では制約を受けます。S3をデータソースにする場合カスタムSQLは使用できないので、SQLで加工処理を実装する必要がある場合はAthenaやRedshiftを使う必要性が出てきます。

たとえば結合だと結合条件はANDのみでORは不可、CROSS JOINができない、CASEやCOALESCEなど組み込み関数に相当する操作が提供されていないなどです。

データセットの機能から逆算してユースケースを満たせるか、満たせないなら受容できるかの判断が必要です。

クォータについて

抵触することは少ないと思われますが、データセット自体の制約、特にSPICEのサイズ制限が存在することには注意しましょう。

Standard Edition の場合、データセットごとに 2,500 万 (25,000,000) 行、または 25 GB

Enterprise エディションの場合、データセットごとに 10 億 (1,000,000,000) 行、または 1 TB

https://docs.aws.amazon.com/ja_jp/quicksuite/latest/userguide/data-source-limits.htmldocs.aws.amazon.com

https://docs.aws.amazon.com/ja_jp/quicksuite/latest/userguide/data-preparation-limits.htmldocs.aws.amazon.com

まとめ: こんな用途におすすめ

S3とQuick SuiteだけでDWH（のようなもの）が作れる時代になりました。

汎用性とのトレードオフですが、小規模な利用であれば本構成でも十分になるケースがあるように思います。

向いている用途

  • 扱うデータが比較的少量かつ固定的（定期作成するレポートなど）
  • 用途特化型の分析基盤
  • BIを主眼に置いたPoC目的

佐藤 航太郎(執筆記事の一覧)

エンタープライズクラウド部 クラウドモダナイズ課
最近はデータエンジニアのようなことをしています。

クラウド活用の「ちょっとした不安」や
「もっと良くしたい」に応えます
サーバーワークスは、AWSの構築から運用まで
幅広く支援しています
資料ダウンロード相談する

佐藤 航太郎