Guide rapide pour comprendre les différents types de bases de données et les modèles d’architecture de données communes | de Hanson Chiu | avril 2022

Photo de Kevin Ku sur Unsplash

Je travaille sur des travaux et des projets liés aux données depuis plus de 6 ans. Avec le développement des technologies de données (également les mots à la mode surtout avec différentes couches de données), de plus en plus de confusion et de malentendus surviennent, ce qui complique la communication technique.

Cette histoire vise à clarifier divers concepts de données de manière simple avec des diagrammes à l’appui pour illustrer le modèle d’architecture de données de haut niveau.

Si on me demande de classer les 3 principaux termes de données trompeurs, je dois voter pour ces trois que même certains praticiens des données de nombreuses années ne peuvent pas distinguer.

Base de données — Il s’agit du terme le plus général utilisé pour décrire le stockage de la collection organisée de données stockées. Lorsque les gens comparent la base de données à l’entrepôt de données, la base de données fait généralement référence à cela “base de données opérationnelle” le 1) stockage de données backend pour les applications, 2) pour le traitement des transactions et 3) la structure de données relationnelle plate.

L’architecture des données de la base de données opérationnelle est relativement simple et directement liée à l’application.

Architecture de données de haut niveau pour les bases de données opérationnelles

entrepôt de données — un stockage de données central qui intègre diverses données transactionnelles avec des données historiques provenant de bases de données opérationnelles / systèmes sources pour objectif de l’analyse (par exemple, science des données, BI)

L’architecture de données pour l’entrepôt de données est le niveau suivant de celle de la base de données opérationnelle, qui consolide les données de différentes bases de données opérationnelles et effectue la transformation/le calcul par ETL. Il y a un espace scénique pour récupérer les fichiers sources des bases de données/systèmes sources opérationnels avant qu’ils ne soient inclus dans l’entrepôt de données.

la Marché des données Le concept est également introduit avec l’entrepôt de données. Différents marts sont conçus et construits à des fins différentes avec une transformation/calcul régulier par ETL au sein d’un seul entrepôt de données. Ces sous-ensembles sont souvent un segment distinct d’une entreprise (comme les ventes, la finance ou le marketing). Autrement dit, Un entrepôt de données peut contenir plusieurs magasins de données.

Architecture de données de haut niveau pour l’entrepôt de données

lac de données– Contrairement à une base de données, le lac de données n’est pas dans un moteur/structure de système de base de données, mais dans un lieu qui contient une grande quantité de données brutes dans son format natif (qui peut être image, mp3, json, csv sous forme structurée, semi-structurée, non structurée).

L’architecture de données pour Data Lake est l’évolution de l’entrepôt de données qui étend encore la zone de staging pour collecter et stocker les fichiers bruts (en données semi-structurées/non structurées) de différentes sources dans une zone d’atterrissage consolidée avant de les charger dans l’entrepôt de données volonté.

Architecture de données de haut niveau pour le lac de données

Maison du lac de données — Il s’agit d’un nouveau concept d’architecture de données combiner des éléments de Entrepôt de données avec ceux du lac de données. Avec les technologies modernes, divers citoyens de données (y compris des scientifiques de données, des ingénieurs de données, des analystes commerciaux, des développeurs BI) pourraient utiliser le stockage de données centralisé pour diverses activités d’analyse.

Nous approfondirons la conception de Data Lakehouse dans une autre histoire avec une comparaison avec diverses architectures de données populaires.

Lorsque les gens prennent des décisions concernant la base de données, ils établissent des liens vers OLAP (“Online Analytical Processing”) et OLTP (“Online Transaction Processing”). Il est utilisé pour définir l’objectif du système, puis pour comprendre l’utilisation et la nécessité de la base de données sous-jacente.

OLTP contre OLAP

OLAP — Les applications OLAP sont conçues à des fins d’analyse pour la prise de décision. Ces applications pourraient être des applications d’apprentissage automatique/IA et d’informatique décisionnelle pour la visualisation de données.

L’entrepôt de données (avec data marts) est généralement la base de données principale que les applications OLAP doivent utiliser. cube de données est également une forme populaire de base de données d’application OLAP qui pré-calcule l’agrégation/le cumul pour augmenter l’efficacité de l’analyse.

OLTP — Les applications OLTP permettent d’exécuter des transactions en temps réel par un grand nombre d’utilisateurs. Ces applications opérationnelles pourraient être des systèmes de transactions bancaires (par exemple, des distributeurs automatiques de billets), des systèmes de réservation/réservation d’hôtel.

Les bases de données opérationnelles sont généralement conçues pour les applications OLTP avec une structure de base de données relationnelle plate/simple

SGBD (“Système de gestion de base de données”) – c’est logiciels pour le stockage, la récupération et l’exécution d’interrogations de données.. Il reçoit une interface utilisateur pour interagir avec la base de données (par exemple, créer, lire, mettre à jour et supprimer des données dans la base de données). Quelques exemples sont MySQL, PostgreSQL, Microsoft Access, SQL Server, FileMaker, Oracle, RDBMS, dBASE.

En règle générale, ces SGBD ne prennent en charge que les ensembles de données plats sans afficher les relations entre les données.

SGBDR (“Système de gestion de base de données relationnelle”)— Il s’agit d’un type de système de gestion de base de données (SGBD) qui stocke les données dans une structure de table basée sur des lignes qui relie les éléments de données associés pour former une base de données relationnelle.

En d’autres termes, les utilisateurs peuvent définir la relation à l’aide de clés primaires, de clés étrangères avec contrôles d’intégrité et de propriétés ACID.

Quelques exemples de systèmes spécifiques utilisant RDBMS incluent IBM, Oracle, MySQL, Microsoft SQL Server et PostgreSQL.

En tant que spécialiste des données, il est important de comprendre les différentes solutions de données, leur nature et leur utilisation pour vous aider à choisir le meilleur stockage de données backend pour différents cas d’utilisation commerciale.

Il pourrait y avoir des conséquences désastreuses si une mauvaise solution est choisie et mise en œuvre. Les écarts de performance, d’efficacité et de coût peuvent entraîner de réelles pertes pour les organisations.

Dans la prochaine histoire, nous approfondirons la conception de l’architecture de données moderne dans Data Lakehouse et comparerons les avantages et les inconvénients de l’architecture de données traditionnelle. Restez à l’écoute.

Leave a Comment