Привет всем.
Вопрос по спарку. Есть три файла csv. Один из них весит 10гб с 19млн записей, два других меньше - 15 мб с 500к записей и 6 мб с 180к соответственно (последние две - тренировочные и тестовые выборки).

В том файле, что весит 10 гб есть айдишник и еще несколько колонок.
В файле который 15 мб  только айдишник и лейбл.
В файле на 6 мб уже только айдишник.

Вопрос в том, что мне нужно с основного файла в 10гб заджоинить данные по айдишнику. Каким образом это можно сделать оптимально и без шаффла?

Мне сказали, что есть вариант положить этот файл в базу данных, а уже потом сделать из двух других датафреймы с последующим джоином данных из этой базы. Насколько это будет ок в целом?

Судя по постановке задачи - БД оптимальное решение. Ибо JOIN - базовый функционал любой БД. А базовый функционал, который пилит сотня/тысяча/да даже десяток разработчиков (с высокой долей вероятности на С) явно более оптимально написан нежели велосипед, который Вы создадите в одиночку на Java и тем более Py.

Вообще не понимаю людей, которые готовят структурированные данные  не с помощью ANSI SQL, а своими велосипедами.

А в чём проблеиа шафла? Данных не так много же

Вам же не шафл нужно избежать , а сделать джойн .

У вас немного странная постановка задачи . Если нужно сделать за минимальное время - это другой вопрос. Но нужно ли именно это вам ?

Сделать джоин, но так чтобы моя оператива выдержала, и не заняло миллион лет

А, да, и без шаффла

Одно из требований

Сейчас падает у вас по памяти ?

Сейчас ничего не падает, я прикидываю лучшую стратегию

Лучшую стратегию для чего ? Когда решается задача оптимизации , то должен быть критерий оптимальности. Если вы например зальете данные в ClickHouse , то у вас джойн будет быстрее ( у вас маленький объем данных ), но если у вас объем данных существенно возрастёт и не будет влезать в память сервера , на котором запускается , то КХ начнет падать

Если вы загрузите в oracle и будете делать join там без включенной параллельности , то у вас будет сброс на диск ( Аля шафл) и стоит это будет существенно дороже )

ПС.КХ у вас не будет падать , если вы оформите 2 ваши маленькие таблицы словарями.

Привет. Есть вопрос. Допустим писались паркетные файлы с одной схемой и решили добавить в данные новое поле, добавили его в схему заранее, но в паркете его еще нет, но появится например завтра. Как сделать так чтобы паркет вычитывался уже с новым полем, но просто обозначал его null?

На данный момент просто кидает ошибку, что нет такого поля

А что за ошибка? Чем и как вычитываете?

Хм, а если поля нет в паркете, как его можно оттуда читать?

Разве его не надо сначала добавить?

Ну я об этом и пишу, что его еще не добавили