Как стать автором
Обновить

Комментарии 8

У меня несколько вопросов по Druid:


  1. Сколько серверов используется в кластере?
  2. Каким методом загружаются данные (tranquility/kafka) ?
  3. Сложно ли поддерживать кластер?
  4. С какими проблемами столкнулись в процессе работы с Druid?
  5. Рассматривали ли какие-то альтернативы?
Вопрос не совсем по теме.
1) 132T сжатых данных на всю историю на 3х2 hdfs-машинах (+3х1 namenodes) + 2x3 — бекап = 15 HDFS
12.6T несжатых hot данных (за последний месяц) на 3x7 машинах = 21
180T несжатых cold данных (за последние 2 года) на 3х6 машинах = 18
=192.6T на 3х13 = 39 машин

+3x3 brokers
+3х12 realtime
+3х1 coordinator
+3x1 newsql
+3x2 tarantool-memcached cache
=3x19 = 57 машин
=324.6T на 3х37 = 111 машин

+63 временные под миграцию.

2) realtime ноды выкачивают данные из самописанных лог буферных баз (собирающих данные непосредственно с приложений) самописным загрузчиком

3) Не особо, периодически мы смотрим тренды и определяемся сколько добавить железа, в основном это нужно для hot, cold и hdfs, расширяем дисковое пространство. Пока, за 2 года, кроме дисков ничего не наращивали.

4) Без трудностей не бывает:
Сложно искать проблемы из-за большого количества нод. Пришлость сделать централизованную консоль, куда сваливаются все ошибки и самодиагностика (которую сами же и сделали).
Пофикшено много узких мест по производительности (в запросах, в индексации), много впилено параллельной обработки.
Пришлось много фиксить по нашим HA-требованиям: в каждом ДЦ должна быть копия данных, потеря одного ДЦ целиком не влияет на работоспособность, выход/вывод машины из строя не должен вызывать переезд данных на другие машины (предполагается что машину починят и вернут), HDFS пришлось «починить» для репликации данных по более 2 ДЦ. mysql был заменен на наш newsql (кассандра) для RF=3. memcached заменен на tarantool-memcached и допилен RF=3 и read-repair для кеша.
Конфигурация realtime на файлах => сделали полу-динамическую конфигурацию, по-прежнему на файлах, но они генерятся из системы управления конфигурацией приложений (PMS) и раскидываются по всем realtime.
Практически полностью статическая конфигурация => мы прицепили нашу систему управления конфигурацией приложений (PMS) и сделали много параметров динамическими (в основном это нужно для экспериментов, решения инцедентов, и создания/перенастройки DSN).

5) Рассматривали несколько вариантов, в том числи druid и «что-то своё». Все, кроме двух последних, были отброшены как не отвечающие требованиям по HA или они вообще не были похожи на production систему (честно говоря, уже и не помним названия остальных вариантов). В итоге выбрали druid.
Не планируете открыть исходники вашей системы для широких масс и отправить ее в путь OpenSource? Очень бы хотелось «пощупать» ее у себя в инфраструктуре.
На данный момент мы не планируем открывать исходники. Но этот вопрос мы слышим очень часто, поэтому задумались об этом. Если это произойдёт, то не в ближайшие пол года.
Скажите, пожалуйста, какова частота обновления точек у одной метрики, с которой работает Anomaly Detector? Т.е. каков временной юнит, которым оперирует AD?

И ещё вопрос — какова «пропускная способность» детектора?
Т.е. сколько метрик обслуживает инстанс AD, в пересчёте на ядра/память?
Мы анализируем пятиминутные данные, сервис работает в 20 потоков (ядер на машине 24), в данный момент анализируем порядка 160000 числовых последовательностей.
Данные по разным таблицам приходят и анализируются асинхронно, так что памяти используется мало.
Сергей спасибо за материал.
«мы берём шесть недель (т. е. если сегодня понедельник, то в обучающую выборку идут все понедельники)» А если прошлые понедельники были жутко аномальные (так совпало). То скорее всего моделька получится перетянутая в аномалии и текущую аномалию не поймает.

Или это просто очень маловероятный кейс :)
Привет.
Мы постоянно улучшаем систему и что-то из статьи устаревает :)
При учёте шести недель это был редкий кейс, сейчас мы стали брать в обучающую выборку больше 6 недель, чем ближе неделя к текущему дню, тем выше её вес.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий