Copier des données depuis MongoDB à l'aide d'Azure Data Factory ou de Synapse Analytics (hérité)
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, l’aide à la décision et la création de rapports. 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 MongoDB. Il s’appuie sur l’article Vue d’ensemble de l’activité de copie.
Important
Le service a publié un nouveau connecteur MongoDB qui améliore la prise en charge native de MongoDB par rapport à cette implémentation basée sur ODBC. Pour en savoir plus, consultez l'article Connecteur MongoDB.
Fonctionnalités prises en charge
Vous pouvez copier des données d’une base de données MongoDB vers toute banque de données réceptrice prise en charge. Pour obtenir la liste des banques de données prises en charge en tant que sources ou récepteurs par l’activité de copie, consultez le tableau Banques de données prises en charge.
Plus précisément, ce connecteur MongoDB prend en charge :
- MongoDB versions 2.4, 2.6, 3.0, 3.2, 3.4 et 3.6.
- Copie de données en utilisant une authentification De base ou Anonyme.
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 MongoDB intégré, ce qui évite d’avoir à en installer un manuellement lors de la copie des données issues de MongoDB.
Prise en main
Pour effectuer l’activité Copie avec un pipeline, vous pouvez vous servir de l’un des outils ou kits SDK suivants :
- L’outil Copier des données
- Le portail Azure
- Le kit SDK .NET
- Le kit SDK Python
- Azure PowerShell
- L’API REST
- Le modèle Azure Resource Manager
Créer un service lié à MongoDB à l’aide de l’interface utilisateur
Utilisez les étapes suivantes pour créer un service lié à MongoDB dans l’interface utilisateur du portail Azure.
Accédez à l’onglet Gérer dans votre espace de travail Azure Data Factory ou Synapse et sélectionnez Services liés, puis cliquez sur Nouveau :
Recherchez Mongo et sélectionnez le connecteur MongoDB.
Configurez les informations du service, testez la connexion et créez le nouveau service lié.
Informations de configuration des connecteurs
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 MongoDB.
Propriétés du service lié
Les propriétés prises en charge pour le service lié MongoDB sont les suivantes :
| Propriété | Description | Obligatoire |
|---|---|---|
| type | La propriété type doit être définie sur : MongoDb | Oui |
| server | Nom d’hôte ou adresse IP du serveur MongoDB. | Oui |
| port | Le port TCP utilisé par le serveur MongoDB pour écouter les connexions clientes. | Non (valeur par défaut est 27017) |
| databaseName | Nom de la base de données MongoDB à laquelle vous souhaitez accéder. | Oui |
| authenticationType | Type d'authentification utilisé pour se connecter à la base de données MongoDB. Les valeurs autorisées sont les suivantes : De base, et Anonyme. |
Oui |
| username | Compte d’utilisateur pour accéder à MongoDB. | Oui (si l’authentification de base est utilisée). |
| mot de passe | Mot de passe pour l’utilisateur. Marquez ce champ en tant que SecureString afin de le stocker en toute sécurité, ou référencez un secret stocké dans Azure Key Vault. | Oui (si l’authentification de base est utilisée). |
| authSource | Nom de la base de données MongoDB que vous souhaitez utiliser pour vérifier vos informations d’identification pour l’authentification. | Non. Par défaut, l’authentification de base utilise le compte d’administrateur et la base de données spécifiés à l’aide de la propriété databaseName. |
| enableSsl | Indique si les connexions au serveur sont chiffrées à l’aide du protocole TLS. La valeur par défaut est false. | Non |
| allowSelfSignedServerCert | Indique si les certificats auto-signés provenant du serveur sont autorisés ou non. La valeur par défaut est false. | Non |
| 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 |
Exemple :
{
"name": "MongoDBLinkedService",
"properties": {
"type": "MongoDb",
"typeProperties": {
"server": "<server name>",
"databaseName": "<database name>",
"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 Jeux de données et services liés. Les propriétés suivantes sont prises en charge pour le jeu de données MongoDB :
| Propriété | Description | Obligatoire |
|---|---|---|
| type | La propriété type du jeu de données doit être définie sur : MongoDbCollection | Oui |
| collectionName | Nom de la collection dans la base de données MongoDB. | Oui |
Exemple :
{
"name": "MongoDbDataset",
"properties": {
"type": "MongoDbCollection",
"linkedServiceName": {
"referenceName": "<MongoDB linked service name>",
"type": "LinkedServiceReference"
},
"typeProperties": {
"collectionName": "<Collection name>"
}
}
}
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 MongoDB.
MongoDB en tant que source
Les propriétés prises en charge dans la section source de l’activité de copie sont les suivantes :
| Propriété | Description | Obligatoire |
|---|---|---|
| type | La propriété type de la source d’activité de copie doit être définie sur : MongoDbSource | Oui |
| query | Utiliser la requête SQL-92 personnalisée pour lire les données. Par exemple : select * from MyTable. | Non (si « collectionName » est spécifié dans le jeu de données) |
Exemple :
"activities":[
{
"name": "CopyFromMongoDB",
"type": "Copy",
"inputs": [
{
"referenceName": "<MongoDB input dataset name>",
"type": "DatasetReference"
}
],
"outputs": [
{
"referenceName": "<output dataset name>",
"type": "DatasetReference"
}
],
"typeProperties": {
"source": {
"type": "MongoDbSource",
"query": "SELECT * FROM MyTable"
},
"sink": {
"type": "<sink type>"
}
}
}
]
Conseil
Lorsque vous spécifiez une requête SQL, soyez attentif au format DateTime. Par exemple : SELECT * FROM Account WHERE LastModifiedDate >= '2018-06-01' AND LastModifiedDate < '2018-06-02' ou pour utiliser le paramètre SELECT * FROM Account WHERE LastModifiedDate >= '@{formatDateTime(pipeline().parameters.StartTime,'yyyy-MM-dd HH:mm:ss')}' AND LastModifiedDate < '@{formatDateTime(pipeline().parameters.EndTime,'yyyy-MM-dd HH:mm:ss')}'
Schéma par Data Factory
Le service Azure Data Factory déduit le schéma à partir d’une collection MongoDB à l’aide des 100 derniers documents dans la collection. Si ces 100 documents ne contiennent pas de schéma complet, certaines colonnes peuvent être ignorées lors de l’opération de copie.
Mappage de type de données pour MongoDB
Lors de la copie de données de MongoDB, les mappages suivants sont utilisés entre les types de données MongoDB et les types de données intermédiaires utilisés dans le service en interne. 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 MongoDB | Type de données de service intermédiaire |
|---|---|
| Binary | Byte[] |
| Boolean | Boolean |
| Date | DateTime |
| NumberDouble | Double |
| NumberInt | Int32 |
| NumberLong | Int64 |
| ObjectID | String |
| String | String |
| UUID | Guid |
| Object | Renormalisé en colonnes aplaties avec « _ » comme séparateur imbriqué |
Notes
Pour en savoir plus sur la prise en charge des tableaux à l’aide de tables virtuelles, reportez-vous à la section Prise en charge des types complexes à l’aide de tables virtuelles.
Les types de données MongoDB suivants ne sont pas pris en charge pour le moment : DBPointer, JavaScript, clé max./min., expression régulière, symbole, horodatage, non définie.
Prise en charge des types complexes à l’aide de tables virtuelles
Le service utilise un pilote ODBC intégré pour assurer la connexion à votre base de données MongoDB et copier des données à partir de cette dernière. Pour les types complexes tels que des tableaux ou des objets avec des types différents entre les documents, le pilote normalise de nouveau les données dans les tables virtuelles correspondantes. En particulier, si une table contient de telles colonnes, 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 type complexe. 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 type complexe, qui étend les données imbriquées. Le nom des tables virtuelles est composé du nom de la table réelle, d’un séparateur « _ » et du nom du tableau ou de l’objet.
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. Vous pouvez accéder au contenu des tableaux MongoDB en interrogeant et en joignant les tables virtuelles.
Exemple
Par exemple, ExampleTable est ici une table MongoDB qui dispose d’une colonne avec un tableau d’objets dans chaque cellule (Factures) et d’une colonne avec un tableau de types scalaires (Évaluations).
| _id | Nom du client | Factures | Niveau de service | Évaluations |
|---|---|---|---|---|
| 1111 | ABC | [{invoice_id:"123", item:"grille-pain", price:"456", discount:"0.2"}, {invoice_id:"124", item:"four", price: "1235", discount: "0.2"}] | Argent | [5,6] |
| 2222 | XYZ | [{invoice_id:"135", item:"réfrigirateur", price: "12543", discount: "0.0"}] | Or | [1,2] |
Le pilote génère plusieurs tables virtuelles pour représenter cette table. La première table virtuelle est la table de base nommée « ExampleTable » présentée dans l’exemple. La table de base contient toutes les données de la table d’origine, mais les données dans les tableaux ont été omises et sont développées dans les tables virtuelles.
| _id | Nom du client | Niveau de service |
|---|---|---|
| 1111 | ABC | Argent |
| 2222 | XYZ | Or |
Les tables suivantes montrent les tables virtuelles qui représentent les tableaux d’origine dans l’exemple. Ces tables contiennent les éléments suivants :
- Une référence à la colonne de clé primaire d’origine correspondant à la ligne du tableau d’origine (via la colonne _id)
- Une indication de la position des données dans le tableau d’origine
- Les données développées pour chaque élément du tableau
Table « ExampleTable_Invoices » :
| _id | ExampleTable_Invoices_dim1_idx | invoice_id | item | price | Remise |
|---|---|---|---|---|---|
| 1111 | 0 | 123 | grille-pain | 456 | 0.2 |
| 1111 | 1 | 124 | four | 1235 | 0.2 |
| 2222 | 0 | 135 | réfrigérateur | 12543 | 0.0 |
Table « ExampleTable_Ratings » :
| _id | ExampleTable_Ratings_dim1_idx | ExampleTable_Ratings |
|---|---|---|
| 1111 | 0 | 5 |
| 1111 | 1 | 6 |
| 2222 | 0 | 1 |
| 2222 | 1 | 2 |
Contenu connexe
Pour obtenir une liste des magasins de données pris en charge comme sources et récepteurs par l’activité de copie, consultez la section sur les magasins de données pris en charge.