Estou tentando fazer uma contagem de registros em um arquivo gzip de 7,6 GB. Encontrei poucas abordagens usando o zcatcomando

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

Isso funciona, mas leva muito tempo (mais de 10 minutos para obter a contagem). Eu tentei mais algumas abordagens como

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

Todos esses três comandos estão executando muito rapidamente, mas fornecendo uma contagem incorreta de 28173811.

Como posso executar uma contagem de registros em um período mínimo de tempo?

Os comandos sed, perle awkque você mencionou podem estar corretos, mas todos lêem os dados compactados e contam caracteres de nova linha. Esses caracteres de nova linha não têm nada a ver com os caracteres de nova linha nos dados descompactados.

Para contar o número de linhas nos dados não compactados, não há como contorná-los. Sua abordagem com zcaté a abordagem correta e desde que os dados é tão grande, ele vai ter tempo para descomprimir.

A maioria dos utilitários que lida com gzipcompactação e descompactação provavelmente usará as mesmas rotinas de biblioteca compartilhada para fazer isso. A única maneira de acelerar isso seria encontrar uma implementação das zlibrotinas que sejam de algum modo mais rápidas que as padrão e reconstruir, por exemplo, zcatpara usá-las.

Use unpigz.

A resposta de Kusalananda está correta, você vai precisar para descompactar o arquivo inteiro para digitalizar seu conteúdo. /bin/gunzipfaz isso o mais rápido possível, em um único núcleo. Pigz é uma implementação paralela gzipque pode usar múltiplos núcleos.

Infelizmente, o próprio descompressão de arquivos gzip normais não pode ser paralelizado, mas pigznão oferecem uma versão melhorada gunzip, unpigzque faz trabalhos relacionados, tais como a leitura, escrita e checksumming em um segmento separado. Em alguns benchmarks rápidos, unpigzé quase o dobro da velocidade gunzipda minha máquina core i5.

Instale pigzcom seu gerenciador de pacotes favorito e use em unpigzvez de gunzipou em unpigz -cvez de zcat. Portanto, seu comando se torna:

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

Tudo isso pressupõe que o gargalo é a CPU, não o disco, é claro.

O problema com todos os pipelines é que você está basicamente dobrando o trabalho. Não importa a rapidez da descompressão, os dados ainda precisam ser transferidos para outro processo.

O Perl possui o PerlIO :: gzip, que permite ler diretamente os fluxos compactados em gzip. Portanto, ele pode oferecer uma vantagem, mesmo que sua velocidade de descompressão não corresponda à 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]': $!";

Eu tentei com um arquivo compactado em gzip de 13 MB (descompacta para 1,4 GB) em um antigo MacBook Pro 2010 com 16 GB de RAM e um ThinkPad T400 antigo com 8 GB de RAM com o arquivo já no cache. No Mac, o script Perl era significativamente mais rápido do que o uso de pipelines (5 segundos vs 22 segundos), mas no ArchLinux, ele perdia a desvantagem:

$ time -p ./gzlc.pl spy.gz 
1154737
real 4,49
usuário 4.47
sys 0,01

versus

$ time -p unpigz -c spy.gz | wc -l
1154737
real 3,68
usuário 4.10
sys 1,46

e

$ time -p zcat spy.gz | wc -l
1154737
real 6,41
usuário 6.08
sys 0.86

Claramente, o uso unpigz -c file.gz | wc -lé o vencedor aqui, tanto em termos de velocidade. E essa linha de comando simples certamente supera a escrita de um programa, por mais curto que seja.

A resposta de Kusalananda é principalmente correta. Para contar linhas, você precisa procurar novas linhas. No entanto, é teoricamente possível procurar novas linhas sem descompactar completamente o arquivo.

O gzip usa a compactação DEFLATE. DEFLATE é uma combinação de codificação LZ77 e Huffman. Pode haver uma maneira de descobrir apenas o nó do símbolo Huffman para nova linha e ignorar o resto. Quase certamente existe uma maneira de procurar novas linhas codificadas usando o L277, manter uma contagem de bytes e ignorar todo o resto.

Então, IMHO é teoricamente possível encontrar uma solução mais eficiente que unpigz ou zgrep. Dito isto, certamente não é prático (a menos que alguém já tenha feito isso).

Pode ser feito usando zgrepcom -cflag e $parâmetro.

Nesse caso, -c instrua o comando a gerar o número de linhas correspondentes e o regex $ corresponde ao final da linha, de forma que corresponda a todas as linhas ou arquivos.

zgrep -c $ T.csv.gz 

Como comentado por @ StéphaneChazelas - zgrepsó é um script em torno zcate grepe deve proporcionar um desempenho semelhante ao sugestão original dezcat | wc -l

Como você pode ver, a maioria das respostas tenta otimizar o que pode: o número de alternâncias de contexto e E / S entre processos. O motivo é que esse é o único que você pode otimizar aqui facilmente.

Agora, o problema é que sua necessidade de recursos é quase insignificante para a necessidade de recursos da descompressão. É por isso que as otimizações realmente não tornam nada mais rápido.

Onde poderia ser realmente acelerado, seria um algoritmo un-gzip (isto é, descompressão) modificado, que deixa de fora a produção real do fluxo de dados descompactado; em vez disso, apenas calcula o número das novas linhas do fluxo descomprimido do comprimido um. Seria difícil, exigiria o conhecimento profundo do algoritmo do gzip (alguma combinação dos algoritmos de compressão LZW e Huffman ). É bem provável que o algoritmo não permita otimizar significativamente o tempo de descompressão com o raio, que precisamos apenas conhecer a contagem da nova linha. Mesmo que fosse possível, essencialmente uma nova biblioteca de descompactação gzip deveria ter sido desenvolvida (ela não existe até que seja conhecida).

A resposta realista para sua pergunta é que não, você não pode torná-la significativamente mais rápida.

Talvez você possa usar alguma descompressão paralela ao gzip, se existir. Ele pode usar vários núcleos da CPU para a descompressão. Se não existir, poderia ser desenvolvido com relativa facilidade.

Para o xz , existe um compressor paralelo (pxz).