1. ClickHouse dan nega koʼchish kerak
ClickHouse — bitta jadval agregatsiyalari uchun kuchli OLAP-dvigatel. Lekin analitikani kengaytirganda tizimli cheklovlar paydo boʼladi.
Koʼchishning tipik sabablari:
- JOIN unumdorligi: ClickHouse multi-table JOIN da tarixan zaif. Yechim — denormalizatsiya, u omborni shishiradi va ETL ni qiyinlashtiradi.
- Real-time yangilanishlar: ReplacingMergeTree eventual consistency beradi. Partial update mumkin emas. SELECT ... FINAL oʼqish unumdorligini buzadi.
- SQL kamchiliklari: TPC-DS soʼrovlarining ~50% bajarilmaydi. Korrelatsiyalangan ichki soʼrovlar, murakkab oyna funksiyalari yoʼq.
- Operatsion murakkablik: qoʼlda shardlash, ZooKeeper/Keeper boshqarish, avtobalansrovka yoʼq.
- Deduplikatsiya: dublikatlarni tozalash uchun OPTIMIZE FINAL — bank sektori va fintech uchun yaroqsiz.
- Tizimlar hayvonot bogʼi: ClickHouse koʼpincha Elasticsearch, Kafka, alohida ETL bilan toʼldiriladi — infratuzilma murakkablashadi.
2. Jadval mappingi: MergeTree → Doris
Koʼchishning asosi — ClickHouse jadval dvigatellarini Doris maʼlumot modellariga mapping:
| ClickHouse Engine | Doris Data Model | Xulq-atvor |
|---|---|---|
| MergeTree | Duplicate Key Model | Append-only, oʼxshash xulq-atvor |
| ReplacingMergeTree | Unique Key Model | Delete Bitmap orqali lahzali deduplikatsiya, FINAL kerak emas |
| AggregatingMergeTree | Aggregate Key Model | Yozish paytida metrikalarni preagregatsiya |
| SummingMergeTree | Aggregate Key Model (SUM) | Merge paytida avtomatik qoʼshish |
Partitioning: ClickHouse PARTITION BY → Doris PARTITION BY RANGE/LIST. Distribution: ClickHouse ORDER BY (sort key) → Doris DISTRIBUTED BY HASH. Materialized Views: ikkala tizim ham qoʼllab-quvvatlaydi, lekin Doris MV automatic query rewrite ishlatadi.
CREATE TABLE oʼzgartirish misoli:
// MAPPING: 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-moslash: nima oʼzgaradi
Standart SQL ning koʼp qismi oʼzgarishsiz ishlaydi: SELECT, WHERE, GROUP BY, ORDER BY, oyna funksiyalari. Asosiy farqlar:
| ClickHouse | Apache Doris |
|---|---|
| UInt64 | BIGINT |
| String | VARCHAR(N) |
| Float64 | DOUBLE |
| toYYYYMM() | DATE_FORMAT() |
| arrayJoin() | LATERAL VIEW EXPLODE |
| SELECT ... FINAL | Kerak emas (Unique Key avtomatik deduplikatsiya qiladi) |
ClickHouse da unumdorlik sababli koʼpincha qochiladigan JOIN lar Doris da Cost-Based Optimizer bilan nativ ishlaydi. SET orqali sozlamalar (max_threads va h.k.) Doris session variables ga almashadi.
4. Maʼlumotlarni koʼchirish: asboblar va yondashuvlar
Maʼlumotlarni koʼchirishning asosiy asboblari:
- X2Doris: Doris ning rasmiy koʼchirish asbobi: sxema va maʼlumotlarni avtomatik tashish.
- ClickHouse Catalog: Doris ClickHouse jadvallarini catalog federation orqali toʼgʼridan-toʼgʼri oʼqiy oladi — maʼlumotlarni koʼchirmasdan.
- Export/Import: ClickHouse → CSV/Parquet → Doris Stream Load. Bir martalik koʼchirish uchun mos.
- Flink CDC: Ikkala tizimdan parallel oʼqish bilan live-koʼchirish uchun. Exactly-once kafolatlar.
Katta maʼlumotlar toʼplamlari uchun Broker Load orqali parallel Stream Load tavsiya etiladi. Validatsiya: qatorlar sonini solishtirish va asosiy ustunlar boʼyicha nazorat summalari.
5. Parallel ishlash va test qilish
5 bosqichli tavsiya etilgan koʼchish strategiyasi:
- 1-bosqich — Dual-write: yangi maʼlumotlar bir vaqtda ikkala tizimga yoziladi.
- 2-bosqich — Tarixiy maʼlumotlarni koʼchirish: Stream Load / Spark orqali batch-yuklash.
- 3-bosqich — Soʼrovlarni solishtirish: bir xil soʼrovlar ikkala tizimda bajariladi, natijalar va timing solishtiriladi.
- 4-bosqich — Oʼtish: read-trafik Doris ga yoʼnaltiriladi.
- 5-bosqich — ClickHouse ni foydalanishdan chiqarish.
Solishtirish uchun asosiy metrikalar: soʼrov latency, throughput, resurs isteʼmoli (CPU, RAM, disk).
6. Koʼchish keyslari
Kwai/Bleem: ClickHouse + ES → Doris
ClickHouse va Elasticsearch ni bitta Apache Doris ga birlashtirish. Trillionlab reklama analitikasi qatorlari, kuniga ~1 mlrd soʼrov. Latency 64–90% kamaydi, arxitektura soddalashdi.
Enterprise-koʼchirishlar
doris.apache.org dagi ommaviy keyslar: fintech, riteyler, telekom. Tipik natija — JOIN-soʼrovlarning 5–50 barobar tezlashuvi, saqlash narxining 40–60% kamayishi.
Tipik muddatlar
Maʼlumotlar hajmi va soʼrovlar soniga qarab 2 dan 8 haftagacha. Eng qimmat qism — SQL validatsiyasi va yuklanish testi. Koʼp hollarda bonus: ClickHouse da mumkin boʼlmagan JOIN lar Doris da yangi analitik ssenariylar ochadi.
7. Koʼchishdan keyingi Production amaliyotlari
Koʼchishdan keyin Doris ni optimallashtirish tavsiylari:
- Compaction tuning: Doris maʼlumotlarni avtomatik kompaktlaydi, lekin parametrlarni yuklama profiliga sozlash mumkin.
- Materialized Views: tez-tez ishlatiladigan agregatsiyalar uchun MV yarating — Doris soʼrovlarni avtomatik qayta yozadi.
- Colocate Join: bir xil distribution key li jadvallar orasidagi yirik JOIN lar uchun — maʼlumotlar bir xil nodlarda.
- Monitoring: Grafana + Doris metrics endpoint. Asosiy dashboardlar: query latency, compaction queue, BE node health.
- Backup: disaster recovery uchun Doris backup/restore HDFS/S3 ga.