ClickHouse անալիտիկայի համար

01Գաղափարը՝ սյունակներ, ոչ թե տողեր

Պատկերացրեք մեկ միլիարդ page view-ի աղյուսակ։ «Դիտումներ ըստ երկրի անցյալ շաբաթ» հարցին պատասխանելու համար տողային պահոցը պետք է կարդա յուրաքանչյուր տող՝ իր բոլոր քսան սյունակներով։ Սյունակային պահոցը յուրաքանչյուր սյունակ պահում է իր ֆայլում․ այն կարդում է միայն ամսաթիվը և երկիրը, ինչը տվյալների չնչին մասն է։ Մեկ սյունակի արժեքները նման են (շատ կրկնվող երկրներ), այնպես որ դրանք չափազանց լավ են սեղմվում, և CPU-ն կարող է դրանք մշակել batch-երով՝ vectorized հրահանգներով։ Փոխզիջումը՝ մեկ ամբողջական տող բերելը կամ թարմացնելը ավելի դանդաղ է, և ClickHouse-ը նախատեսված չէ բազմաթիվ փոքր տրանզակցիոն update-ների համար։ OLTP-ն (պատվերներ, օգտատերեր) մնում է ձեր ռելյացիոն բազայում, OLAP-ը (պատմության մասին հարցեր) գալիս է այստեղ։

• OLTP՝ առանձին գրառումների բազմաթիվ փոքր ընթերցումներ և գրառումներ՝ տրանզակցիաներով։
• OLAP՝ քիչ, բայց մեծ հարցումներ, որոնք սկանավորում և ագրեգացնում են բազմաթիվ գրառումներ։
• Vectorized execution՝ մեկ CPU գործողությամբ արժեքների բլոկի մշակում՝ մեկ առ մեկի փոխարեն։

02MergeTree աղյուսակներ և sorting key-ը

Գրեթե յուրաքանչյուր աղյուսակ օգտագործում է MergeTree ընտանիքի engine։ Յուրաքանչյուր insert գրում է անփոփոխ part՝ դասավորված ըստ ORDER BY key-ի, և ֆոնային merge-երը փոքր part-երը միավորում են ավելի մեծերի։ Primary index-ը sparse է․ այն պահում է մեկ գրառում յուրաքանչյուր granule-ի համար (լռելյայն 8,192 տող), այնպես որ բավականաչափ փոքր է հիշողության մեջ մնալու համար։ Երբ հարցումը ֆիլտրում է ORDER BY-ի առաջատար սյունակներով, ClickHouse-ը բաց է թողնում այն granule-ները, որոնք չեն կարող համընկնել։ Հետևաբար ORDER BY-ի ընտրությունը դիզայնի ամենակարևոր որոշումն է․ առաջինը դրեք ցածր cardinality ունեցող սյունակները, որոնցով միշտ ֆիլտրում եք (tenant, իրադարձության տիպ), ապա ժամանակը։ PARTITION BY-ը տվյալների կառավարման համար է (հին ամիսները ջնջելու), ոչ թե արագության․ partition-ները պահեք խոշոր։

1CREATE TABLE events
2(
3    tenant_id   UInt32,
4    event_type  LowCardinality(String),
5    event_time  DateTime64(3, 'UTC'),
6    user_id     UInt64,
7    url         String,
8    country     LowCardinality(String),
9    properties  JSON
10)
11ENGINE = MergeTree
12PARTITION BY toYYYYMM(event_time)
13ORDER BY (tenant_id, event_type, event_time)
14TTL toDateTime(event_time) + INTERVAL 13 MONTH DELETE;

03Տվյալների ճիշտ insert

ClickHouse-ը սիրում է մեծ batch-եր և ատում է փոքր insert-ները։ Յուրաքանչյուր INSERT ստեղծում է առնվազն մեկ part, և վայրկյանում հազարավոր մեկ տողանոց insert-ները ստեղծում են հազարավոր part-եր, ինչը հրահրում է հայտնի «too many parts» սխալը։ Batch արեք client-ի կողմում (յուրաքանչյուր insert-ում հազարավորից մինչև հարյուր հազարավոր տող, մոտավորապես վայրկյանը մեկ անգամ) կամ միացրեք asynchronous insert-ները, որպեսզի սերվերը ձեր փոխարեն buffer անի փոքր գրառումները։ Տվյալները սովորաբար գալիս են հերթի միջոցով (Kafka, Redis-ի վրա հիմնված worker, HTTP collector-ներ) և flush են արվում batch-երով։ JSONEachRow, CSV, Parquet և native ձևաչափերն աջակցվում են HTTP-ով (8123 պորտ) կամ native պրոտոկոլով (9000)։

1# Batch insert over HTTP from a file of JSON lines
2curl -u your_user:your_password \
3  'http://localhost:8123/?query=INSERT%20INTO%20events%20FORMAT%20JSONEachRow' \
4  --data-binary @events.ndjson
5 
6-- Or let the server batch small inserts
7INSERT INTO events SETTINGS async_insert = 1, wait_for_async_insert = 1
8FORMAT JSONEachRow {"tenant_id":1,"event_type":"page_view","event_time":"2026-11-05 10:00:00","user_id":7,"url":"/","country":"AM","properties":{}}

04Անալիտիկ SQL

ClickHouse-ը խոսում է SQL՝ բազմաթիվ անալիտիկ հավելումներով։ uniq()-ը և uniqExact()-ը հաշվում են եզակի օգտատերերին (uniq-ը մոտավոր է և շատ ավելի արագ), quantile()-ը հաշվում է պերցենտիլներ, countIf()-ը և sumIf()-ը ֆիլտրում են ագրեգատների ներսում, իսկ windowFunnel()-ը և retention()-ը ուղղակիորեն պատասխանում են պրոդուկտային հարցերին։ Զանգվածներն ու map-երը առաջին կարգի են, և JSON տիպը կիսակառուցվածքային հատկությունները պահում է որպես տիպավորված sub-column-ներ։ Միշտ ֆիլտրեք ORDER BY-ի առաջատար սյունակներով և ժամանակային միջակայքով, ընտրեք միայն ձեզ անհրաժեշտ սյունակները (երբեք SELECT * լայն աղյուսակի վրա) և ուսումնասիրելիս օգտագործեք LIMIT։

1SELECT
2    toStartOfDay(event_time)                      AS day,
3    uniq(user_id)                                 AS visitors,
4    countIf(event_type = 'purchase')              AS purchases,
5    round(purchases / visitors * 100, 2)          AS conversion_pct
6FROM events
7WHERE tenant_id = 1
8  AND event_time >= now() - INTERVAL 30 DAY
9GROUP BY day
10ORDER BY day;

05Materialized view-եր արագ dashboard-ների համար

ClickHouse-ում materialized view-ը insert trigger է․ երբ տողերը ժամանում են աղբյուր աղյուսակ, view-ն իր SELECT-ն աշխատեցնում է միայն այդ նոր batch-ի վրա և արդյունքը գրում թիրախային աղյուսակ։ SummingMergeTree-ի կամ AggregatingMergeTree-ի հետ համատեղ սա նախապես ագրեգացված rollup-ները (ըստ ժամի, ըստ tenant-ի) միշտ արդի է պահում, այնպես որ dashboard-ները կարդում են հազարավոր տողեր՝ միլիարդների փոխարեն։ Գրելիս օգտագործեք -State combinator-ները, իսկ կարդալիս՝ -Merge, քանի որ տարբեր part-երի մասնակի ագրեգատները պետք է միավորվեն։ Հիշեք, որ view-ն տեսնում է միայն նոր insert-ները․ պատմական տվյալները backfill արեք առանձին INSERT INTO ... SELECT-ով։

1CREATE TABLE events_hourly
2(
3    tenant_id UInt32, hour DateTime, event_type LowCardinality(String),
4    events UInt64, users AggregateFunction(uniq, UInt64)
5)
6ENGINE = AggregatingMergeTree ORDER BY (tenant_id, event_type, hour);
7 
8CREATE MATERIALIZED VIEW events_hourly_mv TO events_hourly AS
9SELECT tenant_id, toStartOfHour(event_time) AS hour, event_type,
10       count() AS events, uniqState(user_id) AS users
11FROM events GROUP BY tenant_id, hour, event_type;
12 
13-- Read: SELECT hour, sum(events), uniqMerge(users) FROM events_hourly WHERE tenant_id = 1 GROUP BY hour;

06Շահագործում՝ մեկ node, կլաստեր կամ ամպ

Մեկ ClickHouse սերվերը կարողանում է շատ ավելին, քան թիմերի մեծ մասն է սպասում, հաճախ միլիարդավոր տողեր մեկ մեքենայի վրա՝ արագ NVMe սկավառակներով։ Բարձր հասանելիության համար օգտագործեք ReplicatedMergeTree աղյուսակներ՝ համակարգված ClickHouse Keeper-ի կողմից (ZooKeeper-ի ներկառուցված փոխարինիչը)․ ավելի շատ տարողության համար տվյալները shard արեք node-երի միջև Distributed աղյուսակով։ ClickHouse Cloud-ը տարանջատում է պահոցը (object storage) հաշվարկից և հեռացնում է այս աշխատանքի մեծ մասը՝ օգտագործման վրա հիմնված գնով։ Ինչ էլ ընտրեք՝ ստեղծեք նվազագույն արտոնություններով օգտատերեր, 8123 և 9000 պորտերը պահեք հանրային ինտերնետից դուրս, յուրաքանչյուր օգտատիրոջ համար սահմանեք հարցումների սահմաններ (max_memory_usage, max_execution_time) և backup արեք BACKUP TO S3-ով կամ ձեր provider-ի snapshot-ներով։

07Part-եր, granule-ներ և ինչպես է հարցումը բաց թողնում տվյալները

Սկավառակի վրա յուրաքանչյուր part թղթապանակ է՝ յուրաքանչյուր սյունակի համար մեկ ֆայլով (wide format), գումարած primary.idx և mark ֆայլեր։ Mark-երը մատնացույց են անում յուրաքանչյուր granule-ի սկիզբը սեղմված սյունակային ֆայլերի ներսում։ Հարցման ժամանակ ClickHouse-ը primary.idx-ով binary search է անում այն granule-ների միջակայքը, որոնց ORDER BY արժեքները կարող են համընկնել, կարդում է միայն այդ granule-ների mark-երը և ապասեղմում միայն պահանջված սյունակների այդ բլոկները։ Data-skipping ինդեքսները (minmax, set, bloom_filter) ավելացնում են granule-ային ամփոփումներ sorting key-ից դուրս սյունակների համար։ Օգտագործեք EXPLAIN indexes = 1՝ տեսնելու, թե ընդհանուրից քանի part և granule է ընտրվել․ granule-ների 95%-ն ընտրող ֆիլտրը քողարկված full scan է։

1EXPLAIN indexes = 1
2SELECT count() FROM events
3WHERE tenant_id = 1 AND event_time >= now() - INTERVAL 1 DAY;
4 
5-- A skipping index for a column outside ORDER BY
6ALTER TABLE events ADD INDEX idx_url url TYPE bloom_filter GRANULARITY 4;
7ALTER TABLE events MATERIALIZE INDEX idx_url;

08Դեդուպլիկացիա և փոփոխվող տվյալներ՝ ReplacingMergeTree և ընկերներ

ClickHouse-ը չի պարտադրում եզակի key-եր։ ReplacingMergeTree-ն պահում է վերջին տողը յուրաքանչյուր ORDER BY key-ի համար՝ ընտրված version սյունակով, բայց միայն merge-երից հետո, որոնք տեղի են ունենում անհայտ ժամանակ։ Ճշգրիտ արդյունքներ պահանջող հարցումներն օգտագործում են FINAL (որը merge է անում ընթերցման ժամանակ․ վերջին տարբերակներում այն շատ ավելի արագ է, բայց դեռ արժե) կամ ագրեգացնում են argMax(value, version)-ով։ CollapsingMergeTree-ն և VersionedCollapsingMergeTree-ն update-ները մշակում են sign -1-ով չեղարկող տող insert անելով։ Replicated աղյուսակներում insert-ները որոշակի պատուհանի համար դեդուպլիկացվում են ըստ բլոկի hash-ի, այնպես որ timeout-ից հետո նույն batch-ը կրկնելն անվտանգ է, քանի դեռ batch-ը նույնական է։

1CREATE TABLE users_dim
2( user_id UInt64, plan LowCardinality(String), updated_at DateTime64(3) )
3ENGINE = ReplacingMergeTree(updated_at)
4ORDER BY user_id;
5 
6SELECT plan, count() FROM users_dim FINAL GROUP BY plan;

09Join-եր, dictionary-ներ և projection-ներ

ClickHouse-ը կատարում է join-եր, և նրա join planner-ը վերջին թողարկումներում շատ է բարելավվել, բայց լռելյայն hash join-ը դեռ աջ աղյուսակը կառուցում է հիշողության մեջ, այնպես որ փոքր աղյուսակը պահեք աջում և երկու կողմերն էլ ֆիլտրեք join-ից առաջ։ Դանդաղ փոփոխվող փոքր dimension աղյուսակների համար (երկրներ, պլաններ, ապրանքների անուններ) dictionary-ներն ավելի լավն են․ դրանք բեռնվում են հիշողության մեջ և հարցվում dictGet()-ով, հաճախ շատ ավելի արագ, քան join-ը։ Projection-ները նույն part-երի ներսում պահում են աղյուսակի լրացուցիչ, այլ կերպ դասավորված կամ նախապես ագրեգացված պատճեն, և optimizer-ը ավտոմատ օգտագործում է դրանք, երբ հարցումը համապատասխանում է։ Դրանք արժեն սկավառակ և insert-ի ժամանակ, այնպես որ ավելացրեք դրանք միայն ապացուցված hot հարցումների համար։

10Հորիզոնական մասշտաբավորում և կլաստերի պաշտպանություն

Նախ մասշտաբավորեք ուղղահայաց․ ավելի շատ core-եր և արագ NVMe տալիս են գրեթե գծային աճ։ Երբ ավելին է պետք, shard արեք tenancy-ին համապատասխանող key-ով (օրինակ՝ cityHash64(tenant_id)), որպեսզի հարցումների մեծ մասը դիպչի մեկ shard-ի, և յուրաքանչյուր shard ռեպլիկացրեք ReplicatedMergeTree-ով և ClickHouse Keeper-ով (երեք Keeper node՝ quorum-ի համար)։ Distributed աղյուսակը հարցումները տարածում է և միավորում արդյունքները։ Multi-tenant անալիտիկայի համար պաշտպանեք կլաստերը settings profile-ներով և quota-ներով՝ max_memory_usage, max_execution_time, max_rows_to_read և max_concurrent_queries յուրաքանչյուր օգտատիրոջ համար, գումարած row policy-ներ, որպեսզի յուրաքանչյուր tenant-ի օգտատեր տեսնի միայն իր տողերը։ Մոնիտորինգ արեք system.query_log-ը, system.parts-ը (part-եր ըստ partition-ի) և system.merges-ը, և ալերտ դրեք part-երի քանակի և replication lag-ի վրա։