Blogs

Accueil / Blogs / Séance de questions-réponses avec Paul Kellett sur les pipelines de données automatisés

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.

Séance de questions-réponses avec Paul Kellett sur les pipelines de données automatisés

Ammar Ali

Reseaux Sociaux

Août 4th, 2022

Les pipelines de données automatisés constituent l'épine dorsale d'un écosystème entièrement axé sur les données. Ils permettent aux entreprises d'extraire des données de sources disparates, d'appliquer des transformations et d'effectuer le processus d'intégration de manière efficace, fiable et rapide. De plus en plus d'entreprises optent pour l'automatisation des entrepôts de données pour améliorer l'analyse des données et rivaliser de manière plus stratégique.

Nous avons récemment lancé Astera DW Builder, une plate-forme d'automatisation d'entrepôt de données de bout en bout qui fournit un environnement itératif et sans code pour concevoir, développer et déployer des pipelines de données à des vitesses sans précédent.

Pour éduquer les entreprises modernes sur le pipeline de données d'autorégulation, nous avons organisé un webinaire en direct intitulé - Pérennisez votre entrepôt de données avec des pipelines de données autorégulés le novembre 2nd, où nous avons eu une opportunité incroyable d'avoir une discussion avec Paul Kellett. Il a plus de 25 ans d'expérience de travail sur des projets d'intelligence d'affaires au niveau de l'entreprise pour les organisations.

Lors de notre session de questions-réponses, nous avons obtenu des informations précieuses sur la création de pipelines de données automatisés de haute qualité, les processus d'entrepôt de données modernes, l'entreposage de données dans le cloud, etc.

Afnan : Les entrepôts de données modernes traitent d'énormes volumes de données. Recommanderiez-vous des bonnes pratiques que les gens devraient utiliser pour créer des pipelines de données capables de fournir efficacement ces grandes quantités de données à leur entrepôt de données ?

Paul: Oui, mais j'ajouterais aussi qu'il n'y a pas que les volumes de données. C'est la variété des sources, la variété des formats des sources et le fait que si vous êtes particulièrement dans un environnement d'entreprise, vous accédez fréquemment à des dizaines de systèmes — ils sont en constante évolution. Ainsi, le type de données que vous obtenez changera généralement.

Ces systèmes ne restent pas immobiles - les entreprises innovent et changent, vous examinez donc plusieurs problèmes ici. Vous devez l'obtenir de manière fiable ; vous devez [traiter les données] de manière robuste [avec] le moins d'interventions possible. Historiquement, les gens pouvaient créer toute une série d'extraits à partir de leurs systèmes source, ils feraient des solutions de type point à point où vous pourriez avoir plusieurs mécanismes différents pour recevoir les données. Je dirais, essayez d'avoir [un] mécanisme standard constant [et] vous aurez un seul type de pratique.

Vous devez ensuite mettre en place des outils adaptés à ces choses. Donc, évitez autant que possible les solutions artisanales ou point à point. Ce que nous voyons pour de nombreux entrepôts de données historiques, c'est qu'il existe un certain nombre de solutions artisanales sur mesure pour obtenir les données du système « A » et une autre du « système B ». Ils se retrouvent essentiellement avec des problèmes de qualité et de robustesse, et ils se retrouvent également avec des problèmes de maintenance, et ils ont tendance à s'adapter assez lentement au changement.

Donc, c'est un triple coup dur en termes de faire cela. Vous voulez utiliser des choses qui font le gros du travail pour vous. Vous ne voulez pas répéter des choses standard comme la gestion des erreurs. Il doit être simple, facile, robuste, cohérent et standard. Mon dernier point sur cette question serait d'essayer, si possible, d'aller extraire les données des systèmes sources plutôt que de vous les fournir sous forme d'extrait.

Afnan : Les pipelines de données et ETL sont fondamentalement un concept qui est synonyme d'entreposage de données depuis le début de la technologie. Alors, comment pensez-vous que l'ELT et le pipeline de données ont évolué à l'ère du Big Data ? Selon vous, quel type d'innovations pourrait réduire à la fois le coût et la complexité de l'ETL traditionnel ?

Paul: Historiquement, une grande partie des coûts proviennent probablement de deux domaines principaux : l'un a été constitué de nombreuses solutions de type artisanal, qui sont assez chères et assez limitées. Aussi - et je n'aborde pas les outils ELT ici, mais - ils ont été gros [et] chers. Ils nécessitent des ressources spécialisées et leur propre infrastructure, matériel, serveur, plates-formes dédiés, et ils [nécessitent] des ressources [qui] sont difficiles à obtenir.

Donc, ce que nous voyons maintenant est un mouvement pour rendre ces types de processus plus faciles. Ainsi, plutôt que d'avoir à déterminer ce que vous allez obtenir, ils vont automatiquement créer une carte pour vous. C'est beaucoup plus de clics et de points que cela n'a été le cas historiquement. Donc, nous voyons que cela réduit essentiellement le besoin, et [permet] beaucoup plus de codage et de faire passer cela.

Afnan : Une exigence majeure que nous voyons souvent se poser est que davantage d'organisations souhaitent désormais construire des pipelines ELT au lieu des pipelines ETL traditionnels. Alors, que pensez-vous de cette approche ? Pensez-vous que cela pourrait fonctionner pour toutes les organisations? ou y a-t-il certaines choses que les organisations doivent garder à l'esprit avant d'opter pour l'ELT au lieu de l'ETL ?

Paul: Donc, premièrement, il n'y a jamais une solution qui fonctionne pour tout. Il y a des cas où ETL est tout à fait approprié ; en fait, préféré. Mais ce que nous constatons, c'est que le point de départ préféré de nos jours serait probablement l'ELT. Le logiciel et les architectures de base de données se sont considérablement améliorés. L'un des besoins de l'ELT historique a été l'incapacité de la base de données à traiter les grands volumes de transformations requis dans les échelles de temps. Ils peuvent à peu près faire un très grand nombre de cas d'utilisation.

Personnellement, je me suis orienté vers ELT. Je ne me souviens pas de la dernière fois que j'ai fait de l'ELT – cela aurait été il y a au moins dix ans. Leur motivation principale serait la composante bien-être. Vous avez simplifié votre solution. Vous avez une plate-forme de moins pour vous tromper et pour mettre en place [ainsi que] un ensemble de plates-formes de test de moins à parcourir. Donc, vous avez laissé tomber votre complexité.

Vous avez également des coûts, dans la mesure où vous n'avez pas ces plates-formes pour le faire, donc les choses qui en généraient le besoin ont essentiellement diminué. Si je cherchais aujourd'hui dans un environnement Greenfields, je supposerais que mon point de départ serait ELT, puis je m'en éloignerais si j'en ressentais le besoin en raison de circonstances particulières.

Afnan : Comment pouvez-vous vous assurer que vous disposez des données correctes dans votre entrepôt de données ? et qu'il est à la fois combiné, consolidé, [et] transformé d'une manière qui correspond à vos exigences de reporting et d'analyse ?

Paul: Donc, premièrement, vous ne pouvez pas vraiment obtenir des données correctes garanties. La raison en est que vous comptez sur les données que les systèmes sources vous fournissent et, comme le témoignera toute personne ayant travaillé dans le domaine, ils vous donneront souvent des données incorrectes ou des données incohérentes ou des données ont des problèmes lorsqu'elles sont présentées de manière différente - [ it] fournit la mauvaise position.

Mais ce que vous pouvez faire, c'est essayer de donner la meilleure image possible des données de la meilleure façon possible. Vous ne devriez pas vous tromper en disant que nous allons donner des données parfaites parce que cela n'arrive pas. Heureusement, [ce n'est] pas si important parce que vous parlez généralement d'analyse et qu'il s'agit de comprendre le volume de données, donc ce n'est pas nécessairement un problème si vous le gérez correctement.

Si vous voulez obtenir les meilleures données possibles, il y aurait quelques tactiques que je conseillerais, l'une d'entre elles serait de sur-collecter. Si nous prenons l'exemple, disons, des transactions de vente, on vous demande de fournir des rapports de ventes ou une analyse des ventes et quelqu'un se rendra compte que vous avez besoin des champs A, B et C de ces deux tables, puis [champs] de ceci et de cela et ceci et vous obtiendrez les données nécessaires pour résoudre le problème.

Mon conseil est généralement que si vous avez besoin d'informations sur les ventes, saisissez l'intégralité de la transaction de vente [et] toutes les données associées. Aussi, prenez-le de la manière la moins transformée possible. Ne courez pas le risque d'être essentiellement dans une transformation ou une dérivation des données en mettant vos propres erreurs de traduction. Apportez cela dans votre entrepôt de données et faites-le là-bas.

Je chercherais également à créer des boucles de rétroaction, afin d'avoir des moyens de faire des vérifications de haut niveau. Supposons que j'ai les données que je m'attends à obtenir, et que j'utilise généralement des rapports ou des données fiables provenant des systèmes sources, puis les compare à quelque chose de similaire dans ce que vous obtenez au fur et à mesure.

Il est important de comprendre ce qui est assez bon pour l'entreprise. Par exemple, historiquement, les transactions comptables doivent être parfaites et à quelques centimes près, mais si vos transactions de vente augmentent un peu, ce n'est pas la fin du monde. Donc, j'utiliserais aussi des choses comme ça. Il [existe] des astuces et des techniques standard comme le formatage des données standard [et] la suppression de l'espace de fin comme une virgule. Décidez-vous que vous allez les faire et faites-les [d'une] [manière] standard.

Afnan : Quand vous parlez de collecter toutes ces données à partir de différentes sources. Vous aurez affaire à plusieurs pipelines de données, et tous ces pipelines auront évidemment des latences et des interdépendances de données différentes. Alors, selon vous, quels sont les éléments essentiels pour orchestrer essentiellement ces pipelines ?

Paul: Il existe des techniques de modélisation testées assez standard dans la modélisation de dimensionnement utilisées là-bas. Kimball [est] un très bon point de départ pour examiner le type de conseils et de techniques de conception qu'ils ont donnés. Ceux-ci sont très bien adaptés pour construire votre entrepôt de données de manière à ce que vos données soient cohérentes et présentent un format commun à mesure que vous avancez.

Ils géreront des choses comme les informations manquantes, donc si vous n'avez pas XYZ provenant d'une source particulière, si vous ne connaissez pas la définition du produit, alors vous savez que vous avez des techniques standard comme je vais créer un produit de domaine donc à au moins mon rapport de vente additionne le produit. Je ne connais peut-être pas les informations sur le produit, mais je sais que j'ai des informations sur un produit appelé fret. Je n'en sais pas plus sur ce produit, mais c'est tout ce que je sais.

La deuxième chose est que vous devez diriger la manière dont vous traitez vos informations sur le contenu des données [métadonnées], et non la manière dont les données sont traitées ou consultées. Donc, ce sont des choses comme si le lundi, vous obtenez les transactions du dimanche, ne supposez pas que vous obtenez les transactions du dimanche. Chassez tout les dates dans les données. Donc, essayez toujours de récupérer autant de dates que possible dans les données, afin que vous sachiez ce qui se passe et de cette façon, vous pouvez à nouveau faire correspondre les choses les unes aux autres.

Ainsi, vous allez alors avoir des incohérences entre les systèmes, en particulier [lorsque vous avez] des dizaines de systèmes livrés à votre entrepôt de données, l'un d'entre eux sera invariablement en panne à un moment donné, l'un d'eux sera disponible. [et] cela se produira fréquemment. À cette fin, présentez ce qui manque dans votre solution, ne vous contentez pas de le présenter et indiquez clairement et clairement que nous n'avons pas les données d'inventaire de lundi pour [par exemple] le centre de distribution 27.

Traitez-le dans le cadre de votre traitement ; ce seraient mes principaux commentaires. Par conséquent, utilisez les données pour le piloter ; Kimball est roi et assurez-vous que l'entreprise sache quand vous obtenez des choses qui ne sont pas apparues.

Afnan : L'entreposage de données dans le cloud a pris beaucoup d'ampleur, surtout cette année, nous en avons entendu parler partout. Alors, selon vous, quelles sont les considérations que les équipes de données d'entreprise doivent garder à l'esprit lorsqu'elles créent des pipelines de données spécifiquement pour un entrepôt de données cloud ?

Paul: D'accord, je vais donc supposer que lorsque nous parlons de service cloud acheté en termes d'hébergement et de gestion de votre infrastructure d'entrepôt de données. Donc, d'un point de vue technique, il n'y a pas grand-chose de différent dans le passage au cloud.

[Les] principales différences techniques seraient que vous êtes évidemment sur Internet pour ainsi dire, et que vous déplacez peut-être de gros volumes de données, vous devez donc beaucoup réfléchir à la façon dont vous allez déplacer ces données volumineuses. volumes autour. Vos systèmes sources et votre infrastructure hébergée dans le cloud (du point de vue du réseau) sont-ils suffisamment proches les uns des autres pour que vous puissiez déplacer ces éléments ? De plus, sont-ils suffisamment robustes entre vos différents systèmes pour que vous ayez, encore une fois, de la fiabilité dans les données.

L'autre élément à considérer est souvent celui des solutions d'entreposage de données. Il existe des éléments de type tableau de bord, et les éléments de type tableau de bord ont assez souvent eu une rapidité de remise en forme réactive. Ils nécessitent de réagir assez rapidement aux utilisateurs en termes de clic ici et vous obtenez le prochain ensemble.

La latence compte. Si votre temps de ping entre vos utilisateurs et votre infrastructure cloud est faible, cela peut donner une mauvaise apparence à vos tableaux de bord, même s'ils ne le sont pas. La plupart des considérations porteraient sur les aspects commerciaux, réglementaires ou d'infrastructure. Lorsque vous optez pour le cloud, vous choisissez généralement un fournisseur. Ainsi, vous n'êtes plus dépendant de la technologie. Vous dépendez d'un fournisseur pour que ses systèmes soient opérationnels.

Il s'agit beaucoup de mesurer le fournisseur et ses capacités plutôt que la technologie. Certains des problèmes réglementaires potentiels sont que - si je regarde ici où je suis basé - vous n'êtes fondamentalement pas autorisé à prendre des données de santé comme exemple hors du pays sans autorisation spéciale parce que ce sont des données personnelles, et il y a des règles sur ce que vous faire avec les données personnelles.

De même, vous avez une certaine sécurité des données que vous devez examiner dans la mesure où vous êtes désormais responsable de la gestion de vos données par un tiers. En fait, ils seront probablement meilleurs que vous en matière de sécurité des données parce que cela fait partie de leur vie, mais vous devez toujours vous assurer de vérifier cela. Et en fait, je dirais que c'est probablement l'un des domaines où vous pouvez vous reposer un peu plus facilement.

L'une des choses à propos de la migration vers le cloud est que vous obtenez beaucoup plus de capacités [en termes de] votre capacité d'adaptation. [Il y a un] certain nombre de cas où j'ai été avec des clients et essentiellement leur entrepôt de données a été défini sur une architecture vieille de 10 ans qui grince lentement, [avec] les charges quotidiennes arrivant de plus en plus tard dans la matinée. [Donc], vous ne recevez pas vos rapports avant midi, mais la tâche de déménager a été incroyablement difficile.

Ils ont eu toutes sortes de problèmes en essayant de recruter et de posséder des ressources capables de faire ce genre de travail afin que vous puissiez transmettre une grande partie de ce problème à quelqu'un d'autre. Ne le faites pas pour des raisons de coût, car cela coûtera généralement le même; même si le modèle d'établissement des coûts peut différer, vous achetez plus [et] vous vous améliorez. Voilà donc quelques-unes des considérations à prendre en compte pour passer au cloud.

Afnan : Où pensez-vous que l'automatisation s'intègre dans tout cela ? [En utilisant] l'automatisation et l'orchestration, comment pensez-vous pouvoir rendre l'ensemble du processus de création et de maintenance de vos pipelines de données plus efficace ?

Paul: Tout d'abord, dans la mesure du possible, évitez que les solutions point à point aient quelque chose qui fasse le gros du travail pour vous. Donc, vous voulez quelque chose qui surveille pour vous. Fréquemment, ces charges se produisent au milieu de la nuit. Vous voulez un type standard de capacités de type automatisé, comme pouvoir redémarrer à partir d'un moment particulier, sauter des points, tout ce genre de contrôle des travaux et de gestion des travaux.

Vous voulez quelque chose qui est essentiellement facile à construire. Plus il est facile de les assembler [le système], plus vous obtiendrez de données. Plus vous l'obtenez rapidement et moins vous aurez d'erreurs lorsque vous importerez ces données, plus vous aurez de chances de le faire selon la manière dont l'entreprise souhaite que vous le fassiez.

Je veux dire, en passant, je commente fréquemment que nous sommes notre pire ennemi. Si nous réussissons dans une solution de business intelligence, nous le savons normalement parce que nous sommes complètement surchargés de demande. D'accord, vous devez donc pouvoir faire ces choses de la manière la plus simple possible pour faire face à cette demande.

Historiquement, le coût du déplacement [et] de la création d'entrepôts de données a été de l'ordre de soixante pour cent, peut-être même des deux tiers, selon vos échelles de temps du côté ELT. Donc, vous voulez vraiment vous assurer que vous avez quelque chose qui fait un grand nombre de tâches répétables autant que possible pour vous d'une manière aussi simple que possible, car c'est une grande partie de ce qui peut être un coût assez important.

Astera DW Builder : plate-forme d'entrepôt de données automatisé

Astera DW Builder est une solution d'entreposage de données de bout en bout qui vous permet de développer des pipelines de données automatisés dans un environnement sans code. La plate-forme unifiée est livrée avec une architecture basée sur les métadonnées et rationalise vos processus de conception et d'ingénierie pour fournir des informations précises et pertinentes afin de faciliter une meilleure prise de décision.

Les entreprises peuvent créer des pipelines de données autorégulés en tirant parti des fonctionnalités ETL et ELT avancées telles que les composants intégrés d'orchestration de flux de travail et de planification des tâches de Astera Constructeur DW. Essayez Astera DW Builder aujourd'hui pour découvrir comment cela peut ajouter de la valeur à votre organisation.

Tu pourrais aussi aimer
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
BigQuery ou Redshift : lequel choisir ?
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