Apache Iceberg — табличный формат для озёр данных с поддержкой ACID, Schema Evolution, Hidden Partition и версионирования, но при больших метаданных и работе через S3 страдает планирование запросов и латентность. В связке со StarRocks мы показываем, как распределённый Job Plan, Manifest Cache, CBO с гистограммами, Data Cache и материализованные представления выводят lakehouse‑аналитику на уровень DWH: снижают накладные расходы на метаданные, ускоряют планы и выполнение, а запись обратно в Iceberg сохраняет единый источник истины. Разбираем архитектуру Iceberg, типовые узкие места и практики оптимизации на StarRocks 3.2–3.3, включая кейс WeChat/Tencent.

In the big data era, data is one of the most valuable assets for enterprises. The ultimate goal of data analytics is to power swift, agile business decision making. As database technologies advance at a breathtaking pace in recent years, a large number of excellent database systems have emerged. Some of them are impressive in wide-table queries but do not work well in complex queries. Some support flexible multi-table queries but are held back by slow query speed.

Each type of data has a data model that best represents them. However, in real business scenarios, there is no such thing as ultra-fast data analytics under the perfect data model. Big data engineers sometimes have to make compromises on data models. Such compromises may cause long latency in complex queries or damage the real-time query performance because engineers must take the trouble to convert complex data models into flat tables.

New business requirements put forward new challenges for database systems. A good OLAP database system must be able to deliver excellent performance in both wide-table and multi-table scenarios. This system must also reduce the workload of big data engineers and enable customers to query data of any dimension in real time without worrying about data construction.

Apache Druid has been a staple for real-time analytics. However, with evolving and sophisticated analytics demands, it has faced challenges in satisfying modern data performance needs. Enter StarRocks, a high-performance, open-source analytical database, designed to adeptly meet the advanced analytics needs of contemporary enterprises by offering robust capabilities and performance.

In this article, we’ll explore the functionalities, strengths, and challenges of both Apache Druid and StarRocks. Using practical examples and benchmark results, we aim to guide you in identifying which database might best meet your data needs.

Практический гид по быстрому запуску StarRocks Lakehouse с Apache Paimon. Вы узнаете, как построить единую пакетную и потоковую обработку (batch/stream) на базе ACID-хранилища с поддержкой schema evolution и Time Travel, разберетесь в моделях таблиц (Primary Key, Append, Append Queue) и стратегиях compaction. Пошагово настроим Flink, Kafka, Paimon и StarRocks, создадим топик и генератор данных, соберем Flink SQL‑пайплайн и выполним запросы из StarRocks, включая Read-Optimized и инкрементальное чтение.

Импорт терабайтов из S3 одним SQL: INSERT FROM FILES и PIPE. Партиционирование через date_trunc(), RANDOM‑бакетизация, трансформации с JOIN/UNNEST и гибкий ALTER TABLE.

Задача: быстро выполнять агрегирующие запросы (JOIN, GROUP BY, COUNT) по десяткам миллионов строк в офлайновых сценариях на Big Data‑платформе. Мы сравнили три подхода: Parquet + Impala в экосистеме CDH, MPP‑движок Greenplum и MPP‑СУБД StarRocks. В единой тестовой среде (SAD ~7 млн, ITEM ~3 млн записей) выполнили серию запросов JOIN + GROUP BY + ORDER BY и замерили суммарное время 10 прогонов. Показано, что внедрение MPP заметно ускоряет аналитику (типично 1–2 с на запрос), при этом StarRocks в среднем немного обходит Greenplum. В статье — методика, параметры развертывания, нюансы импорта из Oracle (CloudCanal) и сводные метрики.

Сравнение ClickHouse и StarRocks: архитектура и функциональность, типы join и модели данных (широкая таблица vs звезда), конкурентность, частые обновления (Primary Key, Merge‑on‑Read), администрирование и онлайн‑масштабирование. Приводим результаты бенчмарков SSB и TPC‑H, а также тесты загрузки (GitHub dataset). Все тестовые данные и конфигурации актуальны на 2022 год. Если вам интересно, воспроизведите эксперименты по актуальным инструкциям проектов и поделитесь результатами и замечаниями — это поможет уточнить выводы и обновить сравнение.

StarRocks Lakehouse на практике: пошаговый гайд по интеграции с Apache Hive через Hive Catalog. На прикладочном сценарии «управление заказами» показываем, как построить слой ODS/DWD/DWS/ADS в озере данных и ускорить запросы без миграции данных: от создания таблиц и генерации тестовых наборов до подключения External Catalog. Разбираем включение Data Cache для ускорения чтения из HDFS/S3/OSS (Parquet/ORC/CSV) и применение асинхронных материализованных представлений в StarRocks для витрин DWD/DWS/ADS. Поясняем, как добиться быстрых запросов за счёт векторизированного движка и CBO, а также даём практические советы по настройке (Kerberos/HMS, конфигурация BE/FE, прогрев кэша, сбор статистики, MV‑rewrite). Материал будет полезен инженерам по данным и архитекторам DWH, которым нужна аналитика в реальном времени по данным озера без лишнего ETL.

При пиковых нагрузках отчётные и аналитические системы сталкиваются с лавиной схожих агрегирующих запросов: растёт загрузка CPU и увеличиваются задержки. В StarRocks эту проблему решает Query Cache — кэширование промежуточных результатов агрегаций в памяти с их последующим переиспользованием. В реальных сценариях даёт 3–17× ускорение, работает для семантически эквивалентных запросов, перекрывающихся партиций и append-only данных. Внутри — лучшие практики, пример настройки и метрики диагностики.

Это обзор двух проектов аналитических СУБД с открытым исходным кодом, которые развиваются в одном классе задач, но различаются архитектурой, приоритетами и типичными сценариями применения. Ниже — нейтральное сравнение по ключевым аспектам: архитектура и запросный движок, хранение и работа в реальном времени, интеграция с открытыми форматами и lakehouse, производительность, эксплуатация и управление, а также рекомендации по выбору в зависимости от нагрузки.

Ниже — выверенная и локализованная на русский язык версия текста об оптимизации производительности СУБД. Термины без устойчивых русских эквивалентов сохранены на английском с первым пояснением.

Как StarRocks добивается высокой производительности JOIN-запросов в аналитических нагрузках. В материале — практическая кухня оптимизатора: какие типы JOIN эффективнее и когда их стоит конвертировать (например, CROSS→INNER, OUTER→INNER при NULL‑отвергающих предикатах), как работает predicate pushdown, извлечение предикатов из OR, вывод эквивалентностей и pushdown LIMIT. Разбираем Join Reorder для многотабличных запросов (Left‑Deep, Exhaustive, Greedy, DPsub), модель стоимости (CPU*(Row(L)+Row(R))+Memory*Row(R)) и выбор лучшего плана.

На уровне распределённого исполнения — MPP‑архитектура, свойства распределения (Distribution Property) и узлы Exchange; пять базовых планов: Shuffle, Broadcast, Bucket Shuffle, Colocate и экспериментальный Replicate Join. Плюс Global Runtime Filter (Min/Max, IN, Bloom) для ранней фильтрации на Scan. Даем практические принципы: используйте более быстрые типы JOIN, стройте хеш по малой таблице, в многоJOINовых запросах сперва выполняйте высокоселективные соединения, сокращайте объём данных и сетевой трафик. Материал для инженеров данных, DBA, разработчиков OLAP и всех, кто проектирует производительные SQL‑планы.

Материализованные представления в StarRocks упрощают моделирование данных, ускоряют запросы и повышают актуальность данных в lakehouse‑архитектуре. Разбираем базовые возможности MV, три практических сценария — моделирование, прозрачное ускорение и «lake + warehouse» — и даём ссылки на актуальные рекомендации для StarRocks 3.5.

Проект Trino (ранее PrestoSQL) изначально разработан в Meta, чтобы аналитики могли выполнять интерактивные запросы по широкому спектру хранилищ данных на базе Apache Hadoop. Благодаря эффективной обработке крупных наборов и сложных запросов, а также гибкому подключению к множеству источников данных, Trino быстро стал предпочтительным инструментом аналитики для крупных организаций.

Со временем потребности пользователей в аналитике эволюционировали. С ростом мобильного интернета и SaaS-приложений критически важной стала оперативная (в том числе потоковая) аналитика. Компаниям потребовались более производительные движки, поддерживающие большое число одновременных запросов и обеспечивающие низкие задержки. На этом фоне всё больше пользователей стали искать альтернативы.

StarRocks как новый аналитический движок получил широкое признание отрасли. Он демонстрирует заметные преимущества по производительности, поддержке высокой степени параллелизма и низкой задержке, привлекая внимание крупных компаний, таких как WeChat , Xiaohongshu (RedNote), Ctrip, Beike и др. Как именно StarRocks формирует свои преимущества? В чём его сходства и различия с Trino? Ниже — подробный разбор.

StarRocks 3.5 приносит точечные улучшения по надёжности, производительности и безопасности: кластерные Snapshot для DR в архитектуре shared-data (разделение хранения и вычислений), оптимизацию пакетной загрузки (Load Spill) для сокращения мелких файлов и пропуска Compaction, более гибкое управление жизненным циклом партиций (слияние по времени и автоматический TTL), многооператорные транзакции для ETL, ускорение запросов по озеру данных через автоматические глобальные словари, а также поддержку OAuth 2.0 и JWT.

Bank of Hangzhou Consumer Finance, являясь лицензированной организацией потребительского финансирования, всегда сохраняла сильный дух технологических инноваций, занимая второе место в отрасли по количеству патентов. Столкнувшись с вызовами, связанными с быстрым ростом бизнеса, компания начала трансформацию своей инфраструктуры данных, кульминацией которой стало создание платформы GLH Lakehouse на базе Mirrorship.