большой объем данных во многих текстовых файлах - как обрабатывать?

Question

У меня есть большой объем данных (несколько терабайт) и накапливается ... Они содержатся во многих текстовых файлах с разделителями табуляции (каждый около 30 МБ). Основная задача состоит в том, чтобы считывать данные и агрегировать (суммирование/усреднение + дополнительные преобразования) по наблюдениям/строкам на основе ряда предикатных операторов, а затем сохранять вывод в виде текстовых, HDF5 или SQLite-файлов и т. Д. Обычно я использую R для таких задач, но я боюсь, что это может быть немного большим. Некоторые решения кандидаты должны

1. написать все это в C (или Fortran)
2. импортировать файлы (таблицы) в реляционной базы данных непосредственно и затем стянуть куски в R или Python (некоторые преобразований не поддаются для чистых решений SQL)
3. написать все это в Python

Would (3) быть плохой идеей? Я знаю, что вы можете обернуть C-подпрограммы в Python, но в этом случае, поскольку нет ничего вычислимого запретительного (например, оптимизационных процедур, требующих много итеративных вычислений), я думаю, что I/O может быть как узким местом, так и самим вычислением. Есть ли у вас рекомендации относительно дальнейших соображений или предложений? Спасибо

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

Answer 1

(3) не обязательно плохая идея - Python позволяет легко обрабатывать файл «CSV» (и, несмотря на то, что C для Comma, вкладка как разделитель так же удобна в обращении), и, конечно же, получает примерно столько же полосы пропускания в операциях ввода-вывода, сколько и на любом другом языке. Что касается других рекомендаций, то numpy, помимо быстрых вычислений (которые вам могут не понадобиться в соответствии с вашими утверждениями), обеспечивает очень удобные гибкие многомерные массивы, которые могут быть весьма полезны для ваших задач; и стандартный библиотечный модуль multiprocessing позволяет использовать несколько ядер для любой задачи, которая легко распараллеливается (важно, поскольку почти каждая машина в эти дни имеет несколько ядер ;-).

Answer 2

Посмотрите на Disco. Это легкий распределенный движок MapReduce, написанный примерно в 2000 строк Erlang, но специально разработанный для разработки Python. Он поддерживает не только работу с вашими данными, но и надежное хранение репликации. Они только что выпустили версию 0.3, которая включает в себя слой индексирования и базы данных.

Answer 3

Если у вас есть кластер машин, вы можете распараллелить свое приложение с помощью Hadoop Mapreduce. Хотя Hadoop написан на Java, он также может запускать Python. Вы можете проверить следующую ссылку для указателей при распараллеливании кода - PythonWordCount

Answer 4

Да. Ты прав! I/O будет стоить большую часть вашего времени обработки. Я не предлагаю вам использовать распределенные системы, такие как hadoop, для этой задачи.

Ваша задача может быть выполнена на скромной рабочей станции. Я не эксперт Python, я думаю, что он поддерживает асинхронное программирование. В F # /. Net платформа хорошо поддерживает это. Я когда-то выполнял работу по обработке изображений, загружал 20 тыс. Изображений на диск и преобразовывал их в векторы объектов, которые стоят всего несколько минут параллельно.

всего, загрузите и обработайте свои данные параллельно и сохраните результат в памяти (если малый), в базе данных (если большой).

Answer 5

С терабайтами вы все равно будете распараллелить свои чтения на многих дисках; так что может пойти прямо в Hadoop.

Используйте Pig или Hive для запроса данных; обе имеют широкую поддержку пользовательских преобразований, поэтому вы должны иметь возможность реализовать то, что вам нужно сделать, используя собственный код.

Answer 6

Хорошо, просто чтобы быть другим, почему бы не R?

• Вы, кажется, знаете, R, так что вы можете добраться до рабочего кода быстро
• 30 Мб файла не большой на стандартной рабочей станции с несколькими ГБ оперативной памяти
• read.csv() вариант read.table() может быть очень эффективным если вы указать типы столбцов через colClasses аргумент: вместо guestimating типов для преобразования, они будут обработаны эффективно
• узкого места здесь я/о с диска, и это то же самое для каждого языка
• R имеет multicore для настройки параллельной обработки на машинах с несколькими ядрами (похоже, многопроцессорность Python, похоже)
• Если вы хотите использовать «неудобно параллельную» структуру проблемы, R имеет несколько пакетов, которые хорошо подходят для обработки данных, параллельные задачи: например, snow и foreach могут быть развернуты только на одной машине или на сетевом оборудовании.

Answer 7

Когда вы говорите «накапливая», то решение (2) наиболее подходит для решения проблемы.
После первоначальной загрузки в базу данных вы только обновляете базу данных новыми файлами (ежедневно, еженедельно? Зависит от того, как часто вам это нужно).

В случаях (1) и (3) вам необходимо обрабатывать файлы каждый раз (что было сказано ранее как наиболее частое/ресурсоемкое), если вы не найдете способ сохранить результаты и обновить их новыми файлами.

Вы можете использовать R для обработки файлов из csv, например, в базу данных SQLite.

Answer 8

Мне повезло с использованием R с Hadoop на эластичной карте Amazon. С EMR вы платите только за компьютерное время, которое вы используете, и AMZN заботится о том, чтобы разворачивать и разворачивать экземпляры. Точно как структурировать работу в EMR действительно зависит от того, как структурирован ваш рабочий процесс анализа. Например, все записи, необходимые для одного задания, содержащегося полностью внутри каждого csv, или вам нужны биты из каждого csv для завершения анализа?

Вот некоторые ресурсы, которые могут оказаться полезными:

• Пит Skomoroch говорить о R and AMZN EMR on the AMZN discussion forum
• Мой блог о getting started with R and AMZN EMR
• Rhipe project стремится интегрировать R и Hadoop. Однако Rhipe не фокусируется на EMR, поэтому я еще не использовал его. Похоже, что он должен быть мостом для EMR.

Проблема, о которой я упоминал в своем сообщении в блоге, является скорее одной из привязанных к ЦП, а не привязанной к IO. Ваши проблемы больше ввода-вывода, но советы по загрузке библиотек и кеш-файлов могут быть полезны.

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