ClickHouse-тен Doris-қа: Kwai жарнама аналитикасын қалай біріктірді

Бөлшектенген стектен бірыңғай аналитикалық қозғалтқышқа

Kwai жарнама платформасы сыртқы жарнама берушілер мен e-commerce қызмет көрсетеді: науқандар, материалдар, ставкалар және тиімділікті онлайн бақылау. Деректер масштабы үлкен: материалдар бойынша триллиондар жол, тәулігіне ~300 млн жаңа жол, шамамен 700 негізгі өріс және 4000-нан астам сұрау үлгісі.

Мұндай real-time analytics деректерді материалдарға (науқан жүйесінен) және метрикаларға (тиімділік аналитикасына) бөледі. Үш фактор платформаға жүктеме берді:

• Көлем: материалдар бойынша жинақталған деректер — жүз миллиардтар жол, триллионға ұмтылыс; Kwai инфрақұрылымындағы ең ауыр footprint-тердің бірі.
• Өсу: тек 2025 жылдың Q1-інде материалдар бойынша тәуліктік жаңа дерек ағыны ж/ж 3,5 есе өсті — нақты уақытта жоғары жазу және икемді масштабтау қажет.
• Күрделі модель: материалдар, науқандар, пайдаланушылар және тиімділік өлшемдері бойынша жүздеген өріс; мыңдаған сұрау үлгілері қозғалтқыштың үйлесімділігі мен өнімділігіне қысым жасайды.

Apache Doris-қа дейінгі архитектура

Көшірілмей тұрғанда материалдар MySQL + Elasticsearch жұбында, тиімділік метрикалары ClickHouse-та болды.

Тиімділік есептері Elasticsearch материалдарын ClickHouse метрикаларымен JOIN қажет етті. Типтік сұрау Elasticsearch сыртқы кестесін (материалдар) және ClickHouse ішкі кестесін (метрикалар) қозғалтты. ClickHouse сыртқы кесте бөлігін талдап, Elasticsearch сұрауына аударып, HTTP арқылы жауап алды, блоктарға түрлендіріп, локальды деректермен қосуды орындады.

Elasticsearch өскен сайын архитектура төбеге тірелді:

• Сұраулардың деградациясы: 35%-ға дейін «баяу», орташа кідіріс 1,4 с.
• Сақтау: бір Elasticsearch шарды ~1 млрд жолдан асқан жиындарды көтермеді; масштабтау = қымбат деректерді қайта бөлу.
• Операциялық күрделілік: тізбектегі көп компонент — көбірек мониторинг пен сүйемелдеу.
• Бақылау: ClickHouse пен Elasticsearch арасындағы сквозной трасссыз кідіріс пиктері мен десинхронды талдау созылды.

Балама бағалау

Жаңа жүйе үшін мақсаттар анық қойылды:

• Баяу сұраулар үлесі < 5%
• Мәселелерді талдау — минуттарда, сағаттар емес
• Бір кестелі жиындарды триллиондар жолға дейін қолдау
• Деректердің жаңалығы — 5 минут ішінде

Стресс-тесттерде Doris, ClickHouse, Elasticsearch және басқа OLAP қозғалтқыштар салыстырылды: жазу, оқу кідірісі, компрессия және толық мәтінді іздеу. ClickHouse материалдардың біріншілік кіліді бойынша жиі жаңартуларға сай unique key моделінің жоқтығынан шықты. Фокус Elasticsearch пен Apache Doris жұпына ауды.

Doris критерийлер жиынтығы бойынша күшті болып шықты және барлық мақсатты метрикаларды жапты — сондықтан оны жарнама аналитикасының келесі буын қозғалтқышы ретінде таңдады.

Bleem: Apache Doris негізіндегі бірыңғай қозғалтқыш

Технология таңдалғаннан кейін ClickHouse пен Elasticsearch Apache Doris арқылы ауыстырылып, Bleem бірыңғай аналитикалық қабаты құрылды. Сыртқы кестелерге дерек кэші және метадеректер сервисі қосылды, lake-кестелеріне сұрауларды ішкі кестелерге жақындату үшін.

Төменнен жоғары Bleem архитектурасы:

• Сақтау қабаты: HDFS көлінде — Hive / Hudi; ішкі кестелер — object storage-та compute/storage бөлу режимінде немесе байланысты режимде локальды дискілерде.
• Кэш: сыртқы Hive/Hudi кестелерінің деректері тұрақты I/O үшін Alluxio-да кэштеледі.
• Есептеу: ядро — Apache Doris; әртүрлі командаларға оқшауланған кластерлер, compute сұрау бойынша масштабталады. Ішкі және сыртқы Hive/Hudi кестелеріне lakehouse сұраулары екі deployment режимінде де.
• Сервистік қабат: метадеректер кэші Hive өзгерістерімен нақты уақытта синхрондалады.
• Қолжетімділік: OneSQL шлюзі — кластерлер бойынша маршрутизация, сұрауларды қайта жазу және materialized views, авторизация, rate limit және circuit breaker.

Нәтижесінде бөлшектенген сценарийлер бір қозғалтқышқа жиналды: көл, нақты уақытта OLAP, онлайн есептер және толық мәтінді іздеу.

Архитектура деңгейінде бекітілді:

• Баяу сұраулар < 5%, жалпы сұрауларды жеделдету шамамен 20–90%.
• Көлдененді масштабтау бұрынғы Elasticsearch схемасына қарағанда шамамен 10 есе тиімдірек, триллиондық кестелерді қолдай отырып.
• Эксплуатация қарапайым: барлық сұрау түрлері үшін бір қозғалтқыш, аз тәуелділік.
• Толық бақылау: Doris бойынша end-to-end трассировка және мониторинг troubleshooting орташа уақытын шамамен 80% қысқартты.

Көшіру және оптимизация

Көшіруді бизнес үрдістерін үзбей үш фазаға бөлді:

• 1-фаза — пилот: keyword promotion сценарийі; толық және инкрементті жүктеу pipeline-дары; деректердің сәйкестігі мен сұраулардың дұрыстығы бойынша параллельді «қосарлы» валидация.
• 2-фаза — ядро: «ClickHouse + Elasticsearch-пен join» тізбегінің көшірілуі, барлық материалдардың Elasticsearch-тен Doris-қа импорты, cutover кейін Elasticsearch кластерінің сөндірілуі.
• 3-фаза — толық қамту: тек ClickHouse-та қалған сценарийлер (ES-пен join жоқ) — біріктіруді аяқтау.

Келесі — көшіру барысындағы негізгі техникалық шешімдер.

Деректер сәйкестігі: таратылған құлпылар

Ағынды синхронизация Apache SeaTunnel арқылы, батчтар үшін — қайта жазу семантикасы; импорттар eventual consistency үшін two-phase commitпен жүрді. SeaTunnel + Spark байланысында шекаралық жағдайларда дубликаттар шықты:

• Spark speculative execution: екі тапсырма нұсқасы Doris-та commit-ке дейін жетуі мүмкін — деректер екі рет жазылды, бірақ Driver бір әрекетті санады.
• Commit кейін тапсырма құлауы: орындаушы Doris-та commit жасап үлгерсе, бірақ Driver-ға хабарламағанда, Driver тапсырманы қайта іске қосып, сол деректерді қайта commit етеді.

Шешім — екіфазалы коммит айналасында ZooKeeper таратылған құлпы:

1. Commit алдында ZK-да ephemeral lock алу — commit ағында бір уақытта бір транзакция.
2. Қолға түскеннен кейін Prepare күйі мен транзакция ID ephemeral түйінге жазылсын.
3. Алдыңғы транзакция күйін салыстыру:
   • алдыңғы жоқ — ағымдыны commit етеміз;
   • алдыңғы Prepare-да — оны rollback, содан кейін ағымдыны commit;
   • алдыңғы Committed — ағымдыны rollback (дубликат).
4. Операцияны ZK persistent түйініне Commit жазуымен аяқтау.

Жоғары жазуға Stream Load

Жазуда жоғары бәсекелестік үшін Doris-та Stream Load бапталды: тапсырмалардың приоритеттері мен compaction параметрлері өткізу қабілетін және тұрақтылықты арттырды. Планировщик Load Channel қолданады — жоғары және қалыпты приоритет үшін бөлек арналар: егер Stream Load timeout < 300 с болса, тапсырма жоғары приоритетті саналады.

Параметрлер жиынтығының мысалы:

load_task_high_priority_threshold_second=300
compaction_task_num_per_fast_disk=16
max_base_compaction_threads=8
max_cumu_compaction_threads=8

Кестелерді жобалау: материалдар және метрикалар

Екі дерек класы үшін әртүрлі модель таңдалды.

Жарнама материалдары кестесі — жиі жаңартулар және ірі масштабта іздеу:

Бизнес-сұрауларда сүзу негізінен MySQL id автоинкременті емес, account_id бойынша. Doris-та prefix index және sort key үшін account_id бастапқы (account_id, id) күрделі кілі және account_id бойынша bucket алынды. Көпөлшемді іздеу үшін инвертірленген индекстер, ZSTD — көлем мен I/O теңгерімі.

-- Материалдар кестесі: Unique Key + inverted index
CREATE TABLE ad_core_winfo
(account_id BIGINT NOT NULL,
id BIGINT NOT NULL,
word STRING,
INDEX idx_word (`word`) USING INVERTED...)
UNIQUE KEY(account_id, id)
DISTRIBUTED BY HASH(account_id) BUCKETS 1000;

Тиімділік метрикалары кестесі — көп өлшем бойынша агрегациялар:

Aggregate моделі, күн немесе сағат бойынша автопартициялау.

-- Метрикалар: Aggregate + auto partition
CREATE TABLE ad_dsp_report
(__time DATETIME,
account_id BIGINT, ...
`ad_dsp_cost` BIGINT SUM,
...)
AGG KEY(__time, account_id, ...)
AUTO PARTITION BY RANGE(date_trunc(`__time`, 'hour'))()
DISTRIBUTED BY HASH(account_id) BUCKETS 2;

Ірі аккаунттар бойынша деректердің skew-ы

Стресс-тесттерде бұрылу ашылды: account_id бойынша көлемдер бірнеше жолдан миллиондарға дейін — BE-та CPU дисбалансы күшті. SHOW DATA SKEW 3–4 ГБ tablet'тарды 100–200 МБ-қа қарсы көрсетті; «ауыр» аккаунттардың сұраулары баяулады.

A. Account ID бойынша range-партициялау

Аккаунт ID-лері — 5–8 цифр (10-нан аспайды). FROM_UNIXTIME арқылы уақыт типіне аударып, айларға кесті: 33 тарихи партиция, партицияға дейін 2 592 000 аккаунт; жаңа партиция шамамен әр 2 млн жаңа аккаунтта қажет. Тарихи партициялар көлем бойынша қолмен бакеттелді, жаңалары әдепкі 256 бакет. Бұл материалдар бойынша тәулігіне ~300 млн жаңа жолда тиімді partition pruning берді.

B. Екіншілік хештеу

Партиция ішіндегі «киттерді» жаю үшін mod өрісі ID MOD 7 ретінде енгізілді (id account_id-тан тәуелсіз), мәндер 0–6. Тарату кілті бір account_id-тан (account_id, mod)-қа ауыстырылды — бір жарнама берушінің деректері 7 BE-қа бөлінеді.

Доработкалардан кейін tablet көлемі шамамен 1 ГБ тұрақтанды, CPU жүктемесі теңесті.

10 000+ партицияда сұрауларды жоспарлау

Партициялар санының өсуі жаңа тармақшаны берді: қарапайым point-сұраулар мақсат < 100 мс кезінде 250 мс алды. Doris 2.1-де партицияларды кесу тізім бойынша сызықты өтумен жүргізілді — он мыңдаған партицияда бұл қымбаттады.

Команда партицияларды сұрыптап, толық скан орнына екілік іздеуді қолданды: күрделілік O(n)-тен O(log n)-ге, кідіріс 250 мс-тен ~12 мс-қа (шамамен 20×). Өзгеріс Apache Doris 3.1 релизіне енді.

Конкуренттілікті баптау

Парадокс: ірі аккаунттар үшін де сүзуден кейін миллиондаған жол қалса, сұрау профилінде Total Instance 800-ге дейін жетті әдепкі конкуренттілік 32 себебінен — кіші нәтиже үшін артық параллелизм RPC пен кідірісті көбейтті.

Параллелизмді төмендету:

set global parallel_exchange_instance_num=5;
set global parallel_pipeline_task_num=2;

Total Instance 800-ден 17-ге түсті; point-сұраулар кідірісі 220 мс-тен ~147 мс-қа, кластердегі QPS қоры өсті.

Нәтижелер және жоспарлар

Толық көшіру мен тюнингтен кейін сандар жоғарыдағы негізгі KPI-мен сәйкестенді: кідірістер −64…90%, >3× жазу, Elasticsearch-пен салыстырғанда ~60% сақтау үнемі, триллиондық кестелер комфортты режимде.

Doris бойынша жоспарда екі бағыт:

• Толық мәтін және токенизация: BM25 (Doris 4.0), әртүрлі сценарийлер үшін IK сияқты токенайзерлер.
• Векторлық іздеу: ішкі және сыртқы lake-кестелерінде vector search валидациясы мен оптимизациясы Apache Doris 4.0 мүмкіндіктері негізінде.

Қорытынды

Kwai кейсі ClickHouse пен Elasticsearch-ті бір Apache Doris-та біріктіру есептерді жеделдетуге, сақтауды үнемдеуге және толық сквозной бақылауға мүмкіндік беретінін көрсетеді. Материалдар, метрикалар, lakehouse-SQL және толық мәтінді іздеу бір контурға сыйады.

Apache Doris туралы толығырақ — Apache Doris Slack қауымдастығында. Басқарылатын сервис — VeloDB Cloud.

Дереккөз

Zhou Simin, «From ClickHouse + Elasticsearch to Apache Doris: How Kwai Unified Trillion-Scale Ad Analytics», VeloDB Blog, 2026-03-20.

https://www.velodb.io/blog/from-clickhouse-elasticsearch-to-apache-doris-how-kwai-unified-trillion-scale-ad-analytics