Estoy tratando de hacer un recuento de registros en un archivo gzip de 7,6 GB. Encontré algunos enfoques usando el zcatcomando.

$ zcat T.csv.gz | wc -l
423668947

Esto funciona, pero lleva demasiado tiempo (más de 10 minutos para obtener el recuento). Intenté algunos enfoques más como

$ sed -n '$=' T.csv.gz
28173811
$ perl -lne 'END { print $. }' < T.csv.gz
28173811
$ awk 'END {print NR}' T.csv.gz
28173811

Estos tres comandos se ejecutan bastante rápido pero dan un recuento incorrecto de 28173811.

¿Cómo puedo realizar un recuento de registros en un tiempo mínimo?

El sed,perl y los awkcomandos que se pueden mencionar correcta, pero todos ellos leer los comprimidos de datos y los recuentos de caracteres de nueva línea en eso. Estos caracteres de nueva línea no tienen nada que ver con los caracteres de nueva línea en los datos sin comprimir.

Para contar el número de líneas en los datos sin comprimir, no hay forma de descomprimirlos. Tu enfoque conzcat es el enfoque correcto y dado que los datos es tan grande, que va a tomar tiempo para descomprimirlo.

La mayoría de las utilidades que se ocupan de la gzipcompresión y la descompresión probablemente usarán las mismas rutinas de biblioteca compartida para hacerlo. La única forma de acelerarlo sería encontrar una implementación de las zlibrutinas que de alguna manera sean más rápidas que las predeterminadas, y reconstruir, por ejemplo, zcatpara usarlas.

Use unpigz.

La respuesta de Kusalananda es correcta, deberá descomprimir todo el archivo para escanear su contenido. /bin/gunziphace esto tan rápido como puede, en un solo núcleo. Pigz es una implementación paralela gzipque puede usar múltiples núcleos.

Lamentablemente, la descompresión de archivos en sí gzip normales no se puede paralelizar, pero pigzsí ofrece una versión mejorada gunzip, unpigzque hace el trabajo relacionado, como la lectura, la escritura, y la suma de control en un hilo separado. En algunos puntos de referencia rápidos, unpigzes casi el doble de rápido que gunzipen mi máquina Core i5.

Instale pigzcon su administrador de paquetes favorito y use en unpigzlugar de gunzip, o en unpigz -clugar de zcat. Entonces su comando se convierte en:

$ unpigz -c T.csv.gz | wc -l

Todo esto supone que el cuello de botella es la CPU, no el disco, por supuesto.

El problema con todas las tuberías es que esencialmente está duplicando el trabajo. No importa qué tan rápida sea la descompresión, los datos aún deben transferirse a otro proceso.

Perl tiene PerlIO :: gzip que le permite leer secuencias comprimidas directamente. Por lo tanto, podría ofrecer una ventaja incluso si su velocidad de descompresión puede no coincidir con la de unpigz:

#!/usr/bin/env perl

use strict;
use warnings;

use autouse Carp => 'croak';
use PerlIO::gzip;

@ARGV or croak "Need filename\n";

open my $in, '<:gzip', $ARGV[0]
    or croak "Failed to open '$ARGV[0]': $!";

1 while <$in>;

print "$.\n";

close $in or croak "Failed to close '$ARGV[0]': $!";

Lo probé con un archivo comprimido gzip de 13 MB (se descomprime a 1,4 GB) en un viejo MacBook Pro 2010 con 16 GB de RAM y un viejo ThinkPad T400 con 8 GB de RAM con el archivo ya en el caché. En la Mac, el script de Perl fue significativamente más rápido que el uso de tuberías (5 segundos frente a 22 segundos), pero en ArchLinux, perdió debido a la desconexión:

$ time -p ./gzlc.pl spy.gz 
1154737
real 4.49
usuario 4.47
sys 0.01

versus

$ time -p unpigz -c spy.gz | wc -l
1154737
real 3.68
usuario 4.10
sys 1.46

y

$ time -p zcat spy.gz | wc -l
1154737
real 6.41
usuario 6.08
sys 0.86

Claramente, el uso unpigz -c file.gz | wc -les el ganador aquí tanto en términos de velocidad. Y, esa simple línea de comando seguramente es mejor que escribir un programa, por breve que sea.

La respuesta de Kusalananda es mayormente correcta. Para contar líneas necesita buscar nuevas líneas. Sin embargo, es teóricamente posible buscar nuevas líneas sin descomprimir completamente el archivo.

gzip usa la compresión DEFLATE. DEFLATE es una combinación de codificación LZ77 y Huffman. Puede haber una manera de descubrir solo el nodo del símbolo de Huffman para la nueva línea e ignorar el resto. Es casi seguro que hay una forma de buscar nuevas líneas codificadas con L277, mantener un recuento de bytes e ignorar todo lo demás.

Entonces, en mi humilde opinión, es teóricamente posible encontrar una solución más eficiente que unpigz o zgrep. Dicho esto, ciertamente no es práctico (a menos que alguien ya lo haya hecho).

Se puede hacer usando zgrepcon -cbandera y $parámetro.

En este caso, -c indica al comando que muestre el número de líneas coincidentes y la expresión regular $ coincide con el final de línea para que coincida con cada línea o el archivo.

zgrep -c $ T.csv.gz 

Como se ha comentado por @ StéphaneChazelas - zgrepes solamente un guión alrededor zcaty grepy debe proporcionar un rendimiento similar a la sugerencia original dezcat | wc -l

Como puede ver, la mayoría de las respuestas intentan optimizar lo que puede: el número de cambios de contexto y la E / S entre procesos. La razón es que esto es lo único que puede optimizar aquí fácilmente.

Ahora el problema es que su necesidad de recursos es casi insignificante para la necesidad de recursos de la descompresión. Es por eso que las optimizaciones realmente no harán nada más rápido.

Donde realmente podría acelerarse, sería un algoritmo modificado de descompresión (es decir, descompresión), que excluye la producción real del flujo de datos descomprimido; más bien solo calcula el número de las nuevas líneas en el flujo descomprimido del comprimido . Sería difícil, requeriría un conocimiento profundo del algoritmo de gzip (alguna combinación de los algoritmos de compresión LZW y Huffman ). Es bastante probable que el algoritmo no permita optimizar significativamente el tiempo de descompresión con el rayo, que solo necesitamos saber los recuentos de nueva línea. Incluso si fuera posible, esencialmente se debería haber desarrollado una nueva biblioteca de descompresión gzip (no existe hasta que se sepa).

La respuesta realista a su pregunta es que no, no puede hacerlo significativamente más rápido.

Tal vez podría usar alguna descompresión paralela de gzip, si existe. Podría usar múltiples núcleos de CPU para la descompresión. Si no existe, podría desarrollarse con relativa facilidad.

Para el xz , existe un compresor paralelo (pxz).