クラウド DWH

BigQuery・Snowflake・Redshift などのクラウド DWH は、保存（ストレージ）と計算（コンピュート）が分かれているのが特徴です。保存はオブジェクトストレージ並みに安く、計算は必要なときに必要なだけ使います。料金は製品によって考え方が違います。

大きなデータでの SQL の書き方

DWH の費用は、気づくと大きく増えていることがあります。調べるときは、ジョブの履歴（BigQuery の INFORMATION_SCHEMA.JOBS、Snowflake の ACCOUNT_USAGE のクエリ履歴など）から、読んだ量や実行時間の大きいものを順に並べます。

よく効く節約：

• SELECT * をやめ、実行前に読む量を確認する。
• 大きなテーブルは日付でパーティションを切り、よく絞る列でクラスタリングする。パーティションの条件を必須にしておく。
• 全件の作り直しをやめて増分処理にする。ダッシュボードが同じ重い集計を何度も流しているなら、集計テーブルやマテリアライズドビューにする。
• ユーザーやジョブごとに上限（1クエリの最大の読み込み量、予算のアラート）を設定する。
• 使われていないテーブル・古いパーティションに有効期限をつける。

パーティションを細かくしすぎる（1つあたりのデータがとても少ない）と、かえって管理の負担が増えます。日単位で小さすぎるなら月単位にし、その中をクラスタリングで絞るのが目安です。

費用を下げる工夫は、利用者の使い方を変えることも多いので、どのダッシュボード・どの人のクエリかまで特定して、持ち主と一緒に直します。

パーティションには製品ごとの数の上限があり、細かくしすぎると1つあたりのデータが小さくなって効率が落ちます。データが少ないテーブルは、日ではなく月で区切るか、区切らずにクラスタリングだけにします。BigQuery ではパーティションの条件を必須にする設定ができ、条件のない全件の読み込みを防げます。

多くのダッシュボードが、同じ大きなテーブルを毎回同じように集計していると、費用も待ち時間も無駄になります。集計の結果を保存して使い回します。

集計テーブルの粒度は、よく使う切り口の組み合わせに合わせます。率は分子と分母を別に持たせ、あとでまとめ直せるようにします（足せる指標・足せない指標）。

同じ DWH を、取り込み・夜間の変換・BI・アナリストの探索など、性格の違う使い方が同時に使います。1つの計算資源を共有すると、重いバッチの間はダッシュボードが待たされます。

同じ SQL でも、どのエンジンで動かすかは、データの大きさ・置き場所・使う人で選びます。

「大きいデータだから Spark」と決めつけず、DWH の SQL で済むならそれが一番運用が楽です。