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