🥇Dateiformate in Big Data: ein kurzer Überblick

Wettergott von Remarin

Team Mail.ru Cloud Solutions bietet Übersetzung des Artikels von Ingenieur Rahul Bhatia von Clairvoyant über die verschiedenen Dateiformate in Big Data, welche die häufigsten Funktionen von Hadoop-Formaten sind und welches Format am besten verwendet werden sollte.

Warum sind verschiedene Dateiformate notwendig

Ein ernsthaftes Engpassproblem bei der Leistung von Anwendungen, die HDFS unterstützen, wie MapReduce und Spark, ist die Zeit für die Suche, das Lesen und das Schreiben von Daten. Diese Probleme werden durch die Schwierigkeiten beim Management großer Datensätze verschärft, wenn wir nicht über ein festgelegtes, sondern ein sich weiterentwickelndes Schema verfügen oder wenn Einschränkungen für die Speicherung bestehen.

Die Verarbeitung großer Datenmengen erhöht die Belastung des Speichersystems – Hadoop speichert Daten redundant, um Fehlertoleranz zu erreichen. Neben Festplatten werden auch Prozessor, Netzwerk, Ein- und Ausgabesystem usw. belastet. Mit dem Wachstum des Datenvolumens steigen auch die Kosten für deren Verarbeitung und Speicherung.

Verschiedene Dateiformate in Hadoop wurden entwickelt, um genau diese Probleme zu lösen. Die Wahl des geeigneten Dateiformats kann erhebliche Vorteile bringen:

Schnelleres Lesezeiten.
Schnelleres Schreibzeiten.
Teilbare Dateien.
Unterstützung der Schema-Evolution.
Erweiterte Unterstützung von Kompression.

Einige Dateiformate sind für allgemeine Zwecke gedacht, andere für spezifischere Anwendungen, und einige wurden unter Berücksichtigung bestimmter Dateneigenschaften entwickelt. Daher gibt es tatsächlich eine große Auswahl.

Das Avro-Dateiformat

Für zur Datenspeicherung wird weit verbreitet eingesetzt – Avro ist ein zeichenbasierterDatenspeicherformat in Hadoop. Es speichert das Schema im JSON-Format, was das Lesen und Interpretieren durch jedes Programm erleichtert. Die Daten selbst liegen im binären Format vor, kompakt und effizient.

Das Avro-Serialisierungssystem ist sprachneutral. Dateien können in verschiedenen Sprachen verarbeitet werden, derzeit sind dies C, C++, C#, Java, Python und Ruby.

Ein zentrales Merkmal von Avro ist die zuverlässige Unterstützung von Datenschemas, die sich im Laufe der Zeit ändern, d.h. weiterentwickeln. Avro erkennt Schemaänderungen – das Löschen, Hinzufügen oder Ändern von Feldern.

Avro unterstützt eine Vielzahl von Datenstrukturen. Zum Beispiel kann man einen Datensatz erstellen, der ein Array, einen Aufzählungstyp und einen Unterdatensatz enthält.

Dieses Format eignet sich perfekt zum Schreiben in die Landing Zone des Data Lakes (Data Lake, oder Data Lake – eine Sammlung von Instanzen zur Speicherung verschiedener Datentypen zusätzlich zu den Datenquellen selbst).

Also, für das Schreiben in die Landing Zone eines Data Lakes ist dieses Format aus folgenden Gründen am besten geeignet:

Daten aus dieser Zone werden normalerweise vollständig gelesen, um von nachgelagerten Systemen verarbeitet zu werden – und der zeilenbasierte Format ist in diesem Fall effizienter.
Nachgelagerte Systeme können Tabellenschemata problemlos aus Dateien extrahieren – es ist nicht notwendig, Schemata separat in einem externen Metaspeicher zu speichern.
Jede Änderung im ursprünglichen Schema wird leicht verarbeitet (Schema-Evolution).

Das Parquet-Dateiformat

Parquet ist ein Open-Source-Dateiformat für Hadoop, das verschachtelte Datenstrukturen in einem flachen Spaltenformat speichert..

Im Vergleich zu einem traditionellen zeilenbasierten Ansatz ist Parquet hinsichtlich Speicherung und Leistung effizienter.

Dies ist besonders nützlich für Abfragen, die bestimmte Spalten aus einer breiten (mit vielen Spalten) Tabelle lesen. Dank des Dateiformats werden nur die benötigten Spalten gelesen, wodurch Ein- und Ausgaben minimiert werden.

Eine kleine Erklärung: Um das Parquet-Dateiformat in Hadoop besser zu verstehen, lassen Sie uns betrachten, was ein spaltenbasierter – also ein spaltenorientierter – Format ist. In einem solchen Format werden gleichartige Werte jeder Spalte zusammen gespeichert.

Zum Beispiel, der Datensatz umfasst die Felder ID, Name und Abteilung. In diesem Fall werden alle Werte der Spalte ID zusammen gespeichert, ebenso wie die Werte der Spalte Name und so weiter. Die Tabelle würde folgendermaßen aussehen:

ID
Name
Abteilung

1
emp1
d1

2
emp2
d2

3
emp3
d3

Im zeilenbasierten Format werden die Daten wie folgt gespeichert:

1
emp1
d1
2
emp2
d2
3
emp3
d3

Im spaltenbasierten Format werden dieselben Daten so gespeichert:

1
2
3
emp1
emp2
emp3
d1
d2
d3

Das spaltenbasierte Format ist effizienter, wenn Sie aus einer Tabelle mehrere Spalten abfragen müssen. Es werden nur die erforderlichen Spalten gelesen, da sie nebeneinander liegen. Dadurch werden Ein- und Ausgaben minimiert.

Zum Beispiel benötigen Sie nur die Spalte NAME. Im zeilenbasierten Format Jeder Datensatz im Datensatz muss geladen, in Felder zerlegt und dann die Daten NAME extrahiert werden. Das spaltenbasierte Format ermöglicht den direkten Zugriff auf die Spalte Name, da alle Werte für diese Spalte zusammen gespeichert werden. Ein Scannen des gesamten Datensatzes ist nicht erforderlich.

Somit verbessert das spaltenbasierte Format die Abfrageleistung, da weniger Suchzeit benötigt wird, um zu den erforderlichen Spalten zu gelangen, und die Anzahl der Lese- und Schreibvorgänge reduziert wird, da nur die benötigten Spalten gelesen werden.

Eine der einzigartigen Eigenschaften Parquet besteht darin, dass es in diesem Format Daten mit verschachtelten Strukturenspeichern kann. Das bedeutet, dass in einer Parquet-Datei sogar verschachtelte Felder einzeln gelesen werden können, ohne dass alle Felder der verschachtelten Struktur gelesen werden müssen. Für die Speicherung von verschachtelten Strukturen verwendet Parquet den Algorithmus für Zerlegung und Zusammenstellung (shredding and assembly).

Um das Parquet-Dateiformat in Hadoop zu verstehen, müssen die folgenden Begriffe bekannt sein:

Row Group (row group): logische horizontale Aufteilung der Daten in Zeilen. Eine Row Group besteht aus einem Fragment jeder Spalte im Datensatz.
Column Chunk (column chunk): Fragment einer bestimmten Spalte. Diese Spaltenfragmente befinden sich in einer bestimmten Row Group und werden im Datei garantiert benachbart sein.
Seite (page): Spaltenfragmente werden in aufeinanderfolgende Seiten unterteilt. Seiten haben einen gemeinsamen Header, sodass beim Lesen unnötige übersprungen werden können.

Hier enthält der Header einfach eine magische Zahl PAR1 (4 Bytes), die die Datei als Datei im Parquet-Format identifiziert.

Im Footer ist Folgendes aufgezeichnet:

Metadaten der Datei, die die Startkoordinaten der Metadaten jeder Spalte enthalten. Beim Lesen müssen zunächst die Metadaten der Datei gelesen werden, um alle interessierenden Spaltenfragmente zu finden. Danach sollten die Spaltenfragmente nacheinander gelesen werden. Die Metadaten umfassen außerdem die Versionsnummer des Formats, das Schema und alle zusätzlichen Schlüssel-Wert-Paare.
Länge der Metadaten (4 Bytes).
Magische Zahl PAR1 (4 Bytes).

Das ORC-Dateiformat

Optimiertes zeilen- und spaltenbasiertes Dateiformat (Optimized Row Columnar, ORC) bietet eine sehr effiziente Methode zur Datenspeicherung und wurde entwickelt, um die Einschränkungen anderer Formate zu überwinden. Es speichert Daten in einer perfekt kompakten Form und ermöglicht das Überspringen unnötiger Details, ohne dass große, komplexe oder manuell wartbare Indizes erforderlich sind.

Vorteile des ORC-Formats:

Eine Datei pro Aufgabe, was die Belastung des NameNode (Master-Node) verringert.
Unterstützung von Hive-Datentypen, einschließlich DateTime, Dezimal- und komplexen Datentypen (struct, list, map und union).
Gleichzeitige Lesung derselben Datei durch verschiedene Prozesse des RecordReaders.
Möglichkeit der Dateiteilung ohne das Scannen nach Markierungen.
Schätzung des maximalen Heap-Speicherplatzes für Lese-/Schreibprozesse anhand der Informationen im Datei-Footer.
Metadaten werden im binären Format der Serialisierung von Protocol Buffers gespeichert, wodurch das Hinzufügen und Löschen von Feldern möglich ist.

ORC speichert Sammlungen von Zeilen in einer Datei, wobei innerhalb der Sammlung die Zeilendaten in einem Spaltenformat gespeichert werden.

Die ORC-Datei speichert Gruppen von Zeilen, die als Streifen (stripes) bezeichnet werden, und zusätzliche Informationen im Fußbereich der Datei. Der Postscript am Ende der Datei enthält Komprimierungsparameter und die Größe des komprimierten Fußbereichs.

Der Standardstreifen hat eine Größe von 250 MB. Dank der großen Streifen wird das Lesen von HDFS effizienter, da große zusammenhängende Blöcke gelesen werden.

Im Fußbereich der Datei ist eine Liste der Streifen in der Datei, die Anzahl der Zeilen pro Streifen und der Datentyp jeder Spalte aufgezeichnet. Dort sind auch die resultierenden Werte für count, min, max und sum für jede Spalte gespeichert.

Der Fußbereich des Streifens enthält ein Verzeichnis der Standortströme.

Zeilendaten werden beim Scannen von Tabellen verwendet.

Indizes umfassen minimale und maximale Werte für jede Spalte sowie die Positionen der Zeilen in jeder Spalte. ORC-Indizes werden nur zur Auswahl von Streifen und Gruppen von Zeilen verwendet und nicht zur Beantwortung von Anfragen.

Vergleich verschiedener Dateiformate

Avro im Vergleich zu Parquet

Avro ist ein zeilenbasiertes Speicherformat, während Parquet Daten spaltenbasiert speichert.
Parquet eignet sich besser für analytische Abfragen, das heißt, Leseoperationen und Datenabfragen sind viel effizienter als Schreiboperationen.
Schreiboperationen in Avro werden effizienter durchgeführt als in Parquet.
Avro funktioniert reifer mit der Weiterentwicklung von Schemata. Parquet unterstützt nur das Hinzufügen von Schemata, während Avro eine multifunktionale Evolution implementiert, das heißt, das Hinzufügen oder Ändern von Spalten.
Parquet eignet sich hervorragend für Anfragen zu Teilmengen von Spalten in einer mehrspaltigen Tabelle. Avro ist geeignet für ETL-Vorgänge, bei denen wir alle Spalten anfragen.