Hadoop enthält Produkte, die mit Dateien verschiedener Formate arbeiten können. Ich habe wiederholt gesucht, gelesen und darüber nachgedacht, welches Format besser ist. Als ich relativ zufällig auf das ORC-Format stieß, wurde ich interessiert, las (und sogar ein wenig verhätschelt), und das habe ich verstanden - es ist falsch, Formate als solche zu vergleichen. Genauer gesagt werden sie meiner Meinung nach normalerweise falsch verglichen. Eigentlich ein Artikel darüber sowie über das Apache ORC-Format (in technischer Hinsicht) und die Möglichkeiten, die es bietet.

Ich beginne mit der Frage: Wie groß kann eine relationale Tabelle (in Bytes und sehr ungefähr) sein, die aus 10.000 Zeilen besteht (zwei ganzzahlige Felder pro Zeile)? Normalerweise setzen sie hier ein Kat und die Antwort wird unter das Kat gestellt - ich werde hier antworten: 628 Bytes. Und die Details und die Geschichte werden unter Katze übertragen.

Wie alles begann: Ich habe eine Bibliothek für die Arbeit mit Apache ORC erstellt (siehe Projekthomepage - https://orc.apache.org ) und ein eigenes Beispiel für das Schreiben in ORC zusammengestellt (um Ihnen den Kopf zu brechen - wir beginnen mit dem, was funktioniert). Es hatte 2 Felder und 10 Tausend Zeilen. Ich habe es gestartet - ich habe die Ork-Datei erhalten, weil ich es irgendwo außerhalb des Büros gemacht habe - für den Fall, dass ich die Bibliothek und die Datei auf einem Flash-Laufwerk neu geschrieben habe (in Eile - ich habe mir die Größe nicht angesehen, ich denke, das Flash-Laufwerk kann damit umgehen).

Aber irgendwie habe ich schnell korrespondiert ... Ich habe mir die Größe angesehen - 628 Bytes. Ich dachte, es sei ein Fehler, setzte mich und begann zu verstehen. Ich habe das Dienstprogramm zum Anzeigen von ORC aus derselben kompilierten Bibliothek gestartet - der Inhalt der Datei zeigt, dass alles ehrlich ist - zehntausend Zeilen. Danach fragte ich mich, wie zehntausend Zeilen in 628 Bytes passen könnten (ich wusste zu diesem Zeitpunkt bereits ein wenig über ORC und stellte fest, dass es auch Metadaten gab - das Format war autark). Verstanden, teilen.

Informationen zum ORC-Format

Ich werde hier keine allgemeinen Worte über das Format wiederholen - siehe den obigen Link, es ist dort gut geschrieben. Ich werde mich auf zwei Adjektive in hervorragender Form aus dem obigen Bild konzentrieren (das Bild stammt von der Homepage des Projekts): Versuchen wir herauszufinden, warum ORC „das schnellste“ und „das kompakteste“ ist.

Geschwindigkeit

Die Geschwindigkeit kann in Bezug auf Daten unterschiedlich sein - zumindest die Geschwindigkeit des Lesens oder Schreibens (Sie können tiefer gehen, aber lassen Sie uns vorerst aufhören). Da Hadoop im obigen Slogan ausdrücklich erwähnt wird, werden wir in erster Linie die Lesegeschwindigkeit berücksichtigen.

Um ein wenig mehr aus der ORC-Dokumentation zu zitieren:

Es ist für große Streaming-Lesevorgänge optimiert, bietet jedoch integrierte Unterstützung für das schnelle Auffinden der erforderlichen Zeilen. Durch das Speichern von Daten in einem Spaltenformat kann der Leser nur die Werte lesen, dekomprimieren und verarbeiten, die für die aktuelle Abfrage erforderlich sind.

Ich werde ein wenig übersetzen:

• Format optimiert für das Streaming beim Lesen großer Volumes
• enthält gleichzeitig Unterstützung für die schnelle Suche nach notwendigen Zeilen
• Mit dieser Option können Sie nur die Daten lesen, die Sie benötigen

Größe

Es gab kein Zitat, werde ich in meinen eigenen Worten sagen

• Format speichert Meta-Informationen optimal
• ein Gleichgewicht zwischen Streaming-Lesegeschwindigkeit und kompaktem Speicher finden
• integrierte Unterstützung für die kompakteste Speicherung von Spaltenwerten

Möglichkeiten bieten

Ich möchte Ihre Aufmerksamkeit auf den Wortlaut aus den obigen Zitaten lenken: "optimiert für ...", "enthält Unterstützung ...", "ermöglicht das Lesen ..." - das Dateiformat als Programmiersprache ist ein Mittel (in diesem Fall Bereitstellung) effiziente Speicherung und Zugriff auf Daten). Ob die Speicherung und der Zugriff auf Daten wirklich effektiv sind, hängt nicht nur vom Tool ab, sondern auch davon, wer sie wie verwendet.

Mal sehen, welches Format das Format für Geschwindigkeit und Kompaktheit bietet.

Säulenlagerung und Streifen

Die Daten im ORC werden in Form von Spalten gespeichert, die sich zunächst auf die Größe auswirken. Um die Geschwindigkeit des Streaming-Lesens sicherzustellen, wird die Datei in sogenannte "Streifen" unterteilt, wobei jeder Streifen autark ist, d. H. kann separat (und daher parallel) gelesen werden. Aufgrund von Streifen nimmt die Dateigröße zu (nicht eindeutige Spaltenwerte werden mehrmals gespeichert - in den Streifen, in denen solche Werte auftreten) - das gleiche Gleichgewicht von "Geschwindigkeit - Größe" (dies ist ein Kompromiss).

Indizes

Das ORC-Format impliziert Indizes, mit denen Sie bestimmen können, ob der Streifen (oder vielmehr die Streifenteile von jeweils 10.000 Zeilen, die sogenannte "Zeilengruppe") die gewünschten Daten enthält oder nicht. Indizes werden für jede der Spalten erstellt. Dies wirkt sich auf die Lesegeschwindigkeit aus und vergrößert die Größe. Beim Streaming von Leseindizes kann man übrigens nicht lesen.

Komprimierung

Alle Metadaten werden in komprimierter Form gespeichert, und dies

• statistische und beschreibende Informationen (das Format ermöglicht es Ihnen, die darin gespeicherte Tabelle einschließlich der Namen und Feldtypen neu zu erstellen)
• Indizes
• Partitionierung von Informationen (in Streifen und Streams)

(Unten sehen wir, dass Metadaten ein wesentlicher Bestandteil der Datei sind.)

Spaltenwerte werden auch in komprimierter Form gespeichert. Gleichzeitig ist es möglich, nur den benötigten Datenblock zu lesen und zu entpacken (d. H. Keine Datei wird komprimiert und kein ganzer Streifen). Die Komprimierung wirkt sich sowohl auf die Größe als auch auf die Lesegeschwindigkeit aus.

Codierung

Die Spaltenwerte - und die Datei speichert genau diese Werte - werden in codierter Form gespeichert. In der aktuellen Version des Formats (ORC v1) für Ganzzahlen stehen beispielsweise 4 Codierungsoptionen zur Verfügung. Gleichzeitig wird nicht die gesamte Spalte codiert, sondern Teile der Spalte werden codiert. Jeder Teil kann für diesen Teil optimal codiert werden (solche Teile werden in der Spezifikation als "Ausführen" bezeichnet). Somit wird eine Minimierung der Gesamtlänge der gespeicherten Daten erreicht. Wieder die Auswirkung auf Größe und Geschwindigkeit.

Sehen wir uns die ORC-Datei an

Schauen wir uns ganz kurz an, was sich in der ORC-Datei befindet (die selbst ist 628 Byte). Für diejenigen, die nicht sehr an technischen Details interessiert sind, scrollen Sie zum nächsten Abschnitt (über den Formatvergleich).

So wurde unsere Tabelle im Beispieldatensatz in ORC definiert:

Metadaten

Informationen zu den Längen (ich gebe Screenshots von Jupyter Notebooks, ich denke es ist klar genug)

Was wir hier sehen:

• im "shank" (und das ist Postscript + Footer + Metadata) nur 1 + 23 + 115 + 50 = 189 Bytes
• in einem einzelnen Streifen sind nur 3 + 436 = 439 Bytes, insgesamt 628 Bytes
• Streifen enthält einen Index (73 Bytes), Daten (276 Bytes), Fußzeile (87 Bytes)

Achten wir hier auf das Verhältnis von Datenvolumen und Metadaten (276 zu 352 Bytes). Diese 276 Datenbytes sind aber auch nicht nur Daten, die Daten enthalten ein bisschen „überflüssig“ (der Kürze halber gebe ich hier keine Screenshots - es dauert lange, ich werde nur meine Kommentare verwalten), die in den Daten enthalten sind:

• Derzeit sind für jede Spalte drei Streams vorhanden (einschließlich einer gemeinsamen Pseudospaltenstruktur) - jeweils 20 Bytes, insgesamt 60 Bytes
• Datenströme (hier ist die Pseudospalte nicht dargestellt) - 103 und 113 Bytes (Spalten "x" bzw. "y")

PRESENT-Streams sind Bitfolgen, mit denen Sie wissen, wo die Spalten NULL sind. In unserem Beispiel sieht ihre Anwesenheit seltsam aus (in der Statistik unserer Datei steht eindeutig, dass die Daten keine NULL-Werte enthalten - warum dann PRESENT einschließen? Es scheint ein Fehler zu sein ...)

Insgesamt belegen die Daten selbst 216 Bytes, Metadaten - 352.

Aus den Metadaten ist auch ersichtlich, dass beide Spalten mit der DIRECT_V2-Methode codiert sind (für Ganzzahlen sind 4 Arten von Darstellungen zulässig, Einzelheiten finden Sie in der Spezifikation - auf der Projektwebsite).

Daten

Mal sehen (der Kürze halber ohne Screenshots), wie zehntausend Zahlen in 103 Bytes passen (für die Spalte "x"):

• Es wird eine Delta-Codierung verwendet, bei der die Parameter der Anfangswert und der Schritt sind (der Kürze halber etwas vereinfacht).
• Wir haben immer 1 Schritt, der Anfangswert für den ersten Lauf ist 0, dann 511, 1022 usw.
• run (ein auf eine Weise codierter Datensatz) enthält in unserem Fall 511 Werte (der maximal mögliche Wert für die Delta-Codierung).
• Die Länge jedes Laufs in der Datei beträgt 4 bis 6 Byte (die Länge des Laufs nimmt zu, da der Anfangswert im Zickzack dargestellt wird).
• Insgesamt für die Spalte "x" erhalten wir in der Datei 20 Run-s mit einer Gesamtlänge von 103 Bytes (ich habe geprüft - alles passt zusammen)

Zum Abschluss der Überprüfung der Darstellung unserer einfachen Tabelle in einer Datei möchte ich sagen, dass die Indizes in diesem Beispiel entartet sind - sie zeigen den Beginn des Datenstroms an. Ich werde mich anhand von Beispielen aus der Praxis mit Indizes befassen und sie wahrscheinlich in einem separaten Artikel beschreiben.

Für Interessierte: Unter dem Link finden Sie ein Jupyter-Notizbuch, in dem ich das Format Interna "verstanden" habe. Sie können es verwenden und wiederholen (dort ist auch die ORC-Datei angehängt).

Ich bin sicher, dass viele Leser "verloren" sind - ja, das ORC-Format ist nicht einfach (sowohl hinsichtlich des Verständnisses der Details als auch hinsichtlich der Verwendung der bereitgestellten Funktionen).

Über den Formatvergleich

Kommen wir nun zum Hauptpunkt - dem falschen Formatvergleich.

Wie oft werden die Formate verglichen: Vergleichen wir die Größe der Dateien im Format A und B, die Lesegeschwindigkeit (verschiedene Arten des Lesens - zufällig, Streaming usw.) im Format A und B. Vergleichen Sie, dass Format A besser ist als Format B.

Am Beispiel des letzten der oben aufgeführten Kompaktheitstools (Codierungswerkzeuge): Können die Daten im ORC optimal codiert werden? Ja, es gibt Möglichkeiten - siehe oben. Aber genauso gut kann man das nicht! Dies hängt vom „Writer“ ab (Writer in ORC-Terminologie): Im obigen Beispiel könnte der Writer dies tun. Aber er könnte einfach 2 Mal in zehntausend Zahlen aufschreiben und dies wäre auch in Bezug auf das Format korrekt. Beim Vergleich von Formaten "nach Größe" vergleichen wir nicht nur und nicht so sehr die Formate als vielmehr die algorithmische Qualität von Anwendungssystemen, die diese Formate verwenden .

Wer ist der "Schriftsteller" in Hadoop? Es gibt viele davon - zum Beispiel Hive, das eine Tabelle erstellt, in der die Daten in Dateien im ORC-Format gespeichert werden. Wenn wir beispielsweise ORC mit Parquet in Hadoop vergleichen, bewerten wir tatsächlich die Qualität der Implementierung des in Hive implementierten Datenkonvertierungsalgorithmus. Wir vergleichen keine Formate (als solche).

Wichtiges Merkmal von Hadoop

In der klassischen relationalen Welt hatten wir keine Möglichkeit, die Größe der Tabelle in Oracle zu beeinflussen - sie wurde irgendwie gespeichert und nur Oracle wusste wie. In Hadoop ist die Situation etwas anders: Wir können sehen, wie diese oder jene Tabelle gespeichert ist (wie gut Hive es beispielsweise geschafft hat, sie zu „codieren“). Und wenn wir sehen, dass dies verbessert werden kann, haben wir eine echte Chance dafür: unsere eigene optimalere ORC-Datei zu erstellen und sie Hive als externe Tabelle zu geben.

Vergleichen Sie ORC und QVD

Ich habe kürzlich das QVD-Format beschrieben , das QlikVew / QlikSense aktiv verwendet. Lassen Sie uns diese beiden Formate kurz anhand der Funktionen veranschaulichen, die sie bieten, um eine maximale Lesegeschwindigkeit zu erreichen und die Größe zu minimieren. Die Funktionen von ORC sind oben wie in QVD beschrieben:

Spaltenspeicherung

QVD kann als "Spaltenformat" betrachtet werden, es gibt keine Duplizierung von Spaltenwerten - eindeutige Werte werden einmal gespeichert. ABER es erlaubt keine parallele Verarbeitung - zuerst müssen Sie die Werte aller Spalten vollständig lesen, dann können Sie Zeilen parallel lesen.

Und es gibt Duplikate auf Zeilenebene - Zeilen speichern doppelte Indexwerte in einer Zeichentabelle.

Komprimierung

Ich bin nicht auf komprimierte QVD-Dateien gestoßen - es ist mir nicht gelungen - es gibt ein solches Tag in den Metadaten, möglicherweise kann jeder der Teile, für die es einen Versatz und eine Länge in den Metadaten gibt (und dies ist jede Zeichentabelle und die gesamte Zeichenfolgentabelle), komprimiert werden. In diesem Fall ist ein paralleles Lesen der Zeilen "Auf Wiedersehen" ...

Indizes

In der QVD-Datei kann nicht verstanden werden, welcher Teil davon gelesen werden muss. In der Praxis müssen Sie die Zeichentabelle byteweise analysieren (jeweils!). Dies ist kein sehr effizienter Weg ...

Codierung

Die Codierung in QVD wird nicht verwendet. Es ist möglich, eine Analogie des Bitindex in einer Tabelle von Zeichenfolgen mit Codierung zu zeichnen. Diese Analogie wird jedoch durch Duplizieren von Zahlen durch Zeichenfolgen in Zeichentabellen „kompensiert“ (Einzelheiten siehe Artikel kurz - der Spaltenwert wird häufig durch die Zahl UND die Zeichenfolge dargestellt).

Die Schlussfolgerung zu diesem kurzen Vergleich habe ich persönlich gezogen: Das QVD-Format enthält praktisch nicht die Möglichkeit, die in Dateien dieses Formats enthaltenen Daten kompakt zu speichern und schnell zu lesen.

(Es klang für QVD irgendwie anstößig, ich möchte ein wenig hinzufügen - das Format wurde vor langer Zeit erstellt, nur QlikView / QlikSense wird verwendet und sie "speichern" alle Daten im Speicher. Ich denke, dass die QVD-Datei einfach alle "wie sie ist" im Speicher gelesen wird. und dann arbeiten diese in jeder Hinsicht wunderbaren BI-Produkte sehr schnell mit dieser Präsentation - hier sind sie Meister ...)

Anstelle einer Schlussfolgerung

Er kritisierte und hat noch nichts angeboten ... - schlage ich vor.

Es scheint mir, dass Formate nicht am Beispiel ihrer spezifischen Implementierung verglichen werden müssen, sondern dass Formate im Hinblick auf die darin enthaltenen Tools und die Fähigkeit, diese Tools zur Lösung unserer spezifischen Probleme zu verwenden, verglichen werden müssen. Die Geschwindigkeit der Prozessoren nimmt ständig zu. Jetzt können wir uns fast alle Datenkonvertierungsalgorithmen leisten, nachdem sie gelesen wurden. Das Lesen von der Festplatte ist ohnehin langsamer. Deshalb sind die "Ausdrucksmittel" der Formate wichtig.

Oben habe ich meiner Meinung nach kurz interessante Möglichkeiten des ORC-Formats aufgelistet. Ich habe immer noch keine Statistiken darüber, wie die Dinge in der Praxis sind (welche dieser Funktionen und in welchem ​​Umfang werden sie beispielsweise von Hive verwendet). Wenn es erscheint - werde ich schreiben. Die unmittelbaren Pläne sehen eine ähnliche Überprüfung eines anderen beliebten Speicherformats vor - Parkett.

Nun - und abschließend - in der modernen Welt gibt es viele Informationen, leider ist ein Teil dieser Informationen zu oberflächlich. Wir werden nicht nachgeben, wir werden die Essenz betrachten.