1. Зачем мигрировать с ClickHouse
ClickHouse — мощный OLAP-движок для однотабличных агрегаций. Но при масштабировании аналитики появляются системные ограничения, которые вынуждают инженеров искать альтернативу.
Типичные причины миграции:
- JOIN performance: ClickHouse исторически слаб на multi-table JOIN. Обходной путь — денормализация, которая раздувает хранилище и усложняет ETL.
- Real-time updates: ReplacingMergeTree даёт eventual consistency. Partial update невозможен. SELECT ... FINAL убивает производительность чтения.
- SQL gaps: ~50% запросов TPC-DS не выполняются. Отсутствуют коррелированные подзапросы, сложные оконные функции.
- Операционная сложность: ручное шардирование, управление ZooKeeper/Keeper, нет автобалансировки.
- Дедупликация: OPTIMIZE FINAL для очистки дубликатов — неприемлемо для банковского сектора и финтеха.
- Зоопарк систем: ClickHouse часто дополняется Elasticsearch, Kafka, отдельным ETL — растёт сложность инфраструктуры.
2. Маппинг таблиц: MergeTree → Doris
Ядро миграции — маппинг движков таблиц ClickHouse на модели данных Doris:
| ClickHouse Engine | Doris Data Model | Поведение |
|---|---|---|
| MergeTree | Duplicate Key Model | Append-only, аналогичное поведение |
| ReplacingMergeTree | Unique Key Model | Мгновенная дедупликация через Delete Bitmap, без FINAL |
| AggregatingMergeTree | Aggregate Key Model | Преагрегация метрик при записи |
| SummingMergeTree | Aggregate Key Model (SUM) | Автоматическое суммирование при merge |
Partitioning: ClickHouse PARTITION BY → Doris PARTITION BY RANGE/LIST. Distribution: ClickHouse ORDER BY (sort key) → Doris DISTRIBUTED BY HASH. Materialized Views: обе системы поддерживают, но в Doris MV использует automatic query rewrite.
Пример преобразования CREATE TABLE:
// МАППИНГ: CLICKHOUSE → DORIS -- ClickHouse (before) CREATE TABLE events (
event_date Date,
user_id UInt64,
event_type String,
amount Float64
) ENGINE = ReplacingMergeTree()
PARTITION BY toYYYYMM(event_date)
ORDER BY (user_id, event_date);
-- Apache Doris (after) CREATE TABLE events (
event_date DATE,
user_id BIGINT,
event_type VARCHAR(128),
amount DOUBLE
) ENGINE = OLAP
UNIQUE KEY (user_id, event_date)
PARTITION BY RANGE (event_date) (...)
DISTRIBUTED BY HASH(user_id) BUCKETS 16; 3. SQL-адаптация: что меняется
Большинство стандартного SQL работает без изменений: SELECT, WHERE, GROUP BY, ORDER BY, оконные функции. Основные различия:
| ClickHouse | Apache Doris |
|---|---|
| UInt64 | BIGINT |
| String | VARCHAR(N) |
| Float64 | DOUBLE |
| toYYYYMM() | DATE_FORMAT() |
| arrayJoin() | LATERAL VIEW EXPLODE |
| SELECT ... FINAL | Не нужен (Unique Key дедуплицирует автоматически) |
JOIN-ы, которые в ClickHouse часто избегают из-за производительности, в Doris работают нативно с Cost-Based Optimizer. Настройки через SET (max_threads и др.) заменяются на session variables Doris.
4. Перенос данных: инструменты и подходы
Основные инструменты для миграции данных:
- X2Doris: Официальный инструмент миграции Doris: автоматический перенос схемы и данных.
- ClickHouse Catalog: Doris может читать таблицы ClickHouse напрямую через catalog federation — без копирования данных.
- Export/Import: ClickHouse → CSV/Parquet → Doris Stream Load. Подходит для одноразовой миграции.
- Flink CDC: Для live-миграции с параллельным чтением из обеих систем. Exactly-once гарантии.
Для больших датасетов рекомендуется параллельный Stream Load через Broker Load. Валидация: сравнение количества строк и контрольных сумм по ключевым колонкам.
5. Параллельная работа и тестирование
Рекомендуемая стратегия миграции в 5 фаз:
- Фаза 1 — Dual-write: новые данные пишутся в обе системы одновременно.
- Фаза 2 — Перенос исторических данных: batch-загрузка через Stream Load / Spark.
- Фаза 3 — Сравнение запросов: одни и те же запросы выполняются на обеих системах, сравниваются результаты и timing.
- Фаза 4 — Переключение: read-трафик переводится на Doris.
- Фаза 5 — Вывод ClickHouse из эксплуатации.
Ключевые метрики для сравнения: latency запросов, throughput, потребление ресурсов (CPU, RAM, диск).
6. Кейсы миграции
Kwai/Bleem: ClickHouse + ES → Doris
Унификация ClickHouse и Elasticsearch в единый Apache Doris. Триллионы строк рекламной аналитики, ~1 млрд запросов в день. Снижение latency на 64–90%, упрощение архитектуры.
Enterprise-миграции
Публичные кейсы на doris.apache.org: финтех, ритейл, телеком. Типичный результат — ускорение JOIN-запросов в 5–50 раз, снижение стоимости хранения на 40–60%.
Типичные сроки
От 2 до 8 недель в зависимости от объёма данных и количества запросов. Самая затратная часть — валидация SQL и нагрузочное тестирование. Частый бонус: JOIN-ы, невозможные в ClickHouse, открывают новые аналитические сценарии в Doris.
7. Production best practices после миграции
Рекомендации по оптимизации Doris после миграции:
- Compaction tuning: Doris автоматически компактит данные, но параметры можно настроить под профиль нагрузки.
- Materialized Views: создайте MV для часто используемых агрегаций — Doris автоматически переписывает запросы.
- Colocate Join: для крупных JOIN-ов между таблицами с одинаковым distribution key — данные на одних и тех же нодах.
- Мониторинг: Grafana + Doris metrics endpoint. Ключевые дашборды: query latency, compaction queue, BE node health.
- Backup: Doris backup/restore на HDFS/S3 для disaster recovery.