Hadoop in modernen BI-Infrastrukturen. Dr. Stefan Igel inovex GmbH

Transkript

1 Hadoop in modernen BI-Infrastrukturen Dr. Stefan Igel inovex GmbH

2 Stefan Seit 01/2005 als Projektleiter und Systemarchitekt bei inovex Seit 08/2009 als Business Engineer bei 1&1 Erstkontakt mit Hadoop 09/2009 Mag spannende Projekte Tischtennis-Spieler und Häuslebauer 2

3 Agenda BIG DATA und Hadoop bei 1&1 Jede Menge Blech: Die Hardware Was darf es denn sein: Das Hadoop Ecosystem Speichern, Mappen, Reduzieren Spielregeln im Cluster Der fleißige Handwerker Essenz 3

4 Scaleout am Beispiel eines Transportunternehmens 4

5 Scaleout am Beispiel eines Transportunternehmens 5

6 Scaleout am Beispiel eines Transportunternehmens 6

7 Scaleout am Beispiel eines Transportunternehmens 7

8 Scaleout am Beispiel eines Transportunternehmens 8

9 Scaleout am Beispiel eines Transportunternehmens $ Anschaffung Spezial-Know-how für Betrieb und Wartung Hoher Schaden bei Ausfall $ pro Reifen 9

10 Scaleout am Beispiel eines Transportunternehmens Anschaffung pro Fahrzeug skaliert in beide Richtungen modernisierbar keine Spezialkenntnisse erforderlich Ausfall einzelner Fahrzeuge kompensierbar 10

11 Google Facts Bei einer Google Suchanfrage werden Inhalte von mehr als 3 Milliarden Web-Seiten durchsucht. Das Ergebnis steht innerhalb von 0,5 sec zur Verfügung. Und das bei mehr als 200 Milliarden Suchanfragen pro Tag. Und Terabytes Datenvolumen täglich. 11

12 Scaleout à la Google Google's first production server rack, circa

13 Google, Apache, Hadoop... Google lieferte Idee benutzt Hadoop zur Weiterbildung index.html Cloudera kommerzieller Supoort freie Distribution Apache Committer Apache Hadoop & Zusatzprojekte als Open Source Yahoo Hadoop Initiator Committer freie Distribution PIG eigene Cluster Facebook, Amazon, LinkedIn Apache Commiter eigene Cluster 13

14 Scaleout à la Hadoop Ausführungsumgebung Programmiermodell CPU-Leistung Speicherplatz 14

15 Scaleout à la Hadoop werden auf den Rechenknoten verteilt Ergebnis wird auf beliebig vielen Rechenknoten parallelisiert ausgeführt steht zur Weiterverarbeitung bereit 15

16 Scaleout à la Hadoop One of the features of MapReduce is that one can move the computation close to the data because "Moving Computation is Cheaper than Moving Data 16

17 Scaleout à la Hadoop Map 17

18 Dougs Ratschlag QUESTION What advice would you give to enterprises considering Hadoop? DOUG CUTTING I think they should identify a problem that, for whatever reason, they are not able to address currently, and do a sort of pilot. Build a cluster, evaluate that particular application and then see how much more affordable, how much better it is [on Hadoop] STRATA2012DougCuttingTheApacheHadoopEcosystem jpg

19 Agenda BIG DATA und Hadoop bei 1&1 Jede Menge Blech: Die Hardware Was darf es denn sein: Das Hadoop Ecosystem Speichern, Mappen, Reduzieren Spielregeln im Cluster Der fleißige Handwerker Essenz 19

20 Beispiel 1 WEB.DE 1995 gestartet als Internet-Katalog Eines der größten deutschen Internet-Portale mit 16,44 Mio. Nutzern/Monat* WEB.DE Fre beliebtester deutscher Mail-Dienst mit zahlreichen Sicherheitsfeatures *Unique User / AGOF internet facts

21 Beispiel 2 GMX Fre Pionier mit leistungsstarken Mail- und Messaging-Lösungen 12,75 Mio. Nutzer/ Monat* Umfangreiche Portalangebote, Dienste und Online-Services in Deutschland, Österreich und der Schweiz Internationale Mail-Angebote in sechs Ländern (A, CH, F, E, UK, USA), auch unter mail.com *Unique User / AGOF internet facts

22 5 Hochleistungs- Rechenzentren auf 2 Kontinenten Server 10,67 Mio. Kundenverträge 30,8 Mio. Free-Accounts Hosting von 18 Millionen Domains Rund 9 Milliarden Seitenabrufe im Monat Mehr als 5 Milliarden s pro Monat TByte monatliches Transfervolumen Doppelt sicher durch redundante Rechenzentren (Dual Hosting) Nahezu 100%ige Verfügbarkeit Mehrfach redundante Glasfaser-Anbindung Unterbrechungsfreie Stromversorgung (USV) Vollklimatisierte Sicherheitsräume bieten Schutz vor Gas, Wasser und Feuer Betreuung rund um die Uhr durch hochqualifizierte Spezialisten Betrieb mit grünem Strom 22

23 Hadoop bei 1&1 Development Romania Team Big Data Solutions Development Romania: Search mit Solr und Hadoop Organizer Development UIM Abteilung Target Group Planning: Mehrere produktive Hadoop-Cluster Schwerpunkt Data Mining und Machine Learning Abteilung Web.Intelligence: Produktives Hadoop-Cluster SYNAPSE Web-Analytics, Logfile-Processing und Datawarehousing 23

24 Hadoop bei Web.Intelligence Web-Analytics mit spaltenorientiertem Datenbank-System Erste Evaluierung von Hadoop Januar: Hadoop-Projekt Web-Analytics beginnt Mai: Cluster-Ausbau auf 20 Knoten August: Hadoop-Cluster mit 12 Knoten einsatzbereit Oktober: Hadoop verarbeitet im produktiven Einsatz ca Datensätze/Tag Juni: Hadoop-Projekt Log-Analytics geht live: Datensätze/Tag 24

25 Web.Intelligence Das Prinzip Reporting Stammdaten BI Plattform Datenlieferungen Bewegungsdaten 25

26 ... aber die Menge macht s Web-Analytics: 240 Files/d 200 GB/d * 90d = 18 TB Log-Analytics: Files/d 2000 GB/d * 30d = 60 TB BI Plattform 26

27 Die Aufgabenstellung Massendaten durch Aggregation, Selektion und Verknüpfung in wertvolle Informationen zu wandeln. Horizontale und damit kostengünstige Skalierbarkeit bezüglich Verarbeitungsund Speicherkapazität, um auf wachsende Anforderungen reagieren zu können. Multi-Projekt-Fähigkeit, d.h. Speichern und Verarbeiten von Datenbeständen unterschiedlicher Bedeutung und Herkunft. Einsatz einer Standard-Technologie mit breiter Know-how-Basis unter den Mitarbeitern und in der Open Source-Community. Sämtliche granulare Daten des operativen Geschäfts eines Monats vorhalten. 27

28 Die Lösung SYNAPSE SYNAPSE (SYNergetic Analytical Processing and Storage Engine) ist die Architekturkomponente innerhalb der BI-Plattform, die Massendaten Kosten-/Nutzen-gerecht speichern und verarbeiten kann. Fileserver DWH SYNAPSE 28

29 Einige Herausforderungen bleiben... Geeignete Hardware finden und betreiben Geeignete Hadoop-Frameworks identifizieren MapReduce Algorithmen entwickeln und testen Verschiedene Daten-Eingangs- und Ausgangskanäle Unterschiedliche Dateiformate Mehrere konkurrierende Prozesse Mehrere Benutzer Konsistentes Verarbeiten vieler Eingangs-Files Prozess-Steuerung über einen heterogenen System-Stack 29

30 1&1 Best Practice Identifiziere dein BIG DATA Problem 30

31 Agenda BIG DATA und Hadoop bei 1&1 Jede Menge Blech: Die Hardware Was darf es denn sein: Das Hadoop Ecosystem Speichern, Mappen, Reduzieren Spielregeln im Cluster Der fleißige Handwerker Essenz 31

32 Hardware Sizing Hadoop Data Nodes Empfehlung Cloudera Support* 2 Quad Core CPUs Disk Drive Size 1 2 TByte Auswahl-Kriterien Kosten-Effizienz Stromverbrauch Platz im Rechenzentrum Standard-HW-Warenkorb * clouderas-support-team-shares-some-basic-hardware-recommendations 32

33 Sizing der SYNAPSE Die Szenarien sind Storage Heavy Sizing ist bestimmt durch erforderliche Speicherkapazität: 480 TB 78 TB Nutzdaten (Web- + Log- Analytics) Faktor 2 für Zwischenergebnisse Replikationsfaktor 3 zur Datensicherung 480TB / 2TB / 12 = 20 Rechner x 8 Cores = 160 CPUs! 33

34 Unsere Definition von Commodity Hardware 4x 1GB Network 12 x 2TB as JBOD direct attached 8 96 GB RAM 20 x Worker-Node (Datanode, Tasktracker) 50GB local Storage 4 12 GB RAM 2 x Namenode Server (Namenode, Sec.-Namenode, Jobtracker) 34

35 Best Practice Laste deine Systeme nur zu 75 % aus! Hauptspeicher Im Grenzbereich schafft es die Hadoop interne Speicherverwaltung oft nicht mehr den spill to disk durchzuführen => Out Of Memory Exception Plattenplatz Achtung: auch Zwischenergebnisse mit einrechnen Die Tasktracker schreiben lokale Temp-Files => auch dafür muss Platz vorgesehen werden! 35

36 Das Fileserver Problem Problemstellung Paralleler Zugriff der Tasktracker über zentralen Fileserver via NFS-Mounts (Import Rohdaten, Export von Aggregaten) Konkurrierende Zugriffe reduzieren den Durchsatz überproportional Lösung Reduktion der Zugriffslast Mit einem Prozess im/exportieren (hadoop fs copyfrom/tolocal) z. B. via Fair-Scheduler Pools (fair-scheduler.xml: maxmaps and maxreduces) Externe Systeme verwenden, die auf massiv parallelen Zugriff ausgelegt sind: z. B. Flume für Import z. B. HBase für Export 36

37 Namenode Namenode = HDFS-Metadaten-Verwaltung (Dateien, Verzeichnisse,) Es gibt nur genau EINE Namenode im Cluster Fällt diese aus oder wird korrupt, gibt es keine Daten mehr im Cluster! Namenode Server Hadoop Namenode FS Image FS Image Edit Logs 37

38 Namenode Running Datanodes Namenode Server Hadoop Namenode FS Image FS Image Edit Edit Logs Logs 38

39 Secondary Namenode! = Redundanz Die Secondary Namenode dient lediglich dem Verdichten der persistierten Änderungslogs Die Namenode ist ein SPOF und muss entsprechend abgesichert werden! Namenode Server Hadoop Namenode FS Image Sec. Namenode Server Hadoop Secondary Namenode New FS FS Image New Edit Edit Edit Logs Logs Logs Edit Logs FS Image New FS Image Edit Logs 39

40 Namenode HA Redundanz für Namenode transparent für Cluster Crash Recovery möglich

41 Namenode HA Failover im Sekunden-Bereich Im Worst-Case minimaler Daten- Verlust während Failover möglich Im besten Falle keiner! 41

42 Netzwerk Die Knoten eines Hadoop-Clusters sollten möglichst nahe beieinander stehen und auch bei den Datenquellen dafür muss Platz im Rechenzentrum verfügbar sein Je besser die Netzwerk-Anbindung des Clusters desto besser seine Performance 1GBit 4GBit 2GBit each 42

43 1&1 Best Practice Identifiziere dein BIG DATA Problem Etwas mehr schadet nicht: Alle Systeme müssen skalieren und benötigen Reserven, Namenode HA! 43

44 Agenda BIG DATA und Hadoop bei 1&1 Jede Menge Blech: Die Hardware Was darf es denn sein: Das Hadoop Ecosystem Speichern, Mappen, Reduzieren Spielregeln im Cluster Der fleißige Handwerker Essenz 44

45 Wir machen unsere Werkzeugkiste auf und schauen mal, was wir darin finden... 45

46 Aufgabenverteilung Transport kontinuierlich entstehender Massendaten Aggregationen alle 3 Stunden Vorgänge koordinieren >1000 Files/Tag ~ 3TB Aggregation Speicherung Suche AdHoc Anfragen ILM Integration mit DWH Nachvollziehbarkeit Wiederaufsetzbarkeit 46

47 Unser Technologie- Stack (Reduced to the Max) Quelle: 47

48 Lessons learned Stabilität Entwicklung ist immer noch im Fluss Hadoop- Kern ist bereits sehr stabil - aber kein Vergleich bspw. mit einer DB-Lösung Flankierende Projekte haben gefühlt oft noch Beta-Status im Handumdrehen ist man Committer eines OS-Projektes ;-) 48

49 Lessons learned Feature-Set Ähnliche Toolsets unterscheiden sich meist nur in Details Pig, Hive, Cascading HBase und Casandra Askaban vs. Oozie Aber gerade die können manchmal entscheidend sein! 49

50 Schön, dass es Distributionen gibt! Hadoop-Solution- Provider... geben Sicherheit Beispiel: Cloudera Hadoop-Solution-Partner geben Sicherheit Eigenes Hadoop-Release basierend auf den Apache Repositories Beispiel: Cloudera bietet konsistente, in sich schlüssige Release-Stände und Bugfixes Eigenes Hadoop-Release basierend auf den Apache Repositories bietet konsistente, in sich schlüssige Release-Stände und Bugfixes Möglichkeit des kommerziellen Supports Möglichkeit des kommerziellen Supports 50

51 1&1 Best Practice Identifiziere dein BIG DATA Problem Etwas mehr schadet nicht: Alle Systeme müssen skalieren und benötigen Reserven, Namenode HA! Keep Your Ecosystem Simple, wähle sorgfältig aus! 51

52 Agenda BIG DATA und Hadoop bei 1&1 Jede Menge Blech: Die Hardware Was darf es denn sein: Das Hadoop Ecosystem Speichern, Mappen, Reduzieren Spielregeln im Cluster Der fleißige Handwerker Essenz 52

53 Architektur BI-Plattform Access Reporting Adhoc Queries (Mass-)Data Export DWH Oracle 11g EE Database Reporting Layer (Dependent Datamarts) Integration Layer (Core DWH) Acquisition Layer (Staging Area) 4. Verfügbar machen 3. Transformieren 2. Speichern 1. Importieren BI Source Systems Source Data Fileserver Replicated Source Data 53

54 Architektur BI-Plattform Access Reporting Adhoc Queries (Mass-)Data Export DWH Oracle 11g EE Database Reporting Layer (Dependent Datamarts) Integration Layer (Core DWH) Acquisition Layer (Staging Area) SYNAPSE Mass Data Hadoop Cluster Mass Data Aggregation Layer Mass Data Integration Layer Mass Data Acquisition Layer 4. Verfügbar machen 3. Transformieren 2. Speichern 1. Importieren BI Source Systems Source Data Fileserver Replicated Source Data 54

55 Importieren und Speichern Das Serialisierungs- Framework Unterstützt die Verarbeitung durch Header-Zeile pro File mit Typ-Information (JSON-Format) Versionsprüfung möglich IDL optional Effiziente Verarbeitung durch Speicher-effizientes Binärformat (De-)Serialisierung ok Zukunftssicher da Künftiger Hadoop-Standard Aktive Weiterentwicklung Sukzessive Integration in die Hadoop-Teilprojekte # avro textual representation {"type": "record", "name": "Point", "fields": [ {"name": "x", "type": "int"}, {"name": "y", "type": "int"} ] }

56 Importieren und Speichern FLIS - Flexibilität gefragt Plain csv Flexible Input Selector thrift 56

57 Transformieren Join in MapReduce Map Side Join Eingangsfiles müssen nach gleichem Schlüssel sortiert und partitioniert sein Sorted-Merged-Join noch vor dem Mapper Sehr effizient, da Shuffle/Sort-Phase nichts mehr zu tun hat Reduce Side Join Klassischer MR-Join Hauptlast wird in der Shuffle/Sort- Phase getragen 57

58 Transformieren Join in MapReduce Join-Operationen können in MR als Hash Join implementiert werden Lookup wird als Hashmap über den Distributed Cache an Mapper verteilt Kleine CPU, keine Netzwerk-Last während der Verarbeitung Die Grenze bildet das Volumen der Lookup-Daten Lookup- Data Lookup- Data Lookup- Data Lookup- Data Lookup- Data Data Data MR- Join Res ult Data Data MR- Join Res ult 58

59 Transformieren... oder doch mit Hbase? Distributed Key-Value Stores f(k) = V Datenzugriff granular Antwortzeiten im Milli-Sekunden-Bereich Auf Lesezugriff optimiert 59

60 Transformieren mit PIG Ursprünglich von Yahoo entwickelt File basiertes High Level Daten-Manipulations-Framework SQL-artige Sprache welche durch das Framework in Map/Reduce Jobs übersetzt und ausgeführt wird 60

61 Transformieren Ergebnisse aus Web-Analytics Projekt: Optimierung der Verarbeitung-Algorithmen kann erheblichen Performance-Gewinn bringen! Monthly Aggregation Weekly Aggregation Daily Aggregation 61

62 Lessons learned Know-how... Muss oft erst aufgebaut werden. Hierfür passende Projekte einplanen. Am Anfang fehlt das Know-how an allen Fronten DEV: Best Practices sind nicht vorhanden. Oft funktionieren die Dinge in Dev und brechen dann im Live-Einsatz. QS: Herausforderung: verteiltes Testen - möglichst mit Echt-Daten (bzgl. Qualität und Quantität) LIVE: Lastverhalten ist nur bedingt vorhersehbar. Tuning- Möglichkeiten mannigfaltig und oft nur mit DEV- Unterstützung durchführbar. 62

63 1&1 Best Practice Identifiziere dein BIG DATA Problem Etwas mehr schadet nicht: Alle Systeme müssen skalieren und benötigen Reserven, Namenode HA! Keep Your Ecosystem Simple, wähle sorgfältig aus! Die Algorithmen bestimmen die Effizienz! 63

64 Agenda BIG DATA und Hadoop bei 1&1 Jede Menge Blech: Die Hardware Was darf es denn sein: Das Hadoop Ecosystem Speichern, Mappen, Reduzieren Spielregeln im Cluster Der fleißige Handwerker Essenz 64

65 BI-Plattform Information Lifecycle Management Access Standard Reporting Adhoc Queries (Mass) Data Export DWH Oracle 11g EE Database Reporting Layer (Dependent Datamarts) Integration Layer (Core DWH) Acquisition Layer (Staging Area) DWH als Langzeit- Archiv Kosten: 0,15 /MB Hadoop Cluster Mass Data Aggregation Layer Mass Data Integration Layer Mass Data Acquisition Layer Hadoop als Kurzzeit-Archiv Kosten: 0,0005 /MB BI Source Systems Source Data WI Gateway Fileserver Replicated Source Data 65

66 Speichern: Gerne aber wie lange? Auch 500 TByte sind irgendwann einmal voll! IL separat für jede Verarbeitungsebene Je wertvoller die Daten, desto länger der IL Bei vielen 1000 Files hohe Anforderung ans Housekeeping in der SYNAPSE (s. u.) System Ebene Begründung Aufbewahrung Fileserver Import Nachladen 5 Tage Export Fachliche Anforderung 40 Tage SYNAPSE Acquisition Algorithmus / Nachberechnen 30 Tage Integration Fachliche Anforderung Tage Aggregatio n Nachladen 5 Tage DWH Acquisition Nachberechnen 30 Tage Integration Fachliche Anforderung 2-10 Jahre Reporting Fachliche Anforderung 2-10 Jahre 66

67 Mehrparteien- Betrieb Wer darf wann? Hadoop Job Scheduler Gleichmäßige Lastverteilung über die Zeit nach Prioritäten Verschiedene Anwendungen können konkurrierend betrieben werden Mechanismus Default Capacity Fair Vergeben von Prioritäten pro Job Job-Queues mit festgelegten Prioritäten Funktionsfähig Ja Ja Ja Clusterauslastung Ja Nein Ja Gefahr von Starvation Ja Nein Nein Job-Queues und Pools mit Gewichten 67

68 Mehrparteien- Betrieb Wer darf überhaupt? Hadoop hat ein Zugriffsberechtigungskonzept angelehnt an POSIX (ohne sticky, setuid or setgid bits) für Files und Directories Hadoop hat keine eigene Benutzer-Authentifizierung Hadoop übernimmt user name (whoami) und group name (bash -c groups) vom aufrufenden Client-Prozess Authorisierung ist damit (nur) auf File- und Verzeichnisebene möglich Das schützt im Mehrparteienbetrieb vor versehentlichem Löschen oder Überschreiben fremder Dateien. Authorisierung muss auf Betriebssystem-Ebene konsequent umgesetzt sein Geeignetes Konzept für Tool -User oder Application Manager This user identity mechanism combined with the permissions model allows a cooperative community to share file system resources in an organized fashion. 68

69 1&1 Best Practice Identifiziere dein BIG DATA Problem Etwas mehr schadet nicht: Alle Systeme müssen skalieren und benötigen Reserven, Namenode HA! Keep Your Ecosystem Simple, wähle sorgfältig aus! Die Algorithmen bestimmen die Effizienz! Sorge für geordnete Verhältnisse im Cluster! 69

70 Agenda BIG DATA und Hadoop bei 1&1 Jede Menge Blech: Die Hardware Was darf es denn sein: Das Hadoop Ecosystem Speichern, Mappen, Reduzieren Spielregeln im Cluster Der fleißige Handwerker Essenz 70

71 Azkaban (LinkedIn) PRO Workflows können graphisch dargestellt und gedrilled werden Einfache Handhabung (Komplexes wird in Scripts ausgelagert) Startet Hadoop-Jobs und Anderes einfach als Unix-Prozesse Ressoucen (.jar files, pig scripts) werden durch Azkaban verwaltet und deployed CONTRA Minimaler Funktionsumfang Keine Rechte und Zugriffs- Verwaltung Jobausführung nur Zeit-basiert Keine Redundanz (Azkaban-Server wird zum SPOF) 71

72 Oozie (Yahoo!) PRO Enge Integration mit Hadoop and M/R Kann mit unterschiedlichen Job- Typen umgehen: Java MR, PIG, Java, etc. Webservice- und Java-API Zeit- und Ereignis-basierte Job- Ausführung CONTRA WEB-Konsole ist Read-Only, keine graphische Aufbereitung von Abhängigkeiten Ressoucen (.jar files, pig scripts) müssen manuell vor der Jobausführung auf dem HDFS deployed werden Müsste um File-Registierung erweitert werden 72

73 Architektur BI-Plattform Steuerung Steuerung der Verarbeitung und damit der Datenströme muss über den gesamten BI-Stack sichergestellt sein! Das richtige Werkzeug für die jeweilige Aufgabe: GEPPI = 1&1 EAI-Lösung (Workflow-Steuerung) FUNDI = eigens entwickelter verlängerter Arm für Hadoop-Spezifika 73

74 Das richtige Werkzeug für die jeweilige Aufgabe PDI ( ETL-Jobs im DWH HDFS-Zugriff delegiert an Pentaho Kettle GEPPI = Workflow-Engine Übergreifende-Steuerung Functional Dependency Integrator Hadoop Job-Ausführung Data-Repository 74

75 FUNDI Swahili für... Der fleißige Handwerker FUNDI File-Registration Register File & Metadata Distributed or local File System File Registration Functional Dependency Integrator Search for matching files Data Files 75

76 FUNDI Swahili für... Der fleißige Handwerker Fundi Job-Run get Jar/PIG Metadata Input-Filenames Register Output-Files & Metadata Hadoop-Cluster Inp. Data Files Run Job(name) Functional Dependency Integrator Start MR Job Outp Data Files 76

77 FUNDI Swahili für... Der fleißige Handwerker Fundi Job-Ketten (Das EVA-Prinzip) Metadata for Job-Rung, Inp.-Files, Outp.-Files E V A Named-Input Fundi-JOB A Named-Output Fundi-JOB B Configuration e.g. Path, Filenames, Jar/PIG-Script, Settings 77

78 1&1 Best Practice Identifiziere dein BIG DATA Problem Etwas mehr schadet nicht: Alle Systeme müssen skalieren und benötigen Reserven, Namenode HA! Keep Your Ecosystem Simple, wähle sorgfältig aus! Die Algorithmen bestimmen die Effizienz! Sorge für geordnete Verhältnisse im Cluster! Es geht auch ohne Skript-Wüste und cron-jobs! 78

79 Agenda BIG DATA und Hadoop bei 1&1 Jede Menge Blech: Die Hardware Was darf es denn sein: Das Hadoop Ecosystem Speichern, Mappen, Reduzieren Spielregeln im Cluster Der fleißige Handwerker Essenz 79

80 Lange Rede kurzer Sinn: Die Aufgabe Hadoop verlangt ein neues Denken in allen IT-Bereichen: Operations, Entwicklung, QS, Binde alle Stakeholder möglichst früh in deine Planung ein! Know-how zum Entwickeln, Testen und Betreiben einer verteilten Umgebung muss erarbeitet werden! Identifiziere dein Pilotprojekt! Bleibe nicht zu lange im Spielbetrieb, evaluiere gegen echte Anforderungen! 80

81 Lange Rede kurzer Sinn: Die Belohnung Hadoop und sein Ecosystem bieten hervorragende Lösungen für viele BIG DATA Probleme! 81

82 Lange Rede kurzer Sinn: Der Beweis Massendatenverarbeitung ist bei 1&1 für Web-Analytics, Logfile-Verarbeitung und Datawarehousing mit Hadoop messbar performanter, kostengünstiger, skalierbarer, flexibler und zukunftsfähiger geworden! 82

83 Vielen Dank für eure Aufmerksamkeit 83