ანალიტიკური მონაცემების შეკუმშვა

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/Avro (გვერდები/გაფიცვები/სვეტები).
2. Encoding დონეზე სვეტები: 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), Compacchne, page cache.

3) სვეტების ფორმატები და მათი უპირატესობები

Parquet: გვერდები სვეტებზე; ლექსიკონის მხარდაჭერა, RLE/Bit პაკეტი, სტატისტიკური min/max და null-count.
ORC: straips, რომელზეც არის strimes ინდექსები, bloom ფილტრები; ეფექტური გრძელი სკანირებისთვის.
Avro (row): მოსახერხებელია ნაკადი/ლოგებისთვის, უარესია ანალიტიკური სკანირებისთვის.

პრაქტიკა: გამოიყენეთ Parquet/ORC ნაგულისხმევი ანალიტიკოსებისთვის, ჩართეთ column stats და ციფრული, სადაც კარდინალობა დაბალია/საშუალოზე.

4) სვეტების ენკოდინგი (lossless)

Dictionary: ცვლის მნიშვნელობებს ინდექსებით (იდეალურია დაბალი კარდინალობისთვის).
RLE (Run-Length Encoding): განმეორებითი მნიშვნელობები (value, run). კარგი დახარისხებული/კლასტერული სვეტებისთვის.
დელტა/დელტა-ო-დელტა: ინახავს განსხვავებებს (რიცხვები/დრო).
FoR (Frame-of-Reference) + Bit-packing: მნიშვნელობა = base + offset; offset შეფუთულია N ბიტებით.
გორილა/XOR (Time სერია): ინახავს XOR მეზობელ მნიშვნელობებს ცვლადი სიგრძით; კარგი მეტრიკისთვის.
არასასურველი ბიტმასკი: ნულის ცალკეული ნაკადი ზრდის CR- ს.

რჩევა: წინასწარი კლასტერიზაცია/დახარისხება ფილტრაციის ღილაკებზე მკვეთრად აუმჯობესებს RLE/zone-maps და CR.

5) ზოგადი დანიშნულების კოდექსი

ZSTD: საუკეთესო CR ზომიერი CPU ფასით; მხარს უჭერს 1-22 დონეს. უნივერსალური არჩევანი.
Snappy: სწრაფი, დაბალი CR; შესაფერისია ცხელი მონაცემებისთვის, მაღალი კითხვის სიხშირით.
LZ4: კიდევ უფრო სწრაფად, ვიდრე Snappy, CR- ის მსგავსი; ხშირად - ნაკადი/ლოგები/ქეში.
Gzip/Deflate: მაღალი CR, CPU- ს მაღალი ფასი; იშვიათად გამართლებული ინტერაქტიული ანალიტიკაში.

წესი: ცხელი ფენა - Snappy/LZ4, თბილი/ცივი - ZSTD (დაბალი 3-7).

6) დროებითი რიგები და ლოგები

TSDB/სვეტების BD: Gorilla/XOR, Delta-RLE-Bitmap, Sparse-run იშვიათი სიგნალებისთვის.
Logs: JSON, Parquet + ZSTD; დააკონტროლეთ კლავიშები და ტიპები (არ შეინახოთ „სტრიქონის ინტი“).
Downsampling და roll-ups (lossy): შეინახეთ დანაყოფები ფანჯრების გასწვრივ (1m/5m/1h) ცხელ ფენაში; ნედლეული - ცივ.
Sketch სტრუქტურები: HLL (კარდინალობა), TDigest/KLL (კვანილი), CMS (სიხშირეები) - კომპაქტური, მაგრამ მიახლოებითი.

7) სიზუსტის დაკარგვა

Lossless - ანგარიშები, ფინანსები, აუდიტი.
ლოსი - მონიტორინგი, A/B ანალიტიკა დიდ ფანჯრებზე, ტელემეტრია (აშკარა მარკირებით!).
ხარისხის კონტროლი: დასაშვები შეცდომის დადგენა (მაგალითად, P99 ± 0. 5 გვ) და შეამოწმეთ იგი CI- ში.

8) განაწილება, გვერდები და კომპაქტური

წვეულებები: თარიღი/რეგიონი/ტენანტი - ნაკლები სკანირება, უკეთესი CR.
გვერდის ზომა/გაფიცვა: 64-256 KB გვერდზე, 64-512 MB თითო ფაილი - ბალანსი seek- სა და CPU- ს შორის.
Compacchne: დააკავშიროთ მცირე ფაილები (მცირე ფაილები) - ზემოთ CR და სიჩქარე.
Zone-maps/Bloom: აჩქარებს გვერდების გამოტოვებას; ეფექტური ფილტრების დახარისხებისას.

9) შეკუმშვა და დაშიფვრა/კონფიდენციალურობა

ოპერაციების რიგი: ჯერ შეკუმშვა, შემდეგ დაშიფვრა. წინააღმდეგ შემთხვევაში, CR-1.
TDE/at-rest არ ერევა CR (უკვე შეკუმშული ბლოკი დაშიფრულია).
In transit (TLS) არ მოქმედებს ფორმატში.
შენიღბვა/ტოქსიკაცია PII შეკუმშვამდე ინარჩუნებს კონტროლირებად ენტროპიას.
ფრთხილად, OPE/DET დაშიფვრის საშუალებით: მას შეუძლია გაუარესდეს CR ან/და რისკავს კონფიდენციალურობას.

10) ღირებულება და SLO (ეკონომიკა)

სცენა: ნაკლები ბაიტი $/TB-mo.
Compute: ნაკლები IO უფრო სწრაფად, ვიდრე სკანერები; მაგრამ დეკომპრესია ხარჯავს CPU- ს.
Egress: ნაკლები ბაიტი ტრაფიკი/ასლების დრო.
SLO კომპრომისი: შეარჩიეთ კოდი/დონე ისე, რომ 'p95 _ ლატენტობა "დარჩეს სამიზნე ფანჯარაში.

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), ORDER BY RLE/skans, TTL/Compactus.
Snowflake/BigQuery: ავტომატური ფორმატები/კლასტერიზაცია; დაეხმარეთ cluster by (თარიღი, მენანტი, ფილტრის გასაღებები).
Redshift/Presto/Trino: Parquet/ORC ZSTD- ით, კონფიგურაცია 'hive. exec. compress. გარეთ ', სტატისტიკა და ფაილების გამიჯვნა.

12) Payplines: სად ჩართოთ შეკუმშვა

Ingest: შეკუმშული ბატები (ZSTD/LZ4) ტბაში ჩაწერისას.
Transform/DBT: შექმენით სვეტების სამიზნეები სწორი კოდექსით და დახარისხებით.
Serve/OLAP: მატერიალიზებული წარმოდგენები შესაფერისი კოდექსით; ცხელი დაშბორდის წინამორბედები.
Export: для CSV/JSON — gzip/zstd; უმჯობესია პარკეტის მიცემა.

13) ტესტირება და დამოწმება

AB პროფილირება: მოთხოვნების სიმრავლე შეიძლება შევადაროთ p50/p95, bytes scanned, CPU Time, CR.
ოქროს ნაკრები: სისწორე გადამოწმების/კომპაქსების შემდეგ.
რეგლამენტი perf tests: ალერტები, თუ კოდექსი/დონის შეცვლის შემდეგ p95/> X%.
DQ წესები: ტიპები/დიაპაზონი/NULL წესები არ უნდა შეიცვალოს გადართვის დროს.

14) შენახვის პოლიტიკა და TTL

Tiered: hot (7-14 დნ.) , warm (30-90 დნ.) , ცივი (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 სცენა, downsampling/ესკიზები, egress პოლიტიკა.
5. Hardening: რეგრესიული პერფექტები, DQ, runbooks გადატანა.

17) ჩეკის სია გამოქვეყნებამდე

• ფორმატი: Parquet/ORC; შედის სტატისტიკა/ლექსიკონი.
• კლასტერიზაცია ფილტრაციის გასაღებებზე; წვეულებები თარიღი/ტენანტი.
• კოდექსი: Hot = Snappy/LZ4, warm/cold = ZSTD (3-7); p95 ნორმალურია.
• კომპაქტური განწყობა; არ არსებობს მცირე ფილმები; ფაილების/გვერდების მიზნობრივი ზომები.
• DQ და მწვანე ოქროს ნაკრები; შენახული ტიპები/დიაპაზონი.

დაშიფვრა შეკუმშვის შემდეგ; PII შენიღბულია; retenshn/Legal-hold არის დაცული.

• perf რეგრესიის მონიტორინგი; ალერტები 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. კომპეტენტური დიზაინი იძლევა უფრო სწრაფად, ვიდრე ანგარიში და პროგნოზირებადი შესრულება - მონაცემების ნდობის კომპრომისის გარეშე.