Это какой-то инновационный компактор)

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

В лучших домах обычно хранят в каталогах информацию о правильной сортировке и прочих настройках самых жирных датасетов

За свой дом могу сказать, так и есть

Физкультпривет)

Всем привет! Подскажите, пожалуйста, оптимальный способ: нужно записать в hdfs паркетный файл с данными типа Seq[(String, String)] с использованием Hadoop API. Есть вариант использования org.apache.hadoop.ParquetWriter или еще с использованием AvroParquetWriter. Но это как-то высоко. Я не могу понять, можно ли  для записи паркета например использовать FSDataOutputStream например? Спасибо!

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

Вообще-то, в вертике не так...

Если конечно, мы говорим о структуре хранения, а не о структуре запросов с джойном

Располагать колонки только из-за типа, это явно какая-то фантазия. В той же вертике, если мы говорим о хранении и ddl, то для проекций конечно же надо указывать правильную сортировку с нужной последовательностью, но при этом будет это инт или варчар, с точки зрения хранения - все равно.

Когда же делается выборка, то оптимизатор работает чуть иначе и тут как раз уже играет роль колоночности, в первую очередь, для красивого мердж-джойна конечно же надо брать первые сортированные поля, но дальнейшая логика может идти уже по любым полям, даже которые не участвуют в явной форме в сортировке на проекции

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

@aledovsky привет =)

Серёжа, привет

Привет!)

Привет!
Вопрос: есть ли какие-нибудь легковесные in-memory SQL базы данных, чтобы можно было в них держать чуть-чуть данных и иметь возможность быстро получать из них что-то на основе sql запроса (в т.ч. с оконными функциями и т.п.). Т.е. как memcached, но с SQL)

игнайт :)

кстати, смотрю на него, но смутило

is a distributed database for high-performance computing with in-memory speed

звучит как бигдата)

звучит как бигдата, выглядит как бигдата, по факту утка ))

SQLite :)