Utiliser des données synthétiques dans Snowflake¶

Avantages¶

Cohérence statistique:

Un ensemble de données synthétiques représente les propriétés statistiques de l’ensemble de données original, ce qui aide les ingénieurs en données à comprendre les propriétés statistiques de l’ensemble de données réel. Par la suite, l’ingénieur des données peut tester et valider des solutions basées sur l’ensemble des données réelles.

Validation de la production:

Un paramètre synthétique similaire à un ensemble de données de production permet aux ingénieurs de production de tester et de valider leur environnement de production. Le résultat est un environnement de production plus robuste.

À propos de l’algorithme des données synthétiques¶

Snowflake utilise un algorithme pour générer des données synthétiques similaires à l’ensemble de données original. L’algorithme utilise l’ensemble des données originales pour générer des données synthétiques qui ont les mêmes propriétés statistiques que l’ensemble des données originales. Une fois cette distribution saisie, les données synthétiques ressemblent statistiquement aux données d’origine, mais n’ont pas de référence ou de lien direct avec une ligne quelconque des données d’origine.

Valeurs de données générées¶

Snowflake génère des données synthétiques pour les colonnes sans clé de jointure en fonction du type de données source :

• Données statistiques : Données de type nombre, booléen, date, heure ou horodatage. Les données générées sont du même type, avec des valeurs similaires à celles des données sources.

• Chaîne catégorielle : une colonne de type chaîne avec peu de valeurs uniques:sup:‡. Les données générées utilisent les valeurs réelles des données sources.

• Chaîne non catégorielle : une colonne de type chaîne avec beaucoup de valeurs uniques^‡. Masquée dans la sortie, sauf si vous spécifiez un format de sortie avec l’option replace dans GENERATE_SYNTHETIC_DATA.

Vous pouvez désigner explicitement une colonne de type chaîne sans clé de jointure comme étant catégorielle ou non catégorielle en fournissant une valeur categorical à GENERATE_SYNTHETIC_DATA. Les colonnes de la clé de jointure doivent être des chaînes non catégorielles ou des statistiques.

Les données générées dans chaque table conservent les distributions et corrélations approximatives présentes dans la table d’origine.

Les colonnes désignées comme clés de jointure peuvent être de n’importe quel type de données, et elles donneront lieu à des données synthétiques du même type et à des valeurs cohérentes, mais artificielles.

^‡ Peu de valeurs uniques signifie que le nombre de valeurs uniques est inférieur à la moitié du nombre de lignes. Beaucoup de valeurs uniques signifie que le nombre de valeurs uniques est supérieur à la moitié du nombre de lignes.

Maintien de la cohérence des clés de jointure dans les données synthétiques¶

Si vous planifiez d’exécuter des requêtes de jointure sur vos données synthétiques, désignez chaque colonne sur laquelle vous ferez une jointure comme une clé de jointure. Vous pouvez désigner n’importe quelle colonne numérique, booléenne ou non catégorielle comme clé de jointure en lui attribuant la valeur join_key dans GENERATE_SYNTHETIC_DATA. Une valeur synthétique cohérente est générée dans les données de sortie pour la même valeur dans les données sources pour toutes les clés de jointure dans toutes les tables au cours d’une seule exécution. Cela vous permet d’exécuter des requêtes conjointes et d’obtenir des résultats similaires à ceux que vous obtiendriez en exécutant la même requête sur les données sources.

Pour maintenir la cohérence des jointures entre les tables, assurez-vous que la même colonne de clé de jointure dans chaque table a les mêmes arguments. En d’autres termes, si vous souhaitez que cust_id puisse être joint à plusieurs tables, fournissez le même ensemble d’arguments et de valeurs dans la description de columns pour chaque objet de l’ensemble de données :

'datasets':[
  {
    'input_table': 'd.s.orders',
    'output_table': 'd.s.orders_synth',
    'columns': {'cust_id': {'join_key': True, 'replace': 'uuid'}, ...}
  },
  {
    'input_table': 'd.s.customers',
    'output_table': 'd.s.customers_synth',
    'columns' : {'cust_id': {'join_key': True, 'replace':'uuid'}, ...}

  }
]

Si vous fournissez un secret de chaîne symétrique à consistency_secret dans GENERATE_SYNTHETIC_DATA, les valeurs des clés de jointure seront cohérentes d’une table à l’autre et d’une exécution à l’autre. Si vous ne spécifiez pas de secret, les valeurs de la clé de jointure seront cohérentes pour toutes les tables lors d’une même exécution, mais pas lors d’exécutions multiples. La cohérence multi-exécution n’est prise en charge que pour les colonnes de type chaîne.

Exemple : Cohérence mono-exécution de la clé de jointure

CALL SNOWFLAKE.DATA_PRIVACY.GENERATE_SYNTHETIC_DATA({
  'datasets':[
      {
        'input_table': 'CLINICAL_DB.PUBLIC.PATIENTS1',
        'output_table': 'MY_DB.PUBLIC.PATIENTS1',
        'columns': { 'patient_id': {'join_key': TRUE}, 'age':{'join_key': TRUE}}
      },
      {
        'input_table': 'CLINICAL_DB.PUBLIC.PATIENTS2',
        'output_table': 'MY_DB.PUBLIC.PATIENTS2',
        'columns': { 'patient_id': {'join_key': TRUE}, 'age':{'join_key': TRUE}}
      }
    ],
    'replace_output_tables': TRUE
});

Exemple : Cohérence multi-exécution des clés de jointure

-- Generate consistent join keys across multiple runs by
-- providing a symmetric key secret.
CREATE OR REPLACE SECRET my_db.public.my_consistency_secret
  TYPE=SYMMETRIC_KEY
  ALGORITHM=GENERIC;

CALL SNOWFLAKE.DATA_PRIVACY.GENERATE_SYNTHETIC_DATA({
  'datasets':[
      {
        'input_table': 'CLINICAL_DB.PUBLIC.BASE_TABLE',
        'output_table': 'MY_DB.PUBLIC.PATIENTS1',
        'columns': { 'patient_id': {'join_key': TRUE}}
      }
    ],
    'consistency_secret': SYSTEM$REFERENCE('SECRET', 'MY_CONSISTENCY_SECRET', 'SESSION', 'READ')::STRING,
    'replace_output_tables': TRUE
});

CALL SNOWFLAKE.DATA_PRIVACY.GENERATE_SYNTHETIC_DATA({
  'datasets':[
      {
        'input_table': 'CLINICAL_DB.PUBLIC.SECOND_TABLE',
        'output_table': 'MY_DB.PUBLIC.PATIENTS2',
        'columns': { 'patient_id': {'join_key': TRUE}}
      }
    ],
    'consistency_secret': SYSTEM$REFERENCE('SECRET', 'MY_CONSISTENCY_SECRET', 'SESSION', 'READ')::STRING,
    'replace_output_tables': TRUE
});

Améliorer la protection de la vie privée¶

Lorsque vous appelez la procédure stockée GENERATE_SYNTHETIC_DATA, vous pouvez éventuellement définir l’option de configuration 'similarity_filter': True pour appliquer un filtre de confidentialité à la table de sortie. Le filtre de confidentialité supprime les lignes de la table de sortie si les lignes sont trop similaires à l’ensemble des données d’entrée. Le seuil de confidentialité utilise les valeurs du rapport de distance du plus proche voisin (NNDR) et de la distance à l’enregistrement le plus proche (DCR) pour déterminer si une ligne doit être supprimée de la table de sortie.

Les valeurs NULL présentes dans les colonnes qui ne sont pas de type chaîne de caractères entraîneront l’échec du filtre de similarité et ne généreront pas de données synthétiques.

Exigences relatives à la table d’entrée¶

Les tables et les vues sont prises en charge en tant que données sources. Vous pouvez spécifier jusqu’à cinq tables d’entrée par appel de procédure.

Pour générer des données synthétiques, chaque table ou vue d’entrée doit répondre aux exigences suivantes :

• Au moins 20 lignes distinctes

• Maximum 100 colonnes

• Maximum 14 millions de lignes

• Les types de tables d’entrée suivants sont pris en charge :

  • Tables standard, temporaires, dynamiques et transitoires

  • Vues matérialisées standard, matérialisées, et matérialisées sécurisées

• Les types de tables d’entrée suivants ne sont pas pris en charge :

  • Tables externes, Apache Iceberg™ et hybrides

  • Flux

• Les types de colonnes suivants sont pris en charge. Les colonnes dont le type de données n’est pas pris en charge renvoient NULL pour toutes les valeurs de la colonne.

  • Tous les types numériques (NUMBER, DECIMAL, FLOAT, INTEGER, etc.)

  • BOOLEAN

  • Tous les types de date et d’heure (DATE, DATETIME, TIME, TIMESTAMP, etc.) sauf TIMESTAMP_TZ

  • STRING, VARCHAR, CHAR, CHARACTER, TEXT

    Si plus de la moitié des valeurs d’une colonne STRING sont des valeurs uniques, Snowflake remplace la valeur par une valeur expurgée dans la table de sortie pour des raisons de confidentialité.

Exigences en matière de contrôle d’accès¶

Pour générer des données synthétiques, vous devez utiliser un rôle doté de chacune des autorisations suivantes :

• USAGE sur l’entrepôt que vous souhaitez utiliser pour les requêtes.

• SELECT sur la table d’entrée à partir de laquelle vous souhaitez générer des données synthétiques.

• USAGE sur la base de données et le schéma qui contiennent la table d’entrée, et sur la base de données qui contient la table de sortie.

• CREATE TABLE sur le schéma qui contient la table de sortie.

• OWNERSHIP sur les tables de sortie. La façon la plus simple de procéder est d’accorder l’autorisation OWNERSHIP au schéma dans lequel la table de sortie est générée. (Toutefois, si quelqu’un a appliqué un FUTURE GRANT sur ce schéma, la propriété de la table sera remplacée en silence, c’est-à-dire que GRANT OWNERSHIP ON FUTURE TABLES IN SCHEMA db.my_schema TO ROLE some_role accordera automatiquement OWNERSHIP à some_role sur toutes les nouvelles tables créées dans le schéma my_schema)

Tous les utilisateurs peuvent accéder à la procédure stockée SNOWFLAKE.DATA_PRIVACY.GENERATE_SYNTHETIC_DATA. L’accès est possible en utilisant le rôle de base de données SNOWFLAKE.CORE_VIEWER, qui est accordé au rôle PUBLIC.

Autres exigences¶

Vous devez accepter les termes et conditions d’Anaconda dans votre compte Snowflake afin d’activer cette fonction.