HDFS, dauerhafte Datenablage von vielen Datenmengen

[chris085]

Hallo zusammen,

ich mache mir gerade im Rahmen meiner Abschlussarbeit an der Uni Gedanken zu Konzepten in der Scale-Out (Big-Data) Welt.
Folgender Use-Case:

Es ist ein Mittelgroßer Cluster (Mapr bzw. Cloudera) vorhanden der Logdateien nach gewissen Mustern durchsucht und zusammenhänge erkennt. Pro Job werden Datenmengen von ca. 10 TB verarbeitet, diese wiederum liefern einen Output der im kb Bereich liegt und vom User weiter verarbeitet wird. Am Tag laufen rund 10 Jobs!

Nach dem verarbeiteten Job sind die genannten 10 TB Daten eigentlich soweit nutzlos. Allerdings müssen sie aufgrund diverse Regeln für die nächsten x Jahre aufgehoben werden, falls Fehler im Produkt auftreten.

Da HDFS bzw. MaprFS die Datenmenge aufgrund von Ausfallsicherheit mindestens 3-fach repliziert, ist dies ein - wie ich finde - teures Datengrab.

Mit welchen Konzepten bzw. Ansätzen könnte man die Daten für lange Zeit archivieren und wie könnte man in geringer Zeit (weniger als einen Tag) wieder die Daten entsprechend in die Hadoop Umgebung kopieren?
Kosten sind natürlich auch ein wichtiger Faktor.

 

[Firewire2002]

10TB Log-Rohdaten oder komprimiert? Falls Roh-Daten, welche Ratio darf man bei der Komprimierung erwarten?
Gerade Log-Daten sind ja prädestiniert dafür komprimiert zu werden.

PS:
3 Jobs am Tag, 10TB pro Job, lass mich kurz rechnen ... 30TB(?!) Log-Daten pro TAG? Was sind das denn für Logs?
Schalt mal den Debug Modus ab.

 

[chris085]

10TB Log-Rohdaten oder komprimiert? Falls Roh-Daten, welche Ratio darf man bei der Komprimierung erwarten?
Gerade Log-Daten sind ja prädestiniert dafür komprimiert zu werden.

Die Daten liegen Roh vor, wurden teilweise aus Binär zu lesbar konvertiert, daher auch die enorme Menge. Komprimierung im Anschluss ist aktuell noch nicht geklärt, daher muss ich unkomprimiert annehmen

PS:
3 Jobs am Tag, 10TB pro Job, lass mich kurz rechnen ... 30TB(?!) Log-Daten pro TAG? Was sind das denn für Logs?
Schalt mal den Debug Modus ab.

Die Anforderungen haben mich auch erst einmal vom Stuhl gehauen. Der Output kommt von vielen (sehr vielen) Maschinen Steuergeräten. Teilweise werden dort Signale im ns Bereich mitgeschrieben

 

[Firewire2002]

Ich bin es zwar berufsbedingt auch gewohnt in anderen Größenordnungen zu denken, als die meisten User hier, aber 30TB Neu-Daten pro Tag ist auch für mich ein bisschen eine Nummer zu groß.
Kann daher nur mit theoretischen Ansätzen und Erfahrungen aus dem etwas kleineren Storage-Bereich dienen.

Aus bisheriger Erfahrung stehe ich Cluster Dateisystemen immer etwas kritisch gegenüber. Ob GlusterFS oder Ceph in dieser Größenordnung stabil zu betreiben sind, weiß ich nicht. Hätte aber so meine Zweifel.
Bei 30TB pro Tag, reden wir von rund 11PB pro Jahr. Du schreibst der Kram soll archiviert werden, da setze ich mal _nur_ 3 Jahre an. Sind schon 33PB Gesamtdaten ohne irgendeine Redundanz die man irgendwo vorhalten müsste.
Ich habe IFS von EMC Isilon als sehr robustes ClusterFS kennen und lieben gelernt. Allerdings ist Isilon auf eine Clustergröße von 144 Nodes beschränkt und kann in maximalem Kapazitätsausbau auch nur rund 21PB verwalten.
Da würde also selbst ein propritäres Dateisystem vorher aufgeben. Mal davon abgesehen, dass das auch alles andere als preiswert würde. Da bist du mit selbstgebauten HDFS inkl. Redundanz vermutlich preiswerter dran.

Eine Alternative die ich sehen würde, wäre das splitten der Dateien und eigenständige Verteilen auf mehrere Nodes. Die Datei ist schnell zerlegt und die einzelnen Teile kann man mit etwas kleinem Scriptaufwand problemlos auf mehrere Server verteilen. Irgendwo in einer Datenbank den Index über die Teile vorhalten, fertig.
Je nachdem wie man splittet, könnte man bei Bedarf sogar nur Teile davon wiederherstellen und müsste nicht 10TB rauskramen, wenn man vielleicht nur 1GB braucht.

 

[chris085]

Ich bin es zwar berufsbedingt auch gewohnt in anderen Größenordnungen zu denken, als die meisten User hier, aber 30TB Neu-Daten pro Tag ist auch für mich ein bisschen eine Nummer zu groß.
Kann daher nur mit theoretischen Ansätzen und Erfahrungen aus dem etwas kleineren Storage-Bereich dienen.

Aus bisheriger Erfahrung stehe ich Cluster Dateisystemen immer etwas kritisch gegenüber. Ob GlusterFS oder Ceph in dieser Größenordnung stabil zu betreiben sind, weiß ich nicht. Hätte aber so meine Zweifel.
Bei 30TB pro Tag, reden wir von rund 11PB pro Jahr. Du schreibst der Kram soll archiviert werden, da setze ich mal _nur_ 3 Jahre an. Sind schon 33PB Gesamtdaten ohne irgendeine Redundanz die man irgendwo vorhalten müsste.
Ich habe IFS von EMC Isilon als sehr robustes ClusterFS kennen und lieben gelernt. Allerdings ist Isilon auf eine Clustergröße von 144 Nodes beschränkt und kann in maximalem Kapazitätsausbau auch nur rund 21PB verwalten.
Da würde also selbst ein propritäres Dateisystem vorher aufgeben.

Ja gut, ich hätte ohnehin nicht vor alles in ein System zu packen. Man nehme an der Cluster fliegt mir um die Ohren (aus welchen Gründen auch immer) dann sind die letzten x Jahre verloren. Es lässt sich sicher im 6-12 Monatsrhythmus einen neuen Cluster aufbauen.

Welche Erfahrungen hast du mit dem IO. Lassen sich beim kopieren volle Datenraten von 10 Gbit bzw. 40 Gbit mit dem IFS von EMC Isilon erreichen?
Wie viel Overhead existiert bei euch, aufgrund der Replizierung?

Mal davon abgesehen, dass das auch alles andere als preiswert würde. Da bist du mit selbstgebauten HDFS inkl. Redundanz vermutlich preiswerter dran.

Eine Alternative die ich sehen würde, wäre das splitten der Dateien und eigenständige Verteilen auf mehrere Nodes. Die Datei ist schnell zerlegt und die einzelnen Teile kann man mit etwas kleinem Scriptaufwand problemlos auf mehrere Server verteilen. Irgendwo in einer Datenbank den Index über die Teile vorhalten, fertig.
Je nachdem wie man splittet, könnte man bei Bedarf sogar nur Teile davon wiederherstellen und müsste nicht 10TB rauskramen, wenn man vielleicht nur 1GB braucht.

So wie ich den Fachbereich verstanden habe, müssen die Logdaten "unbedingt" so bleiben wie sie sind. Konntest du schon Erfahrungen mit Rehhat Storage Server sammeln? Das soll anscheinend auch ein Glusterfs sein.

 

[Firewire2002]

Welche Erfahrungen hast du mit dem IO. Lassen sich beim kopieren volle Datenraten von 10 Gbit bzw. 40 Gbit mit dem IFS von EMC Isilon erreichen?

Das kommt drauf an wie viele Clients schreiben. Wenn nur ein NFS Client mit einem Mount schreibt, wirst du nicht wirklich über die 10Gbit hinaus kommen. Vorrausgesetzt Client und Isilon Node haben jeweils mindestens einen 10Gbit Link.
Die Isilon kann ihre Performance in größeren Cluster erst ausspielen, wenn tatsächlich die NFS Mounts auch über mehrere Isilon Nodes angesprochen werden. Das erfordert aber eben auch entsprechend viele Clients oder mindestens mehrere Mounts pro Client. Wobei der Client dann der Flaschenhals bleibt.
Man sollte dazu sagen, dass Isilon im Backend zwischen den Clusternodes 40 Gbit Infiniband nutzt. Wenn ich es gerade noch richtig im Kopf habe, nutzt er eine Blocksize von 256KB. Ab einer Dateigröße von 40MB würde er die Stripes also definitiv von allen Clusternodes lesen/schreiben. (Variiert je nach größe des Clusters und Dateigröße )
Kleines Rechenbeispiel (Theorie-Werte: Rundungsfehler, sowie 1000er oder 1024er Umrechnung und praxisnaher Kleinkram mal ignoriert):
20 Nodes, alle mit 10 Gbit angebunden. Du schreibst über 10 Nodes mit 10Gbit. Dann müssen die 10 Nodes 9,5Gbit der eingehenden Daten auf die anderen Nodes verteilen.
0,5Gbit Infiniband pro schreibende Nodes. Bei 10 schreibenden Nodes brauchst du bei allen 20 Cluster-Nodes also 5Gbit Infiniband. Den Break-Even für 40Gbit Infiniband kannst du dir selbst ausrechnen.
Listenpreis pro Isilon Node liegt IMHO irgendwo bei 40.000-60.000 Euro. Je nach Ausstattung. Das wird ein verdammt teurer Spaß in der Größenordnung.

Die Isilon hat ein Problem mit sehr vielen kleinen Dateien. Bei einem 4 Node Cluster mit 4GB Ram pro Node reicht der Ram des Clusters nicht aus, um die Metadaten von 20 Millionen Dateien zu verwalten. Ram als Read-Cache ist dann quasi völlig hinfällig. Da sollte man also auch ein bisschen auf die Ram-Ausstattung achten.

Wie viel Overhead existiert bei euch, aufgrund der Replizierung?

Die Isilon kennt unterschiedliche "Data Protection Policies". Die gehen von einfacher bis mehrfacher Partitätsberechnung bis hin zur plumpen Duplizierung der Daten. Die Redundanz lässt sich pro Datei festlegen. Erbt grundsätzlich aber erstmal die von dem Ordner in dem sie abgelegt wird. Ordner bekommen grundsätzliche eine Policy höher, als definiert.
Die reine Duplizierung der Daten frisst ordentlich IOPS und zieht die Schreibrate massiv in den Keller. Empfohlen sind die Protection Policies mit Paritätsberechnung. Auf Basis dessen habe ich allerdings meine Zweifel, dass mehr als 10Gbit möglich sind. Konnte ich allerdings nicht testen. Habe nur Nodes mit 2x1Gbit Anbindung zur Verfügung.

Was den Overhead im Dateisystem betrifft, so hatte ich mir aus der Isilon Doku mal eine kleine Übersicht mit Rechenbeispielen rauskopiert: http://my.eisscholle.net/protection_level.html

Konntest du schon Erfahrungen mit Rehhat Storage Server sammeln? Das soll anscheinend auch ein Glusterfs sein.

Nein bisher nicht.

 

[chris085]

Danke für die Auskunft. Hat mir auf jeden Fall mal geholfen eine Übersicht über das ganze zu bekommen.

Schätze dass wir in den nächsten Wochen konkret auf Hersteller zu gehen und uns auch mal deren Angebot anhören. Aus dem oben genannten lassen sich ein paar interessante Fragen ableiten

 

[remote_mind]

Bei den Datenmengen und der Anforderung 'Aufheben aber nur selten wieder Zugreifen' könnte man auch über einen LTO-Roboter nachdenken. Also Bänder statt Festplatten. Auf den 10TB-Satz greifst Du ja auch nicht wahlfrei zu, wenn wird der komplett wieder eingelesen.

 

[Joe User]

Wenn Ihr aus 10TB nur <1MB Daten benötigt, dann läuft da etwas grundlegend falsch. Bevor Ihr da etliche 10k Euro an Speicher verschwendet, solltet Ihr lieber die 99,999% Datenmüll erheblich reduzieren.
Üblicherweise legt man sich ein/zwei/drei Produktsamples und eine (zertifizierte) Testumgebung auf Lager und kann dann bei Bedarf jederzeit die benötigten Testdaten reproduzieren. Zudem stellt man so auch sicher, dass die Daten auch noch lesbar sind, wenn die heute verwendete Infrastruktur morgen erneuert/gewechselt wird. Nebenbei spart man sich das Risiko kippender Bits, welche bei ungeeigneten Archivierungslösungen wie Clustern, Datenbanken, komprimierten Datenformaten, etc. auftreten (ein gekipptes Bit macht da aus 1ns mal eben 11ns und schon sind 10TB Messdaten komplett unbrauchbar).

Big Data, oder wie auch immer das nennen möchte, ist da technisch wie wirtschaftlich mit das Dümmste, was man in Betracht ziehen könnte.

Mit dem gesparten Geld kann man dann lieber ein/zwei soziale Einrichtungen vor Ort fördern...

 

[marce]

Wenn Ihr aus 10TB nur <1MB Daten benötigt, dann läuft da etwas grundlegend falsch.

... sorry, aber die Aussage ist Humbug.

Es gibt eben viele Anwendungsfälle, in denen man entsprechende Kummulations/Aggregations-Methoden verwendet. Daß die nicht jedem jeden Tag begegnen oder teilweise komplett unbekannt sind hat ja nichts mit "richtig" oder "falsch" zu tun.

 

[Joe User]

Ich kenne mehrere Messumgebungen bei denen weit mehr als 10TB/Stunde an Messdaten anfallen und wo ebenfalls nur wenige MB irgendwann einmal interessant sein könnten. Dort würde aber Niemand auf die völlig absurde Idee kommen, diesen Müllhaufen dauerhaft komplett zu speichern. Entweder werden dort nur die relevanten Datenhäppchen gespeichert oder eben die Samples auf Lager gelegt, manchmal auch Beides. Da Ersteres vom OP als No-go ausgeschlossen wurde, bleibt noch Zweites als gängige real-world Praxislösung übrig.

Wie hat man soetwas nur vor dem Big-Data-Hype gelöst?



Organisationen/Institute die so Speichern müssen wie es der OP gerne hätte, die haben dafür entsprechende Lösungen und vor Allem Fachpersonal welches sich mit der Thematik auskennt (von denen muss Keiner im SSF nach untauglichen Lösungen fragen, die tauschen sich auf nicht-öffentlichen Fachtagungen/messen gegenseitig aus).

 

[chris085]

@Joe
Die Mehrheit der Logs wird nie wieder reproduzierbar sein! Es geht nicht nur um die Nachstellung von Prozessen, sondern jedes Ergebnis ist einzigartig

Organisationen/Institute die so Speichern müssen wie es der OP gerne hätte, die haben dafür entsprechende Lösungen und vor Allem Fachpersonal welches sich mit der Thematik auskennt (von denen muss Keiner im SSF nach untauglichen Lösungen fragen, die tauschen sich auf nicht-öffentlichen Fachtagungen/messen gegenseitig aus).

Ganz ehrlich... ich habe keine Lust ausschließlich Consultants von Firma xy zu glauben und mein Wissen auf vielleicht 3-4 Firmen zu beschränken. Ich denke dass hier sehr kompetente User unterwegs sind, die durchaus auch Ahnung im Enterprise Bereich haben und willig sind sich Auszutauschen. So verstehe ich zu mindestens den Sinn von Foren - übrigens auch Barcamps. Falls es bei dir nicht so ist, dann solltest du dich ggf. einfach nach einem neuen Job umschauen.

 

[Joe User]

Ich wollte Dir gerade einen Kontakt zu Jemanden vermitteln, der solch ein System (nur in ein paar Grössenordnungen grösser) wie Du es suchst, an einem renomierten deutschen Forschungsinstitut technisch betreut. Da Dir aber offensichtlich die Antworten anderer SSF-User vertrauenswürdiger und zuverlässiger zu sein scheinen, habe ich das Telefonat gerade vorzeitig beendet.

Ich soll Dir aber noch dringend von den hier genannten ClusterFS und sonstigen Lösungen, sowie Hadoop abraten, damit würdest Du Dir früher oder später ins eigene Knie schiessen und die Daten ins Nirvana schicken.

Da ich in diesem Thead quasi unerwünscht bin: EOD

 

[marce]

Naja, Hadoop als "Auswertungs- und Rechenengine" ist durchaus brauchbar für derlei Dinge. Um die Datensicherung und Backup sollte man sich anderweitig kümmern.

 

[Firewire2002]

Ich soll Dir aber noch dringend von den hier genannten ClusterFS und sonstigen Lösungen, sowie Hadoop abraten, damit würdest Du Dir früher oder später ins eigene Knie schiessen und die Daten ins Nirvana schicken.

Hatte ich eingangs ja auch schon geschrieben gehabt, wenn vielleicht auch nicht so drastisch formuliert. Schön das andere das genauso sehen.