The New Age of Big Data: Is It the Death of Hadoop?

Big Data had gone through several transformations through the years, growing into the phrase we identify it as today. From its first identified use on the back of Hadoop and MapReduce, a new age of Big Data has been ushered in with the spread of new technologies such as Kubernetes, Spark, and NoSQL databases.

These might not serve the exact same purpose as Hadoop individually, but they fill the same niche and do the same job with features the original platform designers never envisioned.

The multi-cloud architecture boom and increasing emphasis on real-time data may just mean the end of Big Data as we know it, and Hadoop with it.

A brief history of Big Data

The use of data for making business decisions can be traced back to ancient civilizations in Mesopotamia. However, the age of Big Data as we know it is only as old as 2005 when O’Reilly Media launched the phrase. It was used to describe the massive amounts of data that the world was beginning to produce on the internet.

The newly-dubbed Web 2.0 needed to be indexed and easily searchable, and, Yahoo, being the behemoth that it was, was just the right company for the job. Hadoop was born off the efforts of Yahoo engineers, depending on Google’s MapReduce under the hood. A new era of Big Data had begun, and Hadoop was at the forefront of the revolution.

The new technologies led to a fundamental shift in the way the world regarded data processing. Traditional assumptions of atomicity, consistency, isolation, and durability (ACID) began to fade, and new use cases for previously unusable data began to emerge.

Hadoop would begin its life as a commercial platform with the launch of Cloudera in 2008, followed by rivals such as Hortonworks, EMC and MapR. It continued its momentous run until it seemingly hit its peak in 2015, and its place in the enterprise market would never be guaranteed again

Where Hadoop Couldn’t Keep Up

Hadoop made its mark in the world of Big Data by being a platform to collect, store and analyze large swathes of data. However, not even a technology as revolutionary and versatile as Hadoop could exist without its drawbacks.

Some of these would be so costly developers would rather design whole new systems to deal with them. With time, Hadoop started to lose its charm, unable to grow past its initial vision as a Big Data software.

Hadoop is a machine made up of smaller moving parts that are incredibly efficient at what they do – crunch data. This ultimately results in one of the first drawbacks of Hadoop – it does not come with built-in support for analytics data. Hadoop works well to process your data, but not likely as you need – visual reports about how the data is being processed, for instance.

MapReduce was also built from the ground up to be file-intensive. This makes it a great piece of software for simple requests, but not so much for iterative data. For smaller datasets, it turns out to be a rather inefficient solution.

Another area Hadoop lands flat on its face is with regards to real-time processing and reporting. Hadoop suffers from the curse of time. It relies on technologies that even its very founders (Google in particular) no longer rely on.

With MapReduce, every time you want to analyze a modified dataset (say, after adding or deleting data), you have to stream over the whole dataset again. Thanks to this feature, Hadoop is horrible at real-time reporting – a feature that led to the creation of Percolator, MapReduce’s replacement within Google.

The emergence of better technology has also meant a rise in the number of threats to said technology and a corresponding increase in the emphasis that is placed on it.

Unfortunately, Hadoop is nowhere close to being secure. As a matter of fact, its security settings are off by default, and it has too much inertia to simply change that. To make things worse, plugging in security measures isn’t that much easier.

The Fall of Hadoop

With these and more shortcomings in the data science world, new tools such as Hive, Pig and Spark were created to work on top of Hadoop to overcome its weaknesses. But it simply couldn’t grow out of the shoes it had been made for.

The growth of NoSQL databases such as Hazelcast and MongoDB also meant that problems Hadoop was designed to support were now being solved by single players rather than the ‘all or nothing’ approach Hadoop was designed with. It wasn’t flexible enough to evolve beyond simply being a batch processing software.

Over time, new Big Data challenges began to emerge that a large monolithic software like Hadoop couldn’t deal with, either. Being primarily file-intensive, it couldn’t keep up with the variety of data sources that were now available, the lack of support for dynamic schemas, on-the-fly queries, and the rise of cloud infrastructure all caused people to seek different solutions. Hadoop had lost its grip on the enterprise world.

Businesses whose primary concern was dealing with Hadoop infrastructure like Cloudera and Hortonworks were seeing less and less adoption. This led to the eventual merger of the two companies in 2019, and the same message rang out from different corners of the world at the same time: ‘Hadoop is dead.’

Is Hadoop Really Dead?

Hadoop still has a place in the enterprise world – the problems it was designed to solve still exist to this day. Technologies such as Spark have largely taken over the same space that Hadoop once occupied.

The question of Hadoop or Spark is one every data scientist has to contend with at some point, and most seem to be settling in the latter of these, thanks to the great advantages is speed it offers.

It’s unlikely Hadoop will see much more adoption with newer marker entrants, especially considering the pace with which technology moves. It also doesn’t help that a lot of alternatives have a much smaller learning curve than the convoluted monolith that is Hadoop. Companies like MapR and Cloudera have also begun to pivot away from Hadoop-only infrastructure to more robust cloud-based solutions. Hadoop still has its place, but maybe not for long.

Cloudera und Hortonworks vollenden geplante Fusion

Kombiniertes „ Open-Source-Powerhouse” wird die branchenweit erste Enterprise Data Cloud vom Netzwerk-Rand (Edge) bis hin zu künstlicher Intelligenz bauen.

München, Palo Alto (Kalifornien), 03. Januar 2019 – Cloudera, Inc. (NYSE: CLDR) hat den Abschluss seiner Fusion mit Hortonworks, Inc. bekanntgegeben. Cloudera wird die erste Enterprise Data Cloud bereitstellen, die die ganze Macht der Daten freisetzt, welche sich in einer beliebigen Cloud vom Netzwerk-Rand (Edge) bis zur KI bewegen –  all dies basierend auf einer hundertprozentigen Open-Source-Datenplattform. Die Enterprise Data Cloud unterstützt sowohl hybride als auch Multi-Cloud-Deployments. Unternehmen erhalten dadurch die nötige Flexibilität, um Machine Learning und Analysen mit ihren Daten, auf ihre Art und Weise und ohne Lock-in durchzuführen.

„Heute startet ein aufregendes neues Kapitel für Cloudera als führender Anbieter von Enterprise Data Clouds”, so Tom Reilly, Chief Executive Officer von Cloudera. „Das kombinierte Team und Technologieportfolio etabliert das neue Cloudera als klaren Marktführer mit der Größe und den Ressourcen für weitere Innovationen und Wachstum. Wir bieten unseren Kunden eine umfassende Lösung, um die richtige Datenanalyse für Daten überall dort bereitzustellen, wo das Unternehmen arbeiten muss, vom Edge bis zur KI, mit der branchenweit ersten Enterprise Data Cloud”.  

Ergänzend dazu stellte das Forschungsunternehmen Forrester fest1, dass „diese Fusion … die Messlatte für Innovationen im Big-Data-Bereich höher legen wird, insbesondere bei der Unterstützung einer durchgehenden Big-Data-Strategie in einer Hybrid- und Multi-Cloud-Umgebung. Wir glauben, dass dies eine Win-Win-Situation für Kunden, Partner und Lieferanten ist.”

Cloudera wird weiterhin unter dem Symbol „CLDR” an der New Yorker Börse gehandelt. Die Aktionäre von Hortonworks erhielten 1,305 Stammaktien von Cloudera für jede Aktie von Hortonworks.

Das Cloudera-Management wird am 10. Januar 2019 um 19:00 Uhr ein Online-Meeting veranstalten, um zu diskutieren, wie das neue Cloudera Innovationen beschleunigen und die erste Enterprise Data Cloud der Branche liefern wird. Registrieren Sie sich jetzt. Die Veranstaltung wird am 14. Januar 2019 um 14:00 Uhr auch für die EMEA-Region stattfinden. Registrieren Sie sich hier für dieses Webinar.

1 „Cloudera And Hortonworks Merger: A Win-Win For All”, Beitrag von Noel Yuhanna im Forrester-Blog (4. Oktober 2018)

Über Cloudera

Bei Cloudera glauben wir, dass Daten morgen Dinge ermöglichen werden, die heute noch unmöglich sind. Wir versetzen Menschen in die Lage, komplexe Daten in klare, umsetzbare Erkenntnisse zu transformieren. Cloudera stellt dafür eine Enterprise Data Cloud bereit – für alle Daten, jederzeit, vom Netzwerkrand (Edge) bis hin zu künstlicher Intelligenz. Mit der Innovationskraft der Open-Source-Community treibt Cloudera die digitale Transformation für die größten Unternehmen der Welt voran. Erfahren Sie mehr unter

Cloudera und damit verbundene Zeichen und Warenzeichen sind registrierte Warenzeichen der Cloudera Inc. Alle anderen Unternehmen und Produktnamen können Warenzeichen der jeweiligen Besitzer sein.

Distributed Computing – MapReduce Algorithmus

Sollen große Datenmengen analysiert werden, ist die Hardware eines leistungsfähigen Computers schnell überfordert und die Analysezeiten werden zu lang. Die Lösung zur Bewältigung von Big Data Analytics sind Konzepte des verteilten Rechnens (Distributed Computing).

Vertikale Skalierung – Der Klassiker der leistungsstarken Datenverarbeitung

Die meisten Unternehmen setzen heute noch auf leistungsstarke und aufrüstbare Einzelserver. Sollten Datenmengen größer und Analysen rechenaufwändiger werden, werden Festplatten (Storage), Arbeitsspeicher (RAM) und Prozessoren (CPU) aufgerüstet oder der Server direkt durch einen leistungsstärkeren ersetzt.

Diese Form der sogenannten vertikalen Skalierung (Vergrößerung der Server-Komponenten) ist für viele Unternehmen heute noch gängige Praxis, auch weil sie leicht zu administrieren ist und sie mit nahezu jeder Software funktioniert. Jedoch sind der Erweiterbarkeit gewisse Grenzen gesetzt und auch der Wechsel zu noch leistungsfähigerer Hardware würde den Einsatz von neuester High-End-Hardware bedeuten, der Kostenanstieg wäre exponentiell. Ferner bedarf es einer durchdachten Backup-Strategie mit gespiegelten Festplatten oder einem ganzen Backup-Server.

Leistungsstarke Server sind teuer und können zwar große Datenmengen weitaus schneller auswerten als Consumer-Computer, jedoch sind auch sie eher nicht dazu in der Lage, Big Data zu verarbeiten, also beispielsweise 100 Terabyte Daten binnen Sekunden statistisch auszuwerten.

Horizontale Skalierung – Skalierbare Speicher-/Rechenleistung

Ein alternatives Konzept zur vertikalen Skalierung ist die horizontale Skalierung. Dabei werden mehrere Computer, die im Vergleich oftmals über nur mittelmäßige Leistungsmerkmale verfügen, über ein Computer-Netzwerk verbunden und parallel angesteuert.

Der große Vorteil der horizontalen Skalierung ist der kostengünstige Einstieg, denn praktisch könnte bereits mit einem einzelnen Computer (Node) begonnen werden und dann nach und nach mit weiteren Nodes die Leistungsfähigkeit des Clusters (Verbund von Nodes) linear gesteigert werden. Ungefähr linear wachsen auch die Kosten an, so dass diese weitaus besser planbar sind. Cluster können weitaus höhere Leistungen erreichen als es einzelne Server könnten, daher gibt die horizontale Skalierung als diejenige, die sich für Big Data Analytics eignet, denn sie ermöglicht verteiltes Rechnen (Distributed Computing). Mit einem ausreichend großen Cluster lassen sich auch 100 Terabyte und mehr in wenigen Augenblicken statistisch auswerten.

Ferner ermöglichen horizontale Lösungen integrierte Backup-Strategien, indem jeder Node des Clusters über ein Backup der Daten eines anderen Nodes verfügt. Verfügt ein Node sogar über mehrere Backups, lässt sich eine sehr hohe Ausfallsicherheit – Datenverfügbarkeit im Cluster – erzielen.

Jedoch gibt es auch Nachteile der horizontalen Skalierung: Die Administration eines Clusters ist weitaus herausfordernder als ein einzelner Server, egal wie leistungsstark dieser sein mag. Auch Bedarf es viel räumlichen Platz für einen (oder gar mehrere) Cluster. Die Kompatibilität der Nodes sollte auch für die nächsten Jahr gesichert sein und nicht zuletzt ist es eine große Hürde, dass die einzusetzende Software (Datenbank- und Analyse-Software) für den Einsatz auf Clustern geeignet sein muss. Verbreite Software-Lösungen für verteiltes Speichern und Rechnen kommen beispielsweise von der Apache Foundation als Open Source Software: Hadoop, Spark und Flink.

Map Reduce Processing

Damit verteiltes Rechnung funktioniert, bedarf es der richtigen Software, die wiederum Algorithmen einsetzt, die sich dafür eignen. Der bekannteste und immer noch am weitesten verbreitete Algorithmus ist MapReduce. MapReduce ist ein sehr einfacher Algorithmus und dürfte von der grundsätzlichen Vorgehensweise jedem Software-Entwickler oder Analyst vertraut sein. Das Prinzip entspricht dem folgenden SQL-Statement, dass die am häufigsten vorkommende Sprache aus dem Datensatz (Tabelle Customers) abfragt:

Es gibt eine Tabelle (es könnte eine Tabelle in einer relationalen Datenbank sein oder eine CSV-Datei), die durch eine SELECT-Query abgefragt (map), groupiert (combine) und sortiert (sort). Dieser Schritt kann vereinfacht als Map-Funktion betrachtet werden, die in einer Liste Paaren aus Schlüssel (Keys) und Werten (Values) resultiert. Ist diese Liste vorhanden, kann diese auf die gewünschten Ergebnisse entspechend einer Logik (z. B. max(), min(), mean(), sum()) auf wenige oder nur einen einzigen Wert reduziert werden (Reduce-Funktion). Zu beachten ist dabei, dass der Map-Prozess sehr viel speicher- und rechen-aufwändiger als der Reduce-Prozess ist. Führen wir diese Abfrage auf einer Maschine aus, fassen wir die beiden Abfragen als ein Statement aus:

Betrachten wir jedoch die einzelnen Schritte, können wir sie wieder zumindest in einen Map- und einen Reduce-Schritt unterteilen. Diese Aufteilung machen wir uns für das verteilte Rechnen zunutze: Wenn jeder Computer (Node; oft auch Client Node oder Data Node) einen Teil der Daten besitzt, kann jeder Node für sich einen Map-Prozess durchführen, die Ergebnisse dann an einen Master-Node (oder in Hadoop-Sprache: Name Node) senden, der den Reduce-Prozess durchführt. Der Großteil der Aufgabe findet somit auf dem Cluster statt, nur der simple Reduce-Schritt auf einem einzelnen Computer.

Oftmals reicht ein parallel ablaufender Map-Prozess auf dem Cluster nicht aus, um Daten effizient auswerten zu können. Die Maßgabe sollte stets sein, den Reduce-Aufwand so gering wie möglich zu halten und soviel Arbeit wie möglich auf den Cluster zu verlagern. Daher sollte jeder Node im Cluster soweit aggregieren wie möglich: Dafür gibt es den Combine-Schritt.

Die zuvor erwähnte SQL-Abfrage als MapReduce würde bedeuten, dass ein Node über den Datensatz verfügt (und andere Nodes über weitere Datensätze) und jeder Node für sich seine Daten über einen Map-Prozess herausarbeitet, über einen Combine-Prozess aggregiert und die Aggregationsergebnisse an den Master-Node (Name Node) sendet. Hat der Master-Node alle Ergebnisse erhalten, berechnet dieser daraus das Endergebnis (Reduce).

Zusammenfassung: Map Reduce

MapReduce ist der bekannteste Algorithmus zur verteilten Verarbeitung von Daten und eignet sich für die Durchführung von komplexen Datenanalysen. Liegen Datensätze auf mehreren Computern (Client Nodes) vor, läuft der Algorithmus in der Regel in drei Schritten ab:

  1. Map – Selektierung der Datensätze auf den Computern im gewünschten Format und Durchführung einer Berechnung, beispielsweise der Bildung einer Summe. Dieser Schritt ist ermöglich das Prinzip Schema on Read, das aus Hadoop ein Tool zur Verarbeitung von unstrukturierten Daten macht.
  2. Combine – Durchführung einer Aggregation, die ebenfalls auf jeden Client Node durchgeführt wird, zur Zusammenfassung von Map-Ergebnissen.
  3. Reduce – Aggregation aller Ergebnisse auf dem zentralen Rechner (Name Node)

MapReduce ist dazu geeignet, unstrukturierte Daten zu verarbeiten, denn das Format der Daten wird über einen Map-Algorithmus bestimmt, der sehr flexibel programmiert werden kann. MapReduce ist kein eng definierter Algorithmus, sondern eine Hülle, die mit Inhalt befüllt werden muss. So müssen MapReduce-Algorithmen individuell über eine Programmiersprache wie Java, Scala oder Python programmiert werden.

Ein Beispiel eines in Java programmierten Word-Count-Algorithmus nach der MapReduce-Logik in Hadoop findet sich hier:

MapReduce und Advanced Analytics

MapReduce spielt seine Vorteile auf Computer-Clustern aus und eignet sich sehr zur Analyse von Daten nach dem Schema on Read. Für kompliziertere Analysealgorithmen ist MapReduce jedoch nur bedingt geeignet, denn bereits einfache Join-Anweisungen benötigen mehrere MapReduce-Ketten.

Während statistische Auswertungen und Join-Anweisungen mit MapReduce noch gut möglich sind, werden Algorithmen des maschinellen Lernens schwierig bis kaum möglich, da diese viele Iterationen, z. B. zur Anpassung von Gewichten, benötigen.

Was ist eigentlich Apache Spark?

Viele Technologieanbieter versprechen schlüsselfertige Lösungen für Big Data Analytics, dabei kann keine proprietäre Software-Lösung an den Umfang und die Mächtigkeit einiger Open Source Projekten heranreichen.

Seit etwa 2010 steht das Open Source Projekt Hadoop, ein Top-Level-Produkt der Apache Foundation, als einzige durch Hardware skalierbare Lösung zur Analyse von strukturierten und auch unstrukturierten Daten. Traditionell im Geschäftsbereich eingesetzte Datenbanken speichern Daten in einem festen Schema ab, das bereits vor dem Laden der Daten definiert sein muss. Dieses Schema-on-Write-Prinzip stellt zwar sicher, dass Datenformate bekannt und –konflikte vermieden werden. Es bedeutet jedoch auch, dass bereits vor dem Abspeichern bekannt sein muss, um welche Daten es sich handelt und ob diese relevant sind. Im Hadoop File System (HDFS) wird ein Schema für erst bei lesenden Zugriff erstellt.

Apache Spark ist, ähnlich wie Hadoop, dank Parallelisierung sehr leistungsfähig und umfangreich mit Bibliotheken (z. B. für Machine Learning) und Schnittstellen (z. B. HDFS) ausgestattet. Allerdings ist Apache Spark nicht für jede Big Data Analytics Aufgabe die beste Lösung, Als Einstiegslektüre empfiehlt sich das kostenlose Ebook Getting Started with Spark: From Inception to Production. Wer jedoch erstmal wissen möchte, erfährt nachfolgend die wichtigsten Infos, die es über Apache Spark zu wissen gilt.

Was ist Apache Spark?

Apache Spark ist eine Allzweck-Tool zur Datenverarbeitung, eine sogenannte Data Processing Engine. Data Engineers und Data Scientists setzen Spark ein, um äußerst schnelle Datenabfragen (Queries) auf große Datenmengen im Terabyte-Bereich ausführen zu können.

Spark wurde 2013 zum Incubator-Projekt der Apache Software Foundation, eine der weltweit wichtigsten Organisationen für Open Source. Bereits 2014 es wie Hadoop zum Top-Level-Produkt. Aktuell ist Spark eines der bedeutensten Produkte der Apache Software Foundation mit viel Unterstützung von Unternehmen wie etwa Databricks, IBM und Huawei.

Was ist das Besondere an Spark?

Mit Spark können Daten transformiert, zu fusioniert und auch sehr mathematische Analysen unterzogen werden.
Typische Anwendungsszenarien sind interactive Datenabfragen aus verteilten Datenbeständen und Verarbeitung von fließenden Daten (Streaming) von Sensoren oder aus dem Finanzbereich. Die besondere Stärke von Spark ist jedoch das maschinelle Lernen (Machine Learning) mit den Zusätzen MLib (Machine Learning Bibliothek) oder SparkR (R-Bibliotheken direkt unter Spark verwenden), denn im Gegensatz zum MapReduce-Algorithmus von Hadoop, der einen Batch-Prozess darstellt, kann Spark sehr gut iterative Schleifen verarbeiten, die für Machine Learning Algorithmen, z. B. der K-Nearest Neighbor Algorithmus, so wichtig sind.spark-stack

Spark war von Beginn an darauf ausgelegt, Daten dynamisch im RAM (Arbeitsspeicher) des Server-Clusters zu halten und dort zu verarbeiten. Diese sogenannte In-Memory-Technologie ermöglicht die besonders schnelle Auswertung von Daten. Auch andere Datenbanken, beispielsweise SAP Hana, arbeiten In-Memory, doch Apache Spark kombiniert diese Technik sehr gut mit der Parallelisierung von Arbeitsschritten über ein Cluster und setzt sich somit deutlich von anderen Datenbanken ab. Hadoop ermöglicht über MapReduce zwar ebenfalls eine Prallelisierung, allerdings werden bei jedem Arbeitsschrit Daten von einer Festplatte zu einer anderen Festplatte geschrieben. Im Big Data Umfeld kommen aus Kostengründen überwiegend noch mechanisch arbeitende Magnet-Festplatten zum Einsatz, aber selbst mit zunehmender Verbreitung von sehr viel schnelleren SSD-Festplatten, ist der Arbeitsspeicher hinsichtlich der Zeiten für Zugriff auf und Schreiben von Daten unschlagbar. So berichten Unternehmen, die Spark bereits intensiv einsetzen, von einem 100fachen Geschwindigkeitsvorteil gegenüber Hadoop MapReduce.

Spark kann nicht nur Daten im Terabyte, sondern auch im Petabyte-Bereich analysieren, ein entsprechend großes Cluster, bestehend aus tausenden physikalischer oder virtueller Server, vorausgesetzt. Ähnlich wie auch bei Hadoop, skaliert ein Spark-Cluster mit seiner Größe linear in seiner Leistungsfähigkeit. Spark ist neben Hadoop ein echtes Big Data Framework.
Spark bringt sehr viele Bibliotheken und APIs mit, ist ferner über die Programmiersprachen Java, Python, R und Scala ansprechbar – das sind ohne Zweifel die im Data Science verbreitetsten Sprachen. Diese Flexibilität und geringe Rüstzeit rechtfertigt den Einsatz von Spark in vielen Projekten. Es kann sehr herausfordernd sein, ein Data Science Team mit den gleichen Programmiersprachen-Skills aufzubauen. In Spark kann mit mehreren Programmiersprachen gearbeitet werden, so dass dieses Problem teilweise umgangen werden kann.spark-runs-everywhere

In der Szene wird Spark oftmals als Erweiterung für Apache Hadoop betrachtet, denn es greift nahtlos an HDFS an, das Hadoop Distributed File System. Dank der APIs von Spark, können jedoch auch Daten anderer Systeme abgegriffen werden, z. B. von HBase, Cassandra oder MongoDB.

Was sind gängige Anwendungsbeispiele für Spark?

  • ETL / Datenintegration: Spark und Hadoop eignen sich sehr gut, um Daten aus unterschiedlichen Systemen zu filtern, zu bereinigen und zusammenzuführen.
  • Interaktive Analyse: Spark eignet sich mit seinen Abfragesystemen fantastisch zur interaktiven Analyse von großen Datenmengen. Typische Fragestellungen kommen aus dem Business Analytics und lauten beispielsweise, welche Quartalszahlen für bestimmte Vertriebsregionen vorliegen, wie hoch die Produktionskapazitäten sind oder welche Lagerreichweite vorhanden ist. Hier muss der Data Scientist nur die richtigen Fragen stellen und Spark liefert die passenden Antworten.
  • Echtzeit-Analyse von Datenströmen: Anfangs vor allem zur Analyse von Server-Logs eingesetzt, werden mit Spark heute auch Massen von Maschinen- und Finanzdaten im Sekundentakt ausgewertet. Während Data Stream Processing für Hadoop noch kaum möglich war, ist dies für Spark ein gängiges Einsatzgebiet. Daten, die simultan von mehreren Systemen generiert werden, können mit Spark problemlos in hoher Geschwindigkeit zusammengeführt und analysiert werden.
    In der Finanzwelt setzen beispielsweise Kreditkarten-Unternehmen Spark ein, um Finanztransaktionen in (nahezu) Echtzeit zu analysieren und als potenziellen Kreditkartenmissbrauch zu erkennen.
  • Maschinelles Lernen: Maschinelles Lernen (ML – Machine Learning) funktioniert desto besser, je mehr Daten in die ML-Algorithmen einbezogen werden. ML-Algorithmen haben in der Regel jedoch eine intensive, vom Data Scientist betreute, Trainingsphase, die dem Cluster viele Iterationen an Arbeitsschritten auf die großen Datenmengen abverlangen. Die Fähigkeit, Iterationen auf Daten im Arbeitsspeicher, parallelisiert in einem Cluster, durchführen zu können, macht Spark zurzeit zu dem wichtigsten Machine Learning Framework überhaupt.
    Konkret laufen die meisten Empfehlungssysteme (beispielsweise von Amazon) auf Apache Spark.


Eine Hadoop Architektur mit Enterprise Sicherheitsniveau

Dies ist Teil 3 von 3 der Artikelserie zum Thema Eine Hadoop-Architektur mit Enterprise Sicherheitsniveau.

Die ideale Lösung

Man denkt, dass die Integration einer sehr alten Technologie, wie ActiveDirectory oder LDAP zusammen mit einem etablierten und ausgereiften Framework wie Hadoop reibungslos funktionieren würde. Leider sind solche Annahmen in der IT Welt zu gut um wahr zu sein. Zum Glück gibt es bereits erste Erfahrungsberichte  von  Unternehmen, die ihre Hadoop Infrastruktur an ein zentrales IMS gekoppelt haben.

Da die meisten Unternehmen  Active Directory als IMS benutzen, werden die im Folgenden  dargestellte Bilder und Architekturen dies ebenfalls tun.  Die vorgeschlagene Architektur ist jedoch derartig flexibel und technologieunabhängig, dass man das Active Directory auf den Bildern problemlos gegen LDAP austauschen könnte. Vielmehr ist die Integration eines Hadoop Clusters mit LDAP einfacher, da beide Technologien nativ zu Linux sind.

Schritt Eins – Integration von Hadoop mit Active Directory

Der erste Schritt, um Hadoop in dasActive Directory zu integrieren, ist ein sogenannter One-Way Trust von der Linux Welt hin zur Windows Welt . Dabei ist das Vertrauen des Authentisierungsmechanismuses von Hadoop zum Active Directory gemeint. Alle Identity Management Systeme bieten diese Funktionalität an, um sich gegenseitig vertrauen zu können und User aus anderen Domänen (Realms) zu akzeptieren. Das ermöglicht z.B. globalen Firmen mit vielen Standorten und unterschiedlichen IT Infrastrukturen und Identity Management Systemen diese zu verwalten und miteinander kommunizieren zu lassen.

Das Key Distribution Center (KDC) von Kerberos ist das Herz des Kerberos Systems im Hadoop. Hier  werden die User und ihre Passwörter oder Keytabs geschützt und verwaltet. Dabei brauchen wir lediglich den One Way Trust von KDC zu Active Directory. Allerdings gibt es eine vielversprechendere Technologie, die FreeIPA. Diese hat laut Wikipedia das Ziel, ein einfach zu verwaltendes Identity,-Policy-and-Audit-System (IPA) zur Verfügung zu stellen. Seit der Version 3.0.0 kann sich FreeIPA in das Active Directory integrieren. Die aussagekräftigen Vorteile von FreeIPA sind folgende:

  1. Reibungslose Integration mit Active Directory
  2. Es wird zusammen mit der Technologie SSSD geliefert, die das temporäre Speichern von Rechten und Passwörtern erlaubt. Das erlaubt auch offline den Zugriff auf  Fähigkeiten und Unabhängigkeit vom zentralen IPA, dem unterliegenden System.
  3. Integrierte Kerberos und Single Sign On (SSO) Funktionalitäten.

Wir lassen dann FreeIPA die Verwaltung von Kerberos und die primäre Authentisierung unseres Clusters übernehmen. Sowohl das Active Directory, als auch FreeIPA erlauben eine kinderleichte Umsetzung des One Way Trusts mithilfe von Web Tools. Im Prinzip muss man beim One Way Trust lediglich die öffentlichen Zertifikate jedes Tools mit denen der anderen bekannt machen.

Schritt Zwei – Synchronisation der Rechte & Rollen von Active Directory

Jetzt sind alle User, die sich im Active Directory befinden, unserem Hadoop Cluster bekannt. Ein User kann sich mithilfe des kinit Kommandos und nach Eingabe seines Usernames und Passwortes einloggen. Aber man braucht auch die im Active Directory definierten Rollen und Gruppen, um eine Autorisierung mithilfe von Ranger oder Sentry zu ermöglichen. Ohne die Provisionierung der Rollen haben wir bei der Autorisierung ein ähnliches Problem, wie es bei der Authentisierung aufgetreten ist.  Man müsste die Rollen selber verwalten, was nicht ideal ist.

Zum Glück gibt es verschiedene Ansätze um eine regelforme Synchronisierung der Gruppen von Active Directory in Ranger oder Sentry zu implementieren. Ranger kommt mit einem LDAP Plugin namens uxugsync, das sowohl mit LDAP als auch mit dem Active Directory kommunizieren kann. Leider hat die aktuelle Version dieses Plugins einige Nachteile:

  1. Leistungsprobleme, weil es defaultsmäßig versucht, den ganzen Hierarchiebaum von Active Directory zu synchronisieren. Das kann zu einem großen Problem für große Firmen werden, die mehrere tausend User haben. Außerdem müssen nicht alle User Zugriff auf Hadoop haben.
  2. Man kann bestimmte User syncen lassen, indem man ihren Gruppename im Gruppenfeld vom Plugin einträgt. Nachteil dabei ist, dass diese Abfrage nicht rekursiv funktioniert und alle Gruppe die im Ranger sein sollen einzeln abgefragt werden müssen, Das wiederum skaliert nicht sonderlich gut.
  3. Massive und regelmäßige Abfragen des Plugins können sogar zu einem DDoS Angriff auf den zentralen Active Directory führen.

Eine bessere Lösung wäre es, wenn wir die schönen Features des SSSD Deamons (der wie oben beschrieben zusammen mit FreeIPA kommt) ausnutzen könnten. Mithilfe von SSSD werden alle User und ihre entsprechenden Gruppen dem unterliegenden Linux Betriebssystem bekannt gemacht. Das bedeutet, dass man ein einfaches Script schreiben könnte, das die User und ihre Gruppen vom System direkt abfragt und zu Ranger oder Sentry über ihre entsprechende REST APIs überträgt. Dabei schont man sowohl das Active Directory vor regelmäßigen und aufwändigen Abfragen und schafft sogar ein schnelleres Mapping der Rollen zwischen Hadoop und Betriebssystem, auch wenn Active Directory nicht erreichbar ist. Es gibt derzeit Pläne, ein solches Plugin in den nächsten Versionen von Ranger mitzuliefern.

Schritt Drei – Anlegen und Verwaltung von technischen Usern

Unser System hat jedoch neben personalisierten Usern, die echten Personen in einem Unternehmen entsprechen, auch  technische User. Die technischen Users (Nicht Personalisierte Accounts – NPA), sind die Linux User mit denen die Hadoop Dienste gestartet werden. Dabei hat HDFS, Ambari usw. jeweils seinen eigenen User mit demselben Namen. Rein theoretisch könnten diese User auch im Active Directory einen Platz finden.

Meiner Meinung nach gehören diese User aber nicht dorthin. Erstens, weil sie keine echten User sind und zweitens, weil die Verwaltung solcher User nach Upgrades oder Neuinstallation des Clusters schwierig sein kann. Außerdem müssen solche User nicht den gleichen Sicherheitspolicies unterliegen, wie die normalen User. Am besten sollten sie kein Passwort besetzen, sondern lediglich ein Kerberos Keytab, das sich nach jedem Upgrade oder Neuinstallierung des Clusters neu generiert und in FreeIPA angelegt ist. Deswegen neige ich eher dazu, die NPAs in IPA anzulegen und zu verwalten.

High Level Architektur

Das folgende Bild fasst die Architektur zusammen. Hadoop Dienste, die üblicherweise in einer explorativen Umgebung benutzt werden, wie Hive und HBase, werden mit dargestellt. Es ist wichtig zu beachten, dass jegliche Technologie, die ein Ausführungsengine für YARN anbietet, wie Spark oder Storm, von dieser Architektur ebenfalls profitiert. Da solche Technologien nicht direkt mit den unterliegenden Daten interagieren, sondern diese immer über YARN und die entsprechenden Datanodes erhalten, benötigen sie auch keine besondere Darstellung oder Behandlung. Der Datenzugriff aus diesen 3rd Party Technologien respektiert die im Ranger definierten ACLs und Rollen des jeweiligen Users, der sie angestoßen hat.


Architektur in einer Mehrclusterumgebung

Wir haben schon das Argument untermauert, warum  unsere technischen User direkt im IPA liegen sollten. Das kann jedoch insofern Probleme verursachen, wenn man mit mehreren Clustern arbeitet, die alle die gleichen Namen für ihre technischen User haben. Man merkt sofort, dass es sich hier um eine Namenskollision handelt. Es gibt zwei Lösungsansätze hierfür:

  1. Man fügt den Namen Präfixen, die als kurze Beschreibungen der jeweiligen Umgebung dienen, wie z.B. ada, proj1, proj2 hinzu. Dadurch haben die User unterschiedliche Namen, wie proj1_hdfs für die proj1 Umgebung und ada_hdfs für die ada Umgebung. Man kann diese Lösung auch bei Kerberos KDCs benutzen, die in jeder Umgebung dediziert sind und die technischen User der jeweiligen Umgebung beibehalten.
  2. Man benutzt einen separaten Realm für jede Umgebung und damit auch eine separate IPA Instanz. Hier gibt es wiederum zwei verschiedene Ansätze. Ich muss jedoch zugeben, dass ich die Zweite nie ausprobiert habe und daher für ihre Durchführbarkeit nicht garantieren kann:
    1. Man bindet jede Umgebung einzeln über ihre FreeIPA per One Way Trust an das zentrale Active Directory. Das hat natürlich den Nachteil einer uneinheitlichen User Management Infrastruktur für alle Umgebungen, da Jede ihre eigene IPA Infrastruktur verwaltet und wartet.
    2. Man baut einen Hierarchiebaum von unterschiedlichen IPA Instanzen, so wie man es bei Forests von Active Directory Instanzen macht.

Das folgende Bild stellt den letzten Ansatz dar. Im Prinzip haben wir hier einen hierarchischen IPA Cluster mit mehreren One Way Trusts von den lokalen IPA Instanzen zu der zentralen IPA.



Wie Sie vielleicht von der gesamten Diskussion her abgeleitet haben, ist die Umsetzung einer unternehmerisch-konformen und personenbasierten Sicherheitsarchitektur innerhalb von Hadoop  keine einfache Sache. Man muss mit unterschiedlichen Architekturen und Ansätzen spielen, bevor man einen relativ vernünftigen oder sogar idealen Zustand erreicht hat. Die Berücksichtigung der jeweiligen IT Architektur spielt dabei eine sehr große Rolle. Ich hoffe, ich konnte die wichtigsten Merkmalen einer solchen Architektur und die Punkte, die ein Architekt besonders beachten muss, klar darstellen.

Als Zusammenfassung habe ich Ihnen am Ende eine Art Shoppingliste aller Komponenten zusammengestellt, die wichtig für den personalisierten Zugriff im Hadoop sind:

  1. Kerberos – Authentisierung
  2. FreeIPA – Authentisierung, Integration mit Active Directory
  3. Active Directory oder LDAP
  4. Ranger oder Sentry
    1. Plugin für Rollen/Gruppen Mapping zwischen AD und dem Betriebssystem
  5. Optional SSSD für schnellere Abfrage der Gruppen und Rollen des Betriebssystems

Zurück zu Teil 2 von 3 – Sicherheitstechnologie in Hadoop

Eine Hadoop Architektur mit Enterprise Sicherheitsniveau

Die Motivation für eine unternehmenskonforme Sicherheitsarchitektur für Hadoop

Hadoop und die damit einhergehenden Technologien und Applikationen (Hadoop Ecosystem) stellen keine neue Idee mehr dar. Zugegebenermaßen hat man jedoch das Gefühl, dass Hadoop noch lange nicht reif genug für dessen Integration an die IT Infrastruktur und an die Prozesse eines Unternehmens ist. Bei fast jeder Hadoop Distribution mangelt es an bestimmten nicht-funktionalen Aspekten. Die Hadoop Community hat sich sehr lange um die Erfüllung der funktionalen Anforderungen gekümmert und dabei Aspekte wie Sicherheit, Monitoring, Data Governance und Auditing vernachlässigt.

Eine berechtigte Frage wäre nun: Warum ist das so?

Zum besseren Verständnis der Leser werde ich zunächst auf diese Frage und die Geschichte von Hadoop eingehen, bevor ich mich mit dem Aufbau einer sicheren Hadoop Infrastruktur beschäftige.
Hadoop hat eine, für IT Verhältnisse, relativ lange Geschichte hinter sich. Das erste Release fand im Februar 2006 statt, wobei Yahoo bereits von Beginn an Interesse an der Mitwirkung und Benutzung bekundete. Am Anfang waren alle Applikationen, die für Hadoop geschrieben wurden, Backend Data-Crunching Jobs. Diese führten eine Art von Datenanalyse, basierend auf großen Datenmengen,  durch, die sonst, ohne die Verwendung der von Hadoops verteilter Architektur und Prozessframework, viel länger gedauert hätte. Dabei haben die Entwickler mithilfe der MapReduce Ausführungsengine Aggregierungen und  anderen SQL-ähnliche Abfragen von Datenbeständen geschrieben. Sämtliche Applikationen waren von ihrer Natur her Batchjobs, die regelmäßig auf dem Cluster angestoßen wurden, um Resultate zu berechnen und diese weiter an standardisierte Visualisierungstools zu leiten. Normale User brauchten daher keinen direkten Zugriff auf den Cluster selbst, sondern nur auf die Tools, die die Resultate der Hadoop Jobs sammelten. Das hat die Arbeit der ITler stark vereinfacht, da sie  den Hadoop Cluster, der viele sensible Daten über ihr Unternehmen beherbergt , komplett von der restlichen IT Infrastruktur abtrennen und durch Firewalls sichern konnten. Die Kommunikationskanäle zwischen Hadoop und anderen Tools waren dabei auf das absolut Notwendigste –   sprich Daten rein, Resultate raus –  begrenzt. Durch diese Limitierung fiel das zeitaufwendige Installieren und Verwalten von Usern und das Schreiben von Autorisierungspolicies weg.
Mit dem Zuwachs der Datenmenge in modernen Unternehmen und der wachsenden Popularität des Hadoop Ecosystems kamen weitere Use Cases und mehrere Tools hinzu. Hadoop2 hat in diesem Zuge eine komplett neue Architektur veröffentlicht, in der man nicht mehr vom MapReduce abhängig ist. Andere Ausführungsengines sind aufgetaucht, die auf bestimmte Use Cases abzielen und sich in diesen Fällen durch bessere Leistung als das MapReduce Framework auszeichnen. Mehr und mehr Business- und Daten-Analysten wurden daraufhin auf Hadoop aufmerksam und wollten die Technik für sich nutzen.. Insbesondere Banken und Finanzdienstleister erkannten das gewaltige Potenzial dieser Technologie und wollten sie nutzen, um ihre Kunden besser zu verstehen.
Das war der Moment, in dem Unternehmen weltweit den Druck empfanden, eine ernste Sicherheitsarchitektur für Hadoop zu entwickeln. Dabei stießen ihre Ingenieure jedoch auf erste Probleme:
Wie gewährleistet man nutzerbasierten Zugriff auf Tools, die sich normalerweise innerhalb eines Hadoop Clusters befinden? Und noch wichtiger: Wie beschützt man sensible Daten vor unbefugtem Zugriff? Welcher Nutzer darf auf welche Daten zugreifen?
All diese Fragen, die sich mit dem Thema „Personalisierter Zugriff“  befassten, brauchten umgehend eine Antwort.

Die Sicherheitsanforderungen einer Data Science Plattform

Den Bedarf an höheren Sicherheitsvorkehrungen haben insbesondere die Hadoop Plattformen, die ihren Usern interaktive und adhoc Jobs/Abfragen ermöglichen möchten. Solche Plattformen sind in der BigData Welt als interaktive oder explorative (abgeleitet vom englischen Wort Exploration) Umgebungen bekannt. Ihr Hauptziel ist es, eine BigData Umgebung anzubieten, die den Usern erlaubt, neue Techniken und maschinelles Lernen auf Datensätze anzuwenden, um versteckte Muster zu erkennen.

Hier sind einige der wichtigsten Ziele, die ein sicheres Hadoop Umfeld erfüllen muss:

  1. Jeder User muss in der Lage sein, selber Abfragen oder Machine Learning Algorithmen auf große Datenmengen anzustoßen.
  2. User müssen sogar in der Lage sein, selber Daten einzufügen und zwar in einer kontrollierten Art und Weise.
  3. Resultate müssen direkt auf dem Cluster abrufbar sein, damit die neuesten BigData Visualisierungstechnologien genutzt werden können
  4. Unbefugter Zugriff auf Datensätze einer dritten Abteilung durcheinzelne Personen oder Gruppen muss verhindert werden.
  5. Jeder Datenzugriff muss kontrolliert und auditiert werden können.

Dieser Artikel ist der Start der drei-teiligen Serie zum Thema Sicherheit auf Enterprise-Niveau für Hadoop. 

Weiter zu Teil 2 von 3 – Sicherheitstechnologie in Hadoop

Kontrolle und Steuerung von Spark Applikationen über REST

Apache Spark erfreut sich zunehmender Beliebtheit in der Data Science Szene da es in Geschwindigkeit und Funktionalität eine immense Verbesserung bzw. Erweiterung des reinen Hadoop MapReduce Programmiermodells ist. Jedoch bleibt Spark ebenso wie Hadoop eine Technologie für Experten. Es erfordert zumindest Kenntnisse von Unix-Skripten und muss über die Command-Line gesteuert werden. Die vorhandenen Weboberflächen bieten nur sehr rudimentäre Einblicke in den Status von Spark Applikationen:

spark basic ui

Der Spark JobServer ist ein Open-Source Projekt, das eine REST-Schnittstelle (Representational State Transfer) für Spark anbietet. (In diesem YouTube Video wird anschaulich erläutert, was ein REST API ist und wozu es verwendet werden kann.) Vereinfacht gesagt, ermöglicht es der JobServer, Spark über diese REST-Schnittstelle als Webservice zu nutzen. Es ist möglich, über den JobServer Spark Kontexte und Applikationen (Jobs) zu managen und Kontexte über verschiedene Aufrufe der REST-Schnittstelle hinweg wiederzuverwenden. Jar Files mit Job Implementierungen können vorab über die gleiche Schnittstelle installiert werden, so dass es z.B. möglich ist, auch sehr feingranulare Jobs über die Schnittstelle zu steuern (vollständige Liste der Features).

Der Spark JobServer ist bereits bei verschiedenen Organisationen (u.a. Netflix, Zed Worldwide, KNIME, Azavea und Maana) im Einsatz. Diese Nutzer des JobServers verwenden ihn meist versteckt „unter der Haube“, um so ihre jeweiligen Werkzeuge Big-Data tauglich zu machen. So nutzt KNIME ab dem nächsten Release (Oktober 2015) den JobServer. Anwendern können dann Spark Jobs über eine grafische Oberfläche bequem von ihrem lokalen Rechner aus starten, monitoren und stoppen. In der folgenden Abbildung sehen Sie, wie Trainingsdaten auf den Server hochgeladen werden, um daraus verschiedene Machine Learning Modelle zu erstellen. Diese Modelle können dann auf Testdaten angewandt werden, die z.B. aus einer HIVE-Tabelle nach Spark importiert werden:

spark knime hive jobs

Jeder der dargestellten Knoten mit der Überschrift „Spark ***“, wie z.B. „Spark Decision Tree“, ist ein Spark Job im Sinne des JobServers. Weitere Beispiele für Spark Jobs sind verschiedene Vorverarbeitungsaufgaben wie das Sampling einer Tabelle oder ein Join über mehrere Tabellen.

Spark kann über den JobServer im Standalone-, Mesos- oder im Yarn-Client-Modus angesteuert werden. Eine sehr hilfreiche Erweiterung der eigentlichen Spark-Funktionalität bietet der JobServer über die sogenannten „Named RDDs“ an. Ein Resilient Distributed Dataset (RDD) ist im Prinzip ein Datensatz bzw. eine Tabelle in Spark. „Named RDDs“ erlauben die Weiterverwendung von RDDs über einzelne Jobs hinweg. So kann man Jobs modularer aufbauen und leichter Zwischenergebnisse inspizieren.

Ich kann aus eigener Erfahrung sagen, dass der JobServer die geeignete Middleware zwischen einer benutzerfreundlichen Oberfläche und Spark ist. Die Open-Source Community ist hier sehr aktiv und der JobServer lässt sich bei Bedarf gut erweitern.

Hadoop und Connected Cars

Wie Automotive Unternehmen mehr aus großen Datenmengen machen

Wussten Sie schon: Für 13% der Autokäufer ist ein Neu-Fahrzeug ohne Internetzugang ein “no-go”! Dreizehn Prozent! Das bedeutet gleichzeitig 13% weniger Umsatz für den OEM. Die Unternehmensberatung Bain erwartet, dass diese sogenannten Connected Cars in nur wenigen Jahren die Regel und nicht mehr die Ausnahme sein werden.  

Dabei sind Connected Cars nur der Anfang: OEMs stehen jetzt vor der Herausforderung, ihr Portfolio noch einmal deutlich zu erweitern. Ziel ist es, eine breite Palette maßgeschneiderter Produkte anzubieten, um die immer unterschiedlicheren Erwartungen an Kundennutzen, Fahrerlebnis, Lebenszyklus und Garantie zu erfüllen.

Um all diese Angebote zu identifizieren, zu entwickeln und auch betriebswirtschaftlich tragbar zu machen, müssen Daten analysiert werden – viele Daten!  Read more