Когда мозг пылает, а задачи не становятся проще....

Сижу, значит, дома, состояние адское — какая то простуда скосила, голова трещит, сил нет, а вот на брейншторм почему-то есть. И вот параллельно с попытками заварить чай без того, чтобы забыть, зачем вообще я на кухню пришел, я ломаю голову над задачей: как, чёрт возьми, обработать таблицу весом в 1 ТБ в своей текущей архитектуре?

Тут не просто «пару строк фильтрануть». Тут джойны. Множество джойнов. Сложные операции над всем массивом данных, где результат зависит от всей картины. И вот я сижу, думаю, что использовать и какие инструменты, возможно как бы заставить Apache Spark и Tarantool, это своеобразное «братство», справиться с этой задачей.

Почему это сложнее, чем кажется?
Во-первых, 1 ТБ — это уже не «загрузим в память и поехали». Тут каждый шаг приходится продумывать:
- как разрезать данные на куски, чтобы всё не утонуло в shuffle?
- как джойнить, когда обе таблицы большие?
- как сделать так, чтобы Tarantool на своей стороне не упал в ступор, пока Spark крутит свои колеса?

Во-вторых, я не хочу Hadoop, есть нюансы. Всё на Kubernetes, где Spark чувствует себя более-менее комфортно, но вот Tarantool — это NoSQL-хранилище, которое изначально не заточено под такие сценарии. И да, оно быстрое, гибкое, поддерживает шардирование, но заставить его дружить с задачами масштаба «обработай 1 ТБ за приемлемое время» — это прям испытание, а ещё и со спарком)

Что я придумал (между приступами кашля)? (Возможно придя в себя, пойму, что создаю монстра)

1. Шардирование спасает мир
Без Tarantool vshard здесь вообще никуда. Распределяю данные по нескольким узлам, чтобы не было узких мест. Spark при этом тоже помогает — можно настроить обработку данных параллельно, забирая части таблиц с каждого узла.

2. Делим на куски
Идея проста: даже 1 ТБ можно разбить на более мелкие порции. Можно агрегировать часть данных до джойнов, чтобы уменьшить их объем.

3. Джойны с умом
Тут выбор подхода: либо джойнить данные в Spark через партиции (если таблицы большие), либо попробовать схитрить и сделать часть работы заранее в Tarantool.

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

Вопрос на миллион

А нужен ли мне вообще такой подход? Может, проще выделить одну задачу для Tarantool, другую для Spark? Или всё-таки объединить их возможности, чтобы найти баланс между скоростью Tarantool и мощью Spark?

Сижу, ломаю голову, и понимаю: такие задачи — это как раз тот случай, когда тебе одновременно нужен грамотный подход и хороший аспирин.

P.S. параллельно кручу другие связки, но пока ещё не взвесил все за и против.