Blogs

Accueil / Blogs / Aperçus privilégiés sur le développement d'entrepôts de données modernes avec James Serra

Table des matières
L'automatisé, Pas de code Pile de données

Apprener comment Astera Data Stack peut simplifier et rationaliser la gestion des données de votre entreprise.

Perspectives d'initiés sur le développement d'entrepôts de données modernes avec James Serra

19 octobre 2022

Avec la lancement officiel de notre solution d'entreposage de données de bout en bout Astera DW Builder, nous avons introduit un chemin beaucoup plus rapide et plus agile pour concevoir et déployer des entrepôts de données. Mais ce n'est que le début, nous prévoyons des ajouts et des mises à jour majeurs au produit au cours de la prochaine année qui ajouteront une valeur unique à toute organisation cherchant à contourner les problèmes liés au développement d'entrepôts de données traditionnels.

Pour notre troisième entretien de cette série, nous avons décidé de nous asseoir avec quelqu'un qui a construit sa carrière en étant capable d'identifier, d'anticiper et de résoudre avec succès ces défis tout en menant des projets d'entreposage de données pour Microsoft et actuellement, Ernst & Young. En tant que l'un des principaux leaders d'opinion dans ce domaine, James Serra a abordé un éventail de sujets allant de la BI et des architectures de données aux mégadonnées et à l'analyse dans son populaire article et lors de conférences à travers le monde.

Dans cette interview, nous avons parlé à James de certaines des idées qu'il a acquises au cours de son passage dans l'industrie, de l'évolution des architectures de données à l'ère du big data et de ce à quoi pourrait ressembler l'avenir de l'entrepôt de données.

 

Pouvez-vous me parler un peu de votre implication dans le data warehousing ? Quand avez-vous commencé à travailler dans cet espace et quel genre de rôles avez-vous joué dans le processus de développement au fil des ans ? 

J'ai commencé il y a de nombreuses années avec des bases de données dans les années 80. L'accent initial était mis sur Microsoft SQL Server, d'abord SQL Server 1.0 puis OS 2.0 en 1989, je pense. Il s'agissait donc de bases de données plus transactionnelles avec de nombreuses mises à jour, insertions et suppressions.

Il y a peut-être 20 ans, je me suis impliqué pour la première fois dans l'entreposage de données. Je travaillais en tant que DBA dans une entreprise et ils étaient chargés de créer un entrepôt de données. À l'époque, je connaissais très peu la technologie, mais l'entrepôt de données était basé sur SQL Server, je me suis donc impliqué dans le processus. Ce fut l'une de mes premières expériences dans la création d'un véritable entrepôt de données, c'est-à-dire en extrayant des données de toutes ces différentes sources et en créant des rapports BI en plus de cela.

Depuis lors, j'ai eu de nombreux emplois différents - j'étais consultant travaillant sur de nombreux types de bases de données toujours dans le domaine Microsoft, à partir de SQL Server, puis Azure est arrivé, puis il y avait SQL Database, SQL Data Warehouse, et maintenant Synapse qui est ce que j'ai utilisé à peu près exclusivement au cours des dernières années.

 

De toute évidence, vous avez une vaste expérience dans la construction d'architectures de données à la fois avec Microsoft et maintenant chez EY. Selon vous, quels sont les cas d'utilisation les plus courants pour l'entreposage de données ? En d'autres termes, pourquoi ces entreprises veulent-elles construire un entrepôt de données ?

Les entreprises veulent avant tout prendre de meilleures décisions commerciales. Pour ce faire, ils doivent disposer de toutes les données possibles. Ainsi, au lieu d'essayer d'accéder individuellement à chacune de leurs bases de données opérationnelles et de créer des rapports, ils peuvent obtenir plus de valeur s'ils rassemblent toutes ces données.  

Par exemple, disons qu'ils ont des informations client stockées dans un système CRM, puis qu'ils ont des informations de support client stockées séparément dans un autre système, encore une autre plate-forme pour gérer les informations de vente et un système ERP qui contient également des informations client. Ils ont toutes ces données stockées séparément et, bien sûr, ils veulent les collecter et les utiliser pour identifier les tendances historiques afin qu'ils puissent trouver des raisons pour lesquelles les clients n'achètent pas dans certaines régions du pays. Avec un entrepôt de données, ils peuvent entrer, creuser plus profondément et découvrir ce qui se passe.

Plus récemment, il ne s'agit pas seulement de tendances historiques, mais aussi de regarder vers l'avenir, c'est là qu'interviennent l'IA et l'apprentissage automatique. Aujourd'hui, les entreprises ne veulent pas seulement voir où elles ont été, mais aussi où elles vont , c'est pourquoi l'analyse prédictive devient une chose importante. Donc, si nous prenons ces informations client plus tôt et disons que nous voulons les utiliser, prédisons les chances qu'un client parte. Un modèle d'apprentissage automatique pourrait être en mesure d'estimer 70 % de chances que le client parte en fonction de toutes les données collectées. Alors maintenant, vous, en tant que décideur, pouvez prendre des mesures proactives et faire quelque chose pour éviter cela, comme leur envoyer un coupon pour garantir leur fidélité.  

Fondamentalement, c'est vraiment la collecte de toutes ces données qui permet à l'utilisateur final/à l'analyste de générer des rapports, puis de découper et de découper les sorties pour permettre ces meilleures décisions commerciales.

 

Ainsi, nous avons évidemment constaté une augmentation assez significative du volume et de la variété des données transitant par les entreprises au cours de la dernière décennie. Comment voyez-vous évoluer l'entrepôt de données dit traditionnel pour répondre à ces exigences ?

Donc, tout d'abord, je définirais le big data non seulement comme la taille des données, mais aussi comme le type et la vitesse des données. Tant de clients avec lesquels j'ai travaillé gèrent des téraoctets de données qu'ils essaient de consommer. Mais ils ont également le défi de traiter des données dans toutes sortes de formats, y compris Parquet, CSV, JSON, ainsi que des données qu'ils peuvent vouloir consommer en temps réel à partir de flux de médias sociaux comme Twitter, ils peuvent également vouloir extraire des données IoT. là-dedans.

Alors maintenant, vous avez le défi de tous les types et tailles de données à trois vitesses. Alors que des systèmes sont apparus au cours de la dernière demi-douzaine d'années et peuvent gérer le Big Data comme Azure Synapse sur la plate-forme Microsoft, par exemple, il existe encore un certain nombre d'autres outils nécessaires pour créer un entrepôt de données moderne. Ces outils gèrent la variété, le volume et la taille des données. De nos jours, ils peuvent gérer n'importe quelle combinaison de données, les extraire, les ajuster, les nettoyer et les maîtriser avant de générer des rapports.

 

Quelle est votre opinion sur le lac de données? A-t-il sa place dans le système BI moderne? Complète-t-il l'entrepôt de données ou s'agit-il d'une alternative viable?

Ils sont définitivement complémentaires. Lorsque les lacs de données ont été utilisés pour la première fois il y a une dizaine d'années, ils étaient sur Hadoop et l'idée derrière eux était que nous ne pouvions pas capturer efficacement le Big Data en raison de sa taille, les données semi-structurées ou non relationnelles ne l'étaient pas non plus. vraiment bien dans une base de données relationnelle. Nous avons donc décidé de le mettre dans le lac de données et de l'interroger là-dedans. C'est devenu la zone d'atterrissage pour tous les types de données non relationnelles, tandis que les données relationnelles étaient toujours stockées dans une base de données.

Bien entendu, la plupart des organisations souhaitent combiner les deux types de données, de sorte que les données non relationnelles/semi-structurées du lac de données devraient être déplacées vers la base de données. Bien que, très tôt, il y ait eu des tentatives pour tout mettre dans le lac de données, ce qui a conduit à une variété de problèmes.

La conséquence de cela est que nous avons réalisé que nous aurions toujours besoin d'une base de données relationnelle. Au fil du temps, cette réflexion a évolué, et nous comprenons maintenant qu'il faut avoir un lac de données à côté de la base de données relationnelle et que chacun a ses propres forces.

Nous pouvons considérer un lac de données comme étant capable de gérer des données quelle que soit leur taille ou leur type, mais il a certaines limites. Le lac de données n'est pas bon pour les requêtes extrêmement rapides, il n'est pas idéal pour les types de sécurité que vous souhaitez peut-être pour votre architecture de données - comme la sécurité de bas niveau ou la sécurité au niveau des colonnes, il peut également être plus difficile pour votre fin moyenne. l'utilisateur d'interroger des données se trouvant dans un lac de données parce qu'il s'agit d'un schéma en lecture, ce qui signifie que c'est juste un dossier de fichiers glorifié, vous pouvez y mettre n'importe quel type de données et cela peut rendre difficile d'essayer de le retirer si vous ne le faites pas t avoir les compétences techniques nécessaires. C'est là qu'une base de données relationnelle entre en jeu parce que quelqu'un dans l'informatique fera le travail pour mettre les données avec les métadonnées, il devient donc beaucoup plus facile pour un utilisateur final de les interroger. Ainsi, si vous passez d'un lac de données à une base de données relationnelle et de 3NF à un schéma en étoile, les utilisateurs finaux peuvent désormais facilement effectuer une BI en libre-service, car ils peuvent simplement faire glisser des champs de la base de données et créer des rapports ou des requêtes à partir de cela.

Désormais, des outils comme Azure Synapse sont apparus et ont rendu beaucoup plus facile l'interrogation de données, que ce soit dans un lac de données ou une base de données relationnelle avec SQL standard, et ils ont tous deux leurs avantages et leurs inconvénients. En fin de compte, cependant, l'idée est de prendre des données de toutes ces sources, de les déplacer et de faire un travail pour les préparer, ce qui peut impliquer des coûts supplémentaires, mais à la fin, vous obtiendrez des données formatées de manière beaucoup plus facile pour la plupart des utilisateurs finaux. Pendant ce temps, vous pouvez toujours avoir le lac de données que les scientifiques des données et les utilisateurs expérimentés peuvent interroger, mais pour la plupart des utilisateurs, vous voudrez disposer d'une base de données relationnelle.  

 

Quel serait selon vous l'aspect le plus critique du développement d'un entrepôt de données ? Est-ce que la modélisation des données? Chargement des données dans l'entrepôt de données ? Vous assurer que l'entrepôt de données est accessible à vos plateformes de BI ?

Tous ces aspects sont extrêmement importants, mais la gouvernance des données est vraiment le fil conducteur tout au long de la construction d'un entrepôt de données. Il s'agit de s'assurer que les données sont exactes, correctes et constituent une source unique de vérité pour l'organisation. Parce que la pire chose qui puisse arriver est que vous fassiez tout ce travail pour créer un entrepôt de données et générer un rapport, puis la première fois qu'un utilisateur final le voit, il dit que les données ne sont pas exactes ou incorrectes. Tout de suite, vous avez perdu leur confiance dans le système. Donc, vous devez vraiment vous assurer dès le départ que les données sont correctement gérées. Cela signifie qu'il faut le nettoyer et le maîtriser correctement et toutes ces choses qui vont de pair avec la gouvernance des données.

La sécurité est presque aussi importante, sinon plus. De nos jours, il y a tellement d'informations d'identification personnelle qui pourraient atterrir dans un entrepôt de données, et si vous n'y avez pas le bon type de sécurité, les gens pourraient commencer à voir des données qu'ils ne devraient pas voir. Il peut s'agir d'informations personnelles, de chiffres de vente ou d'autres éléments susceptibles de vous causer beaucoup de problèmes, en particulier si ces données sont extraites de l'extérieur de votre entreprise. Vous êtes maintenant à la une du Wall Street Journal avec une brèche. C'est donc l'autre élément important, c'est la sécurité. Je dirais donc que ces deux-là devraient être une priorité lors de la création d'un entrepôt de données.

Ces dernières années, de gros efforts ont été déployés pour commencer à déplacer les entrepôts de données vers le cloud sur des plateformes telles qu'Azure Synapse, Google BigQuery ou Amazon Redshift. Que pensez-vous des avantages du déploiement cloud ? Recommanderiez-vous toujours de vous en tenir aux bases de données sur site dans certains cas ?

J'ai du mal à voir une solution qui devrait être sur site, il y a juste de très rares cas où cela est plus une solution viable. C'était le cas, chez Microsoft par exemple, lorsque j'ai rejoint pour la première fois il y a 7 ans, où j'avais beaucoup de conversations sur le cloud par rapport au sur site, mais depuis quelques années, il est extrêmement rare que quelqu'un veuille parler de ce dernier. comme une option possible.

Les rares exceptions sont si l'entreprise se trouve dans un endroit qui n'a pas accès à Internet, comme par exemple une mine ou une plate-forme en mer. Ou s'ils traitent des données qui nécessitent des temps de réponse en millisecondes lorsqu'il s'agit de requêtes et de choses comme ça, car il pourrait y avoir un peu de latence dans le cloud. Mais en dehors de cela, tout le monde a, est ou va dans le Cloud pour de nombreuses raisons dont je pourrais passer une demi-heure à parler.

Il est important de noter que le coût n'est pas toujours au premier plan de ce mouvement, c'est d'autres choses comme avoir les dernières fonctionnalités d'un produit, ou probablement le plus grand avantage qui est la capacité de commencer à travailler rapidement. Avec un entrepôt de données cloud, je peux accéder à Azure, par exemple, et avoir une base de données prête en quelques minutes, alors qu'avec sur site, cela peut prendre des jours, voire des semaines, voire des mois pour obtenir une base de données sur un serveur. Donc, je ne me souviens pas de la dernière fois que j'ai rencontré un client que j'ai également recommandé sur site. Bien sûr, il peut y avoir quelques cas d'utilisation comme je l'ai mentionné ci-dessus, mais ceux-ci sont rares.

 

Donc, je vous ai vu écrire pas mal de choses sur l'ETL inversé ces dernières années. Si vous pouviez simplement résumer le concept et parler un peu des avantages que cette approche apporte selon vous ?

Oui, c'est un tout nouveau concept. Ainsi, certaines entreprises peuvent avoir des données clients dans une douzaine de systèmes sources différents, surtout s'il s'agit d'une grande entreprise. Supposons qu'ils extraient toutes ces données client, les nettoient et les maîtrisent (c'est-à-dire en créant des enregistrements d'or), car il pourrait y avoir plusieurs copies du client avec des orthographes différentes. Ils pourraient également compléter les données client d'un système avec différents types de données provenant d'autres systèmes, par exemple en prenant les données client d'un système CRM et en ajoutant des informations sur les tickets d'assistance des clients.

Supposons donc que toutes ces données se trouvent maintenant dans l'entrepôt de données et que j'ai fait tout ce travail pour créer une vue unifiée du client. Eh bien maintenant, le problème est que le nettoyage a été effectué au niveau de l'entrepôt de données, mais les systèmes sources d'où proviennent les données ne sont toujours pas nettoyés. Avec l'ETL inversé, l'idée est que je peux maintenant rediriger les données de l'entrepôt de données dans le système source et corriger ces enregistrements clients. C'est l'une des raisons pour lesquelles je vois l'ETL inversé devenir quelque chose de populaire parce que vous faites tout ce travail dans l'entrepôt de données que vous pouvez ensuite appliquer aux systèmes sources pour les corriger.

L'autre grand avantage de l'ETL inversé est que si je tire toutes ces données dans un entrepôt de données et que je crée des rapports BI à ce sujet et que je dis que c'est un vue client, eh bien, j'ai peut-être beaucoup de vendeurs qui sont habitués à ces autres systèmes d'exploitation, c'est-à-dire un système CRM où ils consultent déjà les données des clients et qu'ils aiment déjà utiliser. Maintenant, vous leur demandez d'aller dans un entrepôt de données et d'utiliser un système différent, un rapport différent, pour examiner ces mêmes clients. Alors, pourquoi ne pas inverser l'ETL et prendre ces données de l'entrepôt de données et les copier dans le système opérationnel. Les analystes peuvent ensuite utiliser les données du système avec lequel ils sont le plus à l'aise. Ainsi, ils n'ont pas à entrer dans l'entrepôt de données.

C'est un autre domaine où je vois l'ETL inversé être très populaire. Faites le travail dans un entrepôt de données, puis déposez les données dans un système opérationnel où les utilisateurs finaux sont le plus à l'aise.

 

Si vous recherchiez une solution d'entreposage de données pour un client, quelles seraient certaines des fonctionnalités clés que vous voudriez qu'il possède ?

J'ai utilisé un certain nombre d'outils d'automatisation d'entrepôt de données au fil des ans avec différents niveaux de succès. Certains d'entre eux ont été très utiles, mais ceux que je trouve les plus efficaces sont ceux qui ne sont pas trop propriétaires et peuvent fournir une automatisation qui accélère la création de solutions, c'est là qu'elles peuvent être extrêmement précieuses.

Lorsque vous évaluez la question Build vs Buy de savoir s'il faut démarrer des projets complètement à partir de zéro, je recommande toujours de rechercher d'abord quelque chose qui a déjà été construit et de voir si cela vous aidera. Maintenant, cela pourrait être un modèle de données commun ou un outil d'automatisation d'entrepôt de données qui construira rapidement l'entrepôt de données pour vous. Si la solution peut le faire en utilisant une technologie courante, c'est-à-dire si cet outil d'automatisation crée un entrepôt de données pour vous, pourriez-vous toujours utiliser l'entrepôt de données sans être obligé d'utiliser l'outil tiers, alors vous êtes sur la bonne voie.

Par exemple, la solution d'automatisation de l'entrepôt de données peut s'interfacer avec un logiciel ETL particulier pour créer des pipelines et après avoir créé ces pipelines, vous pouvez les mettre à jour vous-même sans passer par l'outil DWA. Maintenant, disons qu'il utilise un produit Microsoft pour cette tâche, l'outil DWA peut ne pas suivre les mises à jour du produit ETL, alors disons que le logiciel obtient de nouvelles fonctionnalités, puis l'outil d'entreposage de données peut prendre un certain temps pour tirer parti de ces fonctionnalités qui bien sûr limite la fonctionnalité de votre solution. Il y a aussi la question des compétences, si vous utilisez un outil d'automatisation d'entrepôt de données dans votre entreprise, vous devrez peut-être embaucher des personnes qui ont déjà cette expérience des outils tiers afin de faire avancer le projet.

Dans l'ensemble, je pense que les outils DWA sont particulièrement utiles pour les entreprises qui débutent dans l'entreposage de données et n'ont pas les meilleures pratiques ou normes là-dedans et elles n'ont pas non plus une grande équipe pour créer leur propre configuration. Ils peuvent obtenir des résultats rapides et raccourcir le processus en utilisant un outil prêt à l'emploi pour accélérer le développement.

 

Que pensez-vous du concept de l'entrepôt de données agile ? Fondamentalement, cette idée que l'entreposage de données est un processus, pas un objectif final et que l'itération est à peu près au cœur de tout système de BI efficace ?

Quand j'étais chez Microsoft, les clients voyaient généralement cela comme une technologie, les personnes et les processus étaient quelque chose qu'ils cherchaient à gérer eux-mêmes. Bien sûr, il est important d'avoir tous ces éléments en place. Que nous parlions de créer un centre d'excellence pour la gouvernance des données, ou que nous parlions de DataOps. Parce que la construction d'une application est très différente de la construction d'un entrepôt de données, c'est pourquoi je fais la distinction entre DevOps et DataOps.

Dans un entrepôt de données, vous avez affaire à tellement de systèmes. Tu pourrais être mise à jour d'un modèle dans un entrepôt de données, à un pipeline ETL, au reporting. Donc, toutes ces choses doivent être coordonnées et c'est là que DataOps entre en jeu et c'est extrêmement important. Je vois beaucoup d'entreprises, et EY en fait partie en particulier, qui ont construit ce gigantesque entrepôt de données et elles doivent suivre un processus de type DataOps afin de s'assurer que le produit est utilisé à la fois en interne et en dehors de l'entreprise. , également qu'il ne se brise pas chaque fois qu'une nouvelle fonctionnalité ou une correction de bogue y est ajoutée.

Ainsi, les personnes et les processus sont parfois la partie la plus difficile alors que la technologie peut être relativement facile. Vous devez donc vous assurer de mettre tous ces éléments en place pour vous assurer que la solution finale est aussi exempte de bugs que possible et fournir, comme je l'ai déjà mentionné, l'exactitude des données.

Enfin, où voyez-vous l'entrepôt de données se diriger à l'avenir ? Quelles avancées majeures (le cas échéant) envisagez-vous dans cet espace ?

Eh bien, en ce qui concerne cela – je pense qu'il va y avoir un accent beaucoup plus important sur l'IA et la partie apprentissage machine en particulier. Le défi lorsque vous construisez un entrepôt de données est de collecter des données, de les nettoyer, puis de les placer quelque part, qu'il s'agisse d'un lac de données ou d'une base de données relationnelle. Pour les clients, la collecte de toutes ces données peut prendre des mois, voire des années. Et la cerise sur le gâteau devient le rapport de cela, où vous utilisez quelque chose comme PowerBI pour trancher et découper des ensembles de données. À l'heure actuelle, c'est là que se trouvent encore beaucoup de clients, en train de collecter leurs données.

La plupart des travaux dans cet espace suivent une approche hybride, car de nombreuses entreprises ont des sources de données dans le cloud, mais de nombreux systèmes sont encore sur site et doivent tous les intégrer dans le cloud, ce qui a ses propres défis. . Une fois que vous avez collecté toutes les données, vous pouvez en faire rapport et obtenir des solutions assez rapidement.

L'étape suivante consiste à faire du machine learning et à créer des modèles pouvant être entraînés à l'aide des données du cloud. Beaucoup de clients ne sont pas encore là, ils sont encore au stade de la collecte en essayant d'obtenir des données dans l'entrepôt de données. Ainsi, la grande poussée sera, les clients verront les avantages des modèles ML dans la création d'analyses prédictives pour des choses comme le taux de désabonnement des clients ou lorsqu'une pièce va tomber en panne (les données des appareils IoT sont devenues très populaires pour ce type de maintenance prédictive). Mais encore une fois, c'est un grand pas pour y arriver, car vous aurez besoin de data scientists et des produits nécessaires. Bien sûr, les solutions ont parcouru un long chemin avec l'apprentissage automatique automatisé pour rendre cette partie plus facile, mais le junk in junk out s'applique toujours, vous avez toujours besoin de quelqu'un qui comprend les concepts de la science des données.

Donc, je pense que dans les 2 prochaines années, vous allez voir une énorme quantité de travail effectué pour créer ces modèles d'apprentissage automatique afin de tirer encore plus de valeur des données que vous ne pouvez en tirer des rapports historiques.

Une solution de bout en bout pour le développement d'entrepôts de données modernes

Astera DW Builder offre une plate-forme unifiée que les utilisateurs peuvent exploiter pour rationaliser chaque aspect de leur processus de développement, de la collecte initiale, le nettoyage des données à la conception de modèles de données prêts pour la création de rapports qui sont adaptés à vos exigences de gouvernance des données, et bien sûr le déploiement de votre entrepôt de données dans le cloud.

Avec ADWB, vous n'avez pas besoin de vous fier à une pile technologique complexe ou à des ressources techniques expérimentées pour mener à bien votre implémentation. Le produit offre une interface intuitive par glisser-déposer, prend en charge une itération rapide et fonctionne aussi bien avec un éventail de systèmes source et de destination. Contactez notre équipe pour commencer avec Astera DW Builder aujourd'hui.

Tu pourrais aussi aimer
Qu'est-ce qu'un catalogue de données ? Fonctionnalités, meilleures pratiques et avantages
Schéma en étoile contre. Schéma en flocon de neige : 4 différences clés
Comment charger des données d'AWS S3 vers Snowflake
Considérant Astera Pour vos besoins en gestion de données ?

Établissez une connectivité sans code avec vos applications d'entreprise, vos bases de données et vos applications cloud pour intégrer toutes vos données.

Connectons-nous maintenant !
connectons-nous