Миграция с Greenplum. Эпизод I: Атака клонов и спасение на звёздных камнях

• Cascades-оптимизатор отрабатывает многотабличные JOIN-ы по той же логике, что ORCA в Greenplum — с переоценкой порядка по статистикам и broadcast/shuffle-решениями.
  
• Распределение задается явно на уровне DDL (DISTRIBUTED BY HASH(col) BUCKETS N) — у ClickHouse шардирование настраивается серверно.
  
• Репликация работает per-tablet — знакомая концепция после mirror-сегментов.
  
• План в EXPLAIN читается фрагментами с exchange-операторами вместо motion: знакомые приемы отладки перекосов, broadcast/redistribute-решений и колокации переносятся напрямую.

-- Greenplum
CREATE TABLE fact_orders (
    order_id bigint,
    customer_id bigint,
    amount numeric,
    dt date
)
DISTRIBUTED BY (customer_id);
-- StarRocks
CREATE TABLE fact_orders (
    order_id bigint,
    customer_id bigint,
    amount decimal(18,2),
    dt date
)
DUPLICATE KEY(order_id)
PARTITION BY date_trunc('day', dt)
DISTRIBUTED BY HASH(customer_id) BUCKETS 32;

• Distribution key обычно переносится 1:1
  
• Bucket count: документация рекомендует 100 MB–1 GB сжатых данных на tablet (физическое воплощение bucket). Если получилось меньше числа BE-узлов, то надо взять число BE. С v2.5.7 есть auto-bucketing — можно положиться на него вместо ручного расчета.
  
• DISTRIBUTED REPLICATED прямого аналога не имеет: для маленьких справочников StarRocks обычно сам выбирает broadcast join (по умолчанию, исходя из размера таблицы), либо можно подсказать через broadcast hint.

• AO column-таблицы переезжают почти прозрачно, так как то же колоночное хранение и похожие кодеки;
  
• AO row превращается в Duplicate Key с колоночным форматом;
  
• heap с частыми UPDATE/DELETE — отдельный случай: нужна Primary Key модель или пересмотр архитектуры (если таблица была мелкая транзакционная — она может вообще не уехать на DWH-движок).

• Range/list переносятся почти один в один;
  
• Expression-partitioning может упростить часть DDL: там, в Greenplum делали через cron-jobs или ручные ALTER TABLE ADD PARTITION;
  
• Прямого аналога ALTER TABLE EXCHANGE PARTITION в StarRocks нет. ETL-паттерн переписывается на TEMPORARY PARTITION + INSERT OVERWRITE: данные собираются во временную партицию, затем одной командой атомарно подменяется целевая.

• Duplicate Key — все строки сохраняются как есть, повторы не убираются. Подходит для логов и event-данных.
  
• Aggregate Key — преагрегация на вставке (SUM/MAX/MIN/REPLACE). Подходит для метрик.
  
• Unique Key — последняя запись побеждает (last-write-wins). Подходит для CDC-таблиц и slowly changing dimensions.
  
• Primary Key — ACID на уровне строки, поддерживает UPDATE/DELETE, оптимизирован под точечные запросы по ключу. Подходит для таблиц с частыми UPDATE/DELETE и нагрузок, где много точечных чтений.

• SELECT в той же транзакции не видит данные, измененные предыдущими DML (Limited READ COMMITTED).
  
• DML на одну таблицу — один тип: после UPDATE/DELETE нельзя сделать INSERT в ту же таблицу в той же транзакции.
  
• Только одна БД: cross-database транзакций нет.
  
• INSERT OVERWRITE в транзакции запрещен: атомарную подмену партиции придется делать отдельным шагом.
  
• Нет DDL внутри транзакции, savepoint, REPEATABLE READ.

• Выбор табличной модели — основное решение для каждой таблицы. Логи и сырые события в Duplicate Key. Метрики с агрегацией на вставке в Aggregate Key. Dimensions с семантикой последняя запись побеждает (last-write-wins) в Unique Key. Транзакционные таблицы и таблицы под частые UPDATE → Primary Key.
  
• Мульти-табличные транзакции в простых случаях (несколько INSERT в одной БД с возможным rollback) теперь покрываются нативно с v3.5. Сложные паттерны все равно переезжают в оркестратор с atomic-цепочками в Airflow / DolphinScheduler / dbt и компенсирующими шагами.

• ETL-оркестратор (Airflow, DolphinScheduler, dbt) — то, что было multi-step ETL-процедурами. Это самый большой кусок: SCD-функции, daily aggregations, snapshot processing.
  
• UDF (Java/Python) — точечные функции, которые вызываются из SQL и не зависят от данных в других таблицах. Маппинг 1:1 с PL/pgSQL функциями, возвращающими scalar или table.
  
• Materialized views — то, что было MV с manual refresh. В StarRocks MV умеют auto-refresh и auto-rewrite, и часть логики, которая раньше требовала процедуры, описывается декларативно.

• Sort key — основной механизм пропуска данных, задается при создании таблицы. Работает как кластерный индекс: данные физически отсортированы, сканирование по диапазону sort-ключа эффективно.
  
• Bloom filter — для high-cardinality колонок, по которым часто идут точечные запросы.
  
• Bitmap index — в целом, это тот же класс ускорения фильтров, но переносить GP bitmap indexes механически не стоит: сначала нужно понять, что они закрывали.
  
•  Prefix index — автоматический, на основе sort-key.
  
• Inverted index (с 3.3) — для full-text search по строковым колонкам.

• MV переезжают с упрощением — то, что было manual REFRESH, в StarRocks становится async с auto-rewrite. Часть MV-логики, реализованной в Greenplum через процедуры, в StarRocks описывается одной CREATE MATERIALIZED VIEW.
  
•  Индексы переписываются под другой паттерн. Btree редко нужен — sort key закрывает большинство случаев сканирования. Expression-индексы прямого аналога не имеют, выносятся в обычные колонки или MV. GIN-индексы тоже прямого аналога не имеют: для text search есть inverted index, для других случаев перепроектируется схема.
  
• Стратегия: сначала описать sort key для каждой таблицы под основной запросный паттерн, потом точечно добавить bloom/bitmap по горячим точкам.

• Multi-Warehouse (StarRocks Enterprise) — физически отдельные пулы compute-нод: ETL на своих, дашборды на своих. Данные общие, ресурсы раздельные.
  
• Resource Groups — логические лимиты CPU, памяти и concurrency внутри одного пула.
  
• Query Queues — если пороги превышены, запросы встают в очередь, а не роняют систему.
  
• Pipeline DOP — динамически подстраивает параллелизм под текущую нагрузку.
  
• Spill to Disk— тяжелые JOIN / AGG / SORT уходят на диск вместо OOM.
  
• Big Query Kill — автоматически прерывает запросы по лимитам памяти, CPU или scan rows.

• Mirror-сегменты — каждый primary segment имеет фиксированный mirror на другом узле. Failover автоматический.
  
• Standby master — резервная master-нода с журналом, может перехватить роль координатора, failover ручной.
  
• gpbackup/gprestore — параллельный backup всего кластера (или отдельных схем/таблиц) с компрессией и шифрованием.

• Tablet replication — каждый таблет реплицируется N раз (по умолчанию 3). Это N-replica с автоматическим распределением реплик по BE-узлам — модель отличается от fixed-pair mirror в Greenplum. При падении узла остальные реплики продолжают обслуживать запросы; поврежденные таблеты восстанавливаются автоматически.
  
• FE high availability — несколько FE-нод в режиме leader/follower через BDBJE-консенсус. При падении leader-FE один из follower-FE поднимается автоматически.
  
• Backup в объектное хранилище (для shared-nothing) — BACKUP и RESTORE команды загружают snapshot в S3-совместимое хранилище. Поддерживается резервное копирование per-table или per-database. В shared-data режиме вместо BACKUP/RESTORE используется отдельный механизм Cluster Snapshot.
  
• Резервный кластер на случай падения основного — два кластера с асинхронной репликацией по расписанию (например, каждые 15 минут). Одна команда переключает резервный в активный режим: допустимая потеря данных — от 15 минут, восстановление занимает минуты. Резервный кластер доступен на чтение в обычном режиме. Доступно в StarRocks Enterprise (Mirrorship EE с версии 3.3.5) и в Selena Lakehouse.

• Расписание бэкапов переезжает в BACKUP-команды StarRocks с целевым S3-хранилищем;
  
• Mirror-сегменты Greenplum концептуально становятся 3-replica tablet'ами в StarRocks (можно настроить и больше реплик для критичных таблиц);
  
• Standby master заменяется на multi-FE setup; рекомендуется минимум 3 FE-ноды для отказоустойчивости;

• VACUUM для heap-таблиц — освобождает мертвые строки после UPDATE/DELETE. На больших таблицах работает часами, и без него таблицы растут на диске.
  
• ANALYZE — пересчет статистики для оптимизатора. Нужен после массовых изменений данных, иначе планы запросов деградируют.
  
• VACUUM FULL / REINDEX — на сильно фрагментированных таблицах. Блокирующая операция.
  
• gp_toolkit / gp_segment_configuration — мониторинг состояния кластера, ребалансировка.

• Compaction (cumulative + base) — автоматическая в фоне. Не нужно ничего запускать руками.
  
• Auto-stats — статистика собирается в фоне, оптимизатор всегда видит свежие данные.
  
• REFRESH MV — async MV обновляются автоматически по расписанию или event-driven, без ручных действий.