🔵 عنوان مقاله
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.