Я пытаюсь подсчитать количество записей в 7,6 ГБ gzip-файле. Я нашел несколько подходов, используя zcatкоманду.

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

Это работает, но это занимает слишком много времени (более 10 минут, чтобы получить счет). Я попробовал еще несколько подходов, таких как

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

Все три из этих команд выполняются довольно быстро, но дают неправильный счет 28173811.

Как я могу выполнить подсчет записей за минимальное количество времени?

В sed, perlи awkкоманды , которые вы упоминаете могут быть правильными, но они все прочитать сжатые данные и рассчитывает символы новой строки в этом. Эти символы новой строки не имеют ничего общего с символами новой строки в несжатых данных.

Чтобы посчитать количество строк в несжатых данных, нет никакого способа их разархивировать. Ваш подход с zcatправильным подходом и поскольку данные настолько велики, что будет время , чтобы разархивировать его.

Большинство утилит, которые имеют дело со gzipсжатием и распаковкой, скорее всего, будут использовать для этого одни и те же подпрограммы совместно используемых библиотек. Единственный способ ускорить его - найти реализацию zlibподпрограмм, которые как-то быстрее, чем стандартные, и перестроить, например, zcatдля их использования.

Используйте unpigz.

Ответ Kusalananda является правильным, вам будет нужно распаковывать , что весь файл для проверки его содержимого. /bin/gunzipделает это так быстро, как может, на одном ядре. Pigz - это параллельная реализация, gzipкоторая может использовать несколько ядер.

К сожалению, декомпрессия сам нормальных GZIP файлов не может быть распараллеливание, но pigzделает предложение улучшенную версию gunzip, unpigz, что делает соответствующую работу , такие как чтение, запись и контрольную сумму в отдельном потоке. В некоторых быстрых тестах unpigzэто почти в два раза быстрее, чем gunzipна моей базовой машине i5.

Установите pigzс вашим любимым менеджером пакетов и используйте unpigzвместо gunzipили unpigz -cвместо zcat. Итак, ваша команда становится:

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

Все это предполагает, что узким местом является процессор, а не диск, конечно.

Проблема со всеми конвейерами в том, что вы по сути дела удваиваете работу. Независимо от того, насколько быстро выполняется декомпрессия, данные все равно необходимо перенести в другой процесс.

Perl имеет PerlIO :: gzip, который позволяет вам читать gzip-потоки напрямую. Следовательно, он может предложить преимущество, даже если его скорость распаковки может не соответствовать скорости 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]': $!";

Я попытался сделать это с помощью сжатого файла gzip 13 МБ (распаковывается до 1,4 ГБ) на старом MacBook Pro 2010 года с 16 ГБ оперативной памяти и старом ThinkPad T400 с 8 ГБ оперативной памяти, где файл уже находится в кеше. На Mac скрипт Perl был значительно быстрее, чем при использовании конвейеров (5 секунд против 22 секунд), но в ArchLinux он проиграл unpigz:

$ time -p ./gzlc.pl spy.gz 
1154737
настоящий 4.49
пользователь 4.47
система 0,01

против

$ time -p unpigz -c spy.gz | туалет
1154737
реальный 3,68
пользователь 4.10
система 1,46

и

$ time -p zcat spy.gz | туалет
1154737
настоящий 6.41
пользователь 6.08
система 0,86

Понятно, что использование здесь unpigz -c file.gz | wc -lявляется победителем в плане скорости. И эта простая командная строка наверняка превосходит написание программы, пусть даже короткой.

Ответ Кусалананды в основном правильный. Для подсчета строк вам нужно искать новые строки. Однако теоретически можно искать новые строки без полного распаковки файла.

gzip использует сжатие DEFLATE. DEFLATE представляет собой комбинацию кодировки LZ77 и Хаффмана. Может быть способ вычислить только символьный узел Хаффмана для новой строки и игнорировать все остальное. Почти наверняка есть способ искать строки, закодированные с использованием L277, вести подсчет байтов и игнорировать все остальное.

Так что ИМХО теоретически возможно придумать решение более эффективное, чем unpigz или zgrep. Это, как говорится, конечно, не практично (если кто-то уже не сделал это).

Может быть сделано с помощью zgrepс -cфлагом, и $параметром.

В этом случае -c дает команду команде вывести количество совпавших строк, а регулярное выражение $ соответствует концу строки, чтобы оно соответствовало каждой строке или файлу.

zgrep -c $ T.csv.gz 

Как прокомментировал @ StéphaneChazelas - zgrepэто всего лишь сценарий вокруг zcatи grepи она должна обеспечивать одинаковую производительность с первоначальным предложениемzcat | wc -l

Как видите, большинство ответов пытается оптимизировать то, что может: количество переключений контекста и межпроцессный ввод-вывод. Причина в том, что это единственное, что вы можете легко оптимизировать здесь.

Теперь проблема заключается в том, что потребность в ресурсах практически не зависит от потребности в декомпрессии. Вот почему оптимизация не сделает ничего быстрее.

Там, где это могло бы быть действительно ускорено, это был бы модифицированный алгоритм un-gzip (то есть декомпрессии), который исключал бы фактическое получение распакованного потока данных; скорее он только вычисляет количество новых строк в распакованном потоке из сжатого . Это было бы сложно, это потребовало бы глубокого знания алгоритма gzip (некоторая комбинация алгоритмов сжатия LZW и Хаффмана ). Вполне вероятно, что алгоритм не позволяет существенно оптимизировать время декомпрессии с молнией, нам нужно только знать количество строк новой строки. Даже если бы это было возможно, по сути, должна была быть разработана новая библиотека для распаковки gzip (она не существует, пока не узнают).

Реальный ответ на ваш вопрос таков: нет, вы не можете сделать это значительно быстрее.

Может быть, вы могли бы использовать распакованную распаковку gzip, если она существует. Он может использовать несколько процессорных ядер для распаковки. Если он не существует, он может быть относительно легко разработан.

Для xz существует параллельный компрессор (pxz).