Partager via

Zones d’atterrissage des données

Les zones d’atterrissage des données sont connectées à votre zone d’atterrissage de gestion des données par appairage de réseaux virtuels ou par des points de terminaison privés. Chaque zone d’atterrissage de données est considérée comme une zone d’atterrissage liée à l’architecture de la zone d’atterrissage Azure.

Importante

Avant de provisionner une zone d’atterrissage de données, assurez-vous que votre modèle d’exploitation DevOps et d’intégration continue et de livraison continue (CI/CD) est en place et qu’une zone d’atterrissage de gestion des données est déployée.

Chaque zone d’atterrissage de données comporte plusieurs couches qui permettent l’agilité des intégrations de données de service et les applications de données qu’elle contient. Vous pouvez déployer une nouvelle zone d’atterrissage de données avec un ensemble standard de services qui permettent à la zone d’atterrissage des données d’ingérer et d’analyser les données.

Le tableau suivant montre la structure d’un abonnement Azure classique associé à une zone d’atterrissage de données.

Couche Obligatoire Groupes de ressources
Couche de services de plate-forme Oui
Services de base Oui
Application de données Optionnel
Création de rapports et visualisation Optionnel

Remarque

La couche de services principaux est marquée comme obligatoire, mais tous les groupes de ressources et services inclus dans cet article ne sont pas tous nécessaires pour votre zone d'atterrissage de données.

Architecture de zone d’atterrissage des données

L’architecture de zone d’atterrissage de données suivante illustre les couches, leurs groupes de ressources et les services que chaque groupe de ressources contient. L’architecture fournit une vue d’ensemble de tous les groupes et rôles associés à votre zone d’atterrissage de données et à l’étendue de leur accès à vos plans de contrôle et de données. L’architecture illustre également la façon dont chaque couche s’aligne sur les responsabilités du modèle d’exploitation.

Diagramme de l’architecture de la zone d’atterrissage de données.

Conseil / Astuce

Avant de déployer une zone d’atterrissage de données, veillez à prendre en compte le nombre de zones d’atterrissage de données initiales que vous souhaitez déployer.

Services de plateforme

La couche services de plateforme inclut les services requis pour permettre la connectivité et l’observabilité de votre zone d’atterrissage de données dans le contexte de l’analytique à l’échelle du cloud. Le tableau suivant répertorie les groupes de ressources recommandés.

groupe de ressources Obligatoire Descriptif
network-rg Oui Réseautage
security-rg Oui Sécurité et supervision

Réseautage

Le groupe de ressources réseau contient des services de connectivité, notamment un réseau virtuel Azure, des groupes de sécurité réseau et des tables de routage. Tous ces services sont déployés dans un seul groupe de ressources.

Le réseau virtuel de votre zone d’atterrissage de données est mis en pair automatiquement avec le réseau virtuel de votre zone d’atterrissage de gestion des données et avec le réseau virtuel de votre abonnement de connectivité.

Sécurité et supervision

Le groupe de ressources de sécurité et de surveillance inclut Azure Monitor et Microsoft Defender pour cloud pour collecter les données de télémétrie du service, définir des critères et des alertes de surveillance, et appliquer des stratégies et des analyses aux services.

Services de base

La couche de services de base inclut les services fondamentaux nécessaires pour activer votre zone d’atterrissage de données dans le contexte d’analytique à l’échelle du cloud. Le tableau suivant répertorie les groupes de ressources qui fournissent la suite standard de services disponibles dans chaque zone d’atterrissage de données que vous déployez.

groupe de ressources Obligatoire Descriptif
storage-rg Oui Services de lac de données
runtimes-rg Oui IR partagés
mgmt-rg Oui Agents CI/CD
external-data-rg Oui Stockage de données externes
data-ingestion-rg Optionnel Services d’ingestion de données partagées
shared-applications-rg Optionnel Applications partagées (Azure Databricks)

Stockage

Le diagramme précédent montre trois comptes Azure Data Lake Storage Gen2 provisionnés dans un seul groupe de ressources Data Lake Services. Les données transformées à différentes étapes sont enregistrées dans l’un des lacs de données de votre zone d’atterrissage de données. Les données sont disponibles pour la consommation par vos équipes d’analyse, de science des données et de visualisation.

Les couches data lake utilisent une terminologie différente en fonction de la technologie et du fournisseur. Ce tableau fournit des conseils sur la façon d’appliquer des termes pour l’analytique à l’échelle du cloud :

Analytique à l’échelle du cloud Delta Lake Autres termes Descriptif
Cru Bronze Atterrissage et conformité Tables d’ingestion
Enrichie Argent Zone de normalisation Tables affinées. Entités complètes stockées, jeux d’enregistrements prêts pour la consommation à partir de systèmes d’enregistrement.
Organisé Doré Zone de produit Caractéristiques ou tables de données agrégées. Zone principale pour les applications, les équipes et les utilisateurs pour consommer des produits de données.
Développement -- Zone de développement Lieu pour les ingénieurs data et les scientifiques, qui se compose d’un sandbox analytique et d’une zone de développement de produits.

Remarque

Dans le diagramme précédent, chaque zone d’atterrissage de données a trois comptes de stockage de lac de données. Selon vos besoins, vous pouvez choisir de consolider vos couches brutes, enrichies et organisées dans un compte de stockage et de gérer un autre compte de stockage appelé espace de travail pour les consommateurs de données afin d’apporter d’autres produits de données utiles.

Pour plus d’informations, consultez :

IR partagés

Les pipelines Azure Data Factory utilisent des IR pour accéder aux sources de données de manière sécurisée dans des réseaux appairés ou isolés. Les IRs partagés doivent être déployés sur une machine virtuelle (VM) ou des Virtual Machine Scale Sets dans le groupe de ressources IR partagé.

Pour activer le groupe de ressources partagé :

Remarque

Le déploiement décrit le déploiement d’une VM unique avec un IR auto-hébergé. Vous pouvez associer un runtime d’intégration auto-hébergé à plusieurs machines virtuelles locales ou dans Azure. Ces ordinateurs sont appelés nœuds. Vous pouvez avoir jusqu’à quatre nœuds associés à un IR auto-hébergé. Les avantages de l’utilisation de plusieurs nœuds sont les suivants :

  • La haute disponibilité de l’IR auto-hébergé supprime le point de défaillance unique dans votre application de données ou dans l’orchestration de l’intégration de données cloud.

  • Amélioration des performances et du débit pendant le déplacement des données entre les services de données locaux et cloud. Pour plus d’informations, consultez Guide sur les performances et la scalabilité de l’activité de copie.

Vous pouvez associer plusieurs nœuds en installant le logiciel ir auto-hébergé à partir du Centre de téléchargement Microsoft. Inscrivez-la ensuite à l’aide de l’une des clés d’authentification obtenues à partir de l’applet de commande New-AzDataFactoryV2IntegrationRuntimeKey , comme décrit dans le tutoriel.

Pour plus d’informations, consultez La haute disponibilité et la scalabilité d’Azure Data Factory.

Veillez à déployer des IR partagés au plus près possible de la source de données. Vous pouvez déployer les IR dans une zone d’atterrissage de données, dans des clouds non-Microsoft ou dans un cloud privé si la VM dispose d’une connectivité aux sources de données requises.

Gestion

Les agents CI/CD s’exécutent sur des machines virtuelles et aident à déployer des artefacts à partir du référentiel de code source, y compris les applications de données et les modifications apportées à la zone d’atterrissage des données.

Pour plus d’informations, consultez Agents Azure Pipelines.

Stockage externe

Les éditeurs de données partenaires doivent déposer les données dans votre plateforme afin que vos équipes d’applications de données puissent les importer dans leurs lacs de données. Vous pouvez également disposer de sources de données internes ou externes qui ne peuvent pas prendre en charge les exigences de connectivité ou d’authentification appliquées dans le reste des zones d’atterrissage des données. L’approche recommandée consiste à utiliser un compte de stockage distinct pour recevoir des données. Utilisez ensuite un ir partagé ou un processus d’ingestion similaire pour l’intégrer dans votre pipeline de traitement.

Les équipes des applications de données demandent les blobs de stockage. Ces demandes sont approuvées par l’équipe des opérations de zone de réception des données. Les données doivent être supprimées de leur source de stockage blob une fois qu’elles sont ingérées dans le stockage brut.

Importante

Étant donné que les objets blob de stockage Azure sont approvisionnés en fonction des besoins, vous devez initialement déployer un groupe de ressources de services de stockage vide dans chaque zone de réception des données.

Ingestion des données

Ce groupe de ressources est facultatif et ne vous empêche pas de déployer votre zone d’atterrissage. Elle s’applique si vous avez développé ou êtes en train de développer un moteur d’ingestion agnostique des données qui ingère automatiquement les données en fonction des métadonnées enregistrées. Cette fonctionnalité inclut des chaînes de connexion, des chemins d’accès pour le transfert de données et des planifications d’ingestion.

Le groupe de ressources d’ingestion et de traitement a des services clés pour ce type d’infrastructure.

Déployez une instance Azure SQL Database pour contenir les métadonnées qu’Azure Data Factory utilise. Provisionnez un coffre de clés Azure pour stocker les secrets liés aux services d’ingestion automatisés. Ces secrets peuvent inclure :

  • Informations d’identification du metastore Azure Data Factory.
  • Informations d’identification du principal de service pour votre processus d’ingestion automatisé.

Pour plus d’informations, consultez le moteur d’ingestion indépendant des données.

Le tableau suivant décrit les services de ce groupe de ressources.

Service Obligatoire Lignes directrices
Azure Data Factory. Oui Azure Data Factory est votre moteur d’orchestration pour l’ingestion agnostique des données.
Azure SQL Database Oui SQL Database est le metastore pour Azure Data Factory.
Azure Event Hubs ou Azure IoT Hub Optionnel Event Hubs ou IoT Hub peut fournir un streaming en temps réel aux hubs d’événements, ainsi qu’un traitement par lots et streaming via un espace de travail d’ingénierie Azure Databricks.
Azure Databricks Optionnel Vous pouvez déployer Azure Databricks à utiliser avec votre moteur d’ingestion indépendant des données.

Applications partagées

Utilisez ce groupe de ressources facultatif lorsque vous devez disposer d’un ensemble de services partagés mis à la disposition de toutes les équipes qui créent des applications de données dans cette zone d’atterrissage de données. Les cas d’usage sont les suivants :

  • Un espace de travail Azure Databricks utilisé comme metastore partagé pour tous les autres espaces de travail Databricks créés dans la même zone d’atterrissage de données ou région.

Remarque

Azure Databricks utilise Unity Catalog pour régir l’accès et la visibilité des metastores dans les espaces de travail Databricks. Le catalogue Unity est activé au niveau du locataire, mais les metastores sont alignés avec les régions Azure. Cette configuration signifie que tous les espaces de travail Databricks compatibles avec le catalogue Unity dans une région Azure donnée doivent s’inscrire auprès du même metastore. Pour en savoir plus, consultez l'article Meilleures pratiques Unity Catalog.

Pour intégrer Azure Databricks, suivez les bonnes pratiques d’analytique à l’échelle du cloud. Pour plus d’informations, consultez Sécuriser l’accès à Azure Data Lake Gen2 à partir d’Azure Databricks et des meilleures pratiques Azure Databricks.

Application de données

Chaque zone d’atterrissage de données peut avoir plusieurs applications de données. Vous pouvez créer ces applications en ingéré des données à partir de différentes sources. Vous pouvez également créer des applications de données à partir d’autres applications de données dans la même zone d’atterrissage de données ou à partir d’autres zones d’atterrissage de données. La création d’applications de données est soumise à l’approbation du responsable des données.

Groupe de ressources d’application de données

Votre groupe de ressources pour l'application de données inclut tous les services requis pour créer l'application de données. Par exemple, une base de données Azure est requise pour MySQL, qui est utilisée par un outil de visualisation. Les données doivent être ingérées et transformées avant d’entrer dans cette base de données MySQL. Dans ce cas, vous pouvez déployer Azure Database pour MySQL et Azure Data Factory dans le groupe de ressources d’application de données.

Conseil / Astuce

Si vous décidez de ne pas implémenter un moteur agnostique aux données pour l’ingestion unique à partir de sources opérationnelles, ou si des connexions complexes ne sont pas prises en charge dans votre moteur agnostique aux données, développez une application de données alignée avec la source.

Création de rapports et visualisation

Vous pouvez utiliser des outils de visualisation et de création de rapports dans des espaces de travail Fabric, qui sont similaires aux espaces de travail Power BI. Cette fonctionnalité vous permet d’éviter de déployer des ressources uniques dans votre zone d’atterrissage de données. Vous pouvez inclure un groupe de ressources pour déployer la capacité Fabric, les machines virtuelles pour les passerelles de données ou d’autres services de données nécessaires pour fournir votre application de données à l’utilisateur.

Étape suivante

Produits de données analytiques à l'échelle du cloud dans Azure