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)?
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.
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 überspringtgsutil cat
die Dekompression: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.