Идея дизайна для инструмента инвентаризации дизайна

Question

Я разрабатываю инструмент для анализа транзакций с использованием Python, с pandas и Out of core. Здесь будут большие данные (от 2 до 200 ГБ), поэтому я использую Dask.

В моей таблице SKU, STORE, DATE_BY_DAY, SOLD_PRICE, ORDER_VOLUME, INVENTORY_LEVEL. Я использую формат паркета, разбитый по магазинам (разделы будут слишком маленькими если я разделю его по sku).

Я хочу получать быстрые запросы с очень низкой задержкой (в основном только некоторые агрегации и фильтры по SKU и хранилищам). Проблема в том, что я должен сделать это все на лету. Кроме того, я должен рассчитать уровень запасов (INVENTORY_LEVEL) для каждого дня на основе текущего инвентаря (это на другой таблице), а также переиндексировать по дате, поскольку в исходном файле может быть несколько пропущенных дней.

Dask не поддерживает мультииндексацию, а сортировка очень дорогая, поэтому она слишком трудна и медленна для выполнения упомянутых вычислений выше.

Мои варианты и идеи на данный момент:

1. Переходите полностью к Spark. (В настоящее время я использую dask)
2. Перейти к формату, ориентированному на строки. (В настоящее время я использую паркет)
3. Как-то изменить схему таблицы, например, создать одну таблицу для SOLD_PRICE и другую для ORDER_VOLUME, оба проиндексированы на SKU, STORE с датой, повернутой в виде столбцов .
4. Создание объединения SKU и Store для сокращения иерархии индексации.

Какой из этих параметров может повысить производительность моего проекта? Можете ли вы предложить что-то еще?

Answer 1

Здесь будут большие данные (от 2 до 200 ГБ)

200 ГБ - это не большие данные, но я скажу, что от 2 до 200 - это 2 порядка, не большая часть оценки.

Можете ли вы предложить что-то еще?

Да: SQL. Мне еще предстоит увидеть, как Pandas превзойдет SQLite, а тем более полноценную SQL СУБД, и чем больше набор данных, тем лучше будет SQL. SQL также предоставит вам более выразительный, более всеобъемлющий синтаксис и избавит вас от некоторых скуок Pandas. Кстати,

SQL был изобретен для запросов "на лету".

Я бы предложил загрузить ваши данные в SQLite. Похоже, у вас есть только одна или две таблицы. Затем попробуйте несколько запросов и посмотрите, как вы делаете. Не пропустите индексы для вашего любимого поиска и критериев присоединения. Я думаю, вы можете быть приятно удивлены тем, как быстро он вычисляет, скажем, inventory level, и как мало усилий с вашей стороны.

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