Comments 9
Крутая статья, спасибо! Особенно приятно было увидеть решение проблемы с DataGrip, ну и до XGBoostа не все доходят
Скажите, а какие фичи учитывает модель для определения оптимального кодека для колонок?
С ходу мысль - для низкокардинальных полей использовать RLE. Но что положить в модель - не очень понятно.
И второй вопрос - оптимизация направлена только на оптимизацию сжатия?
Часто можно применть ZSTD с максимальным сжатием, но перф работы при этом будет оставлять желать лучшего.
Спасибо.
Добрый вечер.
Фичи на память такие: тип, номинальная длина/точность типа, текущая позиция в сортировке, количество уникальных значений, количество значений null, как часто следующие значения равны текущему.
Тяжеловесов вроде BZIP или GZIP мы используем в крайне режких случаях как раз по этой причине. ZSTD в общем случае хорош (и например в наших экспериментах с гринпламом использование ZSTD позволило выравняться по месту на дисках с вертикой), но старые вертичные кодировки при умелом применении хорошо жмут и работают быстро. По дефолту мы используем BLOCKDICT_COMP, DELTARANGE_COMP или LZO. Вот здесь хорошая вводная статья была.
Добрый день
Мы как-то хотели в вертике прикрутить внешние таблицы к S3 для хранения холодных данных и поддержка сказала что в таком случае мы все равно должны платить за место занимаемое в S3 (т.е. данные в S3 входят в лицензию)
Как у Вас с точки зрения лицензий это работает? Платите за хранение таблиц в клике или какие-то особенные условия?
С версии 9.1 ORC и Parquet лицензируются, верно. Тем не менее, они лицензируются по физическому месту на диске. А это не тоже самое, что лицензия во внутреннем формате вертики.
На сколько мне известно на настоящий момент самописные UDF не лицензируются. Другое дело, что сырой поток событий с тысячами возможных полей за длительное время в ежедневных расчетах не требуется. Это скорее очень крутая дополнительная возможность для того, чтобы в адхоках что-то разово проверить. И надо иметь ввиду, что удобство работы через UDF конечно уступает тому, что предоставляет вертика из коробки
1) Подскажите, какую компрессию вы выбирали при записи в Parquet? Можно детально увидеть сравнение сжатия?
Parquet + ZSTD компрессия = самое лучшее сжатие данные ever по факту.
В Parquet есть не только блочные storage индексы но и страничные индексы. Если движок который работает с данными об этом знает, то выводы по скорости очевидны.
2) Не хватает технической информации
кол-во узлов, общий объем данных. Так же интересно на каком кол-ве проекций у вас начались проблемы с каталогом.
Какое кол-во конкурентных сессий у вас (ETL и пользовательских) ?
В целом вы приняли конечно правильное решение по разделению ETL и пользовательской нагрузок. На больших конкурентных системах не всегда это можно сделать через ресурсные пулы без ущерба для SLA и все рано или поздно приходят к такому решению, если не закладывали его сразу в архитектуру.
Я так понимаю, у вас dual ETL чтобы данные были синхронизированы. У Vertica пока нет нормальных тулов чтобы носить данные в более-менее нормальном регламенте с кластера на кластер и чтобы при этом кластера были несимметричны по конфигурации.
Эволюция хранилища данных в Авито