ClickHouse — один из самых мощных аналитических баз данных в мире, предоставляющий возможность обработки реального времени с тысячами запросов в секунду. Однако при масштабировании больших аналитических проектов, где данные непрерывно поступают и обрабатываются несколькими слоями таблиц и materialized views (материализованными представлениями), возникает непростая задача: как аккуратно и эффективно обновлять структуру базы данных без остановки потоков данных и без значительных затрат ресурсов. Компания Tinybird, работая с крупными проектами, столкнулась с этим вызовом, когда при первой реализации автоматизации миграций в ClickHouse использовала подход «мигрировать всё». Этот метод подразумевал создание новых таблиц и materialized views для каждого изменения схемы с последующим полным переносом и переобработкой всех данных — от исходных необработанных таблиц до самых агрегированных. Такая система работала безопасно, но оказалась катастрофически неэффективной: даже небольшие изменения могли приводить к миграции десятков терабайт данных, что длилось несколько суток и забирало колоссальные ресурсы.
Корень проблемы лежал в самой природе ClickHouse и его материализованных представлениях. В отличие от классических ETL-систем, где данные обрабатываются пакетами, materialized views в ClickHouse срабатывают мгновенно на каждую вставку. Это обеспечивает низкие задержки и оперативность, однако создает сложную цепочку зависимостей между таблицами. Любое изменение в одном элементе цепочки требует аккуратного пересоздания downstream ресурсов, чтобы сохранить непрерывность и корректность данных. Tinybird начал с построения сложной модели зависимости между таблицами на уровне схемы — так называемого графа зависимостей, отражающего все связи между исходными таблицами, материализованными представлениями, копиями, источниками данных и конечными точками запроса.
В первоначальной версии каждый элемент цепочки мигрировался полностью, чтобы гарантировать целостность и точность данных, что делало систему надежной, но крайне медленной и дорогой. Оптимизация началась с внедрения умных триггеров миграций. Tinybird выделил изменение именно тех элементов, которые требуют обновления схемы и обработки новых данных: источники данных, движки таблиц и materialized views. Остальные компоненты — такие как конечные точки, копии и интеграции — стали обновляться без запуска процесса миграции данных, что существенно ускорило обновления. Далее Tinybird определил концепцию ingestion chains — цепочек источников данных и materialized views, которые необходимо мигрировать совместно.
В результате при изменении лишь в одной цепочке остальные независимые части схемы остались нетронутыми. Однако настоящий прорыв случился при внедрении механизма распределения миграции по уровню цепочки. Ранний подход предполагал миграцию всей цепочки, начиная от самых нижних, «посадочных» таблиц с необработанными данными. Обычно это самые крупные таблицы, зачастую с десятками терабайт информации, например Kafka-таблицы с неагрегированными событиями. Tinybird понял, что при добавлении новой колонки или изменении схемы в условной «пользовательской сессии» вовсе необязательно начинать миграции с самой крупной таблицы.
Инновационная идея заключалась в том, чтобы идентифицировать точку самого верхнего изменения в цепочке и запускать миграцию только начиная с этого элемента вниз по цепочке, оставляя необработанные upstream таблицы без изменений. Для обеспечения связности данных между старой и новой схемой была реализована так называемая cross-version bridging — мост между версиями. Materialized view на границе изменений читает данные из старой версии upstream таблицы и пишет их уже в новую таблицу с обновленной схемой. Такой подход решил одновременно несколько проблем. Во-первых, он сократил объем переносимых данных на несколько порядков, поскольку самая тяжелая часть с необработанными данными практически не задействовалась.
Во-вторых, он обеспечил непрерывность потока событий и корректность данных, которые продолжают читаться и вставляться в соответствующие версии таблиц. В-третьих, производительность запросов сохранялась благодаря созданию специальных UNION VIEW, объединяющих данные из старых и новых таблиц без задержек. Миграции при помощи вспомогательных таблиц и UNION VIEW стали краеугольными камнями для Tinybird. Это позволило обеспечить плавное переключение от старой схемы к новой, избегая дублей данных и потерь информации. При этом система поддерживала параллельную запись в обе версии таблиц временно, пока процесс backfill — интерпретация и миграция исторических данных — не был завершен.
Сложности при реализации cross-version bridging потребовали серьезных архитектурных решений. Например, materialized view, находящееся на стыке версий, должно уметь одновременно читать с одной версии таблицы и записывать в другую, обеспечивая консистентность данных и быструю обработку как исторических, так и real-time записей. Tinybird также планирует дальнейшие улучшения. Одним из перспективных направлений является детектирование «добавочных» изменений в downstream таблицах, например добавления новых колонок, при которых можно обходиться без миграции, обеспечивая соответствие схемы на этапе чтения. Кроме того, учитывая практику короткого времени жизни данных в ряде таблиц (TTL), компания разрабатывает возможность пропуска миграции исторических данных, трансформируя только свежие и новые записи, что дополнительно ускорит обновления.
Преимущества подхода Tinybird очевидны для любых объемов данных и сложных архитектур. Значительное сокращение времени развертывания — c дней до минут — открывает путь к более частым обновлениям, экспериментам и улучшениям, сохраняя стабильность и производительность. Таким образом, Tinybird демонстрирует, как глубокое понимание особенностей работы ClickHouse и творческий подход к автоматизации миграций позволяют превратить потенциально длительный и рискованный процесс в управляемую и эффективную операцию. Использование dependency graphs, smart triggers, ingestion chains, вспомогательных таблиц и cross-version bridging формирует новый стандарт автоматизации обновления схем в OLAP-системах реального времени. Для разработчиков и архитекторов крупных данных в ClickHouse подход Tinybird служит примером, как с минимальными потерями ресурсов и без простоев обеспечить гибкость в развитии аналитических платформ.
Рынок технологий анализа данных стремительно развивается, и способность быстро и безопасно менять схемы становится решающим конкурентным преимуществом. Начать работу с Tinybird можно легко, подключившись к их сервису и воспользовавшись бесплатным планом, что позволит уже сегодня почувствовать преимущества описанных инновационных методик обновления данных в реальном времени. Современная аналитика требует именно таких революционных подходов, соединяющих надежность с гибкостью и масштабируемостью.
