Yvette Teiken

Personal site of Dr. Yvette Teiken

CTO at erminas

Contact Me

Back to Home

Hadoop und Microsoft – wie passt das zusammen? Ein Architektur-Überblick

Big Data ist in aller Munde. Auch Microsoft ist mit HDInsight auf den Zug aufgesprungen. Aber wie passt das zusammen, Open Source Hadoop und Microsoft? Wo sind die Anknüpfungspunkte zu klassischem BI? Dies ist der Auftakt zu einer Blogserie zu genau diesem Thema. Ziel der Serie ist es, einen Einblick in HDInsight zu geben und diesen in Beziehung zu traditionellen BI-Ansätzen zu bringen. In diesem ersten Artikel geht es um die Architektur von HDInsight, die Hadoop und Microsoft vereint.

Architekturüberblick über die HDInsight Komponenten

Architekturüberblick über die HDInsight Komponenten

Als Einstieg eignet sich immer gut ein Architekturbild, welches auch in vielen Veröffentlichungen zu finden ist. Die Abbildung stammt direkt von Microsoft. Die grauen Komponenten sind die, die ich mir beim Schreiben dieses Artikels noch nicht detaillierter angesehen habe und daher zum jetzigen Zeitpunkt noch nicht mehr dazu sagen möchte. Im Folgenden werden nun die einzelnen Komponenten vorgestellt und ein wenig eingeordnet.

Azure als Grundlage: HDInsight basiert auf Windows Azure, entweder in der Cloud oder onPremise. Ein HDinsight Cluster in der Cloud ist relativ teuer, um nur mit ein paar Daten zu spielen, auch weil er per Default aus 12 Knoten besteht. Daher gibt es für lokale Tests den HDInsight Emulator. Dieser sollte nicht produktiv eingesetzt werden, er dient eher dazu Ansätze zu testen und das Ecosystem kennenzulernen.

Basierend auf dem Microsoft Azure-Ökosystem beginnt der eigentliche traditionelle Big Data Ansatz. HDInsight ist eigentlich nichts anderes als Apache Hadoop auf Microsoft, es verwendet die Distribution von Hortonworks. Das heißt, wir bewegen uns in der klassischen Big Data Welt von Hadoop & Co basierend auf der bekannten MS Infrastruktur.

Grundlage für Hadoop alles ist HDFS. Hierbei handelt es sich um ein Dateisystem, welches auf verteiltes Verarbeiten großer Datenmengen ausgelegt ist. Gleichzeitig braucht es keine Highend-Hardware, sondern lässt sich effizient mit günstiger Hardware betreiben. Der Fokus bei der Verarbeitung liegt vielmehr im Bereich von TB statt GB. Hat man also nur wenige Daten, sollte man lieber auf traditionelle Ansätze zurückgehen, sonst ist der Overload der Technologie zu groß. Da das Dateisystem auf Verteilung ausgelegt ist, ist auch die vertikale Skalierung relativ einfach und beeindruckend, was ich selbst schon in meinen kleinen Demo Szenarien spüren konnte.

Die Verarbeitung der Daten in HDFS wird mit Map Reduce vorgenommen. Bei Map Reduce handelt es sich um einen Ansatz zum Rechnen auf verteilten Architekturen. Dabei werden zwei Phasen durchlaufen: Map und Reduce. Im Map Teil werden einzelne, unabhängige Berechnungen durchgeführt, die dann in einem Reduce Schritt zusammengeführt werden.

Hive bezeichnet sich selber als Data Warehouse Layer von HDFS, was meines Erachtens in der gegenwärtigen Phase nicht ganz zutrifft. Es ermöglicht das Definieren und Abfragen von Tabellen in einer SQL ähnlichen Sprache. HiveQl erfüllt zwar nicht den SQL-92 Standard, aber der normale SQL Entwickler wird sich hier schnell zu Hause fühlen. Nicht vorhanden sind zum Beispiel Indexes. Diese werden aber aufgrund der Architektur auch nicht benötigt. Technisch werden die erstellten Anfragen in Map Reduce-Jobs umgewandelt und ausgeführt. Als SQL Entwickler fühlt man sich in dieser Sprache schnell zu Hause.

Das schöne für ein Microsoft-Kind, wie ich es bin, ist, dass dank dem Microsoft SDK vieles in der Open Source Welt direkt mit dem Visual Studio bearbeitet werden kann. So lassen sich Map Reduce Jobs in C# schreiben, die dann in der Java-basierten Umgebung ausgeführt werden. Ähnlich wie bei anderen Azure Diensten lassen sich Jobs vom lokalen Visual Studio direkt auf Azure deployen und ausführen. Neben Map Reduce-Jobs lassen sich auch Hive und Pig Jobs direkt aus dem Visual Studio starten.

Um große Datenmengen verwalten zu können, verfügt Microsoft seit kurzem über die analytische Datenbank PDW. Eine Kombination von PDW mit Big Data scheint sinnvoll, weil sie ja für ähnliche Zwecke konstruiert worden ist.

SQOOP ist als Brücke zwischen HDFS und RDBMS ein schönes kleines Tool, welches die Welten angenehm miteinander integriert

Ergebnisse aus Big Data Analysen lassen sich auch mit den traditionellen BI Tools von Microsoft aufbereiten und verarbeiten. Hier ist es denkbar, Excel als Präsenstations- und Analyse-Werkzeug zu verwenden, da es auch mit entsprechenden Plugins, direkt mit Hive bzw. HDFS interagieren kann. Weiterhin ist auch ein Zusammenspiel zwischen Analysis Services und HDInsight denkbar. So können Ergebnisse aus Big Data in klassischen OLAP Reportings wieder verwendet werden.

Ebenso vielversprechend ist ein Zusammenspiel zwischen eventbasierter Verarbeitung und Big Data. Dabei stellt sich mir die Frage, ob Dienste wie Stream Inside die Quelle oder das Ziel von Big Data sind.

Mit dem Einstieg in HDInsight öffnet sich eine neue Welt, die auf den ersten Blick ein wenig verwirrend ist. In diesem Artikel habe ich versucht, die unterschiedlichen Komponenten der Architektur und deren Verwendung vorzustellen. Auch erkennt man schon in diesem Überblick die Verknüpfungen zu anderen Welten und Technologien. Es ist noch nicht alles integriert und es gibt teilweise offensichtliche Brüche. Aber die Technologie ist vielversprechend und deswegen lohnt sich eine gemeinsame Beschäftigung mit dem Thema.

In diesem Blog werde ich Beispiele vorstellen, wie sich die Welten verbinden lassen. Unter Anderem sind Artikel geplant zu:

  • Erstellung, Anfragen und Export von Hive-Tabellen
  • Umsetzung von ETL-Prozessen mit Hilfe von PIG
  • Entwicklung nativer Map Reduce-Jobs mit C#
  • Interaktion mit traditionellen RDBMS und Streaming-Technologien