Hadoop in modernen BI-Infrastrukturen Dr. Stefan Igel inovex GmbH
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 stefan.igel@inovex.de 2
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
Scaleout am Beispiel eines Transportunternehmens 4
Scaleout am Beispiel eines Transportunternehmens 5
Scaleout am Beispiel eines Transportunternehmens 6
Scaleout am Beispiel eines Transportunternehmens 7
Scaleout am Beispiel eines Transportunternehmens 8
Scaleout am Beispiel eines Transportunternehmens $5.000.000 Anschaffung Spezial-Know-how für Betrieb und Wartung Hoher Schaden bei Ausfall $46.000 pro Reifen 9
Scaleout am Beispiel eines Transportunternehmens 40.000 Anschaffung pro Fahrzeug skaliert in beide Richtungen modernisierbar keine Spezialkenntnisse erforderlich Ausfall einzelner Fahrzeuge kompensierbar 10
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 20.000 Terabytes Datenvolumen täglich. 11
Scaleout à la Google Google's first production server rack, circa 1998 http://en.wikipedia.org/wiki/google_platform 12
Google, Apache, Hadoop... Google lieferte Idee benutzt Hadoop zur Weiterbildung http://code.google.com/edu/parallel/ index.html Cloudera kommerzieller Supoort freie Distribution Apache Committer http://www.cloudera.com Apache Hadoop & Zusatzprojekte als Open Source http://hadoop.apache.org Yahoo Hadoop Initiator Committer freie Distribution PIG eigene Cluster http://developer.yahoo.com/hadoop Facebook, Amazon, LinkedIn Apache Commiter eigene Cluster 13
Scaleout à la Hadoop Ausführungsumgebung Programmiermodell CPU-Leistung Speicherplatz 14
Scaleout à la Hadoop werden auf den Rechenknoten verteilt Ergebnis wird auf beliebig vielen Rechenknoten parallelisiert ausgeführt steht zur Weiterverarbeitung bereit 15
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
Scaleout à la Hadoop Map 17
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]. http://www.computerworld.com/s/article/9222758/the_grill_doug_cutting 18 http://a.images.blip.tv/strataconf- STRATA2012DougCuttingTheApacheHadoopEcosystem410-224.jpg
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
Beispiel 1 WEB.DE 1995 gestartet als Internet-Katalog Eines der größten deutschen Internet-Portale mit 16,44 Mio. Nutzern/Monat* WEB.DE FreeMail beliebtester deutscher Mail-Dienst mit zahlreichen Sicherheitsfeatures *Unique User / AGOF internet facts 2011-12 20
Beispiel 2 GMX FreeMail 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 2011-12 21
5 Hochleistungs- Rechenzentren auf 2 Kontinenten 70.000 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 E-Mails pro Monat 9.000 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
Hadoop bei 1&1 Development Romania Team Big Data Solutions Development Romania: Email Search mit Solr und Hadoop Email 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
Hadoop bei Web.Intelligence 2006 2009 2011 2012 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. 200.000.000 Datensätze/Tag Juni: Hadoop-Projekt Log-Analytics geht live: 1.000.000.000 Datensätze/Tag 24
Web.Intelligence Das Prinzip Reporting Stammdaten BI Plattform Datenlieferungen Bewegungsdaten 25
... aber die Menge macht s Web-Analytics: 240 Files/d 200 GB/d * 90d = 18 TB Log-Analytics: 1.000 Files/d 2000 GB/d * 30d = 60 TB BI Plattform 26
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
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
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
1&1 Best Practice Identifiziere dein BIG DATA Problem 30
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
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 * http://www.cloudera.com/blog/2010/03/ clouderas-support-team-shares-some-basic-hardware-recommendations 32
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
Unsere Definition von Commodity Hardware 4x 1GB Network 12 x 2TB as JBOD direct attached 8 Cores @2,4GHz 96 GB RAM 20 x Worker-Node (Datanode, Tasktracker) 50GB local Storage 4 Cores @2,4GHz 12 GB RAM 2 x Namenode Server (Namenode, Sec.-Namenode, Jobtracker) 34
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
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
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
Namenode Running Datanodes Namenode Server Hadoop Namenode FS Image FS Image Edit Edit Logs Logs 38
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
Namenode HA Redundanz für Namenode transparent für Cluster Crash Recovery möglich http://www.clusterlabs.org/ http://www.drbd.org/ 40
Namenode HA Failover im Sekunden-Bereich Im Worst-Case minimaler Daten- Verlust während Failover möglich Im besten Falle keiner! 41
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
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
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
Wir machen unsere Werkzeugkiste auf und schauen mal, was wir darin finden... 45
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
Unser Technologie- Stack (Reduced to the Max) Quelle: http://www.flickr.com/photos/_mrs_b/4717427429/ 47
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
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
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
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
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
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
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
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"} ] } 5 8-3 4 2-7 55
Importieren und Speichern FLIS - Flexibilität gefragt Plain csv Flexible Input Selector thrift 56
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
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
Transformieren... oder doch mit Hbase? Distributed Key-Value Stores f(k) = V Datenzugriff granular Antwortzeiten im Milli-Sekunden-Bereich Auf Lesezugriff optimiert 59
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 http://hadoop.apache.org/pig/ 60
Transformieren Ergebnisse aus Web-Analytics Projekt: Optimierung der Verarbeitung-Algorithmen kann erheblichen Performance-Gewinn bringen! 12 10 8 6 4 2 0 Monthly Aggregation Weekly Aggregation Daily Aggregation 61
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
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
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
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
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 15-90 Tage Aggregatio n Nachladen 5 Tage DWH Acquisition Nachberechnen 30 Tage Integration Fachliche Anforderung 2-10 Jahre Reporting Fachliche Anforderung 2-10 Jahre 66
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
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. http://hadoop.apache.org/common/docs/r0.20.2/hdfs_permissions_guide.html 68
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
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
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
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
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
Das richtige Werkzeug für die jeweilige Aufgabe PDI (http://kettle.pentaho.com/) 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
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
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
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
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
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
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
Lange Rede kurzer Sinn: Die Belohnung Hadoop und sein Ecosystem bieten hervorragende Lösungen für viele BIG DATA Probleme! http://www.flickr.com/photos/xrm0/184379507/ 81
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
Vielen Dank für eure Aufmerksamkeit 83