Présentation des flux¶

Stockage de décalage¶

Une fois créé, un flux prend logiquement un instantané initial de chaque ligne de l’objet source (par exemple, une table, une table externe ou les tables sous-jacentes d’une vue) en initialisant un point dans le temps (appelé décalage) en tant que version transactionnelle actuelle de l’objet. Le système de suivi des modifications utilisé par le flux enregistre ensuite les informations relatives aux modifications DML après la prise de cet instantané. Les enregistrements de modifications fournissent l’état d’une ligne avant et après la modification. Les informations de modification reflètent la structure de colonne de l’objet source suivi et incluent des colonnes de métadonnées supplémentaires décrivant chaque événement de modification.

Notez que le flux lui-même ne contient aucune donnée de table. Un flux stocke uniquement un décalage de l’objet source et renvoie des enregistrements CDC en exploitant l’historique de gestion des versions de l’objet source. Lorsque le premier flux d’une table est créé, plusieurs colonnes masquées sont ajoutées à la table source et commencent à stocker les métadonnées de traçage des modifications. Ces colonnes consomment une petite quantité de stockage. Les enregistrements CDC renvoyés lors de l’interrogation d’un flux reposent sur une combinaison du décalage stocké dans le flux et des métadonnées de suivi des modifications stockées dans la table. Notez que pour Streams on Views, le suivi des modifications doit être activé explicitement pour la vue et les tables sous-jacentes afin d’ajouter les colonnes cachées à ces tables.

Il peut être utile de considérer un flux comme un signet, indiquant un moment précis dans les pages d’un livre (c’est-à-dire l’objet source). Un signet peut être jeté et d’autres signets insérés à différents endroits dans un livre. De même, un flux peut être détruit et d’autres flux créés au même moment ou à des moments différents (soit en créant les flux consécutivement à des moments différents, soit en utilisant Time Travel) pour consommer les enregistrements de modification d’un objet à des décalages identiques ou différents.

Un exemple de consommateur d’enregistrements CDC est un pipeline de données dans lequel seules les données des tables de transfert qui ont été modifiées depuis la dernière extraction sont transformées et copiées dans d’autres tables.

Table et gestion de versions¶

Une nouvelle version de la table est créée chaque fois qu’une transaction qui comprend une ou plusieurs instructions DML est validée dans la table. Cela s’applique aux types de tables suivants :

• Tables standards

• Tables de répertoire

• Tables externes

• Tables sous-jacentes d’une vue

Dans l’historique des transactions pour une table, un décalage de flux est situé entre deux versions de la table. L’interrogation d’un flux renvoie les changements causés par les transactions effectuées après le décalage et à l’heure actuelle ou avant.

L’exemple suivant montre une table source avec 10 versions validées dans la chronologie. Le décalage pour le flux s1 se situe actuellement entre les versions de table v3 et v4. Lorsque le flux est interrogé (ou consommé), les enregistrements renvoyés comprennent toutes les transactions entre la version de la table v4, la version immédiatement après le décalage du flux dans la chronologie de la table, et v10, la version la plus récente de la table validée dans la chronologie, elle comprise.

Un flux fournit l’ensemble minimal de changements entre son décalage actuel et la version actuelle de la table.

Plusieurs demandes peuvent consommer indépendamment les mêmes données de modification d’un flux sans modifier le décalage. Un flux avance le décalage uniquement lorsqu’il est utilisé dans une transaction DML. Ce comportement s’applique aussi bien aux transactions explicites qu’aux transactions autocommit (validation automatique). (Par défaut, lorsqu’une instructionDML est exécutée, une transaction de validation automatique est implicitement lancée et la transaction est validée à la fin de l’instruction. Ce comportement est contrôlé avec le paramètre AUTOCOMMIT.) L’interrogation d’un flux seul ne fait pas avancer son décalage, même dans le cadre d’une transaction explicite ; le contenu du flux doit être consommé dans une instruction DML.

Lorsqu’une instruction SQL interroge un flux dans une transaction explicite, le flux est interrogé au point d’avance du flux (c’est-à-dire l’horodatage) lorsque la transaction a commencé plutôt que lorsque l’instruction a été exécutée. Ce comportement concerne à la fois les instructions DML et CREATE TABLE … AS SELECT (CTAS) qui remplissent une nouvelle table avec des lignes d’un flux existant.

Une instruction DML qui sélectionne un flux utilise toutes les données de modification du flux tant que la transaction est validée. Pour vous assurer que plusieurs instructions ont accès aux mêmes enregistrements de modification dans le flux, entourez-les d’une instruction de transaction explicite (BEGIN .. COMMIT). Cela verrouille le flux. Les mises à jour DML de l’objet source dans les transactions parallèles sont suivies par le système de suivi des modifications mais ne mettent pas à jour le flux tant que l’instruction de transaction explicite n’est pas validée et que les données de modification existantes ne sont pas utilisées.

Isolement de lecture répétable¶

Les flux prennent en charge l’isolation de lecture répétable. En mode de lecture répétable, plusieurs instructions SQL d’une transaction voient le même jeu d’enregistrements dans un flux. Cela diffère du mode de lecture validée pris en charge pour les tables, dans lequel les instructions voient toutes les modifications apportées par les instructions précédentes exécutées dans la même transaction, même si ces modifications ne sont pas encore validées.

Les enregistrements delta renvoyés par les flux d’une transaction correspondent à la plage allant de la position actuelle du flux jusqu’à l’heure de début de la transaction. La position du flux avance à l’heure de début de la transaction si la transaction est validée ; sinon, elle reste à la même position.

Prenons l’exemple suivant :

Dans la transaction 1, toutes les requêtes pour diffuser s1 affichent le même jeu d’enregistrements. Les modifications DML apportées à la table t1 sont enregistrées dans le flux uniquement lorsque la transaction est validée.

Dans la transaction 2, les requêtes sur le flux affichent les modifications enregistrées dans la table dans la Transaction 1. Notez que si la Transaction 2 avait commencé avant que la Transaction 1 soit validée, les requêtes adressées au flux auraient renvoyé un instantané du flux de la position du flux au début de la Transaction 2 et n’afficheraient aucune modification validée par la Transaction 1.

Colonnes de flux¶

Un flux stocke un décalage pour l’objet source et non les colonnes ou les données réelles de la table. Lorsqu’il est interrogé, un flux accède aux données historiques et les renvoie sous la même forme que l’objet source (c’est-à-dire les mêmes noms de colonnes et le même ordre) avec les colonnes supplémentaires suivantes :

METADATA$ACTION

Indique l’opération DML (INSERT, DELETE) enregistrée.

METADATA$ISUPDATE

Indique si l’opération faisait partie d’une instruction UPDATE. Les mises à jour des lignes de l’objet source sont représentées par une paire d’enregistrements DELETE et INSERT dans le flux avec des valeurs de colonne de métadonnées METADATA$ISUPDATE définies sur TRUE.

Notez que les flux enregistrent les différences entre deux décalages. Si une ligne est ajoutée puis mise à jour dans le décalage actuel, la modification delta est une nouvelle ligne. La ligne METADATA$ISUPDATE enregistre une valeur FALSE.

METADATA$ROW_ID

Spécifie l” ID unique et immuable pour la ligne, qui peut être utilisé pour suivre les modifications apportées à des lignes spécifiques au fil du temps.

Snowflake offre les garanties suivantes en ce qui concerne METADATA$ROW_ID :

1. Le METADATA$ROW_ID dépend de l’objet source du flux.

   Par exemple, un flux stream1 sur la table table1 et un flux stream2 sur la table table1 produisent les mêmes METADATA$ROW_ID pour les mêmes lignes, mais un flux stream_view sur la vue view1 n’est pas garanti de produire les mêmes METADATA$ROW_ID que stream1, même si view est défini à l’aide de l’instruction CREATE VIEW view AS SELECT * FROM table1.

2. Un flux sur un objet source et un flux sur le clone de l’objet source produisent les mêmes METADATA$ROW_ID pour les lignes qui existent au moment du clonage.

3. Un flux sur un objet source et un flux sur la réplication de l’objet source produisent les mêmes METADATA$ROW_ID pour les lignes qui ont été répliquées.

Types de flux¶

Les types de flux suivants sont disponibles en fonction des métadonnées enregistrées par chacun :

Standard

Pris en charge pour les flux sur les tables, les tables de répertoire ou les vues. Un flux standard (c’est-à-dire delta) suit toutes les modifications DML apportées à l’objet source, y compris les insertions, les mises à jour et les suppressions (y compris les troncatures de tables). Ce type de flux effectue une jointure sur les lignes insérées et supprimées dans le jeu de modifications pour fournir le delta de niveau ligne. En tant qu’effet net, par exemple, une ligne qui est insérée puis supprimée entre deux points de temps transactionnels dans une table est supprimée dans le delta (c’est-à-dire qu’elle n’est pas renvoyée lorsque le flux est interrogé).

Note

Les flux standards ne peuvent pas récupérer les données de changement pour les données géospatiales. Nous recommandons de créer des flux d’ajout uniquement sur les objets qui contiennent des données géospatiales.

Ajouter uniquement

Pris en charge pour les flux sur les tables standards, les tables de répertoire ou les vues. Un flux d’ajout uniquement suit uniquement les insertions de lignes. Les opérations de mise à jour, de suppression et de troncature ne sont pas prises en compte par les flux d’ajout uniquement. Par exemple, si 10 lignes sont initialement insérées dans une table, puis 5 de ces lignes sont supprimées avant d’avancer le décalage pour un flux d’ajout uniquement, le flux n’enregistrera que les 10 lignes insérées.

Un flux d’ajout uniquement renvoie spécifiquement les lignes ajoutées, ce qui le rend nettement plus performant qu’un flux standard pour l’extraction, le chargement et la transformation (ELT), ainsi que des scénarios similaires reposant uniquement sur l’insertion de lignes. Par exemple, une table source peut être tronquée immédiatement après la consommation des lignes d’un flux d’ajout uniquement, et les suppressions d’enregistrement ne contribuent pas à la surcharge la prochaine fois que le flux est interrogé ou consommé.

La création d’un flux d’ajout uniquement dans un compte cible utilisant un objet secondaire comme source n’est pas prise en charge.

Insertion uniquement

Pris en charge pour les flux sur les tables externes uniquement. Un flux à insertion uniquement suit uniquement les insertions de lignes. Il n’enregistre pas les opérations de suppression qui suppriment des lignes d’un ensemble inséré (c’est-à-dire sans opération). Par exemple, entre deux décalages, si le fichier1 est supprimé de l’emplacement de stockage Cloud référencé par la table externe et que le fichier2 est ajouté, le flux renvoie les enregistrements pour les lignes du fichier2 uniquement. Contrairement au suivi des données CDC pour les tables standard, Snowflake ne peut pas accéder aux enregistrements historiques des fichiers stockés dans le Cloud.

Les fichiers remplacés ou ajoutés sont essentiellement traités en tant que nouveaux fichiers : l’ancienne version du fichier est supprimée du stockage Cloud, mais le flux à insertion uniquement n’enregistre pas l’opération de suppression. La nouvelle version du fichier est ajoutée au stockage Cloud et le flux à insertion uniquement enregistre les lignes comme des insertions. Le flux n’enregistre pas les différences entre les anciennes et les nouvelles versions du fichier. Notez que les ajouts peuvent ne pas déclencher l’actualisation automatique des métadonnées de la table externe, comme dans le cas de l’utilisation de Azure AppendBlobs.

Flux de données¶

Le diagramme suivant montre comment le contenu d’un flux standard change lorsque les lignes de la table source sont mises à jour. Chaque fois qu’une instruction DML consomme le contenu du flux, la position du flux avance pour suivre le prochain ensemble de modifications de la table DML (c’est-à-dire les modifications apportées à une version de table) :

Période de conservation des données et obsolescence¶

Un flux devient obsolète lorsque son décalage est en dehors de la période de conservation des données pour sa table source (ou les tables sous-jacentes d’une vue source). Lorsqu’un flux devient obsolète, les données historiques de la table source ne sont plus accessibles, y compris les enregistrements de modifications non utilisés. Pour suivre les nouveaux enregistrements de modification d’une table, recréez le flux (à l’aide de CREATE STREAM). Pour empêcher un flux de devenir périmé, consommez les enregistrements de flux dans une transaction pendant la période de conservation de la table. Pour plus d’informations sur la période de conservation des données, voir Comprendre et utiliser la fonction « Time Travel ».

Si la période de conservation des données pour une table est inférieure à 14 jours et qu’un flux n’a pas été consommé, Snowflake prolonge temporairement cette période pour éviter qu’elle ne devienne obsolète. La période est étendue au décalage du flux, jusqu’à un maximum de 14 jours par défaut, quelle que soit l” édition Snowflake de votre compte. Le nombre maximal de jours pendant lesquels Snowflake peut prolonger la période de conservation des données est déterminé par la valeur du paramètre MAX_DATA_EXTENSION_TIME_IN_DAYS. Lorsque le flux est consommé, la période de conservation étendue des données est réduite à la période par défaut de la table.

Le tableau suivant présente les valeurs des exemples DATA_RETENTION_TIME_IN_DAYS et MAX_DATA_EXTENSION_TIME_IN_DAYS et indique à quelle fréquence le contenu du flux doit être consommé pour éviter l’obsolescence :

Pour voir le statut d’obsolescence actuel d’un flux, exécutez la commande DESCRIBE STREAM ou SHOW STREAMS. L’horodatage de la colonne STALE_AFTER indique la date à laquelle il est prévu que le flux devienne obsolète (ou quand il est devenu obsolète, si l’horodatage est dans le passé). Il s’agit de la période de conservation étendue des données pour l’objet source. Cet horodatage est calculé en ajoutant le plus grand des paramètres DATA_RETENTION_TIME_IN_DAYS ou MAX_DATA_EXTENSION_TIME_IN_DAYS de l’objet source à l’horodatage actuel.

Consommer les données de changement pour un flux déplace l’horodatage STALE_AFTER vers l’avant. Notez que la lecture du flux peut se poursuivre pendant un certain temps après l’horodatage STALE_AFTER. Toutefois, le flux peut devenir obsolète à tout moment pendant cette période. La colonne STALE indique si le flux est actuellement censé être obsolète, bien que le flux puisse ne pas l’être encore.

Pour éviter qu’un flux ne devienne obsolète, nous vous recommandons vivement de consommer régulièrement ses données de modification avant son horodatage STALE_AFTER (c’est-à-dire pendant la période de conservation étendue des données de l’objet source).

Une fois que le timestamp STALE_AFTER est passé, le flux peut devenir obsolète à tout moment, même s’il n’y a pas d’enregistrements non consommés pour le flux. Notez que l’interrogation d’un flux peut renvoyer aucun enregistrement, même s’il existe des données de modification pour l’objet source. Par exemple, un flux d’ajout uniquement effectue le suivi uniquement des insertions de lignes, mais les activités de mise à jour et de suppression écrivent également les enregistrements de modification dans un objet source. Un exemple moins clair d’écriture de table qui ne produit pas de données de modification est le reclustering.

La consommation des données de modification pour un flux avance son décalage à la date actuelle, que les versions intermédiaires contiennent ou non des données de modification.

Plusieurs consommateurs de flux¶

Nous recommandons aux utilisateurs de créer un flux séparé pour chaque consommateur d’enregistrements de modification pour un objet. Le terme « consommateur » désigne une tâche, un script ou un autre mécanisme qui consomme les enregistrements de modifications pour un objet en utilisant une transaction DML. Comme indiqué précédemment dans cette rubrique, un flux avance son décalage lorsqu’il est utilisé dans une transaction DML. Les différents consommateurs de données de changement dans un même flux récupèrent différents deltas, sauf si Time Travel est utilisé. Lorsque les données de changement saisies à partir du dernier décalage dans un flux sont consommées en utilisant une transaction DML, le flux avance le décalage. Les données de modification ne sont plus disponibles pour le prochain consommateur. Pour consommer les mêmes données de modification pour un objet, créez plusieurs flux pour l’objet. Un flux ne stocke qu’un décalage pour l’objet source et aucune donnée réelle de colonne de table ; vous pouvez donc créer un nombre quelconque de flux pour un objet sans encourir de coûts importants.

Streams on Views¶

Streams on Views prend en charge à la fois les vues locales et les vues partagées à l’aide de Snowflake Secure Data Sharing, y compris les vues sécurisées. Notez que, pour le moment, les flux ne peuvent pas suivre les modifications dans les vues matérialisées.

Les flux sont limités aux vues qui satisfont aux exigences suivantes :

Tables sous-jacentes

• Toutes les tables sous-jacentes doivent être des tables natives.

• La vue ne peut appliquer que les opérations suivantes :

  • Projections

  • Filters

  • Jointures intérieures ou transversales

  • UNION ALL

Les vues imbriquées et les sous-requêtes dans la clause FROM sont prises en charge à condition que la requête entièrement développée satisfasse aux autres exigences de cette table des exigences.

Voir la requête

Exigences générales :

• La requête peut sélectionner un nombre quelconque de colonnes.

• La requête peut contenir un nombre quelconque de prédicats WHERE.

• Les vues avec les opérations suivantes ne sont pas encore prises en charge :

  • Clauses GROUP BY

  • Clauses QUALIFY

  • Sous-requêtes ne figurant pas dans la clause FROM

  • Sous-requêtes non corrélées

  • Clauses LIMIT

Fonctions :

• Les fonctions de la liste de sélection doivent être des fonctions scalaires définies par le système.

Suivi des modifications

Le suivi des modifications doit être activé dans les tables sous-jacentes.

Avant de créer un flux sur une vue, vous devez activer le suivi des modifications sur les tables sous-jacentes de la vue. Pour obtenir des instructions, voir Activation du suivi des modifications sur les vues et les tables sous-jacentes.

create or replace table orders (id int, order_name varchar);
create or replace table customers (id int, customer_name varchar);

create or replace view ordersByCustomer as select * from orders natural join customers;
insert into orders values (1, 'order1');
insert into customers values (1, 'customer1');

create or replace stream ordersByCustomerStream on view ordersBycustomer;

select * from ordersByCustomer;
+----+------------+---------------+
| ID | ORDER_NAME | CUSTOMER_NAME |
|----+------------+---------------|
|  1 | order1     | customer1     |
+----+------------+---------------+

select * exclude metadata$row_id from ordersByCustomerStream;
+----+------------+---------------+-----------------+-------------------+
| ID | ORDER_NAME | CUSTOMER_NAME | METADATA$ACTION | METADATA$ISUPDATE |
|----+------------+---------------+-----------------+-------------------|
+----+------------+---------------+-----------------+-------------------+

insert into orders values (1, 'order2');
select * from ordersByCustomer;
+----+------------+---------------+
| ID | ORDER_NAME | CUSTOMER_NAME |
|----+------------+---------------|
|  1 | order1     | customer1     |
|  1 | order2     | customer1     |
+----+------------+---------------+

select * exclude metadata$row_id from ordersByCustomerStream;
+----+------------+---------------+-----------------+-------------------+
| ID | ORDER_NAME | CUSTOMER_NAME | METADATA$ACTION | METADATA$ISUPDATE |
|----+------------+---------------+-----------------+-------------------|
|  1 | order2     | customer1     | INSERT          | False             |
+----+------------+---------------+-----------------+-------------------+

insert into customers values (1, 'customer2');
select * from ordersByCustomer;
+----+------------+---------------+
| ID | ORDER_NAME | CUSTOMER_NAME |
|----+------------+---------------|
|  1 | order1     | customer1     |
|  1 | order2     | customer1     |
|  1 | order1     | customer2     |
|  1 | order2     | customer2     |
+----+------------+---------------+

select * exclude metadata$row_id from ordersByCustomerStream;
+----+------------+---------------+-----------------+-------------------+
| ID | ORDER_NAME | CUSTOMER_NAME | METADATA$ACTION | METADATA$ISUPDATE |
|----+------------+---------------+-----------------+-------------------|
|  1 | order1     | customer2     | INSERT          | False             |
|  1 | order2     | customer1     | INSERT          | False             |
|  1 | order2     | customer2     | INSERT          | False             |
+----+------------+---------------+-----------------+-------------------+

Clause CHANGES : alternative en lecture seule aux flux¶

Comme alternative aux flux, Snowflake prend en charge l’interrogation des métadonnées de suivi des modifications pour les tables ou les vues à l’aide de la clause CHANGES pour les instructions SELECT. La clause CHANGES permet d’interroger les métadonnées de suivi des modifications entre deux points dans le temps sans avoir à créer un flux avec un décalage transactionnel explicite. L’utilisation de la clause CHANGES ne fait pas avancer le décalage (c’est-à-dire consommer des enregistrements). Plusieurs requêtes peuvent récupérer les métadonnées de suivi des modifications entre différents points de départ et points de terminaison transactionnels. Cette option nécessite de spécifier un point de départ transactionnel pour les métadonnées à l’aide d’une clause AT | BEFORE ; le point de terminaison de l’intervalle de suivi des modifications peut être défini à l’aide de la clause END facultative.

Un flux stocke la version transactionnelle actuelle d’une table et est la source appropriée d’enregistrements CDC dans la plupart des scénarios. Pour les scénarios peu fréquents qui nécessitent de gérer le décalage pendant des périodes arbitraires, la clause CHANGES est disponible pour votre usage.

Actuellement, les éléments suivants doivent correspondre avant que les métadonnées de suivi des modifications soient enregistrées :

Tables

Soit activer le suivi des modifications sur la table (en utilisant ALTER TABLE … CHANGE_TRACKING = TRUE), soit créer un flux sur la table (en utilisant CREATE STREAM).

Vues

Activez le suivi des modifications sur la vue et ses tables sous-jacentes. Pour obtenir des instructions, voir Activation du suivi des modifications sur les vues et les tables sous-jacentes.

L’activation du traçage des modifications ajoute une paire de colonnes masquées à la table et commence à stocker les métadonnées de traçage des modifications. Les valeurs de ces colonnes de données cachées CDC fournissent les données d’entrée des colonnes de métadonnées du flux. Les colonnes consomment une petite quantité de stockage.

Aucune métadonnée de suivi des modifications de l’objet n’est disponible pendant la période précédant la satisfaction de l’une de ces conditions.

Privilèges d’accès requis¶

L’interrogation d’un flux nécessite un rôle avec au minimum les autorisations de rôle suivantes :

Facturation des flux¶

Comme décrit dans Période de conservation des données et obsolescence (dans ce chapitre), lorsqu’un flux n’est pas consommé régulièrement, Snowflake prolonge temporairement la période de conservation des données pour la table source ou les tables sous-jacentes de la vue source. Si la période de conservation des données de la table est inférieure à 14 jours, alors en arrière-plan, elle est étendue à la valeur la plus petite liée au décalage transactionnel du flux ou à 14 jours (si la période de conservation des données pour la table est inférieure à 14 jours), quelle que soit l” édition Snowflake de votre compte.

L’étendue de la période de conservation des données nécessite un stockage supplémentaire qui se reflétera dans vos frais de stockage mensuels.

Le coût principal associé à un flux est le temps de traitement utilisé par un entrepôt virtuel pour interroger le flux. Ces frais apparaissent sur votre facture en tant que crédits Snowflake familiers.