LoginSignup
18
6
お題は不問!Qiita Engineer Festa 2024で記事投稿!
Qiita Engineer Festa20242024年7月17日まで開催中!

Snowflakeのいろんな数値を集めてみた(デフォルト、最大、仕様、推奨値等)

Last updated at Posted at 2024-06-15

はじめに

Snowflakeで出てくる、様々な設定や仕様にまつわる「数値」をまとめてみました。

主にSnowflakeの認定試験(SnowPro CoreやAdvanced Architect)に向けて学習する過程で登場するものを中心に挙げてみました。

「この数値で何か制限あった気がするけど、何の制限だったっけ?」みたいなモヤモヤ、ありますよね?(自分は何度もありました...)
数値から見た、制限や仕様の逆引きみたいな感じです。

ここでは、1〜10にまつわるものをまとめてみました。

なお、0は特別なのか様々な意味を持ち合わせるので、ここでは省きました。
(設定する項目によって、数値の0という意味、無効という意味、最大という意味、無制限の意味、等)

1

  • 1分 (仕様)

  • 1時間 (60分,3600000ミリ秒) (デフォルト)

    • タスクがタイムアウトしたか、スケジュールウィンドウを超過した

      タスクの1回の実行には、60分のデフォルトの制限があります。この制限は、終了しないタスクに対する保護手段として実装されました。
      ...
      テートメントが記録を返さない場合、タスクには現在、デフォルトの 3600000 ミリ秒(60分)のタイムアウトがあります。

    • USER_TASK_TIMEOUT_MS

      タスクがタイムアウトするまでの1回の実行の制限時間(ミリ秒単位)を指定します。
      ...
      3600000 (1時間)

    • タスクはデフォルト1時間でタイムアウト、これは押さえておいた方がいい仕様

  • 1日 (デフォルト)

    • タイムトラベル(Time Travel)でよく出てくる日数

    • データ保持期間

      標準の保持期間は1日(24時間)であり、すべてのSnowflakeアカウントで自動的に有効になります。

    • DATA_RETENTION_TIME_IN_DAYS

      Snowflakeがオブジェクトに対してTime Travelアクション(SELECT、CLONE、UNDROP)を実行するための履歴データを保持する日数です。
      デフォルト 1

    • タイムトラベルはとりあえずデフォルトでは1日分遡れる、ということ

  • 1日 (最大)

    • USER_TASK_TIMEOUT_MS

      タスクがタイムアウトするまでの1回の実行の制限時間(ミリ秒単位)を指定します。
      ...
      0 - 86400000 (1日)

    • タスクのタイムアウトは最大1日、これも押さえておいた方がいい仕様

  • 1年 (仕様)

    • 定期的なキー更新

      定期的なキー更新が有効になっている場合、テーブルの廃止された暗号化キーが1年より古い場合、Snowflake は自動的に新しい暗号化キーを作成し、廃止されたキーによって以前に保護されていたすべてのデータを新しいキーを使用して再暗号化します。

    • PERIODIC_DATA_REKEYING

      このパラメーターは、 Enterprise Edition (またはそれ以上)にのみ適用されます。毎年、新しいキーを使用してテーブルデータの再暗号化を有効/無効にして、データ保護の追加レベルを提供します
      ...
      TRUE :データが最後に暗号化されてから1年が経過すると、データのキーが再生成されます。キー更新はバックグラウンドで行われるため、ダウンタイムは発生せず、影響を受けるデータ/テーブルは常に利用可能です。

    • Snowflakeが管理する暗号化キーの更新周期に関する数値(1年周期で更新)

    • Enterprise Edition以上で利用可能

    • デフォルトはFALSEなので、定期更新は行われない

    • 有効化するにはALTER ACCOUNT SET PERIODIC_DATA_REKEYING = TRUE;を実行

  • 1ステートメント (デフォルト)

2

  • 2日 (172800秒) (デフォルト)

    • STATEMENT_TIMEOUT_IN_SECONDS

      実行中の SQL ステートメント(クエリ、 DDL、 DMLなど)がシステムによってキャンセルされるまでの時間です(秒単位)。
      デフォルト 172800 (つまり、2日)

    • 何も設定しなければ、SQLの実行は2日後に強制キャンセルが掛かる

    • よく陥りがちなのが、タスクが実行するSQLはデフォルトではこれよりも早くタイムアウトしてしまうこと

  • 2人 (推奨値)

    • ユーザーに対する ACCOUNTADMIN ロール割り当ての制御

      ACCOUNTADMIN のロールをユーザーに割り当てる際には、次の点に注意することを強くお勧めします。

      • このロールは、組織内の選択された/限られた人数にのみ割り当ててください。
      • ACCOUNTADMIN ロールを割り当てられたすべてのユーザーは、ログインに多要素認証(MFA)を使用する必要もあります(詳細については、 アクセス制御の構成 をご参照ください)。
      • このロールを少なくとも2人のユーザーに割り当てます。
    • Snowflake1アカウント内に、ACCOUNTADMINが使用できるユーザーを少なくとも2人作っておくことが推奨されている

    • 実用的には「(1)原則使用しないユーザー(例えばログインできない無効なユーザーに割り当てておく」とか「(2)権限昇格によって一時的に特定のユーザーだけがACCOUNTADMINを使えるような仕組みを作っておく」とかで乗り切るのがいいかもしれない

  • 2〜3回 (仕様)

3

  • 3層 (仕様)
    • Snowflakeアーキテクチャ

      Snowflakeのユニークなアーキテクチャは、3つの重要なレイヤーで構成されています。

      • データベースストレージ
      • クエリ処理
      • クラウドサービス
    • 基礎にして超重要な概念

4

  • 4時間 (仕様,最大)
    • MFA トークンキャッシングを使用して認証中のプロンプトの数を最小限に抑える

      MFA トークンのキャッシュは、特に比較的短い時間間隔内に複数の接続が試行される場合に、Snowflake への接続と認証中に確認する必要があるプロンプトの数を減らすのに役立ちます。キャッシュされた MFA トークンは最大4時間有効です。

    • ここだけ4時間...これは忘れがちな数値かもしれない

    • 試験向けに意識しておいた方がいい数値かもしれない

5

  • 5GB (仕様,最大)

    • ステージ、パイプ、ロード履歴の複製 - 考慮事項

      内部ステージのディレクトリテーブルに5GBを超えるサイズのファイルがある場合、リフレッシュ操作は失敗します。この制限を回避するには、 5GBより大きなファイルを別のステージに移動します。

    • 単一ファイルへのアンロード

      Amazon S3、Google Cloud Storage、またはMicrosoft Azureステージの場合、サポートされる最大ファイルサイズは5GBです。

    • 1ファイルあたりの上限サイズとしてよく出てくる数値

    • 目にする機会も多いと思うので、比較的覚えやすいはず

  • 5分 (仕様)

    • ABORT_DETACHED_QUERY

      セッションの突然の終了(ネットワークの停止、ブラウザの終了、サービスの中断など)により接続が失われた場合に、進行中のクエリに対してSnowflakeが実行するアクションを指定します。
      ...
      TRUE : 接続が失われると、進行中のクエリは5分後に中止されます。

    • デフォルトはFALSE (=進行中のクエリは完了される) のため、あんまり気にしない数値かもしれない

    • 実務ではもしかしたら気にするケースがありそう

  • 5または10分以下 (推奨値)

    • ウェアハウスの停止の自動化

      自動中断を有効にする場合は、Snowflakeが1秒あたりの請求を使用するため、低い値(5または10分以下)に設定することをお勧めします。これは、使用されていないときにウェアハウスが稼働しないように(そしてクレジットを消費しないように)します。

    • ウェアハウスの自動停止時間を設定する時の推奨値

    • ウェアハウスを使っていない時の自動停止の設定なので、クエリ実行時間がこれよりも長くても勝手に停止されることはない

  • 5〜6回 (仕様)

    • マルチクラスターウェアハウスのスケーリングポリシーの設定
      • スケーリングポリシー - エコノミーにおいて、ウェアハウスを落とす条件

        5から6の連続した成功したチェック(1分間隔で実行)の後。これにより、クラスターを再起動せずに、最小負荷クラスターの負荷を他のクラスターに再分散できるかどうかが決定されます。

      • 「標準」と比べて連続で成功させないといけないチェック回数が多いので、シャットダウン条件が厳しい、緩やかにシャットダウンされるようなイメージ

      • スケーリングポリシー周りは押さえておくべき数値が多い...

6

  • 6分 (仕様)
    • マルチクラスターウェアハウスのスケーリングポリシーの設定
      • スケーリングポリシー - エコノミーにおいて、新しくウェアハウスが起動する条件

        システムが、クラスターを少なくとも6分間ビジー状態に保つのに十分なクエリ負荷があると推定する場合のみ。

      • これは6分間というキーワードは覚えられたとしても、標準 or エコノミーどっちだっけ?で迷うかもしれない

7

  • 7日 (604800秒) (最大)

    • STATEMENT_TIMEOUT_IN_SECONDS

      実行中の SQL ステートメント(クエリ、 DDL、 DMLなど)がシステムによってキャンセルされるまでの時間です(秒単位)。
      0 ~ 604800 (つまり、7日間)
      0 の値は、最大タイムアウト値が適用されることを指定します。

    • SQLは最大1週間実行し続けることができる、ということ

    • 相当巨大なデータか複雑なクエリか...いずれにしてもウェアハウスの利用料金が気になるところ

  • 7日 (仕様,最大)

    • Fail-safeで遡れる最大日数であり、固定値でもある(減らすことも増やすことも不可)

    • Fail-safeとは

      Fail-safeが提供する、Snowflakeによって履歴データを回復できる可能性のある期間(構成不可能)は7日間です。

    • ただしベストエフォート

    • 永続テーブルの量産で意図せずストレージコストが掛かるので、お試しテーブルはTAMPORARYとかTRANSIENTで作るようにした方がよい

8

  • 8分 (推奨値)

    • エンドポイント: loadHistoryScan

      重要
      このエンドポイントは、過剰な呼び出しを避けるためにレート制限されています。レート制限(エラーコード429)を超えないようにするため、 loadHistoryScan よりも insertReport に強く依存することをお勧めします。 loadHistoryScan を呼び出すとき、データロードのセットを含む最も狭い時間範囲を指定します。たとえば、履歴の最後の10分を8分ごとに読むとうまくいきます。

    • Snowpipe のloadHistoryScan エンドポイントを呼び出すときに従うべきベストプラクティス

    • 重要と書いてある通り、このエンドポイントを使うにあたっては重要な考慮点

    • 「重要」とあるだけに、資格試験でも問われそう

  • 8ステートメント(同時実行レベル) (デフォルト)

    • MAX_CONCURRENCY_LEVEL

      ウェアハウスによって実行される SQL ステートメント(つまり、クエリおよび DML)の並行性レベルを指定します。
      ...
      デフォルト 8

    • MAX_CONCURRENCY_LEVEL を下げる方法

      デフォルトの最大同時実行レベルは8です。レベルを下げるには、 ALTER WAREHOUSE コマンドを使用してより低い数値を指定します。

    • ウェアハウス1台あたり、デフォルトで8クエリ同時に捌けるということ

    • SQLがあるタイミングで大量に同時実行されるようなワークロードで効いてくる

    • マルチクラスターの最大化モードの話と合わせてとよく出てくる

9

特になさそうでした。

10

  • 10 (台,クラスター) (最大)

    • マルチクラスターウェアハウスとは

      Snowflakeは、マルチクラスターウェアハウスを使用して、静的または動的に追加のクラスターを割り当てて、より多くのコンピューティングリソースを利用できるようにします。マルチクラスターウェアハウスは、次のプロパティを指定することで定義されます。
      クラスターの最大数。1より大きい(最大10)。
      クラスターの最小数。最大値以下(最大10)。

    • マルチクラスターウェアハウスの設定で指定できる最大の数が10

  • 10分 (仕様,最大)

    • エンドポイント: insertReport

      このエンドポイントには次の制限があります。
      10、000の最新のイベントが保持されます。
      イベントは最大10分間保持されます。

    • Snowpipe insertReport エンドポイントの仕様上の最大分数

    • このエンドポイントを使う上では重要なポイント

  • 10分 (仕様)

    • コンシューマーのデータが欠落している、または同期されていない

      自動複製リストからのビューが表示されなくなったとコンシューマーから報告されました。
      ...
      オブジェクトが再作成された後、共有に再付与されなかった
      あるいは、オブジェクトが再付与されたが、10分未満しか経過していない。共有に付与されたオブジェクトの変更は10分ごとにチェックされるので、10分未満であれば、更新されたオブジェクトはまだコンシューマーのリージョンに自動複製されていません。

    • 複製における仕様として、10分毎の変更チェック〜反映という周期になる

    • 複製先に反映されていない時は10分待って再確認が必要

  • 10分 (仕様)

    • Snowflake OAuth の概要

      アクセストークンは短期間有効で、通常は10分です。アクセストークンの有効期限が切れると、クライアントは更新トークンを送信して新しいアクセストークンを取得できます。

    • 比較的短いので利用時は注意

  • 10% (仕様)

    • クラウドサービスの使用に対する請求について

      クラウドサービスの使用量は、クラウドサービスの日次消費量が仮想ウェアハウスの日次使用量の10%を超えた場合にのみ請求されます。料金は毎日計算されます(UTC タイムゾーン)。これにより、その日のクレジット価格で、毎日10%の調整が正確に適用されます。

    • コストに関する数値

    • コストを計算するにあたっては重要な考慮点

    • Snowflakeアカウント作成直後〜初期構築段階等、ウェアハウスをあまり稼働していない時に請求されがちなコスト

  • 10回 (デフォルト)

    • SUSPEND_TASK_AFTER_NUM_FAILURES

      タスク実行が連続して失敗した後、スタンドアロンタスクまたは タスクグラフ ルートタスクが自動的に中断した回数。失敗したタスク実行には、タスク本体の SQL コードがユーザーエラーを生成するかタイムアウトになった実行が含まれます。スキップ、キャンセル、またはシステムエラーが原因で失敗したタスク実行は不確定と見なされ、失敗したタスク実行の数には含まれません。
      ...
      パラメーターのデフォルト値は10に設定されています。これは、10回連続してタスクの実行に失敗すると、タスクが自動的に中断されることを意味します。

    • タスクがいつの間にか state : SUSPENDED になっているのは、大体これのせいと思われる(参考)

    • 実務向けの考慮点かもしれない

  • 10TB (仕様,最大)

    • データベースが10テラバイトを超えている

      エラー
      共有が10TBを超えるデータベースに関連付けられているため、自動複製は使用できません。
      データ製品が10TBを超えるデータベースに関連付けられているため、自動複製は使用できません。

    • 複製の制限(上限)として最大10TB/データベースが設定されている

    • サポートに連絡すれば上限緩和は可能とのこと

おわりに

こうやって並べてみると、色んな数値がありますね...

こういった数値に関してはとりあえず把握はするものの、どうやって決まるのか?あたりが気になったりしますね。
恒久的にこの数値なのか、改修やバージョンアップで見直されるのか、とかも。
資格試験で問われるような数値に関しては、ほぼ恒久的に決まっているのかなとも思ったりします。

まだまだ色んな数値が存在しますが、10よりも大きな数値に関しても別途まとめたいかなと思います。

以上です。

18
6
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
18
6