Талдау деректерін қысу

1) Талдамалық деректерді неге қысу керек

Сығу сақтау көлемі мен трафикті азайтады, сканерлерді аз IO және жақсы кэштеу есебінен жылдамдатады. Баға - CPU және (кейде) жаңарту күрделілігі. Мақсаты - SLO үшін «IO, CPU, дәлдік, құн».

• Compression Ratio (CR) = `raw_size / compressed_size`.
• Scan Cost ≈ bytes_scanned / throughput_storage + cpu_decode_time`.
• Total Cost = `storage_cost + compute_cost + egress_cost`.

2) Қысу тұратын қабаттар

1. Формат деңгейінде: Parquet/ORC/Euro (беттер/страйптар/бағандар).
2. Бағандар энкодингі деңгейінде: Dictionary, RLE, Delta, FoR/Bit-packing, Gorilla/XOR.
3. Кодек деңгейінде: ZSTD, Snappy, LZ4, Gzip.
4. Сұрау/қозғалтқыш деңгейінде: векторлау, беттерді өткізу (min/max), bloom/zone-map.
5. Сақтау деңгейінде: tiered storage (hot/warm/cold), компакшн, page cache.

3) Бағаналы форматтар және олардың артықшылықтары

Parquet: бағандар бойынша беттер; сөздіктерді, RLE/Bit-packing, min/max және null-count статистикаларын қолдау.
ORC: ағындарда индекстері бар страйптар, bloom-сүзгілер; ұзақ сканерлер үшін тиімді.
Euro (row): ағын/логтар үшін қолайлы, аналитикалық сканерлер үшін нашар.

Тәжірибе: әдепкі талдау үшін Parquet/ORC пайдаланыңыз, column stats және dictionary түбірлігі төмен/орташа жерде қосыңыз.

4) Бағандардың энкодингі (lossless)

Dictionary: мәндерді индекстермен алмастырады (төмен түбегейлілік үшін тамаша).
RLE (Run-Length Encoding): қайталанатын мәндер → (value, run). Сұрыпталған/кластерленген бағандар үшін жақсы.
Delta/Delta-of-Delta: айырмашылықтарды сақтайды (сан/уақыт).
FoR (Frame-of-Reference) + Bit-packing: мән = base + offset; offset N биттермен қапталған.
Gorilla/XOR (Time-series): ұзындығы ауыспалы көршілес XOR мәндерін сақтайды; метриктер үшін жақсы.
Nullable-битмаскалар: null 'дердің жеке ағыны CR-ді арттырады.

Кеңес: сүзу кілттері бойынша алдын ала кластерлеу/сұрыптау RLE/zone-maps және CR-ді күрт жақсартады.

5) Жалпы мақсаттағы кодекстер

ZSTD: қалыпты CPU бағасы бойынша ең жақсы CR; 1-22 деңгейлерді қолдайды. Әмбебап таңдау.
Snappy: жылдам, төмен CR; жоғары оқу жиілігімен ыстық деректер үшін жарамды.
LZ4: одан да жылдам Snappy, ұқсас CR; жиі - стрим/лог/кэш үшін.
Gzip/Deflate: жоғары CR, жоғары CPU бағасы; интерактивті талдауда сирек ақталады.

Ереже: ыстық қабат - Snappy/LZ4, жылы/суық - ZSTD (level 3-7).

6) Уақытша қатарлар мен логтар

TSDB/бағаналы ДБ: Gorilla/XOR, Delta-RLE-Bitmap, сирек сигналдар үшін Sparse-run.
Логи: JSON → Parquet + ZSTD; кілттер мен түрлерді қалыпқа келтіріңіз («int» жолағын сақтамаңыз).
Downsampling және roll-ups (lossy): терезе агрегаттарын (1m/5m/1h) ыстық қабатта сақтаңыз; шикі - суықта.
Sketch-құрылымдар: HLL (түбегейлілік), TDigest/KLL (квантильдер), CMS (жиіліктер) - ықшам, бірақ аппроксимациялық.

7) Lossless vs Lossy (дәлдігін жоғалтқанда)

Lossless - есептілік, қаржы, аудит.
Lossy - мониторинг, үлкен терезелердегі A/B-талдау, телеметрия (анық таңбалаумен!).
Сапаны бақылау: рұқсат етілген қате (мысалы, P99 ± 0. 5 п.т.) және оны CI-де тексеру.

8) Партиялану, беттер және компакшн

Партиялар: күні/аймағы/тенанты бойынша → сканерлер аз, CR жақсы.
Бет/страйп өлшемі: 64-256 КБ бетте, 64-512 МБ файл - seek пен CPU арасындағы теңгерім.
Компакшн: CR мен жылдамдықтан жоғары (small files problem) ұсақ файлдарды біріктіріңіз.
Zone-maps/Bloom: беттерді жіберуді жылдамдатады; сүзгілер бойынша сұрыптау кезінде тиімді.

9) Сығу және шифрлау/құпиялылық

Операция тәртібі: алдымен сығу, содан кейін шифрлау. Әйтпесе CR ≈ 1.
TDE/at-rest CR қызметіне кедергі келтірмейді (сығылған блок шифрланады).
In-transit (TLS) пішіміне әсер етпейді.
Қысылғанға дейін PII бүркемелеу/токенизациялау басқарылатын энтропияны сақтайды.
OPE/DET-шифрлаумен сақ болыңыз: CR нашарлатуы және/немесе құпиялылыққа қауіп төндіруі мүмкін.

10) Құны және SLO (экономика)

Storage: аз байт → төмен $/TB-mo.
Compute: IO → сканерден жылдам; бірақ декомпрессия CPU шығындайды.
Egress: аз байт → төмен трафик/көшірме уақыты.
SLO-компромисс: 'p95 _ latency' мақсатты терезеде қалатындай етіп кодек/деңгейді таңдаңыз.

yaml hot:
format: parquet codec: snappy target_p95_ms: 1000 max_scan_mb: 2048 warm:
format: parquet codec: zstd:4 target_p95_ms: 2500 compaction: daily cold:
format: parquet codec: zstd:7 glacier: true retention: 365d

11) Қозғалтқыштарға арналған тәжірибелер (ClickHouse/Snowflake/BigQuery/Redshift/Presto)

ClickHouse: CODEC 'және бағандарда (LZ4/ZSTD/DoubleDelta), RLE/сканерлер үшін ORDER BY, TTL/компакшн.
Snowflake/BigQuery: пішімдер/кластерлеу автоматикасы; cluster by (күні, tenant, сүзгі кілттері).
Redshift/Presto/Trino: ZSTD бар Parquet/ORC, баптау 'hive. exec. compress. output ', статистика және файлдарды бөлу.

12) Пайплайндар: сығуды қайда қосу керек

Ingest: lake жазуда сығылған батчилер (ZSTD/LZ4).
Transform/DBT: қажетті кодекпен және сұрыптаумен бағаналы мақсаттарды жасаңыз.
Serve/OLAP: сәйкес кодекпен материалдандырылған көріністер; ыстық дашбордтарға арналған алдын ала агрегаттар.
Export: для CSV/JSON — gzip/zstd; Parquet беру жақсы.

13) Тестілеу және валидация

AB профильдеу: сұрау жиынтығы → p50/p95, bytes scanned, CPU time, CR салыстыру.
Golden-жиынтықтар: қайта кодтаудан/компакшнадан кейін дұрыстығын тексеру.
Regression perf tests: алерталар, егер p95 ↑> X% кодек/деңгей ауысқаннан кейін.
DQ ережелері: түрлер/ауқымдар/NULL-rate қайта салу кезінде өзгермеуі тиіс.

14) Сақтау саясаты және TTL

Tiered: hot (7-14 күн) , warm (30-90 күн) , cold (180 күн ≥) .
Downsampling: «салқындату» кезінде шикізаттың орнына агрегаттарды/нобайларды сақтаңыз.
Retention/Legal hold: нормативтермен қайшылықтарды жоймаңыз; каталогтар мен нұсқаларды сақтаңыз.

15) Антипаттерндер

«Барлық жерде Gzip level 9 «: қымбат CPU, пайда жоқ.
Сұрыптаусыз/кластерлеусіз: жаман RLE/zone-maps → сканерлер қымбат.
JSON сақтау форматы ретінде: ingest үшін ыңғайлы, талдау үшін нашар.
Тым кіші файлдар: метадеректер/seek; CR құлдырауда.
Сығымдауға дейін шифрлау: нөлге жуық CR.
Таңбалаусыз Lossy: сенім мен есептіліктің бұзылуы.

16) Енгізу жол картасы

1. Discovery: сұрау/деректер профильдері, SLO және бюджеттер.
2. MVP: Parquet + ZSTD/Snappy, базалық сұрыптау/кластерлеу, компакшн.
3. Tuning: ZSTD деңгейлері, бет өлшемдері, cluster by, bloom/zone-maps.
4. Warm/Cold: tiered storage, downsampling/нобайлар, egress-саясат.
5. Hardening: регрессиялық перф-тесттер, DQ, runbooks қайта кодтау.

17) Шығарылым алдындағы чек-парақ

• Пішімі: Parquet/ORC; статистикалар/сөздіктер қосылды.
• Сүзу кілттері бойынша кластерлеу; күні/теңгесі бойынша
• Кодектер: hot = Snappy/LZ4, warm/cold = ZSTD (3-7); p95 қалыпты.
• Компакшн теңшелді; small files жоқ; файлдардың/беттердің мақсатты өлшемдері.
• DQ және алтын жиынтығы жасыл; түрлері/ауқымдары сақталған.
• Қысудан кейін шифрлау; PII бүркемеленген; ретеншн/Legal-hold сақталған.
• Перф-регрессия мониторингіленеді; p95/bytes scanned/CR бойынша алерталар.
• Сақтау саясаты мен қайта кодтау нұсқауларының құжаттамасы дайын.

18) Шағын үлгілер

sql create table if not exists analytics.sales_daily cluster by (event_date, tenant_id)
as select from {{ ref('sales_daily_view') }};
-- в конфиге модели: materialized=table, file_format=parquet, compression=zstd

yaml compaction:
target_file_mb: 256 small_file_threshold_mb: 32 schedule: "hourly"

yaml timeseries:
raw:  keep: 14d rollup_1m: keep: 90d rollup_1h: keep: 365d rollup_1d: keep: 1825d

Қорытынды: талдамалық деректерді қысу - бұл тек «кодекті қосу» ғана емес, тұтас стратегия: дұрыс формат, бағандардың энкодингі, сұрыптау және партиялану, компакшн және сақтау деңгейлері, шифрлау мен SLO құрметтеу. Сауатты дизайн дереккөзге сенімсіз сканерден жылдам, есептен төмен және болжамды өнімділікті береді.