Copier des données de Cassandra à l’aide d’Azure Data Factory ou de Synapse Analytics

S’APPLIQUE À : Azure Data Factory Azure Synapse Analytics

Conseil

Essayez Data Factory dans Microsoft Fabric, une solution d’analyse tout-en-un pour les entreprises. Microsoft Fabric couvre tous les aspects, du déplacement des données à la science des données, en passant par l’analyse en temps réel, la business intelligence et le reporting. Découvrez comment démarrer un nouvel essai gratuitement !

Cet article explique comment utiliser l’activité de copie dans un pipeline Azure Data Factory ou Synapse Analytics pour copier des données à partir d’une base de données Cassandra. Il s’appuie sur l’article Vue d’ensemble de l’activité de copie.

Important

Le connecteur Cassandra version 1.0 est à l’étape de suppression. Il est recommandé de mettre à niveau le connecteur Cassandra de la version 1.0 à la version 2.0.

Fonctionnalités prises en charge

Ce connecteur Cassandra est pris en charge pour les capacités suivantes :

Fonctionnalités prises en charge	IR
Activité de copie (source/-)	(1) (2)
Activité de recherche	(1) (2)

① Runtime d’intégration Azure ② Runtime d’intégration auto-hébergé

Pour obtenir la liste des magasins de données pris en charge en tant que sources et récepteurs, consultez la table Magasins de données pris en charge.

Plus précisément, ce connecteur Cassandra prend en charge :

Cassandra versions 3.x.x et 4.x.x pour la version 2.0.
Cassandra versions 2.x et 3.x pour la version 1.0.
Copie de données en utilisant une authentification De base ou Anonyme.

Remarque

Pour une activité exécutée sur le runtime d’intégration auto-hébergé, Cassandra 3.x est pris en charge à partir d’Integration Runtime version 3.7 ou supérieure.

Prérequis

Si votre magasin de données se trouve dans un réseau local, un réseau virtuel Azure ou un cloud privé virtuel Amazon, vous devez configurer un runtime d’intégration auto-hébergé pour vous y connecter.

Si votre magasin de données est un service de données cloud managé, vous pouvez utiliser Azure Integration Runtime. Si l’accès est limité aux adresses IP qui sont approuvées dans les règles de pare-feu, vous pouvez ajouter les adresses IP Azure Integration Runtime dans la liste d’autorisation.

Vous pouvez également utiliser la fonctionnalité de runtime d’intégration de réseau virtuel managé dans Azure Data Factory pour accéder au réseau local sans installer et configurer un runtime d’intégration auto-hébergé.

Pour plus d’informations sur les mécanismes de sécurité réseau et les options pris en charge par Data Factory, consultez Stratégies d’accès aux données.

Le runtime d’intégration fournit un pilote Cassandra intégré. Ainsi, vous n’avez pas besoin d’installer manuellement un pilote lors de la copie des données vers/depuis Cassandra.

Prise en main

Pour effectuer l’activité de copie avec un pipeline, vous pouvez utiliser l’un des outils ou kits sdk suivants :

Créez un service lié à Cassandra à l’aide de l’interface utilisateur

Utilisez les étapes suivantes pour créer un service lié à Cassandra dans l’interface utilisateur du portail Azure.

Accédez à l’onglet Gérer dans votre espace de travail Azure Data Factory ou Synapse, sélectionnez Services liés, puis cliquez sur Nouveau :
- Azure Data Factory.
- Azure Synapse
Recherchez Cassandra et sélectionnez le connecteur Cassandra.
Configurez les informations du service, testez la connexion et créez le nouveau service lié.

Détails de configuration du connecteur

Les sections suivantes fournissent des informations sur les propriétés utilisées pour définir les entités Data Factory spécifiques du connecteur Cassandra.

Propriétés du service lié

Les propriétés prises en charge pour le service lié Cassandra sont les suivantes :

Propriété	Descriptif	Obligatoire
type	La propriété type doit être définie sur Cassandra	Oui
version	Version que vous spécifiez.	Oui pour la version 2.0.
host	Une ou plusieurs adresses IP ou noms d’hôte de serveurs Cassandra. Renseignez une liste des adresses IP ou des noms d’hôte séparée par des virgules pour vous connecter simultanément à tous les serveurs.	Oui
port	Le port TCP utilisé par le serveur Cassandra pour écouter les connexions clientes.	Non (la valeur par défaut 9042)
type d'authentification	Type d'authentification utilisé pour se connecter à la base de données Cassandra. Valeurs autorisées : De base et Anonyme.	Oui
nom d'utilisateur	Spécifiez le nom d’utilisateur du compte d’utilisateur.	Oui, si authenticationType est défini sur De base.
mot de passe	Spécifiez le mot de passe du compte d'utilisateur. Marquez ce champ en tant que SecureString afin de le stocker de façon sécurisée, ou référencez un secret stocké dans Azure Key Vault.	Oui, si authenticationType est défini sur De base.
connectVia	Runtime d’intégration à utiliser pour la connexion à la banque de données. Pour plus d’informations, consultez la section Conditions préalables. À défaut de spécification, le runtime d’intégration Azure par défaut est utilisé.	Non

Remarque

Actuellement, la connexion à Cassandra à l’aide de TLS n’est pas prise en charge.

Exemple : version 2.0

{
    "name": "CassandraLinkedService",
    "properties": {
        "type": "Cassandra",
        "version": "2.0", 
        "typeProperties": {
            "host": "<host>",
            "authenticationType": "Basic",
            "username": "<username>",
            "password": {
                "type": "SecureString",
                "value": "<password>"
            }
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

Exemple : version 1.0

{
    "name": "CassandraLinkedService",
    "properties": {
        "type": "Cassandra",
        "typeProperties": {
            "host": "<host>",
            "authenticationType": "Basic",
            "username": "<username>",
            "password": {
                "type": "SecureString",
                "value": "<password>"
            }
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

Propriétés du jeu de données

Pour obtenir la liste complète des sections et propriétés disponibles pour la définition de jeux de données, consultez l’article sur les jeux de données. Cette section fournit la liste des propriétés prises en charge par le jeu de données Cassandra.

Pour copier des données de Cassandra, affectez la valeur CassandraTable à la propriété type du jeu de données. Les propriétés prises en charge sont les suivantes :

Propriété	Descriptif	Obligatoire
type	La propriété type du jeu de données doit être définie sur CassandraTable	Oui
espace de clé	Nom de l’espace de clé ou du schéma dans la base de données Cassandra.	Non (si « query » pour « CassandraSource » est spécifié)
tableName	Nom de la table dans la base de données Cassandra.	Non (si « query » pour « CassandraSource » est spécifié)

Exemple :

{
    "name": "CassandraDataset",
    "properties": {
        "type": "CassandraTable",
        "typeProperties": {
            "keySpace": "<keyspace name>",
            "tableName": "<table name>"
        },
        "schema": [],
        "linkedServiceName": {
            "referenceName": "<Cassandra linked service name>",
            "type": "LinkedServiceReference"
        }
    }
}

Propriétés de l’activité de copie

Pour obtenir la liste complète des sections et des propriétés disponibles pour la définition des activités, consultez l’article Pipelines. Cette section fournit la liste des propriétés prises en charge par la source Cassandra.

Cassandra en tant que source

Si vous utilisez la version 2.0 pour copier des données à partir de Cassandra, définissez le type de source dans l’activité de copie sur CassandraSource. Les propriétés prises en charge dans la section source de l’activité de copie sont les suivantes :

Propriété	Descriptif	Obligatoire
type	La propriété type de la source d’activité de copie doit être définie sur CassandraSource	Oui
requête	Utilise la requête personnalisée pour lire des données. Requête CQL, consultez la référence CQL.	Non (si « tableName » et « keyspace » sont spécifiés dans le jeu de données).
Niveau de cohérence	Le niveau de cohérence spécifie le nombre de réplicas devant répondre à une demande de lecture avant de renvoyer des données à l’application cliente. Cassandra vérifie le nombre de réplicas spécifié pour permettre aux données de répondre à la demande de lecture. Reportez-vous à Configuring data consistency (Configuration de la cohérence des données) pour plus d’informations. Valeurs autorisées : ONE, TWO, THREE, QUORUM, ALL, LOCAL_QUORUM, EACH_QUORUM et LOCAL_ONE.	Non (la valeur par défaut est `ONE`)

Exemple :

"activities":[
    {
        "name": "CopyFromCassandra",
        "type": "Copy",
        "inputs": [
            {
                "referenceName": "<Cassandra input dataset name>",
                "type": "DatasetReference"
            }
        ],
        "outputs": [
            {
                "referenceName": "<output dataset name>",
                "type": "DatasetReference"
            }
        ],
        "typeProperties": {
            "source": {
                "type": "CassandraSource",
                "query": "select id, firstname, lastname from mykeyspace.mytable",
                "consistencyLevel": "one"
            },
            "sink": {
                "type": "<sink type>"
            }
        }
    }
]

Si vous utilisez la version 1.0 pour copier des données à partir de Cassandra, définissez le type de source dans l’activité de copie sur CassandraSource. Les propriétés prises en charge dans la section source de l’activité de copie sont les suivantes :

Propriété	Descriptif	Obligatoire
type	La propriété type de la source d’activité de copie doit être définie sur CassandraSource	Oui
requête	Utilise la requête personnalisée pour lire des données. Requête SQL-92 ou requête CQL. Reportez-vous à référence CQL. Lorsque vous utilisez la requête SQL, indiquez keyspace name.table name pour représenter la table que vous souhaitez interroger.	Non (si « tableName » et « keyspace » sont spécifiés dans le jeu de données).
Niveau de cohérence	Le niveau de cohérence spécifie le nombre de réplicas devant répondre à une demande de lecture avant de renvoyer des données à l’application cliente. Cassandra vérifie le nombre de réplicas spécifié pour permettre aux données de répondre à la demande de lecture. Reportez-vous à Configuring data consistency (Configuration de la cohérence des données) pour plus d’informations. Valeurs autorisées : ONE, TWO, THREE, QUORUM, ALL, LOCAL_QUORUM, EACH_QUORUM et LOCAL_ONE.	Non (la valeur par défaut est `ONE`)

Mappage de type de données pour Cassandra

Lors de la copie de données à partir de Cassandra, les mappages suivants sont utilisés entre les types de données Cassandra et les types de données intermédiaires utilisés en interne dans le service. Pour découvrir comment l’activité de copie mappe le schéma et le type de données la source au récepteur, voir Mappages de schémas et de types de données.

Type de données Cassandra	Type de données de service intermédiaire (pour la version 2.0)	Type de données de service intermédiaire (pour la version 1.0)
ASCII	Chaîne	Chaîne
bigint	Int64	Int64
BLOB	Byte[]	Byte[]
BOOLEAN	Booléen	Booléen
DATE	Date et heure	Date et heure
DECIMAL	Décimal	Décimal
DOUBLE	Double	Double
FLOTTANT	Simple	Simple
INET	Chaîne	Chaîne
ENT	Int32	Int32
SMALLINT	Court	Int16
TEXT	Chaîne	Chaîne
TIMSTAMP	Date et heure	Date et heure
TIMEUUID	Guid	Guid
TINYINT	SByte	Int16
UUID (Identifiant Unique Universel)	Guid	Guid
VARCHAR	Chaîne	Chaîne
VARINT	Décimal	Décimal

Remarque

Pour les types de collection (mappage, ensemble, liste, etc.) sous la version 1.0, reportez-vous à la section Travailler avec les types de collection Cassandra à l'aide d'une table virtuelle lors de l'utilisation de la version 1.0.

Les types définis par l’utilisateur ne sont pas pris en charge.

La longueur des colonnes binaires et des colonnes de chaîne ne peut pas être supérieure à 4 000.

Travailler avec des collections lors de l’utilisation de la version 2.0

Lorsque vous utilisez la version 2.0 pour copier des données à partir de votre base de données Cassandra, aucune table virtuelle pour les types de collection n’est créée. Vous pouvez copier une table source dans le récepteur dans son type d’origine au format JSON.

Exemple

Par exemple, « ExampleTable » ci-après est une table de base de données Cassandra qui contient une colonne de clé primaire entière nommée « pk_int », une colonne de texte nommée value, une colonne de liste, une colonne de mappage et une colonne de jeu (nommée « StringSet »).

pk_int	Valeur	Liste	Mappage	StringSet
1	« exemple de valeur 1 »	[« 1 », « 2 », « 3 »]	{« S1 » : « a », « S2 » : « b »}	{« A », « B », « C »}
3	« exemple de valeur 3 »	[« 100 », « 101 », « 102 », « 105 »]	{« S1 » : « t »}	{« A », « E »}

Les données peuvent être lues directement à partir d’une table source et les valeurs de colonne sont conservées dans leurs types d’origine au format JSON, comme illustré dans le tableau suivant :

pk_int	Valeur	Liste	Mappage	StringSet
1	« exemple de valeur 1 »	[« 1 », « 2 », « 3 »]	{« S1 » : « a », « S2 » : « b »}	["A », « B », « C"]
3	« exemple de valeur 3 »	[« 100 », « 101 », « 102 », « 105 »]	{« S1 » : « t »}	["A », « E"]

Travailler avec des collections en utilisant une table virtuelle avec la version 1.0

Le service utilise un pilote ODBC intégré pour assurer la connexion à votre base de données Cassandra et copier des données à partir de cette dernière. Pour les types de collection, notamment les cartes, ensembles et listes, le pilote renormalise les données dans des tables virtuelles correspondantes. En particulier, si une table contient des colonnes de n’importe quelle collection, le pilote génère les tables virtuelles suivantes :

Une table de base, qui contient les mêmes données que la table réelle, à l’exception des colonnes de collection. La table de base utilise le même nom que la table réelle qu’elle représente.
Une table virtuelle pour chaque colonne de collection, qui étend les données imbriquées. Le nom des tables virtuelles qui représentent des collections est composé du nom de la table réelle, du séparateur « vt » et du nom de la colonne.

Les tables virtuelles font référence aux données présentées dans la table réelle, de manière à permettre au pilote d’accéder aux données dénormalisées. Consultez la section Exemple pour plus d’informations. Vous pouvez accéder au contenu des collections Cassandra en interrogeant et en joignant les tables virtuelles.

Exemple

pk_int	Valeur	Liste	Mappage	StringSet
1	« exemple de valeur 1 »	[« 1 », « 2 », « 3 »]	{« S1 » : « a », « S2 » : « b »}	{« A », « B », « C »}
3	« exemple de valeur 3 »	[« 100 », « 101 », « 102 », « 105 »]	{« S1 » : « t »}	{« A », « E »}

Le pilote génère plusieurs tables virtuelles pour représenter cette table. Les colonnes de clés étrangères dans les tables virtuelles font référence aux colonnes de clés primaires dans la table réelle, et indiquent à quelles lignes de la table réelle les lignes de la table virtuelle correspondent.

La première table virtuelle est la table de base nommée « ExampleTable » affichée dans le tableau suivant :

pk_int	Valeur
1	« exemple de valeur 1 »
3	« exemple de valeur 3 »

La table de base contient les mêmes données que la table de base de données d’origine, à l’exception des collections, qui sont omises de cette table et développées dans d’autres tables virtuelles.

Les tableaux suivants montrent les tables virtuelles qui renormalisent les données des colonnes Liste, Mappage et StringSet. Les colonnes portant des noms se terminant par « _index » ou « _key » indiquent la position des données dans la liste ou le mappage d’origine. Les colonnes portant des noms se terminant par « _value » contiennent les données étendues de la collection.

Table « ExampleTable_vt_List » :

pk_int	List_index	List_value
1	0	1
1	1	2
1	2	3
3	0	100
3	1	101
3	2	102
3	3	1:03

Table « ExampleTable_vt_Map » :

pk_int	Map_key	Map_value
1	S1	Un
1	S2	b
3	S1	t

Table « ExampleTable_vt_StringSet » :

pk_int	StringSet_value
1	Un
1	B
1	C
3	Un
3	E

Propriétés de l’activité Lookup

Pour en savoir plus sur les propriétés, consultez Activité Lookup.

Mettre à niveau le connecteur Cassandra

Voici les étapes qui vous aident à mettre à niveau le connecteur Cassandra :

Dans la page Modifier le service lié , sélectionnez la version 2.0 et configurez le service lié en faisant référence aux propriétés du service lié.
Dans la version 2.0, la query source d’activité de copie prend uniquement en charge la requête CQL, et non sql-92. Pour plus d’informations, consultez Cassandra comme source.
Le mappage de type de données pour la version 2.0 est différent de celui de la version 1.0. Pour découvrir le mappage de type de données le plus récent, consultez Mappage de type de données pour Cassandra.

Différences entre Cassandra version 2.0 et version 1.0

Le connecteur Cassandra version 2.0 offre de nouvelles fonctionnalités et est compatible avec la plupart des fonctionnalités de la version 1.0. Le tableau ci-dessous présente les différences de fonctionnalités entre la version 2.0 et la version 1.0.

Version 2.0	Version 1.0
Prise en charge de la requête CQL.	Prise en charge de la requête SQL-92 ou de la requête CQL.
Prise en charge de la spécification distincte de `keyspace` et de `tableName` dans le jeu de données.	Prise en charge de la modification de `keyspace` quand vous choisissez d’entrer manuellement le nom de la table dans le jeu de données.
Aucune table virtuelle n’est créée pour les types de collection. Pour plus d’informations, consultez Utiliser des collections lors de l’utilisation de la version 2.0.	Les tables virtuelles sont créées pour les types de collection. Pour plus d’informations, consultez Utiliser des types de collection Cassandra à l’aide d’une table virtuelle lors de l’utilisation de la version 1.0.
Les mappages suivants sont utilisés des types de données Cassandra vers un type de données de service intermédiaire. SMALLINT -> Short TINYINT -> SByte	Les mappages suivants sont utilisés des types de données Cassandra vers un type de données de service intermédiaire. SMALLINT -> Int16 TINYINT -> Int16

Consultez les banques de données prises en charge pour obtenir la liste des banques de données prises en charge en tant que sources et récepteurs par l’activité de copie.

Rétroaction

Cette page a-t-elle été utile ?

Last updated on 2025-08-21

Partager via

Copier des données de Cassandra à l’aide d’Azure Data Factory ou de Synapse Analytics

Fonctionnalités prises en charge

Prérequis

Prise en main

Créez un service lié à Cassandra à l’aide de l’interface utilisateur

Détails de configuration du connecteur

Propriétés du service lié

Propriétés du jeu de données

Propriétés de l’activité de copie

Cassandra en tant que source

Mappage de type de données pour Cassandra

Travailler avec des collections lors de l’utilisation de la version 2.0

Exemple

Travailler avec des collections en utilisant une table virtuelle avec la version 1.0

Exemple

Propriétés de l’activité Lookup

Mettre à niveau le connecteur Cassandra

Différences entre Cassandra version 2.0 et version 1.0

Contenu connexe

Rétroaction

Ressources additionnelles