Elefant trifft Schichtenarchitektur 25.02.2016 Agenda –Kontext und Übersicht • Diese Präsentation: • Lessons Learned, Design Patterns und Best Practices an der Schnittstelle zwischen Hadoop und Enterprise Software-Landschaften. • Diese Präsentation ist nicht: • Eine Vorstellung von aktuellem Vorgehen der Daimler AG • Struktur: • Kurzvorstellung Daimler TSS • Motivation und Beispiel • Kombinierte Architektur • Migration von Legacy Software • Entwicklungsprozesse Daimler TSS GmbH Elefant trifft Schichtenarchitektur / Analytics / 25.02.2016 / Seite 2 Interner IT-Partner für Daimler Wir sind In-House Spezialist für innovative IT-Gesamtlösungen im Daimler-Konzern 100%ige Daimler-Tochter mit dem Anspruch der Innovations- und Technologieführerschaft. Anbieter von wettbewerbsdifferenzierenden Dienstleistungen und Impulsgeber in anspruchsvollen IT-Fragestellungen, speziell in den Kernthemen Car IT und Mobility, Information Security, Analytics und Shared Services. Daimler TSS GmbH Elefant Trifft Schichtenarchitektur / Analytics / 25.02.2016 / Seite 3 Motivation: Übliche Hadoop Architekturen • Starker Fokus auf Struktur von BI Anwendungen mit Standardsoftware • Nicht-BI Anwendungen und Individualsoftware werden wenig betrachtet Quelle: Hortonworks Modern Data Architecture http://hortonworks.com/blog/webinar-series-building-a-modern-data-architecture-with-hadoop/ Daimler TSS GmbH Elefant Trifft Schichtenarchitektur / Analytics / 25.02.2016 / Seite 4 Motivation II: Schichtenarchitektur Application Client Dynamic HTML • Viele betriebliche Informationssystem sind/werden als Schichtenarchitektur entwickelt Java EE Server Tier • Auch solche Systeme können teilweise von der Nutzung von Hadoop profitieren EIS / DB Tier • Die Integration dieser Welten kann jedoch problematisch sein Client Tier Web Tier (JSP / Servlet / JSF) Business Tier (EJB) Daimler TSS GmbH Elefant Trifft Schichtenarchitektur / Analytics / 25.02.2016 / Seite 5 • Ein Chemiekonzern erstellt neue Software um Scenario-basierte Planung zu beschleunigen • Die Anwendung erlaubt es Nutzern die Parameter eines Scenarios zu bestimmen, die Simulation eines Szenarios zu starten und die Ergebnisse zu analysieren • Die Simulation eines Scenarios soll verschiedene bereits existierende SoftwareKomponenten wiederverwenden z.B. für Produktionsplanung oder physikalische Simulation • Der Simulationsprozess ist Rechen- und DatenIntensiv Daimler TSS GmbH Elefant Trifft Schichtenarchitektur / Analytics / 25.02.2016 / Seite 6 Quelle: CC licensed by john mcsporran on Flickr Motivation III: Ein (fiktives) Beispiel Architekturvision: ‚Passive‘ Komponente zur Ausführung von Datenpipelines • Loose gekoppelte Inputs von anderen Systemen hochgeladen Outputs als Data Workflows Dateien / über aufgerufen ODBC abgerufen durch Ablaufsteuerung Hadoop Daimler TSS GmbH Komponente die aus der EE Welt gesteuert wird (über Knox Webservice interfaces) • Gesteuert werden DatenPipelines • Input Daten werden entgegengenommen (nicht aktiv geholt) Elefant Trifft Schichtenarchitektur / Analytics / 25.02.2016 / Seite 7 Architekturvision II – Hadoop als Ergänzung Application Client Dynamic HTML • Nur ein (kleiner?) Teil der Anwendungslogik wandert in den Hadoop • Bestehende Datenbanken außerhalb vom Hadoop werden nicht ersetzt; transaktionale DB / SoR verbleiben (in diesem Kontext) außerhalb • Ablaufsteuerung in J2EE Welt kombiniert im Hadoop deployte Aktivitäten Elefant Trifft Schichtenarchitektur / Analytics / 25.02.2016 / Seite 8 Client Tier Web Tier (JSP / Servlet / JSF) Java EE Server Tier AblaufBusiness Tier (EJB)steuerung EIS / DB Tier Daimler TSS GmbH Datenimport: Sqoop ist die Lösung • • Quelle: Hortonworks Apache Sqoop http://hortonworks.com/hadoop/sqoop/#section_2 Daimler TSS GmbH • Sqoop gilt als Best Practice für Import/Export von Daten aus Relationalen Datenbanken Für das Arbeiten mit großen Datenmengen in großen Firmen ist es jedoch nicht geeignet: • Skalierung über eine Vielzahl von NetzwerkVerbindungen ist ineffizient (im Vergleich zu spezialisierten Datenbank Load/Export Schnittstellen und komprimiertem Dateitransfer) • Extensive Firewall Freischaltungen sind notwendig (von allen Hadoop Knoten auf die jeweilige Datenbank) Besser: Arbeiten Datenbanktools und File-Transfer Schnittstellen wie Elefant Axway / WebHDFS Trifft Schichtenarchitektur / Analytics / 25.02.2016 / Seite 9 Legacy Software und Hadoop - Motivation & Patterns • • • Dort wo Daten Workflows auf bereits implementierte Berechnungen aufbauen (z.B, Funktion zur Produktionsplanung, physikalische Simulation), kann man diese weiterverwenden wollen (um Aufwand in Erstellung, Pflege und Betrieb zu sparen) Für die schnelle Berechnung von Daten Workflows, will man diese aber in kurzer Zeit sehr oft aufrufen – was oft bisherige Deployments überfordert Lösungen • Man baut bisherige Deployments aus, so dass diese auch die Lastspitzen durch Hadoop Berechnungen aushalten • Man baut eine weitere Infrastruktur explizit für die Anfragen aus Hadoop • Man passt die bestehenden Programme so an, dass diese auf Hadoop ausführbar werden Daimler TSS GmbH Elefant Trifft Schichtenarchitektur / Analytics / 25.02.2016 / Seite 10 Migration von Legacy Software - Erfolgskriterien • Deutlich abgegrenzte Inputs und Outputs, keine Aktualisierungen von Daten • Loose Kopplung zu großen Softwaresystemen und Anwendungscontainern • Keine Abhängigkeit • zu lizensierter Software, • lokal installierter Software • Webservices • Einfach anhand der Input Daten teilbares Problem Daimler TSS GmbH Elefant Trifft Schichtenarchitektur / Analytics / 25.02.2016 / Seite 11 Migration von Legacy Software- Stolpersteine • Extensive Verwendung von J2EE Features (Dependency Injection, Beans ..) • Entsprechende Funktionalität steht auf Hadoop nicht zur Verfügung -> größere Änderungen am Code notwendig • Über JBoss Weld / OpenWebBeans teilweise trotzdem machbar • Datenbankzugriffe • Nicht gewünscht, da • Datenbank und Netzwerk Flaschenhals werden (Starten der Operation auf dem Hadoop wird dann DDOS-Angriff) • Extensive Firewall Freischaltungen notwendig werden Daimler TSS GmbH Elefant Trifft Schichtenarchitektur / Analytics / 25.02.2016 / Seite 12 Design Pattern für Datenbank Abhängigkeiten - Memory Dump Applikation, Teil II Hadoop • • • J2EE Container Applikation, Teil I Belassen der Ladelogik in der J2EE Welt Auslesen der Daten und generieren einer In-Memory Repräsentation Serialisieren dieser, verteilen im Hadoop und Einlesen als Teil des Informationsprozesses DB Daimler TSS GmbH Elefant Trifft Schichtenarchitektur / Analytics / 25.02.2016 / Seite 13 Design Pattern für Datenbank Abhängigkeiten - Embedded DB Hadoop Applikation • DB • • DB Daimler TSS GmbH Exportieren der Daten aus der Datenbank Einlesen in einer im Prozess eingebettete DB (z.B. Derby) Nutzen dieser im Informationsprozess im Hadoop Elefant Trifft Schichtenarchitektur / Analytics / 25.02.2016 / Seite 14 Design Pattern für Datenbank Abhängigkeiten - Big Data DB Applikation • Hadoop DB DB Daimler TSS GmbH • • Exportieren der Daten aus der Datenbank Einlesen in eine Datenbank aus dem Hadoop Ökosystem (Impala, Hive, SparkSQL Zugriff aus dieser aus der Applikation Elefant Trifft Schichtenarchitektur / Analytics / 25.02.2016 / Seite 15 Design Pattern für Datenbank Abhängigkeiten - External DB • Hadoop Applikation, Teil II • Aufsetzen eines Datenbankspiegels Zugriff auf diesen aus Hadoop Spiegel DB Daimler TSS GmbH Elefant Trifft Schichtenarchitektur / Analytics / 25.02.2016 / Seite 16 Vergleich von Design Patterns für DB Abhängigkeiten Datenmenge Änderungen Legacy Parallelisierung Komplexität Neuentwicklunge n Memory Dump Klein – Mittel Gering – Groß* Sehr Gut Gering Embedded DB Klein – Mittel Gering - Mittel** Gut Mittel Big Data DB Bis zu sehr Groß Groß Sehr Gut Gering External DB Klein – Groß Gering Schlecht Gering *: Abhängig davon ob im Legacy Code schon eine In-Memory Datenstruktur besteht **: Abhängig von den im Legacy Code notwendigen DB Features Daimler TSS GmbH Elefant Trifft Schichtenarchitektur / Analytics / 25.02.2016 / Seite 17 Entwicklungsprozesse • Dort wo J2EE Software mit Hadoop Komponenten entwickelt wird, müssen auch die Entwicklungsprozesse angeglichen werden. • Interessante Lessons Learned • Dev, Int, Prod? • Artefakte und Komponenten • Teststrategie Daimler TSS GmbH Elefant Trifft Schichtenarchitektur / Analytics / 25.02.2016 / Seite 18 Dev, Int, Prod? • In der Anwendungsentwicklung ist die Trennung in Dev, Int, Prod Umgebungen üblich • Anwendung in der Nutzung von Multi-Tenant ohne bekannte best Platform User Project BigHadoop Data Platform practice Dev-Platform Internal Platform Dev Environment Dev-Tenant Used during development; frequently updated, automatic tests are executed with this instance Int-Tenant Newest stable, running to facilitate manual testing and integration with other developments projects Prod-Tenant Prod version, approved on int. Daimler TSS GmbH Int-Platform Platform to support the development in projects. Also the first platform to get updates (to facilitate testing) Prod-Platform Runs production workloads Dev, Int, Prod II Platform User Project Big Data Platform Dev-Platform Internal Platform Dev Environment Dev-Tenant Used during development; frequently updated, automatic tests are executed with this instance Ad-hoc Platform Platform to support development and ad hoc Analysis Int-Tenant Newest stable, running to facilitate manual testing and integration with other developments projects Prod-Tenant Prod version, approved on int. Sheduled Workloads Runs known, critical workloads Interessanter Aspekt: Die Nutzung einer Shared Service Platform erzwingt eine stärkere Synchronisati der genutzten Java Versionen über alle Anwendungen hinweg! Daimler TSS GmbH Artefakte und Komponenten • Im Detail besteht häufig Verwirrung darüber was am Ende unter eine Hadoop Applikation zu verstehen ist. • Unser Verständnis • Eine Hadoop Applikation besteht aus mehreren „Aktivitäten“ die in Datenpipelines kombinert werden können • MapReduce Jobs, Pig Skripte, Hive Skripte … • Immer nur Artefakte eine Art (MapReduce, Pig, Spark) sind in einem Projekt • Große Teilprojekte einer Softwareentwicklung werden als separate Nutzer auf einem Shared Service Cluster repräsentiert (so lassen sich klare Interfaces durchsetzen) Daimler TSS GmbH Elefant Trifft Schichtenarchitektur / Analytics / 25.02.2016 / Seite 21 Teststrategie • • Unit Tests: Für Applikationen mit Artefakten für eine Hadoop Komponenten gibt es immer Möglichkeiten zur lokalen Ausführung von Unit Tests (JUnit, MRUnit, local spark master) Integration Tests: • Ein Integrationstest besteht aus dem Upload von Daten, dem Ausführen einer Datenpipeline, dem Download und dem Überprüfen von Dateien • Ein Integrationstest passiert innerhalb der Shared Platform (mit einem entsprechenden Nutzer) • Ein Integrationstest kann über die üblichen Schnittstellen eines Shared Clusters (also Webservice Interfaces von Knox) automatisch durchgeführt werden. Daimler TSS GmbH Elefant Trifft Schichtenarchitektur / Analytics / 25.02.2016 / Seite 22 Zusammenfassung • Passive Komponente zur Ausführung von Datenpipelines • Datenintegration zu relationalen Datenbanken über files (nicht Sqoop) • Muster für Migration von Legacy Software • Entwicklungsprozesse • Dev, Int, Prod? • Artefakte und Komponenten • Teststrategie Daimler TSS GmbH Application Client Dynamic HTML Client Tier Web Tier (JSP / Servlet / JSF) Java EE Server Tier AblaufBusiness Tier (EJB)steuerung EIS / DB Tier Elefant trifft Schichtenarchitektur / Analytics / 25.02.2016 / Seite 23 Daimler TSS GmbH Wilhelm-Runge-Straße 11, 89081 Ulm / Telefon +49 731 505-06 / Fax +49 731 505-65 99 [email protected] / Internet: www.daimler-tss.com / Intranet-Portal-Code: @TSS Sitz und Registergericht: Ulm / HRB-Nr.: 3844 / Geschäftsführung: Dr. Stefan Eberhardt (Vorsitzender), Steffen Bäuerle