В современном мире обработки данных в реальном времени бизнесы стремятся обеспечивать быструю и надежную передачу информации между большими системами. Одним из главных решений для реализации подобных задач традиционно считается Apache Kafka — распределённая система созданная для обработки больших потоков данных с характеристиками высокой производительности и масштабируемости. Однако компания RudderStack, специализирующаяся на обработке маркетинговых и пользовательских данных, решила пойти по другому пути и выбрала для своей системы потоковой обработки данных и очередей сообщений базу данных PostgreSQL. В данной статье мы подробно рассмотрим причины такого выбора, указав на ограничения и вызовы использования Kafka, а также выделим преимуществ PostgreSQL как технологической основы для очередей событий и упрощения процессов сопровождения и отладки. RudderStack как система очерёдности событий предназначена для приема и хранения событий из различных источников с последующей доставкой их в разные системы-получатели.
Важнейшей особенностью такой системы является устойчивость к ошибкам и возможность надежного хранения данных при поломках различных компонентов. Например, если одна из систем-получателей временно недоступна, события не должны теряться, а должны быть надежно зафиксированы до успешной доставки. Для решения этой задачи нужно было организовать очередь сообщений с одним или несколькими потребителями, способную сохранять состояние, обрабатывать ошибки и гарантировать порядок доставки. Apache Kafka считается одной из самых популярных платформ для подобных сценариев за счет продвинутых возможностей: сохранения данных, обеспечения порядка сообщений, поддержки масштабирования, а также возможности горизонтального наращивания мощности. Философия Kafka предполагает разделение потоков событий по темам, которые могут быть настроены в соответствии с конечным назначением.
В теории для RudderStack логичным было бы создать отдельный топик для каждой системы назначения, позволяя тем самым обрабатывать события параллельно и избегать блокировки доставок. Однако на практике с таким подходом возникают серьезные сложности. Во-первых, масштабируемость по количеству тем в Kafka ограничена. Для среды с множеством клиентов и многочисленными точками назначения создание отдельного топика на каждую комбинацию клиента и получателя ведет к огромному количеству тем. Такая архитектура негативно влияет на производительность и стабильность Kafka кластера, что может стать серьезным препятствием для роста бизнеса.
Аналогичные проблемы описывались и другими компаниями, разрабатывавшими системы с Kafka в крупных масштабах. Во-вторых, управление и эксплуатация Kafka представляют собой сложную инженерную задачу. Рабочий процесс Kafka тесно интегрирован с Apache Zookeeper — распределенной системой управления конфигурацией и синхронизаций. Это добавляет дополнительные сложности при развертывании, обновлении и мониторинге. RudderStack ориентировался на решение, которое было бы проще сопровождать, не требовало бы глубоких экспертиз во всех сопутствующих технологиях и позволяло сосредоточиться на развитии бизнес-логики, а не на поддержке инфраструктуры.
Также не стоит забывать о проблемах с лицензированием Apache Kafka и ее расширений. Основной дистрибутив Kafka распространяется под лицензией Apache-2, которая совместима с открытым ПО. Однако некоторые ключевые функции, например kSQL, полезные для отладки и управления потоками, доступны только под лицензиями с ограничениями, не удовлетворяющими требованиям свободного распространения продуктов RudderStack, который стремился к релизу всего кода в рамках AGPLv3. Это создавало ограничения для гибкой настройки и доработок, необходимых для уникальных требований рынка. Третий момент связан с обработкой ошибок и управлением состоянием событий в очереди.
Идеальная очередь должна permitir отслеживать статус каждого события — успешно отправлено, находится на повторе или заблокировано. Кроме того, события от одного и того же пользователя должны обрабатываться последовательно, чтобы не нарушать порядок. Например, если событие номер один не доставлено, следующее за ним событие от того же пользователя не должно быть обработано до решения первой проблемы. В классической Kafka невозможно обновлять уже записанные события или добавлять к ним состояние для хранения информации о ошибках. Попытки реструктуризировать очередь, удаляя и повторно добавляя события, ведут к потере порядка и нарушают логику обработки.
Были и попытки использовать две очереди — основную и для ошибок — однако такая схема сложна в поддержке, особенно при повторяющихся ошибках и многочисленных повторных попытках. С течением времени количество таких очередей может расти экспоненциально, усложняя архитектуру. Таким образом, сохранение логики порядка, возможности апдейтов и быстрой обработки отказов требует механизма, позволяющего манипулировать состоянием каждого элемента очереди. Здесь PostgreSQL предлагает свои преимущества. Как полнофункциональная реляционная база данных, поддерживающая ACID-транзакции и богатый язык запросов, она позволяет реализовать надежную очередь с отслеживанием состояния любых сообщений.
Система RudderStack может легко сохранять события, обновлять статус, присваивать пользовательские метаданные, откатывать и повторно обрабатывать события без потери порядка. Более того, SQL-интерфейс позволяет сразу получать полноценную видимость по всем событиям: видеть их по пользователю, источнику или получателю, что значительно облегчает отладку и мониторинг. Совместное использование одного хранилища для событий и метаданных повышает общую надежность и упрощает сопровождение. Администрирование PostgreSQL в сравнении с Kafka менее трудоемко и не требует управления дополнительным слоем координации, как Zookeeper. Более того, PostgreSQL свободно доступна под лицензией с открытым исходным кодом, что устраняет ограничения и дает свободу для кастомизации и интеграции внутри продукта.
Еще одним положительным моментом является универсальность решения. Используя реляционную базу данных, можно более гибко изменять логику очереди, корректировать правила приоритетов, дописывать новые поля и условия для обработки событий без необходимости менять архитектуру на уровне интеграций или вводить дополнительные сервисы. Стоит отметить, что использование реляционной базы для очередей, конечно, сопряжено с некоторыми компромиссами по производительности при очень больших нагрузках в сравнении со специализированными распределёнными очередями. Однако благодаря современным возможностям PostgreSQL, в том числе горизонтальному масштабированию, оптимизации запросов и использованию индексов, это решение остается вполне жизнеспособным для больших объемов данных с необходимым уровнем надежности и удобством эксплуатации. В итоге выбор PostgreSQL над Apache Kafka в RudderStack обусловлен практическими требованиями к стабильности, гибкости, удобству сопровождения и лицензированию.
Такая архитектура позволяет не только гарантировать сохранность и порядок обработки событий, но и значительно упростить процессы мониторинга и отладки через встроенный SQL-интерфейс. Опыт этой компании демонстрирует, что доведение решения до успешного продукта требует комплексного подхода, где идеальная технология — не та, что гипотетически мощнее, а та, что лучше вписывается в реальные бизнес-практики и технические возможности команды. Благодаря PostgreSQL RudderStack удалось организовать систему очередей, которая хорошо масштабируется, обеспечивает высокую надежность доставки и предоставляет разработчикам гораздо более гибкие инструменты для анализа и управления процессом. Это служит отличным примером того, что реляционные базы данных все еще остаются очень важным ресурсом в эпоху потоковой обработки и больших данных, особенно там, где важны контроль, понимание и прозрачность процессов. Таким образом, несмотря на популярность Apache Kafka, PostgreSQL по ряду причин может быть предпочтительным выбором для систем потоковой передачи событий.
В процентном отношении сложность управляемости, лучшее лицензирование, возможность обновлять состояние сообщений, и универсальная структура предопределяют такую альтернативу как более подходящую в ряде бизнес-кейсов. Отдельные сценарии могут потребовать иных решений или интеграций, но опыт RudderStack показывает, что реляционная база данных способна конкурировать с традиционными потоковыми платформами за счет своей простоты и гибкости.
