Optimaliser Lakehouse-tabeller basert på helsesjekker

Gjelder for:✅ SQL-analyseendepunkt i Microsoft Fabric

I denne veiledningen lærer du hvordan du bygger en Microsoft Fabric Pipeline for å utføre intelligent tabellvedlikehold.

Denne løsningen kaller T-SQL-lagret sys.sp_get_table_health_metrics prosedyre på Lakehouse SQL-analyseendepunktet, evaluerer resultatet, og kjører OPTIMIZE kun når tabellen faktisk trenger vedlikehold. Dette «sjekk-så-handle»-mønsteret forhindrer unødvendig beregningsbruk på friske tabeller, samtidig som det sikrer at degraderte tabeller vedlikeholdes automatisk.

Hvorfor vedlikehold er nødvendig

Lakehouse-tabeller kan samle opp for mange små Parquet-filer over tid, noe som går utover spørringsytelsen på SQL-analyse-endepunktet.

I stedet for å kjøre OPTIMIZE på en fast tidsplan uavhengig av tabellens tilstand, tar denne pipelinen en informert beslutning: den sjekker tabellens helse først, og utløser kun optimalisering når en anomali oppdages.

Forutsetninger

Før du begynner, må du kontrollere at du har:

Løsningsstruktur

Den ferdige rørledningen har denne strukturen:

  1. Skriptaktivitet: Kjører sp_get_table_health_metrics mot måltabellen og returnerer tabellhelsemetrikker som strukturert output.
  2. Hvis Condition-aktivitet: Leser PotentialAnomalyType direkte fra Script-utgangen og sjekker om den er større enn null. For mer informasjon om PotentialAnomalyType, se Potensielle anomalitypekoder.
  3. Notatbokaktivitet (inne i True-grenen ): Kjører OPTIMIZE på tabellen fra en Spark-notatbok.

På slutten av denne veiledningen vil du ha en notatbok som tar parametere fra pipelinen og optimaliserer en tabell når den utløses.

Trinn 1: Opprett optimaliseringsnotatboken

Notatboken godtar mål-Lakehouse-, skjema- og tabellnavnet som parametere fra pipelinen, og kjører OPTIMIZE deretter med Spark SQL.

  1. I Fabric-arbeidsområdet ditt, velg + Ny gjenstand>Notatbok.
  2. Kall notatboken Optimize-Table.
  3. Under Lokasjon, velg Lakehouse hvor bordene du sjekker er lagret. Denne øvelsen bruker et innsjøhus kalt SalesDataLakehouse.
  4. Velg Opprett.

Legg til parametercellen

Den første cellen definerer variablene som pipelinen overstyrer under kjøring.

  1. I den første cellen, skriv inn følgende parametere. Verdiene er ikke viktige, og pipelinen overstyrer dem under kjøring.

    # Parameters 
lakehouse_name = "<LakehouseName>"
schema_name    = "<SchemaName>"
table_name     = "<TableName>"

    Viktig!

    Slik fungerer parameterisering i Fabric-notebooks: Under kjøring injiserer Fabric en ny celle umiddelbart etter parametercellen som tildeler disse variablene med verdiene som sendes gjennom pipelinen. Verdiene du setter her initialiserer bare variablene og forbedrer lesbarheten.

  2. Velg cellemenyen (...) >Veksl parametercelle for å markere denne cellen som en parametercelle.

Legg til OPTIMALISEER-cellen

Kommandoen OPTIMIZE er en Spark SQL-kommando, ikke en T-SQL-kommando. Du må kjøre det i Spark-miljøer som notatbøker, Spark-jobbdefinisjoner eller Lakehouse Maintenance-grensesnittet. SQL analytics-endepunktet og Warehouse SQL-spørringseditoren støtter ikke denne kommandoen direkte.

  1. I den andre cellen, skriv inn:

    full_name = f"{lakehouse_name}.{schema_name}.{table_name}"
print(f"Optimizing {full_name} ...")

result = spark.sql(f"OPTIMIZE {full_name}")
result.show(truncate=False)

  2. Legg til Markdown-celler etter behov for å dokumentere notatboken riktig for andre brukere. Din ferdigstilte notatbok bør se omtrent slik ut:

    Skjermbilde av en Fabric-notatbok med tittelen 'Optimize a Lakehouse-tabell når helsesjekker viser at den er nødvendig,' med to PySpark-celler: den ene setter pipeline-leverte lakehouse-, skjema- og tabellparametere, og den andre kjører en OPTIMIZE-kommando for den valgte Lakehouse-tabellen.

Notat

Dette eksempelet vurderer et Lakehouse med skjemaer aktivert. Juster det tredelte navnet deretter full_name hvis du ikke bruker Lakehouse-skjemaer.

Steg 2: Opprett pipelinen

  1. I Fabric-arbeidsområdet ditt, velg + Ny vare-pipeline>.

  2. Kall pipelinen Check-and-Optimize-Table.

  3. Velg bakgrunnen til rørrøret, og åpne deretter fanen Parametere . Legg til tre parametere:

    Navn Type Standardverdi
    lakehouse_name Streng SalesDataLakehouse
    schema_name Streng dbo
    table_name Streng FactSales

Trinn 3: Legg til skriptaktiviteten

Script-aktiviteten kjører sys.sp_get_table_health_metrics på SQL-analyse-endepunktet og fanger opp resultatet.

Viktig!

Bruk Script-aktiviteten , ikke Stored procedure-aktiviteten . Kun skriptaktiviteten eksponerer resultatsettet som strukturert JSON-utdata som nedstrøms aktiviteter kan tolke.

  1. Fra fanen Aktiviteter , velg Script for å legge det til på lerretet.
  2. Kall det Sjekk Table Health.
  3. I fanen Innstillinger :

    • Tilkobling: Velg SQL-analyse-endepunktet for din Lakehouse. Hvis det ikke er oppført, velg Bla gjennom alle nederst i nedtrekkslisten, og finn deretter Lakehouses SQL-analyseendepunkt.

    • Skripttype: Velg Forespørsel.

    • Skript: Velg Legg til dynamisk innhold og skriv inn følgende uttrykk:

      @concat('EXEC sys.sp_get_table_health_metrics ''',
        pipeline().parameters.schema_name, '.',
        pipeline().parameters.table_name, '''')

Dette uttrykket produserer SQL-kommandoen som utfører den lagrede prosedyren mot måltabellen din, for eksempel: EXEC sys.sp_get_table_health_metrics 'dbo.FactSales'.

Verifiser skriptets utdata

Kjør pipelinen én gang og inspiser skriptaktivitetens output. Du ser et JSON-objekt som ligner på:

{
  "resultSetCount": 1,
  "resultSets": [
    {
      "rowCount": 1,
      "rows": [
        {
          "PotentialAnomalyType": 3,
          "PotentialAnomalyDescription": "Too many small files...",
          "FileCount": 2688,
          "...": "..."
        }
      ]
    }
  ]
}

Viktig!

Det faktiske resultatet kan variere avhengig av tilstanden på bordet ditt. Nøkkelen er at den returnerer kolonnene som eksponeres av sys.sp_get_table_health_metrics.

Trinn 4: Legg til Hvis-aktiviteten

If-betingelsesaktiviteten leser PotentialAnomalyType direkte fra Script-aktivitetens utgang og tar en beslutning basert på resultatet. Bruk følgende fremgangsmåte:

  1. Fra fanen Aktiviteter , velg Hvis betingelse for å legge til en aktivitet på lerretet.

  2. Gi det et navn, sjekk Anomali.

  3. Trekk en Suksess (grønn) pil fra Sjekk tabellens helse til Sjekk Anomali.

  4. I fanen Aktiviteter i Hvis-betingelsesaktiviteten , sett uttrykket til:

    @greater(int(activity('Check Table Health').output.resultSets[0].rows[0]['PotentialAnomalyType']), 0)

Dette uttrykket leser den første raden som returneres av sys.sp_get_table_health_metrics, kastes PotentialAnomalyType til et heltall, og evaluerer til true når verdien er større enn null, noe som indikerer en anomali oppdaget i måltabellen.

Trinn 5: Legg til notatbok-aktiviteten (Sann gren)

Med aktiviteten Hvis betingelse valgt, velg Rediger (blyantikon) ved siden av Sann. Lerretet bytter til et underlerret som er begrenset til True-grenen .

  1. Dra en notatblokkaktivitet over på True-underlerretet.

  2. Kall det Run OPTIMIZE.

  3. I Innstillinger-fanen:

    • Notatbok: Velg notatboken Optimaliser-tabell du opprettet i steg 1.

    • Utvid basisparametrene, og legg deretter til tre rader:

      Navn Type Verdi
      lakehouse_name Streng @pipeline().parameters.lakehouse_name
      schema_name Streng @pipeline().parameters.schema_name
      table_name Streng @pipeline().parameters.table_name

De tre navnekolonneverdiene må samsvare nøyaktig med variabelnavnene i notatbokens parametercelle.

Notat

Du kan la Falske aktiviteter stå tomme. If Condition-aktiviteten behandler en tom False-gren som en no-op og rapporterer pipelinen som fullført.

Din ferdige pipeline bør se slik ut:

Skjermbilde av en Fabric-datapipeline med en Check Table Health-skriptaktivitet koblet til en Check Anomaly-betinget aktivitet. Den ekte grenen kjører en OPTIMIZE notebook-aktivitet, mens den falske grenen ikke har noen aktiviteter.

Trinn 6: Valider og kjør

  1. Velg Valider på pipelineverktøylinjen for å sjekke etter konfigurasjonsfeil.

  2. Velg Kjør for å kjøre pipelinen manuelt.

  3. Følg med på løpet og bekreft:

    1. Sjekk tabellens helse: inspiser utdataene fra denne aktiviteten når den kjører. Du skal se utdataene fra den lagrede sys.sp_get_table_health_metrics prosedyren i JSON-format.
    2. Sjekk Anomalien: evalueres korrekt ved å lese PotentialAnomalyType direkte fra Script-utgangen.
    3. Kjør OPTIMIZE (kun hvis PotentialAnomalyType > 0): hvis Sjekk Anomali-aktiviteten evaluerer True, gjennomgå inputen fra aktiviteten Kjør OPTIMIZE for å verifisere at den bruker riktige parametere (Lakehouse-navn, skjema og tabellnavn) og sjekk utdataene for å gjennomgå meldingene fra operasjonen OPTIMIZE .

Fjerning av ressurser

Hvis du har opprettet ressurser kun for denne veiledningen og ikke lenger trenger dem, slett følgende elementer fra arbeidsområdet ditt:

  • Check-and-Optimize-table-pipelinen.
  • Optimize-Table-notatboken.

Relatert innhold

  • Last updated on