Was verbirgt sich hinter den Wörtern Bigdata, HDFS und Hive ? Wofür braucht man dies ? Und warum gibt es kein Hosting bei Portunity und anderswo dafür ? Auf diese Fragen möchte ich in meinem heutigen Blog-Beitrag eingehen.
Dazu werde ich zunächst die Techniken und Begriffe ein wenig erläutern und den "Erklär-Bär" zum "Elefanten-Projekt Hadoop" geben.
Anschließend möchte ich darauf eingehen, warum es allgemein auf dem Markt und im besonderen auch bei Portunity dazu keine Standard-Angebote gibt.
Hintergrund des Blog-Artikels ist folgende Anfrage, welche uns vor kurzem erreichte:
Nabend, ich bin durch meinen Arbeitgeber mittlerweile sehr tief im BigData Umfeld unterwegs. Mir ist aufgefallen das es für alles mögliche Service Dienstleister gibt, aber für den Betrieb von z.B. einem HDFS und Hive als Warehouse findet man kaum bis gar keine Dienstleister. PTY macht ja doch sehr viel, daher einfach nur mal aus Interesse, habt ihr jemals an diesen Bereich gedacht? Ich versuche aktuell einfach nur zu verstehen wieso es dort so wenig Dienstleister gibt.
Bevor ich auf die eigentliche Frage "warum Portunity da nichts anbietet" eingehe, möchte ich zunächst erklären was HDFS, Hive und BigData ist:
Mit "große Datenmengen" ist es eigentlich auch schon fast erklärt - aber schauen wir genauer in die Details: Gemeint sind insbesondere derart große Datenmengen, dass man sie mit einer normalen Datenbank wie mySQL oder einem normalen Dateisystem (z.B. ext3 unter Linux) nicht mehr verarbeitet bekommt.
Die meisten können sich vielleicht einen Server vorstellen, wie viele Daten auf mehrere Festplatten verteilt da drauf passen und was man damit alles verarbeitet bekommt - was unter normalen Umständen bei der heutigen Leistungsfähigkeit auch schon einiges ist.
Bild links: Festplatten-Storage.
Reicht dies allerdings nicht mehr aus, kann man mit den gängigen Datenbank-Systemen wie zum Beispiel mySQL, MS-SQL & Co ja noch gut skalieren indem man mehrere mySQL-Server betreibt. Hierbei wird im einfachsten Fall ein SQL-Server als Master betrieben - welcher die Daten dann auf mehrere Server repliziert. Schreib-Operationen werden immer an den Master gesendet, welcher es an die Slave-Server verteilt, von denen dann verteilt gelesen werden kann. Hintergrund ist der, dass es meist mehr Lese- als Schreib-Operationen gibt. Darüber hinaus gibt es im Standard-SQL-Umfeld dann noch Cluster-Lösungen - wo es aber auch schnell sehr speziell und kompliziert wird.
Auch im Dateisystem-Umfeld kommt man mit Bordmitteln schon recht weit. So kann man heute mit Storages ohne große Probleme redundante und große Dateisysteme aufbauen welche auf Dutzenden von Festplatten im Terabyte-Bereich (TByte) laufen.
Im Big-Data-Umfeld geht es um vielfach größere Datenmengen im Peta-, Exa- und Zettabyte-Bereich. Hier kommen Standard-SQL-Dienste und Standard-Dateisysteme eigentlich in sämtlichen Bereichen der Verarbeitung an die Grenzen: Erfassung, Speicherung, Suche, Verteilung, Bereitstellung, Analyse, Visualisierung, Datensicherung und vieles mehr wird unmöglich. Und genau dabei geht es im Big-Data Umfeld:
Um dies zu erreichen, werden hunderte oder tausende von Standard-Servern eingesetzt und zusammengeschaltet. D.h. die Daten liegen verteilt auf verschiedenen Servern. Anfragen werden dann von hunderten oder tausenden Servern gleichzeitig bearbeitet - wodurch sich selbst bei komplexen Abfragen enorm hohe Geschwindigkeiten ergeben.
Ein gutes Beispiel für Big Data ist die Suchmaschine Google: Google speichert Milliarden von Webseiten, Stichwörtern und Informationen. Dies geschieht auf zehntausenden von Servern. Gibt ein User nun einen Suchbegriff ein, wird die Anfrage genommen, an ca. 5000 Server verteilt - welche ihre Datenbestände durchsuchen, Teilergebnisse zurückliefern die dann wiederum gebündelt und aufbereitet an den Nutzer am Ende zurückgegeben werden. Bei der nächsten Suchanfrage also bitte ein bisschen mehr Erfurcht davor, wenn sich mal wieder tausende von Servern für Sie in Bewegung setzen ;)
Das große Firmen wie Google sich um solche Datenmengen Gedanken machen (müssen) und entsprechende Lösungen sich gebaut haben ist sicher verständlich. Aber auch immer mehr andere Firmen hantieren heute mit derart großen Datenmengen. Kleine Startup-Firmen wie z.B. Pinterest, Instagram usw. können heute binnen Monaten riesige Nutzerzahlen erreichen - mit entsprechend schnell wachsenden Datenmengen.
Von daher haben sich auch in der Software-Szene dafür Lösungen entwickelt:
Hadoop: Hadoop zum Beispiel ist ein Software-Framework für skalierbare, verteilt arbeitende Software und basiert auf dem MapReduce-Algorithmus von Google und lehnt sich auch auf Ideen aus dem Umfeld des Google-Dateisystems (Google File System, GFS). Hadoop ist in Java entwickelt und stellt wie gesagt lediglich ein Software-Framework da - also eine Art Bibliothek. Hadoop selber ist also keine fertig einsetzbare Lösung, sondern ermöglicht es vielmehr erst Lösungen zu entwickeln.
Hadoop Distributed File System (HDFS): Ist ein Dateisystem auf Basis des Hadoop-Frameworks welches sehr große Dateien und Dateimengen in großen Cluster-Verbunden speichern und organisieren kann - es ist von der Idee am Dateisystem von Google (GFS) angelehnt / inspiriert. Mehrere hundert Millionen Dateien auf einem Cluster aus 10.000 Servern sind kein Problem und ein eher übliches Einsatzgebiet.
Hadopp Hive: Ist ein Datenbanksystem welches ebenfalls auf Hadoop basiert. Es stellt eine Abfragesprache (Query-Language = QL) zur Verfügung, welche von der Syntax an SQL angelehnt ist. Ursprünglich wurde Hive von Facebook entwickelt welche es 2008 der Open-Source-Gemeinde offen zur Verfügung stellten.
Da Hadoop ein Framework ist, gibt es natürlich weitere Hadoop-basierte Software. HBase ist zum Beispiel ein weiteres Datenbanksystem mit etwas anderen Schwerpunkt als Hive usw. Sämtliche Hadoop-basierte Software hier vorzustellen würde den Umfang des Artikels jedoch sprengen - letztendlich wollte ich erstmal den Hintergrund der Eingangsfrage ein wenig beleuchten, zu der ich nun kommen möchte:
Zunächst einmal, weil wir uns damit bislang zu wenig beschäftigt haben und von daher diese Techniken auch noch nicht selber einsetzen. Wir bieten ausschließlich immer Produkte an, hinter denen wir voll stehen. Die wir auf der einen Seite auch wirklich gut verstehen - auf der anderen Seite aber auch selber nutzen.
Beim Server-Hosting bieten wir z.B. gerne Linux-Systeme an (Root-Server, vServer usw.), denn wir selber nutzen Linux täglich, verstehen da (glaube ich *g*) einiges von, können dort also auch entsprechenden Support und Hilfestellungen anbieten und lieben Linux einfach immens. Ganz anders sieht dies bei Windows-basierten Servern aus. Wir selber nutzen Windows allenfalls im Desktop-Bereich - aber von Windows-Servern haben wir echt keine große Ahnung. Wir wissen nicht, wie man einen Windows-Webserver administriert (IIS oder wie auch immer das heute heißen mag). Wir haben uns auf Linux als Betriebssystem spezialisiert - da sind wir zu Hause und da sind wir gut drin. Von daher bieten wir auch keine Windows-Server an.
Aber natürlich können Kunden einen Miet-Server von uns auch bekommen, sich Windows irgendwo kaufen und das ganze bei uns im Rechenzentrum betreiben (die Basis-Installation bis es "Pingt" bekommen wir sicher auch noch hin) - oder per Server-Housing einen Windows-Server bei uns in Wuppertal, Düsseldorf oder Frankfurt unterstellen. Wir haben so auch durchaus einige Windows-Server bei uns im Rechenzentrum stehen. Aber wir bitten dann schlicht darum, bitte keinen Support über das Hosting / Housing hinaus zu erwarten.
Bei uns ergab sich bislang einfach noch nicht die Notwendigkeit derartig große Datenmengen zu verarbeiten. Unsere Kundendaten, deren Produkt-Konfigurationen, die Abrechnungen und alles was da noch da zum Beispiel dran hängt, bekommen wir derzeit noch sehr gut mit klassischen Systemen gestemmt.
Gleiches gilt für Daten welche bei einzelnen Projekten anfallen. Selbst bei unserer Online-Festplatte SpeedDrive kommen wir - noch - mit üblichen Storage-Lösungen zurecht. Wobei dieses Produkt sicher eines der ersten Kandidaten wäre, was mir bei uns zu "BigData" noch am ehesten einfällt.
Von daher hat sich da bislang schlicht noch nie jemand tiefer eingearbeitet oder da mal mit ansatzweise auch nur ein bisschen mit experimentiert. Auch wenn ich die Themen schon länger verfolge und mir immer mal wieder denke "wenn wir mal Zeit hätten, müssten wir mal...".
Der andere Punkt ist: Wie groß wäre der Markt für so was wie Hive-Hosting überhaupt ? Wie viele Firmen gibt es, die solche speziellen Lösungen mit 500 oder 5000 Servern wirklich benötigen ? Und sind die Einsatzgebiete dann nicht immer auch sehr speziell ? Ich könnte mir vorstellen, dass Firmen die sowas benötigen, dann auch sehr spezielle Anforderungen haben.
Lässt sich so was "Out of the Box" wie bei einem Hosting bereitstellen ? Oder sind die Anforderungen derart speziell, dass es eigentlich eher ein Projektgeschäft wäre ? Ich will nicht absprechen, dass es sicherlich einen Markt gibt. Aber wenn, dann eher einen Markt auf Projektbasis denn als einen Massenmarkt, oder ?
In dieser meiner These bestärkt werde ich, wenn ich mir das monatliche Suchvolumen von Google dazu anschaue: Global sind es immerhin noch 91 Anfragen die nach "Hive Hosting" suchen - in Deutschland keine. Nach "hdfs hosting" sucht selber global keiner. Selbst die Anfragen nach "Bigdata" (90), "Hive" (210) oder "HDFS" (immerhin 1300) zeigen doch eher, dass es noch Nischenthemen in Deutschland sind.
Ich denke HDFS-Hosting, Hive-Hosting usw. sind in sich gesehen einfach zu speziell - wenn dann muss man diese Dienste nehmen um darauf aufbauend wiederum abstrahierte Zusatz-Dienste zu bauen, welche dann unter dem Mode-Mischmasch-Worte "Cloud" vermarktet werden können. Ob da im Hintergrund dann nun HDFS oder was anderes läuft, interessiert dann auf der anderen Seite auch schon eher wieder weniger. Und auf den Cloud-Zug sind wir bislang noch nicht so richtig aufgesprungen - das wäre aber mal ein anderer Blog-Artikel ;)
Also kurz zusammengefasst: Ich glaube der Markt für BigData ist ganz sicher existent, aber von der möglichen Anzahl an Kunden eher klein (ganz sicher wird es kein Massenmarkt sein) - dafür sehr speziell und dann auch entsprechend hochpreisig. Ganz klar: Ein paar hundert Server zu betreiben würde dann auch schon was kosten.
Wenn man Big-Data als fertige gehostete Lösung wie auch immer anbieten möchte, müsste man sich auch entsprechend gut damit auskennen - was bei uns derzeit ganz ehrlich nicht gegeben ist. Und ob der Weg der Vermarktung über das Internet (wie wir es mit unseren anderen Produkten fahren) dann der richtige wäre - fraglich, oder ?
Von daher halten wir es derzeit wie mit Windows im Hosting: Wenn jemand das eine oder andere Rack mit entsprechenden Servern betreiben will, können wir ihm gerne den Rackspace, Strom, die Anbindung usw. dafür im Rahmen unserer Möglichkeiten per Colocation und nach Absprache bereit stellen. Ganze Hallen und Platz für 5000 Server sind platzmässig derzeit allerdings nicht drin. Und groß auf Seiten der Software helfen, solch einen Support können wir derzeit offen gesagt ebenfalls nicht leisten.
Vom Grundsatz halte ich die Bigdata-Technologien allerdings für hoch interessant. Ich beobachte alles was da passiert bereits seit mehreren Jahren sehr sehr interessiert - und werde dies auch weiter so halten. Und zum Beispiel bei unserer Online-Festplatte SpeedDrive könnte ich mir bei weiter steigenden Kundenzahlen einen Wechsel vom derzeitigem Storage zu HDFS in näherer Zukunft auch vom Grundsatz gut vorstellen - entsprechende Forschung und positive Test-Erfahrung bei uns intern mal vorausgesetzt.
Vielleicht hält BigData also doch früher oder später bei uns Einzug - ausgeschlossen ist dies nicht. Und vielleicht klappt es dann auch mal noch mit einem Stadard-Angebot, möglich ist alles und in Stein gemeißelt auch am Ende des Tages nichts ;)
Marken-Disclaimer: Apache Hive, Apache Hadoop, Apache HBase, Apache HDFS, Apache sowie die Projekt-Logos sind Marken der Apache Software Foundation.
Bild-Nachweis: Titelbild und Storage-Bild: Lizensiert bei Fotolia , das Titelbild ist darüber hinaus eine Collage.
27.01.2023
Kommentare
Seien Sie der/die Erste und schreiben Sie uns Ihren Kommentar zu diesem Artikel.