von Kalpak Shah, Technischer Direktor

Jedes Technologieunternehmen speichert heute Protokolle für die zukünftige Verarbeitung. Der einfache Ratschlag ist, die Kompression zu verwenden und sicherzustellen, dass die Protokolle vollständig und für jedermann nutzbar sind. Aber in welchem Komprimierungsformat sollten diese Protokolldateien vorliegen? Es gibt eine verwirrende Vielzahl von Komprimierungsoptionen - LZ0, Snappy, Gzip, Bzip2 etc. und mehrere Formate, in denen Daten gespeichert werden können - Text, Binärformate wie Protokollpuffer, Avro, MessagePack etc. und hybride wie Sequenzdateien, RCFile, ORCFile etc.

Protokolldatei-Anwendungen

Jede Anwendung, die die Protokolldateien verwenden wird, wird als Protokolldateianwendung bezeichnet. Eine große Anzahl von Unternehmen nutzt mittlerweile "Big Data Technologies" wie Hadoop, NoSQL, Hive etc. Das Format der Protokolldateien sollte daher eine einfache Verarbeitung ohne übermäßige Anforderungen an ihre breite Verwendung unterstützen.

Komprimierung

Nachfolgend finden Sie eine kurze Grafik von Yahoo darüber, wie die verschiedenen Komprimierungsalgorithmen im Komprimierungsverhältnis zur Komprimierungs-/Dekomprimierungszeit stehen.

Wie Sie sehen können, haben die schnelleren Kompressionsalgorithmen schlechtere Kompressionsverhältnisse. Für die Speicherung von Protokolldateien, die einmal geschrieben und dann mehrfach verwendet werden, schlägt die Dekompressionszeit jedes Mal ein, wenn die Protokolldateien zur Analyse oder von einer beliebigen Anwendung verwendet werden.

Eine weitere Anforderung, die sich für Hadoop normalerweise ergibt, ist, dass gespeicherte Protokolldateien aufteilbar sein müssen. Dies geschieht, damit mehrere Mapper gleichzeitig daran arbeiten können. Betrachten wir die verschiedenen Kompressionsalgorithmen, um zu sehen, ob sie teilbar sind oder nicht:

Wie du sehen kannst, ist nur bzip2 teilbar. Bedeutet das, dass wir alle Protokolldateien mit bzip2 komprimieren sollten? Es ist teilbar und hat eine sehr hohe Kompressionsrate, aber der Kompromiss ist, dass jede Anwendung, die diese Protokolldateien verwenden muss, auch eine sehr hohe CPU-Zeit für die Dekompression benötigt. Um dem hohen CPU-Zeitbedarf entgegenzuwirken, steht ein neues Format - der LZMA-Algorithmus - zur Verfügung, der Dateien in der Erweiterung .xz kodiert. Der Linux-Kernel ist jetzt im.xz-Format anstelle von.bzip2 verfügbar. LZMA bietet ein ähnliches Kompressionsverhältnis wie bzip2 und ist zudem sehr schnell.

Das Problem dabei ist, dass bzip2 nicht sehr beliebt ist, und .xv ist noch weniger. Anwendungen müssen Codes finden, um dies zu unterstützen, was je nach Ihrer Umgebung problematisch sein kann.

Containerformate

Es gibt eine Reihe anderer Formate, die in Ihrer Forschung auftauchen werden, und unten finden Sie eine schnelle Zusammenfassung.

Hadoop verwendet Sequence Files (und Map Files) für ein Binärformat, das teilbar ist. Der Hauptanwendungsfall ist es, mehrere kleinere Dateien in größere Sequenzdateien zu überführen. Hive verwendet sowohl RCFile als auch ORCFile. Diese Formate sind für die Abfrage über mehrere Zeilen hinweg optimiert. Sie sind beide nach Zeilen gruppiert und haben innen ein spaltenartiges Layout. Die Komprimierung kann auf Zeilengruppen angewendet werden. Diese Formate sind großartig, wenn Ihr Hauptanwendungsfall beim Speichern von Protokolldateien die Analyse in Hive (oder seinen Derivaten) ist.

Universal-Binärformate wie Protocol Buffers, Avro und MessagePack sind binäre Serialisierungs-/Deserialisierungsformate und probbaly viel effizienter als nur plain json/text. Die meisten dieser Binärformate sind jedoch nicht teilbar und benötigen eine spezielle Unterstützung für Protokollanwendungen.

Text ist eines der beliebtesten Formate. Wir können die Protokolldateien im Text belassen und die Komprimierung so gestalten, dass sie Platz sparen.