Choisir un magasin de données analytiques dans Azure
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 :
- Azure Synapse Analytics
- Pools Azure Synapse Spark
- Azure Databricks
- Explorateur de données Azure
- Azure SQL Database
- SQL Server dans les machines virtuelles Azure
- HBase/Phoenix sur HDInsight
- Hive LLAP sur HDInsight
- Azure Analysis Services
- Azure Cosmos DB
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 tel que XML, YAML, JSON ou JSON binaire (BSON), mais elle peut aussi utiliser du 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 le contrôle d'accès (gestion des identités et des 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 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] Lorsqu'il est utilisé au sein d'un réseau virtuel Azure. Pour plus d'informations, voir Étendre Azure 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 :
- Zoiner Tejada | CEO et Architecte
Étapes suivantes
- Analyser les données dans un entrepôt de données relationnelles
- Créer une base de données unique - Azure SQL Database
- Créer un espace de travail Azure Databricks
- créer un cluster Apache Spark dans Azure HDInsight à l’aide du portail Azure
- Création d’un espace de travail Synapse
- Exploration des services de données Azure pour l’analytique moderne
- Explorer les services de base de données et d’analytique dans Azure
- Interroger Azure Cosmos DB à l’aide de l’API pour NoSQL