refresh entièrement les tables cibles

S'applique à : connecteurs SaaS connecteurs de base de données connecteurs basés sur la query

L'actualisation complète du pipeline d'ingestion efface les données et l'état des tables cibles, puis retraite tous les enregistrements de la source de données. Vous pouvez refresh entièrement toutes les tables du pipeline ou sélectionner les tables à refresh.

Interface	Instructions
Interface utilisateur Lakehouse	Trigger manuellement une mise à jour du pipeline
API Pipelines	POST /api/2.0/pipelines/{pipeline_id}/updates
Databricks CLI	databricks pipelines start-update

Interface	Instructions
Interface utilisateur Lakehouse	Trigger manuellement une mise à jour du pipeline
API Pipelines	POST /api/2.0/pipelines/{pipeline_id}/updates
Databricks CLI	databricks pipelines start-update

important

La mise à jour du pipeline d'ingestion peut échouer pendant la phase Initializing ou Resetting tables. Lakeflow Connect relance automatiquement le pipeline plusieurs fois. Si vous interrompez les nouvelles tentatives automatiques ou si elles échouent finalement de manière fatale, start manuellement une nouvelle mise à jour du pipeline en utilisant la même sélection de refresh de table qu'auparavant. Sinon, les tables cibles peuvent se retrouver dans un état incohérent avec des données partielles. Si les tentatives manuelles échouent également, créez un ticket d'assistance.

Comportement de full refresh (CDC)

S’applique à : connecteurs SaaS connecteurs de base de données

Lorsque vous Trigger un full refresh d'une table, Databricks optimise le processus pour réduire les temps d'arrêt et maintenir la disponibilité des données :

1. Requête d'instantané : Lorsque vous demandez un refresh complet, la passerelle d'ingestion commence immédiatement à créer un nouvel instantané de la table source. La table de streaming de destination est exclue de la sélection de refresh jusqu'à ce que l'instantané soit terminé.
2. Disponibilité continue : Pendant le processus d'instantané, la table de streaming de destination conserve ses données existantes et reste disponible pour les queries. Aucune mise à jour, aucun ajout ou aucune suppression n'est appliqué à la table pendant que l'instantané est en cours.
3. Atomic refresh : une fois l'instantané terminé, Databricks effectue automatiquement le full refresh en une seule mise à jour. Cette mise à jour applique toutes les données d'instantané et tous les enregistrements CDC accumulés depuis la demande de l'instantané.

Par exemple, si votre table contient 50 enregistrements à la fin de la mise à jour 15 et que vous demandez un refresh complet dans la mise à jour 16 :

1. La passerelle d'ingestion commence à créer un instantané lors de la mise à jour 16.
2. La table continue d'afficher les 50 enregistrements originaux jusqu'à ce que l'instantané soit terminé.
3. Lorsque l'instantané est terminé (dans la mise à jour 16 ou ultérieure, en fonction de la taille de la table source), le refresh complet est automatiquement appliqué en une seule opération atomique.

Cette approche réduit considérablement les temps d'arrêt pendant les opérations de refresh complète et aide à prévenir les erreurs de PENDING_RESET et de délai d'attente.

important

Les instantanés de passerelle ne peuvent pas être repris. Si vous mettez à jour le pipeline pendant qu'un instantané est en cours (par exemple, en ajoutant de nouvelles tables), l'instantané actuel est annulé et un nouvel instantané start. Le nouvel instantané comprend l'union des tables de l'instantané annulé et toutes les tables nouvellement ajoutées. Pour éviter que l'instantané actuel ne soit annulé, attendez qu'il soit terminé avant de mettre à jour le pipeline.

Configurer le comportement de full refresh pour les connecteurs de base de données

S'applique à : connecteurs SaaS connecteurs de bases de données

Découvrez comment configurer le comportement de refresh complet pour les pipelines d'ingestion gérés avec des connecteurs de base de données (comme SQL Server) dans Lakeflow Connect. Vous pouvez planifier le moment où les captures d'écran de refresh complet se produisent et activer le refresh complet automatique pour récupérer des modifications de schéma non prises en charge.

Fenêtre de refresh complète

Une fenêtre de full refresh vous permet de planifier le moment où les Opérations d’instantané pour un full refresh se produisent. Lorsque vous demandez un full refresh ou que le système déclenche automatiquement un full refresh, l’instantané start pendant le prochain créneau disponible dans la fenêtre configurée. Le tableau suivant montre le fonctionnement de la planification :

Temps de requête	Fenêtre	start de l'instantané	Notes
lundi 20 octobre 2025 10 h 00 min 00 s UTC	start heure : 20, Jours : Mardi, Fuseau horaire : UTC	Mardi 2025-10-21 20:00:00 UTC	Instantanné différé au prochain jour de fenêtre disponible
Lundi 2025-10-20 9 h 30 min 00 s UTC	Start heure : 9, Jours : lundi, Fuseau horaire : UTC	Lundi 2025-10-20 9 h 30 min 00 s UTC	Même jour, heure de la requête dans la fenêtre
lundi 20 octobre 2025 10 h 00 min 00 s UTC	Start heure : 9, Jours : lundi, Fuseau horaire : UTC	Lundi 2025-10-27 09:00:00 UTC	Délai de demande dépassé, reporté à la semaine prochaine.

Temps de requête	Fenêtre	start de l'instantané	Notes
lundi 20 octobre 2025 10 h 00 min 00 s UTC	start heure : 20, Jours : Mardi, Fuseau horaire : UTC	Mardi 2025-10-21 20:00:00 UTC	Instantanné différé au prochain jour de fenêtre disponible
Lundi 2025-10-20 9 h 30 min 00 s UTC	Start heure : 9, Jours : lundi, Fuseau horaire : UTC	Lundi 2025-10-20 9 h 30 min 00 s UTC	Même jour, heure de la requête dans la fenêtre
lundi 20 octobre 2025 10 h 00 min 00 s UTC	Start heure : 9, Jours : lundi, Fuseau horaire : UTC	Lundi 2025-10-27 09:00:00 UTC	Délai de demande dépassé, reporté à la semaine prochaine.

Paramètres de configuration

Configurez la fenêtre de refresh complète dans la section ingestion_definition de votre pipeline spécification :

parameter	Type	Description	Obligatoire
start_hour	Entier	L'heure de start de la fenêtre (0-23) dans la journée de 24 heures.	Oui
days_of_week	Tableau	Jours où la fenêtre est active. Valeurs valides : MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY, SUNDAY. Si non spécifié, tous les jours sont utilisés.	Non
time_zone_id	Chaîne	ID du fuseau horaire pour la fenêtre. Consultez Définir le fuseau horaire de la session pour les ID de fuseau horaire pris en charge. Default sur UTC si non spécifié.	Non

parameter	Type	Description	Obligatoire
start_hour	Entier	L'heure de start de la fenêtre (0-23) dans la journée de 24 heures.	Oui
days_of_week	Tableau	Jours où la fenêtre est active. Valeurs valides : MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY, SUNDAY. Si non spécifié, tous les jours sont utilisés.	Non
time_zone_id	Chaîne	ID du fuseau horaire pour la fenêtre. Consultez Définir le fuseau horaire de la session pour les ID de fuseau horaire pris en charge. Default sur UTC si non spécifié.	Non

Exemple : configurez une fenêtre de refresh complète

Les exemples suivants montrent comment ajouter une fenêtre de refresh complète à la définition de votre pipeline.

Declarative Automation Bundles

YAML

resources:
  pipelines:
    gateway:
      name: <gateway-name>
      gateway_definition:
        connection_id: <connection-id>
        gateway_storage_catalog: <destination-catalog>
        gateway_storage_schema: <destination-schema>
        gateway_storage_name: <destination-schema>
      target: <destination-schema>
      catalog: <destination-catalog>

    pipeline_sqlserver:
      name: <pipeline-name>
      catalog: <destination-catalog>
      schema: <destination-schema>
      ingestion_definition:
        ingestion_gateway_id: <gateway-id>
        objects:
          - table:
              source_schema: <source-schema>
              source_table: <source-table>
              destination_catalog: <destination-catalog>
              destination_schema: <destination-schema>
        full_refresh_window:
          start_hour: 20
          days_of_week:
            - MONDAY
            - TUESDAY
          time_zone_id: 'America/Los_Angeles'

Databricks notebook

Python

gateway_pipeline_spec = {
  "pipeline_type": "INGESTION_GATEWAY",
  "name": "<gateway-name>",
  "catalog": "<destination-catalog>",
  "target": "<destination-schema>",
  "gateway_definition": {
    "connection_id": "<connection-id>",
    "gateway_storage_catalog": "<destination-catalog>",
    "gateway_storage_schema": "<destination-schema>",
    "gateway_storage_name": "<destination-schema>"
  }
}

ingestion_pipeline_spec = {
  "pipeline_type": "MANAGED_INGESTION",
  "name": "<pipeline-name>",
  "catalog": "<destination-catalog>",
  "schema": "<destination-schema>",
  "ingestion_definition": {
    "ingestion_gateway_id": "<gateway-pipeline-id>",
    "source_type": "SQLSERVER",
    "objects": [
      {
        "table": {
          "source_schema": "<source-schema>",
          "source_table": "<source-table>",
          "destination_catalog": "<destination-catalog>",
          "destination_schema": "<destination-schema>"
        }
      }
    ],
    "full_refresh_window": {
      "start_hour": 20,
      "days_of_week": ["MONDAY", "TUESDAY"],
      "time_zone_id": "America/Los_Angeles"
    }
  }
}

Politique de full refresh automatique

Pour aider à maintenir la cohérence des données sans intervention manuelle, une politique d'auto full refresh vous permet d'automatiquement Trigger un full refresh lorsque le pipeline rencontre des opérations DDL non prises en charge :

• Truncature de table
• Modifications de schéma incompatibles (par exemple, modifications du type de données)
• Renommage des colonnes
• Ajouts de colonnes avec des valeurs default

Sans le refresh complet automatique activé, vous devez manuellement Trigger un refresh complet lorsque ces Opérations se produisent.

Paramètres de configuration

Configurez l'auto full refresh au niveau du pipeline ou de la table dans votre spécification de pipeline :

parameter	Type	Description	Par défaut
enabled	Booléen	Si le refresh complet automatique est activé.	false
min_interval_hours	Entier	Intervalle d'attente minimum en heures entre les actualisations complètes. Le système attend pendant cet intervalle depuis le dernier instantané avant d'initier une nouvelle auto full refresh.	24

parameter	Type	Description	Par défaut
enabled	Booléen	Si le refresh complet automatique est activé.	false
min_interval_hours	Entier	Intervalle d'attente minimum en heures entre les actualisations complètes. Le système attend pendant cet intervalle depuis le dernier instantané avant d'initier une nouvelle auto full refresh.	24

Vous pouvez configurer le refresh complet automatique à plusieurs niveaux :

• Niveau de pipeline : Dans ingestion_definition.table_configuration.auto_full_refresh_policy
• Niveau de la table : dans ingestion_definition.objects[].table.table_configuration.auto_full_refresh_policy

La configuration au niveau de la table remplace la configuration au niveau du pipeline.

Exemple : configurez le full refresh automatique au niveau du pipeline.

Les exemples suivants montrent comment activer le refresh automatique complet pour toutes les tables d'un pipeline.

Declarative Automation Bundles

YAML

resources:
  pipelines:
    gateway:
      name: <gateway-name>
      gateway_definition:
        connection_id: <connection-id>
        gateway_storage_catalog: <destination-catalog>
        gateway_storage_schema: <destination-schema>
        gateway_storage_name: <destination-schema>
      target: <destination-schema>
      catalog: <destination-catalog>

    pipeline_sqlserver:
      name: <pipeline-name>
      catalog: <destination-catalog>
      schema: <destination-schema>
      ingestion_definition:
        ingestion_gateway_id: <gateway-id>
        objects:
          - table:
              source_schema: <source-schema>
              source_table: <source-table>
              destination_catalog: <destination-catalog>
              destination_schema: <destination-schema>
        table_configuration:
          auto_full_refresh_policy:
            enabled: true
            min_interval_hours: 24

Databricks notebook

Python

gateway_pipeline_spec = {
  "pipeline_type": "INGESTION_GATEWAY",
  "name": "<gateway-name>",
  "catalog": "<destination-catalog>",
  "target": "<destination-schema>",
  "gateway_definition": {
    "connection_id": "<connection-id>",
    "gateway_storage_catalog": "<destination-catalog>",
    "gateway_storage_schema": "<destination-schema>",
    "gateway_storage_name": "<destination-schema>"
  }
}

ingestion_pipeline_spec = {
  "pipeline_type": "MANAGED_INGESTION",
  "name": "<pipeline-name>",
  "catalog": "<destination-catalog>",
  "schema": "<destination-schema>",
  "ingestion_definition": {
    "ingestion_gateway_id": "<gateway-pipeline-id>",
    "source_type": "SQLSERVER",
    "objects": [
      {
        "table": {
          "source_schema": "<source-schema>",
          "source_table": "<source-table>",
          "destination_catalog": "<destination-catalog>",
          "destination_schema": "<destination-schema>"
        }
      }
    ],
    "table_configuration": {
      "auto_full_refresh_policy": {
        "enabled": True,
        "min_interval_hours": 24
      }
    }
  }
}

Exemple : Configurez l'auto full refresh par table.

Les exemples suivants montrent comment activer l'auto full refresh au niveau du pipeline mais la désactiver pour des tables spécifiques.

Declarative Automation Bundles

YAML

resources:
  pipelines:
    gateway:
      name: <gateway-name>
      gateway_definition:
        connection_id: <connection-id>
        gateway_storage_catalog: <destination-catalog>
        gateway_storage_schema: <destination-schema>
        gateway_storage_name: <destination-schema>
      target: <destination-schema>
      catalog: <destination-catalog>

    pipeline_sqlserver:
      name: <pipeline-name>
      catalog: <destination-catalog>
      schema: <destination-schema>
      ingestion_definition:
        ingestion_gateway_id: <gateway-id>
        objects:
          - table:
              source_schema: <source-schema>
              source_table: table_1
              destination_catalog: <destination-catalog>
              destination_schema: <destination-schema>
          - table:
              source_schema: <source-schema>
              source_table: table_2
              destination_catalog: <destination-catalog>
              destination_schema: <destination-schema>
              table_configuration:
                auto_full_refresh_policy:
                  enabled: false
                  min_interval_hours: 24
        table_configuration:
          auto_full_refresh_policy:
            enabled: true
            min_interval_hours: 24

Databricks notebook

Python

gateway_pipeline_spec = {
  "pipeline_type": "INGESTION_GATEWAY",
  "name": "<gateway-name>",
  "catalog": "<destination-catalog>",
  "target": "<destination-schema>",
  "gateway_definition": {
    "connection_id": "<connection-id>",
    "gateway_storage_catalog": "<destination-catalog>",
    "gateway_storage_schema": "<destination-schema>",
    "gateway_storage_name": "<destination-schema>"
  }
}

ingestion_pipeline_spec = {
  "pipeline_type": "MANAGED_INGESTION",
  "name": "<pipeline-name>",
  "catalog": "<destination-catalog>",
  "schema": "<destination-schema>",
  "ingestion_definition": {
    "ingestion_gateway_id": "<gateway-pipeline-id>",
    "source_type": "SQLSERVER",
    "objects": [
      {
        "table": {
          "source_schema": "<source-schema>",
          "source_table": "table_1",
          "destination_catalog": "<destination-catalog>",
          "destination_schema": "<destination-schema>"
        }
      },
      {
        "table": {
          "source_schema": "<source-schema>",
          "source_table": "table_2",
          "destination_catalog": "<destination-catalog>",
          "destination_schema": "<destination-schema>",
          "table_configuration": {
            "auto_full_refresh_policy": {
              "enabled": False,
              "min_interval_hours": 24
            }
          }
        }
      }
    ],
    "table_configuration": {
      "auto_full_refresh_policy": {
        "enabled": True,
        "min_interval_hours": 24
      }
    }
  }
}

Dans cet exemple, table_1 utilise la politique au niveau du pipeline (activée), tandis que table_2 la remplace par la configuration au niveau de la table (désactivée).