Detection Warehouse instellen

Important

Lakewatch staat in privépreview. Neem contact op met uw Azure Databricks-accountteam om toegang aan te vragen.

Geplande detecties draaien op een SQL-warehouse dat je beschikbaar stelt. Lakewatch creëert of beheert deze warehouse niet. In plaats daarvan maak je het aan in je werkruimte en selecteer je het wanneer je een geplande detectie maakt. Het aanmaken en dimensioneren van een warehouse vereist meestal adminrechten voor de werkruimte, dus dit is meestal een administratieve setuptaak.

Deze pagina raadt een startconfiguratie aan voor een detection warehouse. Je kunt één datawarehouse delen over alle geplande detecties in een werkruimte.

Prerequisites

Een detectiewarehouse moet Databricks SQL 2026.35 en hoger draaien. Lakewatch controleert de versie waarop de warehouse draait, niet de kanaalinstelling. Als Databricks je warehouse heeft vastgezet aan een specifieke Databricks SQL-versie, moet de vastgezette versie ook aan dit minimum voldoen.

Om te controleren welke versie een warehouse draait, voer je deze query uit op dat warehouse:

SELECT current_version().dbsql_version;

Zie current_version de functie.

Fouten voor niet-ondersteunde magazijnen

Wanneer Lakewatch de versie controleert

Lakewatch valideert de magazijnversie op deze punten:

  • Wanneer je een regel aanmaakt: Lakewatch wijst de regel af als het bijbehorende warehouse niet wordt ondersteund.
  • Wanneer je het SQL-warehouse of de run-as principal van een regel verandert: Lakewatch wijst de wijziging af als het warehouse niet wordt ondersteund.
  • Wanneer Lakewatch bestaande regels opnieuw valideert: Als het warehouse van een bestaande regel niet wordt ondersteund, stopt Lakewatch met het uitvoeren van de regel en registreert een systeemgebeurtenis voor deze regel.

Als Lakewatch niet kan bepalen welke versie een warehouse draait, behandelt het het warehouse als niet-ondersteund.

Gebruik een ondersteund magazijnsysteem

Als Lakewatch een warehouse afwijst vanwege zijn versie, begint het foutbericht met een van de volgende:

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

Ga als volgende te werk om te herstellen:

  1. Selecteer een SQL-warehouse dat aan de minimumversie voldoet, of neem contact op met Databricks Support voor hulp bij het updaten van het warehouse.
  2. Probeer opnieuw de regel aan te maken of te updaten.

Als je een bestaande regel overzet naar een ander ondersteund magazijn, valideert Lakewatch de regel meteen opnieuw. Als het huidige warehouse van de regel in plaats daarvan wordt bijgewerkt naar een ondersteunde versie, hervat Lakewatch de volgende keer dat het opnieuw wordt gevalideerd het uitvoeren van de regel.

Een andere fout betekent dat Lakewatch de versiecontrole helemaal niet kon uitvoeren:

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

Controleer in dit geval of het magazijn beschikbaar is en dat de run-as-principal van de regel het kan gebruiken, en probeer het dan opnieuw.

Voor de meeste werkruimtes begin je met één serverless SQL-warehouse dat gedeeld wordt door al je geplande detecties:

Configuratie Aanbevolen waarde
Type Serverless
Size 2X-klein
Clusters (min) 1
Clusters (max) ceil(peak concurrent rules / 10), tot het maximum van 40 clusters
Automatische stop 10 minuten

Een 2X-Small warehouse kan 100 of meer eenvoudige detecties uitvoeren. Omdat een SQL-warehouse wordt gefactureerd op basis van clusteruptime in plaats van per query, geldt: hoe meer regels een warehouse delen, hoe lager de kosten per regel.

Note

Een warehouse dat slechts één of twee regels draait, kan evenveel kosten als, of zelfs meer dan, serverless compute. Het kostenvoordeel komt voort uit het delen van één magazijn door meerdere detecties.

Wanneer aanpassen

Verander de standaardwaarden op basis van je werkdruk:

  • Veel, zware of piekbelaste regels: Verhoog het maximale aantal clusters zodat queries niet in de wachtrij komen. Het toevoegen van clusters (scaling out) is de belangrijkste hefboom voor concurrentie. Elk cluster biedt ongeveer 10 queryslots.
  • Latency-kritieke detecties: Stel een minimumcapaciteit in (minimaal 2 of meer clusters) of een langere automatische stop om koude starts te voorkomen, tegen hogere kosten.
  • Weinig, zelden gebruikte of kostengevoelige regels: Verlaag de automatische stop tot 5 minuten (het minimum) om inactieve tijd te verkorten. Een cold warehouse start in ongeveer 5 seconden opnieuw.
  • Zware of complexe queries (grote scans of joins): Vergroot de warehousegrootte (klein, middelgroot of groter). Gebruik een grotere grootte (opschalen) alleen wanneer een individuele query meer geheugen of rekenkracht nodig heeft.

Kostentoeschrijving

Om de detectiekosten afzonderlijk bij te houden, gebruik je een speciaal warehouse voor detectieworkloads in plaats van deze te delen met andere queryactiviteiten. Omdat facturering per cluster uptime plaatsvindt, maakt een dedicated warehouse het eenvoudig om kosten toe te schrijven aan detectie.

Volgende stappen 

  • Laatst bijgewerkt om