Partager via


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 :

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.

  1. 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 :

  2. Recherchez Mongo et sélectionnez le connecteur MongoDB.

    Capture d’écran du connecteur MongoDB.

  3. Configurez les informations du service, testez la connexion et créez le nouveau service lié.

    Capture d’écran de la configuration du service lié pour MongoDB.

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

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.