1. ClickHouse-тен неге көшу керек
ClickHouse — бір кестелі агрегациялар үшін қуатты OLAP-қозғалтқыш. Бірақ аналитиканы кеңейткенде жүйелік шектеулер пайда болады.
Көшудің типтік себептері:
- JOIN өнімділігі: ClickHouse multi-table JOIN-да тарихи түрде әлсіз. Шешім — денормализация, ол қоймаушылықты ісіріп, ETL-ді қиындатады.
- Real-time жаңартулар: ReplacingMergeTree eventual consistency береді. Partial update мүмкін емес. SELECT ... FINAL оқу өнімділігін бұзады.
- SQL олқылықтары: TPC-DS сұраныстарының ~50% орындалмайды. Коррелирленген ішкі сұраныстар, күрделі терезе функциялары жоқ.
- Операциялық күрделілік: қолмен шардтау, 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 автоматты дедупликациялайды) |
ClickHouse-те өнімділік себебінен жиі болдырмайтын JOIN-дар Doris-те Cost-Based Optimizer-мен нативті жұмыс істейді. SET арқылы баптаулар (max_threads т.б.) Doris session variables-ке ауысады.
4. Деректерді тасымалдау: құралдар мен тәсілдер
Деректерді көшірудің негізгі құралдары:
- X2Doris: Doris-тің ресми көшіру құралы: схема мен деректерді автоматты тасымалдау.
- ClickHouse Catalog: Doris ClickHouse кестелерін catalog federation арқылы тікелей оқи алады — деректерді көшірусіз.
- Export/Import: ClickHouse → CSV/Parquet → Doris Stream Load. Бір реттік көшіру үшін жарамды.
- Flink CDC: Екі жүйеден параллель оқумен live-көшіру үшін. Exactly-once кепілдіктері.
Үлкен деректер жиынтықтары үшін Broker Load арқылы параллель Stream Load ұсынылады. Валидация: жол санын салыстыру және негізгі колонкалар бойынша бақылау сомалар.
5. Параллель жұмыс және тестілеу
5 фазалы ұсынылатын көшіру стратегиясы:
- 1-фаза — Dual-write: жаңа деректер бір уақытта екі жүйеге жазылады.
- 2-фаза — Тарихи деректерді тасымалдау: Stream Load / Spark арқылы batch-жүктеу.
- 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 валидациясы мен жүктеме тестілеу. Жиі бонус: ClickHouse-те мүмкін болмаған JOIN-дар Doris-те жаңа аналитикалық сценарийлер ашады.
7. Көшуден кейінгі Production практикалары
Көшуден кейін Doris-ті оңтайландыру ұсыныстары:
- Compaction tuning: Doris деректерді автоматты компактілейді, бірақ параметрлерді жүктеме профиліне баптауға болады.
- Materialized Views: жиі қолданылатын агрегациялар үшін MV жасаңыз — Doris сұраныстарды автоматты қайта жазады.
- Colocate Join: бірдей distribution key бар кестелер арасындағы ірі JOIN-дар үшін — деректер бір нодтарда.
- Мониторинг: Grafana + Doris metrics endpoint. Негізгі дашбордтар: query latency, compaction queue, BE node health.
- Backup: disaster recovery үшін Doris backup/restore HDFS/S3-ке.