🥇Dateiformate in Big Data: ein kurzes Schulungsprogramm

Wettergottheit von Remarin

Team Mail.ru Cloud-Lösungen bietet Artikel übersetzung Ingenieur Rahul Bhatia von Clairvoyant darüber, welche Dateiformate es in Big Data gibt, was die häufigsten Merkmale von Hadoop-Formaten sind und welches Format besser zu verwenden ist.

Warum werden unterschiedliche Dateiformate benötigt?

Ein großer Leistungsengpass für HDFS-fähige Anwendungen wie MapReduce und Spark ist die Zeit, die zum Suchen, Lesen und Schreiben von Daten benötigt wird. Diese Probleme werden durch die Schwierigkeit verschärft, große Datenmengen zu verwalten, wenn wir ein sich entwickelndes Schema anstelle eines festen Schemas haben oder wenn es einige Speicherbeschränkungen gibt.

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

Verschiedene Dateiformate in Hadoop erfunden, um genau diese Probleme zu lösen. Die Auswahl des geeigneten Dateiformats kann einige erhebliche Vorteile bieten:

Schnellere Lesezeit.
Schnellere Aufnahmezeit.
Geteilte Dateien.
Unterstützung für die Schemaentwicklung.
Erweiterte Komprimierungsunterstützung.

Einige Dateiformate sind für den allgemeinen Gebrauch gedacht, andere für spezifischere Zwecke und wieder andere sind darauf ausgelegt, bestimmte Datenmerkmale zu erfüllen. Die Auswahl ist also wirklich recht groß.

Avro-Dateiformat

für Datenserialisierung Avro ist weit verbreitet - es stringbasiert, also ein String-Datenspeicherformat in Hadoop. Es speichert das Schema im JSON-Format, sodass es von jedem Programm leicht gelesen und interpretiert werden kann. Die Daten selbst liegen im Binärformat vor, sind kompakt und effizient.

Das Serialisierungssystem von Avro ist sprachneutral. Dateien können in einer Vielzahl von Sprachen verarbeitet werden, derzeit C, C++, C#, Java, Python und Ruby.

Ein Hauptmerkmal von Avro ist seine robuste Unterstützung für Datenschemata, die sich im Laufe der Zeit ändern, also weiterentwickeln. Avro versteht Schemaänderungen – das Löschen, Hinzufügen oder Ändern von Feldern.

Avro unterstützt eine Vielzahl von Datenstrukturen. Sie können beispielsweise einen Datensatz erstellen, der ein Array, einen Aufzählungstyp und einen Unterdatensatz enthält.

Dieses Format eignet sich ideal zum Schreiben in die Landezone (Übergangszone) eines Data Lake (Datenseeoder Data Lake – eine Sammlung von Instanzen zum Speichern verschiedener Datentypen zusätzlich zu Datenquellen direkt).

Daher eignet sich dieses Format aus folgenden Gründen am besten zum Schreiben in die Landezone eines Data Lake:

Daten aus dieser Zone werden in der Regel vollständig zur Weiterverarbeitung durch nachgelagerte Systeme gelesen – ein zeilenbasiertes Format ist in diesem Fall effizienter.
Nachgelagerte Systeme können Schematabellen problemlos aus Dateien abrufen – Schemata müssen nicht separat in einem externen Metaspeicher gespeichert werden.
Jede Änderung am ursprünglichen Schema kann problemlos verarbeitet werden (Schema-Evolution).

Parquet-Dateiformat

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

Im Vergleich zum herkömmlichen Reihenansatz ist Parkett hinsichtlich Lagerung und Leistung effizienter.

Dies ist besonders nützlich für Abfragen, die bestimmte Spalten aus einer breiten Tabelle (viele Spalten) lesen. Dank des Dateiformats werden nur die notwendigen Spalten gelesen, sodass I/O auf ein Minimum beschränkt wird.

Ein kleiner Exkurs und eine Erklärung: Um das Parquet-Dateiformat in Hadoop besser zu verstehen, sehen wir uns an, was ein spaltenbasiertes – also spaltenorientiertes – Format ist. Dieses Format speichert ähnliche Werte für jede Spalte zusammen.

Beispielsweiseenthält der Datensatz die Felder „ID“, „Name“ und „Abteilung“. In diesem Fall werden alle ID-Spaltenwerte zusammen gespeichert, ebenso die Namensspaltenwerte usw. Die Tabelle sieht in etwa so aus:

ID
Name
Abteilung

1
emp1
d1

2
emp2
d2

3
emp3
d3

Im String-Format werden die Daten wie folgt gespeichert:

1
emp1
d1
2
emp2
d2
3
emp3
d3

In einem spaltenorientierten Dateiformat werden dieselben Daten wie folgt gespeichert:

1
2
3
emp1
emp2
emp3
d1
d2
d3

Das Spaltenformat ist effizienter, wenn Sie mehrere Spalten aus einer Tabelle abfragen müssen. Es werden nur die erforderlichen Spalten gelesen, da diese benachbart sind. Auf diese Weise werden I/O-Vorgänge auf ein Minimum beschränkt.

Beispielsweise benötigen Sie nur die Spalte NAME. IN String-Format Jeder Datensatz im Datensatz muss geladen, nach Feldern analysiert und dann die NAME-Daten extrahiert werden. Das Spaltenformat ermöglicht Ihnen einen direkten Drilldown zur Spalte „Name“, da alle Werte für diese Spalte zusammen gespeichert werden. Sie müssen nicht die gesamte Aufnahme scannen.

Somit verbessert das Spaltenformat die Abfrageleistung, da es weniger Suchzeit benötigt, um zu den erforderlichen Spalten zu gelangen, und reduziert die Anzahl der E/A-Vorgänge, da nur die gewünschten Spalten gelesen werden.

Eines der Alleinstellungsmerkmale Parkett ist, dass es in diesem Format möglich ist Speichern Sie Daten mit verschachtelten Strukturen. Dies bedeutet, dass in einer Parquet-Datei auch verschachtelte Felder einzeln gelesen werden können, ohne dass alle Felder in der verschachtelten Struktur gelesen werden müssen. Parkett verwendet einen Schredder- und Montagealgorithmus, um verschachtelte Strukturen zu speichern.

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

Gruppe von Saiten (Zeilengruppe): logische horizontale Aufteilung der Daten in Zeilen. Eine Zeilengruppe besteht aus einem Fragment jeder Spalte im Datensatz.
Spaltenfragment (Spaltenblock): Ein Fragment einer bestimmten Spalte. Diese Spaltenfragmente befinden sich in einer bestimmten Zeilengruppe und sind in der Datei garantiert zusammenhängend.
Seite (Seite): Spaltenfragmente werden in nacheinander geschriebene Seiten unterteilt. Die Seiten haben einen gemeinsamen Titel, sodass Sie beim Lesen unnötige Titel überspringen können.

Hier enthält der Titel nur die magische Zahl PAR1 (4 Bytes), der die Datei als Parquet-Datei identifiziert.

In der Fußzeile steht folgendes:

Dateimetadaten, die die Startkoordinaten der Metadaten jeder Spalte enthalten. Beim Lesen müssen Sie zunächst die Metadaten der Datei lesen, um alle relevanten Spaltenfragmente zu finden. Die Spaltenteile sollten dann nacheinander gelesen werden. Zu den weiteren Metadaten gehören die Formatversion, das Schema und alle zusätzlichen Schlüssel-Wert-Paare.
Metadatenlänge (4 Bytes).
magische Zahl PAR1 (4 Bytes).

ORC-Dateiformat

Optimiertes Zeilen-Spalten-Dateiformat (Optimierte Zeilenspalte, ORC) bietet eine sehr effiziente Möglichkeit zum Speichern von Daten und wurde entwickelt, um die Einschränkungen anderer Formate zu überwinden. Speichert Daten in perfekt kompakter Form, sodass Sie unnötige Details überspringen können – ohne dass große, komplexe oder manuell gepflegte Indizes erstellt werden müssen.

Vorteile des ORC-Formats:

Eine Datei ist die Ausgabe jeder Aufgabe, wodurch die Belastung des NameNode (Namensknoten) verringert wird.
Unterstützung für Hive-Datentypen, einschließlich DateTime, dezimale und komplexe Datentypen (Struktur, Liste, Karte und Union).
Gleichzeitiges Lesen derselben Datei durch verschiedene RecordReader-Prozesse.
Möglichkeit, Dateien zu teilen, ohne nach Markierungen zu suchen.
Schätzung der maximal möglichen Heap-Speicherbelegung für Lese-/Schreibvorgänge anhand der Informationen im Dateifuß.
Metadaten werden im binären Serialisierungsformat Protocol Buffers gespeichert, das das Hinzufügen und Entfernen von Feldern ermöglicht.

ORC speichert Zeichenfolgensammlungen in einer einzigen Datei, und innerhalb der Sammlung werden Zeichenfolgendaten in einem Spaltenformat gespeichert.

In einer ORC-Datei werden Gruppen von Linien, sogenannte Streifen, und unterstützende Informationen in der Fußzeile der Datei gespeichert. Das Postscript am Ende der Datei enthält Komprimierungsparameter und die Größe der komprimierten Fußzeile.

Die Standard-Stripe-Größe beträgt 250 MB. Aufgrund dieser großen Streifen erfolgt das Lesen aus HDFS effizienter: in großen zusammenhängenden Blöcken.

In der Dateifußzeile werden die Liste der Spuren in der Datei, die Anzahl der Zeilen pro Spur und der Datentyp jeder Spalte aufgezeichnet. Dort wird auch der resultierende Wert von count, min, max und sum für jede Spalte geschrieben.

Die Fußzeile des Streifens enthält ein Verzeichnis der Stream-Standorte.

Beim Scannen von Tabellen werden Zeilendaten verwendet.

Zu den Indexdaten gehören die Mindest- und Höchstwerte für jede Spalte sowie die Position der Zeilen in jeder Spalte. ORC-Indizes werden nur zur Auswahl von Stripes und Zeilengruppen verwendet, nicht zur Beantwortung von Abfragen.

Vergleich verschiedener Dateiformate

Avro im Vergleich zu Parkett

Avro ist ein Zeilenspeicherformat, während Parquet Daten in Spalten speichert.
Parquet eignet sich besser für analytische Abfragen, was bedeutet, dass Lesevorgänge und das Abfragen von Daten wesentlich effizienter sind als Schreibvorgänge.
Schreibvorgänge werden in Avro effizienter ausgeführt als in Parquet.
Avro befasst sich ausgereifter mit der Schaltungsentwicklung. Parquet unterstützt nur das Hinzufügen von Schemata, während Avro die multifunktionale Evolution unterstützt, also das Hinzufügen oder Ändern von Spalten.
Parquet eignet sich ideal zum Abfragen einer Teilmenge von Spalten in einer mehrspaltigen Tabelle. Avro eignet sich für ETL-Operationen, bei denen wir alle Spalten abfragen.