Partager via


Choisir un magasin de données analytiques dans Azure

Dans une architecture Big Data , il est souvent nécessaire d’utiliser un magasin de données analytique qui sert des données traitées dans un format structuré qui peut être interrogé à l’aide d’outils analytiques. Les magasins de données analytiques qui permettent l’interrogation des données chaudes et des données froides sont collectivement appelés couche de service, ou stockage pour la mise à disposition des données.

La couche de service gère les données traitées à partir du chemin d’accès chaud et du chemin froid. Dans l’architecture Lambda, la couche de service est subdivisé en deux couches. La couche de traitement rapide contient les données traitées de manière incrémentielle. La couche de service par lots contient la sortie traitée par lot. La couche de service nécessite une prise en charge forte des lectures aléatoires qui ont une faible latence. Le stockage des données pour la couche de vitesse doit également prendre en charge les écritures aléatoires, car le chargement par lots de données dans ce stockage introduit des retards indésirables. Le stockage de données pour la couche batch doit également prendre en charge les écritures par lots, et non les écritures aléatoires.

Il n’existe aucun choix de gestion des données unique pour toutes les tâches de stockage de données. Chaque solution de gestion des données est optimisée pour différentes tâches. La plupart des applications cloud réelles et des processus Big Data ont diverses exigences en matière de stockage des données et utilisent souvent une combinaison de solutions de stockage de données.

Les solutions analytiques modernes, telles que Microsoft Fabric, fournissent une plateforme complète qui intègre différents services et outils de données pour répondre à divers besoins analytiques. Fabric inclut OneLake, qui est un lac de données logique unique et unifié pour toute votre organisation. OneLake est conçu pour stocker, gérer et sécuriser toutes les données organisationnelles dans un seul emplacement. Cette flexibilité permet à votre organisation de répondre à un large éventail de besoins en matière de stockage et de traitement des données.

Choisir un magasin de données analytiques

Il existe plusieurs options pour le stockage de service des données dans Azure, en fonction de vos besoins :

Les modèles de base de données suivants sont optimisés pour différents types de tâches :

  • Les bases de données clé-valeur stockent un objet sérialisé unique pour chaque valeur de clé. Ils conviennent parfaitement à la gestion de grands volumes de données lorsque la récupération est basée sur une clé spécifique, sans avoir à interroger d’autres propriétés d’élément.

  • Les bases de données de documents sont des bases de données clé-valeur dans lesquelles les valeurs sont des documents. Dans ce contexte, un document est une collection de champs et de valeurs nommés. La base de données stocke généralement les données dans un format tel que XML, YAML, JSON ou JSON binaire, mais peut utiliser du texte brut. Les bases de données de documents peuvent interroger des champs non clés et définir des index secondaires pour améliorer l’efficacité des requêtes. Cette fonctionnalité rend une base de données de documents plus adaptée aux applications qui doivent récupérer des données en fonction de critères plus complexes que la valeur de la clé de document. Par exemple, vous pouvez lancer une requête sur des champs tels que l’ID de produit, l’ID de client ou le nom du client.

  • Les bases de données orientées colonnes sont des magasins de données clé-valeur qui stockent chaque colonne séparément sur le disque. Une base de données de magasin de colonnes large est un type de base de données de magasin de colonnes qui stocke les familles de colonnes, pas seulement les colonnes uniques. Par exemple, une base de données de recensement peut avoir une famille de colonnes distincte pour chacun des éléments suivants :

    • Prénom, deuxième prénom et nom de famille d’une personne

    • Adresse de cette personne

    • Informations de profil de cette personne, telles que leur date de naissance ou leur sexe

    La base de données peut stocker chaque famille de colonnes dans une partition distincte, tout en associant l’ensemble des données d’une personne à la même clé. Une application peut lire une seule famille de colonnes sans analyser toutes les données d’une entité.

  • Les bases de données graphes stockent des informations sous la forme d’une collection d’objets et de relations. Une base de données de graphiques peut lancer efficacement des requêtes qui parcourent le réseau d’objets et les relations entre eux. Par exemple, les objets peuvent représenter les employés d’une base de données de ressources humaines, et vous pouvez définir des requêtes comme « rechercher tous les employés travaillant directement ou indirectement pour Scott. »

  • Les bases de données de télémétrie et de série temporelle sont une collection d'objets uniquement ajoutable. Les bases de données de télémétrie indexent efficacement les données dans différents stockages en colonnes et structures en mémoire. Cette fonctionnalité leur permet de stocker et d’analyser de grandes quantités de données de télémétrie et de série chronologique.

Fabric prend en charge différents modèles de base de données, notamment les bases de données clé-valeur, document, magasin de colonnes, graphiques et données de télémétrie. Cette flexibilité garantit l’extensibilité d’un large éventail de tâches analytiques. Pour choisir le magasin de données Fabric approprié pour vos charges de travail analytiques, consultez le guide de décision Fabric : choisissez un magasin de données.

Critères de sélection principaux

Pour affiner le processus de sélection, tenez compte des critères suivants :

  • Avez-vous besoin d’un stockage pouvant servir de voie rapide pour vos données ? Si oui, limitez vos options à celles qui sont optimisées pour une couche de service vitesse.

  • Avez-vous besoin d’une prise en charge massive du traitement parallèle, où les requêtes sont automatiquement distribuées entre plusieurs processus ou nœuds ? Si oui, sélectionnez une option prenant en charge le scale-out des requêtes.

  • Vous préférez utiliser un magasin de données relationnelles ? Si vous le faites, limitez vos options à celles qui ont un modèle de base de données relationnelle. Toutefois, certains magasins non relationnels prennent en charge la syntaxe SQL pour l’interrogation, et des outils tels que le point final SQL peuvent être utilisés pour interroger des magasins de données non relationnels tels que OneLake.

  • Collectez-vous des données de série chronologique ? Utilisez-vous des données accessibles uniquement pour ajout ? Fabric OneLake prend en charge plusieurs moteurs analytiques, notamment Analysis Services, T-SQL et Apache Spark. Fabric Eventhouse le rend adapté à divers besoins de traitement et d’interrogation des données de série chronologique.

Matrice des fonctionnalités

Les tableaux suivants résument les principales différences de fonctionnalités de ces services managés.

Fonctionnalités générales

Capacité Fabric Lakehouse Fabric Warehouse Fabric Eventhouse Base de données SQL Fabric Azure SQL Database Base de données Azure Cosmos DB Services d'analyse
Modèle de base de données primaire Lac de données unifié, relationnel, format delta lake géré par l’utilisateur à l’aide d’Apache Parquet Lac de données unifié, relationnel, format Delta Lake géré par le système, utilisant Apache Parquet Magasin de données orienté vers l'ajout de séries chronologiques, graphe, vecteur Relationnel (format de stockage en colonnes lorsque vous utilisez des index de magasin en colonnes) Relationnel (format de stockage en colonnes lorsque vous utilisez des index de magasin en colonnes) Stockage de documents, graphiques, stockage de valeurs clés, stockage de colonnes larges Modèles sémantiques tabulaires
Prise en charge du langage SQL Oui1 Oui Oui2 Oui Oui Oui Non
Optimisé pour la couche de service vitesse Oui Oui Oui3 Oui4 Oui5 Oui Non

[1] T-SQL via un point de terminaison SQL Analytics.

[2] KQL a une prise en charge partielle du langage T-SQL.

[3] Prend en charge l’ingestion en file d’attente et l’ingestion en streaming.

[4] Prend en charge la précision transactionnelle avec un accès à faible latence et des mises à jour en temps réel.

[5] Utilisation de tables optimisées pour la mémoire et d’index de hachage ou non clusterisés.

Capacités d'évolutivité

Capacité Fabric Lakehouse Fabric Warehouse Fabric Eventhouse Base de données SQL Fabric Azure SQL Database Base de données Azure Cosmos DB Services d'analyse
Serveurs régionaux redondants pour assurer une haute disponibilité Oui1,2 Oui1,2 Oui Oui Oui Oui Oui
Prend en charge le scale-out des requêtes Oui3 Oui4 Oui5 Oui Non Oui Oui
Scalabilité dynamique (scale-up) Oui3 Oui4 Oui5 Oui Oui Oui Oui
Prend en charge la mise en cache en mémoire des données Oui6 Oui6 Oui7 Oui Oui Oui Non

[1] Les points de terminaison SQL sont routés via des gestionnaires de trafic globaux, mais les données sont toujours traitées dans la région de capacité fabric affectée.

[2] Lakehouse et Warehouse stockent des données dans OneLake à l’aide du format Delta Parquet, qui prend en charge l’interrogation et la réplication entre les moteurs.

Lakehouse prend en charge le scale-out basé sur Spark pour les données non structurées et structurées.

[4] Warehouse utilise T-SQL et prend en charge les transactions multi-tables, la gestion des charges de travail autonomes et le traitement des requêtes distribuées (DQP). DQP agit comme un gestionnaire de cluster, allouant dynamiquement des ressources de calcul en fonction de la complexité des requêtes.

[5] Eventhouse prend en charge la fédération KQL et SQL, ce qui permet l'analyse en temps réel sur plusieurs sources, ainsi que la mise à l'échelle des ressources informatiques si l’utilisation du cache chaud dépasse ~95%.

[6] Cache intelligent pour les travaux Spark, mise en cache en mémoire, mise en cache du jeu de résultats pour les points de terminaison d’analyse SQL.

[7] Les données fréquemment consultées sont stockées dans un cache chaud qui inclut un stockage SSD et en mémoire.

Fonctionnalités de sécurité

Capacité Fabric Lakehouse Fabric Warehouse Fabric Eventhouse Base de données SQL Fabric Azure SQL Database Base de données Azure Cosmos DB Services d'analyse
Authentification Microsoft Entra ID (système d'identification de Microsoft) Microsoft Entra ID (système d'identification de Microsoft) Microsoft Entra ID (système d'identification de Microsoft) Microsoft Entra ID (système d'identification de Microsoft) SQL ou Microsoft Entra ID Utilisateurs de base de données ou ID Microsoft Entra via le contrôle d’accès (gestion des identités et des accès) Microsoft Entra ID (système d'identification de Microsoft)
Chiffrement des données au repos Oui Oui Oui Oui Oui1 Oui Oui
Sécurité au niveau des lignes Oui Oui Oui Oui Oui Non Oui
Prend en charge les pare-feu Oui2 Oui2 Oui3 Oui Oui Oui Oui
Masquage dynamique des données Oui4 Oui4 Non Oui Oui Non Non

[1] Vous devez utiliser le chiffrement transparent des données pour chiffrer et déchiffrer vos données au repos.

[2] Les liaisons privées et l’accès conditionnel Entra peuvent être utilisés pour restreindre l’accès aux ressources Fabric.

[3] Les charges de travail Fabric Eventhouse et Real-Time Intelligence peuvent ingérer des données à partir de sources sécurisées telles que Kafka, Azure Event Hubs et AMQP, avec le routage via des points de terminaison sécurisés.

[4] Il peut être appliqué au niveau du point de terminaison SQL Fabric

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Auteurs principaux :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes