مهندسی داده
An illustrated guide to AI Agents.pdf
کتابی فوق‌العاده و پرمحتوا درباره ایجنت‌های هوش مصنوعی، مملو از مثال‌ها و پروژه‌های کاربردی!
این کتاب به‌صورت منظم و ساختاریافته، ایجنت‌های هوش مصنوعی را با مثال‌های عملی و کدهای پایتون توضیح می‌دهد و راهنمایی عالی برای علاقه‌مندان به این حوزه است.
پروژه‌ها:
1. آشنایی با Agentic RAG
2. ایجنت صوتی RAG
3. جستجوگر پرواز چندایجنتی
4. تحلیلگر مالی
5. سیستم نظارت بر برند
6. جستجوگر هتل چندایجنتی
7. پژوهشگر عمیق چندایجنتی
8. حافظه شبه‌انسانی برای ایجنت‌ها
9. نویسنده کتاب چندایجنتی
10. سیستم تولید محتوا چندایجنتی
11. جریان نویسندگی اسناد
12. تولیدکننده اخبار
این کتاب به‌صورت منظم و ساختاریافته، ایجنت‌های هوش مصنوعی را با مثال‌های عملی و کدهای پایتون توضیح می‌دهد و راهنمایی عالی برای علاقه‌مندان به این حوزه است.
پروژه‌ها:
1. آشنایی با Agentic RAG
2. ایجنت صوتی RAG
3. جستجوگر پرواز چندایجنتی
4. تحلیلگر مالی
5. سیستم نظارت بر برند
6. جستجوگر هتل چندایجنتی
7. پژوهشگر عمیق چندایجنتی
8. حافظه شبه‌انسانی برای ایجنت‌ها
9. نویسنده کتاب چندایجنتی
10. سیستم تولید محتوا چندایجنتی
11. جریان نویسندگی اسناد
12. تولیدکننده اخبار
👍8❤2
آیا ردیس همچنان پادشاه حافظه‌هاست ؟ 👑
در دنیای فناوری، حتی محبوب‌ترین ابزارها هم برای ادامه مسیر به رقیب نیاز دارند. همان‌طور که در حوزه پردازش جریان، ظهور #Redpanda و #AutoMQ باعث شد سطح انتظارات از شرکت Confluent و حتی بنیاد آپاچی برای گسترش امکانات #Kafka بالا برود، حالا نوبت #Redis است که با چالش‌های تازه روبه‌رو شود.
ردیس سال‌هاست به‌عنوان یک پایگاه داده درون‌حافظه‌ای (In-Memory) سریع ⚡️، ساده و بی‌دردسر شناخته می‌شود. بسیاری از ما اولین تجربه کار با Cache، Session Storage یا حتی Pub/Sub را با همین ابزار داشته‌ایم. اما همین موفقیت و سادگی باعث شد که کمتر به سراغ گزینه‌های دیگر برویم… تا وقتی که یک مشکل واقعی سر راه‌مان سبز شود.
مشکل اول: استفاده ناکامل از CPU 🖥
ردیس ذاتاً تک‌ریسمانی است؛ یعنی هر چقدر هم CPU چند هسته‌ای داشته باشیم، در نهایت یک هسته درگیر پردازش می‌شود و بقیه بلااستفاده می‌مانند. وقتی حجم درخواست‌ها بالا برود، صف‌ها طولانی و تأخیرها بیشتر می‌شوند.
اینجاست که #KeyDB وارد میدان شد 💪. این ابزار در واقع نسخه‌ای از Redis است که یاد گرفته از چند هسته CPU همزمان استفاده کند. بدون تغییر در کد یا کتابخانه‌ها، می‌توانید با #KeyDB سرعتی چند برابر تجربه کنید.
مشکل دوم: هزینه بالای RAM 💸
هر کس #Redis را در مقیاس بزرگ استفاده کرده باشد، با مشکل مصرف زیاد حافظه آشناست. بخش زیادی از این مصرف به خاطر تکه‌تکه شدن و هدر رفتن فضای RAM است.
دیتابیس #Dragonfly دقیقاً برای حل همین مشکل ساخته شده 🐉. با معماری متفاوت و بسته‌بندی بهینه داده‌ها، می‌تواند تا یک‌سوم مصرف حافظه را کاهش دهد و همچنان سرعت بالایی ارائه کند. برای پروژه‌هایی با داده‌های کوچک اما بسیار زیاد – مثل ذخیره‌سازی میلیون‌ها سشن کاربر – #Dragonfly یک صرفه‌جویی واقعی در هزینه‌هاست.
مشکل سوم: تغییر لایسنس Redis 📜
تغییر لایسنس #Redis باعث شد بخشی از جامعه متن‌باز احساس کند آینده این پروژه دیگر کاملاً شفاف نیست. نتیجه این نگرانی، تولد #Valkey بود؛ یک فورک متن‌باز که با همان API و پروتکل Redis کار می‌کند اما بدون محدودیت‌های جدید لایسنس.
#Valkey از نظر فنی تفاوت بزرگی با Redis ندارد، اما برای کسانی که به دلایل حقوقی یا سیاست‌های سازمانی نمی‌توانند Redis را استفاده کنند، یک انتخاب امن و بی‌دردسر است.
مشکل چهارم: نیاز به توزیع‌شدگی واقعی 🌍
اگرچه Redis Cluster امکان مقیاس‌پذیری افقی را فراهم می‌کند، اما راه‌اندازی و نگهداری آن همیشه ساده نیست. #Hazelcast از روز اول برای توزیع‌شدگی طراحی شده و مدیریت داده بین چندین نود را به‌صورت خودکار انجام می‌دهد. این ویژگی آن را برای سیستم‌های بزرگ با نیاز واقعی به Cache توزیع‌شده جذاب می‌کند.(البته با پرداخت هزینه)
کدام را انتخاب کنیم؟ 🎯
اگر مشکل کارایی ندارید → #Redis بهترین انتخاب است.
📌اگر گلوگاه CPU دارید و می‌خواهید با کمترین تغییر سرعت بگیرید → #KeyDB را انتخاب کنید.
📌اگر هزینه RAM سنگین شده → #Dragonfly می‌تواند نجات‌بخش باشد.
📌اگر لایسنس برایتان مسئله است → #Valkey جایگزین امنی است.
📌اگر از ابتدا به یک Cache توزیع‌شده و سازمانی نیاز دارید → #Hazelcast را در نظر بگیرید.
در کنار همه این گزینه‌ها، #Kvrocks هم حرفهای زیادی برای گفتن دارد. این دیتابیس که با #C++ و #Go ساخته شده، از RocksDB به‌عنوان موتور ذخیره‌سازی استفاده می‌کند؛ یعنی به جای اینکه همه چیز را فقط در حافظه RAM نگه دارد مثل #Redis، می‌تواند داده‌های بزرگ را روی دیسک ذخیره و مدیریت کند 📀. این کار باعث می‌شود ظرفیت خیلی بیشتری با هزینه کمتر داشته باشید، بدون اینکه از مزیت سرعت زیاد و سازگاری کامل با پروتکل Redis دست بکشید. 🚀
رقابت تازه شروع شده است 🚀. #Redis هنوز پادشاه دنیای پایگاه داده‌های درون‌حافظه‌ای است، اما حالا باید برای حفظ جایگاهش بیشتر تلاش کند. برای ما مهندسان نرم‌افزار، این یعنی گزینه‌های بیشتر، آزادی انتخاب بالاتر و آینده‌ای پر از نوآوری.
در دنیای فناوری، حتی محبوب‌ترین ابزارها هم برای ادامه مسیر به رقیب نیاز دارند. همان‌طور که در حوزه پردازش جریان، ظهور #Redpanda و #AutoMQ باعث شد سطح انتظارات از شرکت Confluent و حتی بنیاد آپاچی برای گسترش امکانات #Kafka بالا برود، حالا نوبت #Redis است که با چالش‌های تازه روبه‌رو شود.
ردیس سال‌هاست به‌عنوان یک پایگاه داده درون‌حافظه‌ای (In-Memory) سریع ⚡️، ساده و بی‌دردسر شناخته می‌شود. بسیاری از ما اولین تجربه کار با Cache، Session Storage یا حتی Pub/Sub را با همین ابزار داشته‌ایم. اما همین موفقیت و سادگی باعث شد که کمتر به سراغ گزینه‌های دیگر برویم… تا وقتی که یک مشکل واقعی سر راه‌مان سبز شود.
مشکل اول: استفاده ناکامل از CPU 🖥
ردیس ذاتاً تک‌ریسمانی است؛ یعنی هر چقدر هم CPU چند هسته‌ای داشته باشیم، در نهایت یک هسته درگیر پردازش می‌شود و بقیه بلااستفاده می‌مانند. وقتی حجم درخواست‌ها بالا برود، صف‌ها طولانی و تأخیرها بیشتر می‌شوند.
اینجاست که #KeyDB وارد میدان شد 💪. این ابزار در واقع نسخه‌ای از Redis است که یاد گرفته از چند هسته CPU همزمان استفاده کند. بدون تغییر در کد یا کتابخانه‌ها، می‌توانید با #KeyDB سرعتی چند برابر تجربه کنید.
مشکل دوم: هزینه بالای RAM 💸
هر کس #Redis را در مقیاس بزرگ استفاده کرده باشد، با مشکل مصرف زیاد حافظه آشناست. بخش زیادی از این مصرف به خاطر تکه‌تکه شدن و هدر رفتن فضای RAM است.
دیتابیس #Dragonfly دقیقاً برای حل همین مشکل ساخته شده 🐉. با معماری متفاوت و بسته‌بندی بهینه داده‌ها، می‌تواند تا یک‌سوم مصرف حافظه را کاهش دهد و همچنان سرعت بالایی ارائه کند. برای پروژه‌هایی با داده‌های کوچک اما بسیار زیاد – مثل ذخیره‌سازی میلیون‌ها سشن کاربر – #Dragonfly یک صرفه‌جویی واقعی در هزینه‌هاست.
مشکل سوم: تغییر لایسنس Redis 📜
تغییر لایسنس #Redis باعث شد بخشی از جامعه متن‌باز احساس کند آینده این پروژه دیگر کاملاً شفاف نیست. نتیجه این نگرانی، تولد #Valkey بود؛ یک فورک متن‌باز که با همان API و پروتکل Redis کار می‌کند اما بدون محدودیت‌های جدید لایسنس.
#Valkey از نظر فنی تفاوت بزرگی با Redis ندارد، اما برای کسانی که به دلایل حقوقی یا سیاست‌های سازمانی نمی‌توانند Redis را استفاده کنند، یک انتخاب امن و بی‌دردسر است.
مشکل چهارم: نیاز به توزیع‌شدگی واقعی 🌍
اگرچه Redis Cluster امکان مقیاس‌پذیری افقی را فراهم می‌کند، اما راه‌اندازی و نگهداری آن همیشه ساده نیست. #Hazelcast از روز اول برای توزیع‌شدگی طراحی شده و مدیریت داده بین چندین نود را به‌صورت خودکار انجام می‌دهد. این ویژگی آن را برای سیستم‌های بزرگ با نیاز واقعی به Cache توزیع‌شده جذاب می‌کند.(البته با پرداخت هزینه)
کدام را انتخاب کنیم؟ 🎯
اگر مشکل کارایی ندارید → #Redis بهترین انتخاب است.
📌اگر گلوگاه CPU دارید و می‌خواهید با کمترین تغییر سرعت بگیرید → #KeyDB را انتخاب کنید.
📌اگر هزینه RAM سنگین شده → #Dragonfly می‌تواند نجات‌بخش باشد.
📌اگر لایسنس برایتان مسئله است → #Valkey جایگزین امنی است.
📌اگر از ابتدا به یک Cache توزیع‌شده و سازمانی نیاز دارید → #Hazelcast را در نظر بگیرید.
در کنار همه این گزینه‌ها، #Kvrocks هم حرفهای زیادی برای گفتن دارد. این دیتابیس که با #C++ و #Go ساخته شده، از RocksDB به‌عنوان موتور ذخیره‌سازی استفاده می‌کند؛ یعنی به جای اینکه همه چیز را فقط در حافظه RAM نگه دارد مثل #Redis، می‌تواند داده‌های بزرگ را روی دیسک ذخیره و مدیریت کند 📀. این کار باعث می‌شود ظرفیت خیلی بیشتری با هزینه کمتر داشته باشید، بدون اینکه از مزیت سرعت زیاد و سازگاری کامل با پروتکل Redis دست بکشید. 🚀
رقابت تازه شروع شده است 🚀. #Redis هنوز پادشاه دنیای پایگاه داده‌های درون‌حافظه‌ای است، اما حالا باید برای حفظ جایگاهش بیشتر تلاش کند. برای ما مهندسان نرم‌افزار، این یعنی گزینه‌های بیشتر، آزادی انتخاب بالاتر و آینده‌ای پر از نوآوری.
👍6
چرا هر مهندس داده‌ای باید Bloom Filter را بشناسد؟
با افزایش حجم داده‌ها و نیاز به پردازش سریع، الگوریتم‌های احتمالاتی زیادی در حوزه زیرساخت داده شکل گرفته‌اند و #Bloom Filter یکی از ساده‌ترین و رایج‌ترین آن‌هاست.
⚠️مشکل چیست؟ تصور کنید در یک سیستم ثبت‌نام کاربران، هر بار که کاربری ایمیل جدیدی وارد می‌کند، باید بررسی کنید که آیا این ایمیل قبلاً ثبت شده یا نه. اگر میلیون‌ها رکورد ایمیل داشته باشید، نگهداری همهٔ آن‌ها در حافظه یا جستجوی مداوم در پایگاه داده بسیار پرهزینه و کند است. یا در پایگاه‌های داده توزیع‌شده و سیستم‌های استریمینگ، قبل از #join کردن داده‌ها یا پردازش رکوردها، باید بررسی شود که رکورد مربوطه واقعاً وجود دارد یا خیر — عملیات مستقیم روی تمام داده‌ها بسیار زمان‌بر و منابع‌بر است.
اینجاست که بلوم فیلتر وارد می‌شود: یک میانبر هوشمند و کم‌هزینه که می‌تواند سریع بگوید «این عنصر قطعاً وجود ندارد» یا «احتمالاً وجود دارد». این پاسخ‌ها کافی است تا بسیاری از عملیات پردازشی بهینه شوند.
بلوم فیلتر یک ساختار داده احتمالاتی است که با استفاده از آرایه بیتی و چند تابع هش، عضویت را با حافظه کم بررسی می‌کند.
🔹 ایدهٔ ساده : نقشه بیتی و هش‌ها 🧭
📌یک آرایهٔ بیتی ایجاد میکنیم، با مقدار اولیه صفر برای همه عناصر
📌هر عنصر (مثلاً یک ایمیل) با k تابع هش مشخص به k موقعیت در آرایه نگاشت می‌شود و آن بیت‌ها یک می‌شوند.
📌بررسی وجود یک عنصر:
- اگر حتی یکی از بیت‌ها صفر باشد → قطعاً موجود نیست
- اگر همه بیت‌ها یک باشند → احتمالاً موجوداست (ممکن است مثبت کاذب باشد)
💡 این معاملهٔ ساده بین حافظه و دقت، کل قدرت بلوم فیلتر است.
🔹 یک مثال ساده 🍎🍌
- آرایه ۸ بیتی: [0,0,0,0,0,0,0,0] را به عنوان آرایه اصلی و مرجع بلوم فیلتر انتخاب میکنیم.
- افزودن "apple"← بیت‌های 1,3,5 توسط سه تابع هش تولید می‌شوند بنابراین این خانه ها را برابر یک می گذاریم ← [0,1,0,1,0,1,0,0]
- افزودن "banana"←بیت‌های 2,3,6 ← [0,1,1,1,0,1,1,0]
- بررسی "cherry" ← تابع هش سه عدد 1،3،7 تولید می‌کند. بیت شماره 7 برابر 0 است ← پس "cherry" قطعاً وجود ندارد.
- بررسی "apple"← تمام بیت‌های تولید شده برابر ۱ هستند ← "apple" احتمالاً وجود دارد.
🔹 نکات فنی کلیدی ⚙️
✅ هیچ منفی کاذبی وجود ندارد (اگر فیلتر درست نگهداری شود و هش‌ها ثابت باشند).
✅ ممکن است مثبت کاذب داشته باشیم، نرخ آن با اندازه آرایه و تعداد توابع هش قابل کنترل است.
✅ برای پشتیبانی از حذف عناصر و شمارش هر عضو، باید از Counting #Bloom Filter یا Cuckoo Filter استفاده کنیم.
✅ فقط برای Membership Test کاربرد دارد، بازیابی داده یا شمارش تکرار را انجام نمی‌دهد.
✅ انتخاب مناسب آرایه و تعداد توابع هش کلیدی است تا حافظه و دقت بهینه شود.
🧠 کاربردهای عملی در مهندسی داده
🎯پایگاه‌های داده توزیع‌شده: در سیستم‌هایی مانند Cassandra برای کاهش تعداد خواندن‌های غیرضروری دیسک و ترافیک شبکه استفاده می‌شود.
🎯پردازش فایل‌های پارکت: بلوم فیلترها به کاهش زمان کوئری‌ها کمک می‌کنند. در Apache #Parquet، می‌توانند زمان کوئری‌ها را به طور چشمگیری کاهش دهند.
🎯سیستم‌های کش: در Redis و سیستم‌های مشابه برای بررسی سریع وجود یا عدم وجود داده‌ها استفاده می‌شوند.
🎯سیستم‌های توزیع‌شده: جلوگیری از ارسال درخواست‌های تکراری به نودهای مختلف
🔹 جمع‌بندی 📚
بلوم فیلتر با طراحی ساده اما هوشمندانه، ابزاری قدرتمند برای مدیریت داده‌های بزرگ است. فهم ایدهٔ پشت بلوم فیلتر به ما کمک می‌کند تصمیمات هوشمندانه‌تری بگیریم و بدانیم در کجاها می‌توانیم از این ابزار ساده اما کاربردی استفاده کنیم.
با افزایش حجم داده‌ها و نیاز به پردازش سریع، الگوریتم‌های احتمالاتی زیادی در حوزه زیرساخت داده شکل گرفته‌اند و #Bloom Filter یکی از ساده‌ترین و رایج‌ترین آن‌هاست.
⚠️مشکل چیست؟ تصور کنید در یک سیستم ثبت‌نام کاربران، هر بار که کاربری ایمیل جدیدی وارد می‌کند، باید بررسی کنید که آیا این ایمیل قبلاً ثبت شده یا نه. اگر میلیون‌ها رکورد ایمیل داشته باشید، نگهداری همهٔ آن‌ها در حافظه یا جستجوی مداوم در پایگاه داده بسیار پرهزینه و کند است. یا در پایگاه‌های داده توزیع‌شده و سیستم‌های استریمینگ، قبل از #join کردن داده‌ها یا پردازش رکوردها، باید بررسی شود که رکورد مربوطه واقعاً وجود دارد یا خیر — عملیات مستقیم روی تمام داده‌ها بسیار زمان‌بر و منابع‌بر است.
اینجاست که بلوم فیلتر وارد می‌شود: یک میانبر هوشمند و کم‌هزینه که می‌تواند سریع بگوید «این عنصر قطعاً وجود ندارد» یا «احتمالاً وجود دارد». این پاسخ‌ها کافی است تا بسیاری از عملیات پردازشی بهینه شوند.
بلوم فیلتر یک ساختار داده احتمالاتی است که با استفاده از آرایه بیتی و چند تابع هش، عضویت را با حافظه کم بررسی می‌کند.
🔹 ایدهٔ ساده : نقشه بیتی و هش‌ها 🧭
📌یک آرایهٔ بیتی ایجاد میکنیم، با مقدار اولیه صفر برای همه عناصر
📌هر عنصر (مثلاً یک ایمیل) با k تابع هش مشخص به k موقعیت در آرایه نگاشت می‌شود و آن بیت‌ها یک می‌شوند.
📌بررسی وجود یک عنصر:
- اگر حتی یکی از بیت‌ها صفر باشد → قطعاً موجود نیست
- اگر همه بیت‌ها یک باشند → احتمالاً موجوداست (ممکن است مثبت کاذب باشد)
💡 این معاملهٔ ساده بین حافظه و دقت، کل قدرت بلوم فیلتر است.
🔹 یک مثال ساده 🍎🍌
- آرایه ۸ بیتی: [0,0,0,0,0,0,0,0] را به عنوان آرایه اصلی و مرجع بلوم فیلتر انتخاب میکنیم.
- افزودن "apple"← بیت‌های 1,3,5 توسط سه تابع هش تولید می‌شوند بنابراین این خانه ها را برابر یک می گذاریم ← [0,1,0,1,0,1,0,0]
- افزودن "banana"←بیت‌های 2,3,6 ← [0,1,1,1,0,1,1,0]
- بررسی "cherry" ← تابع هش سه عدد 1،3،7 تولید می‌کند. بیت شماره 7 برابر 0 است ← پس "cherry" قطعاً وجود ندارد.
- بررسی "apple"← تمام بیت‌های تولید شده برابر ۱ هستند ← "apple" احتمالاً وجود دارد.
🔹 نکات فنی کلیدی ⚙️
✅ هیچ منفی کاذبی وجود ندارد (اگر فیلتر درست نگهداری شود و هش‌ها ثابت باشند).
✅ ممکن است مثبت کاذب داشته باشیم، نرخ آن با اندازه آرایه و تعداد توابع هش قابل کنترل است.
✅ برای پشتیبانی از حذف عناصر و شمارش هر عضو، باید از Counting #Bloom Filter یا Cuckoo Filter استفاده کنیم.
✅ فقط برای Membership Test کاربرد دارد، بازیابی داده یا شمارش تکرار را انجام نمی‌دهد.
✅ انتخاب مناسب آرایه و تعداد توابع هش کلیدی است تا حافظه و دقت بهینه شود.
🧠 کاربردهای عملی در مهندسی داده
🎯پایگاه‌های داده توزیع‌شده: در سیستم‌هایی مانند Cassandra برای کاهش تعداد خواندن‌های غیرضروری دیسک و ترافیک شبکه استفاده می‌شود.
🎯پردازش فایل‌های پارکت: بلوم فیلترها به کاهش زمان کوئری‌ها کمک می‌کنند. در Apache #Parquet، می‌توانند زمان کوئری‌ها را به طور چشمگیری کاهش دهند.
🎯سیستم‌های کش: در Redis و سیستم‌های مشابه برای بررسی سریع وجود یا عدم وجود داده‌ها استفاده می‌شوند.
🎯سیستم‌های توزیع‌شده: جلوگیری از ارسال درخواست‌های تکراری به نودهای مختلف
🔹 جمع‌بندی 📚
بلوم فیلتر با طراحی ساده اما هوشمندانه، ابزاری قدرتمند برای مدیریت داده‌های بزرگ است. فهم ایدهٔ پشت بلوم فیلتر به ما کمک می‌کند تصمیمات هوشمندانه‌تری بگیریم و بدانیم در کجاها می‌توانیم از این ابزار ساده اما کاربردی استفاده کنیم.
👍3
آغاز به کار رسمی مدرسه مهندسی داده سپهرام
با افتخار اعلام میکنم که وب‌سایت https://sepahram.ir به عنوان اولین مدرسه کاربردی مهندسی داده در ایران راه‌اندازی شد. هدف ما ارائه آموزش‌های عملی و پروژه‌محور در حوزه #مهندسی_داده برای جامعه فارسی‌زبان است.
🔰 شروع فعالیت مدرسه با برگزاری دوره نوین:
✨ مبانی مهندسی داده ✨
در این دوره، مفاهیم پایه و ابزارهای اصلی مهندسی داده به شکلی کاملاً عملی آموزش داده می‌شود، شامل:
🗄 پایگاه داده‌ها و طراحی اولیه با #PostgreSQL
🛠 آشنایی با #Airflow برای مدیریت و زمان‌بندی جریان‌های داده
⚡️ پردازش داده‌های عظیم با #ApacheSpark
🔄 پردازش جریان‌های داده در #Kafka
📊 آشنایی عملیاتی با #ClickHouse برای تحلیل سریع و بلادرنگ داده‌ها
🧊 کار با #ApacheIceberg به عنوان نسل جدید فرمت‌های جدولی و مدیریت داده در مقیاس بزرگ
🎯 برای تضمین یادگیری گام‌به‌گام و مؤثر:
- هر درس شامل چند آزمون کوتاه و مفهومی است.
- برای دریافت گواهینامه پایان دوره، انجام و تحویل یک پروژه عملی و کاربردی الزامی است. جزئیات این پروژه در صفحه دوره ذکر شده است.
💬 در صورت بروز مشکل در مسیر آموزشی یا هنگام انجام آزمون‌ها، می‌توانید از طریق پیام‌رسان‌های تلگرام، واتساپ یا بله با حساب پشتیبانی مدرسه مهندسی داده سپهرام در ارتباط باشید:
📌 شناسه پشتیبانی: @sepahram_ir
🙌 به عنوان موسس و مدرس اصلی این مدرسه، امیدوارم سپهرام گامی مؤثر در جهت توانمندسازی جامعه فارسی‌زبان در مسیر حرفهای مهندسی داده باشد.
🔗 جزئیات بیشتر و ثبت‌نام:
https://sepahram.ir/courses/intro-to-data-engineering
کانال رسمی سپهرام :
https://t.iss.one/sepahram_school
با افتخار اعلام میکنم که وب‌سایت https://sepahram.ir به عنوان اولین مدرسه کاربردی مهندسی داده در ایران راه‌اندازی شد. هدف ما ارائه آموزش‌های عملی و پروژه‌محور در حوزه #مهندسی_داده برای جامعه فارسی‌زبان است.
🔰 شروع فعالیت مدرسه با برگزاری دوره نوین:
✨ مبانی مهندسی داده ✨
در این دوره، مفاهیم پایه و ابزارهای اصلی مهندسی داده به شکلی کاملاً عملی آموزش داده می‌شود، شامل:
🗄 پایگاه داده‌ها و طراحی اولیه با #PostgreSQL
🛠 آشنایی با #Airflow برای مدیریت و زمان‌بندی جریان‌های داده
⚡️ پردازش داده‌های عظیم با #ApacheSpark
🔄 پردازش جریان‌های داده در #Kafka
📊 آشنایی عملیاتی با #ClickHouse برای تحلیل سریع و بلادرنگ داده‌ها
🧊 کار با #ApacheIceberg به عنوان نسل جدید فرمت‌های جدولی و مدیریت داده در مقیاس بزرگ
🎯 برای تضمین یادگیری گام‌به‌گام و مؤثر:
- هر درس شامل چند آزمون کوتاه و مفهومی است.
- برای دریافت گواهینامه پایان دوره، انجام و تحویل یک پروژه عملی و کاربردی الزامی است. جزئیات این پروژه در صفحه دوره ذکر شده است.
💬 در صورت بروز مشکل در مسیر آموزشی یا هنگام انجام آزمون‌ها، می‌توانید از طریق پیام‌رسان‌های تلگرام، واتساپ یا بله با حساب پشتیبانی مدرسه مهندسی داده سپهرام در ارتباط باشید:
📌 شناسه پشتیبانی: @sepahram_ir
🙌 به عنوان موسس و مدرس اصلی این مدرسه، امیدوارم سپهرام گامی مؤثر در جهت توانمندسازی جامعه فارسی‌زبان در مسیر حرفهای مهندسی داده باشد.
🔗 جزئیات بیشتر و ثبت‌نام:
https://sepahram.ir/courses/intro-to-data-engineering
کانال رسمی سپهرام :
https://t.iss.one/sepahram_school
👍8
شروع ثبت‌نام دوره تخصصی Apache Airflow
مدرسه مهندسی داده سپهرام با هدف توانمندسازی متخصصان داده و ایجاد زیرساخت‌های حرفهای برای مدیریت جریان‌های کاری (Workflow Management)، دوره‌ای جامع و عملی از Apache Airflow برگزار می‌کند.
🎯 معرفی دوره
در عصر داده‌محور امروز، کافی نیست فقط داده داشته باشید؛ بلکه باید آن را در زمان درست، پاک، ساخت‌یافته و آماده استفاده در اختیار سیستم‌های تحلیلی و مدل‌های یادگیری ماشین قرار دهید. Apache Airflow به‌عنوان یکی از محبوب‌ترین ابزارهای متن‌باز در شرکت‌های بزرگ دنیا، استانداردی برای خودکارسازی و زمان‌بندی جریان‌های کاری داده محسوب می‌شود.
این دوره در مدت ۴ هفته (۱۰ جلسه – ۲۰ ساعت) برگزار می‌شود و شما را از مفاهیم پایه تا طراحی و پیاده‌سازی پایپ‌لاین‌های داده پیشرفته همراهی می‌کند.
📌 جزئیات دوره
👤 سطح: متوسط تا پیشرفته
⏱️ مدت: ۲۰ ساعت (۴ هفته – ۱۰ جلسه)
📌 پیش‌نیاز: آشنایی مقدماتی با Python و Docker
🗓 شروع: پنج‌شنبه ۶ شهریور ۱۴۰۴
👥 ظرفیت: ۳۰ نفر
🆔 کد دوره: ۲۰۱
🕒 زمان برگزاری:
یک‌شنبه‌ها: ۲۰ تا ۲۲
پنج‌شنبه‌ها: ۹ تا ۱۳
🎓 گواهینامه معتبر (با انجام پروژه عملی و پرداخت جداگانه)
🧩 سرفصل‌ها (پروژه‌محور و عملی):
- مقدمه، معماری Airflow و اجرای یک پروژه مقدماتی با N8N
- نصب و راه‌اندازی Airflow (لوکال و Docker)، ساخت اولین DAG عملیاتی
- کار با Variables، XCom، Sensors، Connections
- مدیریت اجرای DAGها: Retry، Backfill، Pools، تخصیص منابع
- طراحی DAGهای پویا: Dynamic Tasks، TaskFlow API، Scheduling پیشرفته
- اجرای تسک‌ها با DockerOperator، KubernetesPodOperator، Ray Executor
- توسعه ماژولار: Custom Operator، Plugins، Logging، RBAC، Metrics، Prometheus/Grafana
- کارگاه عملی: یکپارچه‌سازی با Kafka، OpenAI، Postgres، MinIO
- آشنایی عملی با جایگزین‌های Airflow: Prefect، Kestra، Flyte، Dagster، Mage.ai
💡 اگر می‌خواهید ETLها و پایپ‌لاین‌های داده شما همیشه سر وقت، بدون خطا و با مانیتورینگ کامل اجرا شوند، این دوره بهترین نقطه شروع است.
📩 همین امروز ثبت‌نام کنید : دوره ایرفلو
کانال تلگرام مدرسه مهندسی داده سپهرام : @sepahram_school
مدرسه مهندسی داده سپهرام با هدف توانمندسازی متخصصان داده و ایجاد زیرساخت‌های حرفهای برای مدیریت جریان‌های کاری (Workflow Management)، دوره‌ای جامع و عملی از Apache Airflow برگزار می‌کند.
این دوره شما را از کارهای تکراری و دستی نجات می‌دهد و وارد دنیای حرفهای اتوماسیون پایپ‌لاین‌های داده می‌کند. از طراحی DAGهای ساده تا ساخت جریان‌های پیچیده با Dynamic Tasks، Event-Based Scheduling، اتصال به سرویس‌های ابری، پایگاه داده‌ها و ابزارهایی مثل Kafka و MinIO را در این دوره به‌صورت پروژه‌محور تجربه خواهید کرد.
🎯 معرفی دوره
در عصر داده‌محور امروز، کافی نیست فقط داده داشته باشید؛ بلکه باید آن را در زمان درست، پاک، ساخت‌یافته و آماده استفاده در اختیار سیستم‌های تحلیلی و مدل‌های یادگیری ماشین قرار دهید. Apache Airflow به‌عنوان یکی از محبوب‌ترین ابزارهای متن‌باز در شرکت‌های بزرگ دنیا، استانداردی برای خودکارسازی و زمان‌بندی جریان‌های کاری داده محسوب می‌شود.
این دوره در مدت ۴ هفته (۱۰ جلسه – ۲۰ ساعت) برگزار می‌شود و شما را از مفاهیم پایه تا طراحی و پیاده‌سازی پایپ‌لاین‌های داده پیشرفته همراهی می‌کند.
📌 جزئیات دوره
👤 سطح: متوسط تا پیشرفته
⏱️ مدت: ۲۰ ساعت (۴ هفته – ۱۰ جلسه)
📌 پیش‌نیاز: آشنایی مقدماتی با Python و Docker
🗓 شروع: پنج‌شنبه ۶ شهریور ۱۴۰۴
👥 ظرفیت: ۳۰ نفر
🆔 کد دوره: ۲۰۱
🕒 زمان برگزاری:
یک‌شنبه‌ها: ۲۰ تا ۲۲
پنج‌شنبه‌ها: ۹ تا ۱۳
🎓 گواهینامه معتبر (با انجام پروژه عملی و پرداخت جداگانه)
🧩 سرفصل‌ها (پروژه‌محور و عملی):
- مقدمه، معماری Airflow و اجرای یک پروژه مقدماتی با N8N
- نصب و راه‌اندازی Airflow (لوکال و Docker)، ساخت اولین DAG عملیاتی
- کار با Variables، XCom، Sensors، Connections
- مدیریت اجرای DAGها: Retry، Backfill، Pools، تخصیص منابع
- طراحی DAGهای پویا: Dynamic Tasks، TaskFlow API، Scheduling پیشرفته
- اجرای تسک‌ها با DockerOperator، KubernetesPodOperator، Ray Executor
- توسعه ماژولار: Custom Operator، Plugins، Logging، RBAC، Metrics، Prometheus/Grafana
- کارگاه عملی: یکپارچه‌سازی با Kafka، OpenAI، Postgres، MinIO
- آشنایی عملی با جایگزین‌های Airflow: Prefect، Kestra، Flyte، Dagster، Mage.ai
💡 اگر می‌خواهید ETLها و پایپ‌لاین‌های داده شما همیشه سر وقت، بدون خطا و با مانیتورینگ کامل اجرا شوند، این دوره بهترین نقطه شروع است.
📩 همین امروز ثبت‌نام کنید : دوره ایرفلو
کانال تلگرام مدرسه مهندسی داده سپهرام : @sepahram_school
شروع ثبت‌نام دوره تخصصی ClickHouse
مدرسه مهندسی داده سپهرام با هدف رواج و گسترش ابزارهای موردنیاز برای کسب‌وکارهای کوچک و سازمانی، دوره‌ای تخصصی و کاملاً عملی برای آشنایی و به‌کارگیری یکی از سریع‌ترین و محبوب‌ترین دیتابیس‌های تحلیلی دنیا یعنی ClickHouse برگزار می‌کند.
⚡️ چرا ClickHouse؟
در دنیای امروز که تحلیل داده در مقیاس بالا و نزدیک به زمان واقعی (Near Real-Time) مزیت رقابتی مهمی محسوب می‌شود، پایگاه‌های داده سنتی دیگر پاسخگو نیستند. ClickHouse به‌عنوان موتور تحلیلی فوق‌سریع (OLAP) می‌تواند کوئری‌های پیچیده را روی میلیاردها رکورد در کسری از ثانیه اجرا کند و در معماری‌های مدرن داده نقشی بی‌بدیل داشته باشد. هر چند روال کار دیتابیس‌های تحلیلی با دیتابیس‌های رابطه ای کمی متفاوت است و در این دوره سعی شده است زیر و بم این دیتابیس محبوب به صورت عملی و کاربردی، بررسی شود.
📚 مشخصات دوره جامع ClickHouse (کد: ۳۰۱)
👤 سطح: مقدماتی و متوسط
⏱️ مدت: ۱۸ ساعت
📌 پیش‌نیاز: آشنایی با SQL و Docker
🗓 شروع: پنج‌شنبه ۶ شهریور ۱۴۰۴
👥 ظرفیت: ۳۰ نفر
🕒 زمان برگزاری:
سه‌شنبه‌ها: ۲۰ تا ۲۲
پنج‌شنبه‌ها: ۱۴ تا ۱۸
🎓 امکان دریافت گواهینامه معتبر (با انجام پروژه عملی و پرداخت جداگانه)
🔍 سرفصل‌ها (کاملاً کاربردی):
- نصب و راه‌اندازی + معماری کلیک‌هوس
- طراحی بهینه جداول، ایندکس‌ها و Bloom Filter
- کوئری‌های پیشرفته SQL و clickhouse-local
- بهینه‌سازی پرس‌وجوها با Projection و MergeTree
- کار با داده‌های JSON، Map و Materialized View
- پردازش جریانی با Kafka Engine و glassflow
- مدیریت امنیت، RBAC، مانیتورینگ با Grafana
- پیاده‌سازی کلاسترهای توزیع‌شده (Sharding, Replication)
- مهاجرت داده و تیونینگ عملی با ابزارهای ETL
💡 اگر به‌دنبال ساخت موتورهای تحلیلی سریع و مقیاس‌پذیر برای پروژه‌های واقعی هستید، این دوره برای شماست.
📩 همین حالا برای ثبت‌نام اقدام کنید :
https://sepahram.ir/courses/clickhouse-201/
کانال تلگرام مدرسه مهندسی داده سپهرام : @sepahram_school
مدرسه مهندسی داده سپهرام با هدف رواج و گسترش ابزارهای موردنیاز برای کسب‌وکارهای کوچک و سازمانی، دوره‌ای تخصصی و کاملاً عملی برای آشنایی و به‌کارگیری یکی از سریع‌ترین و محبوب‌ترین دیتابیس‌های تحلیلی دنیا یعنی ClickHouse برگزار می‌کند.
این دوره به‌عنوان یکی از اولین برنامه‌های آموزشی مدرسه و بر اساس آخرین مفاهیم و محتوای رسمی ClickHouse طراحی شده و در اولویت ما برای انتقال دانش کاربردی به مهندسان داده قرار گرفته است.
⚡️ چرا ClickHouse؟
در دنیای امروز که تحلیل داده در مقیاس بالا و نزدیک به زمان واقعی (Near Real-Time) مزیت رقابتی مهمی محسوب می‌شود، پایگاه‌های داده سنتی دیگر پاسخگو نیستند. ClickHouse به‌عنوان موتور تحلیلی فوق‌سریع (OLAP) می‌تواند کوئری‌های پیچیده را روی میلیاردها رکورد در کسری از ثانیه اجرا کند و در معماری‌های مدرن داده نقشی بی‌بدیل داشته باشد. هر چند روال کار دیتابیس‌های تحلیلی با دیتابیس‌های رابطه ای کمی متفاوت است و در این دوره سعی شده است زیر و بم این دیتابیس محبوب به صورت عملی و کاربردی، بررسی شود.
📚 مشخصات دوره جامع ClickHouse (کد: ۳۰۱)
👤 سطح: مقدماتی و متوسط
⏱️ مدت: ۱۸ ساعت
📌 پیش‌نیاز: آشنایی با SQL و Docker
🗓 شروع: پنج‌شنبه ۶ شهریور ۱۴۰۴
👥 ظرفیت: ۳۰ نفر
🕒 زمان برگزاری:
سه‌شنبه‌ها: ۲۰ تا ۲۲
پنج‌شنبه‌ها: ۱۴ تا ۱۸
🎓 امکان دریافت گواهینامه معتبر (با انجام پروژه عملی و پرداخت جداگانه)
🔍 سرفصل‌ها (کاملاً کاربردی):
- نصب و راه‌اندازی + معماری کلیک‌هوس
- طراحی بهینه جداول، ایندکس‌ها و Bloom Filter
- کوئری‌های پیشرفته SQL و clickhouse-local
- بهینه‌سازی پرس‌وجوها با Projection و MergeTree
- کار با داده‌های JSON، Map و Materialized View
- پردازش جریانی با Kafka Engine و glassflow
- مدیریت امنیت، RBAC، مانیتورینگ با Grafana
- پیاده‌سازی کلاسترهای توزیع‌شده (Sharding, Replication)
- مهاجرت داده و تیونینگ عملی با ابزارهای ETL
💡 اگر به‌دنبال ساخت موتورهای تحلیلی سریع و مقیاس‌پذیر برای پروژه‌های واقعی هستید، این دوره برای شماست.
📩 همین حالا برای ثبت‌نام اقدام کنید :
https://sepahram.ir/courses/clickhouse-201/
کانال تلگرام مدرسه مهندسی داده سپهرام : @sepahram_school
👍3
آشنایی با Temporal.io
امروز در لینکدین پستی منتشر شد درباره‌ی مزایای Temporal.io و نقاط قوت آن در مقایسه با Apache Airflow.
این یادداشت را به عنوان تکمیل همان تجربه آماده کرده ایم.
بیایید ابتدا مشکلاتی که برای کاربر در استفاده از Airflow پیش آمده بود را مرور کنیم :
🔹 چالش‌های Airflow در عمل
هرچند Airflow یک ابزار شناخته‌شده و استاندارد برای مدیریت ETL و پردازش دسته‌ای است، اما در سناریوهای پیچیده‌تر محدودیت‌هایی ایجاد می‌کند:
⚠️ماهیت Syncronous بودن بسیاری از Operatorها: اجرای Async در Airflow نیازمند طراحی جداگانه یا اپراتورهای سفارشی است و برای کار با APIهای Async ساده نیست.
⚠️مقیاس‌پذیری و مدیریت منابع: کلاسترکردن Executorها و مدیریت منابع در Airflow به‌ویژه در مقیاس بزرگ، پیچیدگی و سربار بالایی ایجاد می‌کند.
⚠️زمان‌بندی و Triggerها: هرچند می‌توان از طریق API یا Sensorها جریان‌ها را کنترل کرد، اما پیاده‌سازی شرط‌های پویا و وابستگی به رویدادها (Event-driven) نسبتاً دشوار است.
⚠️مدیریت خطا و Retry: Airflow قابلیت Retry دارد اما نسبتاً ساده است. استراتژی‌های پیچیده‌تر مانند backoff نمایی، timeout چندلایه یا مدیریت خطا در سطح گام‌های طولانی‌مدت نیاز به کدنویسی و کنترل دستی دارد.
⚠️تعامل انسانی (Human-in-the-Loop): Airflow به‌طور بومی امکان دخالت کاربر انسانی در میانه‌ی یک DAG را ندارد و چنین قابلیتی باید با توسعه‌ی خارجی یا ترکیب ابزارهای دیگر پیاده شود.
💡 مزایای Temporal در این زمینه
تمپورال رویکرد متفاوتی دارد: به جای تعریف DAG در پایتون، گردش‌های کاری را به شکل کد در زبان‌های مختلف پیاده‌سازی می‌کنید و هسته‌ی آن به‌صورت durable execution تضمین می‌کند که هیچ فعالیتی در اثر خطا یا قطعی از بین نرود. برخی نقاط قوت آن:
✅ پشتیبانی چندزبانه (Polyglot SDKs): تیم‌ها می‌توانند در زبان‌های مختلف (Go, Python, TypeScript, Java و ...) Workflow و Activity بنویسند و در یک سیستم یکپارچه اجرا کنند.
✅ Async-first: معماری Temporal از پایه برای پردازش Async طراحی شده و برخلاف Airflow، نیاز به اپراتورهای خاص یا راه‌حل‌های سفارشی ندارد.
✅ مقیاس‌پذیری بالا: توانایی اجرای میلیون‌ها Workflow در ثانیه، با معماری مقاوم و پشتیبانی از دیتابیس‌های مختلف (Postgres, MySQL, Cassandra و ElasticSearch).
✅ امکان Retry و Error Handling پیشرفته: مدیریت خطا، Retry خودکار با استراتژی‌های متنوع، timeoutهای چندلایه و تضمین اجرای دقیق (exactly-once execution) از ویژگی‌های بومی Temporal است.
✅ قابلیت متمایز و مهم Human-in-the-Loop: از طریق Signalها و Queryها می‌توان تعامل انسانی را به‌راحتی درون Workflow قرار داد (برای مثال تأیید یا رد یک مرحله).
✅ رویکرد Event-driven بودن واقعی: Workflowها می‌توانند توسط سیگنال‌ها یا رویدادهای بیرونی شروع و کنترل شوند؛ چیزی که در Airflow محدودتر و پیچیده‌تر است.
✅ راه اندازی ساده و امکان تعریف ورک‌فلو با زبان‌های مختلف
🔹 کجا Airflow و کجا Temporal؟
🎯اگر پروژه‌ی شما بیشتر شامل ETL دسته‌ای و پردازش‌های دوره‌ای است، Airflow همچنان یک ابزار استاندارد و مناسب است.
🎯اگر به جریان‌های کاری طولانی‌مدت، مقاوم در برابر خطا، پویا و قابل تعامل با انسان نیاز دارید یا تیم‌های چندزبانه روی یک پلتفرم مشترک کار می‌کنند، Temporal انتخاب قدرتمندتری است.
کانال مدرسه مهندسی داده سپهرام : @sepahram_school
امروز در لینکدین پستی منتشر شد درباره‌ی مزایای Temporal.io و نقاط قوت آن در مقایسه با Apache Airflow.
این یادداشت را به عنوان تکمیل همان تجربه آماده کرده ایم.
بیایید ابتدا مشکلاتی که برای کاربر در استفاده از Airflow پیش آمده بود را مرور کنیم :
🔹 چالش‌های Airflow در عمل
هرچند Airflow یک ابزار شناخته‌شده و استاندارد برای مدیریت ETL و پردازش دسته‌ای است، اما در سناریوهای پیچیده‌تر محدودیت‌هایی ایجاد می‌کند:
⚠️ماهیت Syncronous بودن بسیاری از Operatorها: اجرای Async در Airflow نیازمند طراحی جداگانه یا اپراتورهای سفارشی است و برای کار با APIهای Async ساده نیست.
⚠️مقیاس‌پذیری و مدیریت منابع: کلاسترکردن Executorها و مدیریت منابع در Airflow به‌ویژه در مقیاس بزرگ، پیچیدگی و سربار بالایی ایجاد می‌کند.
⚠️زمان‌بندی و Triggerها: هرچند می‌توان از طریق API یا Sensorها جریان‌ها را کنترل کرد، اما پیاده‌سازی شرط‌های پویا و وابستگی به رویدادها (Event-driven) نسبتاً دشوار است.
⚠️مدیریت خطا و Retry: Airflow قابلیت Retry دارد اما نسبتاً ساده است. استراتژی‌های پیچیده‌تر مانند backoff نمایی، timeout چندلایه یا مدیریت خطا در سطح گام‌های طولانی‌مدت نیاز به کدنویسی و کنترل دستی دارد.
⚠️تعامل انسانی (Human-in-the-Loop): Airflow به‌طور بومی امکان دخالت کاربر انسانی در میانه‌ی یک DAG را ندارد و چنین قابلیتی باید با توسعه‌ی خارجی یا ترکیب ابزارهای دیگر پیاده شود.
💡 مزایای Temporal در این زمینه
تمپورال رویکرد متفاوتی دارد: به جای تعریف DAG در پایتون، گردش‌های کاری را به شکل کد در زبان‌های مختلف پیاده‌سازی می‌کنید و هسته‌ی آن به‌صورت durable execution تضمین می‌کند که هیچ فعالیتی در اثر خطا یا قطعی از بین نرود. برخی نقاط قوت آن:
✅ پشتیبانی چندزبانه (Polyglot SDKs): تیم‌ها می‌توانند در زبان‌های مختلف (Go, Python, TypeScript, Java و ...) Workflow و Activity بنویسند و در یک سیستم یکپارچه اجرا کنند.
✅ Async-first: معماری Temporal از پایه برای پردازش Async طراحی شده و برخلاف Airflow، نیاز به اپراتورهای خاص یا راه‌حل‌های سفارشی ندارد.
✅ مقیاس‌پذیری بالا: توانایی اجرای میلیون‌ها Workflow در ثانیه، با معماری مقاوم و پشتیبانی از دیتابیس‌های مختلف (Postgres, MySQL, Cassandra و ElasticSearch).
✅ امکان Retry و Error Handling پیشرفته: مدیریت خطا، Retry خودکار با استراتژی‌های متنوع، timeoutهای چندلایه و تضمین اجرای دقیق (exactly-once execution) از ویژگی‌های بومی Temporal است.
✅ قابلیت متمایز و مهم Human-in-the-Loop: از طریق Signalها و Queryها می‌توان تعامل انسانی را به‌راحتی درون Workflow قرار داد (برای مثال تأیید یا رد یک مرحله).
✅ رویکرد Event-driven بودن واقعی: Workflowها می‌توانند توسط سیگنال‌ها یا رویدادهای بیرونی شروع و کنترل شوند؛ چیزی که در Airflow محدودتر و پیچیده‌تر است.
✅ راه اندازی ساده و امکان تعریف ورک‌فلو با زبان‌های مختلف
🔹 کجا Airflow و کجا Temporal؟
🎯اگر پروژه‌ی شما بیشتر شامل ETL دسته‌ای و پردازش‌های دوره‌ای است، Airflow همچنان یک ابزار استاندارد و مناسب است.
🎯اگر به جریان‌های کاری طولانی‌مدت، مقاوم در برابر خطا، پویا و قابل تعامل با انسان نیاز دارید یا تیم‌های چندزبانه روی یک پلتفرم مشترک کار می‌کنند، Temporal انتخاب قدرتمندتری است.
کانال مدرسه مهندسی داده سپهرام : @sepahram_school
👍5
مهارت‌های ضروری یک فعال حوزه IT
مخاطب این پست بچه های فعال حوزه آیتی در بازه سنی 20 تا 30 سال...
میدونم خیلی از شمایی که این متن رو میخونید آینده کاری خودتون در حوزه آیتی رو یکم مبهم میبینید ، با فراگیر شدن و تجاری شدن هوش مصنوعی قطعاً مهارت های لازم برای ورود و رشد و توسعه در بازار کار تغییر کرده.
به عنوان آدمی که حداقل چند بار تجربه کارکردن خارج از کشور رو دارم و ترند 15 سال اخیر در حوزه دیتا و فناوری اطلاعات رو عمیقاً به خاطر شغلم دنبال کردم چند تا نکته رو میخوام توضیح بدم که دونستنش میتونه آینده کاریتون رو تغییر بده
1- مهمترین زبان برنامه نویسی که همه باید یادبگیرن نه پایتون، نه جاوا ، نا گو ... بلکه زبان انگلیسی !
خیلی خیلی زود بسیاری از مهارت های بیسیک حوزه آیتی زبان محور میشن، به عنوان یک برنامه نویس جونیور تسلط به زبان انگلیسی یعنی تعامل درست با استیک هولدرهای پروژه ، درک نیازهاشون و انتقال صحیحش به محیط کار ، ضمن اینکه زبان انگلیسی مهمترین منبع شما برای یادگیری فناوری خواهد بود. به شخصه اگر برگردم به گذشته زمانی که برای تحصیل تو دوره ارشد رو تلف کردم صرف یادگیری یه زبان جدید میکنم
2- صنعت آیتی به یک بازار Fast Fashion تغییر کرده
یعنی دیگه شرکتی که هدفش تولید یک محصول با سرمایه گذاری کلان در بازه زمانی 1 ساله باشه مرده ! الان سرعت تولید محصولات نرم افزاری به اندازه سرعت تغییر سلیقه مردم در حوزه مد و فشن بالاست پس تسلط شما به تولید مبتنی بر هوش مصنوعی که معادل است با سرعت چشمگیر در تولید نرم افزار اولویت اول کارفرماست تجربه شخصی خودم تولید کل Backend یک سامانه مدیریت ایمیل هوشمند مبتنی بر AI بوده که با بیش از 45 اندپوینت برای API Gateway از مرحله R&D تا مرحله Production فقط سه هفته طول کشید و قطعاً خودم اگر کسی قرار بود این کار رو 3 ماه طول بده استخدامش نمیکردم
3-به جای تمرکز بر فناوری به یادگیری بازار فناوری بپردازین ای کاش یه دوره اقتصاد دیجیتال برای بچه های آیتی برگزار میشد تا فرق محصول واقعی با استارت آپ توهمی رو کامل توضیح بده. به عنوان یک آیتی من باید بدونید چیزی که یک محصول رو با ارزش و قابل مصرف میکنه صرفاً هزینه، درآمد و جمع جبری این دوتاست نه قدرت بک اند و نه جذابیت فرانت اند.
4- یادگیری Cloud Computing واجب تر از نون شب.
باور کنید یا نه خارج از ایران کسی قرار نیست سرور در اختیار شما بذاره که کانفیگ کنید ، همه شرکت های دسترسی کلاد به گوگل، آمازون و مایکروسافت دارن ، همه سرویس ها روی کلاد توسعه داده شده، تقریباً هر فعالیتی که بخواید انجام بدین تهش میرسید به سرویس های ابری. عدم آشنایی برنامه نویس های ایرانی با محیط Cloud بزرگترین نقطه ضعفه ماست . میدونم به خاطر شرایط ایران امکان استفاده و تست رو نداریم ولی این مانع یادگیری از طریق یوتیوب و دوره های آنلاین نیست. رزومه ای که توش تسلط به کلاد نباشه درجا ریجکته
5-نفوذ عمقی به صنعت تخصصی
دنیای هوش مصنوعی بی نهایت بزرگه ، اینکه میبینید یکی تو پروفایلش نوشته دیتاساینتیست یا مهندس هوش مصنوعی قشنگه ولی در دنیای بیرون از لینکدین ازتون میپرسن دیتاساینتیست در چه حوزه ای ؟ ایکامرس، پزشکی، الکترونیک، گیم، فشن، مهندسی، راه و شهرسازی ، اقتصاد ، مالی ... بدون داشتن یه حوزه تخصص تجاری شما شبیه یه آچار با کله گرد هستین که معلوم نیست چه پیچی رو سفت میکنه به نظرم حتما تو یکی دو تا از حوزه های تجاری اطلاعات کسب کنید تا آدم های بفهمن شما رو برای چه کاری باید استخدام کنن برای من این مسیر همیشه بازاریابی و فروش بوده
متن و عکس از این پست لینکدین برداشته شده است:
https://www.linkedin.com/posts/zarvandeh_مخاطب-این-پست-بچه-های-فعال-حوزه-آیتی-در-بازه-activity-7364601996378574850-s2CD
کانال مدرسه مهندسی داده سپهرام : @sepahram_school
مخاطب این پست بچه های فعال حوزه آیتی در بازه سنی 20 تا 30 سال...
میدونم خیلی از شمایی که این متن رو میخونید آینده کاری خودتون در حوزه آیتی رو یکم مبهم میبینید ، با فراگیر شدن و تجاری شدن هوش مصنوعی قطعاً مهارت های لازم برای ورود و رشد و توسعه در بازار کار تغییر کرده.
به عنوان آدمی که حداقل چند بار تجربه کارکردن خارج از کشور رو دارم و ترند 15 سال اخیر در حوزه دیتا و فناوری اطلاعات رو عمیقاً به خاطر شغلم دنبال کردم چند تا نکته رو میخوام توضیح بدم که دونستنش میتونه آینده کاریتون رو تغییر بده
1- مهمترین زبان برنامه نویسی که همه باید یادبگیرن نه پایتون، نه جاوا ، نا گو ... بلکه زبان انگلیسی !
خیلی خیلی زود بسیاری از مهارت های بیسیک حوزه آیتی زبان محور میشن، به عنوان یک برنامه نویس جونیور تسلط به زبان انگلیسی یعنی تعامل درست با استیک هولدرهای پروژه ، درک نیازهاشون و انتقال صحیحش به محیط کار ، ضمن اینکه زبان انگلیسی مهمترین منبع شما برای یادگیری فناوری خواهد بود. به شخصه اگر برگردم به گذشته زمانی که برای تحصیل تو دوره ارشد رو تلف کردم صرف یادگیری یه زبان جدید میکنم
2- صنعت آیتی به یک بازار Fast Fashion تغییر کرده
یعنی دیگه شرکتی که هدفش تولید یک محصول با سرمایه گذاری کلان در بازه زمانی 1 ساله باشه مرده ! الان سرعت تولید محصولات نرم افزاری به اندازه سرعت تغییر سلیقه مردم در حوزه مد و فشن بالاست پس تسلط شما به تولید مبتنی بر هوش مصنوعی که معادل است با سرعت چشمگیر در تولید نرم افزار اولویت اول کارفرماست تجربه شخصی خودم تولید کل Backend یک سامانه مدیریت ایمیل هوشمند مبتنی بر AI بوده که با بیش از 45 اندپوینت برای API Gateway از مرحله R&D تا مرحله Production فقط سه هفته طول کشید و قطعاً خودم اگر کسی قرار بود این کار رو 3 ماه طول بده استخدامش نمیکردم
3-به جای تمرکز بر فناوری به یادگیری بازار فناوری بپردازین ای کاش یه دوره اقتصاد دیجیتال برای بچه های آیتی برگزار میشد تا فرق محصول واقعی با استارت آپ توهمی رو کامل توضیح بده. به عنوان یک آیتی من باید بدونید چیزی که یک محصول رو با ارزش و قابل مصرف میکنه صرفاً هزینه، درآمد و جمع جبری این دوتاست نه قدرت بک اند و نه جذابیت فرانت اند.
4- یادگیری Cloud Computing واجب تر از نون شب.
باور کنید یا نه خارج از ایران کسی قرار نیست سرور در اختیار شما بذاره که کانفیگ کنید ، همه شرکت های دسترسی کلاد به گوگل، آمازون و مایکروسافت دارن ، همه سرویس ها روی کلاد توسعه داده شده، تقریباً هر فعالیتی که بخواید انجام بدین تهش میرسید به سرویس های ابری. عدم آشنایی برنامه نویس های ایرانی با محیط Cloud بزرگترین نقطه ضعفه ماست . میدونم به خاطر شرایط ایران امکان استفاده و تست رو نداریم ولی این مانع یادگیری از طریق یوتیوب و دوره های آنلاین نیست. رزومه ای که توش تسلط به کلاد نباشه درجا ریجکته
5-نفوذ عمقی به صنعت تخصصی
دنیای هوش مصنوعی بی نهایت بزرگه ، اینکه میبینید یکی تو پروفایلش نوشته دیتاساینتیست یا مهندس هوش مصنوعی قشنگه ولی در دنیای بیرون از لینکدین ازتون میپرسن دیتاساینتیست در چه حوزه ای ؟ ایکامرس، پزشکی، الکترونیک، گیم، فشن، مهندسی، راه و شهرسازی ، اقتصاد ، مالی ... بدون داشتن یه حوزه تخصص تجاری شما شبیه یه آچار با کله گرد هستین که معلوم نیست چه پیچی رو سفت میکنه به نظرم حتما تو یکی دو تا از حوزه های تجاری اطلاعات کسب کنید تا آدم های بفهمن شما رو برای چه کاری باید استخدام کنن برای من این مسیر همیشه بازاریابی و فروش بوده
متن و عکس از این پست لینکدین برداشته شده است:
https://www.linkedin.com/posts/zarvandeh_مخاطب-این-پست-بچه-های-فعال-حوزه-آیتی-در-بازه-activity-7364601996378574850-s2CD
کانال مدرسه مهندسی داده سپهرام : @sepahram_school
Linkedin
مخاطب این پست بچه های فعال حوزه آیتی در بازه سنی 20 تا 30 سال...
میدونم خیلی از شمایی که این متن رو میخونید آینده کاری خودتون در…
میدونم خیلی از شمایی که این متن رو میخونید آینده کاری خودتون در…
مخاطب این پست بچه های فعال حوزه آیتی در بازه سنی 20 تا 30 سال...
میدونم خیلی از شمایی که این متن رو میخونید آینده کاری خودتون در حوزه آیتی رو یکم مبهم میبینید ، با فراگیر شدن و تجاری شدن هوش مصنوعی قطعاً مهارت های لازم برای ورود و رشد و توسعه در بازار کار…
میدونم خیلی از شمایی که این متن رو میخونید آینده کاری خودتون در حوزه آیتی رو یکم مبهم میبینید ، با فراگیر شدن و تجاری شدن هوش مصنوعی قطعاً مهارت های لازم برای ورود و رشد و توسعه در بازار کار…
❤2
Forwarded from مدرسه مهندسی داده سپهرام
نقشه راه مهندسی داده؛ چهار گام برای تبدیل شدن به یک مهندس داده حرفهای
امروز را وقت گذاشتم تا بر اساس تجربه‌ی بیش از ده سال فعالیت عملی و همچنین نیازمندی‌های بازار ایران و بر اساس ابزارهای متن‌باز، یک نقشه راه جامع برای مهندسی داده آماده کنم.
این مسیر به‌ویژه برای علاقه‌مندانی طراحی شده است که ممکن است از رشته‌هایی غیر از مهندسی نرم‌افزار یا علوم کامپیوتر وارد شوند. به همین دلیل، بخش ابتدایی آن شامل پیش‌نیازها و مهارت‌های پایه است تا بدانید قبل از شروع چه باید یاد بگیرید یا بهتر است داشته باشید.
🔹 گام اول: اصول اولیه - Foundations
این گام مربوط به پیش‌نیاز ورود به مهندسی داده است.
📌 پایتون عمیق: یادگیری پایتون فراتر از سطح مقدماتی؛ از برنامه‌نویسی شی‌گرا و ماژولار تا مباحث پیشرفته مثل async/await، decorators و context managers.
📌 اصول توسعه سرویس‌ها: آشنایی با REST و gRPC، سریالیزیشن (JSON/Protobuf/Avro)، امنیت و ساخت سرویس‌های پایدار.
📌 مبانی پردازش داده: کار با Pandas/Numpy/Polars، آشنایی با ابزارهای پردازش توزیع‌شده (مثل Celery/Daft) و حتی وب‌کراولینگ برای جمع‌آوری داده.
برای مشاهده جزییات این گام به این لینک مراجعه کنید
🔹 گام دوم: مبانی مهندسی داده
در این مرحله با کلیت ابزارها و معماری‌های اصلی آشنا می‌شویم و یک دید عملیاتی پیدا میکنیم.
📌 محیط توسعه و ابزارهای پایه: کار با لینوکس، خط فرمان و Docker.
📌 دیتابیس‌ها: یادگیری PostgreSQL و SQL در کنار آشنایی با انواع دیتابیس‌های NoSQL، ستونی، سری‌زمانی و برداری.
📌 مدیریت جریان داده: طراحی و اجرای pipelineها با ابزارهایی مثل Airflow، Prefect، Kafka و Spark.
🔹 گام سوم: عمیق شدن در مهندسی داده
اینجا وارد بخش جدی‌تر و تخصصی‌تر می‌شویم.
📌 دیتابیس‌های غیررابطه‌ای: کار عملی با MongoDB، Redis، Cassandra و Elasticsearch و Qdrant برای ذخیره‌سازی و بازیابی داده‌های متنوع.
📌 دیتابیس‌های تحلیلی و Lakehouse: تسلط بر ClickHouse، StarRocks، Doris و همچنین طراحی Lakehouse با MinIO و Open Table Formats مثل Apache Iceberg.
📌 پردازش جریان و ETL حرفهای: تسلط عملی بر Kafka و اکوسیستم آن، ابزارهای ETL/ELT (مثل dbt، Airbyte، Arroyo) و کار با دیتابیس‌های جریانی و پردازش توزیع‌شده.
🔹 گام چهارم: به سوی باشگاه حرفه‌ای‌ها
در این مرحله شما به سطحی میرسید که می‌توانید خود را یک مهندس داده حرفهای بدانید.
📌 استقرار مدرن سرویس‌ها: تسلط بر Kubernetes
📌 زیرساخت به‌عنوان کد (IaC): کار با Terraform، Ansible یا Pulumi.
📌 ابر داخلی و خارجی: آشنایی با AWS، Azure، Databricks، ستون و آروان برای طراحی زیرساخت‌های داده.
📌 عامل‌های هوشمند و MLOps : پیوند دادن داده با یادگیری ماشین (MLFlow) و استفاده از AI Agents برای پایش و اتوماسیون پایپ‌لاین‌ها.
📌 حاکمیت و کیفیت داده: آشنایی با اصول Data Governance و ابزارهایی مثل Great Expectations برای اطمینان از صحت و اعتمادپذیری داده.
✍️ در نهایت این مسیر چهارگانه به شما نشان می‌دهد از کجا شروع کنید، چگونه پیش بروید و در چه نقطه‌ای به مرحله‌ی حرفهای برسید.
🔗 نقشه راه : https://sepahram.ir/data-engineering-roadmap
امروز را وقت گذاشتم تا بر اساس تجربه‌ی بیش از ده سال فعالیت عملی و همچنین نیازمندی‌های بازار ایران و بر اساس ابزارهای متن‌باز، یک نقشه راه جامع برای مهندسی داده آماده کنم.
این مسیر به‌ویژه برای علاقه‌مندانی طراحی شده است که ممکن است از رشته‌هایی غیر از مهندسی نرم‌افزار یا علوم کامپیوتر وارد شوند. به همین دلیل، بخش ابتدایی آن شامل پیش‌نیازها و مهارت‌های پایه است تا بدانید قبل از شروع چه باید یاد بگیرید یا بهتر است داشته باشید.
🔹 گام اول: اصول اولیه - Foundations
این گام مربوط به پیش‌نیاز ورود به مهندسی داده است.
📌 پایتون عمیق: یادگیری پایتون فراتر از سطح مقدماتی؛ از برنامه‌نویسی شی‌گرا و ماژولار تا مباحث پیشرفته مثل async/await، decorators و context managers.
📌 اصول توسعه سرویس‌ها: آشنایی با REST و gRPC، سریالیزیشن (JSON/Protobuf/Avro)، امنیت و ساخت سرویس‌های پایدار.
📌 مبانی پردازش داده: کار با Pandas/Numpy/Polars، آشنایی با ابزارهای پردازش توزیع‌شده (مثل Celery/Daft) و حتی وب‌کراولینگ برای جمع‌آوری داده.
برای مشاهده جزییات این گام به این لینک مراجعه کنید
🔹 گام دوم: مبانی مهندسی داده
در این مرحله با کلیت ابزارها و معماری‌های اصلی آشنا می‌شویم و یک دید عملیاتی پیدا میکنیم.
📌 محیط توسعه و ابزارهای پایه: کار با لینوکس، خط فرمان و Docker.
📌 دیتابیس‌ها: یادگیری PostgreSQL و SQL در کنار آشنایی با انواع دیتابیس‌های NoSQL، ستونی، سری‌زمانی و برداری.
📌 مدیریت جریان داده: طراحی و اجرای pipelineها با ابزارهایی مثل Airflow، Prefect، Kafka و Spark.
🔹 گام سوم: عمیق شدن در مهندسی داده
اینجا وارد بخش جدی‌تر و تخصصی‌تر می‌شویم.
📌 دیتابیس‌های غیررابطه‌ای: کار عملی با MongoDB، Redis، Cassandra و Elasticsearch و Qdrant برای ذخیره‌سازی و بازیابی داده‌های متنوع.
📌 دیتابیس‌های تحلیلی و Lakehouse: تسلط بر ClickHouse، StarRocks، Doris و همچنین طراحی Lakehouse با MinIO و Open Table Formats مثل Apache Iceberg.
📌 پردازش جریان و ETL حرفهای: تسلط عملی بر Kafka و اکوسیستم آن، ابزارهای ETL/ELT (مثل dbt، Airbyte، Arroyo) و کار با دیتابیس‌های جریانی و پردازش توزیع‌شده.
🔹 گام چهارم: به سوی باشگاه حرفه‌ای‌ها
در این مرحله شما به سطحی میرسید که می‌توانید خود را یک مهندس داده حرفهای بدانید.
📌 استقرار مدرن سرویس‌ها: تسلط بر Kubernetes
📌 زیرساخت به‌عنوان کد (IaC): کار با Terraform، Ansible یا Pulumi.
📌 ابر داخلی و خارجی: آشنایی با AWS، Azure، Databricks، ستون و آروان برای طراحی زیرساخت‌های داده.
📌 عامل‌های هوشمند و MLOps : پیوند دادن داده با یادگیری ماشین (MLFlow) و استفاده از AI Agents برای پایش و اتوماسیون پایپ‌لاین‌ها.
📌 حاکمیت و کیفیت داده: آشنایی با اصول Data Governance و ابزارهایی مثل Great Expectations برای اطمینان از صحت و اعتمادپذیری داده.
✍️ در نهایت این مسیر چهارگانه به شما نشان می‌دهد از کجا شروع کنید، چگونه پیش بروید و در چه نقطه‌ای به مرحله‌ی حرفهای برسید.
🔗 نقشه راه : https://sepahram.ir/data-engineering-roadmap
❤7👍4🔥2
از دستیار کدنویس تا همکار هوشمند؛ از کابوس مستندسازی تا اتصال کدبیس دیوار به مدل‌های زبانی
ما در دیوار این هدف رو برای خودمون گذاشتیم که با استفاده از هوش مصنوعی، بهره‌وری مهندسی رو افزایش بدیم. در شروع سرویس‌های مکالمه‌محور مثل ChatGPT رو آوردیم و باهاشون کار کردیم. به مرور سرویس‌هایی مثل Copilot و Cursor رو هم امتحان کردیم. تجربه‌مون تا مدتی به این صورت بود که هر ابزار جدیدی که میومد تعدادی از مشکلات و اذیت‌هایی رو که با ورژن‌های قدیمی‌تر داشتیم، برطرف می‌کرد. برای مثال در کار با ChatGPT باید توضیحات خیلی مفصلی از مسئله ارائه می‌دادیم و تمام کدهای مورد نیازشو کپی پیست می‌کردیم و کد خروجیش رو داخل محیط توسعه‌مون می‌آوردیم و مشکلات سینتکسی که داشت رو برطرف می‌کردیم. برای دیباگ هم لاگ‌های خروجیش رو باز به GPT می‌دادیم. این تجربهٔ کاربری رفت و برگشتی تا حد خوبی در محصولاتی مثل Cursor برطرف شد اما همچنان مشکلات بزرگ دیگری داشتیم.
بخشی از مقاله :
محیط توسعه Cursor برای پروژه‌های کوچک و self-contained خیلی خوب عمل می‌کرد. اما برای پروژه‌های داخل یک سازمان به مشکل می‌خورد. مشکل این بود که همه اطلاعات مورد نیاز داخل پروژه در دسترس نیست و یا پیدا کردنش برای کسی که دانش قبلی از سازمان و کانونشن‌های پروژه نداره کار ساده‌ای نیست. خیلی از جاها هم زمان و هزینه‌ای که ایجنت‌ها برای پیدا کردن داده مورد نظر می‌ذاشتن خیلی بالا بود و حتی ممکن بود Context Window مدل به طور کامل پر بشه و به نتیجه نرسه. تمام محصولات دیگری که امتحانشون کردیم، هر چقدر هم پیشرفته بودن و از مدل‌های بهتر و توکن بیشتری استفاده می‌کردن، باز هم مشکل اصلی پابرجا بود. اینکه کانتکست دیواری و دانش کتابخانه‌های داخل سازمانی رو نداشتن و عملکردشون به همین علت، بهینه نبود. در خیلی از موارد هم مستندات معتبری داشتیم و یا ساخته بودیم که به خوبی ازشون استفاده نمی‌شد.
مکانیزم پیشنهادی برای حل کردن این مسائل در مدل‌های زبانی قابلیت استفاده از ابزار (tool calling) در عامل‌های (agents) هوش‌مصنوعی بود. اینطور که خود مدل بسیاری از داده‌هایی که نیاز داره رو به دست بیاره، و خودش اکشن‌هایی که پیشنهاد می‌ده رو انجام بده و خروجی‌شون رو بررسی کنه. این یعنی مسئولیت از دوش کاربر استفاده کننده برداشته بشه.
برای همین تصمیم گرفتیم اول سعی کنیم منابع داده مختلفی رو که داریم رو با استفاده از ابزارهایی که امکانش هست، به LLMها وصل کنیم. اما باید برای هر سرویسی، به طور جداگانه، داخل Agent Libraryها و با استفاده از SDK خود شرکت‌ها ابزار رو به عنوان یک تابع یا اندپوینتی که صدا زده میشه، اضافه کنیم. کار قابل انجامی بود اما یکپارچه نبود و خیلی از سرویس‌های انحصاری هم قابلیت تغییر و اضافه کردن ابزار به این شکل رو به ما نمی‌دادن.
....
برای خوندن ادامهٔ مطلب از لینک‌های زیر استفاده کنید:
✅بخش اول : کابوس مستندسازی
✅بخش دوم : اتصال کدبیس دیوار به مدل‌های زبانی
ما در دیوار این هدف رو برای خودمون گذاشتیم که با استفاده از هوش مصنوعی، بهره‌وری مهندسی رو افزایش بدیم. در شروع سرویس‌های مکالمه‌محور مثل ChatGPT رو آوردیم و باهاشون کار کردیم. به مرور سرویس‌هایی مثل Copilot و Cursor رو هم امتحان کردیم. تجربه‌مون تا مدتی به این صورت بود که هر ابزار جدیدی که میومد تعدادی از مشکلات و اذیت‌هایی رو که با ورژن‌های قدیمی‌تر داشتیم، برطرف می‌کرد. برای مثال در کار با ChatGPT باید توضیحات خیلی مفصلی از مسئله ارائه می‌دادیم و تمام کدهای مورد نیازشو کپی پیست می‌کردیم و کد خروجیش رو داخل محیط توسعه‌مون می‌آوردیم و مشکلات سینتکسی که داشت رو برطرف می‌کردیم. برای دیباگ هم لاگ‌های خروجیش رو باز به GPT می‌دادیم. این تجربهٔ کاربری رفت و برگشتی تا حد خوبی در محصولاتی مثل Cursor برطرف شد اما همچنان مشکلات بزرگ دیگری داشتیم.
بخشی از مقاله :
محیط توسعه Cursor برای پروژه‌های کوچک و self-contained خیلی خوب عمل می‌کرد. اما برای پروژه‌های داخل یک سازمان به مشکل می‌خورد. مشکل این بود که همه اطلاعات مورد نیاز داخل پروژه در دسترس نیست و یا پیدا کردنش برای کسی که دانش قبلی از سازمان و کانونشن‌های پروژه نداره کار ساده‌ای نیست. خیلی از جاها هم زمان و هزینه‌ای که ایجنت‌ها برای پیدا کردن داده مورد نظر می‌ذاشتن خیلی بالا بود و حتی ممکن بود Context Window مدل به طور کامل پر بشه و به نتیجه نرسه. تمام محصولات دیگری که امتحانشون کردیم، هر چقدر هم پیشرفته بودن و از مدل‌های بهتر و توکن بیشتری استفاده می‌کردن، باز هم مشکل اصلی پابرجا بود. اینکه کانتکست دیواری و دانش کتابخانه‌های داخل سازمانی رو نداشتن و عملکردشون به همین علت، بهینه نبود. در خیلی از موارد هم مستندات معتبری داشتیم و یا ساخته بودیم که به خوبی ازشون استفاده نمی‌شد.
مکانیزم پیشنهادی برای حل کردن این مسائل در مدل‌های زبانی قابلیت استفاده از ابزار (tool calling) در عامل‌های (agents) هوش‌مصنوعی بود. اینطور که خود مدل بسیاری از داده‌هایی که نیاز داره رو به دست بیاره، و خودش اکشن‌هایی که پیشنهاد می‌ده رو انجام بده و خروجی‌شون رو بررسی کنه. این یعنی مسئولیت از دوش کاربر استفاده کننده برداشته بشه.
برای همین تصمیم گرفتیم اول سعی کنیم منابع داده مختلفی رو که داریم رو با استفاده از ابزارهایی که امکانش هست، به LLMها وصل کنیم. اما باید برای هر سرویسی، به طور جداگانه، داخل Agent Libraryها و با استفاده از SDK خود شرکت‌ها ابزار رو به عنوان یک تابع یا اندپوینتی که صدا زده میشه، اضافه کنیم. کار قابل انجامی بود اما یکپارچه نبود و خیلی از سرویس‌های انحصاری هم قابلیت تغییر و اضافه کردن ابزار به این شکل رو به ما نمی‌دادن.
اینجا بود که با MCP آشنا شدیم. MCP یک پروتکل باز بر پایه JSON-RPC v2 هست که توسط Anthropic معرفی شده برای اینکه تعامل LLMها با بقیه APIهای موجود رو استاندارد کنه و از وقتی عرضه شده، استقبال زیادی داشته. در حال حاضر تقریبا هر LLM Application پراستفاده‌ای ازش پشتیبانی میکنه (لیست محصولاتی که از MCP پشتیبانی می‌کنند). برای همین ما هم تصمیم گرفتیم تعدادی سرور MCP توسعه بدیم و ببینیم که به مدل‌ها در انجام تسکشون کمک میکنه یا نه.
....
برای خوندن ادامهٔ مطلب از لینک‌های زیر استفاده کنید:
✅بخش اول : کابوس مستندسازی
✅بخش دوم : اتصال کدبیس دیوار به مدل‌های زبانی
👍1
پروژه گارنت : فرزند نوظهور مایکروسافت برای رفع محدودیت‌های ردیس
اخیراً پستی درباره‌ی جایگزین‌های اپن‌سورس Redis نوشتم که در بخش نظرات، یکی از دوستان اشاره‌ای به پروژه‌ای به نام Garnet کرد که تا آن زمان کمتر درباره‌اش شنیده بودم. همین باعث شد کمی بررسی کنم و به نتایج جالبی برسم؛ نتایجی که به نظر می‌رسد پروژه Garnet آینده روشنی در حوزه دیتابیس‌های مقیم در حافظه و یک Distributed Cache دارد. بیایید این پروژه را با هم مرور کنیم:
🔹 چرا مایکروسافت به سمت Garnet رفت؟
مایکروسافت در سرویس‌های گسترده‌اش (از Windows & Web Experiences گرفته تا Azure Resource Manager) نیاز به یک remote cache-store داشت که هم از نظر کارایی و هم مقیاس‌پذیری فراتر از گزینه‌های موجود باشد. Redis با وجود محبوبیت بالا، محدودیت‌هایی مثل تک‌ریسمانی بودن (تا نسخه‌های اخیر) داشت که در بارهای کاری عظیم و موازی، گلوگاه ایجاد می‌کرد.
تیم Microsoft Research با تکیه بر تجربه پروژه FASTER (۲۰۱۶–۲۰۱۸) از سال ۲۰۲۱ شروع به طراحی Garnet کرد؛ سیستمی که بتواند:
✅مقیاس‌پذیری چندریسمانی واقعی داشته باشد.
✅تاخیر بسیار کم و توان عملیاتی بالا ارائه کند.
✅با ذخیره‌سازی لایه‌ای (RAM، SSD و حتی Azure Storage) کار کند.
✅و مهم‌تر از همه، با اکوسیستم موجود Redis سازگار باشد.
🔹 چه زمانی اپن‌سورس شد؟
در ۱۸ مارس ۲۰۲۴، مایکروسافت به‌طور رسمی Garnet را معرفی و همزمان آن را تحت مجوز MIT اپن‌سورس کرد:
https://github.com/microsoft/garnet👉
🔹 ویژگی‌ها و معماری
گارنت Garnet یک remote cache-store است که برای کارایی بالا، extensibility و تاخیر پایین طراحی شده. برخی ویژگی‌های کلیدی:
🎯 امکان Thread-scalable روی یک نود و پشتیبانی از cluster sharding، replication، failover و transactions.
🎯استفاده از Tsavorite (storage engine مقیاس‌پذیر با tiered storage).
🎯طراحی شبکه pluggable برای رسیدن به throughput بالا و latency در حد صدها میکروثانیه.
🎯پشتیبانی از پروتکل RESP، یعنی می‌توانید Garnet را با کلاینت‌های Redis موجود (مثل StackExchange.Redis) استفاده کنید.
🎯پیاده‌سازی با .NET مدرن، بهینه روی ویندوز و لینوکس، بدون overhead ناشی از garbage collection.
🎯امکان TLS داخلی، extensibility با data structures جدید در .NET.
🔹 جایگاه Garnet در مایکروسافت
طبق اعلام رسمی، نسخه‌هایی از Garnet هم‌اکنون در Windows & Web Experiences Platform، Azure Resource Manager و Azure Resource Graph به کار گرفته شده‌اند.
💡 چرا Garnet خاص است؟
در مقایسه با Redis و حتی Dragonfly، Garnet توانسته:
✅توان عملیاتی بالاتر و Latency پایین‌تر ارائه دهد
✅ مقیاس‌پذیری بهتری در ارتباطات همزمان کلاینت‌ها داشته باشد
✅روی لینوکس و ویندوز یکسان اجرا شود
✅به دلیل Extensibility بالا با نیازهای آینده سازگار بماند
🔄 ردیس هم بیکار ننشسته!
درست است که Garnet بسیار چشمگیر ظاهر شده، اما تیم Redis هم پیشرفت مهمی داشته:
📌 در Redis 8.2 (اوت ۲۰۲۵) مشکل تک‌ریسمانی تا حد زیادی برطرف شده
📌بهبود معماری پردازش چندریسمانی باعث ۴۹٪ افزایش Throughput نسبت به نسخه‌های قبلی شده است
📌 Garnet می‌خواهد همان چیزی باشد که Redis در دنیای مقیاس عظیم هنوز به‌طور کامل نتوانسته باشد؛ یک cache-store سازگار، سریع‌تر، مقیاس‌پذیرتر و مدرن‌تر.
کانال تلگرام مدرسه مهندسی داده سپهرام : @sepahram_school
اخیراً پستی درباره‌ی جایگزین‌های اپن‌سورس Redis نوشتم که در بخش نظرات، یکی از دوستان اشاره‌ای به پروژه‌ای به نام Garnet کرد که تا آن زمان کمتر درباره‌اش شنیده بودم. همین باعث شد کمی بررسی کنم و به نتایج جالبی برسم؛ نتایجی که به نظر می‌رسد پروژه Garnet آینده روشنی در حوزه دیتابیس‌های مقیم در حافظه و یک Distributed Cache دارد. بیایید این پروژه را با هم مرور کنیم:
🔹 چرا مایکروسافت به سمت Garnet رفت؟
مایکروسافت در سرویس‌های گسترده‌اش (از Windows & Web Experiences گرفته تا Azure Resource Manager) نیاز به یک remote cache-store داشت که هم از نظر کارایی و هم مقیاس‌پذیری فراتر از گزینه‌های موجود باشد. Redis با وجود محبوبیت بالا، محدودیت‌هایی مثل تک‌ریسمانی بودن (تا نسخه‌های اخیر) داشت که در بارهای کاری عظیم و موازی، گلوگاه ایجاد می‌کرد.
تیم Microsoft Research با تکیه بر تجربه پروژه FASTER (۲۰۱۶–۲۰۱۸) از سال ۲۰۲۱ شروع به طراحی Garnet کرد؛ سیستمی که بتواند:
✅مقیاس‌پذیری چندریسمانی واقعی داشته باشد.
✅تاخیر بسیار کم و توان عملیاتی بالا ارائه کند.
✅با ذخیره‌سازی لایه‌ای (RAM، SSD و حتی Azure Storage) کار کند.
✅و مهم‌تر از همه، با اکوسیستم موجود Redis سازگار باشد.
🔹 چه زمانی اپن‌سورس شد؟
در ۱۸ مارس ۲۰۲۴، مایکروسافت به‌طور رسمی Garnet را معرفی و همزمان آن را تحت مجوز MIT اپن‌سورس کرد:
https://github.com/microsoft/garnet👉
🔹 ویژگی‌ها و معماری
گارنت Garnet یک remote cache-store است که برای کارایی بالا، extensibility و تاخیر پایین طراحی شده. برخی ویژگی‌های کلیدی:
🎯 امکان Thread-scalable روی یک نود و پشتیبانی از cluster sharding، replication، failover و transactions.
🎯استفاده از Tsavorite (storage engine مقیاس‌پذیر با tiered storage).
🎯طراحی شبکه pluggable برای رسیدن به throughput بالا و latency در حد صدها میکروثانیه.
🎯پشتیبانی از پروتکل RESP، یعنی می‌توانید Garnet را با کلاینت‌های Redis موجود (مثل StackExchange.Redis) استفاده کنید.
🎯پیاده‌سازی با .NET مدرن، بهینه روی ویندوز و لینوکس، بدون overhead ناشی از garbage collection.
🎯امکان TLS داخلی، extensibility با data structures جدید در .NET.
🔹 جایگاه Garnet در مایکروسافت
طبق اعلام رسمی، نسخه‌هایی از Garnet هم‌اکنون در Windows & Web Experiences Platform، Azure Resource Manager و Azure Resource Graph به کار گرفته شده‌اند.
💡 چرا Garnet خاص است؟
در مقایسه با Redis و حتی Dragonfly، Garnet توانسته:
✅توان عملیاتی بالاتر و Latency پایین‌تر ارائه دهد
✅ مقیاس‌پذیری بهتری در ارتباطات همزمان کلاینت‌ها داشته باشد
✅روی لینوکس و ویندوز یکسان اجرا شود
✅به دلیل Extensibility بالا با نیازهای آینده سازگار بماند
🔄 ردیس هم بیکار ننشسته!
درست است که Garnet بسیار چشمگیر ظاهر شده، اما تیم Redis هم پیشرفت مهمی داشته:
📌 در Redis 8.2 (اوت ۲۰۲۵) مشکل تک‌ریسمانی تا حد زیادی برطرف شده
📌بهبود معماری پردازش چندریسمانی باعث ۴۹٪ افزایش Throughput نسبت به نسخه‌های قبلی شده است
📌 Garnet می‌خواهد همان چیزی باشد که Redis در دنیای مقیاس عظیم هنوز به‌طور کامل نتوانسته باشد؛ یک cache-store سازگار، سریع‌تر، مقیاس‌پذیرتر و مدرن‌تر.
کانال تلگرام مدرسه مهندسی داده سپهرام : @sepahram_school
👍2❤1
وقتی شمارش دقیق خیلی گرون میشه: HyperLogLog 🔢
وقتی با داده‌های بزرگ سروکار داریم، خیلی وقت‌ها لازم داریم بدانیم:
✅چند کاربر یکتا در سایت بوده‌اند؟
✅چند IP مختلف به API ما وصل شده‌اند؟
✅چند محصول متفاوت در یک بازه دیده شده؟
💡 راه ساده این است که همه شناسه‌ها را نگه داریم و آخرش بشماریم.
اما در دیتابیس‌های توزیع‌شده، این یعنی انفجار حافظه و فشار شدید روی شبکه.
برای همین سراغ ساختارهای داده‌ی «تقریبی» می‌رویم که با مصرف کم حافظه، جواب نزدیک به درست بدهند. یکی از معروف‌ترین‌ها: #HyperLogLog.
🎲 مثال با تاس: رخدادهای نادر
فرض کن کسی مدام تاس می‌ریزد. تو نمی‌دانی چند بار تاس انداخته، فقط نتایج را می‌بینی.
🔹 اگه فقط یک بار ۶ آمد → عادی است.
🔹 اگه دو بار پشت سر هم ۶ آمد → کمی نادرتر.
🔹 اگه چهار بار پشت سر هم ۶ آمد → خیلی خیلی نادر.
این رخدادهای نادر سرنخ خوبی هستند. وقتی چیزی خیلی نادر دیدی، می‌توانی حدس بزنی که احتمالا تعداد دفعات تاس انداختن خیلی زیاد بوده است.
🔑 ارتباط با #HyperLogLog
حالا این ایده را می‌بریم به دنیای هش:
📌هر آیتم (مثل IP یا UserID) را هش میکنیم → یک رشته‌ی طولانی صفر و یک.
📌به ابتدای این رشته نگاه میکنیم: چند صفر پشت سر هم آمده؟
📌هرچه صفرهای بیشتری پشت سر هم باشد، اتفاق نادرتر است → پس احتمالاً داده‌های یکتای زیادی وارد شده‌اند.
📌در نسخه‌ی ساده‌ی الگوریتم، همیشه بیشترین تعداد صفر دیده‌شده را نگه می‌داریم.
مثلاً اگر حداکثر ۶ صفر دیده‌ایم، می‌گوییم:
تقریباً 6^2 = 64 آیتم یکتا داشته‌ایم. (بر اساس فرمول‌های آماری)
🚨 ایراد نسخه‌ی ساده
این روش یک اشکال بزرگ دارد:
اگر همان اوّل کار شانسی هشی بیاید با ۲۰ صفر پشت سر هم، الگوریتم می‌گوید: «اینجا باید حدود یک میلیون آیتم یکتا دیده شده باشد!»
در حالی که شاید فقط ۱۰ آیتم وارد شده‌اند.
مثل این است که دفعه‌ی اوّل ۴ تا شش پشت سر هم بیاید و ما فکر کنیم هزار بار تاس ریخته‌ایم!
🪣 راه‌حل: باکتینگ
برای حل این مشکل، #HyperLogLog واقعی از باکت‌ها استفاده می‌کند:
🎯چند بیت اول هش → تعیین می‌کند آیتم در کدام باکت قرار بگیرد.
🎯بقیه بیت‌ها → برای شمردن تعداد صفرهای ابتدای رشته استفاده می‌شود.
🎯در هر باکت، فقط «بیشترین تعداد صفر» ذخیره می‌شود.
🎯در پایان، الگوریتم همه باکت‌ها را با هم ترکیب می‌کند (با میانگین هارمونیک + اصلاح خطا).
به این ترتیب، یک رخداد نادر شانسی نمی‌تواند کل تخمین را خراب کند.
🏗 کجاها استفاده می‌شود؟
الگوریتم شمارش #HyperLogLog امروز در خیلی از دیتابیس‌ها و ابزارهای بزرگ به‌کار می‌رود:
🧩ردیس → دستورات PFADD و PFCOUNT برای شمارش یکتاها
🧩بیگ‌کوئری→ پشت APPROX_COUNT_DISTINCT
🧩ترینو/Presto و #ClickHouse → توابع شمارش تقریبی
🧩اسپارک و #Snowflake → در approx_count_distinct
🧩و حتی سیستم‌هایی مثل Cassandra / ScyllaDB که برای کم کردن بار IO از ساختارهای مشابه استفاده می‌کنند
✨ خلاصه اینکه:
الگوریتم HyperLogLog به‌جای شمردن دقیق، «حدس تقریبی اما پایدار» می‌زند؛ و همین باعث شده در مقیاس وب و دیتای عظیم، تبدیل به یک ابزار استاندارد شود.
کانال مدرسه مهندسی داده سپهرام: @sepahram_school
وقتی با داده‌های بزرگ سروکار داریم، خیلی وقت‌ها لازم داریم بدانیم:
✅چند کاربر یکتا در سایت بوده‌اند؟
✅چند IP مختلف به API ما وصل شده‌اند؟
✅چند محصول متفاوت در یک بازه دیده شده؟
💡 راه ساده این است که همه شناسه‌ها را نگه داریم و آخرش بشماریم.
اما در دیتابیس‌های توزیع‌شده، این یعنی انفجار حافظه و فشار شدید روی شبکه.
برای همین سراغ ساختارهای داده‌ی «تقریبی» می‌رویم که با مصرف کم حافظه، جواب نزدیک به درست بدهند. یکی از معروف‌ترین‌ها: #HyperLogLog.
🎲 مثال با تاس: رخدادهای نادر
فرض کن کسی مدام تاس می‌ریزد. تو نمی‌دانی چند بار تاس انداخته، فقط نتایج را می‌بینی.
🔹 اگه فقط یک بار ۶ آمد → عادی است.
🔹 اگه دو بار پشت سر هم ۶ آمد → کمی نادرتر.
🔹 اگه چهار بار پشت سر هم ۶ آمد → خیلی خیلی نادر.
این رخدادهای نادر سرنخ خوبی هستند. وقتی چیزی خیلی نادر دیدی، می‌توانی حدس بزنی که احتمالا تعداد دفعات تاس انداختن خیلی زیاد بوده است.
🔑 ارتباط با #HyperLogLog
حالا این ایده را می‌بریم به دنیای هش:
📌هر آیتم (مثل IP یا UserID) را هش میکنیم → یک رشته‌ی طولانی صفر و یک.
📌به ابتدای این رشته نگاه میکنیم: چند صفر پشت سر هم آمده؟
📌هرچه صفرهای بیشتری پشت سر هم باشد، اتفاق نادرتر است → پس احتمالاً داده‌های یکتای زیادی وارد شده‌اند.
📌در نسخه‌ی ساده‌ی الگوریتم، همیشه بیشترین تعداد صفر دیده‌شده را نگه می‌داریم.
مثلاً اگر حداکثر ۶ صفر دیده‌ایم، می‌گوییم:
تقریباً 6^2 = 64 آیتم یکتا داشته‌ایم. (بر اساس فرمول‌های آماری)
🚨 ایراد نسخه‌ی ساده
این روش یک اشکال بزرگ دارد:
اگر همان اوّل کار شانسی هشی بیاید با ۲۰ صفر پشت سر هم، الگوریتم می‌گوید: «اینجا باید حدود یک میلیون آیتم یکتا دیده شده باشد!»
در حالی که شاید فقط ۱۰ آیتم وارد شده‌اند.
مثل این است که دفعه‌ی اوّل ۴ تا شش پشت سر هم بیاید و ما فکر کنیم هزار بار تاس ریخته‌ایم!
🪣 راه‌حل: باکتینگ
برای حل این مشکل، #HyperLogLog واقعی از باکت‌ها استفاده می‌کند:
🎯چند بیت اول هش → تعیین می‌کند آیتم در کدام باکت قرار بگیرد.
🎯بقیه بیت‌ها → برای شمردن تعداد صفرهای ابتدای رشته استفاده می‌شود.
🎯در هر باکت، فقط «بیشترین تعداد صفر» ذخیره می‌شود.
🎯در پایان، الگوریتم همه باکت‌ها را با هم ترکیب می‌کند (با میانگین هارمونیک + اصلاح خطا).
به این ترتیب، یک رخداد نادر شانسی نمی‌تواند کل تخمین را خراب کند.
🏗 کجاها استفاده می‌شود؟
الگوریتم شمارش #HyperLogLog امروز در خیلی از دیتابیس‌ها و ابزارهای بزرگ به‌کار می‌رود:
🧩ردیس → دستورات PFADD و PFCOUNT برای شمارش یکتاها
🧩بیگ‌کوئری→ پشت APPROX_COUNT_DISTINCT
🧩ترینو/Presto و #ClickHouse → توابع شمارش تقریبی
🧩اسپارک و #Snowflake → در approx_count_distinct
🧩و حتی سیستم‌هایی مثل Cassandra / ScyllaDB که برای کم کردن بار IO از ساختارهای مشابه استفاده می‌کنند
✨ خلاصه اینکه:
الگوریتم HyperLogLog به‌جای شمردن دقیق، «حدس تقریبی اما پایدار» می‌زند؛ و همین باعث شده در مقیاس وب و دیتای عظیم، تبدیل به یک ابزار استاندارد شود.
کانال مدرسه مهندسی داده سپهرام: @sepahram_school
👌4❤1🔥1
فشرده‌سازی JSON — انتخاب الگوریتم مناسب برای سرعت و بهره‌وری بیشتر
JSON همه‌جا هست: از APIها و سرویس‌های میکروسرویس تا ذخیره‌سازی لاگ و داده‌های تحلیلی. اما اغلب فراموش میکنیم که یک انتخاب ساده در الگوریتم فشرده‌سازی می‌تواند سرعت، مصرف CPU و پهنای‌باند را به شدت بهبود دهد.
در ادامه نگاهی دقیق‌تر به الگوریتم‌های مرسوم و نتایج عملی بنچمارک داریم:
🔹 GZIP
🎯چطور کار می‌کند: در واقع ZLIB (ترکیبی از الگوریتم LZ77 برای یافتن الگوهای تکراری و کدگذاری هافمن) است که یک پوسته اضافه دارد و متادیتای فایل و CRC را اضافه می‌کند.
🧩ویژگی‌ها: همان مزایای ZLIB (نسبت فشرده‌سازی بالا، پشتیبانی گسترده در اکثر زبان‌ها و سیستم‌ها) با کمی قابلیت سازگاری بیشتر.
🛠محدودیت‌ها: نسبت فشرده‌سازی و سرعت مشابه ZLIB، اما کمی سنگین‌تر در متادیتا.
🔹 Snappy (گوگل)
🎯چطور کار می‌کند: تمرکز روی سرعت؛ از الگوریتم‌های ساده فشرده‌سازی برای پیدا کردن الگوهای کوتاه استفاده می‌کند.
🧩ویژگی‌ها: سرعت فوق‌العاده بالا، مصرف CPU کم.
🛠محدودیت‌ها: نسبت فشرده‌سازی پایین‌تر از ZLIB/Zstd.
✨کجا استفاده شود: سیستم‌های زمان‌واقعی، پیام‌رسانی، پردازش جریان داده (Streaming).
🔹 Zstandard (Zstd)
🎯چطور کار می‌کند: ترکیبی از الگوریتم‌های LZ77 و Huffman، با طراحی مدرن و قابلیت تنظیم سطح فشرده‌سازی از سریع تا بسیار فشرده.
🧩ویژگی‌ها: نسبت فشرده‌سازی خوب، سرعت بالا، امکان تنظیم دقیق برای تعادل بین سرعت و حجم.
🛠محدودیت‌ها: کمی مصرف حافظه بیشتر از Snappy.
✨کجا استفاده شود: ذخیره‌سازی حجیم، انتقال داده‌های بزرگ، زمانی که نیاز به تعادل بین سرعت و حجم داریم.
🔹 Brotli (گوگل)
🎯چطور کار می‌کند: طراحی شده برای وب و HTTPS، از دیکشنری‌های از پیش تعریف شده و الگوریتم‌های هافمن پیچیده استفاده می‌کند.
🧩ویژگی‌ها: بهترین نسبت فشرده‌سازی برای متن، مخصوصا JSON و HTML.
🛠محدودیت‌ها: سرعت فشرده‌سازی کندتر، مصرف حافظه بیشتر.
✨کجا استفاده شود: وب‌اپلیکیشن‌ها، کاربران موبایل، شبکه‌های با پهنای‌باند محدود.
⚙️ بنچمارک عملی
آدرس بنچمارک : https://lnkd.in/d6iBwzPQ
⚡️ روش کار (Methodology):
⚡️دیتاست: ۱۰,۰۰۰ آبجکت JSON با ساختارهای تو در تو، هر کدام حدود ۱KB
⚡️ابزارها: Node.js zlib, snappy, zstd-codec, brotli
معیارها:
🔰نسبت فشرده‌سازی: اندازه اصلی ÷ اندازه فشرده‌شده
🔰سرعت: MB/s (فشرده‌سازی + بازگشایی)
🔰مصرف CPU و حافظه: اندازه‌گیری شده با Linux perf
محیط اجرا:
📌 زبان Node.js v20.11.1
📌شبکه شبیه‌سازی شده ۱۰۰ Mbps
🔑 نتایج کلیدی
توازن سرعت و نسبت فشرده‌سازی
🎯الگوریتم Snappy سریع‌ترین است، ۴ برابر سریع‌تر از ZLIB، ایده‌آل برای برنامه‌های زمان واقعی.
🎯الگوریتم‌های Brotli و Zstd نسبت فشرده‌سازی بهتری دارند (۵.۱x و ۴.۵x) اما سرعت کمتری دارند.
مصرف CPU و حافظه
🎯 الگوریتم Snappy حدود ۷۰٪ کمتر از ZLIB/Brotli CPU مصرف می‌کند.
الگوریتم Zstd تعادل خوبی بین CPU (۶۰٪ مصرف) و نسبت فشرده‌سازی ارائه می‌دهد.
تأثیر روی شبکه
🎯 الگوریتم Brotli حجم payload را تا ۸۰٪ کاهش می‌دهد، مخصوص شبکه‌های با تأخیر بالا.
الگوریتم Snappy تأخیر را برای سیستم‌های زمان واقعی (مثل گیمینگ و IoT) به حداقل می‌رساند.
💡 جمع‌بندی برای انتخاب الگوریتم
- سرعت مهم است؟ → Snappy
- کمترین حجم و صرفه‌جویی پهنای باند؟ → Brotli یا Zstd
- تعادل و همه‌کاره بودن؟ → Zstd
- سازگاری با سیستم‌های قدیمی؟ → ZLIB/GZIP
JSON همه‌جا هست: از APIها و سرویس‌های میکروسرویس تا ذخیره‌سازی لاگ و داده‌های تحلیلی. اما اغلب فراموش میکنیم که یک انتخاب ساده در الگوریتم فشرده‌سازی می‌تواند سرعت، مصرف CPU و پهنای‌باند را به شدت بهبود دهد.
در ادامه نگاهی دقیق‌تر به الگوریتم‌های مرسوم و نتایج عملی بنچمارک داریم:
🔹 GZIP
🎯چطور کار می‌کند: در واقع ZLIB (ترکیبی از الگوریتم LZ77 برای یافتن الگوهای تکراری و کدگذاری هافمن) است که یک پوسته اضافه دارد و متادیتای فایل و CRC را اضافه می‌کند.
🧩ویژگی‌ها: همان مزایای ZLIB (نسبت فشرده‌سازی بالا، پشتیبانی گسترده در اکثر زبان‌ها و سیستم‌ها) با کمی قابلیت سازگاری بیشتر.
🛠محدودیت‌ها: نسبت فشرده‌سازی و سرعت مشابه ZLIB، اما کمی سنگین‌تر در متادیتا.
🔹 Snappy (گوگل)
🎯چطور کار می‌کند: تمرکز روی سرعت؛ از الگوریتم‌های ساده فشرده‌سازی برای پیدا کردن الگوهای کوتاه استفاده می‌کند.
🧩ویژگی‌ها: سرعت فوق‌العاده بالا، مصرف CPU کم.
🛠محدودیت‌ها: نسبت فشرده‌سازی پایین‌تر از ZLIB/Zstd.
✨کجا استفاده شود: سیستم‌های زمان‌واقعی، پیام‌رسانی، پردازش جریان داده (Streaming).
🔹 Zstandard (Zstd)
🎯چطور کار می‌کند: ترکیبی از الگوریتم‌های LZ77 و Huffman، با طراحی مدرن و قابلیت تنظیم سطح فشرده‌سازی از سریع تا بسیار فشرده.
🧩ویژگی‌ها: نسبت فشرده‌سازی خوب، سرعت بالا، امکان تنظیم دقیق برای تعادل بین سرعت و حجم.
🛠محدودیت‌ها: کمی مصرف حافظه بیشتر از Snappy.
✨کجا استفاده شود: ذخیره‌سازی حجیم، انتقال داده‌های بزرگ، زمانی که نیاز به تعادل بین سرعت و حجم داریم.
🔹 Brotli (گوگل)
🎯چطور کار می‌کند: طراحی شده برای وب و HTTPS، از دیکشنری‌های از پیش تعریف شده و الگوریتم‌های هافمن پیچیده استفاده می‌کند.
🧩ویژگی‌ها: بهترین نسبت فشرده‌سازی برای متن، مخصوصا JSON و HTML.
🛠محدودیت‌ها: سرعت فشرده‌سازی کندتر، مصرف حافظه بیشتر.
✨کجا استفاده شود: وب‌اپلیکیشن‌ها، کاربران موبایل، شبکه‌های با پهنای‌باند محدود.
⚙️ بنچمارک عملی
آدرس بنچمارک : https://lnkd.in/d6iBwzPQ
⚡️ روش کار (Methodology):
⚡️دیتاست: ۱۰,۰۰۰ آبجکت JSON با ساختارهای تو در تو، هر کدام حدود ۱KB
⚡️ابزارها: Node.js zlib, snappy, zstd-codec, brotli
معیارها:
🔰نسبت فشرده‌سازی: اندازه اصلی ÷ اندازه فشرده‌شده
🔰سرعت: MB/s (فشرده‌سازی + بازگشایی)
🔰مصرف CPU و حافظه: اندازه‌گیری شده با Linux perf
محیط اجرا:
📌 زبان Node.js v20.11.1
📌شبکه شبیه‌سازی شده ۱۰۰ Mbps
🔑 نتایج کلیدی
توازن سرعت و نسبت فشرده‌سازی
🎯الگوریتم Snappy سریع‌ترین است، ۴ برابر سریع‌تر از ZLIB، ایده‌آل برای برنامه‌های زمان واقعی.
🎯الگوریتم‌های Brotli و Zstd نسبت فشرده‌سازی بهتری دارند (۵.۱x و ۴.۵x) اما سرعت کمتری دارند.
مصرف CPU و حافظه
🎯 الگوریتم Snappy حدود ۷۰٪ کمتر از ZLIB/Brotli CPU مصرف می‌کند.
الگوریتم Zstd تعادل خوبی بین CPU (۶۰٪ مصرف) و نسبت فشرده‌سازی ارائه می‌دهد.
تأثیر روی شبکه
🎯 الگوریتم Brotli حجم payload را تا ۸۰٪ کاهش می‌دهد، مخصوص شبکه‌های با تأخیر بالا.
الگوریتم Snappy تأخیر را برای سیستم‌های زمان واقعی (مثل گیمینگ و IoT) به حداقل می‌رساند.
💡 جمع‌بندی برای انتخاب الگوریتم
- سرعت مهم است؟ → Snappy
- کمترین حجم و صرفه‌جویی پهنای باند؟ → Brotli یا Zstd
- تعادل و همه‌کاره بودن؟ → Zstd
- سازگاری با سیستم‌های قدیمی؟ → ZLIB/GZIP
👍4
جلسه اول دوره ClickHouse در مدرسه مهندسی داده سپهرام برگزار شد و فیلم بخش نصب و راه‌اندازی و شروع به کار با ClickHouse اکنون در یوتیوب و صفحه درس دوره منتشر شده است.
دوستانی که تاکنون فرصت نصب و کار کردن با ClickHouse را نداشته‌اند اما علاقه دارند با این دیتابیس پرقدرت و سریع تحلیلی آشنا شوند، می‌توانند در یک جلسه کوتاه نیم‌ساعته به صورت عملی کار با آن را تجربه کنند.
در این ویدئو خواهید دید:
ـ نصب ClickHouse روی ویندوز با استفاده از WSL
ـ راه‌اندازی سرور و اتصال اولیه
ـ کار با محیط clickhouse-client
ـ ایجاد دیتابیس و جداول اولیه برای شروع کار
📺 مشاهده ویدئوی جلسه اول:
👉 https://www.youtube.com/watch?v=gGpSbMpfAiM
برای دیدن بخش دوم و ادامه ویدئوهای آموزشی به آدرس زیر مراجعه کنید:
👉 https://sepahram.ir/courses/clickhouse-201/
#ClickHouse #DataEngineering #BigData #Analytics #OLAP #HandsOn
کانال تلگرام سپهرام : @sepahram_school
دوستانی که تاکنون فرصت نصب و کار کردن با ClickHouse را نداشته‌اند اما علاقه دارند با این دیتابیس پرقدرت و سریع تحلیلی آشنا شوند، می‌توانند در یک جلسه کوتاه نیم‌ساعته به صورت عملی کار با آن را تجربه کنند.
در این ویدئو خواهید دید:
ـ نصب ClickHouse روی ویندوز با استفاده از WSL
ـ راه‌اندازی سرور و اتصال اولیه
ـ کار با محیط clickhouse-client
ـ ایجاد دیتابیس و جداول اولیه برای شروع کار
📺 مشاهده ویدئوی جلسه اول:
👉 https://www.youtube.com/watch?v=gGpSbMpfAiM
برای دیدن بخش دوم و ادامه ویدئوهای آموزشی به آدرس زیر مراجعه کنید:
👉 https://sepahram.ir/courses/clickhouse-201/
#ClickHouse #DataEngineering #BigData #Analytics #OLAP #HandsOn
کانال تلگرام سپهرام : @sepahram_school
🔥1🙏1
معرفی Icebox: ساده‌ترین راه برای تجربه Apache Iceberg و دنیای Lakehouse
اگر همیشه کنجکاو بودید که Apache Iceberg را امتحان کنید، اما حوصله‌ی راه‌اندازی‌های پیچیده، کانفیگ‌های سنگین و کلاسترهای پرهزینه را نداشتید، خبر خوب اینجاست:
کتابخانه Icebox مثل یک Flight Simulator برای Iceberg عمل می‌کند:
✨بدون نیاز به Docker یا JVM
✨یک باینری ساده، با نصب صفر و شروع سریع
✨موتور تحلیلی DuckDB برای اجرای کوئری‌های SQL
✨استوریج MinIO داخلی برای شبیه‌سازی فضای S3
✨و مهم‌تر از همه، پشتیبانی از تمام امکانات Iceberg (ACID, Time Travel, Schema Evolution)
🎯 چرا Apache Iceberg ترند شده است؟
ترکیب انعطاف و مقیاس‌پذیری Data Lake با قابلیت‌های قوی Data Warehouse.
و اینجاست که Apache Iceberg نقش اصلی را بازی می‌کند:
✅ ACID Transactions
✅ Schema Evolution
✅ Time Travel
✅ Performance Optimizations
✅ Open & Vendor-neutral
به همین خاطر است که امروز Iceberg به یکی از ترندترین فناوری‌های دنیای داده تبدیل شده است.
برای یک مهندس داده مدرن، یادگیری Iceberg دیگر یک انتخاب نیست؛ یک ضرورت است.
اما ببینیم وقتی یک جدول در Lakehouse تعریف میکنیم چه اتفاقی می‌افتد؟
در ظاهر مثل دیتابیس سنتی می‌نویسیم:
اما پشت صحنه:
🎯یک جدول در Iceberg فقط یک متادیتا + مجموعه‌ای از فایل‌ها (Parquet/ORC) است.
🎯هر بار داده اضافه یا حذف می‌شود، فایل جدید ساخته می‌شود و یک snapshot جدید در متادیتا ثبت می‌گردد.
🎯این snapshotها امکان time travel و versioning را فراهم می‌کنند.
🎯کامیت تغییرات از طریق فایل متادیتا انجام می‌شود (atomic commit) → این همان چیزی است که #ACID را تضمین می‌کند.
🎯موقع اجرای یک کوئری، فقط متادیتا بررسی می‌شود تا بفهمد کدام فایل‌ها باید خوانده شوند → باعث افزایش کارایی می‌شود.
پس در عمل، یک جدول Iceberg چیزی جز این نیست:
metadata.json + snapshots + فایل‌های parquet
این مکانیزم همان چیزی است که Lakehouse را از یک Data Lake ساده متمایز می‌کند.
💡 تجربه عملی در سه قدم:
✅ تبریک! حالا شما یک Lakehouse واقعی روی لپ‌تاپ خودتان دارید.
🔰 آیس‌باکس: شبیه‌ساز سریع برای یادگیری Iceberg
حالا که می‌دانیم چرا Iceberg مهم است و در پشت صحنه چطور کار می‌کند، سوال این است: چطور می‌توانیم به‌سادگی آن را تجربه کنیم؟ اینجاست که Icebox وارد بازی می‌شود.
امکانات کلیدی Icebox:
📌 شروع سریع: فقط یک فایل باینری، بدون نصب و دردسر
📌 کاتالوگ داخلی SQLite برای مدیریت متادیتا
📌 استوریج MinIO داخلی برای شبیه‌سازی S3 و تست workflowهای ابری
📌 دیتابیس DuckDB تعبیه‌شده برای اجرای سریع SQL
📌 سازگار با همه امکانات Iceberg: تراکنش‌ها، تغییر اسکیمای جداول، time travel
چرا Icebox ارزش امتحان کردن دارد؟
🔰برای یادگیری Iceberg و Lakehouse بدون نیاز به کلود یا کلاستر
🔰برای تست و پروتوتایپ کردن پایپ‌لاین‌های داده‌ای
🔰برای درک عملی امکانات Iceberg (time travel, schema evolution, ACID)
🔰برای داشتن یک محیط سبک، ساده و همیشه آماده روی لپ‌تاپ
🔗 سورس‌کد و مستندات: https://github.com/TFMV/icebox
✨ اگر شما هم دوست دارید Apache Iceberg را یاد بگیرید، Icebox یک نقطه‌ی شروع عالی و بدون دردسر است.
کانال مدرسه مهندسی داده سپهرام : https://t.iss.one/sepahram_school
اگر همیشه کنجکاو بودید که Apache Iceberg را امتحان کنید، اما حوصله‌ی راه‌اندازی‌های پیچیده، کانفیگ‌های سنگین و کلاسترهای پرهزینه را نداشتید، خبر خوب اینجاست:
آیس‌باکس یک ابزار ساده نوشته‌شده با زبان Go است که به شما امکان می‌دهد روی لپ‌تاپ شخصی‌تان در کمتر از ۵ دقیقه یک #Lakehouse واقعی را تجربه کنید.
کتابخانه Icebox مثل یک Flight Simulator برای Iceberg عمل می‌کند:
✨بدون نیاز به Docker یا JVM
✨یک باینری ساده، با نصب صفر و شروع سریع
✨موتور تحلیلی DuckDB برای اجرای کوئری‌های SQL
✨استوریج MinIO داخلی برای شبیه‌سازی فضای S3
✨و مهم‌تر از همه، پشتیبانی از تمام امکانات Iceberg (ACID, Time Travel, Schema Evolution)
🎯 چرا Apache Iceberg ترند شده است؟
ترکیب انعطاف و مقیاس‌پذیری Data Lake با قابلیت‌های قوی Data Warehouse.
و اینجاست که Apache Iceberg نقش اصلی را بازی می‌کند:
✅ ACID Transactions
✅ Schema Evolution
✅ Time Travel
✅ Performance Optimizations
✅ Open & Vendor-neutral
به همین خاطر است که امروز Iceberg به یکی از ترندترین فناوری‌های دنیای داده تبدیل شده است.
برای یک مهندس داده مدرن، یادگیری Iceberg دیگر یک انتخاب نیست؛ یک ضرورت است.
اما ببینیم وقتی یک جدول در Lakehouse تعریف میکنیم چه اتفاقی می‌افتد؟
در ظاهر مثل دیتابیس سنتی می‌نویسیم:
CREATE TABLE sales (
id BIGINT,
amount DOUBLE,
created_at TIMESTAMP
);
اما پشت صحنه:
🎯یک جدول در Iceberg فقط یک متادیتا + مجموعه‌ای از فایل‌ها (Parquet/ORC) است.
🎯هر بار داده اضافه یا حذف می‌شود، فایل جدید ساخته می‌شود و یک snapshot جدید در متادیتا ثبت می‌گردد.
🎯این snapshotها امکان time travel و versioning را فراهم می‌کنند.
🎯کامیت تغییرات از طریق فایل متادیتا انجام می‌شود (atomic commit) → این همان چیزی است که #ACID را تضمین می‌کند.
🎯موقع اجرای یک کوئری، فقط متادیتا بررسی می‌شود تا بفهمد کدام فایل‌ها باید خوانده شوند → باعث افزایش کارایی می‌شود.
پس در عمل، یک جدول Iceberg چیزی جز این نیست:
metadata.json + snapshots + فایل‌های parquet
این مکانیزم همان چیزی است که Lakehouse را از یک Data Lake ساده متمایز می‌کند.
💡 تجربه عملی در سه قدم:
./icebox init my-lakehouse
./icebox import data.parquet --table sales
./icebox sql "SELECT COUNT(*) FROM sales"
✅ تبریک! حالا شما یک Lakehouse واقعی روی لپ‌تاپ خودتان دارید.
🔰 آیس‌باکس: شبیه‌ساز سریع برای یادگیری Iceberg
حالا که می‌دانیم چرا Iceberg مهم است و در پشت صحنه چطور کار می‌کند، سوال این است: چطور می‌توانیم به‌سادگی آن را تجربه کنیم؟ اینجاست که Icebox وارد بازی می‌شود.
امکانات کلیدی Icebox:
📌 شروع سریع: فقط یک فایل باینری، بدون نصب و دردسر
📌 کاتالوگ داخلی SQLite برای مدیریت متادیتا
📌 استوریج MinIO داخلی برای شبیه‌سازی S3 و تست workflowهای ابری
📌 دیتابیس DuckDB تعبیه‌شده برای اجرای سریع SQL
📌 سازگار با همه امکانات Iceberg: تراکنش‌ها، تغییر اسکیمای جداول، time travel
چرا Icebox ارزش امتحان کردن دارد؟
🔰برای یادگیری Iceberg و Lakehouse بدون نیاز به کلود یا کلاستر
🔰برای تست و پروتوتایپ کردن پایپ‌لاین‌های داده‌ای
🔰برای درک عملی امکانات Iceberg (time travel, schema evolution, ACID)
🔰برای داشتن یک محیط سبک، ساده و همیشه آماده روی لپ‌تاپ
🔗 سورس‌کد و مستندات: https://github.com/TFMV/icebox
✨ اگر شما هم دوست دارید Apache Iceberg را یاد بگیرید، Icebox یک نقطه‌ی شروع عالی و بدون دردسر است.
کانال مدرسه مهندسی داده سپهرام : https://t.iss.one/sepahram_school
👌4👍3
از CQRS تا یک سامانه حافظه‌محور : داستان بازطراحی Tudum در نتفلیکس
الگوی #CQRS و معماری‌های event-driven ابزارهای قدرتمندی برای مقیاس‌پذیری هستند. اما وقتی تأخیر بین «نوشتن» و «نمایش تغییر» زیاد شود، به‌خصوص برای سناریوهای real-time مثل preview محتوا، همین الگوها می‌توانند به گلوگاه تبدیل شوند.
📌 داستان Tudum (وب‌سایت طرفداران نتفلیکس) دقیقاً ناظر به همین مساله است.
⚡️ معماری اولیه: #CQRS + #Kafka + #Cassandra
نتفلیکس وب‌سایت طرفداران Tudum را در ۲۰۲۱ راه‌اندازی کرد تا محتوای جانبی مرتبط با برنامه‌ها را به کاربران ارائه دهد و ویراستاران بتوانند تغییرات را پیش‌نمایش کنند.
داده‌ها ابتدا از CMS به سرویس ingestion می‌رفت، پردازش و روی #Kafka منتشر میشد، سپس در #Cassandra ذخیره و با near cache سریع‌تر به سرویس ساخت صفحات میرسید تا صفحات HTML برای کاربران ساخته و نمایش داده شوند. مسیر انتشار و نمایش داده‌ها جدا شد تا مقیاس‌پذیری بهتر شود، اما مشکل تأخیر cache همچنان باقی بود.
⚡️مزایا؟ تفکیک write و read و امکان scale مستقل.
⚠️ مشکل؟ ⏳ تغییرات محتوا در CMS با تأخیر زیاد روی سایت دیده میشد.
🔍 دلیل اصلی این تاخیر طبق گزارش نتفلیکس:
🔹کش با یک چرخه‌ی refresh به‌روزرسانی میشد.
🔹مثلاً اگر ۶۰ کلید داشتی و هر ثانیه یکی refresh میشد، تغییرات حداقل ۶۰ ثانیه بعد قابل مشاهده بود.
🔹با رشد محتوا، این زمان حتی به چند ده ثانیه میرسید.
🔹 برای نویسندگان و ویراستاران، این یعنی تجربه‌ی preview عملاً بی‌فایده بود.
🚀 بازطراحی: RAW Hollow به‌جای Kafka و Cassandra
به جای وصله‌پینه روی کش یا افزایش سرعت Kafka، تیم نتفلیکس یک مسیر جدید انتخاب کرد: جایگزینی کل CQRS pipeline با یک دیتابیس in-memory به نام RAW Hollow.
آدرس پروژه : https://hollow.how
ویژگی‌ها:
🔰کل dataset در حافظه‌ی هر process ذخیره می‌شود → latency بسیار پایین.
🔰پشتیبانی از strong read-after-write consistency → تغییرات بلافاصله قابل مشاهده‌اند.
🔰فشرده‌سازی Hollow حجم داده را تا ۲۵٪ نسخه‌ی اصلی کاهش می‌دهد → کل داده جا می‌شود.
🔰معماری ساده‌تر: حذف Kafka، Cassandra و cache → کمتر شدن لایه‌ها = کمتر شدن delay.
📊 نتایج برای Tudum
✨تأخیر در نمایش تغییرات: از چند ده ثانیه → به چند ثانیه.
✨زمان ساخت صفحه: از ~۱.۴s → به ~۰.۴s.
✨تجربه‌ی preview برای نویسندگان روان شد.
✨معماری تمیزتر و بدون گره‌های زائد.
💬 واکنش‌ها در Hacker News و Reddit
انتشار این تجربه بحث‌های زیادی ایجاد کرد:
🎯بعضی گفتند مشکل صرفاً cache invalidation بود و میشد ساده‌تر حل کرد.
🎯عده‌ای این تغییر را over-engineering دانستند برای سایتی شبیه یک بلاگ.
🎯گروهی دیگر تأکید داشتند که با مقیاس و نیاز به personalization نتفلیکس، این تصمیم منطقی است.
🎯برخی هم انتقاد کردند که مسئله‌ی کوچک به شکل یک چالش بزرگ بیان شده است.
🔑 جمع‌بندی:
پیچیدگی تکنیکی همیشه کارآمد نیست؛ Tudum نشان داد که حذف لایه‌های اضافی و نگهداری داده‌ها در حافظه می‌تواند تجربه‌ی کاربری سریع‌تر و واقعی‌تری فراهم کند. انتخاب معماری همواره یک trade-off بین سرعت و سازگاری است، و در این مورد نتفلیکس سرعت را در اولویت گذاشت.
مدرسه مهندسی داده سپهرام : @sepahram_school
مقاله اصلی : https://www.infoq.com/news/2025/08/netflix-tudum-cqrs-raw-hollow
الگوی #CQRS و معماری‌های event-driven ابزارهای قدرتمندی برای مقیاس‌پذیری هستند. اما وقتی تأخیر بین «نوشتن» و «نمایش تغییر» زیاد شود، به‌خصوص برای سناریوهای real-time مثل preview محتوا، همین الگوها می‌توانند به گلوگاه تبدیل شوند.
📌 داستان Tudum (وب‌سایت طرفداران نتفلیکس) دقیقاً ناظر به همین مساله است.
⚡️ معماری اولیه: #CQRS + #Kafka + #Cassandra
نتفلیکس وب‌سایت طرفداران Tudum را در ۲۰۲۱ راه‌اندازی کرد تا محتوای جانبی مرتبط با برنامه‌ها را به کاربران ارائه دهد و ویراستاران بتوانند تغییرات را پیش‌نمایش کنند.
داده‌ها ابتدا از CMS به سرویس ingestion می‌رفت، پردازش و روی #Kafka منتشر میشد، سپس در #Cassandra ذخیره و با near cache سریع‌تر به سرویس ساخت صفحات میرسید تا صفحات HTML برای کاربران ساخته و نمایش داده شوند. مسیر انتشار و نمایش داده‌ها جدا شد تا مقیاس‌پذیری بهتر شود، اما مشکل تأخیر cache همچنان باقی بود.
⚡️مزایا؟ تفکیک write و read و امکان scale مستقل.
⚠️ مشکل؟ ⏳ تغییرات محتوا در CMS با تأخیر زیاد روی سایت دیده میشد.
🔍 دلیل اصلی این تاخیر طبق گزارش نتفلیکس:
🔹کش با یک چرخه‌ی refresh به‌روزرسانی میشد.
🔹مثلاً اگر ۶۰ کلید داشتی و هر ثانیه یکی refresh میشد، تغییرات حداقل ۶۰ ثانیه بعد قابل مشاهده بود.
🔹با رشد محتوا، این زمان حتی به چند ده ثانیه میرسید.
🔹 برای نویسندگان و ویراستاران، این یعنی تجربه‌ی preview عملاً بی‌فایده بود.
🚀 بازطراحی: RAW Hollow به‌جای Kafka و Cassandra
به جای وصله‌پینه روی کش یا افزایش سرعت Kafka، تیم نتفلیکس یک مسیر جدید انتخاب کرد: جایگزینی کل CQRS pipeline با یک دیتابیس in-memory به نام RAW Hollow.
آدرس پروژه : https://hollow.how
ویژگی‌ها:
🔰کل dataset در حافظه‌ی هر process ذخیره می‌شود → latency بسیار پایین.
🔰پشتیبانی از strong read-after-write consistency → تغییرات بلافاصله قابل مشاهده‌اند.
🔰فشرده‌سازی Hollow حجم داده را تا ۲۵٪ نسخه‌ی اصلی کاهش می‌دهد → کل داده جا می‌شود.
🔰معماری ساده‌تر: حذف Kafka، Cassandra و cache → کمتر شدن لایه‌ها = کمتر شدن delay.
📊 نتایج برای Tudum
✨تأخیر در نمایش تغییرات: از چند ده ثانیه → به چند ثانیه.
✨زمان ساخت صفحه: از ~۱.۴s → به ~۰.۴s.
✨تجربه‌ی preview برای نویسندگان روان شد.
✨معماری تمیزتر و بدون گره‌های زائد.
💬 واکنش‌ها در Hacker News و Reddit
انتشار این تجربه بحث‌های زیادی ایجاد کرد:
🎯بعضی گفتند مشکل صرفاً cache invalidation بود و میشد ساده‌تر حل کرد.
🎯عده‌ای این تغییر را over-engineering دانستند برای سایتی شبیه یک بلاگ.
🎯گروهی دیگر تأکید داشتند که با مقیاس و نیاز به personalization نتفلیکس، این تصمیم منطقی است.
🎯برخی هم انتقاد کردند که مسئله‌ی کوچک به شکل یک چالش بزرگ بیان شده است.
🔑 جمع‌بندی:
پیچیدگی تکنیکی همیشه کارآمد نیست؛ Tudum نشان داد که حذف لایه‌های اضافی و نگهداری داده‌ها در حافظه می‌تواند تجربه‌ی کاربری سریع‌تر و واقعی‌تری فراهم کند. انتخاب معماری همواره یک trade-off بین سرعت و سازگاری است، و در این مورد نتفلیکس سرعت را در اولویت گذاشت.
مدرسه مهندسی داده سپهرام : @sepahram_school
مقاله اصلی : https://www.infoq.com/news/2025/08/netflix-tudum-cqrs-raw-hollow
👍5
Forwarded from مدرسه مهندسی داده سپهرام
فیلم آموزش عملی Kafka در یوتیوب – از نصب تا اجرای اولین Producer و Consumer
در جلسه چهارم 🕑، ما با مفاهیم اصلی #Kafka آشنا شدیم و یاد گرفتیم چگونه آن را به صورت لوکال و بدون Docker نصب و راه‌اندازی کنیم 🖥.
این جلسه ترکیبی از تئوری و تمرین عملی بود و شامل موارد زیر شد:
✨ مفاهیم اصلی Kafka
⚡️بروکرها، تاپیک‌ها و پارتیشن‌ها
⚡️پرودیوسرها و کانسیومرها
⚡️عملکرد #Kafka در پیام‌رسانی با توان بالا و توزیع‌شده
💻 تمرین‌های عملی با خط فرمان
⚡️راه‌اندازی بروکر Kafka به صورت محلی
⚡️ایجاد تاپیک‌ها، ارسال پیام با پرودیوسر و دریافت آن با کانسیومر
⚡️مشاهده مسیر پیام‌ها و رفتار توزیع آن‌ها در پارتیشن‌ها
🐍 تمرین‌های عملی با پایتون
⚡️نوشتن اسکریپت‌های ساده پرودیوسر و کانسیومر
⚡️درک توزیع پیام‌ها و گروه‌های کانسیومر
⚡️مشاهده حفظ ترتیب پیام‌ها در هر پارتیشن
✅ دستاوردهای کلیدی
🔰توانایی راه‌اندازی Kafka به صورت لوکال
🔰تجربه عملی در ارسال و دریافت پیام‌ها
🔰درک پارتیشن‌ها و گروه‌های کانسیومر
🔰پایه‌ای محکم برای ساخت pipelineهای داده real-time و مقیاس‌پذیر
در جلسه دوم 🕑، نصب و راه‌اندازی Kafka با Docker و کار با انواع UI موجود در بازار آموزش داده شد. همچنین Redpanda به عنوان یک جایگزین Kafka معرفی شد. تمرین‌های عملی شامل:
🔰خواندن خودکار فایل‌ها و ارسال آن‌ها به Kafka با Redpanda Connect
🔰راه‌اندازی یک پایپ‌لاین CDC ساده برای انتقال داده‌های درج شده و آپدیت شده در Postgres به Kafka
🎥 لینک آموزش در یوتیوب – کانال مدرسه مهندسی داده سپهرام:
https://www.youtube.com/watch?v=hLT0xOEmNQ8
📚 لیست سایر دوره‌های مدرسه مهندسی داده سپهرام:
https://sepahram.ir/courses/
💡 اگر قصد یادگیری مهندسی داده را دارید:
- هم اکنون می‌توانید سرفصل‌های دوره را مرور کنید
- برای دریافت کد تخفیف ثبت نام، به آی‌دی @sepahram_ir در تلگرام پیام بدهید
دوستانی که تاکنون با کافکا کار نکرده‌اند و می‌خواهند به صورت سریع و کاربردی با آن آشنا شوند، این دوره و به ویژه جلسات چهارم و پنجم برای شماست!
در جلسه چهارم 🕑، ما با مفاهیم اصلی #Kafka آشنا شدیم و یاد گرفتیم چگونه آن را به صورت لوکال و بدون Docker نصب و راه‌اندازی کنیم 🖥.
این جلسه ترکیبی از تئوری و تمرین عملی بود و شامل موارد زیر شد:
✨ مفاهیم اصلی Kafka
⚡️بروکرها، تاپیک‌ها و پارتیشن‌ها
⚡️پرودیوسرها و کانسیومرها
⚡️عملکرد #Kafka در پیام‌رسانی با توان بالا و توزیع‌شده
💻 تمرین‌های عملی با خط فرمان
⚡️راه‌اندازی بروکر Kafka به صورت محلی
⚡️ایجاد تاپیک‌ها، ارسال پیام با پرودیوسر و دریافت آن با کانسیومر
⚡️مشاهده مسیر پیام‌ها و رفتار توزیع آن‌ها در پارتیشن‌ها
🐍 تمرین‌های عملی با پایتون
⚡️نوشتن اسکریپت‌های ساده پرودیوسر و کانسیومر
⚡️درک توزیع پیام‌ها و گروه‌های کانسیومر
⚡️مشاهده حفظ ترتیب پیام‌ها در هر پارتیشن
✅ دستاوردهای کلیدی
🔰توانایی راه‌اندازی Kafka به صورت لوکال
🔰تجربه عملی در ارسال و دریافت پیام‌ها
🔰درک پارتیشن‌ها و گروه‌های کانسیومر
🔰پایه‌ای محکم برای ساخت pipelineهای داده real-time و مقیاس‌پذیر
در جلسه دوم 🕑، نصب و راه‌اندازی Kafka با Docker و کار با انواع UI موجود در بازار آموزش داده شد. همچنین Redpanda به عنوان یک جایگزین Kafka معرفی شد. تمرین‌های عملی شامل:
🔰خواندن خودکار فایل‌ها و ارسال آن‌ها به Kafka با Redpanda Connect
🔰راه‌اندازی یک پایپ‌لاین CDC ساده برای انتقال داده‌های درج شده و آپدیت شده در Postgres به Kafka
🎥 لینک آموزش در یوتیوب – کانال مدرسه مهندسی داده سپهرام:
https://www.youtube.com/watch?v=hLT0xOEmNQ8
📚 لیست سایر دوره‌های مدرسه مهندسی داده سپهرام:
https://sepahram.ir/courses/
💡 اگر قصد یادگیری مهندسی داده را دارید:
- هم اکنون می‌توانید سرفصل‌های دوره را مرور کنید
- برای دریافت کد تخفیف ثبت نام، به آی‌دی @sepahram_ir در تلگرام پیام بدهید
❤4
Forwarded from مدرسه مهندسی داده سپهرام
شروع ثبت‌نام دوره عملی PostgreSQL
در این دوره عملی، شما:
🔰 از نصب و راه‌اندازی تا طراحی دیتابیس با ERD و ایجاد جداول را یاد می‌گیرید.
🔰 نوشتن کوئری‌های پیچیده تحلیلی با JOIN، CTE و Window Function را تمرین می‌کنید.
🔰 با بهینه‌سازی کوئری‌ها، ایندکس‌ها، View و Materialized View آشنا می‌شوید.
🔰 قابلیت‌های پیشرفته‌ای مثل افزونه‌ها، MVCC، WAL، بکاپ و بازیابی، Replication و امنیت سطح ردیف را یاد می‌گیرید.
جزئیات تکمیلی دوره:
✅ دوره به صورت آنلاین برگزار می‌شود، اما هر جلسه بعد از ضبط و تدوین روی سایت قرار می‌گیرد و به صورت آفلاین نیز قابل مشاهده است (در داخل خود سپهرام).
✅در این دوره با نسخه ۱۸ PostgreSQL کار خواهیم کرد و همزمان از امکانات جدید این نسخه حرفهای که در مهرماه 1404 منتشر شده است بهره می‌بریم.
✅ شرکت‌کنندگان علاوه بر گروه اختصاصی و امکان مشاهده دائمی فیلم‌های جدید دوره که به تدریج و با نسخه‌های جدید پستگرس، به روز خواهد شد، به گیت اختصاصی دوره دسترسی خواهند داشت.
با گذراندن این دوره، مهارت عملی طراحی، توسعه و نگهداری یک دیتابیس PostgreSQL حرفهای را به دست خواهید آورد و می‌توانید از آن در پروژه‌های واقعی و ابزارهای تحلیلی حرفهای مانند Superset، Airflow و Metabase استفاده کنید.
ثبت‌نام کنید و قدم به دنیای حرفهای مدیریت داده‌های رابطه‌ای با دیتابیس محبوب پستگرس بگذارید!
https://sepahram.ir/courses/postgresql/
حتی با گسترش انواع دیتابیس‌های NoSQL و سیستم‌های تحلیلی، قلب اکثر سیستم‌های اطلاعاتی هنوز بر پایگاه‌های داده رابطه‌ای استوار است. PostgreSQL به‌عنوان یک دیتابیس متن‌باز و حرفهای، ترکیبی از قدرت سنتی دیتابیس‌های رابطه‌ای و امکانات مدرن مانند JSONB، Array و افزونه‌های متنوع را ارائه می‌دهد.
در این دوره عملی، شما:
🔰 از نصب و راه‌اندازی تا طراحی دیتابیس با ERD و ایجاد جداول را یاد می‌گیرید.
🔰 نوشتن کوئری‌های پیچیده تحلیلی با JOIN، CTE و Window Function را تمرین می‌کنید.
🔰 با بهینه‌سازی کوئری‌ها، ایندکس‌ها، View و Materialized View آشنا می‌شوید.
🔰 قابلیت‌های پیشرفته‌ای مثل افزونه‌ها، MVCC، WAL، بکاپ و بازیابی، Replication و امنیت سطح ردیف را یاد می‌گیرید.
جزئیات تکمیلی دوره:
✅ دوره به صورت آنلاین برگزار می‌شود، اما هر جلسه بعد از ضبط و تدوین روی سایت قرار می‌گیرد و به صورت آفلاین نیز قابل مشاهده است (در داخل خود سپهرام).
✅در این دوره با نسخه ۱۸ PostgreSQL کار خواهیم کرد و همزمان از امکانات جدید این نسخه حرفهای که در مهرماه 1404 منتشر شده است بهره می‌بریم.
✅ شرکت‌کنندگان علاوه بر گروه اختصاصی و امکان مشاهده دائمی فیلم‌های جدید دوره که به تدریج و با نسخه‌های جدید پستگرس، به روز خواهد شد، به گیت اختصاصی دوره دسترسی خواهند داشت.
با گذراندن این دوره، مهارت عملی طراحی، توسعه و نگهداری یک دیتابیس PostgreSQL حرفهای را به دست خواهید آورد و می‌توانید از آن در پروژه‌های واقعی و ابزارهای تحلیلی حرفهای مانند Superset، Airflow و Metabase استفاده کنید.
ثبت‌نام کنید و قدم به دنیای حرفهای مدیریت داده‌های رابطه‌ای با دیتابیس محبوب پستگرس بگذارید!
https://sepahram.ir/courses/postgresql/
👍6