Le Guide de l’analyste pour concevoir un entrepôt de données moderne

Vous êtes donc invité à créer un entrepôt de données pour votre entreprise. Un entrepôt de données efficace, évolutif et fiable. Si votre entreprise se lance sérieusement dans la mise en œuvre de rapports de données en tant qu’actif stratégique clé pour votre entreprise, la construction d’un entrepôt de données finira par apparaître dans la conversation.

Mais construire un entrepôt de données n’est ni facile ni trivial. Plus de 50% des projets d’entrepôt de données ont une acceptation limitée ou seront des échecs purs et simples.

Comment devez-vous commencer à concevoir et à construire votre entrepôt de données? Quels sont les pièges et comment l’optimiser ? Plus important encore, par où dois-je commencer?

Cet article fournit un guide de haut niveau sur la façon de penser à la configuration de votre entrepôt de données pour éviter certains pièges courants.

Qu’est-ce qu’un entrepôt de données ?

Une entreprise moderne a généralement des données stockées à différents endroits (sources de données). Il peut s’agir de données provenant de :

• Bases de données d’applications : Pour les startups, il s’agit probablement de leur application produit principale. Pour d’autres entreprises, il peut s’agir de leur application de point de vente,
• Applications Web : Il peut s’agir d’applications nécessaires pour faire évoluer une entreprise ou maintenir ses opérations commerciales. Des exemples pourraient être des logiciels de marketing par courrier électronique comme Mailchimp, des applications d’analyse Web comme Google Analytics ou Mixpanel, ou même des logiciels de comptabilité comme Xero et Quickbooks.Feuilles de calcul : Il peut s’agir de feuilles de calcul de bureau (Excel, CSV) ou de feuilles de calcul en ligne telles que Google Sheets. Ces données peuvent être mises à jour manuellement par quelqu’un, ou mises à jour par une activité Zapier.

Un entrepôt de données synchronise les données de différentes sources en un seul endroit pour tous les besoins de reporting de données.

Il fournit des données fiables et peut gérer la charge de travail d’interrogation de tous les employés de l’entreprise.

Conception d’un entrepôt de données

Lire aussi: Quand devriez-vous obtenir un entrepôt de données?

Voici à quoi ressemble une configuration d’entrepôt de données typique :

Vous concevez et construisez votre entrepôt de données en fonction de vos exigences de reporting. Une fois que vous avez identifié les données dont vous avez besoin, vous concevez les données pour qu’elles circulent dans votre entrepôt de données.

Créez un schéma pour chaque source de données

Créez un schéma de base de données pour chaque source de données que vous souhaitez synchroniser avec votre base de données. Cette

1. Vous aide à identifier rapidement la source de données d’où provient chaque table, ce qui vous aide à mesure que votre nombre de sources de données augmente. Les futurs analystes de données et les membres de l’équipe commerciale qui rejoignent votre entreprise peuvent également apprendre rapidement ce que chaque source de données contient.
2. Vous permet d’attribuer des autorisations spécifiques (lecture/écriture) à chaque source de données. Par exemple, un ingénieur de données peut ne pas vouloir autoriser un analyste junior à lire uniquement, mais pas à écrire dans un schéma spécifique.

Ceci est particulièrement utile lorsque votre nombre de sources de données augmente avec le temps. Il suffit de regarder le nombre de sources dans lesquelles vos données pourraient se trouver.

Par exemple, vous pouvez configurer un schéma appelé mailchimpxero, ou fbads pour les données de marketing par e-mail, de finance et de publicité que vous souhaitez importer de ces applications dans votre entrepôt respectivement.

Lorsque vous importez votre table de contacts de Mailchimp dans votre base de données, vous
pouvez les interroger comme:

SELECT name, email FROM mailchimp.contacts

Comment créer un schéma

Créer un schéma est facile. Il vous suffit de taper une ligne pour créer un nouveau schéma. En fait, ce ne sont que 3 mots dans Postgres.

CREATE SCHEMA 

Exemple :

CREATE SCHEMA mailchimp

Note 1: Les nouveaux analystes peuvent se confondre entre un schéma de base de données. Il existe 2 définitions de schéma. Un schéma peut être utilisé pour décrire soit

1. Comment les tables et les champs d’une base de données sont liés les uns aux autres, soit
2. Un dossier pour les tables de base de données, tout comme la façon dont les dossiers organisent vos fichiers

Note 2: Les bases de données MySQL ne prennent pas en charge le schéma, vous pouvez donc utiliser une convention de nommage pour nommer les tables que vous importez, telles que mailchimp_contacts, etc. C’est l’une des raisons pour lesquelles nous encourageons nos clients à utiliser PostgreSQL pour leur base de données de rapports.

Déplacement des données sources dans votre entrepôt de données

L’étape suivante consiste à synchroniser vos données sources dans votre entrepôt de données. Vos ingénieurs peuvent le savoir comme un script ETL.

Concevez votre script d’importation avec les considérations suivantes :

1. Supprimez les colonnes qui sont évidemment inutiles. Ce n’est pas si difficile pour vous de les ajouter plus tard si vous réalisez que vous en avez besoin.
2. Renommez les noms de colonnes pour les rendre plus descriptifs ou plus conviviaux pour les bases de données (par exemple en utilisant des minuscules ou des casse chameau.
3. Filtrez les enregistrements évidemment inutiles. Cela peut être des enregistrements de vos tests d’utilisateurs internes sur votre système de production (parfois, vos utilisateurs peuvent ajouter des données comme [email protected] ou en définissant leur prénom comme tests)
4. Mappe les valeurs d’enregistrement pour les rendre plus lisibles. Cela évite à vos analystes de les renommer lors du rapport avec des CAS-Fs plus tard). Par exemple, certains enregistrements peuvent stocker des clés numériques (1,2,3, 99, etc.) ou des noms abrégés qui peuvent ne pas être connus du reste de l’organisation. Dans ces cas, vous voudrez peut-être mapper ces clés à leurs valeurs réelles pendant le processus d’importation.
5. Appliquez des index de base de données à votre table de destination une fois l’importation terminée. Notez que nous avons écrit sur les index de base de données dans un article précédent.
6. Gestion des erreurs : e-mails de configuration // Message d’alerte Slack à envoyer aux parties prenantes concernées (en particulier les analystes de données) avec des journaux d’erreurs détaillés lorsque la tâche échoue. Vous pouvez configurer des tentatives de nouvelle tentative automatisées (ou des processus de récupération automatisés) dans un délai spécifique pour réduire le nombre de faux positifs dans ce cas.

Devez-vous transformer vos données source (brutes) ?

Une question qui nous est souvent posée est de savoir comment appliquer des transformations de données avant de déplacer les données vers l’entrepôt.

via GIPHY

Notre conseil général est de ne pas le faire. Du moins pas au début. Surtout s’il s’agit de votre premier projet d’entrepôt de données. Il y a quelques raisons à cela.

a. Il est peu probable que vous ayez des exigences claires sur vos besoins de transformation de données

Même si vous recevez des « exigences claires », il est probable que cette exigence change au cours du projet ou devienne obsolète.

Vous ne voudrez pas passer du temps à réviser votre script ETL en fonction de ce que les différentes parties prenantes souhaitent à différents moments.

Déplacer vos données sources (non transformées) vous aide à séparer la dépendance de votre script ETL des  » exigences métier « .

d. Il est probable que vous ayez besoin des données source pour d’autres cas

Considérez vos données source comme une base d’interaction qui peut être dérivée en plusieurs tables dérivées, soit en les agrégeant selon différentes dimensions, soit en les joignant à des tables provenant d’autres sources.

Voir l’exemple ci-dessous sur la façon de suivre l’efficacité de la conversion du vendeur.

Lors de la transformation de données, vous perdez les détails des données sources qui peuvent être nécessaires pour les futurs cas d’utilisation des rapports.

Par exemple, lorsque vous résumez les revenus des ventes par période, vous perdez les détails des enregistrements de transactions spécifiques qu’un autre utilisateur peut avoir besoin de corréler avec d’autres rapports.

Le déplacement de vos données sources non transformées vous donnera la possibilité de les combiner avec d’autres sources de données.

Le besoin de données source devient plus important lorsque vous commencez à concevoir des modèles de données réutilisables pour répondre à différentes questions. Voir un exemple ci-dessous sur un rapport de cohorte est construit avec une série de données post-transformées. Ce sera plus difficile à faire si vous n’avez pas

c. Réduire la charge sur vos systèmes sources

L’exécution de transformations de données dans le système source peut nécessiter des ressources considérables, en particulier si vous disposez d’une base de données qui dessert les clients du monde entier.

Vous ne voudrez pas le surcharger de tâches de transformation de données de longue durée avant de les déplacer.

Il y a quelques cas qui peuvent avoir du sens pour vous de transformer des données avant de les déplacer, mais ces cas sont généralement pour les entreprises qui ont déjà configuré un entrepôt de données fiable et qui cherchent à l’améliorer davantage.

Transformer des données pour résoudre un problème spécifique

Réfléchir à la façon de transformer des données peut être complexe. Si cette option n’est pas cochée, vous risquez de passer beaucoup de temps à optimiser des données qui n’apportent pas de valeur à l’entreprise.

Planifier, concevoir et mettre en œuvre des transformations de données sans résultat clair est une solution à la recherche d’un problème.

Une bonne règle de base est de commencer par la fin en tête. Les transformations de données ne doivent être créées que pour résoudre un cas d’utilisation ou un problème pratique de vos rapports.

Un bon moyen de trouver (et de hiérarchiser) ces cas d’utilisation pratiques est de commencer à créer les rapports et les tableaux de bord avec les données que vous avez importées.

Lorsque vos utilisateurs commencent à soulever des problèmes de performances de requête, vous pouvez alors envisager de transformer les données.

Cela peut être causé par des rapports qui
(a) Contiennent des sous-requêtes imbriquées ou des expressions de table personnalisées (CTE)

(b) Ou qui ont plusieurs jointures (coûteuses) sur plusieurs tables.

C’est là que la flexibilité des rapports basés sur SQL est utile pour aider à identifier les problèmes que la transformation des données peut résoudre.

Il est facile pour tout analyste d’identifier rapidement la cause première des rapports avec des requêtes de longue durée et de les initier pour optimiser leurs performances.

Cela se fait en grande partie en pré-agrégeant automatiquement les données. Cela peut être fait avec des vues matérialisées où vous pouvez créer des tâches de transformation de données qui :

1. Agrégent de grandes tables de transactions pour accélérer les performances des requêtes.
2. Créer des tables dérivées avec des colonnes provenant de différentes sources de données
3. Remplacer/masquer des données sensibles pour des groupes d’utilisateurs sélectionnés.

Une autre recommandation consiste à créer un nouveau schéma de base de données dans votre entrepôt de données pour stocker vos tables transformées (ou post-traitées).

Comme l’approche précédente consistant à séparer chaque source de données par schémas, la création d’un schéma spécifique peut vous aider à identifier la liste des tables de données dérivées/transformées. Cela sera utile plus tard lorsque vous commencerez à enchaîner une série d’importations de données, les données transforment les tâches en séquence à mesure que la maturité de vos données augmente.

Créez vos documents de données internes

Ceci est important, surtout si vous ne voulez pas que votre entrepôt de données soit une boîte noire où seuls quelques ingénieurs comprennent comment l’utiliser. Si vos utilisateurs ne le comprennent pas, ils ne seront pas sûrs de l’interroger.

Vous pouvez commencer par créer un document partagé (peut être Google Doc) qui décrit une compréhension commune de:

• Tables et colonnes dans vos données source, et comment les interpréter
• Diagramme de données d’inclusion le cas échéant.
• Comment lire vos colonnes dans vos rapports (tableau de bord, métriques) et toutes les hypothèses sous-jacentes qui les sous-tendent

Chaque fois qu’un rapport est créé (ou mis à jour), mettez à jour ce document pour refléter tout nouveau niveau de compréhension métier de vos données.

Nous partagerons plus de détails sur la façon de créer et de structurer ce document de données interne dans un article séparé, alors faites attention à cet espace!

C’est tout!

Nous espérons que ce guide a été utile! Dites-nous comment nous pouvons vous aider à construire un entrepôt de données fiable.