Discuter du passé, du présent et de l'avenir de l'entreposage de données avec l'expert en BI, Paul Kellett
Alors que nous progressons jusqu'à la sortie de Astera Constructeur DW, nous cherchons à donner aux lecteurs un aperçu de la façon dont ils peuvent rendre leurs architectures BI plus rapides, plus agiles et, finalement, mieux adaptées aux exigences de l'environnement de données à haut volume et à haute vitesse d'aujourd'hui.
Lorsqu'il s'agit de créer et de mettre en œuvre des solutions d'entreposage de données efficaces, peu de gens peuvent se vanter du type d'informations d'identification Paul Kellet apporte à la table. Avec 25 ans d'expérience à son actif dans un large éventail de projets pour des organisations à tous les niveaux, Paul a vu de première main comment les clients ont répondu au besoin toujours croissant d'intelligence d'affaires dans leur entreprise.
Au cours de cette vaste conversation, nous avons profité de l'occasion pour recueillir certaines des idées sincères de Paul sur des sujets tels que: l'état actuel de la BI d'entreprise, comment l'automatisation peut accélérer le développement de l'entrepôt de données, et où il voit le secteur se diriger au cours des deux prochaines années.
Alors, selon vous, quels sont les développements les plus significatifs que vous ayez constatés dans la BI d'entreprise depuis vos débuts dans cet espace?
J'ai donc commencé dans cette industrie il y a plus de 25 ans avec ce qu'on appelait alors les MIS (Management Information Systems), travaillant principalement dans des projets de bases de données. Depuis, j'ai été impliqué dans divers projets BI de l'entreprise au département et aux PME.
Si je devais parler des changements majeurs que j'ai constatés au cours de cette période, je dirais une bien plus grande prise de conscience [de l'importance de la BI], des volumes de données plus importants, une plus grande complexité autour des données et une technologie de support améliorée. Alors que les coûts et la complexité sous-jacents sont dde plus en plus, il y a encore du chemin pour y aller. [Je pense] que l'aspect visuel de la BI s'est également amélioré de manière significative.
Quels sont certains des cas d'utilisation de l'entreposage de données les plus courants que vous voyez?
La variété des cas d'utilisation est étonnamment large mais les plus typiques sont Environnements Greenfield lorsqu'une organisation a décidé de mettre en œuvre la BI ou des scénarios de remplacement pour des solutions existantes. Le remplacement est généralement motivé par une solution existante médiocre / défaillante (qui est étonnamment banal) ou remplacement des principaux systèmes de données sources. Il existe également une variété de cas d'utilisation où les éléments d'une solution sont entièrement remplacés, par exemple le remplacement de l'ETL codé à la main par un outil ETL. Ce dernier a tendance à être plus progressif.
Pensez-vous que chaque organisation pourrait bénéficier d'un entrepôt de données?
Un véritable entrepôt de données n'est pas pour tout le monde mais je n'ai pas encore vu une organisation qui ne pourrait pas améliorer son utilisation des données et des informations.
Un EDW peut être un investissement important. Ainsi, [la mise en œuvre réussie de] la BI nécessite normalement des changements culturels dans la façon dont l'entreprise utilise les données. L'un des chemins communs vers la «vraie BI» passe par les data marts, les solutions départementales et l'amélioration des rapports, chaque mise en œuvre ultérieure améliorant l'utilisation des données par l'organisation. Un EDW se trouve au bout de cette route dans de nombreux cas.
Ironiquement, les grandes entreprises se retrouvent avec des mausolées de données qui fournissent des données de goulot d'étranglementy. [Ces architectures] sont souvent détournées par des unités commerciales spécifiques et prennent donc mal en charge l'entreprise au sens large, contrairement à une véritable solution d'entreprise [comme un entrepôt de données]. La solution consiste à créer davantage de data marts pour prendre en charge différents éléments métier. Ces données doivent ensuite être intégrées à l'entrepôt de données de base.
Y a-t-il des facteurs spécifiques à rechercher lors de la recommandation d'un EDW à un client?
Je recherche une entreprise désireuse d'améliorer sa connaissance des données, car tout devrait en découler. Je recommande une approche par étapes dans la mesure du possible. Le jeu final pourrait bien être un entrepôt de données, mais il est important que les avantages commerciaux soient fournis progressivement.
Quels sont certains des principaux défis que vous voyez surgir au cours du processus de développement de l'entrepôt de données?
Probablement, accéder et comprendre les données… cette partie est toujours amusante. Engager les entreprises dans l'approche peut également être une tâche ardue. Une autre contrainte que je rencontre est le manque d'accès aux professionnels de la BI qui comprennent réellement à la fois la technologie et peuvent parler à l'entreprise.
Selon vous, quelle est l'étape la plus importante à franchir lors du développement de l'entrepôt de données? Extraire les données source? Modélisation des données? Créer des processus ETL?
La partie la plus importante est le résultat. Les données doivent être sous une forme prenant en charge la BI. Cela signifie principalement que les données ne perdent aucune information et qu'elles sont disponibles d'une manière pertinente pour l'entreprise.
Il y a de nombreuses façons d'arriver à ce point mais c'est la destination qui compte le plus. Cela dit, la destination en BI n'est souvent pas claire dès le départ, de sorte que la capacité à adapter rapidement le résultat final en fonction des apprentissages et des commentaires commerciaux est primordiale. Cela implique un mécanisme de livraison de données efficace et rapide ainsi qu'un outil de présentation performant [en frontend].
Que pensez-vous des architectures telles que le lac de données ou le coffre-fort de données? Y a-t-il des alternatives à l'entrepôt de données, des solutions complémentaires ou tout simplement beaucoup de battage médiatique?
En général, ils sont complémentaires et non essentiels. Les lacs de données sont généralement beaucoup moins chers et plus simples à mettre en œuvre. Le concept des lacs de données est relativement bien établi et vient en fait d'être renommé ces derniers temps. Cela pourrait avoir été appelé un magasin de données opérationnelles (ODS) il y a plus de 20 ans. Je crée fréquemment un lac de données invisible dans le cadre d'une solution d'entrepôt de données. Invisible en ce sens que je ne publie pas son existence en tant que lac de données car il y a des avantages en termes de flexibilité et d'auditabilité. Un lac de données peut également être une étape intermédiaire bon marché pour une solution BI plus complète, par exemple il permet d'améliorer les rapports.
Un coffre-fort de données est bien plus un composant informatique. Plus formelle et structurée, l'OMI est moins souvent justifiable en raison des coûts supplémentaires et des délais qu'elle ajoute à une solution. S'il est nécessaire de partager largement des données communes entre de nombreuses applications en plus du DW, cela devient alors justifiable.
À votre avis, quel rôle les outils d'automatisation des entrepôts de données jouent-ils dans l'accélération et la rationalisation du développement des entrepôts de données?
Énorme. Immense. Massif. Dois-je continuer? Trop souvent, un entrepôt de données est un projet monolithique de type cascade dans lequel nous, techno nerds, sommes enfermés dans une pièce pendant une période prolongée et invités à émerger avec une solution au mieux de ce dont nous pensons que l'entreprise a besoin. Oui, j'exagère, mais le processus doit être rapide et progressif avec des cycles de révision / révision fréquents qui s'engagent avec l'entreprise. En d'autres termes, l'entreposage de données doit devenir véritablement agile.
D'après l'expérience passée, nous savons que la décomposition d'un DW en plusieurs morceaux réduisent les risques, améliore la qualité de la livraison et améliore l'engagement avec l'entreprise. C'est tellement plus simple à faire avec des outils d'automatisation appropriés.
Une autre façon de voir cela est en termes de retour sur investissement. Dans le DW typique, le côté de la préparation des données représente l'essentiel des coûts. Réduire ces dépenses avec une automatisation appropriée orientée données présente de nombreux avantages, notamment une livraison plus rapide et de meilleure qualité. données pour abaisser la barrière à l'entrée.
L'amélioration de la qualité est évidemment un avantage crucial de l'automatisation, car la quantité sur mesure, plus complexe et sujette à des problèmes est considérablement réduite avec un outil approprié.
Selon vous, quelles fonctionnalités / fonctionnalités sont essentielles pour un outil d'automatisation d'entrepôt de données efficace?
Les tâches répétables, par exemple, la gestion des erreurs, l'audit, la création de SCD, etc. doivent être très simples et robustes. Il y a beaucoup de tâches répétitives dans une version DW. L'intégration dans les systèmes source et le modèle de destination doit être solide. Pour la maintenance et la livraison agile, la capacité à effectuer des analyses de dépendance pour comprendre le traitement est très importante.
Pensez-vous que les entrepôts de données cloud remplaceront les EDW sur site? Ou pensez-vous que le modèle hybride d'entrepôt de données est plus répandu?
Pas certain. Je vois une évolution générale vers les DW hors site car ils offrent une plus grande flexibilité, mais ce [déploiement dans le cloud] n'est pas sans défis. Les trois seront probablement communs avec une plus grande proportion de DW cloud que sur site.
Enfin, où voyez-vous le secteur évoluer au cours des cinq prochaines années environ?
Les éléments `` sexy '' de la BI, tels que les analyses basées sur l'IA et les visualisations plus puissantes, reçoivent l'essentiel de l'attention. Ces éléments continueront probablement à dominer l'espace. Cependant, je vois une révolution tranquille du côté de la livraison de données. La disponibilité des données prenant de plus en plus d'importance à mesure que les organisations se rendent compte que c'est généralement le coût le plus élevé.
Jetez un regard de première main sur l'avenir de l'entreposage de données
Le moment est venu de moderniser la BI de votre entreprise. Avec Astera DW Builder, vous pouvez tirer parti d'une plate-forme complète de bout en bout qui promet de rendre la conception, le développement et le déploiement de votre EDW ultra-rapides. Découvrez comment nous pouvons prendre en charge votre cas d'utilisation, contactez nos experts techniques dès aujourd’hui.
Certains des principaux avantages d'un entrepôt de données sont:
- Les entrepôts de données améliorent l'intelligence d'affaires et prennent en charge l'analyse avancée des données.
- Un entrepôt de données convertit les données dans un format unifié, ce qui améliore la qualité et la cohérence des données.
- Un entrepôt de données stocke des données historiques, qui peuvent aider à analyser les tendances et les périodes commerciales.
- Un entrepôt de données bien construit vous aidera à éviter les coûts associés aux pertes de données, à la qualité des données et à l'achat de divers outils d'intégration de données.
- Un entrepôt de données permet à une entreprise d'être plus agile en accédant à plusieurs sources de données sans les tracas des problèmes d'intégration et de compatibilité.
Un lac de données et un entrepôt de données sont souvent confondus car ils sont tous deux utilisés pour stocker du Big Data. Cependant, il existe quatre différences fondamentales entre le lac de données et l'entrepôt de données.
Premièrement, les lacs de données stockent des données brutes, tandis que l'entrepôt de données stocke des données raffinées. Deuxièmement, dans le lac de données, l'objectif des données n'est pas défini, tandis que les données de l'entrepôt de données sont utilisées pour un objectif défini au sein d'une organisation. De plus, le data lake est souvent utilisé par les data scientists. D'autre part, les professionnels utilisent largement l'entrepôt de données. Enfin, l'utilisation des données ou l'accessibilité est également différente dans les deux. L'architecture du lac de données rend plus flexible les modifications, tandis que l'architecture de l'entrepôt de données est plus compliquée ou rigide, ce qui rend les modifications difficiles et coûteuses.