Комментарии 6
А разве не используется чаще термин «колоночная»? Вместо «столбцовая»…
Я правильно понял, что обучать модель надо самостоятельно. А в КХ уже подсовывать файлы с моделями?
Дополнительно ClickHouse сжимает данные, и то, что мы храним данные по столбцам, дает нам преимущество. Данные получаются более отдаленные и лучше сжимаются.
Наверное, оговорка: в одном столбце данные более гомогенные, поэтому и сжимаются лучше.
… есть пример — вычисление средней длительности сессии.
Наверное, в запросе опечатка — на слайде выбирается только avg_duration, но не FirstPartyCookie, то есть запрос возвращает только средние длительности сессий без привязки к кукисам, что в общем-то бесполезно.
Также мы использовали sampling: сказали, что будем читать 1/10 часть данных. ClickHouse делает это эффективно, он выбрасывает ненужные данные сразу после прочтения данных с диска.
Насколько мне известно, в аналитических СУБД основное время тратится именно на общение СУБД с диском. То есть проведение сэмплинга после чтения с диска в большинстве случаев лишено смысла — я практически уверен, что в приведенном примере запросы с сэмплингом и без будут выполняться приблизительно одинаковое время. Другое дело, что сэмплинг на уровне блоков не будет случайным, но это уже другой вопрос.
У нас есть обученная модель, она выдает хорошее качество. Как теперь ее внедрять?
Казалось бы, вопрос простой. Давайте делать просто: каждый понедельник выгружать из ClickHouse данные за предыдущий месяц, запускать питоновские скрипты, получать вероятность покупки и загружать обратно, скажем, в ту же таблицу ClickHouse
Стоп. Зачем выгружать, зачем питоновские скрипты? Давайте сначала остановимся и опишем, какую именно задачу мы хотим решить? В большинстве случаев намного более эффективным будет применение модели в реальном времени — пользователь присылает запрос, и специальный сервис применяет последнюю версию вашей модели к данным конкретного запроса. Почему вы решили, что нужно применить именно оффлайн предпосчет вероятностей, без указания мотивации этого решения?
Вопрос по существу 1: вы храните данные в column-oriented таблицах, и предлагаете применять к этим данным одну из обученных моделей. Проблема в том, что для применения модели зачастую требуются практически все столбцы таблицы. В итоге, колоночная СУБД для вашего запроса собирает полные строки исходных данных — не является ли overkill'ом использование колоночной БД в этом случае? Согласно моему опыту, колоночное хранение данных выигрывает у построчного при использовании <50% столбцов в запросе, а использование 100% столбцов — худший кейс для колоночной БД.
Вопрос по существу 2: вы используете свой XML-подобный формат для хранения моделей. Почему не PMML, являющийся стандартом де-факто в индустрии?
Прошу простить за поздний ответ — я почему-то только сейчас нашёл эту статью.
В статье ошибка. Как раз смысл отдельной поддержки сэмплирования в ClickHouse в том, что при этом с диска читается меньше данных. Данные расположены на диске так, что для чтения сэмпла достаточно прочитать отдельные диапазоны данных. Это реализовано очень просто: данные хранятся в небольшом наборе кусков, каждый из которых упорядочен по первичному ключу. А ключ сэмплирования обязан входить в первичный ключ, при чём это имеет смысл только если до него присутствуют лишь столбцы небольшой кардинальности. Для примера, первичным ключом может быть (CounterID, Date, intHash32(UserID)), а ключом сэмплирования — intHash32(UserID).
Подробнее здесь и здесь .
Загружать данные в ClickHouse только для применения модели, по большей части бессмысленно. Основной сценарий использования данной фичи — когда данные уже хранятся в ClickHouse. В этом случае удобно иметь модель в виде готовой функции, которую можно использовать прямо в SELECT-е, вместо того, чтобы выгружать данные и затем обрабатывать их скриптом.
Для примера, у нас хранятся данные Яндекс.Метрики, и мы применяли модель на таблице с сессиями пользователей, для предсказания покупки в интернет-магазине. В таблице с сессиями уже есть всевозможные свойства пользователя, включая данные об истории (например, сколько сессий на сайте было раньше). Дальше мы берём из этого всё, что кажется подходящим, и обучаем модель. После обучения можно выкинуть из модели большинство факторов.
На этот вопрос не могу ответить, так как далёк от разработки как самого CatBoost, так и его интеграции с ClickHouse. Спрошу у коллег…
Насколько мне известно, в аналитических СУБД основное время тратится именно на общение СУБД с диском. То есть проведение сэмплинга после чтения с диска в большинстве случаев лишено смысла — я практически уверен, что в приведенном примере запросы с сэмплингом и без будут выполняться приблизительно одинаковое время. Другое дело, что сэмплинг на уровне блоков не будет случайным, но это уже другой вопрос.
В статье ошибка. Как раз смысл отдельной поддержки сэмплирования в ClickHouse в том, что при этом с диска читается меньше данных. Данные расположены на диске так, что для чтения сэмпла достаточно прочитать отдельные диапазоны данных. Это реализовано очень просто: данные хранятся в небольшом наборе кусков, каждый из которых упорядочен по первичному ключу. А ключ сэмплирования обязан входить в первичный ключ, при чём это имеет смысл только если до него присутствуют лишь столбцы небольшой кардинальности. Для примера, первичным ключом может быть (CounterID, Date, intHash32(UserID)), а ключом сэмплирования — intHash32(UserID).
Подробнее здесь и здесь .
В итоге, колоночная СУБД для вашего запроса собирает полные строки исходных данных — не является ли overkill'ом использование колоночной БД в этом случае?
Загружать данные в ClickHouse только для применения модели, по большей части бессмысленно. Основной сценарий использования данной фичи — когда данные уже хранятся в ClickHouse. В этом случае удобно иметь модель в виде готовой функции, которую можно использовать прямо в SELECT-е, вместо того, чтобы выгружать данные и затем обрабатывать их скриптом.
Для примера, у нас хранятся данные Яндекс.Метрики, и мы применяли модель на таблице с сессиями пользователей, для предсказания покупки в интернет-магазине. В таблице с сессиями уже есть всевозможные свойства пользователя, включая данные об истории (например, сколько сессий на сайте было раньше). Дальше мы берём из этого всё, что кажется подходящим, и обучаем модель. После обучения можно выкинуть из модели большинство факторов.
Вопрос по существу 2: вы используете свой XML-подобный формат для хранения моделей. Почему не PMML, являющийся стандартом де-факто в индустрии?
На этот вопрос не могу ответить, так как далёк от разработки как самого CatBoost, так и его интеграции с ClickHouse. Спрошу у коллег…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Применение моделей CatBoost внутри ClickHouse. Лекция Яндекса