MCG Global Services Benchmark de l'intégration Hadoop

Benchmark de l'intégration Hadoop

Profil et évaluation des produits : Talend et Informatica Par William McKnight et Jake Dolezal Octobre 2015

Sponsorisé par

MCG Global Services Benchmark de l'intégration Hadoop

© MCG Global Services 2015 www.mcknightcg.com Page 2

Synthèse

Ces dix dernières années, Hadoop a acquis une position dominante dans le domaine de la gestion des informations en renforçant les stratégies numériques avec des possibilités à grande échelle. Bien qu'Hadoop aide les organisations orientées données (ou souhaitant le devenir) à surmonter les obstacles liés au volume à stocker et traiter, et au coût de traitement inhérent à des volumes de données croissants, il ne résout pas le problème de l'intégration des données hautes performances : une activité qui utilise au moins 80 % du temps d’obtention d’informations exploitables depuis les big data (mégadonnées). Les outils d'intégration de données modernes ont été conçus dans un monde de données structurées, de bases de données relationnelles et d'entrepôts de données (warehouses). La révolution conceptuelle des big data et d'Hadoop a modifié et rendu caduques certaines des méthodes utilisées pour transformer des données en valeur commerciale. Malheureusement, le domaine des outils d'intégration de données n'a pas su se mettre au diapason de cette révolution. Ceux qui ont, dès leur apparition, fait le choix des big data pour leur architecture d'entreprise n'ont découvert que récemment la variété et sélection d'outils et de fonctionnalités d'intégration de données qui peuvent accompagner leurs capacités croissantes de stockage de données. Hadoop a beaucoup évolué depuis ses débuts où il traitait simplement de grands volumes de données par lot de manière à la fois économique et évolutive. Nombre d’approches et outils sont apparus depuis permettant l’amélioration des capacités et l’élargissement des utilisations potentielles d'Hadoop. Un des nouveaux outils les plus intéressants est Spark, un moteur de traitement multi-étapes en mémoire qui offre des vitesses haute performance, beaucoup plus rapides que celles de ses prédécesseurs basés sur disque. Malgré leurs efforts pour acquérir toutes ces prometteuses capacités les entreprises s'obstinent encore dans l'ancien concept de systèmes OLTP relationnels structurés qui exécutent leurs activités quotidiennes. Ce monde bien présent le restera encore longtemps La solution consiste donc à associer ces capacités afin de rapprocher ces deux mondes. Et la clé en est l'intégration de données qui rapproche les données transactionnelles et de référence des bases de données relationnelles traditionnelles basées sur le SQL et les big data provenant d'une large gamme et variété de sources. De nombreux fournisseurs d'intégration de données ont compris ce concept et pris l’initiative d’intégrer les capacités des big data et d'Hadoop dans leurs ensembles d'outils. L'idée est de donner aux spécialistes de l'intégration de données la capacité d'exploiter ces outils comme ils le feraient avec les sources et transformations traditionnelles auxquelles ils sont habitués. Des fournisseurs toujours plus nombreux s'engagent dans l'arène des big data, il deviendra donc de plus en plus difficile d'identifier et de sélectionner l'outil le plus adapté. Les différenciateurs clés dont il faudra tenir compte seront la profondeur à laquelle un outil exploite Hadoop et la performance des tâches d'intégration. L’accroissement continu des volumes de données à intégrer,

http://www.mcknightcg.com/�



entrainera l’allongement des durées de traitement des tâches d'intégration. Cela pourrait faire la différence entre une réponse « juste à temps » et une arrivant « juste un peu trop tard » . Le benchmark présenté ici est axé sur ces deux différenciateurs. Les fournisseurs séléctionnés pour ce benchmark sont Talend et Informatica. Ce benchmark a été conçu pour simuler un ensemble de scénarios de base en réponse à certaines questions fondamentales sur lesquelles une organisation, quel que soit son secteur d'activité, peut être amenée à se pencher, par opposition à un scénario spécialisé ou un cas d'application dans le cadre d'un « exercice académique » . Nous espérons par ce biais parvenir à identifier, non seulement les performances, mais également le confort d'utilisation. Les résultats du benchmark indiquent que Spark est le grand gagnant : la preuve, il affiche des performances presque 8 fois plus élevées dans le scénario avec la plus grande échelle. Au vu de ces tendances, nous estimons également que le fossé va encore se creuser avec des ensembles de données et des environnements de cluster encore plus importants. De plus, le benchmark révèle également l'avantage qui consiste à exploiter Spark directement via l'outil d'intégration, plutôt que par le biais d’un autre moyen (Hive, dans ce cas), qui s'est avéré peu satisfaisant en raison de son manque de capacités de prise en charge, même par les distributions entreprise d'Hadoop.




À propos des auteurs

William est président de McKnight Consulting Group Global Services (www.mcknightcg.com). Il est reconnu comme autorité mondiale dans le domaine de la gestion des informations. En tant que consultant, il a travaillé avec de nombreuses entreprises du Global 200 et du marché intermédiaire. Ses équipes ont gagné de nombreux concours de bonnes pratiques pour leurs implémentations, et nombre de ses clients ont fait la une des journaux avec leurs succès. Ses stratégies forment le plan de gestion des informations pour les grandes entreprises de différents secteurs. William est l'auteur du livre « Information Management : Strategies for Gaining a Competitive Advantage with Data » . William est un conférencier très réputé dans le monde entier ainsi qu’un écrivain prolifique avec des centaines d'articles et de livres blancs publiés. William est un entrepreneur de renom, ancien directeur technique et ingénieur logiciel de Fortune 50. Il fournit à ses clients stratégies, architectures, sélection de plateformes et outils, et programmes complets pour la gestion d’informations.

Jake Dolezal possède plus de 16 années d'expérience dans le domaine de la gestion d’informations et une grande expertise en Business Intelligence, analyse, entreposage de données (warehousing), statistiques, modélisation et intégration de données, visualisation de données, gestion de données de référence et qualité des données. Jake a de l'expérience dans de nombreux secteurs, notamment la santé, l'éducation, le gouvernement, la fabrication, l'ingénierie, l'hébergement et les jeux. Jake a obtenu son Doctorat en gestion de l’Information à l'université de Syracuse, classée avec constance n°1 pour les systèmes d'informations par U.S. News et World Report. C'est également un professionnel certifié en Business Intelligence via TDWI et spécialisé dans l'analyse de données. Il est également conseiller en leadership et a aidé des clients à évoluer plus rapidement dans leurs




carrières et à bénéficier de plusieurs promotions à des postes de direction. Jake est Chef de pratique chez McKnight Consulting Group Global Services.

À propos de MCG Global Services

Avec une liste de clients qui est « LA » liste de gestion d'informations complexes, politiquement viables et prospères, MCG dispose de nombreux points de contact sur le marché de la gestion de l’information. Nos conseils sont issus des bonnes pratiques les plus actuelles provenant d'une expérience à la fois récente et personnelle. Ils sont pratiques, pas théoriques. Nous anticipons en amont les besoins de nos clients grâce à notre approche basée sur le cycle de vie complet. Nos équipes, constituées d'individus déterminés et expérimentés génèrent des résultats efficaces, économiques, durables et politiquement viables pour nos clients.

• Nous portons une grande attention à la justification opérationnelle. • Nous adoptons une approche par programme et non par projet. • Nous favorisons un modèle de collaboration avec le personnel du client et nous concentrons

sur le transfert de connaissances. • Nous organisons les effectifs et élaborons les processus du client pour progresser. • Nous observons la plus stricte neutralité vis à vis des fournisseurs et vous donnons

l'assurance que nos conseils sont entièrement axés sur le client. • Nous connaissons, définissons, évaluons et favorisons les bonnes pratiques. • Nous avons rencontré et dépassé les défis de gestion des informations les plus

inconcevables. • Nous garantissons que les résultats de l'entreprise seront livrés rapidement et fréquemment.

Les services MGS intègrent la stratégie, l'implémentation et la formation pour transformer les informations en ressources utiles à votre organisation. Nous mettons en place stratégies et conceptions et les déployons dans des disciplines telles que la Gestion des données de référence, les big data, l'entreposage de données, les bases de données analytiques et le Business Intelligence.

Hadoop et l'intégration de données

Ce benchmark fait partie de la recherche de la performance des charges sur les clusters Hadoop, une plateforme d’importance croissante de stockage des données qui fournissent les stratégies numériques.




L'utilisation d'Hadoop a évolué depuis l'invention de cette technologie dont l'objectif était de rendre le traitement par lot des big data économique et évolutif. Aujourd'hui, avec une communauté live de contributeurs Open source et de fournisseurs qui innovent dans une multitude d'outils prenant en charge de manière native les composants Hadoop, l'utilisation et les données se développent. Les référentiels de données brutes (data lakes) incarnent l'idée du stockage de toutes les données en mode natif dans Hadoop. Traditionnellement, la préparation des données consomme environ 80 % des efforts de développement analytique. Une des utilisations les plus courantes d'Hadoop est la réduction des frais analytiques. La préparation de données peut être effectuée via un processus ETL traditionnel : extraire les données des sources, les transformer (nettoyage, normalisation, intégration) pour répondre aux exigences des référentiels et des applis des entrepôts de données ou en aval et les charger dans ces destinations. Comme dans le monde des bases de données relationnelles, de nombreuses organisations préfèrent les processus ELT qui permettent d'obtenir de meilleures performances en effectuant des transformations après le chargement. Cependant, au lieu de surcharger les entrepôts de données avec ce traitement, vous effectuez les transformations dans Hadoop. Cela génère des processus haute performance, tolérants aux pannes et extensibles, sans nuire aux vitesses des requêtes. Dans les environnements Hadoop, vous avez également besoin d'une énorme puissance de traitement car les transformations impliquent souvent l'intégration de différents types de données provenant de nombreuses sources. Vos analyses peuvent inclure les données des systèmes ERP et CRM, les environnements analytiques en mémoire et les applications internes et externes via les API. Vous voudrez peut-être mélanger et distiller les données des fichiers maîtres clients avec des données de navigation stockées dans les Clouds et des données de reseaux sociaux de vos propres bases de données NoSQL ou accessibles depuis des services d'agrégation tiers. Vous voudrez peut-être examiner d'énormes quantités de données transactionnelles historiques avec du streaming de données en temps réel provenant des transactions, machines, capteurs ou puces des consommateurs. Hadoop peut intégrer toutes ces données structurées, non structurées, semi-structurées et multi-structurées car il permet un stockage et un traitement sans schéma. Lorsque vous intégrez vos données dans Hadoop, il n'est pas nécessaire de déclarer un modèle de données ou d'effectuer des associations avec les applications cibles. Au lieu de cela, des associations libres sont utilisées pour appliquer ou découvrir un schéma de données après transformation, lorsque les données sont écrites dans l'application de production cible ou dans le répertoire d'analyse en aval spécialisé. Cette séparation des processus d'intégration de données et du moteur d'exécution permet de :

• Partager et réutiliser les transformations dans les projets d'intégration de données • Afficher les données de différentes façons et exposer de nouveaux éléments de données en

appliquant différents schémas




• Améliorer les ensembles de données en ajoutant de nouvelles dimensions au fur et à mesure que de nouvelles informations deviennent disponibles ou que des questions supplémentaires surgissent.

Il existe d'innombrables sources des big data et d'autres apparaissent constamment. Depuis les limites rencontrées par des services open source à faibles performances tels que Sqoop, Flume, HDFS par ligne de commande et Hive, de nombreux approches et outils sont apparus pour répondre au défi de l'intégration des données Hadoop. Alors qu’il existe de nombreuses études sur les requêtes de données dans Hadoop, il n’en va pas de même pour l'obtention des données dans les clusters Hadoop. De nombreuses entreprises apportent dans le monde Hadoop les fonctionnalités et fonctions auxquelles elles sont habituées dans le monde relationnel, ainsi que des exigences non fonctionnelles, la productivité des développeurs, la gestion des métadonnées, la documentation et gestion des règles métier que vous offre un outil d'intégration des données moderne. Les fournisseurs faisant l'objet du benchmark dans ce rapport sont Talend et Informatica.




Profil du produit Talend

Profil de l'entreprise

Nom du produit Talend Big Data Integration

Lancement initial 2012

Version actuelle et date Version 6.0, expédiée en septembre 2015

Caractéristiques principales

Support natif de Apache Spark et de Spark Streaming qui s'appuient sur plus de 100 composants Spark, la conversion en un clic des tâches MapReduce en Spark, la prise en charge de la livraison continue, la gestion des données de référence (MDM), l'API REST et la prise en charge du langage de requêtes, le masquage des données et l'analyse sémantique

Concurrents d'Hadoop en intégration de données

Informatica, Pentaho, Syncsort

Création de l'entreprise 2006

Centres d’intérêt Solutions d'intégration hautement évolutives qui s'adressent aux big data, à l'intégration des applications, l'intégration de données, la qualité des données, la MDM et BPM

Employés 500

Siège social Redwood City, Californie

Propriété Privée




Profil du produit Informatica

Profil de l'entreprise

Nom du produit Informatica Big Data Edition

Lancement initial 2012

Version actuelle et date Version 9.6.1, expédiée en 2015

Caractéristiques principales

Toutes les fonctions sur Hadoop, Universal Data Access, ingestion et extraction de données à haute vitesse, collecte et streaming de données en temps réel, découverte de données sur Hadoop, traitement automatique du langage naturel sur Hadoop, Attunity Replicate entièrement intégrées ; améliorations supplémentaires de l'interface utilisateur graphique ; autres plateformes cibles

Concurrents d'Hadoop en intégration de données

Talend, Pentaho, Syncsort, Tervela

Date de fondation 1998

Centres d'intérêt Numéro un mondial des fournisseurs indépendants de logiciels d'intégration de données.

Employés +5 500

Siège social Redwood City, Californie

Propriété Privée (anciennement publique)




Présentation du benchmark

L'objectif de la conception de ce benchmark était de simuler un ensemble de scénarios de base pour répondre aux questions fondamentales sur lesquelles une organisation, quel que soit son secteur d'activité, peut être amenée à se pencher. Ces questions courantes formulées pour le benchmark sont les suivantes :

• Nos clients et les visiteurs de notre site Web déclenchent un certain nombre d'affichages. Quel est l'impact de ces affichages sur les ventes ? En moyenne, combien de pages sont vues avant une décision d'achat (en ligne ou en magasin) ?

• Quel est l'impact de nos campagnes promotionnelles à base de coupons sur nos ventes de produits ou l'utilisation de nos services ? Les clients et prospects qui consultent ou reçoivent nos promotions à base de coupons sont-ils incités à visiter notre site Web et à acheter plus ou/et d'autres produits que s'ils n’avaient pas bénéficié de ces coupons ?

• Notre moteur de recommandation est-il efficace pour influencer ou stimuler les ventes ? Les clients ont-ils tendance à acheter plus ou/et d'autres produits grâce à ces recommandations personnalisées ?

Notre expérience de collaboration avec des clients provenant de nombreux secteurs d'activité au cours des dix dernières années montre que ces questions ne sont pas des questions de spécialistes mais des questions courantes sur lesquelles se sont penchées de nombreuses entreprises. Ce benchmark a été conçu pour montrer comment une entreprise peut approcher la réponse à ces questions en apportant différentes sources d'informations. Nous avons également saisi l'occasion de montrer comment Hadoop peut être exploité, car certaines des données intéressantes de ce cas d'analyse sont probablement d'un volume important et non relationnelles ou semi ou non-structurées par nature. Dans ces cas-là, l'utilisation d'Hadoop serait probablement le meilleur choix que nous recommanderions à un client cherchant des réponses à ces questions. Ce benchmark a été conçu comme un benchmark d'intégration de données, car il est également fort probable que les données requises se trouvent dans différentes sources. Certaines de ces sources sont également probablement non consommées et agrégées dans un entrepôt de données de l'entreprise, en raison du volume élevé et de la difficulté à intégrer des quantités importantes de données semi-structurées dans un entrepôt de données traditionnel. Par conséquent, le benchmark a été conçu pour imiter un scénario courant et les défis que doit relever une organisation qui cherche à intégrer des données pour répondre à ces questions et à d'autres questions semblables.




Configuration du benchmark

Le benchmark a été exécuté à l'aide de la configuration, de l'environnement, des normes et des configurations suivantes.

Environnement de serveur

Figure 1 : Environnement et configuration du serveur

Caractéristique Sélection

Hadoop Distribution Cloudera CDH 5.4.7

Instance EC2 Mémoire optimisée r3.xlarge (4 vCPU, Mémoire 30,5 Go, Stockage 200 Go)

SE Ubuntu LTS 14.04 (Trusty Tahr)

Types de données sources Fichiers journaux basés sur le texte et une base de données relationnelle

Volume de données 20 Go (fichiers journaux) et 12 000 000 de lignes (RDBMS)

Facteur d'échelle TPC-H 0,125x – 2x

RDBMS MySQL 5.6

Version Java 1.6.0_87




Le benchmark a été mis en place à l'aide des instances EC2 des Amazon Web Services (AWS) déployées dans un AWS Virtual Private Cloud (VPC) dans le même groupe de placement. Selon Amazon, toutes les instances lancées au sein d'un groupe de placement ont une latence basse, une bissection complète, une bande passante de 10 Gigaoctets par seconde entre les instances. La première instance EC2 était une mémoire optimisée r3.xlarge avec 4 vCPU et 30,5 Go de RAM. Un volume de stockage de 200 Go a été ajouté et monté sur l'instance. Cette instance Linux exécutait Ubuntu LTS 14.04 (surnommée Trusty Tahr). Sur cette instance, nous avons déployé Cloudera CDH 5.4.7 comme notre distribution Hadoop avec MySQL 5.6 pour service de base de données relationnelle source. La deuxième instance EC2 était une machine r3.xlarge sous Windows Server 2012. L'instance Windows a été installée avec les suites de développeur Talend Studio et Informatica Big Data Edition (BDE). REMARQUE : afin d'exécuter Informatica BDE, une 3ème instance EC2 a été utilisée pour exécuter les services de domaine et de référentiel requis pour Informatica. Il s'agissait d'une machine RedHat Linux uniquement utilisée pour servir de service de référentiel Informatica. Elle n'était pas impliquée dans le processus de données ou d'exécution du benchmark. La source relationnelle pour le benchmark (stockée dans MySQL 5.6 sur l'instance Linux) a été construite à l'aide de Transaction Processing Performance Council TPC Benchmark H (TPC-H) Revision 2.17.1 Standard Specification. La base de données TPC-H a été créée pour imiter un système de point de vente réel selon le diagramme entité-relation et le type de données et les spécifications d'échelle fournis par le TPC-H. La base de données a été remplie par des scripts peuplés de chiffres aléatoires pour créer le faux ensemble de données. Les spécifications TPC-H ont un facteur d'échelle dont est dérivé le nombre d'enregistrements pour chaque tableau. Pour ce benchmark, nous avons sélectionné un facteur d'échelle maximum de 2. Dans ce cas, la base de données TPC-H contenait 3 millions d'enregistrements dans le tableau ORDERS et 12 millions d'enregistrements dans le tableau LINEITEM.




Source relationnelle

Figure 2 : TPC-H ER Diagram ©1993-2014 Transaction Processing Performance Council

Sources des fichiers journaux Les trois autres sources de données à utiliser dans les routines d'intégration pour le benchmark ont été créées en tant que fichiers journaux ASCII semi-structurés basés sur le texte. Trois fichiers journaux ont été créés pour imiter les fichiers journaux réels pour trois cas :

1. Journal de clics Web

2. Journal de coupons

3. Journal de moteurs de recommandations

Journal de clics Web Un journal de clics Web a été généré de la même façon qu'un fichier journal de serveur Web Apache standard. Le fichier journal a été généré à l'aide des scripts pour simuler deux types d'entrée : 1)




affichages de page entièrement aléatoires (remplis par des chiffres aléatoires) et 2) clics Web qui correspondent aux affichages de page réels des produits commandés (remplis par des enregistrements aléatoires dans les tableaux TPC-H ORDERS et LINEITEMS). Les entrées de journaux Web « factice » ou « bruit » sont apparues dans un grande nombre de possibilités mais dans un format similaire cohérent avec l'entrée de journaux de clics Web Apache. Toutes les données ont été sélectionnées de manière aléatoire. Les dates étaient limitées à l'année 2015. Par exemple : 249.225.125.203 - anonymous [01/Jan/2015:16:02:10 -0700] "GET /images/footer-basement.png HTTP/1.0" 200 2326 "http://www.acmecompany.com/index.php" "Windows NT 6.0"

Les entrées de journaux Web « signal » qui correspondaient au (et étaient remplies avec) les enregistrements ORDERS et LINEITEM réels avaient le même caractère aléatoire que les entrées « factices » . Cependant, les valeurs LINEITEM.L_PARTKEY réelles et les valeurs ORDERS.O_ORDERDATE correspondantes de la base de données TPC-H ont été sélectionnées pour créer des enregistrements et représenter un affichage de page d'un article réel commandé le même jour que la commande. Les segments en surbrillance représentent ceux qui pourraient correspondre aux commandes réelles : 154.3.64.53 - anonymous [02/Jan/2015:06:03:09 -0700] "GET /images/side-ad.png HTTP/1.0" 200 2326 "http://www.acmecompany.com/product-search.php?partkey=Q44271" "Android 4.1.2"

Le fichier journal de clics Web contenait 26 009 338 entrées et faisait 5,1 Go. Il y avait une entrée de clic Web pour un enregistrement LINEITEM aléatoire pour chaque enregistrement ORDERS ( 3 000 000 au total). Par conséquent, 12 % des entrées de journaux de clics Web correspondaient aux commandes. Le reste des entrées était aléatoire. Journal de coupons Un journal de coupons a été généré de la même façon qu'un fichier journal de serveur Web Apache personnalisé. Le journal de coupons a été conçu pour imiter un fichier journal spécifique généré dès qu'un client potentiel examinait un article en raison d'un clic provenant d'une campagne de publicité à base de coupons. De nouveau, le fichier journal a été généré à l'aide des scripts pour simuler deux types d'entrée : 1) des affichages de page entièrement aléatoires (remplissage par des chiffres aléatoires) et 2) des affichages de page qui correspondent aux affichages de page réels des produits commandés par des clients réels via la campagne de publicité à base de coupons (remplissage par des enregistrements aléatoires dans les tableaux TPC-H ORDERS, LINEITEMS et CUSTOMERS). Les données d'entrée du journal de coupons « factice » ou « bruit » ont été sélectionnées de manière aléatoire. Les dates étaient limitées à l'année 2015. Les entrées de journaux de coupons « signal » qui correspondaient au (et étaient remplies avec) les enregistrements ORDERS et LINEITEM réels avaient le même caractère aléatoire que les entrées « factices » . Cependant, les valeurs LINEITEM.L_PARTKEY réelles et les valeurs ORDERS.O_ORDERDATE correspondantes de la base de




données TPC-H ont été sélectionnées pour créer des enregistrements et représenter un affichage de page d'un article réel commandé le même jour que la commande. Les segments en surbrillance représentent ceux qui pourraient correspondre aux commandes réelles : 49.243.50.31 - anonymous [01/Jan/2015:18:28:14 -0700] "GET /images/header-logo.png HTTP/1.0" 200 75422 "http://www.acmecompany.com/product-view.php?partkey=S22211" "https://www.coupontracker.com/campaignlog.php?couponid=LATEWINTER2015&customerid=C019713&trackingsnippet=LDGU-EOEF-LONX-WRTQ" "Windows Phone OS 7.5"

Le fichier journal de coupons contenait 20 567 665 entrées et faisait 6,6 Go. Il y avait une entrée de clics Web pour un enregistrement LINEITEM aléatoire pour chaque enregistrement ORDERS ( 3 000 000 au total). Par conséquent, 15 % des entrées de journaux de coupons correspondaient aux commandes. Le reste des entrées était aléatoire. Journal de recommandations Un journal de moteurs de recommandations a été généré sous la forme d'un fichier journal de sortie avec balises XML. Le journal de recommandations a été conçu pour se reproduire dès qu'un client potentiel examinait un article en raison d'un clic provenant d'un article recommandé sur la page de l'article actuelle. Dans ce cas, le site Web de l'entreprise recommandait 5 articles supplémentaires ou associés pour chaque article consulté. De nouveau, le fichier journal a été généré à l'aide des scripts pour simuler deux types d'entrée : 1) affichages de pages « factices » ou entièrement aléatoires et recommandations aléatoires (remplissage par des chiffres aléatoires) et 2) affichages de pages qui correspondent aux affichages de pages réels des produits commandés via les recommandations (remplissage par des enregistrements aléatoires dans les tableaux TPC-H ORDERS et LINEITEMS). Les données d'entrée du journal de recommandations « factices » ou « bruit » ont été sélectionnées de manière aléatoire. Les dates étaient limitées à l'année 2015. Les entrées de journaux de recommandations « signal » qui correspondaient au (et étaient remplies avec) les enregistrements ORDERS et LINEITEM réels avaient le même caractère aléatoire que les entrées « factices » . Cependant, les valeurs LINEITEM.L_PARTKEY réelles et les valeurs ORDERS.O_ORDERDATE correspondantes de la base de données TPC-H ont été sélectionnées pour créer des enregistrements et représenter un affichage de page d'un article réel commandé le même jour que la commande. Les segments en surbrillance représentent ceux qui pourraient correspondre aux commandes réelles : <itemview>

<cartid>326586002341098</cartid> <timestamp>01/01/2015:16:53:07</timestamp> <itemid>Q48769</itemid> <referreditems>

<referreditem1> <referreditemid1>R33870</referreditemid1> </referreditem1> <referreditem2> <referreditemid2>P19289</referreditemid2> </referreditem2> <referreditem3> <referreditemid3>R28666</referreditemid3> </referreditem3> <referreditem4>




<referreditemid4>P72469</referreditemid4> </referreditem4> <referreditem5> <referreditemid5>S23533</referreditemid5> </referreditem5>

</referreditems> <sessionid>CGYB-KWEH-YXQO-XXUG</sessionid>

</itemview>

Le fichier journal de recommandations contenait 13 168 336 entrées et faisait 8,3 Go. Il y avait une entrée de clics Web pour un enregistrement LINEITEM aléatoire pour chaque enregistrement ORDERS ( 3 000 000 au total). Par conséquent, 23 % des entrées de journaux de recommandations correspondaient aux commandes. Le reste des entrées était aléatoire.

Facteur d'échelle Chacune des sources de données décrites ci-dessus était également mise à l'échelle sur différents facteurs d'échelle, afin que les routines d'intégration (décrites dans la section suivante) puissent être exécutées en fonction de sources de données de différentes tailles. La base de données TPC-H et les fichiers journaux ont été mis à l'échelle de la manière suivante :

Facteur d'échelle 2,0 1,0 0,5 0,25 0,125 Enregistrements LINEITEM

12 000 000 6 000 000 3 000 000 1 500 000 750 000

Enregistrements ORDERS

3 000 000 1 500 000 750 000 375 000 187 500

Enregistrements CUSTOMERS

300 000 150 000 75 000 37 500 18 750

Taille totale des journaux

20 Go 10 Go 5 Go 2,5 Go 1,25 Go

Taille des journaux de clics Web

5,1 Go 2,6 Go 1,3 Go 638 Mo 319 Mo

Entrées des journaux de clics Web

26 009 338 13 004 669 6 502 335 3 251 167 1 625 584

Taille des journaux de coupons

6,6 Go 3,3 Go 1,7 Go 825 Mo 413 Mo

Entrées des journaux de coupons

20 567 665 10 283 833 5 141 916 2 570 958 1 285 479

Taille des journaux de recommandations

8,3 Go 4,2 Go 2,1 Go 1,0 Go 519 Mo

Entrées des journaux de recommandations

13 168 336 6 584 168 3 292 084 1 646 042 823 021

Tableau 1 : Nombre d'enregistrements et fichiers journaux de la base de données TPC-H à différents facteurs d'échelle




Routines d'intégration Le cas d'usage des big data du benchmark a été conçu pour présenter des scénarios réels là où les entreprises désirent intégrer des données de leurs systèmes transactionnels à des big data non structurés et semi-structurés. Le benchmark le démontre en exécutant des routines qui intègrent les données sources relationnelles TPC-H aux fichiers journaux individuels décrits ci-dessus. Les routines d'intégration suivantes ont été créées pour le benchmark. Dans les deux cas, des bonnes pratiques ont été observées pour optimiser la performance de chaque tâche. Par exemple, il n'y avait pas de conversion de type de données ; les dates étaient traitées comme des chaînes et les tailles de types de données étaient réduites. Workflow Informatica Le diagramme suivant représente le workflow qui a été créé dans Informatica Developer.

Figure 3 : Présentation du workflow Informatica Informatica Big Data Edition offre deux manières d'interagir avec Hadoop ; via Hive ou directement sur le Système de fichiers Hadoop (HDFS). La première partie était l'extraction des données MySQL en utilisant exactement la même requête sur My SQL qu'avec le Job Talend. Ces données ont été stockées dans Hadoop avec Hive. Puis, les fichiers journaux Web, de coupons et de recommandations ont été analysés avec les mêmes expressions régulières que celles qui seront utilisées avec les Jobs Talend et chargées directement dans HDFS. La 3ème partie consistait en l'intégration des données TPC-H aux fichiers journaux avec la transformation de recherche d'Informatica. Les fichiers délimités en résultant ont également été stockés sur HDFS. Ces routines seront décrites plus en détail dans la section suivante.




Remarque : au moment du benchmark, Informatica BDE n'avait pas de connecteur MySQL inclus dans le package que nous avons installé. Un connecteur ODBC générique a été utilisé à la place. Cela n'a pas paru avoir un impact général sur les performances de la tâche d'intégration.




Conception d'un Job Talend Le diagramme suivant représente la conception d'un Job qui a été créé dans Talend Studio.

Figure 4 : Présentation de la conception d'un Job Talend Talend Studio 6 propose une nouvelle fonctionnalité puissante d'interaction avec Spark sur Hadoop en plus de l'approche conventionnelle via Hive ou directement sur le système de fichiers Hadoop (HDFS). La première partie était l'extraction des données MySQL en utilisant la requête suivante sur MySQL : SELECT L_ORDERKEY, L_PARTKEY, O_CUSTKEY, O_ORDERDATE FROM LINEITEM LEFT OUTER JOIN ORDERS ON L_ORDERKEY = O_ORDERKEY;

Ces données ont été stockées dans Spark. Ensuite, les fichiers journaux Web, de coupons et recommandations ont été analysés avec des expressions régulières et chargées directement dans Spark. La 3ème partie consistait à intégrer des données TPC-H aux fichiers journaux avec la transformation tMap de Talend. Les fichiers délimités en résultant ont été stockés directement sur le HDFS. Informatica et Spark Nous avons envisagé et même tenté d'exécuter le benchmark avec Informatica BDE sur Spark via Hive. Nous avons pu configurer Hive pour exploiter Spark pour l'exécution en utilisant les outils d'administration Cloudera CDH. Cependant, des incohérences importantes sont apparues dans l'exécution rendant cette utilisation instable. Selon Cloudera, concernant l'utilisation de Hive sur Spark, l'exclusion suivante existe :

Important : Hive sur Spark est inclus dans CDH 5.4 mais n'est pas pris en charge ni recommandé actuellement pour une utilisation de production. Si cette fonctionnalité vous




intéresse, essayez-la dans un environnement test jusqu'à ce que nous corrigions les problèmes et limites nécessaires à l'utilisation dans un environnement de production.

Par conséquent, cette méthode a été jugée instable et considérée comme un cas d'usage inadapté au moment du benchmark.

Résultats du benchmark

Cas d'usage 1 : E-influence L'objectif du premier cas d'usage pour le benchmark était de préparer un ensemble de données mettant en relation les produits commandés avec les affichages de page sur le site Web de commerce électronique. Les tâches d'intégration étaient créées pour mapper les affichages de page aux produits commandés. Le diagramme suivant est un mappage conceptuel de l'intégration. Dans Informatica, la transformation de recherche a été utilisée pour associer le journal de clics Web aux enregistrements dans la base de données TPC-H à l'aide du champ PARTKEY. Dans Talend, la transformation tMap a été utilisée.

Figure 5 : Mappage E-influence Durées d'exécution Le tableau suivant répertorie les durées d'exécution du mappage E-influence (clics Web) en secondes. Clic Web (Cas d'usage 1) SF 2.0 SF 1.0 SF 0.5 SF 0.25 SF 0.125 Informatica-MapReduce 5 221 1 977 622 308 111 Talend-Spark 579 383 257 148 88 Tableau 2 : Durées d'exécution du mappage E-influence




Cas d'usage 2 : Influence relative aux coupons L'objectif du deuxième cas d'usage pour le benchmark était de préparer un ensemble de données mettant en relation les produits commandés et une campagne de publicité basée sur les coupons. Les tâches d'intégration ont été créées pour mapper les affichages de pages associés aux publicités basées sur les coupons et les clients aux produits commandés. Le diagramme suivant est un mappage conceptuel de l'intégration. Dans Informatica, la transformation de recherche a été utilisée pour associer le journal de coupons aux enregistrements dans la base de données TPC-H à l'aide du champ PARTKEY et CUSTKEY. Dans Talend, la transformation tMap a été utilisée.

Figure 6 : Mappage de l'influence des coupons Durées d'exécution Le tableau suivant répertorie les durées d'exécution du mappage d'influence des coupons en secondes. Coupon (Cas d'usage 2) SF 2.0 SF 1.0 SF 0.5 SF 0.25 SF 0.125 Informatica-MapReduce 8 573 3 197 1 210 693 396 Talend-Spark 882 478 331 202 169 Tableau 3 : Durées d'exécution du mappage des coupons




Cas d'usage 3 : Influence des recommandations L'objectif du 3ème cas d'usage pour le benchmark était de préparer un ensemble de données qui mette en relation les produits commandés et l'influence d'un moteur de recommandations. Les tâches d'intégration ont été créées pour mapper les produits recommandés aux produits commandés. Le diagramme suivant est un mappage conceptuel de l'intégration. Dans Informatica, la transformation de recherche a été utilisée pour associer le journal de coupons aux enregistrements dans la base de données TPC-H à l'aide du champ PARTKEY cinq fois. Dans Talend, la transformation tMap a été utilisée.

Figure 7 : Mappage de l'influence des recommandations Durées d'exécution Le tableau suivant répertorie les durées d'exécution en secondes du mappage de l'influence des recommandations. Recommandation (Cas d'usage 3) SF 2.0 SF 1.0 SF 0.5 SF 0.25 SF 0.125 Informatica-MapReduce 14 973 6 544 2 802 1 272 590 Talend-Spark 1 313 701 473 236 188 Tableau 4 : Durées d'exécution du mappage des recommandations




Récapitulatif des résultats Les tableaux suivants sont l'ensemble de résultats complet. Toutes les durées d'exécution sont affichées en secondes (sauf mention contraire). Récapitulatif des facteurs d'échelle SF 2.0 SF 1.0 SF 0.5 SF 0.25 SF 0.125 Enregistrements TPCH LINEITEM 12 000 000 6 000 000 3 000 000 1 500 000 750 000 Taille des fichiers journaux (totale) 20 Go 10 Go 5 Go 2,5 Go 1,25 Go

Durées d'exécution de + MapReduce Informatica-MapReduce SF 2.0 SF 1.0 SF 0.5 SF 0.25 SF 0.125 Charger TPCH (MySQL) dans Hadoop 859 711 349 164 95 Charger le journal Web dans Hadoop 388 360 76 43 22 Charger le journal de coupons dans Hadoop 504 404 111 58 32 Charger le journal de recommandations dans Hadoop 578 442 129 65 33 Clic Web (Cas d'usage 1) 5 221 1 977 622 308 111 Coupon (Cas d'usage 2) 8 573 3 197 1 210 693 396 Recommandation (Cas d'usage 3) 14 973 6 544 2 802 1 272 590 TOTAL 31 096 13 635 5 299 2 603 1 279 TOTAL (Minutes) 518,3 227,3 88,3 43,4 21,3 TOTAL (Heures) 8,6 3,8 1,5 0,7 0,4

Durées d'exécution de + Talend-Spark SF 2.0 SF 1.0 SF 0.5 SF 0.25 SF 0.125 Charger TPCH (MySQL) dans Spark 748 642 302 143 82 Charger le journal Web dans Spark 158 79 33 21 12 Charger le journal de coupons dans Spark 213 123 59 33 17 Charger le journal de recommandations dans Spark 204 117 55 31 16 Clic Web (Cas d'usage 1) 579 383 257 148 88 Coupon (Cas d'usage 2) 882 478 331 202 169 Recommandation (Cas d'usage 3) 1 313 701 473 236 188 TOTAL 4 097 2 523 1 510 814 572 TOTAL (Minutes) 68,3 42,1 25,2 13,6 9,5 TOTAL (Heures) 1,1 0,7 0,4 0,2 0,2 Tableau 5 : Synthèse




Le diagramme suivant est une comparaison des durées d'exécution totales du workflow Informatica et des Jobs Talend nécessaires au chargement, aux transformations et à la génération de fichiers. Des lignes de régression ont été ajoutées.

+ SF 0.125 SF 0.25 SF 0.5 SF 1.0 SF 2.0 Fois plus rapide 2,2x 3,2x 3,2x 5,2x 7,2x Figure 8 : Comparaison des durées d'exécution totales

Conclusion

L'exploitation directe de Spark offre un avantage indéniable dans la capacité à traiter des ensembles de données de taille croissante. Lorsque la taille des ensembles de données était relativement petite (c'est-à-dire moins de 3 millions d'enregistrements transactionnels et des fichiers journaux de 5 Go), la différence de durée d'exécution était négligeable, car les deux outils pouvaient accomplir les tâches en moins d'une heure. Cependant, une fois le facteur d'échelle 0,5 atteint, la différence est devenue significative. À un facteur d'échelle de 2,0, la réalisation de la tâche Informatica a duré plus de 8 heures. Des durées d'exécution croissantes représenteront un problème pour les analystes et les scientifiques de données souhaitant effectuer leurs expérimentations sur les données et leurs analyses avancées mais devant attendre une journée pour que leurs ensembles de données cibles soient intégrés. L'ajout de complications dans les mappages (plusieurs clés de recherche) a semblé




accentuer ce problème. En utilisant MapReduce, la transformation de recherche s’enferme dans des performances médiocres pendant que la mémoire cache des données de recherche et celle de l'index sont surchargées. En exploitant les capacités en mémoire (in-memory) de Spark, les utilisateurs peuvent intégrer beaucoup plus rapidement leurs données. Spark s'appuie sur un mécanisme ultra-rapide d'appels vers des systèmes distants (RPC) qui optimise la distribution et planification des tâches. En outre, le traitement repose sur un pool de threads et non sur un pool de processus exécutés par des machines virtuelles Java (JVM). Ce qui permet à Spark de planifier et exécuter les tâches en quelques millisecondes, alors que la planification Informatica MapReduce exige parfois plusieurs secondes (ou minutes !) dans les clusters très actifs. Spark via Hive ne constituerait pas une bonne approche pour obtenir les résultats présentés ici. Les résultats d'exécution oscilleraient d'incohérents à indéfinis. Développer une bonne utilisation de Spark pour un fournisseur revient presque à développer un produit de zéro. Cela demande des années et coûte des millions de dollars. Utiliser l'ensemble des capacités de Spark pour l'intégration de données avec Hadoop est une approche gagnante.


cmaindron

Typewritten Text

WP206-FR

cmaindron

Typewritten Text

cmaindron

Typewritten Text

cmaindron

Typewritten Text

Documents

MCG Global Services Benchmark de l'intégration Hadoop