2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Snowflakeを使ったデータパイプライン構築、最初につまずいたポイントまとめ

2
Posted at

はじめに

データエンジニアとして日々Snowflakeと向き合っています。

Snowflakeは非常に強力なクラウドデータウェアハウスですが、使い始めの頃は「なぜかクエリが遅い」「コストが想定より高い」「設計をどう考えればいいかわからない」といった壁にぶつかりました。

この記事では、Snowflakeを触り始めた頃に自分がハマったポイントを実例とともに紹介します。同じ境遇の方の参考になれば嬉しいです。


1. Warehouseのサイズ感覚がつかめない

最初は「とりあえずSmallで動かせばいいか」と思っていましたが、これが落とし穴でした。

Snowflakeのコンピューティングリソースは Virtual Warehouse で制御され、サイズによって処理能力とコストが変わります。

サイズ クレジット/時間
X-Small 1
Small 2
Medium 4
Large 8

やらかし例:
バッチ処理をSmallで回していたら何時間もかかり、結果的にLargeで30分で終わらせるより高くついた。

教訓:

  • 開発・テスト環境はX-Smallで十分
  • 本番バッチはサイズを上げて処理時間を短縮する方がコスト効率が良いことも
  • AUTO_SUSPENDを短め(60〜120秒)に設定して無駄な起動時間を減らす
-- Warehouseの設定例
ALTER WAREHOUSE my_warehouse SET
  AUTO_SUSPEND = 60
  AUTO_RESUME = TRUE;

2. クラスタリングキーの設定を後回しにしていた

データ量が増えてきたとき、クエリが急に遅くなりました。原因は テーブルのクラスタリングを考慮していなかったこと。

Snowflakeはデータを マイクロパーティション という単位で管理しており、クラスタリングキーを設定することで不要なパーティションのスキャンを省略できます。

よくある失敗:

-- WHERE句でよく使うカラムにクラスタリングがない
SELECT * FROM events
WHERE event_date = '2024-01-01'
  AND user_id = 12345;

改善:

-- event_dateでクラスタリングを設定
ALTER TABLE events CLUSTER BY (event_date);

クラスタリングが効いているか確認するには SYSTEM$CLUSTERING_INFORMATION が便利です。

SELECT SYSTEM$CLUSTERING_INFORMATION('events', '(event_date)');

3. COPY INTOのエラーハンドリングを知らなかった

S3などからデータをロードする際に使う COPY INTO 。最初はエラーが出るたびに原因がわからず困りました。

デフォルトでは1件でもエラーがあるとロード全体が失敗します。

-- エラーがあっても続行し、エラー行をスキップ
COPY INTO my_table
FROM @my_stage/data.csv
FILE_FORMAT = (TYPE = CSV)
ON_ERROR = 'CONTINUE';

エラーの詳細は VALIDATE 関数で確認できます:

-- 直前のCOPY INTO結果を検証
SELECT * FROM TABLE(VALIDATE(my_table, JOB_ID => '_last'));

4. TIME TRAVELは意外と便利

「あ、間違えてUPDATEした!」というとき、Snowflakeの Time Travel に何度助けられたかわかりません。

デフォルトで最大90日前のデータを参照・復元できます。

-- 1時間前の状態を参照
SELECT * FROM my_table AT (OFFSET => -3600);

-- 特定タイムスタンプの状態を参照
SELECT * FROM my_table AT (TIMESTAMP => '2024-06-01 10:00:00'::TIMESTAMP);

-- テーブルをある時点の状態に復元
CREATE TABLE my_table_restored CLONE my_table
  AT (OFFSET => -3600);

ただしTime Travelの保持期間を長くするとストレージコストが増えるので、テーブルの重要度に応じて設定するのがベターです。


まとめ

ポイント 対策
Warehouseサイズ 用途に合わせてサイズを選び、AUTO_SUSPENDを活用
クラスタリング WHERE句でよく使うカラムに設定
COPY INTOエラー ON_ERROR設定とVALIDATEで原因を特定
データ復元 Time Travelを使いこなす

Snowflakeはドキュメントが充実しているので、公式ドキュメントも積極的に読むことをおすすめします。

今後も業務で得た知見を少しずつ発信していきます。よろしくお願いします!

2
1
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
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?