Pull to refresh

Comments 20

А не проще ли было купить у SAS Institute их движок для хранения агрегатов данных и просто состыковать с «зоопарком» источников? Или не у SAS, так у Teradata?

Ценник, конечно, начинается от миллиона евро и устремляется в стратосферу, но так и хранилище у SAS проектировалось строго под задачи аналитики big data и ни что иное. Что-то мне подсказывает, что на зарплаты админов и разработчиков, писавших решение без «фундаментального недостатка» на круг ушло больше.
Да ладно. Вы думаете на то, что описано в этой статье, ушло больше 10 человеко-лет разработки?
Как раз суть данного решения заключалась в минимизации написания собственных велосипедов. В ядре системы лежит уже готовый opensource проект (Apache Kafka), вокруг него мы построили свою обвязку и инфраструктуру, которая удовлетворяет нашим требованиям. От начала разработки до запуска в продакшен прошло 4 месяца. Внедрение было бесшовным, источники и не заметили, что стали лить данные в новую систему. В итоге мы получили кучу плюшек, описанных в статье.
У нас есть планы на частичное открытие исходников. Это касается клиетской части, сервера с ограниченным функционалом и клиентских библиотек к Kafka. Но это не в этом году.
Мы используем AWS Kinesis для схожих целей.

Скажите есть ли у вас требования на доставку сообщений консюменрам в том же порядке в каком они пришли от продюсеров. Если такое требование есть то как вы его реализуете?
(партиция упорядочена, но упорядочен ли топик с несколькими партициями ?)

Супервопрос — как вы считаете сколько в топике сообщений еще не доставленных консюмерам?
Порядок мы гарантируем только в пределах партиции. У нас каждый источник полностью ложится в одну партицию. При этом, в случае логов, источник это файл в файловой системе с точностью до inode. Если файл переименовали, а на его месте создали файл с тем же именем, то это уже будет новый источник и он польется в общем случае в другую партицию. Консьюмеров, которые зависят от порядка сообщений у нас сейчас нет.

Отставание считаем двумя способами. 1. Текущее отставание считается как high_watermark — offset, оно обновляется только когда работает консьюмер. 2. Есть внешний процесс, который с помощью запросов OffsetRequest определяет размеры партиций, также он ходит в хранилище offset'ов консьюмеров (сейчас это zk) и смотрит текущую позицию. По этим данным строится отставание. Все мониторинги завязаны на работу именно внешнего процесса, так как он может вычислять отставания даже когда не работает система.
Спасибо за ответ.
Вот вам и преимущества своей архитектуры — AWS берет плату за шарды так что нам и в страшно сне такое решение приснитася не могло.
Используем для тех-же задач flume
Вы потом это все в Hadoop складываете?
Да, и обрабатываем там-же, благо инструментов море на любой вкус. Объем данных ~1Тб в сутки пожатых LZO. Flume вполне стабилен и может практически все, что описано в статье. Правда не без недостатков, о чем, наверное, напишу когда-нибудь сюда статью.
Алексей, привет.
Наша система примерно делает тоже самое только не для логов, а для других более важных данных.
Из требований у нас так же налагаются жесткие требование на soft realtime.
Технологии которые используем это: Erlang, Riak, RiakKV(map reduce), Mnesia и так далее.
Правда данных гоняется гораздо меньше.
Вы aozeritsky смотрели в сторону этих решений?
Так же раньше имел дело с sonic esb и его копию fuse esb, oracle fusion middlleware. Я правильно понял что вам не нужно динамически управлять потоками данных или как-то на лету их изменять?
Так же интересно, а как вы потом строите отчет? кладете в hadoop или что-то свое?

Спасибо,
Дмитрий
Привет,

Система изначально создавалась для логов, но последнее время мы начали к ней подключать потоки не-логи. Технологии кроме Apache Kafka: Scala, Akka, Spray, C++ (парсинг логов). На клиентской стороне Си (без плюсов :) ),libevent. Для обработки данных и построения отчетов: YT и YAMR.

Динамическое управление данными имеется. 1. Есть система автоматического определения типа данных, которые отправляет источник. В зависимости от типа решается куда поставлять данные и в какую таблицу на кластере (в это очень сильно помогают Kafka Topics). 2. Можно на лету менять правила поставки и «рисовать стрелки» для потоков данных.

Riak не смотрели, но смотрели другие системы, построенные на аналогичных принципах. После негативного опыта взяли более простое, дубовое решение, такое как Apache Kafka :)
Спасибо, на Moscow JUG 2014 был доклад из Яндекса о использовании акторов в Scala =) Очень классный.
Наверное вы используете Scala как раз для этих целей, а почему не Erlang?
Изначально мы строились вокруг стандартного клиентского кода Kafka, а он имел более-менее полный API только для Scala. Также за Scala можно посадить Java-разработчика, а вот с Erlang всё гораздо сложнее, у нас в отделе совсем нет специалистов по нему.
А у нас есть!
Приходите, научим :)
А где если не секрет в Москве еще Erlang используется?
Поиск по открытым источникам дает такие результаты:
— disk.yandex.ru
— fly.me
— platbox.com
— billing.ru
— mainpeople.ru
— flussonic.com
— exante.com

Скорее всего, это сильно неполный список.
в radio-t как-то бобук говорил что диск переписали с erlang на что-то более правоверное.
Sign up to leave a comment.