Database
 sql >> Base de données >  >> RDS >> Database

ETL vs ELT :Nous postulons, vous jugez

Divulgation complète :Comme cet article est rédigé par une entreprise centrée sur l'ETL avec son point fort dans la manipulation de données volumineuses en dehors des bases de données, ce qui suit ne semblera pas objectif à beaucoup. Néanmoins, il est toujours destiné à présenter des éléments de réflexion et ouvre la voie à la discussion.

Depuis leurs débuts, les architectes d'entrepôt de données (DWA) ont été chargés de créer et de remplir un entrepôt de données avec des données disparates et formatées. En raison de la croissance spectaculaire des volumes de données, ces mêmes DWA sont mis au défi de mettre en œuvre plus efficacement leurs opérations d'intégration et de transfert de données. La question de savoir si la transformation des données se produira à l'intérieur ou à l'extérieur de la base de données cible est devenue une question critique en raison des performances, de la commodité et des conséquences financières impliquées.

Dans les opérations ETL (extraction, transformation, chargement), les données sont extraites de différentes sources, transformées séparément et chargées dans une base de données DW et éventuellement d'autres cibles. Dans ELT, les extraits sont introduits dans la base de données intermédiaire unique qui gère également les transformations.

L'ETL reste répandu car le marché prospère avec des acteurs éprouvés comme Informatica, IBM, Oracle - et IRI avec Voracity, qui combine FACT (Fast Extract), CoSort ou Hadoop transforme, et le chargement en masse dans la même interface graphique Eclipse - pour extraire et transformer des données. Cette approche évite de surcharger les bases de données conçues pour le stockage et la récupération (optimisation des requêtes) avec la surcharge d'une transformation de données à grande échelle.

Cependant, avec le développement de nouvelles technologies de base de données et d'appliances matérielles comme Oracle Exadata qui peuvent gérer les transformations « dans une boîte », ELT peut être une solution pratique dans certaines circonstances. Et il y a des avantages spécifiques à isoler les couches de mise en scène (chargement) et sémantique (transformation).

Un avantage cité de l'ELT est l'isolation du processus de chargement du processus de transformation, car il supprime une dépendance inhérente entre ces étapes.

Nous notons que l'approche ETL d'IRI les isole de toute façon car Voracity met en scène les données dans le système de fichiers (ou HDFS). Tout bloc de données lié à la base de données peut être acquis, nettoyé et transformé en externe avant un chargement (pré-trié). Cela élimine le fardeau des transformations à grande échelle de la base de données (ainsi que des outils de BI/analytique, etc.).

Les volumes de données et les budgets sont souvent ce qui détermine si un DWA doit développer une solution ETL ou ELT. Dans son article de blog ITToolbox "So What Is Better, ETL or ELT ?", Vincent McBurney présente ses avantages et ses inconvénients pour l'une ou l'autre approche, que j'ai répété ci-dessous, puis suivi chacun avec une réponse typique selon laquelle IRI ETL les utilisateurs orientés vers le point  (conformément à ma mise en garde initiale sur la subjectivité) :

Avantages ETL
  • ETL peut équilibrer la charge de travail et partager la charge de travail avec le SGBDR - et en fait supprimer cette charge de travail en transformant les données via le programme SortCL ou Hadoop sans coder dans Voracity
  • ETL peut effectuer des opérations plus complexes dans des diagrammes de flux de données uniques via des cartes de données – comme avec la cartographie Voracity et les diagrammes de flux de travail qui sont également abstraits courts et ouverts  Scripts 4GL et SQL
  • ETL peut évoluer avec du matériel séparé :sur les boîtiers de produits, vous pouvez vous approvisionner et vous entretenir à des coûts bien inférieurs à ceux des appliances d'un seul fournisseur
  • ETL peut gérer le partitionnement et le parallélisme indépendamment du modèle de données, de la disposition de la base de données et de l'architecture du modèle de données source – via les tâches CoSort SortCL de Voracity n'a pas du tout besoin d'être partitionné...
  • ETL peut traiter les données en flux, car elles sont transférées de la source à la cible - ou par lots si cela a du sens également
  • ETL ne nécessite pas la colocalisation des ensembles de données pour faire son travail - ce qui vous permet de maintenir les plates-formes de sources de données existantes sans soucis de synchronisation des données
  • ETL capture d'énormes quantités de lignées de métadonnées aujourd'hui :dans quelle mesure ou de manière intuitive une base de données intermédiaire peut-elle le faire ?
  • ETL peut s'exécuter sur du matériel SMP ou MPP - que vous pouvez à nouveau gérer et exploiter de manière plus rentable, sans vous soucier des conflits de performances avec la base de données
  • ETL traite les informations ligne par ligne et cela semble bien fonctionner avec l'intégration de données dans des produits tiers – mieux encore  bloc complet, table ou fichier(s) à la fois, que Voracity exécute en volume.
Inconvénients ETL
  • Un investissement matériel supplémentaire est nécessaire pour les moteurs ETL - sauf si vous l'exécutez sur le(s) serveur(s) de base de données
  • Coût supplémentaire lié à la construction d'un système ETL ou à la licence d'outils ETL – qui sont encore moins chers que les appliances ELT, mais les outils IRI comme Voracity, qui combinent Fast Extract (FACT) et CoSort pour accélérer l'ETL sans une telle complexité, sont encore moins chers
  • Performance réduite possible de l'approche basée sur les lignes - correct, et pourquoi la capacité de Voracity à profiler, acquérir, transformer et produire des données en plus gros morceaux est plus rapide
  • Compétences spécialisées et courbe d'apprentissage requises pour la mise en œuvre de l'outil ETL – sauf si vous utilisez une interface graphique ergonomique comme celle de Voracity, qui fournit plusieurs options de conception de tâches dans le même IDE Eclipse
  • Réduction de la flexibilité en raison de la dépendance vis-à-vis du fournisseur d'outils ETL – Je ne sais pas comment cela peut être amélioré en s'appuyant plutôt sur un seul fournisseur d'ELT/d'appareil ; l'indépendance vis-à-vis des fournisseurs n'est-elle pas la clé de la flexibilité et des économies ?
  • Les données doivent traverser une couche supplémentaire avant d'atterrir dans le magasin de données – à moins que le magasin ne soit qu'un autre résultat du processus ETL, typique des opérations Voracity multicibles.
Pros ELT
  • ELT exploite le matériel du moteur RDBMS pour l'évolutivité, mais taxe également les ressources de base de données destinées à l'optimisation des requêtes. Les transformations CoSort et Hadoop dans Voracity tirent parti des algorithmes de mise à l'échelle linéaire et de la consolidation des tâches, et non de la mémoire ou des ressources d'E/S de la base de données
  • ELT conserve toutes les données dans le SGBDR en permanence – ce qui est bien tant que les données source et cible se trouvent dans la même base de données
  • ELT est parallélisé en fonction de l'ensemble de données, et les E/S de disque sont généralement optimisées au niveau du moteur pour un débit plus rapide – oui, mais c'est encore plus vrai pour les transformations externes qui ne sont pas en concurrence avec les ressources du serveur de base de données 
  • ELT évolue tant que le matériel et le moteur RDBMS peuvent continuer à évoluer – ce qui coûte combien par rapport à l'alternative ci-dessus ?
  • ELT peut atteindre 3 à 4 fois les débits sur la plate-forme RDBMS MPP correctement réglée, ce qui place l'appliance aux niveaux de performances de Voracity par rapport aux outils ETL également, mais à un coût 20 fois supérieur.
  • La transformation ELT est effectuée sur le serveur RDBMS une fois que la base de données est sur la plate-forme cible et qu'elle ne met plus de pression sur le réseau  – elle met donc la pression sur la base de données (utilisateurs) à la place ?
  • ELT a des spécifications de transformation simples via SQL - qui ne sont pas aussi simples, flexibles ou aussi riches en fonctionnalités que la syntaxe CoSort SortCL ou le mappage de champs par glisser-déposer dans l'interface graphique Eclipse de Voracity.
Inconvénients ELT
  • Outils limités disponibles avec prise en charge complète d'ELT – et à des prix très élevés pour les appliances DB vantant des performances à haut volume
  • Perte de statistiques détaillées de surveillance de l'exécution et de lignage des données – en particulier les analyses d'impact des métadonnées sur les modifications apportées à des fichiers, des tables ou des sources non structurées disparates
  • Perte de modularité due à la conception basée sur les ensembles pour la performance - et la perte de fonctionnalité/flexibilité qui en découle
  • Les transformations utiliseraient les ressources de la base de données, ce qui pourrait avoir un impact sur les performances des rapports BI – sans parler des performances des requêtes et des autres opérations de la base de données

Des architectures hybrides telles que ETLT, TELT et même TETLT émergent par la suite pour tenter de combler les faiblesses de l'une ou l'autre approche. Mais ceux-ci semblent ajouter des niveaux supplémentaires de complexité aux processus déjà si lourds. Il n'y a vraiment pas de solution miracle, et de nombreux projets d'intégration de données échouent sous le poids des SLA, des dépassements de coûts et de la complexité.

C'est pour ces raisons qu'IRI a conçu Voracity pour intégrer les données via le programme CoSort SortCL dans les systèmes de fichiers existants ou les structures Hadoop sans recodage. Voracity est la seule plate-forme orientée ETL (bien que prenant également en charge ELT) qui offre les deux options pour les transformations de données externes. En plus d'un rapport qualité-prix supérieur en matière de déplacement et de manipulation de données, Voracity inclut :

  • Transformation avancée des données, qualité des données, MDM et création de rapports
  • dimensions à évolution lente, modification de la capture des données, fédération des données
  • profilage des données, masquage des données, génération de données de test et gestion des métadonnées
  • des scripts 4GL simples que vous ou les assistants, diagrammes et boîtes de dialogue Eclipse créez et gérez
  • exécution fluide dans Hadoop MR2, Spark, Spart Stream Storm et Tez
  • prise en charge des connecteurs intelligents erwin (conversion à partir d'autres outils ETL)
  • Pilotes MongoDB natifs et connexions à d'autres sources NoSQL, Hadoop, cloud et héritées
  • rapports intégrés, statistiques et fonctions prédictives, liens KNIME et Splunk, et flux de données de l'outil d'analyse.

Voir aussi :

  • http://www.iri.com/blog/data-transformation2/etl-elt-iri-in-between
  • http://www.iri.com/solutions/data-integration/etl
  • http://www.iri.com/solutions/data-integration/elt
  • http://www.iri.com/solutions/data-integration/implement