Über unsMediaKontaktImpressum
Dominik Claßen 02. Mai 2017

Hadoop-Implementierungen: Sieben häufige Fehler

Die Data Lake-Metapher verleitet dazu, sich den Data Lake als klaren Bergsee vorzustellen. © ristoviitanen / Fotolia.com
© ristoviitanen / Fotolia.com

Es ist kein Geheimnis, dass Hadoop komplex ist und Unternehmen vor zahlreiche Herausforderungen stellt. Und obwohl sich viele dessen bewusst sind, scheitern doch viele Hadoop-Implementierungen. Die Ursachen für das Scheitern von Hadoop-Projekten sind häufig die gleichen, unabhängig von der Branche.

Die folgende Zusammenstellung häufiger Fehler basiert auf Pentahos langjähriger Erfahrung mit Big Data-Projekten und umfasst sowohl taktische als auch strategische Fehler:

Fehler Nr. 1: Der Versuch alles neu zu erfinden

Viele Anwender versuchen die ersten Schritte mit Bordmitteln, die zwar ihre Daseinsberechtigung haben, aber letztendlich mehr Probleme verursachen können als sie lösen. Die Data Warehouse-Welt fing vor vielen Jahren mit Scripten an und entwickelte sich dann über Code-Generatoren und proprietäre "Black Boxes" hin zu modernen Datenintegrations-Engines, die eben auch Hadoop beherrschen. Oft wird bei Hadoop-Implementierungen allerdings ein Schritt zurück gemacht und gescriptet, anstatt sich moderner Tools zu bedienen, die beide Welten abdecken können. Gerade wenn es darum geht, Massendaten aus tausenden von Datenquellen in einen Data Lake zu pumpen und dort aufzubereiten, stoßen Scripte schnell an ihre Grenzen.

Fehler Nr. 2: Migration ohne Plan

Big Data-Technologien lösen Probleme, die mit SQL-basierten Lösungen nicht oder nur extrem schwer und teuer umzusetzen sind. Da diese neuen Technologien aber in weiten Teilen auf einem grundverschiedenen Ansatz basieren, kommen mit ihnen auch neue Herausforderungen. Man sollte daher abwägen, welche Technologie bzw. welche Kombination an Technologien man einsetzt, um diese Herausforderungen zu lösen. Und nicht, wie es in der Praxis oft geschieht, eine Migration bzw. Erweiterung ohne langfristige Strategie zu starten, da sich dies im Nachhinein oft mit hohen Kosten rächt. Wichtig ist es, alle Phasen des Prozesses – von der Datenaufnahme über die Transformation zur Analyse und darüber hinaus von Anfang an zu berücksichtigen. Auch den betrieblichen Nutzen sollte man nicht aus den Augen lassen. Technologie nur um der Technologie willen einzusetzen, kann zwar Spaß machen, kommt aber oft über den Status eines "Jugend forscht"-Projekts nicht hinaus.

Fehler Nr. 3: Zu glauben, dass das traditionelle relationale Datenbank-Know-how auch für Hadoop ausreicht

Nach wie vor hält sich der Glaube, dass man ein relationales Datenbankmanagementsystem (RDBMS) im Verhältnis 1:1 mit Hadoop ersetzen kann und damit für geringere Kosten ein leistungsfähigeres System erhält. Da Hadoop aber nun mal kein RDBMS ist, sondern ein Framework auf einem verteilten Dateisystem, funktioniert dieser Ansatz nicht. Hier gilt es, die richtigen Technologien und vor allem auch Gesamtarchitekturen auszuwählen und gründlich zu planen. SQL-on-Hadoop macht zwar deutliche Fortschritte, ist aber in vielen Punkten noch weit davon entfernt, einem klassischen, gereiften RDBMS den Rang abzulaufen. Viele der neuen SQL-on-Hadoop-Technologien bieten gerade für den analytischen Gebrauch schon einiges. Um diese aber richtig einsetzen zu können, benötigt man Spezialkenntnisse. Die Erfahrung mit relationalen Datenbanken hilft hier nur begrenzt weiter.

In der Realität verkommt der Data Lake nicht selten zu einem Sumpf.

Fehler Nr. 4: Einen Hadoop Data Lake wie eine normale Datenbank behandeln

Der Hadoop Data Lake wie eine normale Datenbank zu behandeln, ist ein typisches Missverständnis. Hadoop ist leistungsstark, aber eben nicht in der gleichen Art und Weise strukturiert wie z. B. eine Datenbank von Oracle, HP Vertica oder Teradata. Der Vergleich von ELT mit einer klassischen Staging Area verführt dazu, die Dinge zu vermischen. Die Data Lake-Metapher verleitet außerdem dazu, sich den Data Lake als einen klaren Bergsee vorzustellen, in dem alles schnell zu finden ist. In der Realität verkommt der Data Lake aber nicht selten zu einem Sumpf. Hier ist es besonders wichtig, schon beim ersten Schritt – dem Laden der Rohdaten – auf die Erfassung und Nutzung von Metadaten und die Erstellung einer nachvollziehbaren Struktur zu achten. Ein Data Lake ergänzt typischerweise ein existierendes Data Warehouse (DWH) und ermöglicht es, jene Daten effizient zu verarbeiten, die bisher nicht recht ins "SQL-Korsett" passen wollten.

Fehler Nr. 5: Sicherheit auf die lange Bank schieben

Für die meisten Unternehmen ist Sicherheit ein sensibles Thema und sollte daher auch unbedingt von Anfang an bei der Planung berücksichtigt werden. Man sieht oft, dass erste Prototypen ohne jedes Sicherheitskonzept aufgesetzt werden, sodass die gewählte Technologie später die benötigte Sicherheit (noch) nicht bietet. Um das zu ändern, sollten folgende Sicherheits-Features in den Plan mit einbezogen werden:

  • Authentifizierung: kontrolliert, wer Zugriff auf das Cluster hat.
  • Autorisierung: kontrolliert, was die einzelnen Nutzer im Cluster (mit den Daten) tun dürfen.
  • Audit und Tracking: Verfolgt und registriert zu Dokumentationszwecken alle Handlungen der Nutzer.
  • Datenschutzvorschriften: Verwendung von Standard-Methoden zur Datenverschlüsselung in Übereinstimmung mit den jeweils gültigen Datenschutzrichtlinien. Hierzu gehören auch Anonymisierung und Tokenization.
  • Automatisierung: Vorbereitung, Verknüpfung, Meldung und Verschicken von Warnmeldungen basierend auf den Hadoop-Daten.
  • Predictive Analytics: Integration von Predictive Analytics, um in Fast-Echtzeit Daten und Nutzerverhalten auf Auffälligkeiten hin zu analysieren.

Brauchen wir Big Data jetzt oder erst in der Zukunft?

Fehler Nr. 6: Kein Geschäftsziel definieren

Hadoop-Projekte sind komplex. Um besser zu verstehen, wann, wo und für was man es eigentlich einsetzt, sollte unbedingt der Input von allen am Projekt Beteiligten von Anfang an miteinbezogen werden. Dabei steht an erster Stelle die Frage, welches Geschäftsziel erreicht werden soll, wer von der Investition profitiert und wie man die Ausgaben rechtfertigt. Die meisten Big Data-Projekte scheitern daran, dass sie nicht den gedachten Mehrwert erzielen. Um den Mehrwert richtig zu kalkulieren, muss man mit dem zu lösenden Datenproblem beginnen. Brauchen wir Big Data jetzt oder erst in der Zukunft? Brauchen wir Self-Service-Datenaufbereitung? Müssen die Analysefunktionen in andere Anwendungen oder Portale eingebettet werden? Ist die Datenaufbereitung langwieriger oder die Visualisierung? Die Beantwortung dieser Fragen hilft, zu ermitteln, ob die gegenwärtige Architektur eventuell doch ausreicht, um die Geschäftsziele zu erreichen oder ob man eine neue Architektur braucht.

Fehler Nr. 7: Das Budget, das Budget...

Einer der Gründe, warum Unternehmen auf Hadoop setzen, ist der Preis. Hadoop ist relativ günstig und lässt sich kosteneffizient skalieren. Viele übersehen bei der Planung allerdings die mit Hadoop verbundenen versteckten Kosten, wie z. B. die Kosten für Replikation/Kompression, die Kosten für Fachkenntnisse und die Kosten für das Datenintegrationsmanagement. Hadoop wurde entwickelt, um eine enorme Datenmenge zu verarbeiten, die nicht nur vielfältig ist, sondern auch schnell wächst. Bezogen auf die Replikation heißt das aber auch, dass bei einer Standardeinstellung mit dreifacher Replikation (zur Vereinfachung sei hier mal die Kompression der verschiedenen Dateiformate in HDFS (Hadoop Distributed File System) außen vor gelassen) für 1TB Daten mindestens 3TB Speicherplatz benötigt werden. Ein ebenfalls wichtiger Faktor für das Sizing ist die Art der Nutzung. Ist ein einfacher Datenspeicher gewünscht, begnügt man sich mit geringer Rechenleistung und großen Festplatten. Ist allerdings geplant, Machine Learning oder In Memory-Technologien einzusetzen (Stichwort "big compute"), sind die Anforderungen an die Hardware logischerweise deutlich höher, der Mehrwert allerdings meist auch.

Durch die Vermeidung dieser häufigen Fehler wird Hadoop zwar immer noch nicht zum Kinderspiel, aber die größten Stolperfallen lassen sich umgehen.

nach Oben
Autor

Dominik Claßen

Dominik Claßen ist Director of Sales Engineering EMEA & APAC bei Pentaho. Er ist ein Branchenkenner mit mehr als zehnjähriger Arbeitserfahrung im Bereich Business Analytics/Business Intelligence.
>> Weiterlesen
botMessage_toctoc_comments_929