🔵 عنوان مقاله
Apache DataFusion 50.0.0 Released (6 minute read)
🟢 خلاصه مقاله:
Apache DataFusion نسخه 50.0.0 با تمرکز بر بهبود کارایی و تجربه تحلیلی منتشر شد. مهم‌ترین بهبودها شامل dynamic filter pushdown برای inner hash joins است که با انتقال فیلترهای حاصل از join به مرحله اسکن، در بسیاری از سناریوها باعث جهش قابل‌توجه در کارایی اسکن می‌شود. همچنین عملگر nested loop join بازنویسی شده و اکنون تا ۵ برابر سریع‌تر اجرا می‌شود و تا ۹۹٪ حافظه کمتری مصرف می‌کند. در کنار این‌ها، قابلیت automatic Parquet metadata caching در پرس‌وجوهای نقطه‌ای (point queries) تا ۱۲ برابر سرعت بیشتر فراهم می‌کند.
از نظر قابلیت‌ها، پشتیبانی از disk-spilling sorts پایداری پردازش مرتب‌سازی را در داده‌های بزرگ با امکان استفاده از دیسک تضمین می‌کند. افزوده شدن عبارات QUALIFY و FILTER نیز نگارش پرس‌وجوهای تحلیلی پیشرفته—از جمله فیلترگذاری پس از window functions و فیلتر روی تجمیع‌ها—را ساده‌تر می‌سازد. علاوه بر این، سازگاری گسترده‌تر با Apache Spark انتقال و اجرای بارهای کاری موجود را با تغییرات کمتر ممکن می‌کند. مجموع این تغییرات، DataFusion 50.0.0 را برای تحلیل تعاملی، ETL و محیط‌های ابری حساس به هزینه به گزینه‌ای ارتقایافته و کارآمد تبدیل می‌کند.
#ApacheDataFusion #DataFusion #BigData #DataEngineering #QueryEngine #Parquet #SQL #ApacheSpark
🟣لینک مقاله:
https://datafusion.apache.org/blog/2025/09/29/datafusion-50.0.0?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Apache DataFusion 50.0.0 Released (6 minute read)
🟢 خلاصه مقاله:
Apache DataFusion نسخه 50.0.0 با تمرکز بر بهبود کارایی و تجربه تحلیلی منتشر شد. مهم‌ترین بهبودها شامل dynamic filter pushdown برای inner hash joins است که با انتقال فیلترهای حاصل از join به مرحله اسکن، در بسیاری از سناریوها باعث جهش قابل‌توجه در کارایی اسکن می‌شود. همچنین عملگر nested loop join بازنویسی شده و اکنون تا ۵ برابر سریع‌تر اجرا می‌شود و تا ۹۹٪ حافظه کمتری مصرف می‌کند. در کنار این‌ها، قابلیت automatic Parquet metadata caching در پرس‌وجوهای نقطه‌ای (point queries) تا ۱۲ برابر سرعت بیشتر فراهم می‌کند.
از نظر قابلیت‌ها، پشتیبانی از disk-spilling sorts پایداری پردازش مرتب‌سازی را در داده‌های بزرگ با امکان استفاده از دیسک تضمین می‌کند. افزوده شدن عبارات QUALIFY و FILTER نیز نگارش پرس‌وجوهای تحلیلی پیشرفته—از جمله فیلترگذاری پس از window functions و فیلتر روی تجمیع‌ها—را ساده‌تر می‌سازد. علاوه بر این، سازگاری گسترده‌تر با Apache Spark انتقال و اجرای بارهای کاری موجود را با تغییرات کمتر ممکن می‌کند. مجموع این تغییرات، DataFusion 50.0.0 را برای تحلیل تعاملی، ETL و محیط‌های ابری حساس به هزینه به گزینه‌ای ارتقایافته و کارآمد تبدیل می‌کند.
#ApacheDataFusion #DataFusion #BigData #DataEngineering #QueryEngine #Parquet #SQL #ApacheSpark
🟣لینک مقاله:
https://datafusion.apache.org/blog/2025/09/29/datafusion-50.0.0?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
🔵 عنوان مقاله
Uber's Strategy to Upgrading 2M+ Spark Jobs (10 minute read)
🟢 خلاصه مقاله:
ارتقای گسترده Uber از Spark 2.4 به Spark 3.3 در مقیاس بزرگ انجام شد و طی شش ماه بیش از ۴۰هزار برنامه Spark و ۲۱۰۰ برنامه دیگر مهاجرت یافت. برای پرهیز از تغییرات دستی زمان‌بر و پرخطا، Uber فرآیند را خودکار کرد و از ابزار متن‌باز Polyglot Piranha استفاده نمود؛ ابزاری که کد را تجزیه کرده و به Abstract Syntax Tree (AST) تبدیل می‌کند تا با اعمال «قوانین تبدیل»، بازنویسی‌های برنامه‌ریزی‌شده و یکدست در سطح انبوه انجام شود. این رویکرد، تغییرات گسترده را با ثبات و سرعت بیشتر ممکن کرد، ریسک خطا را کاهش داد و مسیر بهره‌گیری یکپارچه از قابلیت‌های Spark 3.3 را در زیرساخت داده Uber هموار ساخت.
#Uber #ApacheSpark #PolyglotPiranha #AST #CodeRefactoring #BigData #Migration #Automation
🟣لینک مقاله:
https://www.uber.com/blog/ubers-strategy-to-upgrading-2m-spark-jobs/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Uber's Strategy to Upgrading 2M+ Spark Jobs (10 minute read)
🟢 خلاصه مقاله:
ارتقای گسترده Uber از Spark 2.4 به Spark 3.3 در مقیاس بزرگ انجام شد و طی شش ماه بیش از ۴۰هزار برنامه Spark و ۲۱۰۰ برنامه دیگر مهاجرت یافت. برای پرهیز از تغییرات دستی زمان‌بر و پرخطا، Uber فرآیند را خودکار کرد و از ابزار متن‌باز Polyglot Piranha استفاده نمود؛ ابزاری که کد را تجزیه کرده و به Abstract Syntax Tree (AST) تبدیل می‌کند تا با اعمال «قوانین تبدیل»، بازنویسی‌های برنامه‌ریزی‌شده و یکدست در سطح انبوه انجام شود. این رویکرد، تغییرات گسترده را با ثبات و سرعت بیشتر ممکن کرد، ریسک خطا را کاهش داد و مسیر بهره‌گیری یکپارچه از قابلیت‌های Spark 3.3 را در زیرساخت داده Uber هموار ساخت.
#Uber #ApacheSpark #PolyglotPiranha #AST #CodeRefactoring #BigData #Migration #Automation
🟣لینک مقاله:
https://www.uber.com/blog/ubers-strategy-to-upgrading-2m-spark-jobs/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
🔵 عنوان مقاله
How We Scaled Raw GROUP BY to 100 B+ Rows In Under A Second (30 minute read)
🟢 خلاصه مقاله:
کلیک‌هاوس با معرفی قابلیت Parallel Replicas نشان می‌دهد چگونه می‌توان اجرای پرس‌وجوهای GROUP BY را به‌صورت افقی و بدون تغییر در چیدمان داده‌ها مقیاس داد؛ به‌گونه‌ای که تجمیع بیش از ۱۰۰ میلیارد ردیف در کمتر از یک ثانیه ممکن شود. در این روش، کار یک پرس‌وجوی واحد میان همه‌ی Replicaهای یک Shard تقسیم می‌شود، هر Replica بخشی از داده را می‌خواند و تجمیع‌های جزئی را می‌سازد، و در پایان نتایج به‌صورت قطعی با هم ادغام می‌شوند.
این رویکرد، بدون نیاز به Re-sharding، از Replicaها برای موازی‌سازی Query استفاده می‌کند، با SQL استاندارد سازگار است، و تأخیر انتهایی را برای داشبوردها و تحلیل‌های تعاملی کاهش می‌دهد. به‌دلیل سهم بالای GROUP BY در پرس‌وجوهای BI و رشد بارهای observability و AI analytics، Parallel Replicas راهی عملی برای مقیاس‌پذیری تقریباً نامحدود فراهم می‌کند و نمونه‌ی ۱۰۰B+ ردیف در <۱ ثانیه نشان می‌دهد که استفاده از Replicaها به‌عنوان ظرفیت محاسباتی موازی چه جهشی در کارایی ایجاد می‌کند.
#ClickHouse #ParallelReplicas #GROUPBY #Scalability #BigData #Analytics #OLAP #RealTime
🟣لینک مقاله:
https://clickhouse.com/blog/clickhouse-parallel-replicas?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
How We Scaled Raw GROUP BY to 100 B+ Rows In Under A Second (30 minute read)
🟢 خلاصه مقاله:
کلیک‌هاوس با معرفی قابلیت Parallel Replicas نشان می‌دهد چگونه می‌توان اجرای پرس‌وجوهای GROUP BY را به‌صورت افقی و بدون تغییر در چیدمان داده‌ها مقیاس داد؛ به‌گونه‌ای که تجمیع بیش از ۱۰۰ میلیارد ردیف در کمتر از یک ثانیه ممکن شود. در این روش، کار یک پرس‌وجوی واحد میان همه‌ی Replicaهای یک Shard تقسیم می‌شود، هر Replica بخشی از داده را می‌خواند و تجمیع‌های جزئی را می‌سازد، و در پایان نتایج به‌صورت قطعی با هم ادغام می‌شوند.
این رویکرد، بدون نیاز به Re-sharding، از Replicaها برای موازی‌سازی Query استفاده می‌کند، با SQL استاندارد سازگار است، و تأخیر انتهایی را برای داشبوردها و تحلیل‌های تعاملی کاهش می‌دهد. به‌دلیل سهم بالای GROUP BY در پرس‌وجوهای BI و رشد بارهای observability و AI analytics، Parallel Replicas راهی عملی برای مقیاس‌پذیری تقریباً نامحدود فراهم می‌کند و نمونه‌ی ۱۰۰B+ ردیف در <۱ ثانیه نشان می‌دهد که استفاده از Replicaها به‌عنوان ظرفیت محاسباتی موازی چه جهشی در کارایی ایجاد می‌کند.
#ClickHouse #ParallelReplicas #GROUPBY #Scalability #BigData #Analytics #OLAP #RealTime
🟣لینک مقاله:
https://clickhouse.com/blog/clickhouse-parallel-replicas?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
ClickHouse
How we scaled raw GROUP BY to 100 B+ rows in under a second
ClickHouse Cloud now scales analytical queries with parallel replicas, fanning a single query across thousands of cores for terabyte-per-second throughput. This post dives into the internals and lets you see and feel the speed.
👍1🔥1
🔵 عنوان مقاله
Why You Should Prefer MERGE INTO Over INSERT OVERWRITE in Apache Iceberg (7 minute read)
🟢 خلاصه مقاله:
MERGE INTO همراه با استراتژی Merge-on-Read (MOR) در Apache Iceberg برای به‌روزرسانی داده‌ها معمولاً بهتر از INSERT OVERWRITE است، زیرا به‌جای بازنویسی پارتیشن‌ها، تغییرات را به‌صورت دلتا در سطح فایل اضافه می‌کند؛ نتیجه این کار کاهش I/O، زمان اجرای کوتاه‌تر و صرفه‌جویی در هزینه ذخیره‌سازی است. در مقابل، INSERT OVERWRITE با هر تغییر کوچک مجبور به بازنویسی کامل پارتیشن می‌شود و در مواجهه با Partition Evolution آسیب‌پذیرتر است. رویکرد MOR با تکیه بر تکامل پارتیشن مبتنی بر متادیتا، بدون بازنویسی داده‌های تاریخی، با الگوهای افزایشی مثل CDC و رویدادهای دیررس سازگار است. نقطه ضعف MOR نیاز به فشرده‌سازی و خانه‌تکانی دوره‌ای و اندکی سربار در خواندن برای اعمال دلتاهاست؛ با این حال، برای اغلب بارهای کاری افزایشی، انتخاب پیش‌فرض بهتر MERGE INTO (MOR) است و INSERT OVERWRITE فقط زمانی توصیه می‌شود که قصد بازسازی کامل یا اصلاح گسترده و مشخص داده را دارید.
#ApacheIceberg #MERGEINTO #MergeOnRead #DataEngineering #DataLakehouse #PartitionEvolution #BigData #ETL
🟣لینک مقاله:
https://medium.com/expedia-group-tech/why-you-should-prefer-merge-into-over-insert-overwrite-in-apache-iceberg-b6b130cc27d2?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Why You Should Prefer MERGE INTO Over INSERT OVERWRITE in Apache Iceberg (7 minute read)
🟢 خلاصه مقاله:
MERGE INTO همراه با استراتژی Merge-on-Read (MOR) در Apache Iceberg برای به‌روزرسانی داده‌ها معمولاً بهتر از INSERT OVERWRITE است، زیرا به‌جای بازنویسی پارتیشن‌ها، تغییرات را به‌صورت دلتا در سطح فایل اضافه می‌کند؛ نتیجه این کار کاهش I/O، زمان اجرای کوتاه‌تر و صرفه‌جویی در هزینه ذخیره‌سازی است. در مقابل، INSERT OVERWRITE با هر تغییر کوچک مجبور به بازنویسی کامل پارتیشن می‌شود و در مواجهه با Partition Evolution آسیب‌پذیرتر است. رویکرد MOR با تکیه بر تکامل پارتیشن مبتنی بر متادیتا، بدون بازنویسی داده‌های تاریخی، با الگوهای افزایشی مثل CDC و رویدادهای دیررس سازگار است. نقطه ضعف MOR نیاز به فشرده‌سازی و خانه‌تکانی دوره‌ای و اندکی سربار در خواندن برای اعمال دلتاهاست؛ با این حال، برای اغلب بارهای کاری افزایشی، انتخاب پیش‌فرض بهتر MERGE INTO (MOR) است و INSERT OVERWRITE فقط زمانی توصیه می‌شود که قصد بازسازی کامل یا اصلاح گسترده و مشخص داده را دارید.
#ApacheIceberg #MERGEINTO #MergeOnRead #DataEngineering #DataLakehouse #PartitionEvolution #BigData #ETL
🟣لینک مقاله:
https://medium.com/expedia-group-tech/why-you-should-prefer-merge-into-over-insert-overwrite-in-apache-iceberg-b6b130cc27d2?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Medium
Why You Should Prefer MERGE INTO Over INSERT OVERWRITE in Apache Iceberg
Stop overwriting —start merging: a smarter approach to updating Iceberg tables