Comments 8
У меня несколько вопросов по Druid:
- Сколько серверов используется в кластере?
- Каким методом загружаются данные (tranquility/kafka) ?
- Сложно ли поддерживать кластер?
- С какими проблемами столкнулись в процессе работы с Druid?
- Рассматривали ли какие-то альтернативы?
0
Вопрос не совсем по теме.
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.
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.
+3
Не планируете открыть исходники вашей системы для широких масс и отправить ее в путь OpenSource? Очень бы хотелось «пощупать» ее у себя в инфраструктуре.
0
Скажите, пожалуйста, какова частота обновления точек у одной метрики, с которой работает Anomaly Detector? Т.е. каков временной юнит, которым оперирует AD?
И ещё вопрос — какова «пропускная способность» детектора?
Т.е. сколько метрик обслуживает инстанс AD, в пересчёте на ядра/память?
И ещё вопрос — какова «пропускная способность» детектора?
Т.е. сколько метрик обслуживает инстанс AD, в пересчёте на ядра/память?
0
Сергей спасибо за материал.
«мы берём шесть недель (т. е. если сегодня понедельник, то в обучающую выборку идут все понедельники)» А если прошлые понедельники были жутко аномальные (так совпало). То скорее всего моделька получится перетянутая в аномалии и текущую аномалию не поймает.
Или это просто очень маловероятный кейс :)
«мы берём шесть недель (т. е. если сегодня понедельник, то в обучающую выборку идут все понедельники)» А если прошлые понедельники были жутко аномальные (так совпало). То скорее всего моделька получится перетянутая в аномалии и текущую аномалию не поймает.
Или это просто очень маловероятный кейс :)
0
Sign up to leave a comment.
SmartMonitoring — мониторинг бизнес-логики в Одноклассниках