Примечание (Latest‑3.5): Текст основан на возможностях StarRocks 3.0. За актуальными возможностями материализованных представлений (MV) в StarRocks 3.5 и практиками ускорения запросов к data lake см. документацию: Latest‑3.5 MV — Data Lake Query Acceleration with Materialized Views: https://docs.mirrorship.cn/docs/using_starrocks/async_mv/use_cases/data_lake_query_acceleration_with_materialized_views/
Сегодня компании при анализе данных сталкиваются с множеством проблем и вызовов, и обработка данных как неотъемлемая часть этого процесса имеет особое значение.
Первый ключевой вызов — сложность обработки данных. От момента появления данных до получения ценности цепочка остается сложной, включает множество этапов и технических решений, что повышает технологическую сложность и, как следствие, усложняет трудозатраты. Эта сложность мешает конечным пользователям достичь цели «сделать данные доступными» (Make Data Accessible) и ограничивает дальнейшие инвестиции в инфраструктуру данных.
Второй вызов — производительность, актуальность и стоимость. Пользователи ожидают высокопроизводительную платформу с данными в реальном времени и одновременно — низкую стоимость. Между этими требованиями есть техническое противоречие: невозможно на 100% удовлетворить их все одновременно. Однако по мере эволюции технологий этот компромисс удаётся всё лучше балансировать, а на разных этапах приходится решать разные задачи.
Чтобы закрыть неудовлетворённые потребности, StarRocks 3.0 предложил новую архитектуру единого lakehouse, призванную лучше помогать управлять крупномасштабными корпоративными данными. В этом подходе материализованные представления играют ключевую роль: они снижают сложность обработки данных, повышают производительность запросов и улучшают актуальность данных, позволяя вместе с апгрейдом архитектуры получить и апгрейд пользовательского опыта.
В этой статье мы рассмотрим:
почему вам нужен новый lakehouse‑подход StarRocks;
базовые возможности материализованных представлений StarRocks;
три типовых сценария применения MV;
эволюцию MV в StarRocks.
Новая lakehouse‑парадигма StarRock
StarRocks 3.0 предлагает новую lakehouse‑парадигму, чтобы снизить сложность «цепочки» дата‑инжиниринга и улучшить производительность. Суть lakehouse — в объединении преимуществ озера данных и хранилища данных:
Преимущества хранилища: качество данных, производительность запросов, аналитика в реальном времени, управление данными. Цель — за счёт тщательного моделирования и обработки обеспечить высокое качество данных.
Преимущества озера: открытая экосистема, гибкая унификация, масштабируемость, выгодная стоимость. Цель — за счёт инклюзивного хранения уместить больше данных.
На основе этой идеи проявляются важные практические принципы:
Единое хранение и единые запросы: детальные, архивные и полуструктурированные данные хранятся в озере, а детально обработанные — в хранилище. Используется единый вычислительный движок для запросов и аналитики.
Снижение сложности обработки: большую часть вычислительных нагрузок можно исполнять внутри lakehouse без отдельных систем обработки (например, Hive или Spark).
Более доступный по стоимости конвейер данных (data pipeline): цепочка от генерации и сбора до обработки и монетизации данных становится сквозной в рамках lakehouse‑«конвейера», что снижает стоимость и повышает актуальность.
Лучший баланс производительности, стоимости и свежести данных: объединение real‑time запросов, инкрементальных вычислений и batch‑обработки в одном конвейере избавляет от выбора между разрозненными системами и сводит задачу к настройке параметров.
Роль MV (материализованных представлений) в этом подходе:
MV для моделирования данных: декларативное моделирование без необходимости поддерживать ETL‑конвейер ради самого моделирования — это повышает качество данных и производительность запросов.
MV для прозрачного ускорения: по требованию можно ускорять запросы без предварительного управления данными (data governance) и моделирования данных, сокращая время и стоимость подготовки.
MV для инкрементальных вычислений: инкрементальный конвейер повышает актуальность и снижает сквозную задержку.
Примечание (Latest‑3.5): Единый паттерн «lake + warehouse» эволюционирует. Рекомендации по созданию MV для ускорения запросов к данным из data lake (Hive/Iceberg/Hudi) в StarRocks 3.5 см. в руководстве.
Далее — базовые возможности MV, решаемые ими задачи и практические сценарии.
Базовые возможности материализованных представлений
Рассмотрим базовую функциональность на примере ключевых возможностей:
Materialized (материализация): результат вычислений сохраняется в таблицу StarRocks; структура хранения не отличается от обычной таблицы.
Partition by: партиционирование MV (например, по дням) позволяет обновлять, обслуживать и применять TTL (Time to Live) на уровне партиции. Партиции MV можно сопоставлять с партициями внешних таблиц Hive/Iceberg, автоматически «подписываясь» на их обновления.
Обновление (REFRESH): пересчёт и материализация результата запроса. Поддерживаются автообновление, обновление по расписанию, ручной запуск и инкрементальное обновление в ряде сценариев. Например, можно триггерить обновление при загрузке данных, настраивать ежечасное расписание или запускать из внешней системы оркестрации.
Resource Group: типичная боль — изоляция ресурсов между фронтовыми запросами и обслуживанием MV. В StarRocks это решается через Resource Group с эластичной изоляцией и планированием, чтобы обслуживание MV не влияло на производительность пользовательских запросов.
Запросы и источники: MV поддерживают агрегирование, JOIN, оконные функции (WINDOW) и т. п., материализуя результаты для широкого круга сценариев. Источники данных — JDBC‑внешние таблицы (например, MySQL, PostgreSQL), lake‑внешние таблицы (Hive, Iceberg), а также собственные таблицы StarRocks.
На поверхности MV — это предвычисление результатов по заданной пользователем политике REFRESH, чтобы избегать повторных вычислений. Ключевые способности: планирование, предвычисления и инкрементальные вычисления.
Важнейшая возможность скрыта за лаконичным синтаксисом — переписывание запросов: оптимизатор автоматически сопоставляет ускоряемые SQL‑запросы и переписывает их так, чтобы использовать предвычисленные результаты, резко снижая затраты. Это открывает новое: пользователь может тюнить производительность без изменения SQL, гибко балансируя стоимость и производительность.
Комбинируя эти атомарные возможности, MV закрывают два ключевых класса проблем.
Сложность обработки данных:
MV описывают обработку декларативно: пользователю достаточно понимать итог, не детализируя сложные процессы.
REFRESH абстрагирует поток данных; нет нужды управлять зависимостями между системами и решать сложные задачи качества данных.
Изоляция ресурсов упрощается благодаря вертикальной интеграции — для простых вычислений не нужно выделять дополнительные мощности.
«Прозрачное ускорение» избавляет от предварительного моделирования: модель и ускорение добавляются по мере эволюции бизнеса, существенно снижая трудозатраты на управление данными.
Производительность, актуальность и стоимость:
Больше не нужно выбирать между потоковой и пакетной системами: стабильной и дешёвой batch или более дорогой, но актуальной stream. Разные режимы REFRESH сводят задачу к выбору параметров под нужный сценарий.
Далее — практические сценарии, где MV наиболее полезны.
Сценарии применения MV
01. Моделирование данных
Моделирование данных — это очистка, многослойная организация, агрегация и связывание данных для получения удобных к использованию результатов. Зачем это нужно?
исходные данные часто страдают от проблем качества и плохо подходят для прямой аналитики;
«сырые» данные слишком сложны, содержат множество нерелевантных бизнесу показателей и трудны для понимания;
без агрегирования запросы медленны, не удовлетворяют требованиям производительности и потребляют много ресурсов.
Типичное противоречие — моделирование не поспевает за бизнесом, сложно оценить его окупаемость. На ранних этапах ресурсы ограничены и ценность моделирования неочевидна; бизнес‑модель быстро меняется, требуя итераций. Поэтому часто данные используют «как есть», что ведёт к проблемам качества и производительности; когда же потребность в моделировании становится явной, сложившиеся практики использования мешают рефакторингу.
Материализованные представления снимают эти противоречия:
Упрощение архитектуры: не нужно поддерживать отдельный зоопарк компонентов для обработки, оркестрации и мониторинга.
Упрощение использования: достаточно базового SQL — задачи решают аналитики, а не только узкие дата‑инженеры.
Упрощение сопровождения: MV поддерживают линейдж данных (data lineage), автоматически управляют зависимостями — не нужна целая платформа для этого.
Рассмотрим два базовых подхода — моделирование по слоям и по партициям.
Моделирование по слоям
В реальных ландшафтах источники включают потоковые детальные данные, данные измерений (справочники), архив из озера данных; на стороне бизнеса требуются разные способы аналитики: real‑time дашборды, BI‑запросы почти в реальном времени, ad hoc‑запросы аналитиков, периодические отчёты и т. п. Требования различаются: гибкость, производительность, стоимость.
Единого средства недостаточно, поэтому StarRocks совместно использует логическое представление (View) и материализованное представление (Materialized View, MV):
View — логическое: каждый запрос повторно парсит и выполняет его определение. Хорош для выражения бизнес‑семантики и упрощения SQL, но не снижает стоимость выполнения.
MV — предвычисляет результат, избегая повторных затрат и ускоряя выполнение; хорошо подходит для упрощения ETL‑конвейера.
Как это ложится на слои:
View для конечных пользователей: гибко меняется и предоставляет чистую бизнес‑семантику.
View для real‑time: связывает потоковые детальные данные и данные измерений, отдавая максимально актуальный результат.
MV для ускорения «почти real‑time»: когда вычисления сложны, часть их предвычисляется для ускорения конечных запросов.
MV для физического моделирования: помимо логики, моделирование требует физической подготовки данных.
Итог: в зависимости от требований к актуальности и производительности бизнес гибко выбирает комбинации View и MV для послойного моделирования. Кроме того, StarRocks позволяет гибко менять как верхние, так и нижние View/MV — в отличие от классического ETL‑конвейера, где малое изменение затрагивает всё, здесь изменения делаются простым SQL.
Моделирование по партициям
Помимо слоёв, моделирование часто требует связывать данные по бизнес‑семантике и задавать TTL в зависимости от требований к свежести — это и есть моделирование по партициям.
Разные способы связывания формируют схему «звезда» и «снежинка»; базовые сущности — факт‑таблица и таблицы измерений. Где‑то есть несколько очень больших факт‑таблиц; где‑то — сложные таблицы измерений и связи. MV StarRocks поддерживают партиционное согласование с факт‑таблицей: факт партиционируется, и результат JOIN в MV партиционируется аналогично.
Это открывает несколько полезных сценариев:
Обновления факта: при мелкозернистом партиционировании (день/час) MV автоматически обновляет соответствующие партиции после обновления факта.
Обновления измерений: изменение измерений часто требует пересчёта всех связанных результатов — это дорого; можно игнорировать обновления некоторых измерений или пересчитывать только недавний период.
Автообновление внешних таблиц: системы вроде Hive/Iceberg меняют данные на уровне партиций; MV «подписываются» на такие изменения и обновляются при изменении партиции.
TTL: при партиционировании MV можно задавать TTL и хранить только результаты за недавний период — полезно, когда нужны, например, только данные за последнюю неделю.
Итоги (возможности MV для моделирования данных):
Много источников: MV создаются поверх внутренних таблиц, lake‑внешних и JDBC‑внешних таблиц (MySQL, PostgreSQL), а также источников Hive/Iceberg; зависимости данных управляются автоматически.
Сопоставление партиций: поддерживается соответствие партиций между внутренними и внешними таблицами, обновления MV на уровне партиций.
Автообновление: MV могут автоматически обновляться при изменениях источников.
Многослойное моделирование: поддержка многоуровневых MV по слоям ODS, DWD, DWS, ADS; гибкое сочетание View и MV.
Оркестрация задач: поддержка триггерного, DAG‑ориентированного и периодического расписания под разные бизнес‑семантики.
02. Прозрачное ускорение
Моделирование сложно «подружить» с гибкостью бизнеса: на ранних этапах объёмы малы и неопределённость высока — данные используют «грубо»; позже растут требования к производительности и масштабы, возникает потребность в моделировании, но платформы уже сформированы, и рефакторинг дорог.
StarRocks решает это с помощью прозрачного ускорения на базе MV:
Прозрачное ускорение: оптимизатор автоматически переписывает SQL и подбирает подходящее MV — без изменения исходного SQL пользователем.
Создание по требованию: не нужно заранее планировать все сценарии и запросы — при обнаружении узких мест создаётся MV для оптимизации.
Отложенное моделирование: MV по сути — предвычисление и моделирование ради ускорения, но отложив этот шаг, легче удовлетворить разные потребности на разных этапах, избегая избыточных затрат.
Пример: создадим MV с группировкой по lo_orderdate и c_city и расчётом count — и прозрачно ускорим три класса запросов:
Пример 1 — роллап‑агрегирование (roll‑up): требуется агрегирование по lo_orderdate. На базе MV выполняется дополнительный роллап; так как MV уже резко сократило объём данных, вторичный роллап лёгкий.
Пример 2 — роллап с фильтрацией: отбор части периодов и агрегирование по c_city; выполняется поверх MV — фильтрация, затем вторичный роллап.
Пример 3 — фильтрация: отбор части периодов и агрегирование; поскольку MV уже сгруппировано по lo_orderdate, можно напрямую отфильтровать результат.
Все эти фильтрации и роллапы выполняются оптимизатором StarRocks автоматически, без сложной переписки SQL и без необходимости глубоко разбираться в семантике запросов. Помимо агрегирующих переписываний, поддерживаются и другие: автоматическое переписывание JOIN для «широких» таблиц и переписывание UNION для временных рядов. Об этом — в отдельных материалах.
Итог: с прозрачным ускорением MV задача моделирования во многом превращается в задачу оптимизации производительности. Когда возникает потребность, анализируются сценарии и запросы, создаётся подходящее MV — оценка ценности моделирования становится проще, а избыточное планирование и дизайн — не нужны.
03. Единый lakehouse
Наконец, как MV помогают по‑настоящему объединить озеро и хранилище:
Единое хранение и запросы: детальные, архивные и полуструктурированные данные — в озере; детально обработанные — в хранилище. Используется единый вычислительный движок, а MV соединяют слои.
Гибкое моделирование через MV: повышение качества данных в озере и производительности запросов.
Прозрачное ускорение по требованию через MV: меньше предварительного управления и моделирования, ниже стоимость и время подготовки.
Эволюция MV в StarRocks
Функция MV появилась в StarRocks 2.4 и прошла ряд итераций:
V2.4 — базовые возможности, поддержка партиционного согласования.
V2.5 — переписывание запросов, поддержка множества источников (JDBC/Hive), поддержка CTE/WINDOW/UNION и др. конструкций SQL.
V3.0 — поддержка сценариев многослойного моделирования, подписка на обновления Hive, улучшенные удобство и наблюдаемость.
Примечание (Latest‑3.5): Актуальные изменения и расширения MV в StarRocks 3.5 (режимы REFRESH, правила переписывания, поддержка источников data lake) смотрите в документации.
Дальнейшие направления развития:
Удобство: «готово из коробки» и комплексные решения «всё‑в‑одном» под конкретные сценарии.
Переписывание запросов: больше поддерживаемых случаев и автоматические рекомендации.
Интеграция с озером: автообновление для Iceberg/Hudi и др. источников — более оперативные REFRESH.
Инкрементальные вычисления: больше сценариев, ещё выше актуальность данных в реальном времени.
Итоги
StarRocks стремится, с одной стороны, помочь пользователям обновить архитектуру за счёт единого lakehouse, а с другой — с помощью материализованных представлений упростить работу с данными, повысить эффективность затрат и раскрыть большую ценность данных.
Мы выпустим серию материалов о MV с подробными примерами функций и применения. Присоединяйтесь к сообществу и подписывайтесь на наш официальный канал, чтобы получать новости первыми!
