Gsutil: Wie kann man gsutil cp-Gzip-Dateien verwenden, ohne sie zu dekomprimieren?

Erstellt am 11. Apr. 2018  ·  5Kommentare  ·  Quelle: GoogleCloudPlatform/gsutil

Wenn ich die GCS-Dokumentation zur dekomprimierenden Transkodierung lese, verstehe ich, dass die einzige Möglichkeit zum Abrufen einer auf GCS gespeicherten gzip-Datei mit Content-Encoding: gzip im komprimierten Zustand darin besteht, den "Accept-Encoding: gzip" Header bei der Anforderung zu übergeben.

Beim Versuch, dies mit gsutil zu tun, erhalte ich einen Fehler:

$ gsutil ls -L gs://xxx/0.json.gz | grep 'Content-'
    Content-Encoding:       gzip
    Content-Length:         129793
    Content-Type:           text/plain
$ gsutil -h "Accept-Encoding: gzip" cp gs://xxx/0.json.gz .
ArgumentException: Invalid header specified: accept-encoding: gzip

(Ich weiß, dass dieses Beispiel wahrscheinlich schlecht ist; die Erweiterung sollte nicht explizit auf .gz aber ich muss jetzt damit arbeiten)

Ich vermute, dass gsutil eine clientseitige Dekompression durchführt (wie in der gsutil cp Dokumentation vorgeschlagen) und somit verhindert, dass der Accept-Encoding Header übergeben wird.

Meine Frage ist dann, wie ich gsutil , um eine gzip-Datei herunterzuladen, deren Metadaten auf Content-Encoding: gzip ohne sie zu dekomprimieren (und ohne andere Metadaten wie Cache-control: no-transform wenn das wäre ein Workaround)?

Feature Request

Hilfreichster Kommentar

Es sieht nicht so aus, als ob es eine Möglichkeit gibt, das Verhalten der automatischen Dekompression für gsutil cp zu deaktivieren. Für einmalige Anwendungsfälle überspringt gsutil cat die Dekompression:

$ gsutil cat gs://bucket/obj.gz > /destination/path/obj.gz

Aber mir ist klar, dass es sehr langsam und mühsam ist, für jedes Objekt wie dieses einen separaten Aufruf von gsutil auszuführen. Wir sollten eine Art Verhalten bereitstellen, um die automatische Dekompression beim Herunterladen von Objekten über cp/mv/rsync zu verhindern.

Alle 5 Kommentare

Es sieht nicht so aus, als ob es eine Möglichkeit gibt, das Verhalten der automatischen Dekompression für gsutil cp zu deaktivieren. Für einmalige Anwendungsfälle überspringt gsutil cat die Dekompression:

$ gsutil cat gs://bucket/obj.gz > /destination/path/obj.gz

Aber mir ist klar, dass es sehr langsam und mühsam ist, für jedes Objekt wie dieses einen separaten Aufruf von gsutil auszuführen. Wir sollten eine Art Verhalten bereitstellen, um die automatische Dekompression beim Herunterladen von Objekten über cp/mv/rsync zu verhindern.

Danke für deine Antwort. Ich denke, in der Dokumentation könnte auch die Tatsache erwähnt werden, dass gsutil den Accept-Encoding Header erzwingt (wenn ich richtig liege), da der Fehler auf den ersten Blick einfach etwas seltsam aussieht.

Die Verwendung von Cache-Control: no-transform hilft nicht, da das Herunterladen ( cp oder rsync von der Cloud nach lokal) nur basierend auf Content-Encoding: gzip automatisch dekomprimiert wird (metadata_util.py, ObjectIsGzipEncoded und Verwendungen).

Ich denke, die automatische Dekompression ist aktiv, damit cp -z für Up- und Download "wie erwartet" funktioniert (zB #42), obwohl argumentiert werden könnte, dass cp -z im Wesentlichen ein gzip Operation, und ein bloßes cp sollte _immer_ kopieren, nicht gunzip automatisch (vgl. die tar -cz und tar -xz Symmetrie).

Für rsync ist die automatische Dekompression besonders problematisch, bedenken Sie:

1) Erstellen Sie ein Verzeichnis mit einer einzigen, vorkomprimierten Datei
mkdir local
echo "compress me" | gzip -c > local/precompressed
2) Lokal mit Remote synchronisieren
rsync -r local/ gs://somewhere/remote/
3) Stellen Sie die geeignete Kodierung auf vorkomprimiert ein
setmeta -h 'content-encoding:gzip' gs://somewhere/remote/precompressed
4) Fernbedienung synchronisieren
rsync -r gs://somewhere/remote/ local/
5) Beachten Sie, dass nichts kopiert wird
Building synchronization state...
Starting synchronization...
6) jetzt die lokale vorkomprimierte Datei ändern
echo "compress me differently" | gzip -c > local/precompressed
7) und synchronisiere die Fernbedienung erneut
rsync -r gs://somewhere/remote/ local/
8) Beachten Sie, dass vorkomprimierte Dateien synchronisiert und automatisch dekomprimiert werden
Building synchronization state...
Starting synchronization...
gs://somewhere/remote/precompressed has a...
Copying gs://somewhere/remote/precompressed...
Downloading to temp gzip filename...
...
9) und synchronisiere die Fernbedienung noch einmal
rsync -r gs://somewhere/remote/ local/
10) Beachten Sie die gleichen Meldungen wie oben in 8), da local/precompressed _uncompressed_ ist und remote/precompressed nicht - sie unterscheiden sich
11) 9) und 10) bis ins Unendliche wiederholen

Fazit: Eine Option zum Abschalten der automatischen Dekompression wäre sehr hilfreich.

Hallo :)

Irgendein Update zu diesem?

Es ist ziemlich unpraktisch, wenn Sie mit vielen gzip-Dateien in einer Data-Science-Umgebung arbeiten (das entspricht mehreren TB im gzip-Format).
Ich habe im Moment keinen guten Workaround gefunden (ich werde die Cat-Version ausprobieren, aber das Fehlen von md5sum-Checks könnte zu anderen Problemen führen :/)

Vielleicht kennen Sie ein Skript mit der Python-API (oder einer anderen Sprache), das dies tut?

Danke.

PS (Bearbeiten): Nachdem ich den Code nachgeschlagen hatte, fand ich https://github.com/hackersandslackers/googlecloud-storage-tutorial/blob/master/main.py . Ich habe dieses mit raw_download=True für download_to_filename verwendet und es funktioniert, aber a priori langsamer als gsutil. (was ein Problem mit der großen Datenmenge ist, die ich übertragen muss)

Wenn Sie *.gz Dateien mit Content-Encoding: gzip Metadaten haben und alle Dateien herunterladen möchten?

Schreckliche "Lösung":

Verwenden Sie stattdessen http://rclone.org/ mit dem Befehl: rclone sync oder rclone copy und übergeben Sie --header-download "Accept-Encoding: gzip" .
Es lädt die ursprüngliche .gz-Datei herunter und dekomprimiert die Datei nicht.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen