検出warehouseのセットアップ
プレビュー
Lakewatchは プライベート プレビュー段階です。アクセスをリクエストするには、Databricksアカウントチームにお問い合わせください。
スケジュール設定された検出は、提供されたSQLウェアハウスでランされます。Lakewatchは、このwarehouseを作成または管理しません。代わりに、ワークスペースでウェアハウスを作成し、スケジュールされた検出を作成するときにそのウェアハウスを選択します。warehouseの作成とサイズ設定には通常、ワークスペース管理者権限が必要であるため、これは通常、管理者セットアップタスクです。
このページでは、検出warehouseの開始構成を推奨します。ワークスペース内のすべてのスケジュールされた検出で単一のwarehouseを共有できます。
前提条件
検出warehouseは、Databricks SQL 2026.35以上でランする必要があります。Lakewatchは、Warehouseのチャンネル設定ではなく、Warehouseが実行しているバージョンを確認します。DatabricksがWarehouseを特定のDatabricks SQLバージョンにピン留めしている場合、そのピン留めされたバージョンもこの最小要件を満たす必要があります。
warehouseが実行しているバージョンを確認するには、そのwarehouseで以下のクエリーを実行します。
SELECT current_version().dbsql_version;
current_version関数を参照してください。
サポートされていないwarehouseエラー
Lakewatchがバージョンをチェックする時
Lakewatchは、これらのポイントでwarehouseのバージョンを検証します：
- ルールを作成するとき ：ルールにサポートされていないwarehouseがある場合、Lakewatchはそのルールを拒否します。
- ルールのSQLウェアハウスまたは実行プリンシパルを変更するとき ：warehouseがサポートされていない場合、Lakewatchはその変更を拒否します。
- Lakewatchが既存のルールを再検証するとき : 既存のルールのwarehouseがサポートされていない場合、Lakewatchはルールの実行を停止し、そのルールに対してシステムイベントを記録します。
Lakewatchがwarehouseが実行しているバージョンを決定できない場合、Lakewatchはそのwarehouseをサポートされていないと見なします。
サポートされているWarehouseを使用してください
Lakewatchがバージョンを理由にwarehouseを拒否した場合、エラーメッセージは次のいずれかで始まります。
SQL warehouse '<name>' (<id>) is running a version that Lakewatch does not support.Lakewatch could not verify that SQL warehouse '<name>' (<id>) is supported.
復旧するには：
- 最小バージョンを満たすSQLウェアハウスを選択するか、Databricksサポートにお問い合わせの上、warehouseの更新を行ってください。
- ルールの作成または更新を再試行してください。
既存のルールを別のサポートされているwarehouseに切り替えると、Lakewatchはすぐにルールを再検証します。ルールの現在のwarehouseがサポートされているバージョンに代わりに更新された場合、Lakewatchは次回の再検証時にルールの実行を再開します。
別のエラーは、Lakewatchがバージョンチェックを全く実行できなかったことを意味します：
Lakewatch could not validate the SQL warehouse runtime. Check warehouse availability and the rule's run-as permissions, then retry.
その場合は、Warehouseが使用可能であり、ルールの実行元プリンシパルがそれを使用できることを確認してから再試行してください。
推奨構成
ほとんどのワークスペースでは、スケジュールされたすべての検出で共有される1つのServerless SQL Warehouseから起動します。
設定 | 推奨値 |
|---|---|
Type | サーバーレス |
サイズ | 2X-Small |
クラスター (最小) | 1 |
クラスター (最大) |
|
自動停止 | 10 分 |
2X-Small warehouseは、100以上の単純な検出をランできます。SQL Warehouseはクエリーごとではなくクラスターの稼働時間に基づいて課金されるため、複数のルールでwarehouseを共有するほど、ルールあたりのコストは低くなります。
1つまたは2つのルールしか実行しないwarehouseは、Serverlessコンピュートと同じか、あるいはそれ以上のコストがかかる可能性があります。コスト上の利点は、多くの検出にわたって1つのwarehouseを共有することから得られます。
調整のタイミング
ワークロードに基づいてdefaultを変更する：
- 多く、高い、またはバースト的なルール : クエリーがキューに入らないように、最大クラスター数を増やします。クラスターの追加（スケールアウト）は、コンカレンシーの主なレバーです。各クラスターには約10個のクエリースロットがあります。
- レイテンシクリティカルな検出 ：コールド起動を回避するためにウォームフロア（最低2つ以上のクラスター）または長めの自動停止を設定しますが、コストは高くなります。
- 少数の、低頻度の、またはコストに敏感なルール : アイドル時間を短縮するため、自動停止を最小値である5分に短縮します。コールドwarehouseは、約5秒で再起動します。
- 重いクエリーまたは複雑なクエリー (大規模なスキャンまたは結合): warehouseのサイズを拡大します (小、中、またはそれ以上)。個々のクエリーでより多くのメモリまたはコンピュートが必要な場合にのみ、より大きなサイズを使用します（スケールアップ）。
コスト帰属
検出コストを個別に追跡するには、他のクエリー処理と共有せず、検出ワークロード専用のwarehouseを使用します。課金はクラスターの稼働時間に基づくため、専用のwarehouseを使用すると、検出にかかるコストを簡単に割り当てられます。
次のステップ
- 検出ルールの作成と管理: スケジュールされた検出を作成するときにこのwarehouseを選択します。