نوروز ۱۴۰۴ مبارک! 🌸🌿

امیدوارم امسال برای همه‌ی ما سالی بهتر از سال‌های گذشته باشد. سالی که کمی از استرس‌های زندگی، مخصوصاً در ایران، فاصله بگیریم و لحظات آرام‌تری را تجربه کنیم. 🌱

یکی از فصلنامه‌هایی که مدتی است مشترک آن هستم و همیشه با اشتیاق می‌خوانم، ترجمان است که شامل ترجمه‌ی مقالات عمیق و تحلیلی از منابع معتبر خارجی در حوزه علوم انسانی و مباحث فکری و فرهنگی است.

شماره‌ی جدید آن با عنوان «دیگر چیزی برای تماشا نمانده است» منتشر شده و این بار به بحران‌های محیط‌زیستی و اقلیمی پرداخته است. 📖🌍

آدرس وب سایت ترجمان : https://tarjomaan.com

اگر در این روزهای زیبای بهاری، عازم سفر و طبیعت‌گردی هستید، ردپای حضورتان را تنها در خاطره‌ها بگذارید، نه بر تن خسته‌ی زمین… مبادا که ترک بردارد آغوش سبز طبیعت. 🍃✨

نوروزتان سبز، دلتان آرام و سالتان پر از مهر و معنا. 🌸💙
معمولاً سعی می‌کنم چیزهایی را منتشر کنم که مفید باشد و وقتتان را نگیرد اما وقتی به اوضاع محیط‌زیست نگاه می‌کنم، می‌ترسم که این عنوان، نه یک هشدار، که یک واقعیتِ آینده‌ی نزدیک باشد… خواستم این دغدغه را هم با شما در میان بگذارم. 🍂💭

‍ چگونه پی‌پال با ۸ ماشین مجازی، روزانه ۱.۲ میلیارد تراکنش را پردازش می‌کند؟🚀
✅ با کاهش ۹۰٪ هزینه نسبت به ۱۰۰۰ ماشین مجازی؟
در این نوشتار به صورت مختصر این معماری فوق‌العاده را با هم بررسی می‌کنیم
1️⃣ پی‌پال چگونه مسیر خود را پیدا کرد؟
پی‌پال در سال ۱۹۹۸ به‌عنوان یک شرکت امنیتی شروع به کار کرد، اما مدل کسب‌وکار اولیه‌اش موفق نبود. پس از یک تغییر استراتژیک (پیوت)، به سرویس پرداخت آنلاین تبدیل شد و نام PayPal را برگزید.
با افزایش سریع کاربران، نیاز به سخت‌افزار قدرتمندتر احساس شد، اما این تنها آغاز چالش‌های مقیاس‌پذیری بود.
2️⃣ رشد نمایی و محدودیت‌های سخت‌افزاری
در کمتر از دو سال، پی‌پال به بیش از ۱ میلیون تراکنش روزانه رسید. اما قانون مور (Moore’s Law) که پیش‌بینی می‌کرد هر دو سال تعداد ترانزیستورها دو برابر شود، به کندی گرایید.
افزایش عملکرد پردازنده‌های سینگل‌ترد متوقف شد، و صرفاً ارتقای سخت‌افزار دیگر پاسخگوی نیاز نبود.
3️⃣ راه‌حل اولیه: مقیاس‌پذیری افقی (Horizontal Scaling)
پی‌پال برای حل این مشکل، سرویس‌های خود را روی بیش از ۱۰۰۰ ماشین مجازی اجرا کرد. این کار مشکل را موقتاً حل کرد، اما چالش‌های جدیدی به وجود آمد:
🔸 افزایش لتنسی شبکه
🔸 هزینه‌های زیرساختی بالا
🔸 پیچیدگی مدیریت سیستم‌ها
🔸 مصرف ناکارآمد منابع (CPU کم‌بار)
4️⃣ راه‌حل نهایی: مدل اکتور (Actor Model)
پی‌پال به دنبال سیستمی ساده، مقیاس‌پذیر و کم‌هزینه بود. در نهایت، معماری خود را بر پایه مدل اکتور طراحی کرد و به فریم‌ورک Akka (یک ابزار قوی بر پایه JVM و Java) مهاجرت کرد.
🔹 مدل اکتور چیست؟

اکتورها واحدهای فوق‌سبک پردازشی هستند که به‌جای استفاده از تردها، از پیام‌های غیرقابل‌تغییر (Immutable Messages) برای ارتباط استفاده می‌کنند.
این تغییر به پی‌پال اجازه داد میلیون‌ها اکتور را در سیستم مدیریت کند و به سطح جدیدی از کارایی دست یابد.

5️⃣ مزایای مدل اکتور برای پی‌پال
✅ استفاده بهینه از منابع
اکتورها فقط در لحظه پردازش پیام یک ترد دریافت می‌کنند. تعداد تردها محدود به تعداد هسته‌های CPU است، و با Dynamic Thread Pooling هزاران اکتور به‌طور همزمان اجرا می‌شوند.
✅ مدیریت بهینه State
اکتورها ایزوله و بدون حافظه مشترک هستند. هر اکتور یک Mailbox دارد که پیام‌ها را به‌صورت FIFO ذخیره می‌کند.
این معماری نیاز به کش‌های توزیع‌شده یا دیتابیس اضافی را کاهش داده و با ذخیره‌سازی محلی، لتنسی را به حداقل می‌رساند.
✅ کانکارنسی بالا بدون بلاک شدن
هر اکتور پیام‌های خود را به‌صورت ترتیبی پردازش می‌کند، اما چندین اکتور می‌توانند همزمان و غیرهمزمان اجرا شوند.
این معماری از بلاک شدن پردازش‌ها جلوگیری می‌کند و با استفاده از برنامه‌نویسی Functional، ساید افکت‌ها را حذف می‌کند.
🎯 نتیجه؟
با این تغییر معماری، پی‌پال توانست با فقط ۸ ماشین مجازی، روزانه ۱.۲ میلیارد تراکنش را پردازش کند، درحالی‌که هزینه‌های زیرساختی را ۹۰٪ کاهش داد!
مرجع :
https://newsletter.systemdesign.one/p/actor-model
آشنایی با مدل اکتور به زبان فارسی :
https://virgool.io/@sadeghhp/-tyizn4ij09v7

‍ تا چند سال پیش، اگر تغییرات یک پایگاه داده را می‌خواستید رصد کنید، احتمالاً یا مجبور بودید کلی کد سفارشی بنویسید، یا از روش‌های دست و پاگیری مثل پولینگ دوره‌ای استفاده کنید که هم کارایی پایینی داشت و نیازهای بلادرنگ را پیشتیبانی نمی‌کرد، هم ممکن بود تغییراتی را از دست بدهید. اما حالا در دنیای مهندسی داده، CDC یک مفهوم کاملا جاافتاده است!

📌 CDC (Change Data Capture) چیه؟

یک تکنیک هوشمند برای ردگیری تغییرات دیتابیس به‌صورت بلادرنگ است. یعنی هر اضافه، حذف یا ویرایش روی یک جدول دیتابیس، بلافاصله شناسایی شده و می‌تواند برای پردازش‌های بعدی ارسال شود. منظور از هوشمندی تکنیک هم این است که این روش با بررسی تغییرات لحظه‌ای فایل لاگ دیتابیس، بدون اینکه باراضافه ای به دیتابیس تحمیل کند، تغییرات انجام شده را استخراج و آنها را به مقاصدی مانند کافکا ارسال می‌کند.

🔹 بیایید چند مثال بزنیم که چرا CDC این‌قدر پرطرفدار شده:

✅ سرویس‌های پیامکی و ایمیلی
فرض کنید یک فروشگاه آنلاین دارید و می‌خواهید به محض ثبت‌نام کاربر جدید، یک ایمیل خوشامدگویی یا کد تخفیف برایش ارسال کنید. با CDC می‌توانید این تغییرات را شناسایی و به سیستم پیام‌رسانی خود ارسال کنید، بدون اینکه نیازی به تغییر در کدهای بک‌اند داشته باشید.

✅ به‌روزرسانی داشبوردهای تحلیلی
اگر یک دیتابیس فروش دارید و می‌خواهید هم‌زمان در یک انبار داده (Data Warehouse) مثل BigQuery یا ClickHouse هم اطلاعات را به‌روز کنید، CDC اجازه می‌دهد هر سفارش جدید را بلافاصله دریافت و پردازش کنید. (معمولا این تغییرات در کافکا یا یک پیام‌رسان واسط ذخیره میشوند و سپس دیتابیسی مانند کلیک‌هوس آنها را به صورت خودکار از آنها برمی دارد)

✅ مانیتورینگ تراکنش‌های بانکی
در سیستم‌های بانکی، لازم است هر تراکنش مشکوک بلافاصله بررسی شود. CDC این امکان را می‌دهد که تغییرات حساب‌ها را ردیابی کنید و به محض شناسایی فعالیت غیرعادی، به سرویس تحلیل تقلب ارسال کنید.

✅ سنکرون‌سازی دیتابیس‌ها
اگر یک اپلیکیشن دارید که از PostgreSQL استفاده می‌کند و حالا می‌خواهید یک نسخه از داده‌ها را در Elasticsearch هم داشته باشید (مثلاً برای جستجوی سریع‌تر)، CDC می‌تواند این داده‌ها را در لحظه همگام‌سازی کند.

🔥 چرا در سال‌های اخیر CDC این‌قدر محبوب شده؟

🔸 تا چند سال پیش، اگر می‌خواستید یک پردازش بلادرنگ روی تغییرات دیتابیس انجام دهید، گزینه‌های زیادی نداشتید. بیشتر شرکت‌ها مجبور بودند یا پولینگ مداوم انجام دهند (یعنی هر چند ثانیه یک‌بار دیتابیس را اسکن کنند) یا تغییرات را از طریق APIهای پیچیده مدیریت کنند.

🔸 اما حالا با رشد ابزارهایی مثل Debezium، Maxwell، و Estuary Flow، پیاده‌سازی CDC بسیار ساده‌تر و کارآمدتر شده است. شرکت‌های بزرگ مثل Netflix، Airbnb و Uber به‌شدت از CDC برای پردازش‌های بلادرنگ استفاده می‌کنند.

🔸 همچنین، با ظهور معماری‌های مدرن داده مثل Lakehouse، بسیاری از شرکت‌ها به دنبال انتقال داده‌ها از دیتابیس‌های عملیاتی به دیتابیس‌های تحلیلی در لحظه هستند. CDC دقیقاً همین کار را انجام می‌دهد!

بیایید ببینیم امروزه برای دریافت لحظه‌ای تغییرات پایگاه‌های داده مطرح دنیا چه گزینه‌هایی در دسترس داریم .

مدل‌های مختلف CDC
ابزارهای CDC با روش‌های مختلفی داده‌ها را رهگیری و منتقل می‌کنند. پنج مدل اصلی در این زمینه عبارت‌اند از:

🎯 CDC مبتنی بر لاگ (Log-based CDC)
📌 تغییرات را از لاگ تراکنش‌های دیتابیس استخراج می‌کند.
💡 ایده‌آل برای حجم‌های بالا بدون تأثیر بر عملکرد دیتابیس.
🎯 مناسب برای سازمان‌های بزرگ و محیط‌های Enterprise.

🎯 CDC مبتنی بر تریگر (Trigger-based CDC)
📌 از تریگرهای دیتابیس برای ثبت تغییرات استفاده می‌کند.
✅ امکان کنترل دقیق تغییرات.
⚠️ در محیط‌های پرتراکنش باعث کاهش کارایی دیتابیس می‌شود.

🎯 CDC مبتنی بر Query
📌 با اسکن دوره‌ای دیتابیس، تغییرات را شناسایی می‌کند.
✅ پیاده‌سازی ساده و بدون وابستگی به لاگ تراکنش.
⚠️ برای داده‌های حجیم، کارایی پایینی دارد.

🎯 CDC مبتنی بر Timestamp
📌 تغییرات را با بررسی زمان آخرین بروزرسانی رهگیری می‌کند.
✅ پیاده‌سازی آسان، اما ممکن است برخی تغییرات از دست بروند.

🎯 CDC ترکیبی (Hybrid CDC)
📌 ترکیبی از روش‌های بالا برای افزایش دقت و کارایی.
✅ انعطاف‌پذیر برای نیازهای خاص هر سازمان.

معرفی ابزارهای برتر CDC در سال ۲۰۲۵

در این بخش، هر ابزار CDC را به‌همراه دسته‌بندی آن توضیح می‌دهیم تا بدانید کدام ابزار برای نیاز شما مناسب‌تر است.

‍ 🌟 دبزیوم : Debezium 🔥 (پادشاه محبوب و سنگین‌وزن CDC)
📌 مدل CDC: مبتنی بر لاگ (Log-based CDC)
🎯 ویژگی‌ها:
✅ یک استاندارد صنعتی برای CDC، طراحی‌شده برای Kafka
✅ پشتیبانی از PostgreSQL, MySQL, SQL Server, Oracle, MongoDB
✅ قابلیت Snapshot اولیه و تبدیل پایگاه داده‌های قدیمی به بلادرنگ
⚠️ چالش: پیچیدگی در تنظیمات و نیازمند منابع بالا


🌟 راهکاری مدرن با پشتیبانی از NATS DBConvert Streams ⚡️
📌 مدل CDC: مبتنی بر لاگ (Log-based CDC)
🎯 ویژگی‌ها:
✅ سازگار با PostgreSQL و MySQL
✅ داده‌ها را به Kafka، NATS و سایر سیستم‌ها ارسال می‌کند
✅ سبکتر از Debezium
⚠️ چالش: تنوع دیتابیس‌های پشتیبانی‌شده کمتر از Debezium است

🌟 مکسول: Maxwell Daemon 🏃 (گزینه‌ای سبک برای MySQL)
📌 مدل CDC: مبتنی بر لاگ (Log-based CDC)
🎯 ویژگی‌ها:
✅ طراحی شده برای MySQL (فقط)
✅ سبک‌تر و ساده‌تر از Debezium
✅ خروجی JSON به Kafka، Redis، Kinesis و Google Pub/Sub
⚠️ چالش: پشتیبانی از دیتابیس‌های دیگر را ندارد


🌟 یک ابزار مبتنی بر تریگر : Sequin 🛡 (انتقال داده‌ها به APIها، بدون از دست دادن داده‌ها!)
📌 مدل CDC: مبتنی بر تریگر (Trigger-based CDC)
🎯 ویژگی‌ها:
✅ برای PostgreSQL طراحی شده است
✅ تحویل داده‌ها ۱۰۰٪ تضمین‌شده
✅ داده‌ها را به REST APIها و Webhooks ارسال می‌کند
⚠️ چالش: وابستگی به تریگرها که می‌تواند روی عملکرد دیتابیس تأثیر بگذارد


🌟 دیتالیک‌هوس : OLake 🌊 (پل CDC به دنیای Data Lakehouse!)
📌 مدل CDC: ترکیبی (Hybrid CDC)
🎯 ویژگی‌ها:
✅ طراحی‌شده برای Apache Iceberg و Data Lakehouse
✅ داده‌ها را مستقیم از پایگاه داده‌های رابطه‌ای به Lakehouse منتقل می‌کند
✅ عملکرد بهینه برای تحلیل داده‌های حجیم
⚠️ چالش: وابستگی زیاد به معماری Data Lakehouse


🌟ابزاری برای اتصال بلادرنگ Estuary Flow 🔄 (اتصال بلادرنگ دیتابیس‌ها به Data Warehouse!)
📌 مدل CDC: مبتنی بر لاگ (Log-based CDC)
🎯 ویژگی‌ها:
✅ انتقال Real-time داده‌ها از PostgreSQL, MySQL و SQL Server
✅ قابلیت همگام‌سازی با BigQuery، Snowflake، و Redshift
✅ دارای رابط کاربری ساده و بدون نیاز به مدیریت Kafka
⚠️ چالش: کمتر شناخته شده در مقایسه با ابزارهای جاافتاده


🌟 پریزما - ابزاری برای توسعه دهندگان Prisma Pulse 💡
📌 مدل CDC: مبتنی بر تریگر (Trigger-based CDC)
🎯 ویژگی‌ها:
✅ یک ابزار جدید از Prisma، مخصوص PostgreSQL
✅ ساده و سبک، بدون نیاز به Kafka
✅ مناسب برای اپلیکیشن‌های کوچک و متوسط
⚠️ چالش: برای مقیاس‌های بزرگ مناسب نیست


🌟 محصول نتفلیکس DBLog 🎬 (انتقال بلادرنگ داده‌ها در مقیاس Netflix!)
📌 مدل CDC: مبتنی بر لاگ (Log-based CDC)
🎯 ویژگی‌ها:
✅ توسعه‌یافته توسط Netflix برای PostgreSQL
✅ طراحی‌شده برای مقیاس‌های بزرگ و استریم داده با کارایی بالا
✅ بهینه برای تحلیل داده‌های کلان
⚠️ چالش: ابزار جدیدی است و هنوز به‌اندازه Debezium تست نشده است


🌟 ردپاندا کانکت - Redpanda Connect
📌 مدل CDC: مبتنی بر لاگ (Log-based CDC)
🎯 ویژگی‌ها:
✅ ارائه‌ی کانکتورهای قدرتمند برای پایگاه‌های داده محبوب مانند PostgreSQL، MySQL و MongoDB
✅ جایگزینی مقیاس‌پذیر و انعطاف‌پذیر برای Kafka Connect
✅ تسهیل در یکپارچه‌سازی سیستم‌های داده‌ی مختلف
✅ بسیار سریع و اکوسیستم رو به رشد و افزوده شدن سایر دیتابیس ها در آینده نزدیک
⚠️چالش‌: وابستگی به کافکا (ردپاندا)

🔥 جمع‌بندی و انتخاب ابزار مناسب

✅ اگر به Kafka نیاز دارید: Debezium، Maxwell Daemon یا DBConvert Streams
✅ اگر به BigQuery یا Snowflake نیاز دارید: Estuary Flow
✅ اگر به یک راهکار سبک برای PostgreSQL می‌خواهید: Prisma Pulse یا Sequin
✅ اگر داده‌ها را به Data Lakehouse ارسال می‌کنید: OLake
✅ اگر یک ابزار در سطح Netflix می‌خواهید: DBLog (Netflix) / RedPanda Connect

🔥 جمع‌بندی
امروزه، ابزارهای CDC به بخش مهمی از معماری داده مدرن تبدیل شده‌اند. با ظهور گزینه‌های جدید، کسب‌وکارها می‌توانند بسته به نیاز خود، بهترین ابزار را برای پردازش تغییرات بلادرنگ در پایگاه داده‌هایشان انتخاب کنند.

💡 در سال‌های اخیر، حرکت از Batch Processing به سمت Real-time Data Processing سرعت گرفته است. هر روز شرکت‌های بیشتری CDC را جایگزین روش‌های قدیمی برای انتقال داده می‌کنند.
Reference: https://asrathore08.medium.com/change-data-capture-tools-c0e4ee4434ac

Fundamentals of Data Engineering (Reis, JoeHousley, Matt) (Z-Library).pdf

‍ تا سال ۲۰۳۰، نزدیک به ۵۹٪ از نیروی کار جهانی نیازمند یادگیری مهارت‌های جدید خواهند بود—اما همه به این فرصت دسترسی نخواهند داشت!

این یکی از پیام‌های کلیدی گزارش تازه مجمع جهانی اقتصاد – آینده مشاغل ۲۰۲۵ است.

لینک آنلاین گزارش (که بسیار کامل و خواندنی است) :

https://www.weforum.org/publications/the-future-of-jobs-report-2025/in-full/introduction-the-global-labour-market-landscape-in-2025/


این گزارش که با تحلیل داده‌های بیش از ۱۰۰۰ شرکت، ۲۶ صنعت و ۱۴ میلیون کارگر تهیه شده، روندهای پیش روی بازار کار را بررسی می‌کند.

📌 نتیجه روشن است: هوش مصنوعی با سرعتی فراتر از پیش‌بینی‌ها، آینده مشاغل را دگرگون خواهد کرد.

🔹 آیا هوش مصنوعی، انقلاب صنعتی جدید است؟

شواهد نشان می‌دهند که در ۲ تا ۳ سال آینده، تأثیر هوش مصنوعی بر کسب‌وکارها و بازار کار، به‌اندازه تحول موتور بخار در قرن نوزدهم عمیق خواهد بود.

🏆 ۱۰ مهارت کلیدی برای سال ۲۰۳۰:

1️⃣ هوش مصنوعی و کلان‌داده

2️⃣ سواد دیجیتال

3️⃣ تفکر خلاقانه

4️⃣ انعطاف‌پذیری و چابکی

5️⃣ تحلیل‌گری و حل مسئله

6️⃣ رهبری و نفوذ اجتماعی

7️⃣ خودانگیختگی و شناخت فردی

8️⃣ تفکر سیستمی

9️⃣ مدیریت استعدادها

🔟 کنجکاوی و یادگیری مادام‌العمر

🚀 موضوع فقط یادگیری فناوری نیست—بلکه پرورش مهارت‌های انسانی مانند خلاقیت، انطباق‌پذیری و تفکر سیستمی است که ماشین‌ها قادر به تقلید آن نیستند.

📌 نکات کلیدی گزارش:

✅ تا سال ۲۰۳۰، ۱۷۰ میلیون شغل جدید ایجاد خواهد شد، اما ۹۲ میلیون شغل از بین می‌رود.

✅ ۳۹٪ از مهارت‌های کنونی دیگر کاربرد نخواهند داشت.

✅ هوش مصنوعی هم یک چالش جدی است و هم یک فرصت بی‌نظیر.

✅ فاکتورهای اصلی این تغییرات: پیشرفت فناوری، اهداف زیست‌محیطی، ESG و تحولات جمعیتی.

🔹 حقیقت این است که مهارت‌آموزی دیگر یک گزینه نیست—بلکه یک ضرورت است.

🔹 یا خود را برای آینده آماده می‌کنید، یا از قافله عقب خواهید ماند!

🛠 چگونه با این تغییرات همراه شویم؟

📌 همین امروز یادگیری هوش مصنوعی را آغاز کنید!

🔹 مفاهیم پایه را بیاموزید.

🔹 ابزارهای هوش مصنوعی را در حوزه کاری خود به کار ببرید.

🔹 یادگیری را متوقف نکنید—زیرا دنیای فناوری هر روز در حال تغییر است!

در این مسیر، کلان‌داده نقش کلیدی ایفا می‌کند. هوش مصنوعی برای یادگیری، بهینه‌سازی و تصمیم‌گیری نیازمند حجم عظیمی از داده‌های باکیفیت است. ابزارهای مرتبط با کلان‌داده، از پردازش لحظه‌ای گرفته تا تحلیل‌های پیشرفته، بنیان اصلی این تحول دیجیتال هستند.
بدون زیرساخت داده‌ای قوی، حتی پیشرفته‌ترین الگوریتم‌های هوش مصنوعی نیز نمی‌توانند به پتانسیل واقعی خود برسند! 🚀

پ.ن:

این متن ترجمه ای است از این پست در لینکدین : yun.ir/r1x9ef

کلیک‌هوس و خرید PeerDB 🚀: رفع محدودیت کوئری‌های سنگین تحلیلی بر روی پستگرس بدون درد و خونریزی

کلیک‌هوس با خرید PeerDB، گامی بزرگ در حوزه تحلیل داده‌های سازمانی برداشته است. PeerDB یک ابزار قدرتمند و ساده برای انتقال خودکار داده‌ها از PostgreSQL به پایگاه‌های داده تحلیلی و انبارهای داده است.
این ابزار، کار را برای شرکت‌ها و سازمان‌هایی که داده‌های اصلی‌شان روی پستگرس ذخیره می‌شود، بسیار آسان‌تر کرده است.
اکنون، آن‌ها می‌توانند به‌راحتی داده‌های خود را به کلیک‌هوس منتقل کرده و گزارش‌های سنگین تحلیلی خود را به‌جای پستگرس، روی کلیک‌هوس اجرا کنند.

🔹 ابزار PeerDB چه مزایایی دارد؟
✅ پشتیبانی از سه حالت مختلف استریمینگ داده‌ها:

Log-based (CDC)

Cursor-based (timestamp یا عدد صحیح)

XMIN-based
✅ ۱۰ برابر سریع‌تر از ابزارهای مشابه
✅ پشتیبانی از ویژگی‌های بومی پستگرس مانند:

انواع داده‌های پیچیده (jsonb، آرایه‌ها، داده‌های مکانی و...)

استریمینگ بهینه‌ی TOAST columns

پشتیبانی از تغییرات در ساختار جدول‌ها


🔗 آدرس گیت‌هاب PeerDB:
github.com/PeerDB-io/peerdb

عکس پست میزان رشد استفاده از PeerDB را نشان میدهد.

‍ معرفی Apache DataFusion: یک موتور SQL سریع، سبک و قدرتمند برای داده‌های حجیم

دیتافیوژن یکی از پروژه‌های جذاب بنیاد آپاچی در حوزه پردازش داده است که به شما اجازه می‌دهد بدون نیاز به پایگاه داده سنگین، یک موتور پردازش SQL سریع و کارآمد داشته باشید. چه بخواهید خودتان یک سیستم تحلیلی یا ابزار پردازش داده جدید توسعه دهید و برای بخش پردازش کوئری و فایل‌های خام داده نیاز به یک کتابخانه مناسب دارید که چرخ را دوباره اختراع نکنید و چه برای کاربردهای روزمره تحلیل داده به یک ابزار ساده و سریعتر از Pandas که با زبان Rust توسعه داده شده و پردازش درون حافظه ستونی (Arrow) استفاده کند، Data Fusion یک گزینه فوق العاده است.
اگر تجربه کار با DuckDB را دارید، DataFusion می‌تواند برای شما آشنا به نظر برسد —یک Query Engine سبک و مقیم در حافظه که می‌تواند درون برنامه‌های شما یا برای تحلیل سریع داده‌های حجیم استفاده شود.

🔥 چرا دیتافیوژن؟

✅ سرعت بالا و مصرف بهینه منابع → به لطف توسعه با زبان Rust و پردازش داده‌ها با فرمت ستونی و درون حافظه، به لطف Apache Arrow

✅ کاملاً سبک و انعطاف‌پذیر → مناسب برای تحلیل‌های بلادرنگ و پردازش داده در برنامه‌های کاربردی

✅ بدون نیاز به وابستگی‌های پیچیده → اجرا به‌صورت مستقل یا درون سرویس‌های دیگر


⚡️ بهینه‌سازی پردازش‌های Spark

اگر با Apache Spark کار می‌کنید، DataFusion می‌تواند عملکرد پردازش‌های شما را بهبود دهد و از Apache Arrow برای افزایش کارایی در پردازش‌های ستونی استفاده کند.

⚡️ اجرای SQL به‌صورت توزیع‌شده با Ray

DataFusion از Ray نیز پشتیبانی می‌کند، بنابراین می‌توانید داده‌های حجیم را به‌صورت توزیع‌شده پردازش کنید و از مزایای موازی‌سازی در سطح بالاتر بهره ببرید.

برخی از کاربردهای دیتافیوژن :

🔹 پایگاه‌های داده تحلیلی تخصصی مانند HoraeDB و سیستم‌های مشابه Apache Spark مانند Ballista ⚡️

🔹 موتورهای جدید برای زبان‌های پرس‌وجو مانند prql-query و شتاب‌دهنده‌هایی مثل VegaFusion 🚀

🔹 پلتفرم‌های تحقیقاتی برای سیستم‌های پایگاه داده جدید مانند Flock 🔬

🔹 افزودن پشتیبانی از SQL به کتابخانه‌های دیگر مانند dask-sql 📊

🔹 پلتفرم‌های پردازش داده‌های جریانی (Streaming) مانند Synnada 🌊

🔹 ابزارهای پردازش و تبدیل فرمت داده‌ها برای خواندن، مرتب‌سازی و تغییر فرمت Parquet, CSV, AVRO و JSON مانند qv 📂

🔹 جایگزین‌های بومی برای اجرای Spark مانند Blaze 🔥

📌 اگر به دنبال یک موتور پردازش SQL سبک، سریع و مقیاس‌پذیر هستید که هم روی سیستم شخصی و هم در محیط‌های توزیع‌شده به خوبی کار کند و یا اصلا قصد دارید یک سامانه پردازش دیتای جدیدی را توسعه دهید، برای بخش پردازش کوئری و یا خواندن فایلهای رایج داده با سرعت بالا Apache DataFusion را حتما بررسی کنید!

برای مشاهده لینک کامل محصولاتی که از دیتافیوژن استفاده می‌کنند به صفحه اصلی این پروژه در بنیاد آپاچی مراجعه کنید :
https://datafusion.apache.org/user-guide/introduction.html

عکس پست از مطلب زیر برداشته شده است :
https://medium.com/@asrathore08/apache-datafusion-modern-query-engine-for-performance-787c47679ee1

‍ رقابت بر سر خدمات سازمانی Apache Iceberg: چرا Table Services اهمیت دارند؟ 🚀

با گسترش استفاده از Apache Iceberg در زیرساخت‌های تحلیلی، بسیاری از سازمان‌ها داده‌های خام خود را (اغلب در قالب Parquet) ذخیره کرده و بدون نیاز به تبدیل یا پردازش اضافه، مستقیماً بر روی آن‌ها کوئری اجرا می‌کنند. این رویکرد Lakehouse باعث انعطاف‌پذیری بالا و کاهش هزینه‌های ذخیره‌سازی و پردازش شده است.

از طرفی با گسترش Apache Iceberg به‌عنوان استانداردی برای ذخیره‌سازی داده‌های تحلیلی، شرکت‌های بزرگ علاوه بر امکان ایجاد زیرساخت داده با این استاندارد، به سمت ارائه خدمات حرفه‌ای و سازمانی Iceberg هم حرکت کرده‌اند و رقابتی بزرگ در این حوزه در حال شکل‌گیری است.. موضوعی که امروزه از آن به Table Services یاد می‌کنیم.

خدمات جدول یا Table Services مجموعه‌ای از ابزارهای مدیریتی هستند که به سازمان‌ها کمک می‌کنند چالش‌های زیر را در مدیریت جداول داده در آیس‌برگ حل کنند:

✅ Optimization:
سازمان‌دهی و فشرده‌سازی فایل‌ها برای بهبود عملکرد کوئری‌ها و کاهش تعداد فایل‌های کوچک.
✅ Cleanup:
حذف نسخه‌های قدیمی و کنترل رشد متادیتا برای کاهش هزینه‌ها.
✅ Disaster Recovery:
امکان بازیابی داده‌ها در صورت خرابی‌های غیرمنتظره.
✅ Multi-table Rollback:
اجرای عملیات پیچیده با قابلیت بازگردانی تغییرات.
✅ Metadata Enrichment:
افزودن اطلاعات تکمیلی به داده‌های خام برای تحلیل‌های پیشرفته‌تر.

با افزایش اهمیت این خدمات، شرکت‌های مختلف در حال توسعه راهکارهای اختصاصی خود هستند، از جمله:

🔹 Amazon S3 Table – برای مدیریت و بهینه‌سازی داده‌های Iceberg در AWS.
🔹 Dremio Catalog Service – برای کنترل متادیتا و بهینه‌سازی کوئری‌ها در مقیاس سازمانی.

بدون Table Services، مدیریت Iceberg در مقیاس بزرگ دشوار و پرهزینه خواهد بود. در آینده، رقابت بر سر ارائه این خدمات بیش از پیش تشدید خواهد شد.
مقاله زیر با جزییات بیشتر به این موضوع و دو حوزه فعال دیگر در توسعه Apache Iceberg 🧊 می‌پردازد .
https://www.dremio.com/blog/demystifying-apache-iceberg-table-services-what-they-are-and-why-they-matter/

‍ زبان Rust در افق مهندسی داده
مدتی است که Rust حضور پررنگی در مهندسی داده پیدا کرده است. از Polars که به رقیبی سریع برای pandas تبدیل شده، تا DataFusion که یک موتور سبک SQL است. ابزارهایی مانند Vector.dev، Redpanda Connect، Meilisearch، Cube و Tauri نیز در حوزه‌های خود بسیار مورد توجه قرار گرفته‌اند.
اخیراً شرکت RisingWave اعلام کرد که استفاده از Iceberg-Rust تا ۱۰ برابر هزینه‌های فشرده‌سازی و مدیریت LakeHouse را بهبود داده و عملکردی سریع‌تر از Spark ارائه داده است.

اگر درباره Rust و مهندسی داده جستجو کنید، به مقالات زیادی برمی‌خورید :


🔹 Will Rust Take over Data Engineering? 🦀
🔹 Why Rust is taking the data engineering world by storm
🔹 Rust and Data Engineering: why it makes sense in 2024
🔹 Behind the Rust Hype: What Every Data Engineer Needs to Know
🔹 Building Strong Foundations: Using Rust for Data Engineering
🔹 Love and Hate to Rust – Two Years' Journey of a Data Engineer
🔹 Rust for Big Data and Parallel Processing Applications
🔹 Data Engineering in Rust


📊 چرا Rust این قدر محبوب شده است؟
📌 کارایی بالا – انتزاع‌های بدون هزینه و مدیریت حافظه قوی، پردازش داده‌ها را بهینه می‌کند.
📌 ایمنی حافظه – بررسی‌های سخت‌گیرانه زمان کامپایل، از بروز خطاهای رایج جلوگیری می‌کند.
📌 اکوسیستم در حال رشد – ابزارهایی مانند Polars، DataFusion و Iceberg-Rust در حال گسترش هستند.
📌 قابلیت همکاری – امکان تعامل با سایر زبان‌ها و سیستم‌ها، Rust را به گزینه‌ای مناسب در معماری‌های مهندسی داده تبدیل کرده است.

طبق نظرسنجی StackOverflow 2024، زبان Rust با ۸۳٪ محبوبیت همچنان عنوان محبوب‌ترین زبان برنامه‌نویسی را در اختیار دارد! 🎖

🆚 آیا Rust جایگزین Python خواهد شد؟

✅ در حوزه پردازش داده، Python همچنان یک انتخاب اصلی است، اما در بخش‌هایی که کارایی و سرعت حیاتی است، ابزارهای مبتنی بر Rust در حال گسترش و محبوبیت هستند. بنابراین به عنوان یک مهندس داده، تا چند سال آینده آشنایی با این زبان به نظرم یکی از ضروریات خواهد بود.

📚 آیا به‌عنوان یک مهندس داده علاقه‌مند هستید که Rust را شروع کنید؟
سه مسیر پیشنهادی برای یادگیری Rust
1️⃣ بخش Rust By Example از مستندات رسمی Rust – این منبع آموزشی با ارائه مثال‌های عملی و همراه با جزئیات کافی، شما را با مفاهیم اصلی Rust آشنا می‌کند.
2️⃣ کتابخانه آموزشی Rustlings – اگر به یادگیری سریع و چالشی علاقه‌مند هستید، Rustlings گزینه‌ای عالی است. خود من با کتابخانه آموزشی شروع کردم . این پروژه شامل حدود ۱۰۰ تمرین عملی است که شما باید هر فایل را تکمیل کرده و خطاهای آن را برطرف کنید. حالت چالشی و تعاملی این روش، یادگیری را جذاب‌تر می‌کند!
- ابتدا Rust را در WSL نصب کنید.
- سپس Rustlings را اجرا کنید و پیشرفت خود را بررسی کنید.
در یک ترمینال، تمرین‌ها را اصلاح کرده و با rustc کامپایل کنید تا از درستی کار خود مطمئن شوید.

3️⃣ دوره آموزشی Coursera – اگر به یادگیری ساختارمند علاقه دارید، این دوره از ۳۱ مارس شروع شده و روی ساختارهای داده، ایمنی، هم‌زمانی و پردازش داده تمرکز دارد. همچنین شما را با ابزارهای هوش مصنوعی، محیط‌های ابری و پیاده‌سازی پایپ‌لاین‌های داده‌ای بهینه آشنا می‌کند.

‍ 🔴 بحران پنهان مهندسی داده: چرا کمبود متخصصان این حوزه زنگ خطر بزرگی است؟

📌 این مطلب ترجمه‌ای است از مقاله Shashwath Shenoy در مدیوم با عنوان: 🔗 The Data Engineering Talent Crisis No One Is Talking About!

🚀 مهندسی داده؛ ستون فقرات تحول دیجیتال که در حال نادیده گرفته شدن است

💾 در دنیای فناوری، داده حکم طلا را دارد. شرکت‌ها میلیاردها دلار برای پلتفرم‌های داده، پردازش‌های بلادرنگ و تحلیل‌های مبتنی بر هوش مصنوعی سرمایه‌گذاری می‌کنند.

⚠️ اما یک چالش بزرگ در حال شکل‌گیری است:

ما به تعداد کافی مهندس داده‌ی متخصص نداریم!

📈 تقاضا برای مهندسان داده سر به فلک کشیده است، اما عرضه‌ی نیروی متخصص همچنان محدود باقی مانده است.


🤔 چرا تمرکز بیش از حد روی علم داده، مشکل‌ساز شد؟

🔍 سال‌ها، شرکت‌ها اولویت خود را روی استخدام دانشمندان داده گذاشتند و تصور کردند که این افراد موتور محرک نوآوری خواهند بود.


❌ اما مشکل کجاست؟

💡 بدون زیرساخت مناسب و خطوط پردازش داده‌ی بهینه، دانشمندان داده کارایی لازم را ندارند!

📉 داده‌های بی‌کیفیت، عملکرد ضعیف کوئری‌ها و نبود زیرساخت‌های مقیاس‌پذیر، باعث شکست بسیاری از پروژه‌های هوش مصنوعی و تحلیلی شده است.

🆘 حتی اکنون، آگهی‌های شغلی برای مهندسان داده از دانشمندان داده پیشی گرفته است، اما دانشگاه‌ها همچنان روی علم داده تمرکز دارند و دوره‌های آموزشی فقط سطحی‌ترین مباحث مهندسی داده را پوشش می‌دهند.

🏢 چرا استارتاپ‌ها و شرکت‌های متوسط از رقابت برای جذب مهندسان داده بازمانده‌اند؟

💰 یکی دیگر از دلایل این بحران، جذب گسترده‌ی مهندسان داده توسط غول‌های فناوری مانند گوگل، آمازون و مایکروسافت با پرداخت حقوق‌های نجومی است.

🔹 بسیاری از استارتاپ‌ها و شرکت‌های متوسط ماه‌ها به دنبال استخدام متخصصان مناسب می‌گردند اما موفق نمی‌شوند.

🔹 مهندسان داده‌ای که در شرکت‌های کوچک‌تر استخدام می‌شوند، ناچارند چندین نقش را همزمان ایفا کنند: معمار داده، مهندس زیرساخت و حتی مسئول DevOps، که این فشار کاری منجر به فرسودگی شغلی و نرخ بالای استعفا می‌شود.

🧠 هوش مصنوعی جایگزین مهندسان داده خواهد شد؟ 🤖 یک باور اشتباه!

⚡️ با پیشرفت ابزارهای ETL خودکار و پلتفرم‌های هوشمند پردازش داده، برخی تصور می‌کنند که مهندسی داده به‌زودی کاملاً خودکار خواهد شد.

🚫 اما این یک باور اشتباه و خطرناک است.

✅ هوش مصنوعی می‌تواند سرعت و بهره‌وری را افزایش دهد، اما قادر به طراحی معماری‌های مقیاس‌پذیر و رفع مشکلات پیچیده‌ی داده نیست.

✅ با گسترش یادگیری ماشین و پردازش‌های هوش مصنوعی، نیاز به مهندسان داده بیشتر از قبل خواهد شد.


🔧 چگونه می‌توان این بحران را حل کرد؟

🔄 برای جلوگیری از گسترش این بحران، شرکت‌ها باید رویکرد خود را تغییر دهند:

✔️ به‌جای رقابت بر سر تعداد محدودی از متخصصان، نیروهای موجود را آموزش دهند

🎓 بسیاری از برنامه‌نویسان، مهندسان نرم‌افزار و مدیران پایگاه داده می‌توانند با آموزش مناسب، به مهندسان داده‌ی توانمند تبدیل شوند.

✔️ دانشگاه‌ها و بوت‌کمپ‌ها باید دوره‌های عملی مهندسی داده ارائه دهند

📚 مهارت‌هایی مانند اسپارک، ایرفلو، کوبرنتیز و معماری‌های ابری باید بخش کلیدی آموزش‌های مهندسی داده باشند.

✔️ شرکت‌ها باید بر روی نگهداشت نیروی انسانی تمرکز کنند

🏆 سازمان‌هایی که روی ایجاد تیم‌های قدرتمند مهندسی داده سرمایه‌گذاری کنند یک مزیت رقابتی پایدار خواهند داشت.

📸 عکس از Unsplash🔗

‍ تحول معماری داده: از Data 1.0 تا Data 3.0

شرکت سرمایه گذاری خطر پذیر BVP اخیرا یک گزارش با عنوان «نقشه راه: Data 3.0 در عصر Lakehouse» منتشر کرده است که نکات اصلی آنرا در این نوشتار با هم مرور می‌کنیم (https://lnkd.in/gFFwjBDg).

توضیح اینکه Bessemer Venture Partners (BVP) یک شرکت سرمایه‌گذاری خطرپذیر با بیش از یک قرن سابقه است که بر روی استارتاپ‌های نوآور در حوزه‌هایی مانند هوش مصنوعی، محاسبات ابری، فین‌تک و امنیت سایبری سرمایه‌گذاری می‌کند. این شرکت در رشد برندهای بزرگی مانند Shopify، LinkedIn، Pinterest و Databricks نقش داشته و با تمرکز بر فناوری‌های پیشرفته، به کارآفرینان کمک می‌کند تا کسب‌وکارهای تحول‌آفرین ایجاد کنند. بنابراین گزارشی که این شرکت منتشر کرده است می‌تواند حائز اهمیت و حاوی نکات ارزشمندی باشد. این نوشتار، خلاصه ای از گزارش فوق است.

🔎 مقدمه: چرا Data 3.0 مهم است؟

مدیریت و پردازش داده‌ها از گذشته تا کنون چندین مرحله تحول را پشت سر گذاشته است. هر نسل از فناوری‌های داده‌ای مشکلات نسل قبل را برطرف کرده و امکانات جدیدی را برای تحلیل، ذخیره‌سازی و استفاده از داده‌ها فراهم کرده است. اکنون در آستانه ورود به نسل سوم مدیریت داده، یعنی Data 3.0 هستیم. اما قبل از آن، بیایید نگاهی به دو نسل قبلی بیندازیم.

🛠دوره اول - Data 1.0: پایگاه‌های داده و انبارهای اطلاعاتی

📅 دوره: ۱۹۷۰ تا ۲۰۰۰

🔹 ویژگی: پردازش متمرکز داده‌های ساختاریافته

🔹 ابزارها: RDBMS (Oracle, MySQL, SQL Server)، انبار داده

❌ محدودیت: عدم پشتیبانی از داده‌های غیرساختاریافته، هزینه بالا

در این دوران، شرکت‌ها از پایگاه‌های داده رابطه‌ای مانند Oracle, MySQL, SQL Server برای مدیریت اطلاعات استفاده می‌کردند. با ظهور انبار داده (Data Warehouse)، سازمان‌ها توانستند داده‌های عملیاتی را برای گزارش‌گیری و تحلیل‌های BI بهینه کنند.


🌊 دوره دوم - Data 2.0: کلان‌داده و دریاچه‌های داده

📅 دوره: از ۲۰۱۰ به بعد

🔹 ویژگی: ذخیره‌سازی و پردازش داده‌های حجیم و متنوع

🔹 ابزارها: Hadoop، Spark، Data Lake

✅ مزایا: پشتیبانی از انواع داده‌ها، پردازش موازی

❌ چالش: کیفیت پایین داده (Data Swamp)، پیچیدگی بالا

در این دوره، شرکت‌ها سعی کردند حجم عظیمی از داده‌های خام را بدون پردازش اولیه ذخیره کنند و بعداً برای تحلیل‌های مختلف از آن استفاده کنند. اما نبود استانداردهای کیفیت داده باعث شد بسیاری از پروژه‌های Data Lake با شکست مواجه شوند.


🚀 دوره سوم - Data 3.0: ترکیب بهترین‌های گذشته با فناوری‌های جدید
🔹 دوره زمانی: از ۲۰۲۰ به بعد
🔹 ویژگی اصلی: یکپارچگی، هوشمندی و انعطاف‌پذیری
🔹 ابزارهای کلیدی: Lakehouse، AI-powered Pipelines، پردازش لحظه‌ای

🔹 Data 3.0 چه چیزی را حل می‌کند؟
✅ Lakehouse ترکیب قدرت انبار داده (DW) و دریاچه داده (DL) را ارائه می‌دهد.
✅ پردازش داده‌های ساختاریافته، نیمه‌ساختاریافته و غیرساختاریافته بدون نیاز به انتقال بین سیستم‌های مختلف.
✅ استفاده از هوش مصنوعی و یادگیری ماشین برای خودکارسازی پردازش داده‌ها.
✅ پشتیبانی از فرمت‌های مدرن مانند Delta Lake، Iceberg و Hudi برای ذخیره و مدیریت داده.
✅ معماری‌های Cloud-Native و Serverless باعث کاهش هزینه‌های پردازشی شده‌اند.

🎯 مهم‌ترین فناوری‌ها و مفاهیم در Data 3.0

1️⃣ Lakehouse:
مدلی که ساختار داده‌های Data Warehouse را با انعطاف‌پذیری Data Lake ترکیب می‌کند.

2️⃣ Data Mesh:
مدلی که مالکیت داده‌ها را بین تیم‌های مختلف توزیع می‌کند تا به جای یک تیم مرکزی، هر تیم مسئولیت داده‌های خود را داشته باشد.

3️⃣ Metadata & Data Governance:
مدیریت متادیتا و کیفیت داده اهمیت بیشتری پیدا کرده است.

4️⃣ AutoML & AI-driven Pipelines:
یادگیری ماشین و هوش مصنوعی فرآیندهای ETL را بهینه می‌کنند.

5️⃣ Real-time & Streaming Analytics:
تحلیل‌های لحظه‌ای (مانند Apache Flink) به جای پردازش‌های دسته‌ای.

6️⃣ New Data Formats (Delta/Iceberg/Hudi)


🔮 آینده Data 3.0: به کجا می‌رویم؟

💡 در آینده، معماری‌های داده‌ای بیشتر خودکار، توزیع‌شده و هوشمند خواهند شد. تیم‌های مهندسی داده دیگر مجبور به مدیریت زیرساخت‌های پیچیده نخواهند بود، بلکه تمرکز بیشتری روی ارزش‌آفرینی از داده‌ها خواهند داشت.

‍ 📌 چرا استک داده‌های امروزی ناکارآمد شده‌اند؟ و راه‌حل چیست؟

🔹 امروزه سازمان‌ها با انبوهی از ابزارهای داده (مثل Snowflake، Databricks، Fivetran، dbt، Tableau و ...) مواجه هستند که هرکدام به‌تنهایی کارآمد هستند، اما در کنار هم باعث افزایش پیچیدگی، کاهش بهره‌وری و اتلاف منابع می‌شوند.

📉 مشکلات اصلی استک داده‌های امروزی:

🔸 هزینه‌های پنهان 💸

پرداخت لایسنس به ۵+ فروشنده مختلف.

هزینه‌های زیرساختی (سرورها، پردازش و ذخیره‌سازی مجزا).

نیاز به استخدام متخصصان متعدد برای مدیریت هر ابزار.

۴۰٪ از زمان مهندسان داده صرف یکپارچه‌سازی ابزارها می‌شود!

🔸 بار شناختی بالا و فرسودگی تیم‌ها 🧠

هر ابزار معماری و زبان خاص خود را دارد (Airflow برای Batch، Flink برای Real-time و …).

متخصصان درگیر حل مشکلات ابزارها هستند، نه تحلیل داده.

وابستگی به افراد خاص که فقط یک بخش از استک را می‌شناسند.

🔸 بی‌اعتمادی به داده‌ها 📉

گزارش‌های متناقض در ابزارهای مختلف (مثلاً عدد فروش در Power BI با Tableau متفاوت است).

اختلافات بین تیم‌ها بر سر ابزارهای موردعلاقه‌شان.

مشکلات حاکمیت داده در معماری‌های متمرکز یا غیرمتمرکز.


🔎 راهکار چیست؟

✅ ۱. حرکت به سمت معماری مدولار و مستقل از فروشنده (Vendor-Agnostic)

به‌جای ابزارهای یکپارچه و پیچیده، از ماژول‌های سبک‌وزن و ترکیب‌پذیر برای ETL، ذخیره‌سازی و پردازش استفاده کنید.

نتیجه؟ کاهش هزینه، افزایش انعطاف‌پذیری و امکان انتخاب بهترین ابزار برای هر نیاز.

✅ ۲. ایجاد یک لایه یکپارچه (Utility Plane) برای مدیریت داده‌ها

این لایه وظایف پردازش، ذخیره‌سازی و متادیتا را به‌صورت استاندارد ارائه می‌دهد. مثال: Netflix با Utility Plane داده‌هایش را بین Redshift، Snowflake و Athena هماهنگ نگه می‌دارد.

✅ ۳. کاهش پیچیدگی بدون تغییرات ناگهانی

به‌جای حذف یکباره ابزارهای قدیمی، از Adapterها برای اتصال آنها به Utility Plane استفاده کنید.

به‌مرور، ابزارهای سنگین و ناکارآمد را با ماژول‌های جدید جایگزین کنید.

✅ ۴. پیاده‌سازی پلتفرم توسعه‌دهنده داده (Data Developer Platform)

- مدیریت متمرکز منابع (Central Control Plane):

کنترل دسترسی‌ها، متادیتا و خط‌مشی‌ها از یک نقطه.

- توسعه ماژولار (Development Plane):

مهندسان داده می‌توانند ماژول‌های کوچک (مثل یک Transform یا Validator) بنویسند و در کل سازمان استفاده کنند.

- معماری Right-to-Left:

شروع از نیاز کسب‌وکار (مثلاً "چرا فروش کاهش یافته؟") و سپس انتخاب ماژول‌های موردنیاز.

💡 جمع‌بندی:

📌 مشکل اصلی: پیچیدگی بیش‌ازحد، وابستگی به ابزارهای متعدد و ناکارآمدی عملیات داده.

📌 راه‌حل: حرکت به سمت معماری ماژولار، Utility Plane یکپارچه، و رویکرد تدریجی در بهینه‌سازی استک داده.


📖 مقاله کامل را در مدیوم بخوانید: https://lnkd.in/di9w9Hgz

‍ یک خرید استراتژیک در دنیای مهندسی داده متن‌باز: SDF+DBT
اگر دنیای فناوری را دنبال کرده باشید، احتمالاً بارها دیده‌اید که یک شرکت نوپا با ایده‌ای جذاب، قبل از اینکه به رقیبی جدی بدل شود، توسط یکی از غول‌های صنعت خریداری می‌شود.
📌 WarpStream که در ۲۰۲۴ توسط Confluent خریداری شد، یکی از همین نمونه‌ها بود. WarpStream ابزار پردازش داده‌های جریانی نوآورانه‌ای بود که در Confluent ادغام شد.
🔎 چرا این اتفاق می‌افتد؟ زیرا شرکت‌های بزرگ ترجیح می‌دهند نوآوری را بخرند و آن را در محصولات خود ادغام کنند، نه اینکه با آن رقابت کنند. این دقیقاً همان اتفاقی است که برای SDF Labs، یکی از رقبای جدید dbt، رخ داد.

آیا خریدهای متن‌باز به نفع جامعه متن‌باز هستند؟
خریدهای استراتژیک می‌توانند با تأمین منابع بیشتر، رشد و توسعه پروژه‌های متن‌باز را تسریع کنند. اما، احتمالاً باعث کاهش نوآوری مستقل و کنترل بیشتر شرکت‌های بزرگ روی پروژه‌ها می‌شود. امیدواریم که این خریدها به تقویت پروژه‌های متن‌باز منجر شود.

💡 ببینیم DBT چیست ؟
سالهاست که dbt به عنوان یک ابزار اصلی در دنیای تحلیل داده‌ها، تحولی اساسی در ETL های مبتنی بر SQL ایجاد کرده است. dbt به تحلیلگران داده این امکان را می‌دهد که بدون نیاز به ابزارهای پیچیده، فرآیندهای Transform را خودشان مدیریت کنند، آن‌هم تنها با استفاده از SQL استاندارد. این ابزار به سرعت در تیم‌های داده در سراسر دنیا محبوب شد و به یک استاندارد صنعتی تبدیل شد.

💡 محدودیت‌های dbt
با وجود تمام مزایای dbt، یک مشکل اساسی همیشه باقی بود:
❌ ابزار dbt درک مستقیمی از SQL نداشت و فقط آن را به عنوان یک string پردازش می‌کرد.
🔍 این یعنی SQL نوشته‌شده به‌صورت مستقیم توسط پایگاه داده اجرا می‌شد و dbt توانایی بررسی و تحلیل دقیق آن را نداشت.
🚧 نتیجه؟ فرایندهای پیچیده‌تر، مشکلات ناشی از تغییرات غیرمنتظره و زمان طولانی برای اجرا!

🔥 حالا SDF چرا در عرض دو سال به سرعت محبوب شد؟
در حالی که dbt به خوبی نیازهای بسیاری از تیم‌های داده را پوشش می‌داد، SDF توانست به نحوی نوآورانه به چالش‌های آن پاسخ دهد.
📊 با توجه به محبوبیت و رواج SQL در بین تیم‌ها تحلیل داده، SDF می‌تواند کدهای SQL را عمیق‌تر تحلیل کند، خطاها را سریع‌تر شناسایی کند و حتی تغییرات نادرست را قبل از ورود به محیط واقعی متوقف کند.
✅ ویژگی‌های کلیدی SDF:
🔹 تشخیص سریع خطاها و جلوگیری از مشکلات داده‌ای
🔹 بهینه‌سازی کدهای SQL
🔹 ردیابی دقیق مسیر حرکت داده‌ها در سطح ستون‌ها
🔹 پشتیبانی از چندین نوع SQL و اتصال به ابزارهای مختلف مثل Snowflake
🔹 محیط توسعه ایزوله برای تست و بررسی تغییرات بدون تأثیر بر داده‌های واقعی
ابزار SDF به تیم‌های داده این امکان را می‌داد که با خیال راحت‌تر و سریع‌تر کار کنند و پیش از وقوع مشکلات، آنها را شبیه‌سازی و شناسایی کنند.

آینده متن‌باز در دنیای داده‌ها

این خرید، یکی از دلایلی است که به معماری دریاچه داده‌های باز (Open Data Lakehouse) اشاره می‌کند، جایی که هر جزء از استک باید مدل باز داشته باشد. این باز بودن می‌تواند از ذخیره‌سازی متن‌باز گرفته تا فرمت‌های جداول باز مانند Iceberg، Delta Lake، و Hudi، به موتورهای کوئری و حالا به لایه‌های تبدیل داده‌های SQL با dbt و SDF Labs ادامه یابد.

امیدواریم که با وجود این خرید استراتژیک، SDF Core همچنان به‌صورت متن‌باز باقی بماند .

نگاهی سریع به SDF :
https://docs.sdf.com/introduction/welcome

منبع خبر :
https://www.getdbt.com/blog/dbt-labs-acquires-sdf-labs

‍ ده سال با مهندسی داده (BigData.ir) 🎉
ده سال پیش، وقتی تصمیم گرفتم وب‌سایتی برای موضوعی بسازم که آن روزها حتی ترجمه‌اش به فارسی ناشناخته بود – «بیگ دیتا» – نه فکرش را می‌کردم که این مسیر تا امروز ادامه پیدا کند و نه می‌دانستم که روزی «مهندسی داده» به یکی از تخصص‌های کلیدی دنیای فناوری تبدیل خواهد شد.

در این سال‌ها، تلاش کرده‌ام در BigData.ir محتوایی بنویسم که از دل تجربه و یادگیری‌های شخصی‌ام یا گفتگو با دوستان و همکارانم بیرون آمده باشد. نه صرفاً بازنشر، بلکه تحلیل و انتخاب آگاهانه از میان انبوهی از موضوعات و تکنولوژی‌ها. بعضی فناوری‌ها که در گذشته درباره‌شان نوشته‌ام امروز شاید فراموش شده‌اند، اما تلاش من همیشه این بوده که چیزی منتشر کنم که به درد کسی بخورد.

امروز می‌دانم که خیلی‌ها دیگر کمتر به سایت‌ها یا وبلاگ‌های فنی مراجعه می‌کنند، اما مهندسی داده برای من فقط یک وب‌سایت نیست؛ بخشی از مسیر حرفه‌ای من است. دغدغه‌ای که باعث شده همیشه سعی کنم به‌روز بمانم و نوشتن را رها نکنم. حتی لوگوی سایت، که از همان ابتدا «مهندسی داده» بود، آن‌قدر جلوتر از زمان خودش بود که هنوز هم برایم الهام‌بخشه.

امیدوارم در این سال‌ها تونسته باشم نقشی – هرچند کوچک – در رشد جامعه تخصصی داده در ایران داشته باشم.
و اگر دوست داشتید، این هم لینک نوشته‌ام در سایت شخصی خودم درباره راه‌اندازی سایت، دقیقاً ده سال پیش:
🔗 وب‌سایت کلان‌داده (بیگ دیتا) راه‌اندازی شد

به امید ادامه‌ی این مسیر... 🙏
#BigData #مهندسی_داده #DataEngineering # تولید_محتوا #علم_داده #ده_سالگی

‍ تحولی بزرگ در Apache Airflow: نسخه ۳ در راه است! 🚀

بعد از سال‌ها تجربه با نسخه‌های ۱ و ۲، حالا نسخه ۳ با بازطراحی گسترده و حل چالش‌های قدیمی در دسترس توسعه‌دهندگان قرار گرفته — فعلاً به‌صورت نسخه‌ کاندید انتشار (Release Candidate).
در ادامه نگاهی داریم به مهم‌ترین تغییرات:


🔁 نسخه‌بندی DAGها و تاریخچه اجراها

در گذشته بررسی تغییرات در DAGها کاری زمان‌بر و دشوار بود.

✅ حالا در نسخه ۳، تاریخچه‌ی کامل DAGها از طریق UI (در Grid و Graph View) در دسترس است — حتی حذف یا اضافه شدن Taskها بین نسخه‌ها قابل ردیابی شده است.


🧠 Backfill هوشمند و یکپارچه

Backfillها قبلاً مشکلاتی در عملکرد و مقیاس‌پذیری داشتند.

✅ اکنون توسط Scheduler مدیریت می‌شوند و از طریق UI هم قابل اجرا هستند. مناسب برای ML و ETL.


🌐 اجرای وظایف در هر زبان و محیطی

تا قبل از این، فقط Python در دسترس بود.

✅ با Task Execution API، Airflow به معماری Client/Server رسیده.

می‌توانید Taskها را از Python، Go (و بزودی زبان‌های دیگر) اجرا کنید — حتی در Edge یا Multi-cloud.


📩 زمان‌بندی بر اساس رویدادها (Event-Driven Scheduling)

در نسخه‌های قبلی، اجرای DAGها تنها براساس زمان یا وابستگی‌های داخلی ممکن بود.

✅ حالا Airflow 3 با معرفی مفهوم «دارایی‌های داده‌ای» (Data Assets) و «ناظران» (Watchers) امکان اجرای DAG بر اساس رویدادهای خارجی را فراهم کرده است.

به‌صورت پیش‌فرض، اتصال به AWS SQS فراهم شده است — مثلاً با رسیدن یک پیام به SQS، یک DAG می‌تواند اجرا شود.

اما نکته مهم‌تر:

🔄 این ساختار ماژولار است و می‌توانید Apache Kafka یا سایر سیستم‌های پیام‌رسان را نیز جایگزین کنید. کافی است یک Watcher مخصوص Kafka بنویسید که روی Topic مشخصی گوش دهد و پیام‌های جدید را به Airflow منتقل کند.
این امکان، Airflow را برای سناریوهای real-time در مقیاس بالا، بسیار انعطاف‌پذیر می‌کند.


🤖 اجرای بلادرنگ برای هوش مصنوعی

تاکنون وابستگی به execution_date مانع اجرای DAGهای Realtime بود.

✅ اکنون می‌توانید DAGهایی بدون وابستگی زمانی اجرا کنید — عالی برای Inference و API-based Workflows.


🖥 رابط کاربری کاملاً جدید

UI قدیمی سنگین و محدود بود.

✅ Airflow 3 با React و FastAPI بازنویسی شده. سریع، سبک و قابل توسعه.

همچنین Flask AppBuilder از Core جدا شده و به یک پکیج مستقل تبدیل شده.


🔐 ایزولاسیون وظایف و امنیت بالا

اجرای Taskها در یک محیط مشترک مشکل‌ساز بود.

✅ حالا هر Task می‌تواند به‌صورت ایزوله اجرا شود. CLI هم با airflowctl برای دسترسی از راه دور مجهز شده.

🗳 این نسخه فعلاً در مرحله آزمایشی و بررسی جامعه توسعه‌دهندگان است. اگر تجربه Airflow دارید، فرصت خوبیه برای تست و ارسال بازخورد قبل از انتشار نهایی.

#مهندسی_داده #ApacheAirflow3 #DataEngineering #MLOps #Kafka #EventDriven #DataOps #Automation 🚀

منبع : https://www.linkedin.com/pulse/apache-airflow-3-release-candidate-apr-4-2025-vikram-koka-3lhmc/

‍ طراحی یک موتور پردازش جریان با Rust: بررسی Sail 0.2.2

چند وقت پیش به کتابخانه متن‌باز Sail برخوردم که نسخه 0.2.2 آن تازه منتشر شده. با اینکه هنوز در مراحل ابتدایی است، طراحی هوشمندانه‌اش توجه من را جلب کرد. Sail یک موتور پردازش داده سبک، سریع و مدرن است که با زبان Rust توسعه یافته و از پیشرفت‌های اخیر در پردازش داده‌ها و تجربیات سیستم‌های پردازش جریان بهره می‌برد.

هدف؟ ساختن جایگزینی برای ابزارهای سنگینی مثل Spark Structured Streaming—اما با طراحی ساده‌تر، هزینه کمتر، و عملکرد بسیار بالاتر.

🧠 معماری دوبخشی: تفکیک واضح بین Control و Data
کتابخانه Sail از یک معماری دو لایه استفاده می‌کنه:

بخش کنترل - Control Plane: مغز سیستم که مسئول زمان‌بندی، هماهنگی و مدیریت اجرای تسک‌هاست. ارتباط بین اجزا از طریق gRPC انجام می‌شه که latency پایین و بازدهی بالا داره.

بخش مدیریت داده - Data Plane: محل پردازش و انتقال داده‌ها. با بهره‌گیری از Apache Arrow IPC، داده‌ها بدون serialization بین اجزا جابجا می‌شن. این یعنی کارایی بالا و پردازش سریع در حافظه.

🦀 چرا Rust؟ برای کارایی، ایمنی و کنترل
زبان Rust انتخاب شده چون:
مدیریت حافظه در زمان کامپایل داره → بدون نیاز به GC → بدون توقف ناگهانی
پشتیبانی از async/await با کتابخونه‌هایی مثل Tokio → هم‌زمانی ایمن و سریع
zero-cost abstractions → abstraction بدون هزینه‌ی runtime
جلوگیری از race condition و memory leak

ترکیب این ویژگی‌ها باعث شده Sail به‌صورت طبیعی مناسب real-time data processing باشه—با latency پایین و throughput بالا.


🔁 اتصال سریع به دنیای Python و AI

کتابخانه Sail راه ارتباط با پایتون رو ساده و سریع کرده:
پشتیبانی از UDFهای پایتون (مثل PySpark)
استفاده از PyO3 برای ارتباط با Python، بدون Py4J و سربار serialization
zero-copy بودن ارتباط → انتقال داده بدون کپی اضافی
پشتیبانی از Pandas UDFs و تبادل مستقیم داده با NumPy/Arrow

این یعنی می‌تونی از مدل‌های ML یا تحلیل‌های سفارشی در پایتون استفاده کنی، بدون هزینه‌ی اضافه‌ای که Spark به همراه داره.


💡 موتور SQL قدرتمند و قابل توسعه
کتابخانه Sail یک موتور SQL اختصاصی دارد که با استفاده از پارسرهای ترکیبی chumsky و Rust macros برای گسترش گرامر SQL پیاده‌سازی شده. این موتور قادر است کوئری‌های پیچیده استاندارد مانند TPC-H و TPC-DS را به‌خوبی اجرا کند. همچنین، با بهره‌گیری از Apache DataFusion، از قابلیت‌های بهینه‌سازی برداری، پردازش ستونی و اجرای هم‌زمان پشتیبانی می‌کند.


🧩 مدل Actor برای هم‌زمانی ایمن و مقیاس‌پذیر
کتابخانه Sail از الگوی Actor برای اجرای توزیع‌شده استفاده می‌کنه:
هر node مثل driver یا worker → یک actor مستقل
ارتباط بین actorها از طریق پیام → بدون lock یا شرایط رقابتی
اجرا در event loop غیربلوکه شونده → هم‌زمانی بهینه
تحمل خطا بالا → crash یک actor کل سیستم رو متوقف نمی‌کنه

این معماری به‌ویژه برای سیستم‌هایی که با داده‌های زنده یا حجم بالا کار می‌کنن عالیه—مثل real-time dashboards یا AI pipelines.

کتابخانه Sail نشون می‌ده چطور با انتخاب‌های درست—مثل Rust برای کارایی، مدل Actor برای هم‌زمانی، Arrow برای انتقال داده و سازگاری با Spark—سیستمی ساخته می‌شه که هم نیازهای فعلی رو برآورده می‌کنه، هم برای آینده آماده است. این طراحی نه‌تنها در تئوری جذابه، بلکه در عمل هم موفق بوده: کاهش ۹۴٪ هزینه سخت‌افزار و سرعت ۴ برابر بیشتر نسبت به Spark.

اگر قصد دارید با Spark کار کنید، شاید بد نباشه این گزینه رو به جای اسپارک اصلی امتحان کنید.

آدرس پروژه : https://github.com/lakehq/sail

‍ از خبر تا پادکست در چند دقیقه: جادوی n8n و هوش مصنوعی بدون یک خط کدنویسی 🎙

همه‌ی ما که در تیم‌های فنی/تحلیل‌داده یا توسعه سامانه‌ها کار می‌کنیم، خوب می‌دونیم که بخشی از کارها باید به‌صورت خودکار و زمان‌بندی‌شده انجام بشن؛ مثلاً:

🧩گرفتن بکاپ دیتابیس به‌صورت شبانه

🧩اجرای اسکریپت‌های پردازش داده در ساعات کم‌ترافیک

🧩همگام‌سازی داده‌ها بین چند سرویس

🧩ارسال اعلان، ایمیل یا گزارش‌های روزانه و هفتگی

🧩یا حتی پاک‌سازی فایل‌های موقت و مانیتورینگ وضعیت سرویس‌ها

تا چند سال پیش برای این کارها معمولاً سراغ کرون‌جاب‌ها، اسکریپت‌های دستی، یا نهایتاً Airflow می‌رفتیم. ولی دنیای اتوماسیون خیلی سریع‌تر از اون چیزی که فکر می‌کردیم پیشرفت کرده...


🌍 جایی که اتوماسیون به عامل‌های هوشمند می‌رسه...

با رشد ابزارهای هوش مصنوعی مولد (مثل GPT, Gemini, Claude)، حالا انتظار ما از سیستم‌های اتوماسیون فقط اجرای زمان‌بندی‌شده نیست—بلکه می‌خوایم:

- 📦 ورودی‌ها رو هوشمند تحلیل کنه

- 📦 تصمیم بگیره که چه کاری انجام بشه

- 📦 با سایر ابزارها گفت‌وگو کنه

- 📦 نتیجه نهایی رو تولید کنه، اونم بدون دخالت ما

اینجا دقیقا جاییه که ابزارهایی مثل n8n وارد می‌شن—که نه‌تنها اتوماسیون رو ساده می‌کنن، بلکه بستری برای پیاده‌سازی همین "عامل‌های هوشمند" هم فراهم می‌کنن.

🔄 از NiFi تا n8n: سیر تکامل سیستم‌های Workflow محور

طلیعه‌دار این نوع تفکر، پروژه Apache NiFi بود که مفهوم جریان داده‌های بصری (Visual Flow-Based Programming) رو وارد دنیای بک‌اند کرد. اخیراً هم نسخه ۲ اون با تغییرات اساسی عرضه شده.

اما در مقابل، نیاز امروزی توسعه‌دهندگان به سمت ابزارهایی سبک‌تر، ساده‌تر و سریع‌تر با رابط گرافیکی جذاب و جامعه کاربری فعال حرکت کرده. اینجاست که n8n خودش رو نشون می‌ده:

🎯 چرا n8n محبوب شده؟

✅نصب ساده و سبک، حتی روی سرورهای کوچک

✅رابط کاملاً گرافیکی و No-code برای ساخت workflow

✅اتصال راحت به انواع API، دیتابیس، سرویس‌های ابری و ابزارهای AI

✅پشتیبانی از زبان‌های مختلف :

JavaScript (Node.js) برای نوشتن فانکشن‌ها

Python (با ماژول Python Node) برای اجرای تحلیل‌های پیچیده‌تر یا مدل‌های ML

✅ادغام‌های آماده با Hugging Face، Google Gemini، OpenAI و ...


🎧 یک نمونه واقعی: تبدیل اخبار BBC به پادکست صوتی با n8n و AI

اگر دوست دارید قدرت این ابزار رو در عمل ببینید، پیشنهاد می‌کنم این ویدئوی آموزشی فارسی از محمدرضا رنج‌دوست رو ببینید:

🔗 مشاهده در یوتیوب - https://www.youtube.com/watch?v=Z4MaAM6B3S4

این ویدیو چه چیزی رو نشون می‌ده؟

✅ دریافت خودکار اخبار از BBC

✅ پردازش و خلاصه‌سازی متن با استفاده از مدل‌های AI

✅ تولید فایل صوتی حرفه‌ای (Text-to-Speech)

✅ همه این مراحل فقط با چند کلیک ساده و بدون حتی یک خط کدنویسی

🎙 خروجی؟ یک پادکست روزانه، خودکار و هوشمند—فقط با n8n!



🧠 جمع‌بندی

در کنار ابزارهای قدرتمندی مثل Airflow، Prefect یا Dagster برای orchestrating pipelineهای پیشرفته، ابزارهایی مثل n8n دنیای جدیدی رو برای تیم‌های کوچک‌تر، توسعه MVPها، یا حتی خودکارسازی فرآیندهای هوشمند باز کرده‌اند.

ابزاری که هم ساده‌ست، هم منعطف، و هم آماده برای آینده‌ای که در اون عامل‌های هوشمند قراره نقش اول رو بازی کنن.


#هوش_مصنوعی #اتوماسیون #عامل_هوشمند #توسعه_سامانه #پادکست_هوشمند

‍ چند ثانیه سریع‌تر، یک تجربه متفاوت: افزایش سرعت سرویس ثبت آگهی، رضایت کاربران و درآمد!
این مطلب از وبلاگ مهندسی دیوار در وب سایت ویرگول برداشته شده است . آدرس اصلی مقاله : yun.ir/divar01
سال ۱۴۰۱، سرویس ثبت آگهی دیوار، یکی از حیاتی‌ترین بخش‌های پلتفرم، با چالش‌های فزاینده‌ای روبرو بود. با رشد دیوار و افزایش روزانه‌ی تعداد آگهی‌ها، زیرساخت قدیمی که با پایتون نوشته شده بود، دیگر پاسخگوی نیازهای ما نبود. کاربران هنگام ثبت آگهی با کندی و خطا مواجه می‌شدند و این موضوع مستقیماً بر تجربه‌ی آن‌ها و در نتیجه بر موفقیت دیوار تأثیر می‌گذاشت.

تیم فنی تصمیم گرفت برای حل ریشه‌ای این مشکلات، سرویس ثبت آگهی را بازنویسی کند. هدف اصلی بهبود پایداری (Reliability) و سرعت سرویس بود، اما نتیجه‌ی کار، یک غافلگیری خوشایند برای همه ما به همراه داشت: بدون اینکه هیچ تغییری در ظاهر یا فرآیند محصولی ثبت آگهی ایجاد کنیم، شاهد بهبود قابل توجه در متریک‌های محصولی و حتی افزایش محسوس درآمد دیوار بودیم!

ماجرا چه بود؟ چالش‌های سرویس قدیمی ثبت آگهی
سرویس قدیمی ثبت آگهی که با زبان پایتون توسعه داده شده بود، در گذر زمان و با افزایش بار ترافیکی، دچار مشکلاتی شده بود که هم کاربران و هم تیم‌های فنی دیوار را آزار می‌داد:

🦀 کندی و خطاهای مکرر: طراحی قدیمی سرویس دیگر نمی‌توانست حجم بالای درخواست‌ها را به خوبی مدیریت کند. کاربران اغلب با کندی در بارگذاری صفحات فرم ثبت آگهی و حتی خطاهای غیرمنتظره در لحظه‌ی نهایی فشردن دکمه «ثبت آگهی» مواجه می‌شدند. طبق گزارش‌ها، نزدیک به ۱۰ درصد تماس‌های پشتیبانی دیوار ناشی از همین مشکلات در فرآیند ثبت یا ویرایش آگهی بود و حدود ۰.۷۵ درصد درخواست‌های ثبت/ویرایش آگهی با خطای غیرمنتظره مواجه می‌شدند.
🦀 وابستگی‌های زیاد و شکنندگی: سرویس ثبت آگهی به سرویس‌های داخلی متعددی وابسته بود. بروز مشکل در هر یک از این سرویس‌ها می‌توانست کل فرآیند ثبت آگهی را مختل کند.
🦀 تجربه‌ی کاربری نامطلوب: کندی و خطاها باعث می‌شد کاربران از ثبت آگهی منصرف شوند یا فرآیند را نیمه‌کاره رها کنند. این تجربه‌ی ناخوشایند، به خصوص برای کاربرانی که برای اولین بار قصد ثبت آگهی داشتند، می‌توانست دلسردکننده باشد.
🦀 بهره‌وری پایین توسعه‌دهندگان: سرویس قدیمی از کتابخانه‌ای به نام ui schema برای ساخت فرم‌ها استفاده می‌کرد که قدیمی، فاقد type safety و مستندات کافی بود. این موضوع باعث بروز خطاهای زیاد در زمان توسعه، کندی فرآیند توسعه (تا ۲۰٪ کندتر طبق گفته‌ی تیم‌ها) و سختی در افزودن قابلیت‌های جدید می‌شد. مذاکرات مداوم بین تیم‌های بک‌اند و کلاینت برای اطمینان از هماهنگی، زمان زیادی را تلف می‌کرد.
با توجه به این چالش‌ها، در اردیبهشت ۱۴۰۲ تیمی اختصاصی برای بازنویسی کامل سرویس ثبت آگهی تشکیل شد. هدف، ساخت سرویسی به‌روز، پایدار، سریع و توسعه‌پذیر بود.

🧠 تغییرات فنی‌ای که دادیم: بازنویسی با نگاهی نو
برای مشاهده ادامه مطلب به سایت ویرگول و وبلاگ فنی دیوار مراجعه کنید.