Configurer un entrepôt pour la détection

Important

Lakewatch est en aperçu privé. Pour demander l’accès, contactez votre équipe de comptes Azure Databricks.

Les détections programmées s’exécutent sur un entrepôt SQL que vous fournissez. Lakewatch ne crée ni ne gère cet entrepôt. À la place, vous la créez dans votre espace de travail et la sélectionnez lors de la création d’une détection programmée. Créer et dimensionner un warehouse nécessite généralement des autorisations d’administration de l’espace de travail, donc il s’agit généralement d’une tâche de configuration administrative.

Cette page recommande une configuration initiale pour un entrepôt de détection. Vous pouvez partager un même entrepôt entre toutes les détections planifiées d’un espace de travail.

Prerequisites

Un entrepôt de détection doit exécuter Databricks SQL 2026.35 et versions supérieures. Lakewatch vérifie la version utilisée par l’entrepôt, pas son réglage de canal. Si Databricks a épinglé votre SQL Warehouse à une version spécifique de Databricks SQL, la version épinglée doit également respecter ce minimum.

Pour vérifier la version utilisée par un entrepôt, lancez cette requête sur cet entrepôt :

SELECT current_version().dbsql_version;

Consultez Fonction current_version.

Erreurs d’entrepôt non prises en charge

Quand Lakewatch vérifie la version

Lakewatch valide la version de l’entrepôt à ces points :

  • Lorsque vous créez une règle : Lakewatch rejette la règle si son entrepôt n’est pas pris en charge.
  • Lorsque vous modifiez l’entrepôt SQL d’une règle ou l’identité d’exécution : Lakewatch rejette la modification si l’entrepôt n’est pas pris en charge.
  • Lorsque Lakewatch revalide les règles existantes : si l’entrepôt d’une règle existante n’est pas pris en charge, Lakewatch cesse d’exécuter la règle et enregistre un événement système pour celle-ci.

Si Lakewatch ne peut pas déterminer la version utilisée par un entrepôt de données, il considère l’entrepôt de données comme non pris en charge.

Utilisez un entrepôt pris en charge

Si Lakewatch rejette un warehouse à cause de sa version, le message d’erreur commence par l’un des suivants :

  • SQL warehouse '<name>' (<id>) is running a version that Lakewatch does not support.
  • Lakewatch could not verify that SQL warehouse '<name>' (<id>) is supported.

Pour récupérer :

  1. Sélectionnez un entrepôt SQL qui respecte la version minimale, ou contactez le support Databricks pour obtenir de l’aide afin de mettre à jour l’entrepôt.
  2. Réessayez la création ou la mise à jour de la règle.

Si vous changez une règle existante vers un autre entrepôt supporté, Lakewatch la révalide immédiatement. Si l’entrepôt actuel de la règle est mis à jour vers une version prise en charge à la place, Lakewatch reprend l’exécution de la règle la prochaine fois que Lakewatch effectue une nouvelle validation.

Une erreur différente signifie que Lakewatch n’a pas pu exécuter la vérification de version du tout :

  • Lakewatch could not validate the SQL warehouse runtime. Check warehouse availability and the rule's run-as permissions, then retry.

Dans ce cas, vérifiez que le warehouse est disponible et que le principal d’exécution de la règle peut l’utiliser, puis réessayez.

Pour la plupart des espaces de travail, commencez par un seul entrepôt SQL serverless partagé par toutes vos détections programmées :

Setting Valeur recommandée
Type Serverless
Size 2X-Petit
Clusters (min) 1
Clusters (max) ceil(peak concurrent rules / 10), jusqu’au maximum de 40 clusters
Arrêt automatique 10 minutes

Un entrepôt de taille 2X-Small peut exécuter au moins 100 détections simples. Parce qu’un entrepôt SQL est facturé par temps d’activité du cluster plutôt que par requête, plus il y a de règles qui partagent un entrepôt, plus le coût par règle est faible.

Note

Un entrepôt qui n’exécute qu’une ou deux règles peut coûter autant, voire plus, que le calcul serverless. L’avantage en termes de coût vient du partage d’un seul entrepôt entre de nombreux déploiements.

Quand ajuster

Changez les paramètres par défaut en fonction de votre charge de travail :

  • Règles nombreuses, en grand nombre ou en rafale : augmentez le nombre maximal de clusters pour éviter que les requêtes ne soient en file d’attente. L’ajout de clusters (mise à l’échelle horizontale) constitue le principal moyen d’augmenter la capacité d’exécution simultanée. Chaque cluster fournit environ 10 emplacements d’exécution de requêtes.
  • Détections nécessitant une faible latence : Définissez un nombre minimal de clusters maintenus actifs (au moins 2) ou un délai d’arrêt automatique plus long pour éviter les démarrages à froid, mais à un coût plus élevé.
  • Peu de règles, peu fréquentes ou sensibles au coût : Réduisez l’arrêt automatique à 5 minutes (le minimum) pour diminuer le temps d’inactivité. Un entrepôt arrêté redémarre en environ 5 secondes.
  • Requêtes lourdes ou complexes (analyses de grands volumes de données ou jointures) : Augmentez la taille de l’entrepôt (petit, moyen ou plus grand). Utilisez une taille plus grande (mise à l’échelle verticale) uniquement lorsqu’une requête individuelle nécessite plus de mémoire ou de calcul.

Attribution des coûts

Pour suivre le coût de détection de manière autonome, utilisez un entrepôt de données dédié pour les charges de travail de détection plutôt que de le partager avec d’autres activités de requête. Comme la facturation se fait par uptime du cluster, un entrepôt dédié rend facile d’attribuer le coût à la détection.

Étapes suivantes

  • Dernière mise à jour :