Aller au contenu principal
Dernière mise à jour le

Colonne de données sauvée Zerobus

info

Bêta

La colonne de secours est en bêta et prend actuellement en charge l’ingestion au format JSON. Les administrateurs de Workspace peuvent l’activer depuis la page Previews en optant pour l’aperçu Zerobus rescue column . Consultez Gérer les aperçus Databricks.

Par default, Zerobus Ingest dans Lakeflow Connect rejette tout enregistrement contenant des champs qui ne correspondent pas au schéma de la table cible. La fonctionnalité de colonne de données sauvée vous permet de capturer ces champs non conformes au lieu de les perdre. Les champs qui ne correspondent pas au schéma sont regroupés dans un objet JSON et stockés dans une colonne de données sauvée désignée sous forme de type VARIANT.

La colonne de secours prend actuellement en charge l’ingestion au format JSON. Si vous effectuez une ingestion avec Protocol Buffers (protobuf) ou Apache Arrow, planifiez votre schéma de manière à ce que les enregistrements correspondent à la table, car les champs non conformes sont rejetés plutôt que secourus.

La colonne de données sauvées est l'une des trois façons de définir le degré de rigueur avec lequel votre table valide les données entrantes. Pour une vue d'ensemble, consultez Trois façons de structurer le contrat.

Configurer une colonne de récupération​

Pour désigner une colonne comme colonne de récupération, la colonne doit :

  • Autorisez les valeurs nulles.
  • Utilisez le type VARIANT.
  • Le tag zerobus-rescue doit être appliqué dans Unity Catalog.

Une seule colonne doit remplir les trois critères. Zerobus gère les autres cas comme suit :

  • **Aucune colonne ne répond aux trois critères** : la fonctionnalité de colonne de données sauvée est inactive et Zerobus rejette les champs non conformes comme il le ferait sans cette fonctionnalité.
  • Plusieurs colonnes remplissent les trois critères : Zerobus en sélectionne une arbitrairement. Pour éviter toute ambiguïté, vérifiez qu'une seule colonne est éligible.

Les modifications apportées au balisage de colonne peuvent prendre jusqu'à 5 minutes pour prendre effet.

Lorsque Zerobus écrit dans la colonne de données sauvée​

Zerobus Ingest achemine chaque champ d'un enregistrement en fonction de sa correspondance avec le schéma de la table :

Champ dans l'enregistrement

Résultat

Correspond à une colonne de la table (nom et type)

Écrit normalement dans cette colonne.

Non présent dans le schéma de la table

Capturé dans la colonne de données sauvée.

Présent dans le schéma de table, mais le type de la valeur ne correspond pas et la colonne cible est nullable

Capturé dans la colonne de données sauvée.

Champ dans l'enregistrement

Résultat

Correspond à une colonne de la table (nom et type)

Écrit normalement dans cette colonne.

Non présent dans le schéma de la table

Capturé dans la colonne de données sauvée.

Présent dans le schéma de table, mais le type de la valeur ne correspond pas et la colonne cible est nullable

Capturé dans la colonne de données sauvée.

Seuls les champs non conformes sont dirigés vers la colonne des données sauvées. Les champs conformes au schéma sont toujours écrits dans leurs propres colonnes.

Exemple : incompatibilité de type et champ supplémentaire​

L'exemple suivant montre une non-concordance de type et un champ supplémentaire, tous deux acheminés vers la colonne rescue. Considérez une table avec le schéma suivant : rescue peut être nul, utilise le type VARIANT et a la balise zerobus-rescue appliquée dans Unity Catalog.

SQL
CREATE TABLE main.default.air_quality (
  device_name STRING NOT NULL,
  temp INT,
  humidity LONG,
  rescue VARIANT
);

Cet exemple ingère l'enregistrement JSON suivant :

JSON
{
  "device_name": "sensor-1",
  "temp": "72F",
  "humidity": 87,
  "extra_field": "some value"
}

L'enregistrement produit la ligne suivante dans la table Delta cible :

device_name

temp

humidity

rescue

sensor-1

null

87

{"extra_field": "some value", "temp": "72F"}

device_name

temp

humidity

rescue

sensor-1

null

87

{"extra_field": "some value", "temp": "72F"}

Résultat de chaque colonne :

  • device_name est écrit normalement car la valeur de la charge utile correspond au type STRING de la colonne.
  • temp est écrit en tant que null car la valeur de la charge utile ("72F", une chaîne) ne correspond pas au type INT de la colonne.
  • humidity est écrite normalement car la valeur de la charge utile correspond au type de la colonne.
  • extra_field n'est pas dans le schéma de la table, elle est donc écrite dans rescue au lieu d'être rejetée.

Zerobus regroupe les champs non conformes, temp et extra_field, dans l'objet JSON de la colonne rescue.

Limitations​

Les limitations suivantes s'appliquent lors de l'utilisation de la colonne de données sauvées :

  • La colonne de récupération est réservée, ce qui signifie que la charge utile de l'enregistrement ne peut pas lui fournir une valeur non nulle explicite. Si un enregistrement le fait, il est rejeté avec une erreur. Une valeur null pour la colonne de récupération est autorisée et est ignorée, tout comme tout champ absent ou null.
  • Un champ défini sur null dans la charge utile JSON est traité de la même manière qu'un champ absent et n'est pas écrit dans la colonne de récupération.
  • Si la charge utile contient plusieurs entrées pour la même clé, la dernière valeur l'emporte, conformément à la convention d'analyse JSON standard.

Connexes​

Sur cette page