Можно ли использовать Apache Kafka в качестве базы данных и какое у Кафки будущее? Провели небольшое интервью с нашим экспертом, спикером Слёрма Георгом Гаалом. Он ответил на эти вопросы, а ещё рассказал о сильных и слабых сторонах платформы, возможностях её масштабирования и о том, кому надо изучать Кафку, а кому не стоит.
— Скажи, пожалуйста, где ты работаешь?
— Сейчас я работаю в Райффайзенбанке, моя должность звучит как Senior DevOps Expert, вице-президент.
— Титул почти королевский!
— Да, многим может показаться, что вице-президент звучит круто. Но это не совсем так. В банках «вице-президент» — скорее почётный титул за заслуги. Если перевести на русский, то себя я могу позиционировать как техлида: у меня есть команда, и мы делаем жизнь разработчиков лучше.
— Как давно работаешь с Apache Kafka?
— На самом деле с Кафкой я познакомился примерно года четыре назад. Это произошло в компании S7, там мы её использовали как шину обмена сообщениями. Там же я обучался Кафке в рамках курса по BigData-инструментарию на одной учебной платформе.
— Участвовал ли ты в её внедрении в продакшен?
— Это интересный вопрос, потому что по большей части, я с Кафкой работаю таким образом: есть тестовый стенд, я её там поднимаю, минимально настраиваю, и ребята начинают ею пользоваться. То есть такой задачи, как, например, построить большую систему на Кафке, шину в условном ГазМясе, полностью весь прод, у меня не стояло, но были задачи более точечные. В рамках таких внедрений я стоял рядом, как говорится, «свечку держал», это позволило немного расширить свой кругозор и набраться умных слов от коллег :-)
— Тебе есть что сказать об альтернативах Кафки?
— На самом деле не особо, потому что Kafka — это продукт из стека BigData и стека Apache, она хорошо скейлится, и поэтому смысла заморачиваться на условный RabbitMQ не было.
Грубо говоря, продукты занимают разные ниши, Rabbit — скорее про очередь, которую разработчик берёт сразу по потребности, а не «костылит» свою реализацию поверх Redis и PostgreSQL, он хочет полноценную очередь с группами подписок и рассылками. Решение наивное, но не всегда правильное, потому что на практике Rabbit обладает множеством недостатков. Например, у нас был случай, когда кластер Rabbit развалился, и обе половинки начали работать автономно, а связать их воедино — это уже была отдельная история.
В этом отношении Кафка — совершенно другой продукт, нормальное кластерное решение, с Зукипером под капотом. Там есть устойчивость, есть репликация. Конечно, по функционалу она может проигрывать в некоторых местах, и что-то нужно делать руками. То есть Кафка довольно простая: очередь и очередь. Нет такого, что невычитанные сообщения кладутся в другую очередь — такие вещи ты реализуешь на уровне логики своего приложения, что на самом деле позволяет лучше настраивать Кафку под себя.
Из альтернатив могу упомянуть ещё Pulsar, который тоже относится к Apache-стеку. Это решение вышло немного позже Кафки, поэтому не успело получить международного признания и экспертов по нему намного сложнее найти. Продукт менее популярный, но Pulsar намного интереснее за счёт большего количества встроенного функционала. Однако такое малое количество экспертов и отсутствие возможности приобрести техническую поддержку (как, например, у Confluent для Кафки) даёт свои проблемы. Из cloud-native аналогов есть NATS.
— В чём сила Кафки?
— Я думаю, её сила в том, что она очень хорошо закрыла потребность рынка, когда вышла. Технологически она реализована очень грамотно. Под капотом используются правильные технологии, например, та же zero memory copy, которая позволяет достичь высокой скорости. Кафка масштабируемая, она отказоустойчивая, что добавляет популярности, ведь ты можешь её поставить и не бояться, что она развалится.
Также Кафка обеспечивает быстродействие, потому что она может хорошо утилизировать дисковую пропускную способность и последовательно складывать на диск блоки данных, которые в неё приходят. Опять же, её можно испортить, если неправильно использовать, но если применять правильно, то проблем не будет. Кафка — часть стека BigData, это позволяет использовать его компоненты в полный рост, что тоже немаловажно!
— А в чём её слабость?
— Слабость в том, что нужно тащить минимум два компонента: Zookeeper и сама Kafka. Сейчас первый компонент пытаются реализовать с помощью протокола консенсуса репликации внутри Кафки, но пока что это ещё не случилось и больше похоже на эксперимент. Скорее бы уже доработали, потому что Зукипер уже архаичен сам по себе, на мой взгляд.
Ещё слабым местом Кафки является то, что она довольно простая и дополнительный функционал для разработчика там не такой уж и хороший. Да, есть топики в Кафке, куда можно складывать, можно вычитывать, есть стандартные Producer API и Сonsumer API, но многие вещи нужно имплементировать самостоятельно, например, какие-либо ретраи, очереди для необработанных сообщений. Теоретически это всё решается использованием более высокоуровневых библиотек поверх Кафки, таких как Kafka Streams. Экосистема вокруг Кафки уже большая и зрелая, и можно найти много хороших биндингов для различных языков программирования и библиотек на любой вкус.
— Насчёт масштабируемости — насколько в Кафке она хороша?
— Она хороша и универсальна, я знаю кейсы, где Кафка обрабатывает миллионы сообщений в секунду и при этом не давится.
— Кому Кафка нужна и для чего?
— Это сложный вопрос, как, например, с Linux или Kubernetes. Она есть везде, и это часть среды, в которой ты существуешь: не знать её уже грустно, и ты становишься менее конкурентоспособным на рынке труда.
Если говорить предметно, то Кафка хорошо ложится на задачи Data Engineering и Data Science, то есть с её помощью можно хорошо перекладывать данные из одного источника в другой автоматизированно. Кафка может присутствовать в больших enterprise-системах. Кафка может выступать в качестве хранилища данных, можно что-то вроде базы данных из неё соорудить, но нужно быть аккуратным, так как изначально у неё другое применение, а то может получиться троллейбус из «буханки».
— А есть те, для кого Кафка окажется бесполезной?
— Да, такие люди есть, так как есть разные группы приложений, и если тебе требуется синхронное взаимодействие, то Кафка, наверно, не очень подойдёт. Она хороша для асинхронных паттернов взаимодействия, когда процесс обработки данных не требует мгновенных реакций. То есть всегда нужно думать, похоже ли это на то, что тебе нужно или нет, и на основе этого принимать решение.
— Расскажи подробнее, что ты думаешь про использование Кафки в качестве базы данных?
— Думаю, здесь зависит от области применения. Например, у нас есть сообщения, которые представляют биды на аукционы, и нам нужно посчитать максимальное или среднее по каждому из участников торгов. И тут мы можем при помощи Кафки и её внутреннего хранилища на RocksDB реализовать логику подсчёта среднего или максимального. Здесь Кафка вроде сама по себе не база, но, с другой стороны, мы поверх неё быстро проводим подсчёт, получаем конечные данные и можем их отдавать наружу.
Если идти с точки зрения Кафки как хранилища, то тут скорее нет. Так как хранилище предполагает обращение к произвольным данным по произвольным ключам, а у Кафки такой возможности нет. То есть история про чтение по оффсетам звучит не очень хорошо, особенно для производительности.
— Последний вопрос: какое будущее ты видишь у Кафки?
Думаю, что Кафка будет дальше захватывать рынок, будет внедрена в большее количество организаций в том или ином виде. Соответственно, она, скорее всего, будет обрастать дополнительными библиотеками и функционалом, которые будут решать конкретные задачи пользователя.
