فشرده سازی داده های تحلیلی

1) چرا فشرده سازی داده های تحلیلی

فشرده سازی باعث کاهش ذخیره سازی و ترافیک، سرعت اسکن با IO کمتر و ذخیره سازی بهتر می شود. قیمت CPU و (گاهی اوقات) پیچیدگی به روز رسانی است. هدف «IO↔CPU↔tochnost↔stoimost» بهینه برای SLO های شما است.

• نسبت تراکم (CR) = 'raw _ size/ compressed_size'.
• هزینه اسکن ≈ bytes_scanned/ throughput_storage + cpu_decode_time'.
• مجموع هزینه = 'storage _ cost + compute_cost + egress_cost'.

2) لایه هایی که فشرده سازی زندگی می کند

1. در سطح فرمت: پارکت/ORC/آورو (صفحات/راه راه/ستون).
2. در سطح رمزگذاری ستون: فرهنگ لغت، RLE، دلتا، FoR/بیت بسته بندی، گوریل/XOR.
3. در سطح کدک: ZSTD، Snappy، LZ4، Gzip.
4. در سطح پرس و جو/موتور: برداری، پرش صفحه (حداقل/حداکثر)، بلوم/منطقه نقشه.
5. در سطح ذخیره سازی: ذخیره سازی لایه ای (گرم/گرم/سرد)، فشرده سازی، کش صفحه.

3) فرمت ستون و مزایای آنها

پارکت: صفحات ستون ؛ پشتیبانی از فرهنگ لغت، RLE/Bit-packing، آمار حداقل/حداکثر و شمارش صفر.

ORC: نوار با شاخص در جریان، فیلتر شکوفه ؛ موثر برای اسکن های طولانی

Avro (ردیف): مناسب برای جریان/سیاهههای مربوط، بدتر برای اسکن تحلیلی.

تمرین: برای تجزیه و تحلیل پیش فرض، از Parquet/ORC استفاده کنید، شامل آمار ستون و فرهنگ لغت است که در آن کاردینالیتی کم/متوسط است.

4) رمزگذاری ستون (lossless)

Dictionary-Replaces values with indexes (ایده آل برای cardinality کم).
RLE (Run-Length Encoding) - duplicate → values (value, run). خوب برای ستون های مرتب شده/خوشه ای.
Delta/Delta-of-Delta: تفاوت ذخیره ها (اعداد/زمان).
FoR (قاب مرجع) + بیت بسته بندی: ارزش = پایه + افست ؛ افست با N بیت بسته بندی شده است.
Gorilla/XOR (سری زمانی): XOR مقادیر همسایه را با طول متغیر ذخیره می کند. خوب برای متریک.
bitmasks nullable: یک جریان جداگانه از null ها CR را افزایش می دهد.

نکته: مرتب سازی کلید قبل از خوشه بندی/فیلتر کردن به طور چشمگیری RLE/zone-maps و CR را بهبود می بخشد.

5) کدک های عمومی

ZSTD: بهترین CR در قیمت CPU متوسط ؛ پشتیبانی از سطوح 1-22. انتخاب جهانی

سریع: سریع، کم CR ؛ مناسب برای داده های داغ با فرکانس خواندن بالا.
LZ4: Snappy حتی سریع تر، CR مشابه ؛ اغلب - برای جریان/سیاهههای مربوط/انبارها.
Gzip/Deflate: CR بالا، قیمت CPU بالا ؛ به ندرت در تجزیه و تحلیل تعاملی توجیه می شود.

قانون: لایه گرم - Snappy/LZ4، گرم/سرد - ZSTD (سطح 3-7).

6) سری زمان و سیاهههای مربوط

پایگاه داده های TSDB/ستون: Gorilla/XOR، Delta-RLE-Bitmap، Sparse-run برای سیگنال های نادر.
سیاهههای مربوط: JSON → پارکت + ZSTD ؛ عادی سازی کلیدها و انواع («رشته int» را ذخیره نکنید).
Downsampling و رول یو پی اس (lossy): واحدهای فروشگاه توسط ویندوز (1m/5m/1h) در یک لایه داغ ؛ خام - در سرما.
ساختار طرح: HLL (کاردینالیتی)، TDigest/KLL (چندک)، CMS (فرکانس) - جمع و جور، اما تقریبی.

7) Lossless در مقابل Lossy (زمانی که می توانید دقت را از دست بدهید)

بی ضرر - گزارش، امور مالی، حسابرسی.
Lossy - نظارت، تجزیه و تحلیل A/B در پنجره های بزرگ، تله متری (با علامت گذاری صریح!).
کنترل کیفیت: تحمل را تنظیم کنید (به عنوان مثال P99 ± 0 5 ص) و آن را در CI بررسی کنید.

8) پارتیشن بندی، صفحات و فشرده سازی

احزاب: بر اساس تاریخ/منطقه/مستاجر → اسکن کمتر، CR بهتر.
اندازه صفحه/نوار: 64-256 کیلوبایت در هر صفحه، 64-512 مگابایت در هر فایل - تعادل بین جستجو و CPU.
فشردهسازی: مشکل فایلهای کوچک را ترکیب کنید - بالاتر از CR و سرعت.
منطقه نقشه ها/بلوم: سرعت پرش صفحه ؛ موثر در مرتب سازی بر اساس فیلتر.

9) فشرده سازی و رمزگذاری/حفظ حریم خصوصی

ترتیب عملیات: ابتدا فشرده سازی، سپس رمزگذاری. در غیر این صورت CR 1 ≈.
TDE/at-rest با CR تداخل ندارد (یک بلوک فشرده شده رمزگذاری شده است).
در حمل و نقل (TLS) فرمت تاثیر نمی گذارد.
PII masking/tokenization قبل از فشرده سازی، آنتروپی را کنترل می کند.
احتیاط در رمزگذاری OPE/DET: ممکن است CR و/یا حریم خصوصی را کاهش دهد.

10) هزینه و SLO (اقتصاد)

ذخیره سازی: بایت کمتر → کمتر از $/TB-mo.
محاسبه: IO کمتر → اسکن سریعتر ؛ اما فشرده سازی CPU را هدر می دهد.
خروج: بایت کمتر → زمان ترافیک/کپی کمتر.
سازش 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)، ORDER BY برای RLE/اسکن، TTL/فشرده سازی.
دانه برف/BigQuery: اتوماسیون فرمت/خوشه بندی ؛ کمک به خوشه (تاریخ، مستاجر، کلید های فیلتر).
انتقال به سرخ/Presto/Trino: پارکت/ORC با ZSTD، تنظیم کندو. اجرایی. فشرده سازی. خروجی، آمار و تقسیم فایل.

12) خطوط لوله: جایی که شامل فشرده سازی است

Ingest: دسته های فشرده (ZSTD/LZ4) هنگام نوشتن در دریاچه.
Transform/DBT: اهداف ستون را با کدک مورد نظر و مرتب سازی ایجاد کنید.
خدمت/OLAP: دیدگاه های تحقق یافته با یک کدک مناسب ؛ پیش جمع برای داشبورد داغ.
صادرات: для CSV/JSON - gzip/zstd ؛ بهتر است از پارکت استفاده کنید.

13) تست و اعتبار سنجی

پروفایل AB: مجموعه ای از درخواست ها → مقایسه p50/p95، بایت اسکن شده، زمان CPU، CR.
مجموعه های طلایی: بررسی صحت پس از ضبط/فشرده سازی.
تست منطقه perf: هشدار اگر p95 ↑> X٪ پس از تغییر کدک/سطح.
قوانین DQ: انواع/محدوده/نرخ NULL نباید هنگام بارگیری مجدد تغییر کند.

14) حفظ و سیاست های TTL

چند لایه: گرم (7-14 روز)، گرم (30-90 روز)، سرد (≥180 روز).
Downsampling: همانطور که شما «خنک کردن»، فروشگاه واحد/طرح به جای خام.
نگهداری/نگهداری قانونی: درگیری با مقررات را حذف نکنید ؛ دایرکتوری ها و نسخه ها را ذخیره کنید.

15) ضد گلوله

«در همه جا Gzip سطح 9 «: CPU گران قیمت، هیچ سود.
بدون مرتب سازی/خوشه بندی: RLE/zone-maps بد → اسکن گران قیمت.
JSON به عنوان یک فرمت ذخیره سازی: مناسب برای مصرف، بد برای تجزیه و تحلیل.
پرونده های خیلی کوچک: ابرداده/جستجو را متورم کنید. سقوط سي آر.
رمزگذاری قبل از فشرده سازی: CR نزدیک به صفر.
Lossy unmarked: نقض اعتماد و پاسخگویی.

16) نقشه راه پیاده سازی

1. کشف: پروفایل های پرس و جو/داده ها، SLO ها و بودجه ها.
2. MVP: پارکت + ZSTD/Snappy، مرتب سازی/خوشه بندی اولیه، تراکم.
3. تنظیم: سطوح ZSTD، اندازه صفحه، خوشه توسط، شکوفه/منطقه نقشه.
4. گرم/سرد: ذخیره سازی لایه، downsampling/طرح، سیاست های خروج.
5. سخت شدن: آزمون perf رگرسیون، DQ، transcoding runbooks.

17) چک لیست قبل از انتشار

• فرمت: پارکت/ORC ؛ آمار/لغت نامه ها گنجانده شده است.
• خوشه بندی با فیلتر کردن کلید ؛ احزاب توسط تاریخ/مستاجر.
• کدک ها: گرم = Snappy/LZ4، گرم/سرد = ZSTD (3-7) ؛ P95 طبیعی است.
• فشرده سازی تنظیم شده است ؛ بدون فایل های کوچک ؛ اندازه فایل/صفحه هدف.
• DQ و مجموعه های طلایی سبز هستند ؛ انواع/محدوده ذخیره شده.
• رمزگذاری پس از فشرده سازی ؛ PII ماسک زده ؛ نگهداری/نگهداری قانونی رعایت شده است.
• رگرسیون perf نظارت می شود ؛ هشدارهای p95/بایت اسکن شده/CR.
• سیاست ذخیره سازی و مستندات دستورالعمل transcoding آماده است.

18) قالب های کوچک

sql create table if not exists analytics. sales_daily cluster by (event_date, tenant_id)
as select from {{ ref('sales_daily_view') }};
-- in model config: 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. طراحی هوشمند اسکن سریعتر، شمارش کمتر و عملکرد قابل پیش بینی را ارائه می دهد - بدون اینکه اعتماد به داده ها را به خطر بیاندازد.