Choisir un magasin de données analytiques dans Azure

L’architecture big data a souvent besoin d’un magasin de données analytique qui sert les données traitées dans un format structuré. Vous pouvez interroger ces données à l’aide d’outils analytiques. Les magasins de données analytiques prenant en charge l’interrogation des données provenant d’un chemin relatif et d’un chemin à froid sont collectivement appelés couche service ou stockage de service des données.

La couche service gère les données traitées à partir du chemin réactif 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.

Bien que la couche de service globale nécessite une prise en charge forte des lectures aléatoires qui ont une faible latence, le stockage des données pour la couche vitesse doit également prendre en charge les écritures aléatoires, car le chargement par lots de données dans ce magasin introduit des retards indésirables. À l’inverse, le stockage de données pour la couche batch doit prendre en charge les écritures par lots, et non les écritures aléatoires.

Aucune solution de gestion des données unique ne correspond à chaque tâche de stockage de données. Différentes solutions sont optimales pour des tâches spécifiques. 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.

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

Microsoft offre plusieurs options pour le stockage de services de données, en fonction de vos besoins :

Différents modèles de base de données correspondent à différents types de tâches :

  • Les bases de données clé-valeur contiennent un objet sérialisé unique associé à chaque clé. Ils peuvent gérer 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 documentaires 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. Le magasin 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 magasins de données de document 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 interroger des champs tels que l’ID de produit, l’ID client ou le nom du client.

  • Les magasins de données de famille de colonnes sont des magasins de données clé-valeur qui conservent chaque colonne séparément sur le disque. Un magasin de colonnes large 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 attributs d’un individu :

    • Prénom, milieu et nom
    • Adresse postale
    • Informations de profil, telles que la date de naissance ou le sexe

    Le magasin de données peut stocker chaque famille de colonnes dans une partition distincte, tout en conservant toutes les données d’une personne associée à la même clé. Une application peut lire une seule famille de colonnes sans analyser toutes les données d’une entité.

  • Les magasins de données Graph contiennent des informations sous la forme d’une collection d’objets et de relations. Un magasin de données de graphe peut effectuer 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 bon magasin de données Fabric pour vos charges de travail analytiques, consultez Fabric guide de décision : 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, choisissez des options optimales pour une couche de diffusion rapide.

  • 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, choisissez des options qui ont un modèle de base de données relationnelle. Toutefois, certains magasins de données non relationnels prennent en charge la syntaxe SQL pour les requêtes, et vous pouvez utiliser des outils tels que des points de terminaison d’analyse SQL pour interroger des magasins de données non relationnels comme OneLake.

  • Collectez-vous des données de série chronologique ? Utilisez-vous des données accessibles uniquement pour ajout ? OneLake prend en charge plusieurs moteurs analytiques, notamment Analysis Services, T-SQL et Apache Spark. Eventhouse convient parfaitement à divers besoins en matière 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 entre ces services managés.

Fonctionnalités générales

Capacité Lakehouse Entrepôt de données 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 utilisant Apache Parquet Lac de données unifié, relationnel, format Delta Lake géré par le système utilisant Apache Parquet Base de données de séries temporelles orientée magasin de données, graphe, vecteur Relationnel (format en stockage de colonnes lors de l’utilisation des index columnstore) Relationnel (format en stockage de colonnes lors de l’utilisation des index columnstore) 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 d’analytique SQL.

[2] Le langage de requête Kusto (KQL) prend en charge partiellement le 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] En utilisant des tables à mémoire optimisée et des index de hachage ou non clusterisés.

Capacités d'évolutivité

Capacité Lakehouse Entrepôt de données 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

Les points de terminaison SQL transitent via des gestionnaires de trafic mondiaux, mais c’est toujours la région de capacité Fabric attribuée qui traite les données.

[2] Lakehouse et Warehouse stockent les données dans OneLake au 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 multitables, 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 pour l’analytique en temps réel entre plusieurs sources et pour augmenter les ressources de calcul lorsque 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é Lakehouse Entrepôt de données 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 la base de données ou Microsoft Entra ID via le contrôle d'accès (gestion des identités et des accès (IAM)) 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] Exige que vous utilisiez le chiffrement transparent des données pour chiffrer et déchiffrer vos données au repos.

[2] Utilisez des liaisons privées et des Accès conditionnel Microsoft Entra 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] Appliquez-le au niveau du point de terminaison SQL de Fabric.

Contributeurs

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

Auteur principal :

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

Étapes suivantes

  • Last updated on