Questions et réponses avec Barry Devlin sur les pipelines de données automatisés

Les pipelines de données automatisés sont une pièce cruciale du puzzle de l'entreposage de données. Ils permettent aux entreprises modernes de conserver des données précises et de haute qualité qui alimentent leurs initiatives de BI et d'analyse. Nous avons récemment lancé Astera DW Builder, un constructeur d'entrepôt de données robuste qui accélère radicalement la construction, l'orchestration et la gestion des pipelines de données pour permettre des décisions plus rapides et basées sur les données.

Astera Les pipelines de données autorégulés de DW Builder vous permettent de remplir de manière transparente votre entrepôt de données avec des données interentreprises. En utilisant les fonctionnalités ETL et ELT automatisées du produit, vous pouvez couvrir le parcours des données de la source aux informations avec un effort manuel minimal.

Nous avons récemment eu la chance de discuter avec Barry Devlin, une autorité de premier plan sur tout ce qui concerne l'entreposage de données, des meilleures pratiques de business intelligence au big data et au-delà. Voici quelques-unes des informations fournies par Barry sur les considérations clés pour le pipeline de données dans l'EDW moderne.

Les entrepôts de données modernes traitent d'énormes volumes de données. Lorsqu'il s'agit de créer des pipelines de données capables de fournir activement ces grandes quantités de données, recommanderiez-vous des bonnes pratiques ?

Eh bien, avant de parler des meilleures pratiques, j'aimerais faire moi-même une meilleure pratique qui consiste à définir et à développer certaines des phrases que nous utiliserons ici. [C'est] parce qu'il existe actuellement de très nombreuses significations différentes des mots et expressions clés sur le marché.

Donc, tout d'abord, les pipelines de données, de nombreuses personnes utilisent cette expression pour désigner un chemin intégré complet depuis les données sources jusqu'aux outils utilisés par l'homme d'affaires. Je vois que votre utilisation du terme est moins axée sur cette voie complète de la soupe aux noix, mais plutôt sur la possibilité d'un pipeline plus court entre, disons, différents composants comme une instance SAP et un flux de clics de site Web vers un entrepôt de données d'entreprise. Je crois que c'est une meilleure approche, et celle qui a le plus de chances de réussir.  

Deuxièmement, se pose la question de savoir ce que nous entendons par entrepôt de données. Parce qu'il existe de nombreuses approches contrastées. Ainsi, dans la plupart des cas, quand je dis entrepôt de données, je veux dire une structure à deux couches composée d'un entrepôt de données d'entreprise, d'un EDW et d'une troisième forme normale - ou plus probablement aujourd'hui, modèle de coffre-fort de données - alimentant plusieurs magasins de données, dont beaucoup peuvent être de nature dimensionnelle. Et cela n'exclut pas d'autres structures dont la plupart sont une simplification de cette approche à deux couches.

Enfin, j'utiliserai l'expression « préparation des données ou de l'information » pour couvrir tous les types de traitement comme l'ETL, l'ELT, le streaming, l'automatisation de l'entrepôt de données et même la virtualisation des données, car tous ces derniers termes sont des instances spécifiques de préparation de données et d'informations ou le approches techniques de celui-ci.

Cela étant dit d'emblée, permettez-moi de parler des meilleures pratiques sur lesquelles vous m'avez posé des questions et je vais me limiter à trois, mais il y en a bien d'autres.

Donc, tout d'abord, je dirais un outillage et une automatisation complets et faciles à utiliser - et c'est assez évident. La préparation des données [préparation] est la partie la plus coûteuse d'un entrepôt de données. Ainsi, la mise en place d'équipes de programmeurs pour créer de multiples solutions sur mesure incohérentes et impossibles à maintenir est, ou devrait être, une chose du passé. C'est le premier point.

La meilleure pratique n°XNUMX est la suivante : mettez au point la phase de conception en impliquant étroitement et en permanence l'entreprise dans le processus. Cela signifie itératif, approches de développement agiles [c'est-à-dire] moins sur la livraison d'applications professionnelles, mais plus sur la livraison de parties utiles du périmètre d'information de l'entrepôt de données.

Et troisièmement, je dirais la maintenance et la gestion du changement. Ce sont des caractéristiques clés qui sont souvent négligées. Veillez donc à ce que les mises à niveau et la maintenance soient envisagées tôt et mettez en place un processus étroitement lié à la conception et à la construction initiales.

Donc, pour revenir à mon premier point, l'outillage et l'automatisation jouent un rôle central pour y parvenir. Donc, il y a trois meilleures pratiques qui, à mon avis, sont vraiment importantes dans ce domaine.

Développer et déployer des entrepôts de données à haut volume

Essayez-le maintenant!

ETL est synonyme d'entreposage de données depuis le début de la technologie. Comment ce processus a-t-il évolué à l'ère des mégadonnées que nous connaissons aujourd'hui ? Quel type d'innovations voyez-vous qui peut réduire le coût et la complexité de l'ETL traditionnel ?

Je crois que nous devons toujours apprendre de l'histoire. La préparation des données, à mon avis, a évolué par à-coups avec de fréquents retours en arrière. Par exemple, récemment, les lacs de données initiaux et les entrepôts de données basés sur le cloud étaient très souvent remplis via des scripts et des solutions programmatiques similaires dans Hadoop. Cela a été une grande déception pour moi.

Il est bon de voir maintenant un recentrage sur l'outillage automatisé. La tendance à long terme est largement passée des solutions artisanales et sur mesure à l'utilisation d'ETL - et plus récemment d'outils ELT. Cela a été complété par le passage de la livraison par lots de données à une variété d'approches de livraison incrémentielle à mesure que les volumes de données augmentent et que l'entreprise exige de plus en plus d'informations en temps opportun.

Autrefois, ETL provenait de systèmes opérationnels souvent de conception à l'ancienne avec de nombreux codes obscurs. Comprendre les complexités ainsi que les règles métier profondes qui étaient obsolètes mais étaient toujours dans le système était une exigence clé pour un programmeur ETL.

Et puis il y avait l'exigence absolue de limiter l'impact sur les systèmes opérationnels, [en termes] à la fois de leur conception et de leurs performances. Les ingénieurs ETL devaient être profondément experts dans les structures mystérieuses et le contenu de ces systèmes sources hérités.

La bonne nouvelle maintenant, c'est que les systèmes opérationnels sont souvent mieux conçus, plus modernes et parfois basés sur le cloud. Ainsi, il est moins nécessaire de traiter avec des systèmes obscurs et davantage de se concentrer sur une conception innovante et des systèmes cibles. Bien sûr, [cela] réduit les coûts et la complexité de la préparation des données.

Cependant, les sources de données externes telles que l'Internet des objets (IoT) génèrent de nouveaux besoins à la fois en termes d'actualité des données et de types d'analyses impliqués. Ainsi, sur le plan technique, nous devons également considérer les approches de streaming par rapport au chargement par lots ou à la réplication.

Des sources moins archaïques permettent également de passer de transformations sur mesure et codées à la main à une approche davantage axée sur les modèles ou les métadonnées de la préparation de l'information qui est vraiment au cœur de l'automatisation des entrepôts de données.

Vous avez mentionné à quelques reprises que l'ELT est une approche plus récente qui s'est imposée. Comment voyez-vous cela par rapport à ETL ? S'agit-il d'approches complémentaires ou y a-t-il un contre type de chose qui se passe ici ?

Je pense qu'il y a beaucoup de questions à ce sujet mais, tout d'abord, je voudrais juste dire quelque chose que je pense qu'ETL était un choix de terminologie vraiment malheureux au début. Extraire, transformer et charger — car cela concentre l'attention sur la séquence d'actions plutôt que sur le processus global, c'est pourquoi je préfère utiliser le terme de préparation de données ou d'informations.

L'ordre ou l'emplacement des étapes est moins important pour moi que la façon dont nous les exécutons réellement. Espérons que, d'une manière axée sur les métadonnées. Il convient donc de noter également que la transformation est l'étape la plus complexe et la plus importante du processus et que comprendre où elle se produit s'avère être une considération clé en matière de conception.

Donc, cela dit et revenons à votre question. ELT - extraire, charger et transformer - signifie simplement que la transformation se produit dans l'environnement cible en utilisant la puissance de calcul [des] approches telles qu'une base de données relationnelle qui s'y trouve. Est-ce bon? Oui. Principalement.

La transformation sur le système source, qui aurait peut-être dû s'appeler transformer, extraire et charger [TEL], est toujours effectuée dans une certaine mesure, mais était historiquement maintenue au minimum absolu pour réduire l'impact du système source. La transformation sur un système intermédiaire - ETL - était alors un choix évident, minimisant les impacts sur les systèmes source et cible.

Cependant, les systèmes cibles en particulier sur le cloud ont peu ou pas de contraintes de performances et le SGBD relationnel cible a de bonnes capacités de transformation, donc ELT a beaucoup de sens, et oui je pense qu'ils sont complémentaires et en particulier une approche qui combine ETL et ELT semble pour moi d'être le plus flexible et le plus puissant, surtout s'il y a une certaine intelligence et automatisation dans le choix quand et dans quelles circonstances la fonction est poussée depuis le serveur ETL [c'est-à-dire] où elle est d'abord définie et exécutée vers le système cible. Alors, absolument ! Pas question de choisir entre les deux. Je pense que les deux peuvent coexister, et je pense que c'est une très bonne approche.

Comment vous assurez-vous que les données correctes sont introduites dans votre entrepôt de données qui sont combinées et transformées de manière optimale pour répondre aux exigences de reporting et d'analyse ? Quels conseils donneriez-vous aux organisations qui cherchent à garantir la qualité des données dans leur entrepôt de données d'entreprise ?

Oh, ce sont de bonnes questions. Je veux dire que la qualité est au cœur de toutes les formes de prise de décision basée sur des données ou je dirais des informations plus appropriées. Ainsi, la première chose pour moi est toujours un travail de modélisation de données ou d'informations approfondi et de qualité. Je sais que certaines personnes lèveront la main et diront : « Oh, trop lent [et] trop cher. Faisons le schéma à la lecture » Mais honnêtement, je ne pense pas qu'il existe d'autre moyen d'obtenir des données hautement cohérentes dans votre entrepôt que la modélisation en amont.

Donc, c'est vraiment important, et je pense que cette modélisation peut et doit être effectuée par étapes - une approche par étapes agile. C'est un sujet énorme et probablement pour un autre jour. Je sais que de nombreuses organisations ont opté pour une approche d'entrepôt de données entièrement dimensionnelle et qui peut être idéale pour les entreprises de taille moyenne.

Mais pour les grandes entreprises, un stockage cohérent de données de base réconciliées et d'EDW est généralement préférable pour créer et maintenir des données et des informations de qualité optimale. Et enfin, au-delà de la modélisation, l'emploi d'une équipe de modélisation compétente et flexible est probablement le prochain aspect le plus important de la mise en œuvre d'un environnement de préparation de données de premier ordre.

En particulier, dans les organisations de taille moyenne, je suggérerais qu'une approche d'automatisation d'entrepôt de données est probablement la meilleure en termes de qualité et de coût, car cela inclut généralement l'étape de modélisation dans le processus d'avancement.

[Dites] cette architecture que vous avez est construite. Vous disposez de plusieurs pipelines de données provenant de divers systèmes sources. Vous avez mentionné les systèmes opérationnels, évidemment, les flux IoT peut-être, [donc] il y a beaucoup de possibilités quand vous parlez de l'entreprise moderne. Vous avez différentes latences de données qui fonctionnent ici et des interdépendances dans de nombreux cas. Orchestrer tout cela est évidemment une question difficile. Selon vous, quels sont les éléments essentiels pour que cette partie de l'équation soit correcte ?

Eh bien, tout d'abord, je voudrais dire que nous avons toujours eu affaire à plusieurs pipelines de données provenant de divers systèmes sources avec différentes latences et interdépendances de données, comme vous l'avez mentionné - certainement, dans les grandes entreprises avec lesquelles j'ai eu affaire.

Je pense que l'aspect le plus important aujourd'hui et vous l'avez mentionné, c'est que nous cherchons à ingérer et à analyser d'énormes quantités de données brutes et ce sont souvent ces données sales - et on ne sait pas à quel point elles sont sales - du Web et de l'Internet de des choses. Et ces données ont des caractéristiques très différentes des données du système opérationnel que j'appelle les données médiatisées par le processus, ou PMD en abrégé, qui étaient les principales sources de données jusqu'à il y a, disons 10 ans.

Donc, étant donné cette différence de qualité des données, je dirais qu'essayer de pousser toutes ces nouvelles données dans le même entrepôt de données que votre PMD est une erreur. Vous avez besoin de plusieurs piliers du traitement des données. J'ai expliqué tout ça dans mon livre "Non-intelligence d'affaires”, donc si vous voulez y plonger plus profondément, faites-le. Certains de ces piliers seront des entrepôts de données traditionnels, d'autres ressembleront davantage à des lacs de données, mais tous seront bien sûr alimentés par des pipelines de données comme je l'ai défini plus tôt dans l'interview.

Donc, la clé pour que tout cela fonctionne bien, bien sûr, est de s'assurer que les données de ces piliers sont bien interconnectées, liées et réconciliées par opposition à ce que nous avons vu dans les silos de données traditionnels et ce que vous appelez l'orchestration à travers les pipelines de données est un élément clé pour que cela se produise.

Maintenant cela nous ramène à la modélisation mais aussi aux métadonnées car un élément essentiel dans l'orchestration de tous ces pipelines sont les métadonnées. Maintenant, je préfère l'appeler information de mise en contexte, ou CSI, parce que ce mot "méta" est un peu abusé ces jours-ci, même Facebook l'a adopté.

Ainsi, ce type d'informations contextuelles est ce qui est contenu et mentionné dans l'architecture Data Fabric de Gartner. intelligence] pour le faire.

Il est donc très important d'avoir cette idée de métadonnées actives impliquées. Je pense que nous sommes en fait assez loin de cela aujourd'hui, mais nous devons vraiment nous concentrer là-dessus parce que je pense que cela va vraiment faire fonctionner tout ce système ou il va s'effondrer.

Parlons donc de l'entrepôt de données réel et de l'endroit où il est construit. De toute évidence, le cloud semble être l'endroit où tout le monde utilise ses systèmes de BI de nos jours. Quelles sont les considérations que les équipes de données d'entreprise doivent garder à l'esprit lors de la création d'un pipeline de données pour ces plates-formes ?

Ouais, je veux dire tout le monde parle de cloud. En termes d'architecture, mon point de vue est que le cloud est simplement [que c'est] un autre pool de stockage, bien qu'énorme et hautement distribué, et si vos outils de préparation de données prennent en charge les sources et les cibles du cloud, vous êtes prêt à partir, n'est-ce pas ? Eh bien, je dirais pas tout à fait.

C'est la nature distribuée du cloud que vous devez d'abord et toujours garder à l'esprit. La gestion des données était beaucoup plus simple, je dis toujours, lorsque toutes vos données se trouvaient dans un seul ordinateur central. Mais les copies de données sont le fléau de la gouvernance des données et plus il y a d'endroits et plus ces copies sont éloignées, plus le défi devient difficile. Ainsi, le cloud permet et – dans une certaine mesure – favorise la duplication de données, dont certaines [est] largement invisible.

Donc, mon premier conseil en termes de cloud est de renforcer vos équipes de gouvernance et de gestion des données car elles vont vraiment être nécessaires. La deuxième considération est ce qu'on appelle la gravité des données. D'où proviennent les données ?

S'il provient de locaux, il y aura des coûts pour le faire passer au cloud. [Et] s'il vient du cloud, il est généralement plus efficace de le garder là-bas.

Bien sûr, la plupart des entreprises disposent aujourd'hui de données provenant des deux sources, il n'y a donc pas de réponse unique et correcte quant à l'endroit où stocker et traiter vos données. Mais il est clair que la pression est forte pour l'installer sur le cloud, souvent pour des raisons financières. Mais voici le vol - l'essentiel ici est de garder un œil sur les coûts relatifs du traitement du stockage et du transport des données, et je pense que c'est ce dernier qui peut vous surprendre, surtout quand nous parlons de préparation de données et de pipelines de données .

Donc, passons à la dernière question et je suppose que c'est celle que nous avons contournée et mentionnée de différentes manières et dans certaines réponses précédentes, mais pour obtenir une idée approximative, pensez-vous que l'automatisation s'intègre dans tout cela? Comment peut-il rendre le processus de création et de maintenance des pipelines de données plus efficace ?

Ouais, je pense que tu as raison. Tout pointe désormais vers l'automatisation. Comme je l'ai déjà dit, je veux dire que je suis un grand partisan de l'automatisation dans la préparation des données et des informations. Cela dit, je me méfie profondément de l'automatisation dans d'autres domaines, en particulier lorsque des décisions affectant la vie sont prises et je pense que nous devons faire attention à l'automatisation là-bas.

Mais revenons à la préparation des données, je pense que tout ce qui réduit le coût de ce qui n'est effectivement que de la plomberie est le bienvenu. Et l'automatisation doit être appliquée à chaque étape du processus, dans la mesure du possible, de la spécification et de la conception initiales aux opérations quotidiennes et jusqu'à la maintenance continue et la gestion des changements.

C'est un éventail très large et très large de ce que nous aurions besoin de faire et de ce que nous devons automatiser. Je ne fais pas de mise en garde, vous savez, sur la base de mes longues années d'expérience et c'est que l'automatisation a tendance à vous pousser vers des fonctions de transformation prédéfinies, et elles sont géniales ! Mais la possibilité de créer des transformations personnalisées propres à votre propre environnement est souvent la clé du succès en interne des outils de préparation des données.

De tels besoins peuvent ne représenter que cinq pour cent ou moins que les transformations [prédéfinies], mais leur importance est souvent facilement sous-estimée car ce sont souvent les transformations les plus importantes d'un point de vue commercial.

À mon avis, les outils d'automatisation des entrepôts de données doivent permettre le développement et l'intégration de ces routines de transformation très spécifiques dans le flux de travail. Cela dit, l'automatisation offre la possibilité de réduire ou d'éliminer les parties répétitives et courantes du processus de préparation des données. Et les outils d'automatisation des entrepôts de données augmentent également les aspects humains du processus.

Je pense ici à la définition des exigences, à la recherche de consensus, à la gestion du changement, etc. En ce sens, DWA est un peu comme l'intelligence artificielle, en ce sens qu'elle contient à la fois des aspects d'automatisation et d'augmentation. Donc, je pense que c'est un aspect particulièrement important de ce à quoi nous devons penser.

En dernier lieu, j'ai toujours pensé que l'automatisation des entrepôts de données comme ETL était un choix de nom malheureux pour cette classe d'outils car ces outils font plus que l'automatisation comme je viens de le dire, et ils peuvent et doivent s'appliquer à un une gamme plus large de systèmes de stockage et de gestion de données que de simples entrepôts de données.

Toutes les parties du nom ont leurs faiblesses. Alors, quel devrait être le nom? Je ne sais pas vraiment, à moins que vous ne vouliez essayer de l'appeler le couteau suisse de la gestion des données et je pense que c'est probablement un bon endroit pour s'arrêter.

Automatisez vos pipelines de données sans écrire de code

Trouver comment

Astera DW Builder : automatisez vos pipelines de données

Astera DW Builder est une solution d'entreposage de données unifiée qui vous permet de créer une architecture de pipeline de données basée sur les métadonnées. La plate-forme de bout en bout offre un environnement zéro code pour développer votre entrepôt de données à un niveau logique et automatiser vos processus de conception et d'ingénierie pour obtenir des informations riches qui répondent à vos besoins en matière de business intelligence.

La solution agile et automatisée est dotée des meilleures capacités ETL et ELT, y compris des composants intégrés d'orchestration de flux de travail et de planification des tâches, pour créer des pipelines de données autorégulés. Prenez Astera DW Builder pour un essai routier pour découvrir comment il peut vous aider à fournir des données précises et fiables à votre architecture de BI et de reporting.