Блог DevOps | OTUS
Посты
Гибкость в хранении информации и масштабировании в Kafka

Сложно спорить с тем, что одно из важных преимуществ Kafka -- это возможность долговременного хранения информации. Мало того, используя настройки, вы можете как указать определенное время хранения топиков, так и ограничить размер топика в байтах -- в случае превышения сообщения станут недействительны и будут удалены. Разве не удобно, что сообщения хранятся лишь до той поры, пока они нужны? Однако это еще не всё.

Работа с базами данных и облачной инфраструктурой в SRE

Именно SRE-инженер находится в первых рядах, если речь идет про обеспечение аптайма высоконагруженных сервисов и стабилизацию системы после краша. Именно поэтому такой специалист должен разбираться и в разработке, и в системном администрировании, и в траблшутинге. Но есть еще одно чрезвычайно важное умение для SRE-инженера: работа с БД & облачной инфраструктурой. Остановимся на этом чуть подробнее.

Helmwave v0.19.3

Продолжаю делиться новостями ченджлогов. В этот раз небольшой апдейт по Helmwave -- известный инструмент для декларативного описания деплоя helm-чартов, представляющий собой, по сути, docker-compose для @helm. Предыстория здесь и здесь.

Топики в Apache Kafka

Мало кто не знаком с Apache Kafka. Это популярная платформа потоковой обработки событий в реальном времени, обладающая низкой задержкой и высокой пропускной способностью. Еще ее называют распределенным программным брокером сообщений с открытым исходным кодом. Однако все эти сообщения еще надо где-то группировать. В случае с Kafka используются топики.

Измеряем самое важное: Prometheus

Как известно, единственный способ принимать правильные и, что не менее важно, осознанные решения в процессе разработке программных проектов, заключается в точной и аккуратной работе с метриками продукта. И чем раньше вы приступите к сбору данных обо всем, что происходит, тем лучше, ведь тем быстрее вы обнаружите проблемы продукта, следовательно, тем раньше вы определите возможности для его роста. Один из хорошо зарекомендовавших себя инструментов -- это, конечно же, Prometheus.

Повышаем производительность Spark: Broadcasting

Соединение нескольких таблиц является достаточно распространенной операцией в Spark. Как правило, при ее выполнении происходит перетасовка (shuffle), которая за счет перемещений данных между узлами оказывает влияние на производительность. Можно ли избежать этой дорогостоящей операции?

Популярное
Сегодня тут пусто