نگاهی به قالبهای جدید ذخیره دادهها (به صورت خام)
آیا پادشاهی parquet در حوزه قالب های خام ذخیره دادهها در معرض خطر قرار گرفته است؟
با گسترش مفاهیمی مانند LakeHouse ها و استانداردهایی مانند IceBerg و تسهیل امکان اجرای کوئری بر روی فایلهای داده پردازش نشده (خام )، قالب ذخیره Parquet و تا حدودی هم ORC به یک de facto استاندارد در این حوزه تبدیل شده است و در چند سال اخیر، رشد استفاده از آنها را شاهد بودهایم.
با این وجود به نظر میرسد در مرحله گذار از این قالبهای کلاسیک ذخیره ستونی دادهها به قالبهای ذخیره دادههای خام با ضریب فشردگی بالاتر و بهینگی بسیار بیشتر در پردازش و پیمایش هستیم .
تعدادی ازین قالبهای جدید ذخیره دادهها به صورت خام (بدون نیاز به دیتابیس برای ذخیره این اطلاعات) در مقاله زیر معرفی و بررسی شدهاند.
“Make Apache Parquet 10-100x Faster 🚀” That’s one of the motivations! There is no denying in the fact that the #Parquet file format has been instrumental…
https://www.linkedin.com/posts/dipankar-mazumdar_parquet-bigdata-dataengineering-activity-7253095572268613632-Wk2r
در نظر بگیرید :
– سامانههای ذخیره سازی مانند s3 بسیار رایج شدهاند و هزینه استفاده از آنها هم بسیار کاهش یافته است.
– کتابخانههای پردازش داده، بسیار حرفهای تر و موثرتر شدهاند (مثلا polars در مقابل pandas)
– استانداردهایی برای ساختاردهی به فایلهای خام ایجاد شدهاند که حتی امکان اجرای تراکنشهای ACID را هم روی دادههای خام فراهم میکنند(Apache Iceberg)
– کاتالوگهایی مانند Polaris ، مسأله سطح دسترسی و مسایل امنیتی مرتبط با این فایلهای خام را برطرف کردهاند.
– ابزارهای دمدستی مانند DuckDB برای کار با این استانداردها، ارتقا یافتهاند …
– خیلی از منابع دادهای ما زیر یک ترابایت هستند.(پست اخیر علیرضا صادقی را در این زمینه از دست ندهید)
https://lnkd.in/d7W467Fb
به چه نتیجهای میرسید ؟ آیا ظهور بازیگران جدید و رواج این قالبهای حرفهای ذخیره دادهها در دنیای مهندسی داده که هم سرعت پردازش دیتا را تضمین خواهند کرد و هم نیاز به استفاده از دیتابیس را برای بسیاری از دادههای غیرحیاتی سامانهها، از بین خواهند برد، دور از انتظار نخواهد بود؟
نکات اصلی مقاله فوق :
آیا پادشاهی parquet در حوزه قالب های خام ذخیره دادهها در معرض خطر قرار گرفته است؟
با گسترش مفاهیمی مانند LakeHouse ها و استانداردهایی مانند IceBerg و تسهیل امکان اجرای کوئری بر روی فایلهای داده پردازش نشده (خام )، قالب ذخیره Parquet و تا حدودی هم ORC به یک de facto استاندارد در این حوزه تبدیل شده است و در چند سال اخیر، رشد استفاده از آنها را شاهد بودهایم.
با این وجود به نظر میرسد در مرحله گذار از این قالبهای کلاسیک ذخیره ستونی دادهها به قالبهای ذخیره دادههای خام با ضریب فشردگی بالاتر و بهینگی بسیار بیشتر در پردازش و پیمایش هستیم .
تعدادی ازین قالبهای جدید ذخیره دادهها به صورت خام (بدون نیاز به دیتابیس برای ذخیره این اطلاعات) در مقاله زیر معرفی و بررسی شدهاند.
“Make Apache Parquet 10-100x Faster 🚀” That’s one of the motivations! There is no denying in the fact that the #Parquet file format has been instrumental…
https://www.linkedin.com/posts/dipankar-mazumdar_parquet-bigdata-dataengineering-activity-7253095572268613632-Wk2r
نکته مهم در مورد این موضوع این است که هر چقدر قالبهای موثرتر و فشردهتری برای ذخیره خام داده ایجاد شود، رواج LakeHouse ها یا سامانههای تحلیلی مبتنی بر فایلهای خام دیتا سرعت بیشتری خواهد گرفت.
در نظر بگیرید :
– سامانههای ذخیره سازی مانند s3 بسیار رایج شدهاند و هزینه استفاده از آنها هم بسیار کاهش یافته است.
– کتابخانههای پردازش داده، بسیار حرفهای تر و موثرتر شدهاند (مثلا polars در مقابل pandas)
– استانداردهایی برای ساختاردهی به فایلهای خام ایجاد شدهاند که حتی امکان اجرای تراکنشهای ACID را هم روی دادههای خام فراهم میکنند(Apache Iceberg)
– کاتالوگهایی مانند Polaris ، مسأله سطح دسترسی و مسایل امنیتی مرتبط با این فایلهای خام را برطرف کردهاند.
– ابزارهای دمدستی مانند DuckDB برای کار با این استانداردها، ارتقا یافتهاند …
– خیلی از منابع دادهای ما زیر یک ترابایت هستند.(پست اخیر علیرضا صادقی را در این زمینه از دست ندهید)
https://lnkd.in/d7W467Fb
به چه نتیجهای میرسید ؟ آیا ظهور بازیگران جدید و رواج این قالبهای حرفهای ذخیره دادهها در دنیای مهندسی داده که هم سرعت پردازش دیتا را تضمین خواهند کرد و هم نیاز به استفاده از دیتابیس را برای بسیاری از دادههای غیرحیاتی سامانهها، از بین خواهند برد، دور از انتظار نخواهد بود؟
نکات اصلی مقاله فوق :
Now, in the past year or so, there has been a huge effort in bringing other file formats.
✅ Some of these formats take inspiration from Parquet at some level but are targeted towards specific workloads (say unstructured data – machine learning)
✅ Formats like BTRBlocks uses a set of lightweight encoding schemes, achieving fast & efficient decompression & high compression ratios (GitHub Address).
✅ Lance by LanceDB use cases’ are more targeted towards ML (multi modal). Claims 100x faster than Parquet. (check out this blog post)
✅ Nimble by Meta is a new columnar file format for large datasets. It is meant to be a replacement for file formats such as Parquet, ORC. Suited for ML use cases (feature store).
✅ Vortex is another one that claims to provide faster random access reads (100-200x faster) and scans (2-10x faster), while preserving approximately the same compression ratio and write throughput as Parquet with ZSTD. (Vortex’s default compression strategy is based on the BtrBlocks paper.)
Linkedin
#parquet #bigdata #dataengineering #softwareengineering | Dipankar Mazumdar, M.Sc | 10 comments
"Make Apache Parquet 10-100x Faster 🚀"
That's one of the motivations!
There is no denying in the fact that the #Parquet file format has been instrumental in the analytics world.
Specifically for workloads that deals with a large volume of data.
Parquet…
That's one of the motivations!
There is no denying in the fact that the #Parquet file format has been instrumental in the analytics world.
Specifically for workloads that deals with a large volume of data.
Parquet…
👍2
وقت آن رسیده که از JSON استاندارد یک گام جلوتر برویم!
اگر تاکنون هنگام نوشتن فایلهای پیکربندی، با محدودیتهایی مثل ممنوعیت کامنت، اجبار به دابلکوتیشن یا خطاهای ناشی از کاماهای انتهایی مواجه شدهاید، شاید زمان آن رسیده باشد که با JSON5 آشنا شوید — نسخهای توسعهیافته و انسانمحور از JSON که برای خوانایی و راحتی توسعهدهنده طراحی شده است.
🛠 جیسان ۵ - JSON5 چه چیزهایی را ممکن میکند؟
✅ پشتیبانی از کامنتها
✅ کلیدهای بدون کوتیشن
✅ رشتههای تکی (Single-quoted strings)
✅ کاماهای پایانی مجاز (Trailing commas)
✅ پشتیبانی از رشتههای چندخطی
✅ عددهای هگزادسیمال (Hex)
✅ مقادیر ویژه مثل NaN, Infinity, -Infinity, و +Infinity
✅ عدد با علامت مثبت (مثل +42)
✅ فضای بیشتر برای نوشتن تنظیمات قابلفهم برای انسانها
🎯 مناسب برای: فایلهای تنظیمات پروژه، محیطهای توسعه، ابزارهای داخلی، و هرجا که خوانایی و سادگی اولویت دارد.
🚫 نهچندان مناسب برای: تبادل داده با APIها یا ارتباط میانسیستمی — جایی که JSON استاندارد با پشتیبانی وسیع، انتخاب امنتری است.
👨💻 مقاله پیشنهادی برای مطالعه:
“JSON vs. JSON5: More flexible and human-readable configuration files”
✍🏻 نوشتهی Tihomir Manushev
📎 https://freedium.cfd/https://medium.com/@tihomir.manushev/json-vs-json5-7753f5060c90
#JSON #JSON5 #ConfigFiles #DeveloperExperience #DX #SoftwareEngineering #WebDev #CleanCode
اگر تاکنون هنگام نوشتن فایلهای پیکربندی، با محدودیتهایی مثل ممنوعیت کامنت، اجبار به دابلکوتیشن یا خطاهای ناشی از کاماهای انتهایی مواجه شدهاید، شاید زمان آن رسیده باشد که با JSON5 آشنا شوید — نسخهای توسعهیافته و انسانمحور از JSON که برای خوانایی و راحتی توسعهدهنده طراحی شده است.
🛠 جیسان ۵ - JSON5 چه چیزهایی را ممکن میکند؟
✅ پشتیبانی از کامنتها
✅ کلیدهای بدون کوتیشن
✅ رشتههای تکی (Single-quoted strings)
✅ کاماهای پایانی مجاز (Trailing commas)
✅ پشتیبانی از رشتههای چندخطی
✅ عددهای هگزادسیمال (Hex)
✅ مقادیر ویژه مثل NaN, Infinity, -Infinity, و +Infinity
✅ عدد با علامت مثبت (مثل +42)
✅ فضای بیشتر برای نوشتن تنظیمات قابلفهم برای انسانها
🎯 مناسب برای: فایلهای تنظیمات پروژه، محیطهای توسعه، ابزارهای داخلی، و هرجا که خوانایی و سادگی اولویت دارد.
🚫 نهچندان مناسب برای: تبادل داده با APIها یا ارتباط میانسیستمی — جایی که JSON استاندارد با پشتیبانی وسیع، انتخاب امنتری است.
👨💻 مقاله پیشنهادی برای مطالعه:
“JSON vs. JSON5: More flexible and human-readable configuration files”
✍🏻 نوشتهی Tihomir Manushev
📎 https://freedium.cfd/https://medium.com/@tihomir.manushev/json-vs-json5-7753f5060c90
#JSON #JSON5 #ConfigFiles #DeveloperExperience #DX #SoftwareEngineering #WebDev #CleanCode
👍5❤1