Choisir un magasin de données analytiques dans Azure

  • Article

Une architecture Big Data nécessite souvent un magasin de données analytique qui fournit les données traitées dans un format structuré qui peut être interrogé à l’aide des outils d’analyse. 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 service est divisée en une couche de service vitesse, qui stocke les données qui ont été traitées de façon incrémentielle, et en une couche de service par lots, contenant la sortie traitée par lots. La couche service requiert une prise en charge des lectures aléatoires à faible latence. Le stockage des données de la couche vitesse doit également prendre en charge les écritures aléatoires, car le chargement par lots des données dans ce magasin entraînerait des délais indésirables. En revanche, le stockage des données de la couche de traitement par lots n’a pas besoin de prendre en charge les écritures aléatoires, mais plutôt les écritures par lots.

Il n’existe pas de choix optimal pour la gestion des données de 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 du monde réel et des processus Big Data dépendent de diverses exigences en matière de stockage de données, et utilisent souvent une combinaison de solutions de stockage de données.

Quelles sont vos options lors du choix d’un magasin de données analytique ?

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

Ces options offrent divers modèles de base de données optimisés pour différents types de tâches :

  • Les bases de données Clé/valeur contiennent un objet sérialisé unique pour chaque valeur de clé. Elles sont parfaites pour le stockage de grands volumes de données lorsque vous souhaitez obtenir un élément pour une valeur de clé donnée et que vous n’avez pas besoin d’interroger les données en fonction d’autres propriétés de l’élément.
  • Les bases de données Document 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 comme XML, YAML, JSON ou BSON, mais également au format texte brut. Les bases de données Document peuvent lancer des requêtes sur des champs non-clés et définir des index secondaires pour améliorer l’efficacité des requêtes. Une base de données Document est ainsi 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é du 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 de stockage de 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 stockage multicolonne est un type de base de données de stockage de colonnes qui stocke des familles de colonnes, pas seulement des colonnes uniques. Par exemple, une base de données de recensement peut contenir une famille de colonnes pour le nom d’une personne (prénom, deuxième prénom et nom), une famille pour l’adresse de la personne, et une famille pour les informations de profil de la personne (date de naissance, 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 famille de colonnes unique sans parcourir toutes les données d’une entité.
  • Les bases de données de graphiques stockent des informations comme une collection d’objets et des 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 chronologique sont une collection d’objets en ajout uniquement. Les bases de données de télémétrie indexent efficacement les données dans divers magasins de colonnes et structures en mémoire, ce qui en fait le choix optimal pour le stockage et l’analyse de vastes quantités de données de télémétrie et de séries chronologiques.

Critères de sélection principaux

Pour restreindre les choix, commencez par répondre aux questions suivantes :

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

  • Avez-vous besoin de la prise en charge de l’architecture Massively Parallel Processing (MPP), où les requêtes sont automatiquement réparties 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 ? Dans ce cas, limitez vos options à celles proposant un modèle de base de données relationnelle. Notez cependant que certains magasins de données non relationnelles prennent en charge la syntaxe SQL pour l’interrogation, et des outils comme PolyBase peuvent servir à interroger des magasins de données non relationnelles.

  • Collectez-vous des données de série chronologique ? Utilisez-vous des données d’ajout uniquement ?

Matrice des fonctionnalités

Les tableaux suivants résument les principales différences entre les fonctionnalités.

Fonctionnalités générales

Fonctionnalité SQL Database Pool SQL Azure Synapse Pool Azure Synapse Spark Explorateur de données Azure HBase/Phoenix sur HDInsight Hive LLAP sur HDInsight Azure Analysis Services Azure Cosmos DB
Est un service géré Oui Oui Oui Oui Oui 1 Oui 1 Oui Oui
Modèle de base de données primaire Relationnel (format en stockage de colonnes lors de l’utilisation des index columnstore) Tables relationnelles avec stockage de colonnes Stockage de colonnes larges Magasin relationnel (stockage de colonnes), télémétrie et série chronologique Stockage de colonnes larges Hive/In-Memory Modèles sémantiques tabulaires Stockage de documents, graphiques, stockage de valeurs clés, stockage de colonnes larges
Prise en charge du langage SQL Oui Oui Oui Oui Oui (à l’aide du pilote JDBC Phoenix) Oui No Oui
Optimisé pour la couche de service vitesse Oui 2 Oui 3 Oui Oui Oui Oui No Oui

[1] Avec mise à l’échelle et configuration manuelles.

[2] Avec un hachage et des tables à mémoire optimisée ou des index non cluster.

[3] Pris en charge en tant que sortie Azure Stream Analytics.

Fonctionnalités d’évolutivité

Fonctionnalité SQL Database Pool SQL Azure Synapse Pool Azure Synapse Spark Explorateur de données Azure HBase/Phoenix sur HDInsight Hive LLAP sur HDInsight Azure Analysis Services Azure Cosmos DB
Serveurs régionaux redondants pour assurer une haute disponibilité Oui No Non Oui Oui No Oui Oui
Prend en charge le scale-out des requêtes Non Oui Oui Oui Oui Oui Oui Oui
Évolutivité dynamique (montée en puissance) Oui Oui Oui Oui No Non Oui Oui
Prend en charge la mise en cache en mémoire des données Oui Oui Oui Oui No Oui Oui Non

Fonctionnalités de sécurité

Fonctionnalité SQL Database Azure Synapse Explorateur de données Azure HBase/Phoenix sur HDInsight Hive LLAP sur HDInsight Azure Analysis Services Azure Cosmos DB
Authentification ID d'entrée SQL/Microsoft ID d'entrée SQL/Microsoft Microsoft Entra ID local/ID Microsoft Entra 1 local/ID Microsoft Entra 1 Microsoft Entra ID utilisateurs de la base de données / Microsoft Entra ID via contrôle d'accès (IAM)
Chiffrement des données au repos Oui 2 Oui 2 Oui Oui 1 Oui 1 Oui Oui
Sécurité au niveau des lignes Oui Oui 3 Oui Oui 1 Oui 1 Oui Non
Prend en charge les pare-feu Oui Oui Oui Oui4 Oui 4 Oui Oui
Masquage dynamique des données Oui Oui Oui Oui 1 Oui No Non

[1] Suppose d’utiliser un cluster HDInsight joint à un domaine.

[2] Nécessite l’utilisation du chiffrement transparent des données (TDE) pour chiffrer et déchiffrer vos données au repos.

[3] Prédicats de filtre uniquement. Consultez la page Sécurité au niveau des lignes

[4] Si utilisé au sein d’un réseau virtuel Azure. Voir Étendre HDInsight à l’aide d’un réseau virtuel Azure.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

Étapes suivantes