PostHog отказалась от DuckDB в своем дата-хранилище

Пять месяцев назад компания PostHog полностью перестроила свое хранилище данных на базе DuckDB вместо ClickHouse, однако теперь команда объявила о создании новой архитектуры. Основными причинами перехода стали стремительный рост масштабов клиентских нагрузок и ограничения облачного использования одноузловых систем.

• PostHog перенесла хранилище на DuckDB пять месяцев назад для решения проблем со сложными запросами.
• Платформа столкнулась с ограничениями одноузлового движка при масштабировании в облаке.
• Объем данных в DuckLake достиг 2 петабайт, около 1 триллиона строк и 15,3 миллиона снимков.
• Компания разработала собственную архитектуру на базе Trino и формат HogLake.

Проблемы одноузловой архитектуры в облаке

Хотя DuckDB отлично подходит для локального анализа данных на одном компьютере, в облачной среде ее использование оказалось сопряжено с серьезными трудностями. Клиенты запускали гораздо более сложные запросы, чем ожидали разработчики, что потребовало выделения огромных вычислительных экземпляров. Прогнозировать необходимые для каждого запроса ресурсы процессора и оперативной памяти оказалось крайне сложно, так как пользователи не должны самостоятельно заниматься распределением инфраструктуры.

Кроме того, в системе возникали узкие места при загрузке больших объемов данных из S3 без асинхронного режима. Из-за архитектурных особенностей одноузловых решений PostHog столкнулась с необходимостью предварительного выделения ресурсов воркеров до поступления самого запроса, что существенно снижало гибкость платформы и ухудшало пользовательский опыт.

Ограничения DuckLake и масштабируемость

В качестве основы для хранилища использовалось расширение DuckLake, однако на петабайтных масштабах PostHog стандартная схема каталога начала давать сбои. Поскольку формат должен оставаться универсальным для множества баз данных SQL, разработчики были ограничены в специфических оптимизациях. Запись в одну таблицу могла занимать более трех минут из-за постоянного пересчета статистики всего каталога.

Более 99% строк статистики каталога принадлежали уже удаленным таблицам, а очистка лишь временно ускоряла процессы записи. Постоянное поддержание совместимости с официальной схемой DuckLake привело к тому, что инженерам пришлось работать с собственным форком и кастомными патчами. Это лишило компанию главного преимущества использования готового сообщества.

Трудности с протоколом Postgres и сетевой инфраструктурой

Предоставление прямого доступа по протоколу Postgres через порт 5432 на практике оказалось гораздо сложнее, чем классические HTTP-соединения. Управление таймаутами простоя, обработка обрывов связи и масштабирование долгоживущих подключений потребовали огромных ресурсов. В отличие от HTTP, экосистема инструментов для балансировки нагрузки pgwire развита намного слабее.

Огромное разнообразие клиентов Postgres со специфическими требованиями к поведению заставило команду тратить много времени на исправление багов. В результате PostHog решила сосредоточиться на создании идеального продукта, а не на поддержке бесконечного хвоста совместимости с клиентами.

Что ждет пользователей дальше

Полученный опыт показал, что для клиентов важен не конкретный стек технологий под капотом, а надежный и стабильный результат. Команда полностью пересобрала систему на основе собственного варианта Trino и разработала новый открытый табличный формат HogLake. Новая инфраструктура уже прошла тестирование на петабайтных нагрузках внутри компании перед передачей первым партнерам.