Я думаю, вы можете найти несколько отличных лайнеров и сделать из них псевдонимы, но обычно, когда у вас есть несколько команд, сценарий лучше, потому что он более гибкий, надеюсь, более читаемый, и вы можете расширить его функциональность позже намного проще, если вы скажете: «О! Я также должен заставить это сделать x ...». Итак, вот один из способов сделать это:
#!/bin/bash
# Add filepath to first line of file
myFile="file.dat"
filePath=`pwd`
tmpFile="tmpFile"
cp $myFile $tmpFile
echo $filePath | cat - $tmpFile > $myFile
rm $tmpFile
exit 0
Не забудьте сделать его исполняемым: chmod u + x addPath.sh
(предполагается, что вы сохранили приведенный выше сценарий в файл addPath.sh
).
Ваши требования (, так что запасная оперативная память/хранилище/облако )сделают это очень медленным, но это возможно, написав собственный драйвер файловой системы. Однако, если у вас есть время/навыки для этого, будет быстрее/дешевле арендовать/купить/продать/вернуть диск емкостью 2 ТБ за 37 долларов и использовать
.https://en.m.wikipedia.org/wiki/External_sorting
Обходным решением может быть сжатие zram и/или 7z/fs -, если файл сжимаемый, вы можете освободить место для второй копии
https://en.m.wikipedia.org/wiki/Zram
https://en.m.wikipedia.org/wiki/Category:Compression_file_systems
Если есть место для вывода без удаления ввода и ввод предварительно -отсортирован, то это тривиально.
Разве это не подходит для Spark в файловой системе Hadoop? Я предлагаю вам получить Apache Zeppelin (, который представляет собой блокнот в стиле Jupyter для Spark ), и начать играть с некоторыми учебными пособиями. Spark — это путь к большим данным.
Проведя сегодня еще несколько экспериментов с различными данными, я полагаю, что нашел проблему :по умолчанию, сортировка (BSD )будет открывать только 16 файлов одновременно (справочная страница, по-видимому, подразумевает сюда входят как входные, так и временные файлы ).
Переключатель --batch -size= позволяет увеличить это значение.
Использование предварительно -отсортированных файлов размером 100 МБ:
sort -u -m <...15 имен файлов...>
sort -u -m <...16 имен файлов...>
sort--batch -size=20-u -m <...16 имен файлов...>
Обратите внимание, что мне не удалось проверить это на исходных данных, но я почти уверен, что проблема именно в этом.
Надеюсь, это поможет кому-то с такой же проблемой.
Я думаю, что вы ищете comm
. Я не уверен, сколько памяти или временного пространства он использует, но, учитывая требование сортировки входных файлов и то, что люди, которые пишут эти утилиты, не глупы, могу поспорить, что это действительно эффективно.
Вы можете удалить дубликаты с помощью uniq
, так как это также предполагает отсортированный ввод.
У меня возникла похожая проблема, когда я пытался решить очень большую головоломку с выдвижным блоком. На данный момент мне нужно слить около 100 отсортированных файлов, каждый из которых содержит около 60 миллионов позиций и занимает 15 гигабайт. Файлы сортируются индивидуально без дубликатов, но разные файлы могут иметь одну и ту же запись. Я написал утилиту на C++, которая в основном открывает все файлы и читает по одной записи от каждого. На каждом шаге он находит самую раннюю по алфавиту запись (с помощью сортировки SHELL )и записывает эту запись. Он считывает следующую запись из этого файла и любых других файлов, в которых также есть такая же запись.Он работал в течение 5 часов на новом ноутбуке MAC, чтобы получить ответ. Требования к памяти невелики, и каждый файл читается только один раз. Он работает намного быстрее, чем решение для связи, которое ограничено двумя файлами одновременно и предполагает многократное чтение файлов.