Benchmark zur Hadoop-Integration - info.talend.com · Benchmark zur Hadoop-Integration Produktprofil und -auswertung: Talend und Informatica . von William McKnight und Jake Dolezal

Benchmark zur Hadoop-Integration

Produktprofil und -auswertung: Talend und Informatica von William McKnight und Jake Dolezal Oktober 2015

Gefördert von

MCG Global Services Benchmark zur Hadoop-Integration

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

Zusammenfassung

Hadoop hat seine Marktanteile im Bereich der Informationsverwaltung in den letzten 10 Jahren immer mehr steigern können. Dies liegt nicht zuletzt daran, dass Hadoop die Umsetzung digitaler Strategien mit seinen umfassenden Möglichkeiten voranbringt. Dabei unterstützt Hadoop zwar datengestützte Unternehmen (bzw. solche, die es sein wollen) bei der Überwindung von Hindernissen im Speicher- und Prozessorbereich wie auch bei der Einsparung von Kosten, die aufgrund immer größerer Datenmengen anfallen. Nicht gelöst wird jedoch die Herausforderung einer leistungsfähigen Datenintegration (und zwar weder durch noch in Hadoop). Es ist jedoch ausgerechnet die Datenintegration, die dafür verantwortlich ist, dass geschätzt mindestens 80 Prozent der Zeit damit verbracht wird, Big-Data-Beständen umsetzbare Informationen zu entnehmen. Moderne Datenintegrationstools wurden in einer Welt entwickelt, in der strukturierte Daten, relationale Datenbanken und Data Warehouses im Überfluss vorhanden waren. Der durch Big Data und Hadoop bedingte Paradigmenwechsel hat jedoch die Vorgehensweisen, mit denen wir Wertbeiträge aus Daten erzielen, zu großen Teilen umgekrempelt. Bedauerlicherweise vollzieht der Markt für Datenintegrationstools diesen Paradigmenwechsel nur mit Verzögerung. Auch Unternehmen, die in ihrer Architektur eigentlich schon lange auf Big Data setzen, finden erst seit Kurzem eine ausreichende Auswahl an Tools und Funktionen zur Datenintegration, die ihren erhöhten Datenspeicherungsbedarf angemessen unterstützen können, am Markt. Zu Beginn konnte Hadoop große Datenmengen kostengünstig und skalierbar lediglich im Batch bearbeiten, doch seither hat sich allerlei getan. Zahlreiche Methoden und Tools wurden entwickelt, um den Funktionsumfang und mögliche Anwendungsfälle für Hadoop zu erweitern. Eines der aufregendsten neuen Tools dabei ist Spark. Spark ist eine mehrstufige In-Memory-Engine zur Datenverarbeitung, die eine hohe Leistungsfähigkeit bei sehr viel schnellerer Verarbeitung bietet als seine festplattenbasierten Vorgänger. Zwar würden die Unternehmen nichts lieber tun, als all diese aufregenden Funktionen sofort einzusetzen, doch noch immer sind sie fest dem alten Paradigma der relationalen, strukturierten OLTP-Systeme verhaftet, auf denen nach wie vor ihr Tagesgeschäft fußt. Diese Welt wird uns noch eine lange Zeit begleiten. Der Schlüssel zur Behebung des Problems besteht darin, diese beiden Welten miteinander zu verbinden. Und dieser Schlüssel heißt Datenintegration: Transaktions- und Stammdaten aus traditionellen relationalen Datenbanken auf SQL-Basis werden mit Big Data aus einer ungeheuren Vielzahl unterschiedlicher Quellen zusammengeführt. Viele Anbieter von Datenintegrationssoftware haben sich diese Methode bereits zu eigen gemacht und stellen sich der Herausforderung, indem sie ihre Produktpaletten mit Funktionen für Big Data und Hadoop erweitern. Datenintegrationsexperten sollen diese Tools dabei so verwenden können, wie sie es von den traditionellen Quellen und Transformationen her kennen.

http://www.mcknightcg.com/�



Weil nun jedoch so viele Anbieter ihren Hut in den Ring geworfen haben, wird es immer schwieriger, das beste oder am besten geeignete Big-Data-Tool zu finden und auszuwählen. Die wesentlichen Faktoren sind dabei der Umfang, in dem ein Tool Hadoop nutzt, und die Leistungsfähigkeit der Integrationsaufträge. In dem Maße, in dem das Volumen der zu integrierenden Daten immer größer wird, verlängern sich auch die Bearbeitungszeiten von Integrationsaufträgen. Und eine solche Verlängerung der Dauer könnte genau den Unterschied zwischen einer rechtzeitigen Bereitstellung und dem Ergebnis „zu wenig, zu spät“ ausmachen. Der hier präsentierte Benchmark legt den Schwerpunkt auf diese beiden Unterscheidungsmerkmale. Gegenstand des Benchmarkings sind die Anbieter Talend und Informatica. Für den Benchmark wurde eine Reihe einfacher Szenarios simuliert, um einige grundlegende geschäftliche Fragen zu beantworten, die sich Organisationen aus praktisch allen Industriebereichen stellen könnten. Dieser Ansatz steht im Gegensatz zu Nischenszenarios oder explizit akademischen Anwendungsfällen. Mit dieser Vorgehensweise hoffen wir, nicht nur die Leistungsfähigkeit, sondern auch den Nutzen der jeweiligen Lösung quantifizieren zu können. Die Ergebnisse des Benchmarks zeigen, dass der Gewinner nur Spark heißen kann. Allein im umfangreichsten Szenario konnte sich die Lösung durch einen um den Faktor 8 höheren Leistungsvorsprung auszeichnen. Zudem lassen die Tendenzen erahnen, dass diese Kluft bei größeren Datenmengen und größeren Clusterumgebungen eher noch breiter werden wird. Der Benchmark zeigt auch, welche Vorteile die direkte Nutzung von Spark über das Integrationstool im Vergleich zum Einsatz über ein anderes Medium (im vorliegenden Fall Hive) bietet; die Verwendung eines anderen Mediums erweist sich aufgrund der fehlenden Unterstützungsmöglichkeit sogar in den Enterprise-Distributionen von Hadoop als sinnlos.




Die Autoren

William McKnight ist Vorstand von McKnight Consulting Group Global Services (www.mcknightcg.com). Er ist eine international anerkannte Autorität im Bereich des Informationsmanagements und hat im Laufe seiner Karriere zahlreiche Global Player wie auch Unternehmen aus dem mittleren Marktsegment beraten. Seine Teams sind für ihre Implementierungen vielfach ausgezeichnet und viele seiner Kunden mit ihren Erfolgsgeschichten öffentlich bekannt geworden. Die Informationsmanagementpläne führender Unternehmen aus den verschiedensten Branchen basieren auf seinen Strategien. McKnight ist Autor eines Buchs mit dem Titel „Information Management: Strategies for Gaining a Competitive Advantage with Data“. Zudem ist er ein weltweit gefragter Redner und hat ferner Hunderte von Fachartikeln und Whitepapers verfasst. Er ist profilierter Unternehmer und war in der Vergangenheit bereits als Technologiemanager und Softwareingenieur bei Fortune 50-Unternehmen tätig. Sein Portfolio umfasst Strategien, Architekturen, Plattform- und Toolempfehlungen sowie vollständige Programme für das Informationsmanagement.

Jake Dolezal kann auf mehr als 16 Jahre Erfahrung im Bereich des Informationsmanagements verweisen. Dabei hat er Fachwissen auf den Gebieten Business Intelligence, Analytics, Data Warehousing, Statistik, Datenmodellierung und Datenintegration, Datenvisualisierung, Stammdatenverwaltung und Datenqualität erworben. Er war bereits in so unterschiedlichen Branchen wie dem Gesundheitswesen, der Bildung, staatlichen Stellen, der Fertigung, dem technischen Bereich, dem Hotelfach und der Spieleentwicklung tätig. Jake Dolezal hat einen Doktor in Information Management der Syracuse University – jener Hochschule, die Jahr für Jahr im U.S. News & World Report als beste Lehranstalt für Informatiker genannt wird. Außerdem hat er am TDWI die Zertifizierung als Certified Business Intelligence Professional mit Schwerpunkt Datenanalyse erhalten. Schließlich ist er zertifizierter Coach für




Führungskräfte und unterstützt seine Kunden bei schnellerem Aufstieg und Beförderungen. Bei McKnight Consulting Group Global Services hat Dolezal die Position des Practice Lead inne.

MCG Global Services

Mit einem Kundenportfolio, in dem die wichtigsten Vertreter eines komplexen, politisch nachhaltigen und erfolgreichen Informationsmanagements vertreten sind, hat MCG zahlreiche Berührungspunkte mit dem Markt für Informationsmanagement. Unsere Empfehlungen stellen die Essenz neuester Best Practices dar, die auf unseren aktuellen Erfahrungen beruhen. Hier geht es nicht um Theorie, sondern um handfeste Praxis. Mit unserem Full Lifecycle Approach sind wir in der Lage, die Bedürfnisse unserer Kunden auch in die Zukunft vorherzusehen. Unsere erfahrenen Teams handeln kundenorientiert und generieren für unsere Kunden Resultate, die effizient, wirtschaftlich sowie langfristig und politisch tragfähig sind.

• Business Justification bildet bei uns einen Schwerpunkt. • Wir verfolgen keinen projekt-, sondern einen programmbezogenen Ansatz. • Wir glauben an ein Modell, das auch die Mitarbeiter des Kunden einbezieht, und haben den

Wissenstransfer im Fokus. • Wir implementieren Mitarbeiterteams und Prozesse auf Kundenseite, um die Kontinuität zu

gewährleisten. • Wir sind anbieterneutral. Sie können sich also darauf verlassen, dass unsere Empfehlungen

ausschließlich kundenorientiert sind. • Wir kennen, definieren, bewerten und fördern Best Practices. • Egal welche Probleme Ihnen beim Informationsmanagement in den Sinn kommen: Wir

haben uns bereits damit auseinandersetzen müssen und haben sie in den Griff bekommen. • Wir stellen sicher, dass geschäftliche Resultate oft und zu einem frühen Zeitpunkt verfügbar

sind. Die Dienstleistungen von MCG umfassen Strategien, Implementierung und Schulungen, um aus Informationen Assets zu machen, die Sie in Ihrem Unternehmen gewinnbringend einsetzen können. Unsere Schwerpunkte sind Strategieentwicklung, Entwürfe und Bereitstellungen in den Bereichen Master Data Management, Big Data, Data Warehousing, Analytic Databases und Business Intelligence.




Hadoop und die Datenintegration

Dieser Benchmark ist Bestandteil von Forschungen zur Leistung von Lasten in Hadoop-Clustern – einer immer wichtiger werdenden Plattform zur Speicherung von Daten, die die Grundlage für die Umsetzung digitaler Strategien bilden. Der Einsatz von Hadoop hat sich seit der Erfindung als Lösung zur kostengünstigen und skalierbaren Big-Data-Batchverarbeitung erheblich weiterentwickelt. Eine lebendige Community aus Open-Source-Programmierern und Anbietern hat eine Vielzahl von Tools hervorgebracht, die Komponenten, Funktionen und Daten in Hadoop nativ unterstützen. Data Lakes manifestieren die Idee, dass alle Daten nativ in Hadoop gespeichert werden. Traditionell machte die Aufbereitung von Daten geschätzt 80 Prozent des Aufwands bei der Analyseentwicklung aus. Hadoop wird deswegen häufig dafür eingesetzt, diesen Analyseaufwand einzudämmen. Die Datenaufbereitung lässt sich mithilfe eines traditionellen ETL-Prozesses umsetzen: Die Daten werden aus den Quellen extrahiert, dann transformiert (d. h. bereinigt, normalisiert und integriert), um die Anforderungen des Data Warehouse oder nachfolgender Repositorys und Apps zu erfüllen, und schließlich in diese Zielentitäten geladen. Wie in der Welt der relationalen Datenbanken auch bevorzugen zahlreiche Unternehmen ELT-Prozesse, bei denen durch das Verschieben der Transformationsphase an eine Stelle nach dem Laden eine höhere Leistung erzielt wird. Statt jedoch das Data Warehouse mit dieser Verarbeitung zu belasten, werden die Transformationen in Hadoop ausgeführt. Hierdurch werden Leistung, Fehlertoleranz und Elastizität der Verarbeitung ohne Beeinträchtigung der Abfragegeschwindigkeiten verbessert. In Hadoop-Umgebungen wird außerdem ein Maximum an Prozessorleistung benötigt, da bei den Transformationen häufig sehr unterschiedliche Datentypen aus einer Vielzahl von Quellen integriert werden müssen. Ihre Analysen können Daten aus ERP- und CRM-Systemen, In-Memory-Analyseumgebungen wie auch internen und externen Apps umfassen, die über APIs bereitgestellt werden. Womöglich müssen Sie Daten aus Stammdateien von Kunden mit Klickstreamdaten aus der Cloud und Social-Media-Daten zusammenführen, die aus Ihren eigenen NoSQL-Datenbanken stammen oder bei Aggregationsdiensten von Drittanbietern abgerufen werden müssen. Oder Sie möchten riesige Datenmengen zu früheren Transaktionen mit Informationen zu Kundentransaktionen verknüpfen, die in Echtzeit gestreamt oder von Geräten, Sensoren oder Chips übertragen werden. Ob strukturiert, unstrukturiert, teilstrukturiert oder mehrfach strukturiert: Hadoop kann alle diese Daten aufnehmen, da es schemaloses Speichern und Verarbeiten gestattet. Beim Befüllen von Hadoop mit Daten ist es nicht notwendig, ein Datenmodell zu deklarieren oder Zuordnungen zu Zielanwendungen vorzunehmen. Stattdessen wird eine lose Bindung verwendet, um nach Abschluss der Transformation ein Datenschema anzuwenden bzw. zu erkennen, wenn die Daten in die




vorgesehene Produktionsanwendung oder ein nachgeschaltetes spezielles Analyse-Repository geschrieben werden. Diese Trennung der Datenintegrationsprozesse von der Runtime-Engine gestattet Folgendes:

• Übergreifendes Teilen und Wiederverwenden von Transformationen in verschiedenen Datenintegrationsprojekten

• Anzeigen von Daten auf unterschiedliche Weise und Erkennen neuer Datenelemente durch Anwendung eines anderen Schemas

• Optimieren von Datasets durch Hinzufügen neuer Dimensionen, sobald neue Daten verfügbar werden oder weitere Fragen beantwortet werden müssen

Es gibt unendlich viele Big-Data-Quellen, und Tag für Tag werden es mehr. Da man anfangs auf leistungsschwache Open-Source-Lösungen wie Sqoop, Flume, HDFS für die Befehlszeile oder Hive zurückgreifen musste, ist eine Vielzahl von Methoden und Tools entstanden, um die Probleme von Hadoop bei der Datenintegration zu lösen. Während wir inzwischen über genügend Wissen darüber verfügen, wie die Daten in Hadoop abgefragt werden, lässt sich dasselbe leider nicht über das Einbringen der Daten in Hadoop-Cluster sagen. Viele Unternehmen übertragen die Merkmale und Funktionen, die sie aus der Welt der relationalen Datenbanken kennen, auf Hadoop. Gleiches gilt für nicht funktionsbezogene Anforderungen, die Entwicklerproduktivität, das Metadatenmanagement, die Dokumentation und die Verwaltung von Geschäftsregeln, wie sie moderne Datenintegrationstools bieten. Gegenstand des für den vorliegenden Bericht durchgeführten Benchmarkings sind die Anbieter Talend und Informatica.




Produktprofil Talend

Unternehmensprofil

Produktname Talend Big Data Integration

Markteinführung 2012

Aktuelle Version und Datum

Version 6.0, Auslieferung seit September 2015

Wesentliche Merkmale Nativer Support für Apache Spark und Spark Streaming, Verwendung von mehr als 100 Spark-Komponenten, 1-Klick-Konversion von MapReduce-Aufträgen nach Spark, Continuous-Delivery-Unterstützung, Support für MDM (Master Data Management), REST-API und Abfragesprachen, Anonymisierung und semantische Analyse

Mitbewerber im Bereich Hadoop

Informatica, Pentaho, Syncsort

Unternehmensgründung 2006

Schwerpunkte Hochskalierbare Integrationslösungen für die Bereiche Big Data, Application Integration, Data Integration, Data Quality, MDM, BPM

Mitarbeiter 500

Hauptniederlassung Redwood City, USA

Eigentumsstatus Privat




Produktprofil Informatica

Unternehmensprofil

Produktname Informatica Big Data Edition

Markteinführung 2012

Aktuelle Version und Datum

Version 9.6.1, Auslieferung seit 2015

Wesentliche Merkmale Alle Funktionen für Hadoop, universeller Datenzugriff, ultraschnelle Datenaufnahme und -extraktion, Datenerfassung und -streaming in Echtzeit, Data Discovery in Hadoop, Verarbeitung natürlicher Sprache in Hadoop, vollständige Integration von Attunity Replicate; zusätzliche Verbesserungen an der GUI, weitere Zielplattformen

Mitbewerber im Bereich Hadoop

Talend, Pentaho, Syncsort, Tervela

Unternehmensgründung 1998

Schwerpunkte Weltmarktführer unter den unabhängigen Anbietern von Datenintegrationssoftware

Mitarbeiter Über 5.500

Hauptniederlassung Redwood City, USA

Eigentumsstatus Privat (vormals öffentlich)




Der Benchmark im Überblick

Zweck des Benchmarkentwurfs war die Simulation einer Reihe einfacher Szenarios mit dem Ziel, einige grundlegende geschäftliche Fragen zu beantworten, die sich Organisationen aus praktisch allen Industriebereichen stellen könnten. Konkret wurden für den Benchmark die folgenden allgemeinen Fragen formuliert:

• Welche Auswirkungen haben Seiten- und Produktaufrufe auf unserer Website auf den Umsatz? Wie viele Seitenaufrufe erfolgen vor der Kaufentscheidung (online oder im Ladengeschäft)?

• Wie wirken sich unsere Gutscheinkampagnen auf Produktumsatz und Servicenutzung aus? Besuchen Kunden nach Ansicht oder Erhalt unserer Gutscheinwerbung unsere Website? Kaufen sie mehr Produkte oder zusätzliche Produkte, die sie ohne Gutschein nicht kaufen würden?

• Wie stark beeinflusst bzw. fördert unsere Empfehlungs-Engine den Produktabsatz? Neigen Kunden dazu, aufgrund dieser Empfehlungen zusätzliche Produkte zu kaufen?

Nach unseren Erfahrungen, die wir im Laufe der letzten zehn Jahre mit Kunden aus den unterschiedlichsten Branchen gesammelt haben, handelt es sich hierbei nicht um Nischenanwendungen, sondern um grundsätzliche Fragen, die in vielen Unternehmen täglich gestellt werden. Mit dem Benchmark soll gezeigt werden, wie ein Unternehmen diese geschäftlichen Fragen unter Umständen beantworten kann, indem verschiedene Informationsquellen ins Spiel gebracht werden. Zusätzlich haben wir die Möglichkeit genutzt, zu demonstrieren, wie Hadoop sinnvoll eingesetzt werden kann, denn einige der in diesem Analysefall wichtigen Datenbestände sind umfangreich und nicht-relational oder aber ihrem Wesen nach nur teil- oder unstrukturiert. Für solche Fälle würden wir, wenn ein Kunde diese Fragen beantwortet wissen möchte, auf jeden Fall Hadoop als Mittel der Wahl empfehlen. Ferner sollen mit dem Benchmark auch Umfang und Qualität der Datenintegration ermittelt werden, denn die erforderlichen Daten sind im Zweifelsfall in verschiedenen Quellen abgelegt. Ebenso wahrscheinlich ist, dass diese Quellen zum Teil nicht in einem Data Warehouse aggregiert und zugänglich gemacht werden, denn aufgrund der großen Datenmenge und der Schwierigkeiten bei der Integration umfangreicher und zudem nur teilstrukturierter Datenbestände in einem traditionellen Data Warehouse ist ein solcher Ansatz nicht pragmatisch. Aufgrund dessen simuliert der Benchmark ein allgemeines Szenario einschließlich der Herausforderungen, mit denen ein Unternehmen konfrontiert wird, das geschäftliche Fragen wie die oben beschriebenen durch Datenintegration beantworten möchte.




Benchmarkaufbau

Für den Benchmark wurden Aufbau, Umfeld, Standards und Konfigurationen entsprechend nachfolgender Beschreibung realisiert.

Serverumgebung

Abbildung 1: Serverumgebung und Setup

Merkmal Auswahl

Hadoop-Distribution Cloudera CDH 5.4.7

EC2-Instanz r3.xlarge, speicheroptimiert (4 vCPUs, 30,5 GB RAM, 200 GB Festplattenspeicher)

Betriebssystem Ubuntu LTS 14.04 (Trusty Tahr)

Quelldatentypen Textbasierte Logdateien und eine relationale Datenbank

Datenvolumen 20 GB (Logdateien), 12 Mio. Zeilen (RDBMS)

TPC-H-Skalierungsfaktor 0,125 bis 2

RDBMS MySQL 5.6

Java-Version 1.6.0_87




Der Benchmark wurde mit Amazon Web Services (AWS) EC2-Instanzen eingerichtet, die in einer AWS Virtual Private Cloud (VPC) innerhalb derselben Placement-Gruppe bereitgestellt wurden. Laut Amazon verfügen alle innerhalb einer Placement-Gruppe gestarteten Instanzen zur Gewährleistung niedriger Latenzen über eine vollständig 10-Gbit/s-Duplexbandbreite zwischen den Instanzen. Die erste EC2-Instanz war ein speicheroptimiertes r3.xlarge mit vier vCPUs und 30,5 GB RAM. An diese Instanz wurde ein Festplattenspeicher von 200 GB angehängt und gemountet. Diese Linux-Instanz lief unter Ubuntu LTS 14.04 (Trusty Tahr). Auf dieser Instanz haben wir Cloudera CDH 5.4.7 als Hadoop-Distribution sowie MySQL 5.6 für die als Quelle verwendete relationale Datenbank bereitgestellt. Die zweite EC2 war eine r3.xlarge-Maschine unter Windows Server 2012. Auf der Windows-Instanz wurden die Entwicklerpakete Talend Studio und Informatica Big Data Edition (BDE) installiert. HINWEIS: Zur Ausführung von Informatica BDE war eine dritte EC2-Instanz erforderlich, auf der die Domänen- und Repository-Dienste für Informatica ausgeführt wurden. Hierbei handelte es sich um eine RedHat Linux-Maschine, die lediglich als Informatica-Repository-Dienst fungierte. Dieses System war weder mit der Datenverarbeitung noch mit der Ausführung des Benchmarks befasst. Die relationale Quelle für den Benchmark, die auf der Linux-Instanz in MySQL 5.6 gespeichert ist, wurde gemäß Standardspezifikation des Transaction Processing Performance Council Benchmark H (TPC-H) in Revision 2.17.1 erstellt. Ziel der Verwendung der TPC-H-Datenbank war es, ein realistisches Point-of-Sale-System entsprechend dem Entity-Relationship-Diagramm und den Datentyp- und Skalierungsspezifikationen zu simulieren, die vom TPC-H vorgegeben werden. Die Datenbank wurde dann mithilfe von Skripts befüllt, deren Ausgangswerte randomisiert waren, um das Pseudo-Dataset zu erstellen. Die TPC-H-Spezifikationen umfassen einen Skalierungsfaktor, mit dessen Hilfe die Anzahl der Datensätze je Tabelle abgeleitet wird. Bei diesem Benchmark entschieden wir uns für einen maximalen Skalierungsfaktor von 2. Im vorliegenden Fall enthielt die TPC-H-Datenbank 3 Mio. Datensätze in der Tabelle ORDERS und 12 Mio. Datensätze in der Tabelle LINEITEM.




Relationale Datenquelle

Abbildung 2: TPC-H-ER-Diagramm ©1993-2014 Transaction Processing Performance Council

Logdateiquellen Die übrigen drei Datenquellen, die in den Integrationsroutinen für den Benchmark verwendet werden sollten, wurden als teilstrukturierte ASCII-Logdateien erstellt. Verwendet wurden die folgenden drei Logdateien, um realistische Anwendungsfälle nachzustellen:

1. Webklick-Log

2. Gutschein-Log

3. Empfehlungs-Log

Webklick-Log Das Webklick-Log wurde auf die gleiche Weise erstellt wie eine normale Apache-Webserver-Logdatei. Die Logdatei wurde unter Verwendung von Skripts so angelegt, dass zwei Arten von




Einträgen simuliert wurden: erstens vollständig zufällige Seitenaufrufe (die mit Zufallszahlen initialisiert wurden) und zweitens Webklicks, die den tatsächlichen Seitenaufrufen bestellter Produkte entsprachen (diese wurden mit zufälligen Datensätzen in den TPC-H-Tabellen ORDERS und LINEITEMS initialisiert). Diese Pseudoeinträge im Webklick-Log erschienen in einer Vielzahl von Kombinationen, das Format orientierte sich aber an echten Einträgen in einem Apache-Webklick-Log. Alle Daten wurden zufällig ausgewählt. Die Datumsangaben beschränken sich auf das Jahr 2015. Beispiel: 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"

Die „Signaleinträge“ im Webklick-Log, die echten Datensätzen aus den Tabellen ORDERS und LINEITEM entsprachen (und entsprechend initialisiert worden waren), wiesen dasselbe Format an Zufälligkeit auf wie die Pseudoeinträge. Ausgenommen waren lediglich echte LINEITEM.L_PARTKEY-Werte und die entsprechenden ORDERS.O_ORDERDATE-Werte aus der TPC-H-Datenbank, die ausgewählt worden waren, um Datensätze zu erstellen, mit denen ein Seitenaufruf für einen Artikel dargestellt werden sollte, der am selben Tag bestellt wurde, an dem auch die Bestellung aufgegeben wurde. Die hervorgehobenen Segmente stellen Einträge dar, die potenziell echten Bestellungen entsprechen: 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"

Die Webklick-Logdatei enthielt 26.009.338 Einträge und war 5,1 GB groß. Für jeden einzelnen der insgesamt 3 Mio. Datensätze in ORDERS gab es jeweils einen Webklick-Eintrag für einen zufällig ausgewählten LINEITEM-Datensatz. Folglich entsprachen 12 Prozent der Einträge im Webklick-Log tatsächlich Bestellungen. Die übrigen Einträge enthielten Zufallswerte. Gutschein-Log Das Gutschein-Log wurde auf die gleiche Weise erstellt wie eine angepasste Apache-Webserver-Logdatei. Die Logdatei sollte eine echte Logdatei für Sonderfälle simulieren, die erstellt wird, wenn ein Interessent eine Artikelseite durch einen Klick auf einen Gutschein aus einer Werbekampagne aufgerufen hat. Auch diese Logdatei wurde unter Verwendung von Skripts so angelegt, dass zwei Arten von Einträgen simuliert wurden: erstens vollständig zufällige Seitenaufrufe (die mit Zufallszahlen initialisiert wurden) und zweitens Seitenaufrufe, die den tatsächlichen Seitenaufrufen echter Kunden über Klicks auf Gutscheine aus einer Werbekampagne entsprachen (diese wurden mit zufälligen Datensätzen in den TPC-H-Tabellen ORDERS, LINEITEMS und CUSTOMERS initialisiert). Die Pseudoeintragsdaten im Gutschein-Log wurden zufällig ausgewählt. Die Datumsangaben beschränken sich auf das Jahr 2015. Die „Signaleinträge“ im Gutschein-Log, die echten Datensätzen aus den Tabellen ORDERS und LINEITEM entsprachen (und entsprechend initialisiert worden waren), wiesen dasselbe Format an Zufälligkeit auf wie die Pseudoeinträge. Ausgenommen waren lediglich echte LINEITEM.L_PARTKEY-Werte und die entsprechenden ORDERS.O_ORDERDATE-Werte aus der




TPC-H-Datenbank, die ausgewählt worden waren, um Datensätze zu erstellen, mit denen ein Seitenaufruf für einen Artikel dargestellt werden sollte, der am selben Tag bestellt wurde, an dem auch die Bestellung aufgegeben wurde. Die hervorgehobenen Segmente stellen Einträge dar, die potenziell echten Bestellungen entsprechen: 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"

Die Gutschein-Logdatei enthielt 20.567.665 Einträge und war 6,6 GB groß. Für jeden einzelnen der insgesamt 3 Mio. Datensätze in ORDERS gab es jeweils einen Webklick-Eintrag für einen zufällig ausgewählten LINEITEM-Datensatz. Folglich entsprachen 15 Prozent der Einträge im Gutschein-Log tatsächlich Bestellungen. Die übrigen Einträge enthielten Zufallswerte. Empfehlungs-Log Ein Empfehlungs-Log wurde als Ausgabelogdatei mit XML-Tags generiert. Die Empfehlungs-Logdatei sollte simulieren, wie oft Interessenten Artikel aufgerufen hatten, indem sie auf der aktuellen Artikelseite einer Empfehlung gefolgt waren. In diesem Fall empfahl die Website des Unternehmens für jeden angezeigten Artikel fünf zusätzliche oder ähnliche Artikel. Auch diese Logdatei wurde unter Verwendung von Skripts so angelegt, dass zwei Arten von Einträgen simuliert wurden: erstens Pseudo- oder vollständig zufällige Seitenaufrufe und zufällige Empfehlungen (die mit Zufallszahlen initialisiert wurden) und zweitens Seitenaufrufe, die den tatsächlichen Seitenaufrufen von über die Empfehlungen bestellten Produkten entsprachen (diese wurden mit zufälligen Datensätzen in den TPC-H-Tabellen ORDERS und LINEITEMS initialisiert). Die Pseudoeintragsdaten im Empfehlungs-Log wurden zufällig ausgewählt. Die Datumsangaben beschränken sich auf das Jahr 2015. Die „Signaleinträge“ im Empfehlungs-Log, die echten Datensätzen aus den Tabellen ORDERS und LINEITEM entsprachen (und entsprechend initialisiert worden waren), wiesen dasselbe Format an Zufälligkeit auf wie die Pseudoeinträge. Ausgenommen waren lediglich echte LINEITEM.L_PARTKEY-Werte und die entsprechenden ORDERS.O_ORDERDATE-Werte aus der TPC-H-Datenbank, die ausgewählt worden waren, um Datensätze zu erstellen, mit denen ein Seitenaufruf für einen Artikel dargestellt werden sollte, der am selben Tag bestellt wurde, an dem auch die Bestellung aufgegeben wurde. Die hervorgehobenen Segmente stellen Einträge dar, die potenziell echten Bestellungen entsprechen: <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>

Die Empfehlungs-Logdatei enthielt 13.168.336 Einträge und war 8,3 GB groß. Für jeden einzelnen der insgesamt 3 Mio. Datensätze in ORDERS gab es jeweils einen Webklick-Eintrag für einen zufällig ausgewählten LINEITEM-Datensatz. Folglich entsprachen 23 Prozent der Einträge im Empfehlungs-Log tatsächlich Bestellungen. Die übrigen Einträge enthielten Zufallswerte.

Skalierungsfaktor Alle oben aufgeführten Datenquellen wurden auch auf verschiedene Faktoren skaliert, damit die (im nächsten Abschnitt beschriebenen) Integrationsroutinen für Datenquellen unterschiedlicher Größe ausgeführt werden konnten. Die TPC-H-Datenbank und die Logdateien wurden wie folgt skaliert:

Skalierungsfaktor 2,0 1,0 0,5 0,25 0,125 LINEITEM-Einträge 12.000.000 6.000.000 3.000.000 1.500.000 750.000 ORDERS-Einträge 3.000.000 1.500.000 750.000 375.000 187.500 CUSTOMERS-Einträge 300.000 150.000 75.000 37.500 18.750 Gesamtgröße Logdatei 20 GB 10 GB 5 GB 2,5 GB 1,25 GB Größe des Webklick-Logs 5,1 GB 2,6 GB 1,3 GB 638 MB 319 MB Einträge im Webklick-Log 26.009.338 13.004.669 6.502.335 3.251.167 1.625.584 Größe des Gutschein-Logs 6,6 GB 3,3 GB 1,7 GB 825 MB 413 MB Einträge im Gutschein-Log 20.567.665 10.283.833 5.141.916 2.570.958 1.285.479 Größe des Empfehlungs-Logs 8,3 GB 4,2 GB 2,1 GB 1,0 GB 519 MB Einträge im Empfehlungs-Log 13.168.336 6.584.168 3.292.084 1.646.042 823.021 Tabelle 1: Anzahl der Datensätze und Logdateien in der TPC-H-Datenbank bei unterschiedlichen Skalierungsfaktoren

Integrationsroutinen Der Big-Data-Anwendungsfall des Benchmarks wurde so entworfen, dass realistische Szenarios demonstriert werden, in denen Unternehmen Daten aus ihren Transaktionssystemen mit un- und teilstrukturierten Big Data integrieren möchten. Der Benchmark veranschaulicht dies durch Ausführung von Routinen, die die relationalen TPC-H-Quelldaten mit den einzelnen oben beschriebenen Logdateien integrieren. Die nachfolgend beschriebenen Integrationsroutinen wurden für den Benchmark erstellt. In beiden Fällen wurden Best Practices berücksichtigt, um die Leistung aller Aufträge zu optimieren. Es gab




beispielsweise keine Datentypkonvertierungen, Datumsangaben wurden als Strings behandelt und die Größen der Datentypen wurden minimiert. Der Informatica-Workflow Das folgende Diagramm stellt den in Informatica Developer erstellten Workflow dar.

Abbildung 3: Informatica-Workflow im Überblick Die Informatica Big Data Edition bietet zwei Möglichkeiten zur Interaktion mit Hadoop, nämlich via Hive oder direkt mit dem Hadoop File System (HDFS). Der erste Teil bestand in der Extraktion der MySQL-Daten unter Verwendung exakt derselben Abfrage, die beim Talend-Auftrag für MySQL verwendet wurde. Diese Daten wurden mithilfe von Hive in Hadoop gespeichert. Danach wurden die Web-, Gutschein- und Empfehlungs-Logdateien mit denselben regulären Ausdrücken wie bei den Talend-Aufträgen analysiert und dann direkt in das HDFS geladen. Der dritte Teil umfasste die Integration der TPC-H-Daten mit den Logdateien unter Verwendung der Lookup-Transformation in Informatica. Die resultierenden, mit Trennzeichen versehenen Ausgabedateien wurden dann ebenfalls direkt in HDFS gespeichert. Diese Routinen werden im nächsten Abschnitt ausführlicher beschrieben. Hinweis: Zum Zeitpunkt des Benchmarkings verfügte das von uns installierte Paket der Informatica BDE nicht über einen MySQL-Connector. Deswegen wurde stattdessen ein generischer ODBC-Connector verwendet. Diese Vorgehensweise schien keine signifikanten Auswirkungen auf die Leistung des Integrationsauftrags zu haben.




Talend-Auftragsentwurf Das folgende Diagramm stellt den in Talend Studio erstellten Auftragsentwurf dar.

Abbildung 4: Talend-Auftragsentwurf im Überblick Talend Studio 6 bietet eine neue, sehr leistungsfähige Funktion zur Interaktion mit Spark auf Hadoop zusätzlich zur konventionellen Interaktion via Hive oder direkt mit dem Hadoop File System (HDFS). Der erste Teil bestand in der Extraktion der MySQL-Daten unter Verwendung der folgenden MySQL-Abfrage: SELECT L_ORDERKEY, L_PARTKEY, O_CUSTKEY, O_ORDERDATE FROM LINEITEM LEFT OUTER JOIN ORDERS ON L_ORDERKEY = O_ORDERKEY;

Diese Daten wurden in Spark gespeichert. Danach wurden die Web-, Gutschein- und Empfehlungs-Logdateien mit regulären Ausdrücken analysiert und dann direkt in das HDFS geladen. Der dritte Teil umfasste die Integration der TPC-H-Daten mit den Logdateien unter Verwendung der tMap-Transformation in Talend. Die resultierenden, mit Trennzeichen versehenen Dateien wurden dann direkt in HDFS gespeichert. Informatica und Spark Wir haben erwogen, den Benchmark mit Informatica BDE auf Spark via Hive auszuführen, und dies sogar ausprobiert. Dabei konnten wir Hive mithilfe der Cloudera CDH-Administrationstools so konfigurieren, dass es für die Ausführung Spark nutzte. Allerdings traten bei der Ausführung erhebliche Inkonsistenzen auf, weswegen eine solche Verwendung instabil ist. Nach Angaben von Cloudera gilt im Zusammenhang mit der Verwendung von Hive auf Spark folgender Haftungsausschluss:




Wichtig: Hive auf Spark ist im Lieferumfang von CDH 5.4 enthalten, wird aber gegenwärtig nicht unterstützt und auch nicht für den Einsatz in der Produktion empfohlen. Wenn Sie Interesse haben, diese Funktion zu verwenden, sollten Sie sie so lange ausschließlich in einer Testumgebung einsetzen, bis wir alle Probleme behoben und Einschränkungen beseitigt und die Funktion für den Einsatz in der Produktion freigegeben haben.

Aus diesem Grund wurde die beschriebene Methode als instabil angesehen und zum Zeitpunkt des Benchmarkings als ungeeigneter Anwendungsfall gewertet.

Benchmarkergebnisse

Anwendungsfall 1: Webklick-Einfluss Ziel des ersten Anwendungsfalls für den Benchmark war es, ein Dataset vorzubereiten, das bestellte Produkte mit den Seitenaufrufen auf der E-Commerce-Website korreliert. Die Integrationsaufträge wurden so formuliert, dass die Seitenaufrufe den bestellten Produkten zugeordnet wurden. Das folgende Diagramm stellt eine konzeptionelle Zuordnung der Integration dar. In Informatica wurde die Lookup-Transformation zur Verknüpfung des Webklick-Logs mit Datensätzen in der TPC-H-Datenbank mithilfe des Felds PARTKEY verwendet. In Talend wurde die tMap-Transformation benutzt.

Abbildung 5: Zuordnung des Webklick-Einflusses Ausführungszeiten Die folgende Tabelle zeigt die Ausführungszeiten für die Zuordnung des Webklick-Einflusses in Sekunden. Webklick (Anwendungsfall 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 Tabelle 2: Ausführungszeiten bei der Zuordnung des Webklick-Einflusses




Anwendungsfall 2: Gutscheineinfluss Ziel des zweiten Anwendungsfalls für den Benchmark war es, ein Dataset vorzubereiten, das bestellte Produkte mit einer Gutscheinwerbekampagne korreliert. Die Integrationsaufträge wurden so formuliert, dass die Aufrufe von Seiten mit Gutscheinanzeigen und Kunden den bestellten Produkten zugeordnet wurden. Das folgende Diagramm stellt eine konzeptionelle Zuordnung der Integration dar. In Informatica wurde die Lookup-Transformation zur Verknüpfung des Gutschein-Logs mit Datensätzen in der TPC-H-Datenbank mithilfe der Felder PARTKEY und CUSTKEY verwendet. In Talend wurde die tMap-Transformation benutzt.

Abbildung 6: Zuordnung des Gutscheineinflusses Ausführungszeiten Die folgende Tabelle zeigt die Ausführungszeiten für die Zuordnung des Gutscheineinflusses in Sekunden. Gutschein (Anwendungsfall 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 Tabelle 3: Ausführungszeiten bei der Zuordnung des Gutscheineinflusses




Anwendungsfall 3: Einfluss von Empfehlungen Der Zweck des dritten Anwendungsfalls für den Benchmark bestand darin, ein Dataset vorzubereiten, das bestellte Produkte mit dem Einfluss eines Empfehlungsmoduls korreliert. Die Integrationsaufträge wurden so formuliert, dass die empfohlenen Produkte den bestellten Produkten zugeordnet wurden. Das folgende Diagramm stellt eine konzeptionelle Zuordnung der Integration dar. In Informatica wurde die Lookup-Transformation zur Verknüpfung des Gutschein-Logs mit Datensätzen in der TPC-H-Datenbank unter fünfmaliger Verwendung des Felds PARTKEY verwendet. In Talend wurde die tMap-Transformation benutzt.

Abbildung 7: Zuordnung des Empfehlungseinflusses Ausführungszeiten Die folgende Tabelle zeigt die Ausführungszeiten für die Zuordnung des Empfehlungseinflusses in Sekunden. Empfehlung (Anwendungsfall 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 Tabelle 4: Ausführungszeiten bei der Zuordnung des Empfehlungseinflusses




Zusammenfassung der Ergebnisse Die folgenden Tabellen zeigen das Gesamtergebnis. Soweit nicht anders angegeben, werden alle Ausführungszeiten in Sekunden angezeigt. Zusammenfassung zum Skalierungsfaktor SF 2,0 SF 1,0 SF 0,5 SF 0,25 SF 0,125 TPC-H-LINEITEM-Einträge 12.000.000 6.000.000 3.000.000 1.500.000 750.000 Gesamtgröße der Logdatei 20GB 10GB 5GB 2,5GB 1,25GB

+ MapReduce: Ausführungszeiten Informatica-MapReduce SF 2,0 SF 1,0 SF 0,5 SF 0,25 SF 0,125 TPCH (MySQL) nach Hadoop laden 859 711 349 164 95 Webklick-Log nach Hadoop laden 388 360 76 43 22 Gutschein-Log nach Hadoop laden 504 404 111 58 32 Empfehlungs-Log nach Hadoop laden 578 442 129 65 33 Webklick (Anwendungsfall 1) 5.221 1.977 622 308 111 Gutschein (Anwendungsfall 2) 8.573 3.197 1.210 693 396 Empfehlung (Anwendungsfall 3) 14.973 6.544 2.802 1.272 590 GESAMT 31.096 13.635 5.299 2.603 1.279 GESAMT (Minuten) 518,3 227,3 88,3 43,4 21,3 GESAMT (Stunden) 8,6 3,8 1,5 0,7 0,4

+ : Ausführungszeiten Talend-Spark SF 2,0 SF 1,0 SF 0,5 SF 0,25 SF 0,125 TPCH (MySQL) nach Spark laden 748 642 302 143 82 Webklick-Log nach Spark laden 158 79 33 21 12 Gutschein-Log nach Spark laden 213 123 59 33 17 Empfehlungs-Log nach Spark laden 204 117 55 31 16 Webklick (Anwendungsfall 1) 579 383 257 148 88 Gutschein (Anwendungsfall 2) 882 478 331 202 169 Empfehlung (Anwendungsfall 3) 1.313 701 473 236 188 GESAMT 4.097 2.523 1.510 814 572 GESAMT (Minuten) 68,3 42,1 25,2 13,6 9,5 GESAMT (Stunden) 1,1 0,7 0,4 0,2 0,2 Tabelle 5: Zusammenfassung




Das folgende Diagramm zeigt die für die Ausführung aller Ladevorgänge, Transformationen und Dateierstellungen benötigten Gesamtausführungszeiten für den Informatica-Workflow und die Talend-Aufträge im Vergleich. Die Regressionslinien wurden hinzugefügt.

+ SF 0,125 SF 0,25 SF 0,5 SF 1,0 SF 2,0 Faktor, um den die Geschwindigkeit höher war 2,2 3,2 3,5 5,4 7,6 Abbildung 8: Gesamtausführungszeiten im Vergleich

Fazit

Eine direkte Nutzung von Spark bietet für die Verarbeitung immer größer werdender Datenmengen klare Vorteile. Bei relativ kleinen Datasets (d. h. solchen, die weniger als 3 Mio. Transaktionsdatensätze und 5 GB Logdateien enthielten) waren die Unterschiede in der Ausführungsdauer vernachlässigbar, denn beide Tools waren in der Lage, die Bearbeitungsaufträge in weniger als einer Stunde fertigzustellen. Mit dem Erreichen des Skalierungsfaktors 0,5 machte sich der Unterschied jedoch deutlich bemerkbar. Beim Skalierungsfaktor 2,0 dauerte es mehr als 8 Stunden, bis der Informatica-Auftrag abgeschlossen war. Die Zunahme der Ausführungszeiten ist für Analysten und Datenforscher frustrierend, möchten sie doch schnellstmöglich ihre Datenexperimente und anspruchsvollen Analysen durchführen; stattdessen müssen sie auf die Integration ihrer Zieldatenmengen einen geschlagenen Tag warten.




Das Problem wird offenbar durch zusätzliche Komplexität in den Zuordnungen (durch mehrere Nachschlageschlüssel) noch verschärft. Bei Verwendung von MapReduce benötigen bereits die Lookup-Transformationen selbst übermäßig viel Leistung, weil Nachschlage- und Indexcache überfordert werden. Dank der In-Memory-Kapazitäten von Spark können Nutzer Datasets sehr viel schneller einbinden. Spark verwendet schnelle Remote Procedure Calls für eine effiziente Verteilung und Planung der Aufgaben. Darüber hinaus nutzt es die Vorteile eines Thread Pools für die Ausführung von Aufgaben anstelle eines Pools von Java Virtual Machine-Prozessen. So kann Spark Aufgaben in Millisekunden planen und ausführen, während die MapReduce-Planung mehrere Sekunden und – bei stark belegten Clustern – sogar Minuten dauern kann. Wenn es darum geht, die hier gezeigten Spark-Resultate zu erzielen, ist Spark via Hive keine Alternative. Die Ausführungsergebnisse wären in diesem Fall inkonsistent, wenn nicht sogar unbestimmt. Die Entwicklung einer passenden Verwendung von Spark für einen Anbieter ist der Entwicklung des Produkts selbst nicht unähnlich: Sie dauert Jahre und verschlingt Millionen. Insofern ist die Nutzung der gesamten Spark-Funktionalität zur Datenintegration mit Hadoop ein vielversprechender Ansatz.


cmaindron

Typewritten Text

WP206-DE

cmaindron

Typewritten Text

Documents

Benchmark zur Hadoop-Integration - info.talend.com · Benchmark zur Hadoop-Integration Produktprofil und -auswertung: Talend und Informatica . von William McKnight und Jake Dolezal