Parquet چیست و چه عملکردی دارد؟

در مهندسی داده امروز، حتی یک فایل خراب که به صورت مخرب ساخته شده می‌تواند کل خطوط تحلیلی را به خطر بیندازد، پتابایت‌ها داده حساس را در معرض افشا قرار دهد و عملیات حیاتی کسب‌وکار را متوقف کند.

Apache Parquet یک فرمت فایل ذخیره‌سازی ستونی است که در پردازش و تحلیل داده‌های بزرگ به‌طور گسترده استفاده می‌شود. این فرمت در سال ۲۰۱۳ توسط Cloudera و Twitter ایجاد شد و اکنون بخشی از اکوسیستم Apache Hadoop است و در فریم‌ورک‌های پردازش داده مانند Apache Spark، Hive، Presto/Trino و بیشتر انبارهای داده ابری به یک فرمت اصلی تبدیل شده است.

Parquet داده‌ها را به گروه‌های ردیفی (Row Groups) و قطعات ستونی (Column Chunks) تقسیم می‌کند تا موتورهای پردازش بتوانند فقط مقادیر ستون‌های مورد نیاز را بخوانند بدون نیاز به خواندن کل فایل. این فرمت ستونی باعث بهبود نسبت فشرده‌سازی، کاهش I/O و افزایش چشمگیر سرعت تحلیل داده‌های بزرگ ذخیره شده در Amazon S3، Google Cloud Storage یا Azure Data Lake Storage می‌شود.

Parquet به‌طور یکپارچه با فریم‌ورک‌های پردازش داده مانند Apache Spark، Hive، Presto و موتورهای سرورلس مانند AWS Athena و BigQuery کار می‌کند و به همین دلیل، فرمت ذخیره‌سازی استاندارد برای داده‌های بزرگ و دریاچه‌های داده (Data Lakes) است.

ویژگی‌های کلیدی فرمت فایل Parquet

Parquet یک فرمت قدرتمند ذخیره‌سازی داده است که بهینه‌سازی همزمان برای فضای ذخیره‌سازی و عملکرد پرس‌وجو را ارائه می‌دهد. ویژگی‌های برجسته عبارتند از:

• ذخیره‌سازی ستونی: داده‌ها به صورت ستونی نوشته می‌شوند و موتورهای پردازش می‌توانند فقط داده‌های مرتبط را بخوانند.

• گزینه‌های فشرده‌سازی انعطاف‌پذیر: پشتیبانی از Snappy، Gzip، LZO، Brotli و Zstandard، امکان تعادل بین هزینه CPU و فضای ابری را می‌دهد.

• روش‌های پیشرفته رمزگذاری: Dictionary encoding، Run-length encoding، Bit-packing و Delta encoding باعث کاهش حجم داده و افزایش سرعت بازگشایی می‌شوند.

• متادیتای غنی: آمار min/max هر قطعه ستونی امکان Predicate Pushdown و استنتاج خودکار شِما (Schema) را فراهم می‌کند.

• Predicate Pushdown: اعمال فیلترها در لایه ذخیره‌سازی انجام می‌شود تا داده‌های اسکن شده کاهش یابند و سرعت پرس‌وجو افزایش یابد.

• تکامل شِما (Schema Evolution): افزودن یا تغییر ستون‌ها بدون نیاز به بازنویسی کل داده‌ها ممکن است.

• داده‌های پیچیده و تو در تو: آرایه‌ها، Mapها و Structها اجازه می‌دهند داده‌های پیچیده را به صورت بومی مدیریت کنید بدون نیاز به Flatten کردن JSON.

• سازگاری گسترده: قابل استفاده در زبان‌های برنامه‌نویسی مختلف (Python, Java, Rust, Go) و پلتفرم‌ها، از جمله Delta Lake و Apache Iceberg.

تفاوت فرمت‌های ردیفی و ستونی

هنگام انتخاب فرمت ذخیره‌سازی مناسب، تفاوت بین فرمت‌های ردیفی (Row-Based) و ستونی (Columnar) اهمیت دارد.

• در فرمت‌های ردیفی، داده‌ها هر ردیف در کنار هم ذخیره می‌شوند که برای عملیات تراکنشی مناسب است اما برای پرس‌وجوهای تحلیلی کمتر بهینه است.

• در فرمت‌های ستونی مانند Parquet، داده‌ها ستون به ستون ذخیره می‌شوند که اجازه می‌دهد پرس‌وجو و فشرده‌سازی بهینه‌تر انجام شود.

بهبود پردازش داده با فرمت ستونی

در فرمت ردیفی، حتی اگر فقط یک یا چند ستون نیاز باشد، کل ردیف خوانده می‌شود که باعث اسکن اضافی، مصرف بالای ذخیره‌سازی و کاهش عملکرد می‌شود.
در فرمت ستونی، تنها ستون‌های مورد نیاز خوانده می‌شوند که باعث کاهش حجم داده پردازش شده و افزایش عملکرد می‌شود.

فشرده‌سازی و روش‌های رمزگذاری بهینه

با گروه‌بندی داده‌های مشابه، Parquet می‌تواند روش‌های رمزگذاری مانند Dictionary Encoding و Run-Length Encoding را اعمال کند که باعث کاهش حجم و بهبود عملکرد پرس‌وجو می‌شود.

انعطاف‌پذیری در شِما (Schema)

فرمت‌های ستونی امکان تکامل شِما را به‌طور ساده فراهم می‌کنند؛ می‌توان ستون‌های جدید اضافه کرد بدون اینکه کل ردیف‌ها بازنویسی شوند.

مزایای اصلی Parquet برای مهندسی داده (Primary Benefits)

1. عملیات I/O کارآمد: خواندن فقط ستون‌های مورد نیاز باعث کاهش اسکن دیسک، انتقال شبکه و مصرف CPU می‌شود.

2. فشرده‌سازی بهتر و کاهش فضای ذخیره‌سازی: ذخیره داده‌های مشابه کنار هم باعث فشرده‌سازی کارآمد می‌شود و گزارش‌ها نشان می‌دهد حجم فایل‌ها ۲ تا ۵ برابر کمتر از CSV است.

3. بهبود عملکرد پرس‌وجو: Column pruning و Predicate Pushdown حجم داده‌های اسکن شده را به‌شدت کاهش می‌دهد و پرس‌وجوها را از دقیقه به ثانیه می‌رساند.

4. تکامل شِما: امکان تغییر شِما بدون بازنویسی پتابایت‌ها داده‌ها.

5. سازگاری با اکوسیستم: تقریبا همه موتورهای تحلیلی از Parquet پشتیبانی می‌کنند، از Snowflake تا Databricks و Trino.

ملاحظات امنیتی و ویژگی‌های رمزگذاری در Parquet

محیط‌های داده مدرن به اقدامات امنیتی پیشرفته‌ای نیاز دارند که فراتر از رمزگذاری کامل فایل باشد. چارچوب رمزگذاری مدولار Parquet این نیازها را با امکان حفاظت از داده در سطح ستون و حفظ مزایای عملکرد فرمت، برطرف می‌کند.

درک چارچوب رمزگذاری مدولار

چارچوب رمزگذاری مدولار Parquet یک تغییر پارادایم در امنیت داده‌ها است که فراتر از رمزگذاری کل فایل عمل می‌کند و امکان حفاظت در سطح ستون را فراهم می‌کند.

• کلیدهای رمزگذاری داده (DEKs) ستون‌ها یا اجزای متادیتا را رمزگذاری می‌کنند.

• کلیدهای رمزگذاری کلید (KEKs) این DEKها را رمزگذاری می‌کنند.

• کلیدهای اصلی (MEKs) در سرویس‌های مدیریت کلید خارجی ذخیره می‌شوند، تا کلیدهای حساس هرگز در سیستم ذخیره‌سازی نباشند.

این مدل اجازه می‌دهد هر ستون با کلید مجزا رمزگذاری شود و کنترل دسترسی دقیق ایجاد کند، به طوری که تحلیل‌گران تنها ستون‌های غیرحساس را بتوانند رمزگشایی کنند.
دو حالت رمزنگاری پشتیبانی می‌شود:

• AES-GCM برای احراز هویت کامل داده و متادیتا

• AES-GCM-CTR برای عملیات با تأخیر کمتر و حفاظت جزئی از یکپارچگی

آگاهی از آسیب‌پذیری‌های بحرانی

CVE-2025-30065 یک آسیب‌پذیری RCE بحرانی در کتابخانه Java Parquet با امتیاز CVSS 10.0 است. بهره‌برداری از آن زمانی رخ می‌دهد که فایل‌های مخرب Parquet وارد سیستم شوند و امکان اجرای کد دلخواه از طریق پردازش شِما ایجاد شود.

راهکارهای پیشگیری سه‌لایه‌ای:

1. مدیریت Patch: ارتقاء فوری به Parquet 1.15.1

2. اعتبارسنجی ورودی: اسکن شِما قبل از وارد کردن داده با ابزارهایی مثل NiFi

3. پروتکل‌های رمزگذاری: استفاده از AES-GCM مدولار برای جلوگیری از دستکاری داده‌ها

الگوها و بهترین روش‌های پیاده‌سازی

• متادیتای Footer: کنترل الگوهای دسترسی؛ Footer رمزگذاری شده شِما را مخفی می‌کند.

• رمزگذاری سطح ستون: ستون‌های مالی با کلید اختصاصی و ستون‌های غیرحساس در دسترس تیم گسترده‌تر.

• بار اضافی عملکرد: AES-GCM تقریبا ۱۵٪ تاخیر ایجاد می‌کند، AES-GCM-CTR تنها ۴–۵٪ بار اضافی دارد.

• یکپارچگی با KMS ابری: کاهش ۴۰٪ بار مدیریت کلید نسبت به پیاده‌سازی دستی و حفظ انطباق با مقررات.

بهینه‌سازی Parquet برای جریان داده و پردازش بلادرنگ

پردازش جریان داده نیازمند تعادل بین محدودیت حافظه، اندازه فایل و پردازش بلادرنگ است.

تکنیک‌های حافظه-کارآمد برای جریان داده

نوشتن داده به صورت Row-wise به Parquet ستونی نیازمند بافر کردن گروه‌های ردیفی ۱۲۸MB–1GB است که فشار حافظه ایجاد می‌کند.

راهکار دو مرحله‌ای:

1. نوشتن گروه‌های ریز ردیفی (Micro-row 10MB)

2. استفاده از فرآیند Background Compaction برای ادغام آن‌ها به گروه‌های ۱۲۸MB

• کاهش حداکثر مصرف حافظه تا ۸۹٪

• حفظ عملکرد پرس‌وجو

تکنیک‌های پیشرفته بهینه‌سازی عملکرد

• Vectorized V2 Encoding: افزایش عملکرد تا ۷۷٪

• Delta Encoding: کاهش چرخه‌های CPU با پردازش ستونی بهینه

• Partitioning ابری: بهبود کارایی جریان داده با تقسیم‌بندی بر اساس تاریخ (Year/Month)

• Indexing Metadata ستون‌ها: خودکارسازی Min/Max برای Footer و سرعت بخشیدن به Predicate Pushdown

الگوهای ادغام بلادرنگ

• Kafka Connect با Avro-decorated به Parquet

• Delta Lake Auto-Optimize: ادغام Micro-fileهای Parquet در پارتیشن‌های ≥128MB

• پشتیبانی از ۵۰،۰۰۰ رویداد بر ثانیه با میانگین تأخیر ۳۵ms

کار با Parquet

ایجاد فایل‌های Parquet

1. انتخاب زبان یا فریم‌ورک با پشتیبانی Parquet

2. تبدیل یا وارد کردن داده‌های ساخت‌یافته به DataFrame

3. استفاده از APIها مانند pandas.DataFrame.to_parquet() یا spark.write.parquet()

4. تنظیم فشرده‌سازی و رمزگذاری (مثال: compression=”snappy”)

5. ذخیره در ذخیره‌سازی ابری یا HDFS

خواندن فایل‌های Parquet

1. انتخاب موتور پردازش سازگار با Parquet (Python, Spark, Hive, Trino)

2. استفاده از read_parquet() یا معادل آن

3. اعمال فیلترها (WHERE clause)

4. پردازش، تحلیل یا ارسال به downstream

یکپارچگی و سازگاری اکوسیستم

• ELTهای مدرن مانند Airbyte قابلیت‌های Parquet را توسعه داده‌اند

• بهبود سرعت نوشتن ۴۰–۶۰٪ و مدیریت هوشمند Schema Evolution

• CDC pipeline: حالت “Append + Deduped” برای جلوگیری از رکوردهای تکراری

بهترین روش‌ها (Best Practices)

• اندازه فایل و گروه ردیفی: هدف ۱۲۸MB–۱GB، گروه‌های ردیفی ۶۴–۲۵۶MB

• تقسیم‌بندی هوشمند: کلیدهای متوسط کاردینالیته (Year/Month/Day, Region)

• انتخاب Codec فشرده‌سازی: Snappy برای سرعت، Zstandard برای هزینه ابری کمتر

• استفاده از Dictionary Encoding برای ستون‌های دسته‌ای

• Column Pruning و Predicate Pushdown: فیلتر کردن زودهنگام

• اجتناب از تغییرات گسترده شِما

• نظارت بر عملکرد: تأخیر پرس‌وجو و حجم داده اسکن شده

• ادغام فایل‌های کوچک: برای داده‌های جریان‌یافته

• اسکن امنیتی: پیش‌اعتبارسنجی فایل‌های Parquet و مدیریت Patch

• بهینه‌سازی براساس نوع Workload:
  Zstandard برای Analytical، Snappy برای Real-time

جایگاه Parquet در معماری Lakehouse

• Delta Lake: Parquet + Transaction Log برای ACID و Time Travel

• Apache Iceberg: Snapshot Isolation و Partition Evolution

• Apache Arrow: نمایش ستونی در حافظه با خواندن مستقیم Parquet

این فناوری‌ها امکان ساخت Lakehouse را فراهم می‌کنند که مقیاس‌پذیری Data Lake و حاکمیت انبار داده را ترکیب می‌کند.

مقایسه با فرمت‌های دیگر

کاربردهای اصلی و مثال‌ها

• Data Lakes و Lakehouses:
  Airbnb، Uber، خرده‌فروشان Fortune 500

• BI و Dashboardها: Tableau، Apache Superset، Power BI

• Feature Storeهای ML: بارگذاری ستون‌های خاص برای آموزش مدل

• Pipelineهای جریان داده: Kafka / Kinesis → Parquet

• رعایت قوانین: رمزگذاری ستونی برای Compliance

• Observability: ذخیره متریک‌ها و لاگ‌ها بهینه

پرسش‌های متداول

• چه زمانی نباید از Parquet استفاده کرد؟

  • برای تراکنش‌های لحظه‌ای یا به‌روزرسانی‌های ردیفی مکرر مناسب نیست، فرمت‌هایی مثل Avro یا Protobuf بهترند.

• آیا Parquet خارج از ابر هم کارایی دارد؟

  • بله، روی سیستم‌های On-Prem مثل Hadoop HDFS یا SSD محلی نیز کارآمد است.

• چگونه تغییر شِما را ایمن مدیریت کنیم؟

  • با پشتیبانی Parquet از Schema Evolution و ابزارهایی مثل Delta Lake یا Iceberg.

• آیا Parquet به‌طور پیش‌فرض امن است؟

  • خیر، نیاز به پیکربندی چارچوب رمزگذاری مدولار و یکپارچگی با KMS دارد.