rPman

wc
утилита командной строки, часть coreutils любого linux - в один поток считает количество строк/слов/символов в текстовых файлах

разделение слов в файле с помощью xargs, сортировка sort, подсчет уникальных слов uniq -c
cat file | xargs -n 1 | sort | uniq -c

если файлы упакованы, распаковка запускается параллельно с помощью потоков (команда распаковки в stdout | wc )

parallel (одноименный пакет linux) - позволяет максимально просто запускать параллельно несколько процессов (список команд указываются в stdin, по мере необходимости они читаются и запускаются)

На нескольких нодах запускай команду сам.

Итого, любым языком программирования подготавливаешь список команд, обрабатывающих текстовые данные по частям (с учетом их размещения на разных носителях, так как обычно именно они часто являются самым узким местом тут), скармливаешь его parallel и так же своими утилитами читаешь логи на предмет ошибок и результатов.

типа такого:

for a in *.zst;do echo "zstd -d --stdout $a |(printf \"%s\\t\" $a;wc)";done | parallel -j 5

данный код выводит по строчкам имя архива zstd со сжатым текстом и 3 числа, количество строк, слов и символов, параллельно запуская распаковку и подсчет символов в 5 потоков, утилизируя 12 ядер (12-gen intel) по максимуму посчитав 38гб несжатых (4.4гб сжатых) коротких json-файлов (построчно записаны в кучу файлов) за 121сек (узкое место тут распаковка)

Извиняюсь за неекропост

4000 колонок * 20кк строк * 1 байт значение (даже не надо в биты упаковывать, та ккак у вас 4 варианта значений)
это 80,000,000,000 байт, т.е. считанные 80 гигабайт данных в виде матрицы

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

которые при генерации отчета как либо аггрегируются.

это чуть ли не наисложнейшая задача для баз данных, 80м записей тем более

Партицируйте прямо по суткам.

Убирайте транзакции, нафиг вам тут innodb когда хватит myisam, оно на запись быстрее, у вас база write once read ... тоже once.

У вас там база данных упирается случайно не в работу с диском? в облаке можно взять несколько дисков, они будут независимыми, раскидай по ним таблицы (myisam штатно поддерживает симлинки), что может дать прирост в скорости в разы только за счет этого, даже если они ssd, например отделить хранение индексов от данных или отделить старые данные от сегодняшних.

На время обработки аналитики можно потюнить файловую систему и отключить flush для файлов таблиц (например ext4 data writeback и можно отключить журнал) - сильно ускоряет именно запись, особенно если много ram, это включает большой риск потери/порчи данных при сбросе ос но с другой стороны вероятность этого очень мала и как я понимаю, данные в базу и так пишутся из какого то другого хранилища, т.е. при проблеме с сервером просто перезапускается обработка за текущие сутки.

Уберите индексы на запись, все, сначала пусть идет вставка данных без их индексации, затем создаете индекс (это на порядок быстрее) и уже потом строите аналитику.

Общая аналитика должна не работать с самими данными, а с их посуточной выжимкой (возможно в результате и хранить их не придется) считай это самодельные индексы. Грубо говоря если в запросе на аналитику стоит count,max,min,.. то достаточно сложить посуточные значения и для глобальных считать уже по ним... само собой если запросы с условиями и сложными группировками, то надо думать но все решаемо.. грубый пример нужно считать агрегацию по часам, вот в индексы и пиши суточные значения по часам, а если надо постранично то для каждой страницы для каждых суток считаешь, потом агрегируешь уже по этим результатам.

Само понятие 'большие данные' подразумевает что данных ТАК МНОГО что обычные подходы и инструменты не катят.

Например (все цифры от балды, только чтобы показать порядок проблемы), вам надо обработать логи вашего веб сервера, ваши скрипты перелопачивают данные за сутки посещаемости - за пол часа на вашем домашнем компьютере. А теперь попробуйте обработать логи какого-нибудь avito или яндекс, даже нагрузив все ваши домашние компьютеры, телефоны, роутеры, компьютеры ваших друзей, родни и даже компы в вашем классе, ваш скрипт все равно не будет успевать их обрабатывать, так как их будет поступать больше на порядок.

Это и есть big data.

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

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