🔵 عنوان مقاله
The Great Consolidation is underway (2 minute read)
🟢 خلاصه مقاله:
** روند The Great Consolidation در مهندسی داده سرعت گرفته است؛ ادغامهایی مثل Fivetran نشان میدهد بازاری که سالها بیشازحد داغ شده بود، حالا در حال بلوغ و یکپارچهسازی ابزارهای همپوشان است. محرکها شامل خستگی از تکثر ابزارها و هزینههای یکپارچهسازی، فشار برای کاهش هزینهها، و نیاز به حاکمیت، امنیت و مشاهدهپذیری یکپارچه است. پیامدها: ابزارهای تخصصی کمتر و پلتفرمهای جامعتر، تغییر در نقشهراهها، ادغام یا توقف برخی محصولات، و ریسکهای جابهجایی و قفلشدن در فروشنده. راهکار: تکیه بر استانداردها و رابطهای باز، معماری ماژولار، شروط خروج در قراردادها و ارزیابی TCO برای حفظ اختیار عمل. برندگان، پلتفرمهای انتهابهانتها با حاکمیت قوی خواهند بود و ابزارهای نیچی تنها با برتری ۱۰ برابری میمانند. تمرکز بازار از هیجان به پایداری، کارایی و نتایج اندازهپذیر منتقل میشود.
#DataEngineering #Consolidation #MergersAndAcquisitions #DataStack #VendorLockIn #DataPlatforms #Fivetran
🟣لینک مقاله:
https://www.reddit.com/r/dataengineering/comments/1nulrd5/the_great_consolidation_is_underway/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
The Great Consolidation is underway (2 minute read)
🟢 خلاصه مقاله:
** روند The Great Consolidation در مهندسی داده سرعت گرفته است؛ ادغامهایی مثل Fivetran نشان میدهد بازاری که سالها بیشازحد داغ شده بود، حالا در حال بلوغ و یکپارچهسازی ابزارهای همپوشان است. محرکها شامل خستگی از تکثر ابزارها و هزینههای یکپارچهسازی، فشار برای کاهش هزینهها، و نیاز به حاکمیت، امنیت و مشاهدهپذیری یکپارچه است. پیامدها: ابزارهای تخصصی کمتر و پلتفرمهای جامعتر، تغییر در نقشهراهها، ادغام یا توقف برخی محصولات، و ریسکهای جابهجایی و قفلشدن در فروشنده. راهکار: تکیه بر استانداردها و رابطهای باز، معماری ماژولار، شروط خروج در قراردادها و ارزیابی TCO برای حفظ اختیار عمل. برندگان، پلتفرمهای انتهابهانتها با حاکمیت قوی خواهند بود و ابزارهای نیچی تنها با برتری ۱۰ برابری میمانند. تمرکز بازار از هیجان به پایداری، کارایی و نتایج اندازهپذیر منتقل میشود.
#DataEngineering #Consolidation #MergersAndAcquisitions #DataStack #VendorLockIn #DataPlatforms #Fivetran
🟣لینک مقاله:
https://www.reddit.com/r/dataengineering/comments/1nulrd5/the_great_consolidation_is_underway/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Reddit
From the dataengineering community on Reddit: The Great Consolidation is underway
Explore this post and more from the dataengineering community
🔵 عنوان مقاله
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
🔵 عنوان مقاله
How the COPY Command Gets More User Friendly in Postgres 18
🟢 خلاصه مقاله:
بهروزرسانیهای Postgres 18 بر بهبود تجربه کاربری تمرکز دارد؛ از جمله آسانتر و ایمنتر شدن کار با دستور COPY. هدف این است که پیامهای خطا در مواجهه با ناسازگاری ستونها، مسائل کدگذاری یا ردیفهای CSV معیوب شفافتر و قابل اقدامتر شوند، گزینههای رایج (مثل کار با هدرها و CSV) رفتار پیشفرض قابلاعتمادتری داشته باشند، و جریانهای کاری واردسازی انبوه با امکان نادیدهگرفتن یا ثبت ردیفهای خطادار اصطکاک کمتری داشته باشند. همچنین همگرایی رفتار بین COPY سمت سرور و copy در psql و شفافیت بیشتر در مجوزها و متن خطاها به پیشبینیپذیری و عیبیابی سریعتر کمک میکند.
در کنار اینها، کار روی cumulative statistics نیز پررنگ است. همانطور که Deepak Mahto و Cédric Villemain توضیح میدهند، هدف، ارائه نمایی منسجمتر، کمهزینهتر و دانهدرشتتر از رفتار سیستم در حوزههایی مانند پرسوجو، I/O و waitهاست تا هم پایش آنی و هم برنامهریزی ظرفیت سادهتر شود. برآیند این تغییرات، کاهش غافلگیریها با پیشفرضهای بهتر، بازخورد سریعتر هنگام خطا و مشاهدهپذیری عمیقتر برای تنظیم کارایی در Postgres 18 است.
#Postgres18 #PostgreSQL #COPY #CumulativeStatistics #Database #Observability #DataEngineering #DX
🟣لینک مقاله:
https://postgresweekly.com/link/175100/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
How the COPY Command Gets More User Friendly in Postgres 18
🟢 خلاصه مقاله:
بهروزرسانیهای Postgres 18 بر بهبود تجربه کاربری تمرکز دارد؛ از جمله آسانتر و ایمنتر شدن کار با دستور COPY. هدف این است که پیامهای خطا در مواجهه با ناسازگاری ستونها، مسائل کدگذاری یا ردیفهای CSV معیوب شفافتر و قابل اقدامتر شوند، گزینههای رایج (مثل کار با هدرها و CSV) رفتار پیشفرض قابلاعتمادتری داشته باشند، و جریانهای کاری واردسازی انبوه با امکان نادیدهگرفتن یا ثبت ردیفهای خطادار اصطکاک کمتری داشته باشند. همچنین همگرایی رفتار بین COPY سمت سرور و copy در psql و شفافیت بیشتر در مجوزها و متن خطاها به پیشبینیپذیری و عیبیابی سریعتر کمک میکند.
در کنار اینها، کار روی cumulative statistics نیز پررنگ است. همانطور که Deepak Mahto و Cédric Villemain توضیح میدهند، هدف، ارائه نمایی منسجمتر، کمهزینهتر و دانهدرشتتر از رفتار سیستم در حوزههایی مانند پرسوجو، I/O و waitهاست تا هم پایش آنی و هم برنامهریزی ظرفیت سادهتر شود. برآیند این تغییرات، کاهش غافلگیریها با پیشفرضهای بهتر، بازخورد سریعتر هنگام خطا و مشاهدهپذیری عمیقتر برای تنظیم کارایی در Postgres 18 است.
#Postgres18 #PostgreSQL #COPY #CumulativeStatistics #Database #Observability #DataEngineering #DX
🟣لینک مقاله:
https://postgresweekly.com/link/175100/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Database and Migration Insights
Exploring PostgreSQL 18: A Developer’s Guide to New Features – Part 1: The COPY Command Gets More User-Friendly
PostgreSQL 18, released on September 25, 2024, enhances the COPY command with improved error handling through the REJECT_LIMIT option, allowing data loading to be controlled by limiting errors. Thi…
🙏1
🔵 عنوان مقاله
Introducing Apache Airflow® 3.1 (8 minute read)
🟢 خلاصه مقاله:
**نسخه 3.1 از Apache Airflow با تمرکز بر جریانهای داده مدرن، امکاناتی مانند اپراتورهای HITL و اجرای همگام DAG را برای پوشش بهتر سناریوهای GenAI/MLOps ارائه میکند. این نسخه یک رابط افزونه مبتنی بر React برای توسعه رابط کاربری سفارشی اضافه کرده و تجربه کاربری را با قابلیتهایی مثل افزودن DAG به علاقهمندیها و انتخاب زبان بهبود میدهد. همچنین زمان پارس شدن DAGها را نمایش میدهد، از Python 3.13 پشتیبانی میکند و یک trigger rule جدید برای انعطافپذیری بیشتر در تعریف وابستگیها ارائه شده است.
#ApacheAirflow #Airflow3_1 #DataEngineering #MLOps #GenAI #Python313 #DAG #WorkflowOrchestration
🟣لینک مقاله:
https://www.astronomer.io/blog/introducing-apache-airflow-3-1/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Introducing Apache Airflow® 3.1 (8 minute read)
🟢 خلاصه مقاله:
**نسخه 3.1 از Apache Airflow با تمرکز بر جریانهای داده مدرن، امکاناتی مانند اپراتورهای HITL و اجرای همگام DAG را برای پوشش بهتر سناریوهای GenAI/MLOps ارائه میکند. این نسخه یک رابط افزونه مبتنی بر React برای توسعه رابط کاربری سفارشی اضافه کرده و تجربه کاربری را با قابلیتهایی مثل افزودن DAG به علاقهمندیها و انتخاب زبان بهبود میدهد. همچنین زمان پارس شدن DAGها را نمایش میدهد، از Python 3.13 پشتیبانی میکند و یک trigger rule جدید برای انعطافپذیری بیشتر در تعریف وابستگیها ارائه شده است.
#ApacheAirflow #Airflow3_1 #DataEngineering #MLOps #GenAI #Python313 #DAG #WorkflowOrchestration
🟣لینک مقاله:
https://www.astronomer.io/blog/introducing-apache-airflow-3-1/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
www.astronomer.io
Introducing Apache Airflow® 3.1
The momentum continues from the release of Airflow 3
🔵 عنوان مقاله
Why Python Data Engineers Should Know Kafka and Flink (3 minute read)
🟢 خلاصه مقاله:
یادگیری Kafka و Flink برای مهندسان دادهی Python مسیر سریع ساخت سامانههای استریمی قابلاتکا و کمتأخیر است، بدون نیاز به ترک زبان و ابزارهای آشنا. پیشرفتهای اخیر در Python API—بهویژه PyFlink و کلاینتهای پختهی Kafka—امکان ساخت کل پایپلاینهای استریم را با همان سینتکس Python فراهم کردهاند: خواندن/نوشتن از Kafka، پردازش stateful با پنجرهها و watermarks، و تضمینهای exactly-once، همگی از دل Python. نتیجه این است که میتوانید منطق کسبوکار را در Python بنویسید و Flink بار سنگین مقیاس، وضعیت و پایداری را برعهده بگیرد. کاربردها شامل ETL بلادرنگ، پایش عملیاتی، KPIهای نزدیک به زمان واقعی و پایپلاین ویژگیهای ML است. شروع کار ساده است: یک topic در Kafka، یک job کوچک در PyFlink برای تجمع پنجرهای، و سپس سختسازی با checkpoint، تکامل اسکیمایی و رصدپذیری.
#Python #Kafka #Flink #PyFlink #StreamProcessing #DataEngineering #RealTimeData #EventDriven
🟣لینک مقاله:
https://thenewstack.io/why-python-data-engineers-should-know-kafka-and-flink/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Why Python Data Engineers Should Know Kafka and Flink (3 minute read)
🟢 خلاصه مقاله:
یادگیری Kafka و Flink برای مهندسان دادهی Python مسیر سریع ساخت سامانههای استریمی قابلاتکا و کمتأخیر است، بدون نیاز به ترک زبان و ابزارهای آشنا. پیشرفتهای اخیر در Python API—بهویژه PyFlink و کلاینتهای پختهی Kafka—امکان ساخت کل پایپلاینهای استریم را با همان سینتکس Python فراهم کردهاند: خواندن/نوشتن از Kafka، پردازش stateful با پنجرهها و watermarks، و تضمینهای exactly-once، همگی از دل Python. نتیجه این است که میتوانید منطق کسبوکار را در Python بنویسید و Flink بار سنگین مقیاس، وضعیت و پایداری را برعهده بگیرد. کاربردها شامل ETL بلادرنگ، پایش عملیاتی، KPIهای نزدیک به زمان واقعی و پایپلاین ویژگیهای ML است. شروع کار ساده است: یک topic در Kafka، یک job کوچک در PyFlink برای تجمع پنجرهای، و سپس سختسازی با checkpoint، تکامل اسکیمایی و رصدپذیری.
#Python #Kafka #Flink #PyFlink #StreamProcessing #DataEngineering #RealTimeData #EventDriven
🟣لینک مقاله:
https://thenewstack.io/why-python-data-engineers-should-know-kafka-and-flink/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
The New Stack
Why Python Data Engineers Should Know Kafka and Flink
Excellent integrations make these frameworks seamlessly accessible to Python developers, allowing them to use these powerful tools without deep Java knowledge.
🔵 عنوان مقاله
Apache Parquet vs. Newer File Formats (BtrBlocks, FastLanes, Lance, Vortex) (7 minute read)
🟢 خلاصه مقاله:
Apache Parquet بیش از یک دهه فرمت ستونی غالب بوده و به لطف چیدمان ستونی، فشردهسازی مؤثر و پشتیبانی گسترده در اکوسیستمهایی مثل Spark و Iceberg، برای اسکنهای حجیم و تحلیلهای دستهای عالی عمل میکند. اما با تغییر نیازها به سمت AI و سختافزارهای جدید مثل NVMe، SIMD و GPU، فرمتهای تازهای مانند BtrBlocks، FastLanes، Lance، Vortex و Nimble معرفی شدهاند که روی دسترسی کمتأخیر، بهرهگیری از SIMD/GPU و خواندن گزینشی داده تمرکز دارند. این فرمتها معمولاً با بازطراحی کُدگذاری و چیدمان صفحات، سربار پردازش را کاهش میدهند و برای پایپلاینهای AI و تحلیل تعاملی مناسبتر میشوند. در مقابل، Parquet از بلوغ و سازگاری گسترده برخوردار است و ابزارها و عملیات پایدارتری دارد. راهبرد منطقی، حفظ Parquet برای تبادل و تحلیل عمومی و استفاده هدفمند از فرمتهای جدید در سناریوهایی است که بهبود ملموسی در تأخیر یا هزینه محاسباتی روی NVMe/GPU نشان میدهند.
#ApacheParquet #FileFormats #ColumnarStorage #AI #GPU #NVMe #SIMD #DataEngineering
🟣لینک مقاله:
https://dipankar-tnt.medium.com/apache-parquet-vs-newer-file-formats-btrblocks-fastlanes-lance-vortex-cdf02130182c?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Apache Parquet vs. Newer File Formats (BtrBlocks, FastLanes, Lance, Vortex) (7 minute read)
🟢 خلاصه مقاله:
Apache Parquet بیش از یک دهه فرمت ستونی غالب بوده و به لطف چیدمان ستونی، فشردهسازی مؤثر و پشتیبانی گسترده در اکوسیستمهایی مثل Spark و Iceberg، برای اسکنهای حجیم و تحلیلهای دستهای عالی عمل میکند. اما با تغییر نیازها به سمت AI و سختافزارهای جدید مثل NVMe، SIMD و GPU، فرمتهای تازهای مانند BtrBlocks، FastLanes، Lance، Vortex و Nimble معرفی شدهاند که روی دسترسی کمتأخیر، بهرهگیری از SIMD/GPU و خواندن گزینشی داده تمرکز دارند. این فرمتها معمولاً با بازطراحی کُدگذاری و چیدمان صفحات، سربار پردازش را کاهش میدهند و برای پایپلاینهای AI و تحلیل تعاملی مناسبتر میشوند. در مقابل، Parquet از بلوغ و سازگاری گسترده برخوردار است و ابزارها و عملیات پایدارتری دارد. راهبرد منطقی، حفظ Parquet برای تبادل و تحلیل عمومی و استفاده هدفمند از فرمتهای جدید در سناریوهایی است که بهبود ملموسی در تأخیر یا هزینه محاسباتی روی NVMe/GPU نشان میدهند.
#ApacheParquet #FileFormats #ColumnarStorage #AI #GPU #NVMe #SIMD #DataEngineering
🟣لینک مقاله:
https://dipankar-tnt.medium.com/apache-parquet-vs-newer-file-formats-btrblocks-fastlanes-lance-vortex-cdf02130182c?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Medium
Apache Parquet vs. Newer File Formats (BtrBlocks, FastLanes, Lance, Vortex)
For over a decade, Apache Parquet has been the cornerstone of analytical data storage. Parquet emerged in the Hadoop era as an open…
🔵 عنوان مقاله
SQLMesh, dbt, and Fivetran... What's Next? (5 minute read)
🟢 خلاصه مقاله:
فشردهسازی اخیر در اکوسیستم Modern Data Stack با تصاحب dbt توسط Fivetran و یکپارچهسازیهای اخیر با Tobiko Data و Census نشان میدهد که لایههای ingestion، transformation، modeling و حتی activation به سمت تجمیع زیر چتر چند فروشنده محدود میروند. این روند میتواند کار را برای تیمها سادهتر کند و به متادیتا، lineage، حاکمیت و صورتحساب یکپارچه بینجامد، اما ریسکهایی هم دارد: کوچک شدن سطح open-source و دورتر شدن قابلیتهای dbt Core از dbt Fusion که میتواند به قفلشدن در فروشنده و تجربههای نامتوازن منجر شود. در این میان، ابزارهایی مثل SQLMesh با تأکید بر قابلیت اطمینان، تغییرات مبتنیبر plan و سازگاری با پروژههای dbt گزینهای برای حفظ انعطافپذیری و اجرای موازی یا مسیرهای مهاجرتی هستند. در آینده باید انتظار یکپارچگی بیشتر پلتفرمی و استانداردهای در حال تغییر را داشت. تیمها بهتر است وابستگیهای خود به dbt Core در برابر قابلیتهای مدیریتشده را بسنجند، اصول قابلحمل بودن (قراردادهای داده، استانداردهای lineage، چکهای CI/CD) را تعریف کنند، لایههای ذخیرهسازی/محاسبات را از ارکستراسیون جدا نگه دارند و با گزینههایی مانند SQLMesh آزمایشهای هدفمند انجام دهند تا برای تغییرات پیشرو آماده باشند.
#ModernDataStack #dbt #Fivetran #DataEngineering #OpenSource #SQLMesh #AnalyticsEngineering
🟣لینک مقاله:
https://smallbigdata.substack.com/p/sqlmesh-dbt-and-fivetran-whats-next?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
SQLMesh, dbt, and Fivetran... What's Next? (5 minute read)
🟢 خلاصه مقاله:
فشردهسازی اخیر در اکوسیستم Modern Data Stack با تصاحب dbt توسط Fivetran و یکپارچهسازیهای اخیر با Tobiko Data و Census نشان میدهد که لایههای ingestion، transformation، modeling و حتی activation به سمت تجمیع زیر چتر چند فروشنده محدود میروند. این روند میتواند کار را برای تیمها سادهتر کند و به متادیتا، lineage، حاکمیت و صورتحساب یکپارچه بینجامد، اما ریسکهایی هم دارد: کوچک شدن سطح open-source و دورتر شدن قابلیتهای dbt Core از dbt Fusion که میتواند به قفلشدن در فروشنده و تجربههای نامتوازن منجر شود. در این میان، ابزارهایی مثل SQLMesh با تأکید بر قابلیت اطمینان، تغییرات مبتنیبر plan و سازگاری با پروژههای dbt گزینهای برای حفظ انعطافپذیری و اجرای موازی یا مسیرهای مهاجرتی هستند. در آینده باید انتظار یکپارچگی بیشتر پلتفرمی و استانداردهای در حال تغییر را داشت. تیمها بهتر است وابستگیهای خود به dbt Core در برابر قابلیتهای مدیریتشده را بسنجند، اصول قابلحمل بودن (قراردادهای داده، استانداردهای lineage، چکهای CI/CD) را تعریف کنند، لایههای ذخیرهسازی/محاسبات را از ارکستراسیون جدا نگه دارند و با گزینههایی مانند SQLMesh آزمایشهای هدفمند انجام دهند تا برای تغییرات پیشرو آماده باشند.
#ModernDataStack #dbt #Fivetran #DataEngineering #OpenSource #SQLMesh #AnalyticsEngineering
🟣لینک مقاله:
https://smallbigdata.substack.com/p/sqlmesh-dbt-and-fivetran-whats-next?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Substack
SQLMesh, dbt and Fivetran... what's next?
A Turning Point for the Data Engineering Landscape
🔵 عنوان مقاله
F3: The Open-Source Data File Format for the Future (45 minute read)
🟢 خلاصه مقاله:
F3 یک فرمت ستونی متنباز و نسل جدید است که با تمرکز بر میانعملیاتی، توسعهپذیری و کارایی طراحی شده و هنوز در حال تکامل است. نوآوری اصلی آن جاسازی منطق رمزگشایی WebAssembly داخل هر فایل است تا خوانندههای قدیمی و جدید بتوانند بدون بهروزرسانی همزمان کتابخانهها، رمزگذاریهای تازه را تفسیر کنند. F3 با جدا کردن چیدمان واحدهای I/O از گروههای ردیف، امکان بهینهسازی برای الگوهای دسترسی گوناگون را فراهم میکند؛ همچنین با پشتیبانی از محدودههای لغتنامهای انعطافپذیر و استفاده از flatbuffers برای دسترسی سریع به فراداده، هم فشردهسازی و هم سرعت رمزگشایی را بهبود میدهد. ارزیابیها نشان میدهد F3 از نظر کارایی همتراز Parquet و ORC است و در عین حال تکامل بیدردسر فرمت را ممکن میسازد؛ کد پیادهسازی آن نیز بهصورت عمومی در دسترس است.
#DataFormats #ColumnarStorage #WebAssembly #OpenSource #Parquet #ORC #FlatBuffers #DataEngineering
🟣لینک مقاله:
https://db.cs.cmu.edu/papers/2025/zeng-sigmod2025.pdf?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
F3: The Open-Source Data File Format for the Future (45 minute read)
🟢 خلاصه مقاله:
F3 یک فرمت ستونی متنباز و نسل جدید است که با تمرکز بر میانعملیاتی، توسعهپذیری و کارایی طراحی شده و هنوز در حال تکامل است. نوآوری اصلی آن جاسازی منطق رمزگشایی WebAssembly داخل هر فایل است تا خوانندههای قدیمی و جدید بتوانند بدون بهروزرسانی همزمان کتابخانهها، رمزگذاریهای تازه را تفسیر کنند. F3 با جدا کردن چیدمان واحدهای I/O از گروههای ردیف، امکان بهینهسازی برای الگوهای دسترسی گوناگون را فراهم میکند؛ همچنین با پشتیبانی از محدودههای لغتنامهای انعطافپذیر و استفاده از flatbuffers برای دسترسی سریع به فراداده، هم فشردهسازی و هم سرعت رمزگشایی را بهبود میدهد. ارزیابیها نشان میدهد F3 از نظر کارایی همتراز Parquet و ORC است و در عین حال تکامل بیدردسر فرمت را ممکن میسازد؛ کد پیادهسازی آن نیز بهصورت عمومی در دسترس است.
#DataFormats #ColumnarStorage #WebAssembly #OpenSource #Parquet #ORC #FlatBuffers #DataEngineering
🟣لینک مقاله:
https://db.cs.cmu.edu/papers/2025/zeng-sigmod2025.pdf?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
🔵 عنوان مقاله
Spark Config Madness (3 minute read)
🟢 خلاصه مقاله:
اجرای Spark روی جدولهای Iceberg که توسط AWS Glue مدیریت میشوند، با استفاده از پکیجهای رسمی AWS Iceberg Glue، تمام عملیاتهای متداول مانند CTAS، MERGE، UPDATE، DELETE و INSERT را پشتیبانی میکند و قابلیتهایی مثل snapshot isolation و تکامل اسکیمای Iceberg را روی دادههای مبتنی بر S3 به ارمغان میآورد. با چند تنظیم ساده برای Spark—از جمله فعالسازی افزونههای Iceberg، تعریف Glue بهعنوان کاتالوگ، و استفاده از Default AWS Credential Chain—میتوان هم امنیت و هم انطباق با محیط تولید را حفظ کرد و از سختکد کردن رازها پرهیز نمود. با این رویکرد، ساخت جدولهای جدید با CTAS، انجام upsertها با MERGE و پاکسازی هدفمند دادهها ممکن میشود و Iceberg مدیریت متادیتا و همزمانی را بر عهده میگیرد. با این حال، پیچیدگی تنظیمات، سازگاری نسخهها و ظرایف کار با S3 یادآور میشود که استفاده از سرویسهای مدیریتشدهی Spark یا پایگاهدادهها میتواند هزینه و سربار مهندسی را بهطور معناداری کاهش دهد.
#ApacheSpark #AWS #AWSGlue #ApacheIceberg #S3 #DataEngineering #Lakehouse #ETL
🟣لینک مقاله:
https://performancede.substack.com/p/spark-config-madness?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Spark Config Madness (3 minute read)
🟢 خلاصه مقاله:
اجرای Spark روی جدولهای Iceberg که توسط AWS Glue مدیریت میشوند، با استفاده از پکیجهای رسمی AWS Iceberg Glue، تمام عملیاتهای متداول مانند CTAS، MERGE، UPDATE، DELETE و INSERT را پشتیبانی میکند و قابلیتهایی مثل snapshot isolation و تکامل اسکیمای Iceberg را روی دادههای مبتنی بر S3 به ارمغان میآورد. با چند تنظیم ساده برای Spark—از جمله فعالسازی افزونههای Iceberg، تعریف Glue بهعنوان کاتالوگ، و استفاده از Default AWS Credential Chain—میتوان هم امنیت و هم انطباق با محیط تولید را حفظ کرد و از سختکد کردن رازها پرهیز نمود. با این رویکرد، ساخت جدولهای جدید با CTAS، انجام upsertها با MERGE و پاکسازی هدفمند دادهها ممکن میشود و Iceberg مدیریت متادیتا و همزمانی را بر عهده میگیرد. با این حال، پیچیدگی تنظیمات، سازگاری نسخهها و ظرایف کار با S3 یادآور میشود که استفاده از سرویسهای مدیریتشدهی Spark یا پایگاهدادهها میتواند هزینه و سربار مهندسی را بهطور معناداری کاهش دهد.
#ApacheSpark #AWS #AWSGlue #ApacheIceberg #S3 #DataEngineering #Lakehouse #ETL
🟣لینک مقاله:
https://performancede.substack.com/p/spark-config-madness?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Substack
Spark Config Madness
Will it Ever Stop?
🔵 عنوان مقاله
AWS Glue Iceberg Rest Catalog (5 minute read)
🟢 خلاصه مقاله:
AWS Glue 5.0 با تکیه بر Apache Iceberg و Iceberg REST catalog قابل شبیهسازی در محیط محلی است تا بتوان منطق ETL، طراحی جدول و رفتار کوئری را بدون هزینه EMR آزمایش کرد. با راهاندازی یک سرویس محلی Iceberg REST catalog و تنظیم Spark برای استفاده از آن، ساخت و تغییر طرح، پارتیشنبندی، snapshots و time travel بهصورت محلی قابل ارزیابی میشود. مراحل کلیدی شامل نصب Spark با وابستگیهای Iceberg، اجرای سرویس REST catalog، تنظیم URI و مسیر warehouse محلی و سپس اجرای سناریوهای ETL و پرسوجوهاست. این روش چرخه توسعه را سریع میکند و امکان تستهای تکرارپذیر را فراهم میسازد، هرچند تفاوتهایی مثل نبود IAM و تفاوت کارایی با فضای ابری وجود دارد؛ بنابراین پیش از استقرار نهایی، اعتبارسنجی در staging روی AWS Glue یا EMR توصیه میشود.
#AWSGlue #ApacheIceberg #Spark #ETL #RESTCatalog #EMR #DataEngineering #Lakehouse
🟣لینک مقاله:
https://performancede.substack.com/p/aws-glue-iceberg-rest-catalog?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
AWS Glue Iceberg Rest Catalog (5 minute read)
🟢 خلاصه مقاله:
AWS Glue 5.0 با تکیه بر Apache Iceberg و Iceberg REST catalog قابل شبیهسازی در محیط محلی است تا بتوان منطق ETL، طراحی جدول و رفتار کوئری را بدون هزینه EMR آزمایش کرد. با راهاندازی یک سرویس محلی Iceberg REST catalog و تنظیم Spark برای استفاده از آن، ساخت و تغییر طرح، پارتیشنبندی، snapshots و time travel بهصورت محلی قابل ارزیابی میشود. مراحل کلیدی شامل نصب Spark با وابستگیهای Iceberg، اجرای سرویس REST catalog، تنظیم URI و مسیر warehouse محلی و سپس اجرای سناریوهای ETL و پرسوجوهاست. این روش چرخه توسعه را سریع میکند و امکان تستهای تکرارپذیر را فراهم میسازد، هرچند تفاوتهایی مثل نبود IAM و تفاوت کارایی با فضای ابری وجود دارد؛ بنابراین پیش از استقرار نهایی، اعتبارسنجی در staging روی AWS Glue یا EMR توصیه میشود.
#AWSGlue #ApacheIceberg #Spark #ETL #RESTCatalog #EMR #DataEngineering #Lakehouse
🟣لینک مقاله:
https://performancede.substack.com/p/aws-glue-iceberg-rest-catalog?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Substack
AWS Glue Iceberg Rest Catalog
An Exhaustive Test
❤1
🔵 عنوان مقاله
Practical Guide to Semantic Layers: From Definition to Demo (10 minute read)
🟢 خلاصه مقاله:
این راهنمای ۱۰ دقیقهای نشان میدهد «لایهٔ معنایی» چگونه با تعریف متمرکزِ متریکها و ابعاد در YAML، محاسبات KPI را در همه ابزارها یکسان میکند. در یک دمو عملی، با استفاده از Boring Semantic Layer و موتور DuckDB/Ibis، همان متریکها از طریق Python و Streamlit بدون دوبارهنویسی منطق، نتایج یکسان تولید میکنند. نگهداری تعریفها در YAML (همراه با نسخهبندی و تست) به حکمرانی بهتر، قابلیت بازتولید و جابهجایی ساده بین موتورهای اجرایی کمک میکند. در سطح اکوسیستم، ابزارهایی مانند dbt SL، Malloy و استاندارد OSI از Snowflake همکنشپذیری را پیش میبرند و به سمت یک قرارداد مشترک برای متریکها حرکت میکنند.
#SemanticLayer #DataEngineering #AnalyticsEngineering #DuckDB #Ibis #dbt #Malloy #Snowflake
🟣لینک مقاله:
https://rasmusengelbrecht.substack.com/p/practical-guide-to-semantic-layers?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Practical Guide to Semantic Layers: From Definition to Demo (10 minute read)
🟢 خلاصه مقاله:
این راهنمای ۱۰ دقیقهای نشان میدهد «لایهٔ معنایی» چگونه با تعریف متمرکزِ متریکها و ابعاد در YAML، محاسبات KPI را در همه ابزارها یکسان میکند. در یک دمو عملی، با استفاده از Boring Semantic Layer و موتور DuckDB/Ibis، همان متریکها از طریق Python و Streamlit بدون دوبارهنویسی منطق، نتایج یکسان تولید میکنند. نگهداری تعریفها در YAML (همراه با نسخهبندی و تست) به حکمرانی بهتر، قابلیت بازتولید و جابهجایی ساده بین موتورهای اجرایی کمک میکند. در سطح اکوسیستم، ابزارهایی مانند dbt SL، Malloy و استاندارد OSI از Snowflake همکنشپذیری را پیش میبرند و به سمت یک قرارداد مشترک برای متریکها حرکت میکنند.
#SemanticLayer #DataEngineering #AnalyticsEngineering #DuckDB #Ibis #dbt #Malloy #Snowflake
🟣لینک مقاله:
https://rasmusengelbrecht.substack.com/p/practical-guide-to-semantic-layers?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Substack
Practical Guide to Semantic Layers: From Definition to Demo (Part 1)
An introduction to semantic layers with a hands-on demo using the boring-semantic-layer library and a Streamlit app.
🔵 عنوان مقاله
The Feature We Were Afraid to Talk About (7 minute read)
🟢 خلاصه مقاله:
dltHub با صراحت توضیح میدهد که اتکای کامل به LLM برای ساخت خودکار data scaffold از روی مستندات، در عمل برای محیطهای تولیدی قابل اعتماد نبود. نسخه اول، اسکَفولدها را مستقیم با LLM میساخت و در ظاهر عالی بود، اما خطاهای ظریف و «توهمات» باعث شکست پایپلاینها و اتلاف زمان دیباگ میشد. در v2 رویکرد برعکس شد: ابتدا با پارسرها و اعتبارسنجهای قطعی، حقایق قابل راستیآزمایی (مثل endpointها، schemaها، روشهای احراز هویت و قواعد pagination) استخراج و تثبیت میشوند؛ سپس LLM فقط برای ظرایف معنایی وارد میشود—برای رفع ابهامها، نامگذاری بهتر یا پیشنهاد تبدیلهای سبک—آن هم با ارجاع شفاف به منبع تا قابلیت رهگیری و اصلاح حفظ شود. نتیجه، کاهش خطا و افزایش قابلیت بازتولید و دیباگپذیری است؛ LLM ارزش افزوده میدهد اما موتور تصمیم قطعی نیست. درس کلیدی: در دادههای تولیدی، باید LLM را با ریلهای ایمنی، استخراج قطعی و اعتبارسنجی احاطه کرد، نه اینکه همه چیز را به آن سپرد.
#LLM #DataEngineering #MLOps #AI #ProductionReliability #DeterministicParsing #DataPipelines #dltHub
🟣لینک مقاله:
https://dlthub.com/blog/improving_generation_baseline?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
The Feature We Were Afraid to Talk About (7 minute read)
🟢 خلاصه مقاله:
dltHub با صراحت توضیح میدهد که اتکای کامل به LLM برای ساخت خودکار data scaffold از روی مستندات، در عمل برای محیطهای تولیدی قابل اعتماد نبود. نسخه اول، اسکَفولدها را مستقیم با LLM میساخت و در ظاهر عالی بود، اما خطاهای ظریف و «توهمات» باعث شکست پایپلاینها و اتلاف زمان دیباگ میشد. در v2 رویکرد برعکس شد: ابتدا با پارسرها و اعتبارسنجهای قطعی، حقایق قابل راستیآزمایی (مثل endpointها، schemaها، روشهای احراز هویت و قواعد pagination) استخراج و تثبیت میشوند؛ سپس LLM فقط برای ظرایف معنایی وارد میشود—برای رفع ابهامها، نامگذاری بهتر یا پیشنهاد تبدیلهای سبک—آن هم با ارجاع شفاف به منبع تا قابلیت رهگیری و اصلاح حفظ شود. نتیجه، کاهش خطا و افزایش قابلیت بازتولید و دیباگپذیری است؛ LLM ارزش افزوده میدهد اما موتور تصمیم قطعی نیست. درس کلیدی: در دادههای تولیدی، باید LLM را با ریلهای ایمنی، استخراج قطعی و اعتبارسنجی احاطه کرد، نه اینکه همه چیز را به آن سپرد.
#LLM #DataEngineering #MLOps #AI #ProductionReliability #DeterministicParsing #DataPipelines #dltHub
🟣لینک مقاله:
https://dlthub.com/blog/improving_generation_baseline?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Dlthub
The feature we were afraid to talk about
This is the story of how we made our LLM generation workflow superior to starting from raw docs.
🔵 عنوان مقاله
pg_ivm 1.13: Incremental View Maintenance (IVM) Extension
🟢 خلاصه مقاله:
pg_ivm 1.13 یک افزونه برای PostgreSQL است که رویکرد Incremental View Maintenance (IVM) را به کار میگیرد تا بهجای بازمحاسبه کامل، فقط تغییرات لازم را روی materialized view اعمال کند. در مقایسه با REFRESH MATERIALIZED VIEW، این روش با بهروزرسانیهای افزایشی باعث کاهش زمان، مصرف منابع و قفلگذاری میشود و بهویژه برای پایگاههای داده حجیم، داشبوردهای تحلیلی و سناریوهای نزدیک به زمان واقعی مفید است.
#PostgreSQL #pg_ivm #IVM #MaterializedViews #DatabasePerformance #DataEngineering #IncrementalUpdates
🟣لینک مقاله:
https://postgresweekly.com/link/176027/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
pg_ivm 1.13: Incremental View Maintenance (IVM) Extension
🟢 خلاصه مقاله:
pg_ivm 1.13 یک افزونه برای PostgreSQL است که رویکرد Incremental View Maintenance (IVM) را به کار میگیرد تا بهجای بازمحاسبه کامل، فقط تغییرات لازم را روی materialized view اعمال کند. در مقایسه با REFRESH MATERIALIZED VIEW، این روش با بهروزرسانیهای افزایشی باعث کاهش زمان، مصرف منابع و قفلگذاری میشود و بهویژه برای پایگاههای داده حجیم، داشبوردهای تحلیلی و سناریوهای نزدیک به زمان واقعی مفید است.
#PostgreSQL #pg_ivm #IVM #MaterializedViews #DatabasePerformance #DataEngineering #IncrementalUpdates
🟣لینک مقاله:
https://postgresweekly.com/link/176027/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
GitHub
Release pg_ivm 1.13 (2025-10-20) · sraoss/pg_ivm
What's Changed
New feature
Add support for outer joins (#48) by @yugo-n in #149
Views that include outer joins are now supported, under the following restrictions:
The target list of an oute...
New feature
Add support for outer joins (#48) by @yugo-n in #149
Views that include outer joins are now supported, under the following restrictions:
The target list of an oute...
🔵 عنوان مقاله
Exploring Postgres to Parquet Archival for JSON Data with S3 Range Reads
🟢 خلاصه مقاله:
این مقاله یک الگوی بایگانی داده ارائه میکند: انتقال رکوردهای سرد JSON از Postgres به فایلهای Parquet روی S3 برای کاهش هزینه و فشار عملیاتی، در حالیکه امکان بازیابی سریع حفظ میشود. دادهها با کلیدهایی مثل tenant_id و تاریخ پارتیشنبندی میشوند، با ابزارهایی مانند pyarrow یا Spark به Parquet (با فشردهسازی Snappy/ZSTD و اندازه row group مناسب) تبدیل میگردند و در S3 با مسیرهای قابل پیشبینی ذخیره میشوند. برای بازیابی تند، با تکیه بر S3 Range Reads و متادیتای footer در Parquet فقط row groupها و column chunkهای لازم خوانده میشود؛ اگر lookup کلیدی بسیار سریع نیاز باشد، کنار هر فایل Parquet یک index کوچک نگهداری میشود که id را به بایترنچهای لازم نگاشت میکند. مسیر بازگردانی میتواند رکوردهای انتخابی را به Postgres برگرداند یا مستقیماً از S3 سرویس دهد؛ و موضوعاتی مانند رمزنگاری، نسخهبندی، lifecycle، و سنجش هزینه/کارایی نیز پوشش داده شده است.
#Postgres #Parquet #S3 #JSON #RangeReads #DataArchival #DataEngineering #AWS
🟣لینک مقاله:
https://postgresweekly.com/link/175387/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Exploring Postgres to Parquet Archival for JSON Data with S3 Range Reads
🟢 خلاصه مقاله:
این مقاله یک الگوی بایگانی داده ارائه میکند: انتقال رکوردهای سرد JSON از Postgres به فایلهای Parquet روی S3 برای کاهش هزینه و فشار عملیاتی، در حالیکه امکان بازیابی سریع حفظ میشود. دادهها با کلیدهایی مثل tenant_id و تاریخ پارتیشنبندی میشوند، با ابزارهایی مانند pyarrow یا Spark به Parquet (با فشردهسازی Snappy/ZSTD و اندازه row group مناسب) تبدیل میگردند و در S3 با مسیرهای قابل پیشبینی ذخیره میشوند. برای بازیابی تند، با تکیه بر S3 Range Reads و متادیتای footer در Parquet فقط row groupها و column chunkهای لازم خوانده میشود؛ اگر lookup کلیدی بسیار سریع نیاز باشد، کنار هر فایل Parquet یک index کوچک نگهداری میشود که id را به بایترنچهای لازم نگاشت میکند. مسیر بازگردانی میتواند رکوردهای انتخابی را به Postgres برگرداند یا مستقیماً از S3 سرویس دهد؛ و موضوعاتی مانند رمزنگاری، نسخهبندی، lifecycle، و سنجش هزینه/کارایی نیز پوشش داده شده است.
#Postgres #Parquet #S3 #JSON #RangeReads #DataArchival #DataEngineering #AWS
🟣لینک مقاله:
https://postgresweekly.com/link/175387/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Shayon Mukherjee
Exploring PostgreSQL to Parquet archival for JSON data with S3 range reads
Moving large JSON payloads from PostgreSQL TOAST tables to Parquet on S3 with deterministic sharding, row-group pruning, and range-based reads for millisecond point lookups.
❤1
🔵 عنوان مقاله
pg_timetable 6.1 Released: Advanced Job Scheduling Extension
🟢 خلاصه مقاله:
نسخه 6.1 از pg_timetable منتشر شد؛ یک افزونه مستقل و پخته برای زمانبندی کارها که کاملاً داخل پایگاه داده اجرا میشود. این ابزار اجازه میدهد در خود Postgres، فرمانها و کوئریها، برنامههای سیستمی و عملیات داخلی را زمانبندی کنید و وظایف را بهصورت زنجیرهای به هم متصل کنید تا گردشکارهای چندمرحلهای بسازید. اجرای زمانبندی داخل پایگاه داده، استقرار را ساده میکند، با سیاستهای دسترسی و پشتیبانگیری هماهنگ است و برای نگهداری دورهای، ETL، گزارشگیری، کنترل کیفیت داده و پشتیبان/خروجی گرفتن بسیار مناسب است. نسخه جدید بر بلوغ و آمادگی تولیدی این راهکار تأکید دارد و گزینهای عملی برای خودکارسازی مبتنی بر پایگاه داده بدون نیاز به سرویسهای خارجی اضافی ارائه میکند.
#pg_timetable #Postgres #JobScheduler #DatabaseAutomation #ETL #DevOps #OpenSource #DataEngineering
🟣لینک مقاله:
https://postgresweekly.com/link/176688/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
pg_timetable 6.1 Released: Advanced Job Scheduling Extension
🟢 خلاصه مقاله:
نسخه 6.1 از pg_timetable منتشر شد؛ یک افزونه مستقل و پخته برای زمانبندی کارها که کاملاً داخل پایگاه داده اجرا میشود. این ابزار اجازه میدهد در خود Postgres، فرمانها و کوئریها، برنامههای سیستمی و عملیات داخلی را زمانبندی کنید و وظایف را بهصورت زنجیرهای به هم متصل کنید تا گردشکارهای چندمرحلهای بسازید. اجرای زمانبندی داخل پایگاه داده، استقرار را ساده میکند، با سیاستهای دسترسی و پشتیبانگیری هماهنگ است و برای نگهداری دورهای، ETL، گزارشگیری، کنترل کیفیت داده و پشتیبان/خروجی گرفتن بسیار مناسب است. نسخه جدید بر بلوغ و آمادگی تولیدی این راهکار تأکید دارد و گزینهای عملی برای خودکارسازی مبتنی بر پایگاه داده بدون نیاز به سرویسهای خارجی اضافی ارائه میکند.
#pg_timetable #Postgres #JobScheduler #DatabaseAutomation #ETL #DevOps #OpenSource #DataEngineering
🟣لینک مقاله:
https://postgresweekly.com/link/176688/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
GitHub
GitHub - cybertec-postgresql/pg_timetable: pg_timetable: Advanced scheduling for PostgreSQL
pg_timetable: Advanced scheduling for PostgreSQL. Contribute to cybertec-postgresql/pg_timetable development by creating an account on GitHub.
🔵 عنوان مقاله
How Would You Like Your Iceberg Sir? Stream or Batch Ordered? (9 minute read)
🟢 خلاصه مقاله:
این مقاله توضیح میدهد که در جدولهای Iceberg، چیدمان Stream-order با حفظ ترتیب ورود داده برای پردازش ترتیبی و راهاندازی سریع جریانها مناسب است، در حالیکه چیدمان Batch-order با خوشهبندی دادهها کارایی پرسوجوهای تحلیلی را بهینه میکند. تلاش برای پشتیبانی همزمان هر دو نیاز در یک جدول، به سربار محاسباتی پنهان منجر میشود؛ بهویژه هنگام راهاندازی jobهای جریانی از دادههای Batch-order که مستلزم مرتبسازی و shuffling پرهزینه است. نتیجه این است که صرفهجویی ظاهری در فضای ذخیرهسازی با افزایش هزینههای محاسباتی از بین میرود. راهکار پیشنهادی، Confluent Tableflow است که دادههای جریانی را در Iceberg مادیسازی میکند و با نگهداشتن نمای مناسب برای هر سناریو، انعطافپذیری و کارایی بهتری ارائه میدهد—even اگر به معنای تقریباً دو برابر شدن فضای ذخیرهسازی باشد.
#ApacheIceberg #Streaming #BatchProcessing #DataEngineering #Confluent #Tableflow #DataLake #Lakehouse
🟣لینک مقاله:
https://jack-vanlightly.com/blog/2025/11/5/how-would-you-like-your-iceberg-sir-stream-or-batch-ordered?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
How Would You Like Your Iceberg Sir? Stream or Batch Ordered? (9 minute read)
🟢 خلاصه مقاله:
این مقاله توضیح میدهد که در جدولهای Iceberg، چیدمان Stream-order با حفظ ترتیب ورود داده برای پردازش ترتیبی و راهاندازی سریع جریانها مناسب است، در حالیکه چیدمان Batch-order با خوشهبندی دادهها کارایی پرسوجوهای تحلیلی را بهینه میکند. تلاش برای پشتیبانی همزمان هر دو نیاز در یک جدول، به سربار محاسباتی پنهان منجر میشود؛ بهویژه هنگام راهاندازی jobهای جریانی از دادههای Batch-order که مستلزم مرتبسازی و shuffling پرهزینه است. نتیجه این است که صرفهجویی ظاهری در فضای ذخیرهسازی با افزایش هزینههای محاسباتی از بین میرود. راهکار پیشنهادی، Confluent Tableflow است که دادههای جریانی را در Iceberg مادیسازی میکند و با نگهداشتن نمای مناسب برای هر سناریو، انعطافپذیری و کارایی بهتری ارائه میدهد—even اگر به معنای تقریباً دو برابر شدن فضای ذخیرهسازی باشد.
#ApacheIceberg #Streaming #BatchProcessing #DataEngineering #Confluent #Tableflow #DataLake #Lakehouse
🟣لینک مقاله:
https://jack-vanlightly.com/blog/2025/11/5/how-would-you-like-your-iceberg-sir-stream-or-batch-ordered?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Jack Vanlightly
How Would You Like Your Iceberg Sir? Stream or Batch Ordered? — Jack Vanlightly
Today I want to talk about stream analytics, batch analytics and Apache Iceberg. Stream and batch analytics work differently but both can be built on top of Iceberg, but due to their differences there can be a tug-of-war over the Iceberg table itself. In…
🔵 عنوان مقاله
ClickPipes for Postgres now supports failover replication slots.
🟢 خلاصه مقاله:
** این بهروزرسانی اعلام میکند که ClickPipes for Postgres اکنون از failover replication slots پشتیبانی میکند؛ قابلیتی که در محیطهای با قابلیت دسترسپذیری بالا باعث تداوم جریان داده هنگام جابهجایی از primary به standby میشود. با حفظ موقعیت اسلات در زمان failover، مصرفکنندگان CDC میتوانند بیوقفه روی primary جدید ادامه دهند، بدون از دستدادن داده یا رشد غیرقابلکنترل WAL. این تغییر ریسک عملیاتی را کم میکند، پیادهسازی HA را سادهتر میسازد و برای تیمهای Go که روی Postgres سرویسهای داده میسازند—طبق پوشش آخرین شماره Golang Weekly—خبر مهمی است.
#Postgres #Replication #Failover #ClickPipes #Golang #CDC #HighAvailability #DataEngineering
🟣لینک مقاله:
https://postgresweekly.com/link/176987/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
ClickPipes for Postgres now supports failover replication slots.
🟢 خلاصه مقاله:
** این بهروزرسانی اعلام میکند که ClickPipes for Postgres اکنون از failover replication slots پشتیبانی میکند؛ قابلیتی که در محیطهای با قابلیت دسترسپذیری بالا باعث تداوم جریان داده هنگام جابهجایی از primary به standby میشود. با حفظ موقعیت اسلات در زمان failover، مصرفکنندگان CDC میتوانند بیوقفه روی primary جدید ادامه دهند، بدون از دستدادن داده یا رشد غیرقابلکنترل WAL. این تغییر ریسک عملیاتی را کم میکند، پیادهسازی HA را سادهتر میسازد و برای تیمهای Go که روی Postgres سرویسهای داده میسازند—طبق پوشش آخرین شماره Golang Weekly—خبر مهمی است.
#Postgres #Replication #Failover #ClickPipes #Golang #CDC #HighAvailability #DataEngineering
🟣لینک مقاله:
https://postgresweekly.com/link/176987/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
ClickHouse
ClickPipes for Postgres now supports failover replication slots
Learn about how failover-ready replication slots keep Postgres CDC pipelines running without interruption.
🔵 عنوان مقاله
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
🔵 عنوان مقاله
All You Can Do Before Airflow (5 minute read)
🟢 خلاصه مقاله:
سادهترین روش ارکستریشن را شروع کنید و فقط وقتی رشد واقعی پیچیدگی آن را توجیه کرد به Airflow مهاجرت کنید. برای بسیاری از نیازها، ترکیبی از cron، اسکریپتهای Bash یا Python، یک Makefile، کانتینرسازی با Docker Compose و زمانبندیهای مدیریتشده مثل Cloud Scheduler یا EventBridge بههمراه logging، retry و alert کفایت میکند. نشانههای نیاز به Airflow زمانی ظاهر میشوند که وابستگیها و DAGها پیچیده میشوند، backfill و SLA اهمیت پیدا میکند، مالکیت بین تیمها توزیع میشود و به observability، lineage، RBAC و مدیریت secrets نیاز دارید. قبل از مهاجرت، کارها را idempotent و کوچک کنید، state را در دیتابیس/شیءاستور نگه دارید، تنظیمات را در کد مدیریت کنید، تست و مستندسازی و پایش را جدی بگیرید. قاعده تصمیم این است: سادهترین ابزار کافی امروز را انتخاب کنید و فقط وقتی درد واقعی تجربه کردید به Airflow ارتقا دهید.
#DataOrchestration #ApacheAirflow #DataPipelines #ETL #DataEngineering #Scalability #CronJobs #Observability
🟣لینک مقاله:
https://dataengineeringcentral.substack.com/p/all-you-can-do-before-airflow?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
All You Can Do Before Airflow (5 minute read)
🟢 خلاصه مقاله:
سادهترین روش ارکستریشن را شروع کنید و فقط وقتی رشد واقعی پیچیدگی آن را توجیه کرد به Airflow مهاجرت کنید. برای بسیاری از نیازها، ترکیبی از cron، اسکریپتهای Bash یا Python، یک Makefile، کانتینرسازی با Docker Compose و زمانبندیهای مدیریتشده مثل Cloud Scheduler یا EventBridge بههمراه logging، retry و alert کفایت میکند. نشانههای نیاز به Airflow زمانی ظاهر میشوند که وابستگیها و DAGها پیچیده میشوند، backfill و SLA اهمیت پیدا میکند، مالکیت بین تیمها توزیع میشود و به observability، lineage، RBAC و مدیریت secrets نیاز دارید. قبل از مهاجرت، کارها را idempotent و کوچک کنید، state را در دیتابیس/شیءاستور نگه دارید، تنظیمات را در کد مدیریت کنید، تست و مستندسازی و پایش را جدی بگیرید. قاعده تصمیم این است: سادهترین ابزار کافی امروز را انتخاب کنید و فقط وقتی درد واقعی تجربه کردید به Airflow ارتقا دهید.
#DataOrchestration #ApacheAirflow #DataPipelines #ETL #DataEngineering #Scalability #CronJobs #Observability
🟣لینک مقاله:
https://dataengineeringcentral.substack.com/p/all-you-can-do-before-airflow?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Substack
All You Can Do Before Airflow:
4 Orchestration Levels From Cron to Full Pipelines
🔵 عنوان مقاله
From Text to Token: How Tokenization Pipelines Work
🟢 خلاصه مقاله:
** این مطلب در دو بخش به نکات کاربردی میپردازد. در بخش اول، «From Text to Token: How Tokenization Pipelines Work» به قلم James Blackwood-Sewell توضیح میدهد که چگونه متن خام طی مراحلی مانند نرمالسازی، پیشتوکنیزهکردن و بهکارگیری الگوریتمهای زیرواژهای مثل BPE، WordPiece و Unigram به توکن تبدیل میشود. نکاتی مانند ساخت واژگان، استفاده از توکنهای ویژه (PAD، BOS/EOS، CLS/SEP)، مدیریت نویسههای ناشناخته، حفظ آفستها، و چالشهای چندزبانه و ایموجیها مطرح میشود. همچنین بر ملاحظات مهندسی مانند تکهتکهکردن متنهای بلند، اسلایدینگ ویندو، تفاوت نیازهای آموزش و استنتاج، و بهینهسازی عملکرد با ابزارهایی مانند Hugging Face Tokenizers و SentencePiece تأکید میشود؛ چرا که تعداد توکنها مستقیماً بر هزینه و تأخیر سامانههای LLM اثر میگذارد.
در بخش دوم، «Understanding and Setting Postgres JDBC Fetch Size» نوشته Shane Borden توضیح میدهد که رفتار پیشفرض Postgres JDBC ممکن است برای نتایج بزرگ حافظه را پر کند و چگونه با فعالکردن سرور-ساید کرسرها و تنظیم setFetchSize (یا defaultRowFetchSize) میتوان نتایج را بهصورت batched و استریمشده دریافت کرد. به ارتباط این تنظیم با autocommit، بازههای پیشنهادی برای اندازه batch، موازنه بین تعداد رفتوبرگشت شبکه و مصرف حافظه، و نکات عملی مانند بستن بهموقع ResultSet/Statement و هماهنگی با تنظیمات ORM (مثلاً hibernate.jdbc.fetch_size) پرداخته میشود. جمعبندی این است که کنار بهینهسازی fetch size، طراحی کوئری و ایندکس مناسب و پروفایلکردن حافظه و زمان، برای پایایی و کارایی ضروری است.
#Tokenization #NLP #Postgres #JDBC #PerformanceTuning #DataEngineering #LLM #Database
🟣لینک مقاله:
https://postgresweekly.com/link/175726/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
From Text to Token: How Tokenization Pipelines Work
🟢 خلاصه مقاله:
** این مطلب در دو بخش به نکات کاربردی میپردازد. در بخش اول، «From Text to Token: How Tokenization Pipelines Work» به قلم James Blackwood-Sewell توضیح میدهد که چگونه متن خام طی مراحلی مانند نرمالسازی، پیشتوکنیزهکردن و بهکارگیری الگوریتمهای زیرواژهای مثل BPE، WordPiece و Unigram به توکن تبدیل میشود. نکاتی مانند ساخت واژگان، استفاده از توکنهای ویژه (PAD، BOS/EOS، CLS/SEP)، مدیریت نویسههای ناشناخته، حفظ آفستها، و چالشهای چندزبانه و ایموجیها مطرح میشود. همچنین بر ملاحظات مهندسی مانند تکهتکهکردن متنهای بلند، اسلایدینگ ویندو، تفاوت نیازهای آموزش و استنتاج، و بهینهسازی عملکرد با ابزارهایی مانند Hugging Face Tokenizers و SentencePiece تأکید میشود؛ چرا که تعداد توکنها مستقیماً بر هزینه و تأخیر سامانههای LLM اثر میگذارد.
در بخش دوم، «Understanding and Setting Postgres JDBC Fetch Size» نوشته Shane Borden توضیح میدهد که رفتار پیشفرض Postgres JDBC ممکن است برای نتایج بزرگ حافظه را پر کند و چگونه با فعالکردن سرور-ساید کرسرها و تنظیم setFetchSize (یا defaultRowFetchSize) میتوان نتایج را بهصورت batched و استریمشده دریافت کرد. به ارتباط این تنظیم با autocommit، بازههای پیشنهادی برای اندازه batch، موازنه بین تعداد رفتوبرگشت شبکه و مصرف حافظه، و نکات عملی مانند بستن بهموقع ResultSet/Statement و هماهنگی با تنظیمات ORM (مثلاً hibernate.jdbc.fetch_size) پرداخته میشود. جمعبندی این است که کنار بهینهسازی fetch size، طراحی کوئری و ایندکس مناسب و پروفایلکردن حافظه و زمان، برای پایایی و کارایی ضروری است.
#Tokenization #NLP #Postgres #JDBC #PerformanceTuning #DataEngineering #LLM #Database
🟣لینک مقاله:
https://postgresweekly.com/link/175726/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Paradedb
From Text to Token: How Tokenization Pipelines Work
Understanding how search engines transform text into tokens through character filtering, tokenization, stemming, and stopword removal.