Comments 14
Александр, спасибо за доклад/статью, очень интересно, по делу, прекрасная подача!
Вопрос по анализу аномалий — этот функционал случайно не собирается утечь в open-source? :)
Интересует реализация такой штуки на timeseries, конкретно — Prometheus. Мы умеем это делать кастомным кодом, но были бы счастливы какому-нибудь более-менее продакшн-лайк open-source решению.
Вопрос по анализу аномалий — этот функционал случайно не собирается утечь в open-source? :)
Интересует реализация такой штуки на timeseries, конкретно — Prometheus. Мы умеем это делать кастомным кодом, но были бы счастливы какому-нибудь более-менее продакшн-лайк open-source решению.
AnyKey80lvl, сейчас AD представляет собой комбинацию из Spark + Spark-ts + Yahoo Egads. В ближайшее время мы собираемся рефакторить этот функционал. Думаем над тем, чтобы оформить его в стиле Spark MLLIB (Transformers API, etc.). В этом случае можно будет говорить о каком-либо open-source. Но что это случится скоро — не могу обещать.
Вставлю свои 5коп. Батчинг для снижения количества INSERT-ов на golang github.com/maslennikov-yv/tm
UFO just landed and posted this here
Спасибо за вопрос!
На момент появления ClickHouse у нас в качестве транспорта уже использовался LSD. Переделывать связку транспорт + процессинг в один заход у нас намерения не было (переход Hadoop -> CH был не одномоментным, а постепенным), и мы фокусировались на процессинге.
В дальнейшем мы, возможно, рассмотрим использование Kafka.
На данный момент мне нравятся «ручки» в нашей системе вставки:
1.) Отключение произвольных хостов/шардов
2.) Регулирование concurrency и размера батчей
3.) Внешний контроль в принципе. На мой взгляд, текущая интеграция CH + Kafka несколько сыровата. Например, я не понимаю, зачем нужна настройка «kafka_row_delimiter» (API Kafka подразумевает, что разбиение потока на отдельные сообщения реализовано в рамках broker-consumer протокола)
На момент появления ClickHouse у нас в качестве транспорта уже использовался LSD. Переделывать связку транспорт + процессинг в один заход у нас намерения не было (переход Hadoop -> CH был не одномоментным, а постепенным), и мы фокусировались на процессинге.
В дальнейшем мы, возможно, рассмотрим использование Kafka.
На данный момент мне нравятся «ручки» в нашей системе вставки:
1.) Отключение произвольных хостов/шардов
2.) Регулирование concurrency и размера батчей
3.) Внешний контроль в принципе. На мой взгляд, текущая интеграция CH + Kafka несколько сыровата. Например, я не понимаю, зачем нужна настройка «kafka_row_delimiter» (API Kafka подразумевает, что разбиение потока на отдельные сообщения реализовано в рамках broker-consumer протокола)
> удивительно похож на здание Крайслера в Нью-Йорке.
Приятно встретить человека который тоже увлекается рисованием зданий на графиках.
Приятно встретить человека который тоже увлекается рисованием зданий на графиках.
Вы изобрели 1Сные итоги регистров накопления в бигдате! )
Не совсем понятно чем было вызвано изначальное решение использование хадупа в задаче для которой он не был предназначен. Задача хадупа — работа с данными которые быстрее обработать чем передать по сети. В этом и его философия — мы перемещаем код а не данные и оставляем петабайты данных на разных континентах.
В рассмотренном же случае речь скорее идёт об обработке данных в одном дата-центре, где узким место скорее является CPU и диск, а не сеть.
В итоге видим не ускорение обработки данных, а изначально неверно выбранный инструмент для задачи.
Получается как в анекдоте: купи козу, продай козу.
В рассмотренном же случае речь скорее идёт об обработке данных в одном дата-центре, где узким место скорее является CPU и диск, а не сеть.
В итоге видим не ускорение обработки данных, а изначально неверно выбранный инструмент для задачи.
Получается как в анекдоте: купи козу, продай козу.
Спасибо за комментарий!
Я позволю себе с вами не согласиться, что Hadoop был не предназначен для задачи. Если забыть про второй ДЦ, с доставкой данных из которого возникали сложности, то задача по-прежнему звучит как «считать сложные агрегаты на массивном потоке эвентов, в окне размером вплоть до одного дня». И тут как раз работает и Spark (+Spark Streaming), разделение работ по агрегации по воркерам, использование HDFS для сохранения сериализованных представлений агрегатных функций. Поэтому, анекдот про рынок парнокопытного скота мне кажется здесь несколько притянутым.
Я позволю себе с вами не согласиться, что Hadoop был не предназначен для задачи. Если забыть про второй ДЦ, с доставкой данных из которого возникали сложности, то задача по-прежнему звучит как «считать сложные агрегаты на массивном потоке эвентов, в окне размером вплоть до одного дня». И тут как раз работает и Spark (+Spark Streaming), разделение работ по агрегации по воркерам, использование HDFS для сохранения сериализованных представлений агрегатных функций. Поэтому, анекдот про рынок парнокопытного скота мне кажется здесь несколько притянутым.
Расскажте как сделан Anomaly Detection?
И что используете для визуализации?
И что используете для визуализации?
А нету у вас планов задачи, которые решаются в Exasol, постепенно переносить в CH (из соображений экономии на лицензиях)?
Спасибо за вопрос!
Тут суть в том, что в Exasol мы используем тот функционал, который нам не даст ClickHouse ни под каким соусом — не equi-join, оконные функции. Можно забыть про транзакционную доставку данных, и нагородить какой-то хитрый ETL с RENAME'ом таблиц/удалением партиций, и прочее, но вот JOIN, оконные функции, и у нас ещё есть немного скриптинга под Exasol — без этого мы не проживём :)
Тут суть в том, что в Exasol мы используем тот функционал, который нам не даст ClickHouse ни под каким соусом — не equi-join, оконные функции. Можно забыть про транзакционную доставку данных, и нагородить какой-то хитрый ETL с RENAME'ом таблиц/удалением партиций, и прочее, но вот JOIN, оконные функции, и у нас ещё есть немного скриптинга под Exasol — без этого мы не проживём :)
Sign up to leave a comment.
Разгоняем обработку событий до 1,6 миллионов в секунду