Рабочий процесс разработки функций большого набора данных Python с использованием dask hdf / parquet

Об этом уже есть хороший вопрос в SO, но лучший ответ Сейчас ему 5 лет, поэтому я думаю, что в 2018 году должны быть варианты получше.

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

Исходный файл - это CSV, который не помещается в памяти. Вот мои потребности:

  1. Создавайте функции (в основном, используя групповые операции с несколькими столбцами).
  2. Объедините новую функцию с предыдущими данными (на диске, потому что они не помещаются в памяти)
  3. Используйте подмножество (или все) столбцы / индекс для некоторых приложений машинного обучения
  4. Повторите 1/2/3 (это итеративный процесс, такой как день 1: создание 4 функций, день 2: создание еще 4 ...)

Попытка с паркетом и dask:

Сначала я разделил большой CSV-файл на несколько маленьких паркетных файлов. При этом dask очень эффективен для вычисления новых функций, но затем мне нужно объединить их с исходным набором данных и atm, мы не можем добавлять новые столбцы в файлы parquet. Чтение CSV по частям, слияние и повторное сохранение в несколько паркетных файлов занимает слишком много времени, поскольку разработка функций в этом проекте является итеративным процессом.

Попытка HDF и dask:

Затем я обратился к HDF, потому что мы можем добавлять столбцы, а также использовать специальные запросы, и это все еще хранилище двоичных файлов. Я снова разделил большой файл csv на несколько HDF с тем же ключом = 'base' для базовых функций, чтобы использовать одновременную запись с DASK (не разрешено HDF).

data = data.repartition(npartitions=10) # otherwise it was saving 8Mo files using to_hdf
data.to_hdf('./hdf/data-*.hdf', key='base', format='table', data_columns=['day'], get=dask.threaded.get)

(Очередь приложения: указание data_columns для dask кажется бесполезным, поскольку в dask.read_hdf нет where?)

В отличие от того, что я ожидал, я не могу объединить новую функцию с несколькими небольшими файлами с таким кодом:

data = dd.read_hdf('./hdf/data-*.hdf', key='base')
data['day_pow2'] = data['day']**2
data['day_pow2'].to_hdf('./hdf/data-*.hdf', key='added', get=dask.threaded.get) 

с dask.threaded я получаю, что python перестал работать после 2%. С dask.multiprocessing.get это занимает вечность и создает новые файлы

Какие инструменты (хранение и обработка) наиболее подходят для этого рабочего процесса?


person Florian Mutel    schedule 29.03.2018    source источник
comment
Я бы серьезно подумал об использовании базы данных в качестве хранилища ...   -  person MaxU    schedule 29.03.2018


Ответы (2)


Я просто сделаю копию комментария из связанной проблемы на fastparquet: это Технически возможно добавить столбцы в существующие наборы данных паркета, но это не реализовано в fastparquet и, возможно, не в любой другой реализации паркета.

Создание кода для этого может быть не слишком обременительным (но в настоящее время это не планируется): вызовы столбцы записи происходят последовательно, поэтому новые столбцы для записи должны будут передаваться этой функции вместе с позицией файла, соответствующей текущему первому байту метаданных в нижнем колонтитуле. Кроме того, схему нужно будет обновить отдельно (это просто). Этот процесс необходимо будет повторить для каждого файла набора данных. Это не «ответ» на вопрос, но, возможно, кто-то захочет взять на себя эту задачу.

person mdurant    schedule 01.04.2018

Я бы серьезно рассмотрел возможность использования базы данных (индексированный доступ) в качестве хранилища или даже использования Apache Spark (для обработки данных распределенным / кластерным способом) и Hive / Impala в качестве бэкэнда ...

person MaxU    schedule 29.03.2018
comment
Я работаю в локальной настройке, без доступа к кластеру. Подойдет ли SQLite? Боюсь за время чтения / записи - person Florian Mutel; 29.03.2018
comment
@FlorianMutel, я бы попробовал хотя бы MySQL - он больше подходит для БД, которая не помещается в вашу оперативную память ... - person MaxU; 29.03.2018
comment
postgresql кажется наиболее распространенным для решений с открытым исходным кодом. Однако вы добавляете столбцы, то есть развиваете схему, что является сложной операцией для традиционных баз данных. - person mdurant; 01.04.2018