در چند ماه گذشته از کافکا کلا سوئیچ کرده ام به ردپاندا بابت مسایلی مثل بهینه‌تر بودن مصرف منابع و طراحی مدرن‌تر یک سامانه پیام رسان مبتنی بر پروتکل کافکا با امکانات کامل و یکپارچه.
حتی قصد داشتم خلاصه ای از مشاهدات آقای Wu را در کنفرانس ۲۰۲۴ کافکا و داده های جریانی در اینجا به اشتراک بگذارم با این محوریت که کافکا به نقطه حساسی رسیده است و اگر نتواند تغییرات مورد انتظار بازار را برآورده کند، بازار را به رقبا واگذار خواهد کرد و خریدن شرکت‌هایی مثل WarpStream توسط کانفلوئنت که هزینه نگهداری یک کلاستر کافکا را بسیار کاهش می‌دهد، باز هم به تنهایی به کافکا کمک نخواهد کرد :
https://medium.com/@yingjunwu/kafka-has-reached-a-turning-point-649bd18b967f
اگر در حوزه مهندسی داده فعالیت میکنید توصیه میکنم مقاله فوق را با دقت مطالعه کنید. .
اما مهم‌تر ازین مسائل پایه در انتخاب یک ابزار مانند مصرف منابع و سادگی کار با آن و یکپارچه بودن ابزار و اکوسیستم، دید و ویژن شرکت ردپاندا برایم جذاب بود .
دیدی که باعث شد چند ماه پیش، پروژه Benthos را خریده و به RedPanda Connect اضافه کند. یک پروژه عالی، سبک و حرفه ای برای کارهای ETL .
اخیرا هم دیدم ردپاندا، نوع جدیدی از تاپیک‌ها برای کار مستقیم با Apache Iceberg ایجاد کند، به این ویژن و توجه به نیازهای نوین بازار، باور بیشتری دارم.
توصیه میکنم اگر با کافکا کار میکنید، ردپاندا را هم حتما تست کنید (نیاز به تغییر خاصی در کدها ندارید و دقیقا از دید برنامه و ابزار،مثل یک کلاستر کافکا عمل میکند).
مقاله زیر را هم که راجع به افزوده شدن این نوع جدید از تاپیک ها و ذخیره مستقیم پیام‌ها در آپاچی آیس‌برگ است را هم حتما نگاهی بیندازید ....
Read “Apache Iceberg Topics: Stream directly into your data lake“ by Redpanda Data on Medium: https://redpanda-data.medium.com/apache-iceberg-topics-stream-directly-into-your-data-lake-0250a8dfdd76
#مهندسی_داده #redpanda #kafka
حتی قصد داشتم خلاصه ای از مشاهدات آقای Wu را در کنفرانس ۲۰۲۴ کافکا و داده های جریانی در اینجا به اشتراک بگذارم با این محوریت که کافکا به نقطه حساسی رسیده است و اگر نتواند تغییرات مورد انتظار بازار را برآورده کند، بازار را به رقبا واگذار خواهد کرد و خریدن شرکت‌هایی مثل WarpStream توسط کانفلوئنت که هزینه نگهداری یک کلاستر کافکا را بسیار کاهش می‌دهد، باز هم به تنهایی به کافکا کمک نخواهد کرد :
https://medium.com/@yingjunwu/kafka-has-reached-a-turning-point-649bd18b967f
اگر در حوزه مهندسی داده فعالیت میکنید توصیه میکنم مقاله فوق را با دقت مطالعه کنید. .
اما مهم‌تر ازین مسائل پایه در انتخاب یک ابزار مانند مصرف منابع و سادگی کار با آن و یکپارچه بودن ابزار و اکوسیستم، دید و ویژن شرکت ردپاندا برایم جذاب بود .
دیدی که باعث شد چند ماه پیش، پروژه Benthos را خریده و به RedPanda Connect اضافه کند. یک پروژه عالی، سبک و حرفه ای برای کارهای ETL .
اخیرا هم دیدم ردپاندا، نوع جدیدی از تاپیک‌ها برای کار مستقیم با Apache Iceberg ایجاد کند، به این ویژن و توجه به نیازهای نوین بازار، باور بیشتری دارم.
توصیه میکنم اگر با کافکا کار میکنید، ردپاندا را هم حتما تست کنید (نیاز به تغییر خاصی در کدها ندارید و دقیقا از دید برنامه و ابزار،مثل یک کلاستر کافکا عمل میکند).
مقاله زیر را هم که راجع به افزوده شدن این نوع جدید از تاپیک ها و ذخیره مستقیم پیام‌ها در آپاچی آیس‌برگ است را هم حتما نگاهی بیندازید ....
Read “Apache Iceberg Topics: Stream directly into your data lake“ by Redpanda Data on Medium: https://redpanda-data.medium.com/apache-iceberg-topics-stream-directly-into-your-data-lake-0250a8dfdd76
#مهندسی_داده #redpanda #kafka
Medium
Kafka Has Reached a Turning Point
Is Kafka still relevant in today’s evolving tech landscape? And where is Kafka headed in the future?
👍6👌1
Forwarded from عکس نگار
تحولی بزرگ در 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/
بعد از سال‌ها تجربه با نسخه‌های ۱ و ۲، حالا نسخه ۳ با بازطراحی گسترده و حل چالش‌های قدیمی در دسترس توسعه‌دهندگان قرار گرفته — فعلاً به‌صورت نسخه کاندید انتشار (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/
👍3
خرید پروژه‌ی متن‌باز Arroyo توسط Cloudflare 🔥
شرکت Cloudflare به‌تازگی اعلام کرده که پروژه‌ی Arroyo، یکی از نوآورانه‌ترین موتورهای پردازش جریان داده، را به مجموعه‌ی خود افزوده است. این پروژه که در سال ۲۰۲۲ با زبان #Rust 🦀 و توسط دو بنیان‌گذار راه‌اندازی شد، بر تجربه‌ای بی‌نیاز از مدیریت زیرساخت، عملکرد بالا و سادگی در توسعه متمرکز بوده است.
منبع خبر : https://www.arroyo.dev/blog/arroyo-is-joining-cloudflare
🔍 کتابخانه Arroyo : ساده‌سازی پردازش جریان بلادرنگ برای همه ⚙️
پروژه Arroyo یک موتور پردازش جریان (#StreamProcessing) مدرن و متن‌باز است که با هدفی روشن توسعه یافته:
💡 «تبدیل پردازش جریان از یک فناوری پیچیده و لوکس به ابزاری ساده و در دسترس، شبیه نوشتن یک کوئری SQL معمولی برای یک جدول پایگاه‌داده.»
این پروژه با هدف ساده‌سازی توسعه‌ی سیستم‌های پردازش آنی و حذف پیچیدگی‌های زیرساختی ایجاد شده ⚡️ و از فناوری‌های مدرنی مانند Apache Arrow 🏹 و DataFusion 🔗 بهره می‌برد تا عملکرد بالا و کارایی حافظه را تضمین کند.
✨ مهم‌ترین قابلیت‌های Arroyo:
✅ پشتیبانی کامل از SQL با بیش از ۳۰۰ تابع توکار برای تحلیل‌های زمانی، پنجره‌ای و آماری
✅ دقت بالا با Exactly-Once Semantics حتی در صورت بروز خطا یا دریافت داده‌های نامرتب
✅ پشتیبانی از انواع پنجره‌ها (گروه‌بندی زمانی رخدادها): sliding، tumbling و session ⏱️
✅ اتصال به منابع متنوع مانند #Kafka 🧩، #Redis 🔴، #RabbitMQ 🐰 و CDC
✅ مقیاس‌پذیری برای پردازش میلیون‌ها رویداد در ثانیه ⚡️
✅ پشتیبانی از UDF با #Python 🐍، پروتکل Protobuf و مدیریت TTL در وضعیت‌ها
✅ امکان ساخت lookup tables برای داده‌های جریانی 🧷
📸 برای اینکه دقیقا متوجه شوید منظور از پردازش جریان با Arroyo آنهم فقط به کمک SQL چیست، می‌توانید به عکس‌های پایین این پست دقت کنید.
اکنون با پیوستن Arroyo به زیرساخت گسترده‌ی Cloudflare، کاربران می‌توانند از مزایای ترکیب پردازش آنی SQL (به کمک Arroyo)، ذخیره‌سازی ابری (R2)، صف‌های توزیع‌شده (Queues) و اجرای بدون سرور (Workers) در قالب یک پلتفرم یکپارچه و مقیاس‌پذیر بهره‌مند شوند.
🔓کتابخانه Arroyo همچنان متن‌باز و قابل میزبانی مستقل باقی خواهد ماند، و با حمایت Cloudflare از توسعه‌ی پایدار، افزایش کارایی و رشد جامعه‌ی کاربران خود بهره‌مند خواهد شد.
🚀 برای مهندسان داده، استارتاپ‌ها، مدیران محصول، تحلیل‌گران داده و تیم‌هایی که به‌دنبال جایگزینی سریع‌تر و ساده‌تر برای #ApacheFlink یا سایر ابزارهای پردازش جریان هستند، Arroyo اکنون نه‌تنها یک انتخاب هوشمندانه، بلکه یک بستر قدرتمند برای آینده است.
🦀 همچنین Arroyo نمونه‌ای از موج نوین پروژه‌های مبتنی بر زبان برنامه‌نویسی Rust است؛ زبانی که با امنیت بالا و مدیریت حافظه‌ی بسیار دقیق، در حال گشودن مرزهای تازه‌ای در دنیای زیرساخت‌های داده و پردازش بلادرنگ است.
شرکت Cloudflare به‌تازگی اعلام کرده که پروژه‌ی Arroyo، یکی از نوآورانه‌ترین موتورهای پردازش جریان داده، را به مجموعه‌ی خود افزوده است. این پروژه که در سال ۲۰۲۲ با زبان #Rust 🦀 و توسط دو بنیان‌گذار راه‌اندازی شد، بر تجربه‌ای بی‌نیاز از مدیریت زیرساخت، عملکرد بالا و سادگی در توسعه متمرکز بوده است.
منبع خبر : https://www.arroyo.dev/blog/arroyo-is-joining-cloudflare
این خرید از دو جهت برای من مهم است:جزییات این خبر و این پروژه را با هم کمی مرور می‌کنیم.
🧠 کلودفلیر با افزودن قابلیت پردازش جریان با SQL 📊 به سرویس‌هایی مثل R2 ، Workers ⚙️ و Queues ، یک گام مهم به‌سوی ساخت پلتفرم ابری کامل، مقیاس‌پذیر و بی‌نیاز از مدیریت زیرساخت برداشته است—رقابتی جدی برای #AWS و #GoogleCloud.
🧠 پروژه‌ی متن‌باز Arroyo تنها با تلاش دو نفر در ۲۰۲۲ آغاز شد و امروز توسط یکی از بزرگ‌ترین شرکت‌های اینترنتی خریداری شده است؛ نمونه‌ای الهام‌بخش از اینکه تیم‌های کوچک هم می‌توانند به موفقیت‌های بزرگ برسند. 🚀
🔍 کتابخانه Arroyo : ساده‌سازی پردازش جریان بلادرنگ برای همه ⚙️
پروژه Arroyo یک موتور پردازش جریان (#StreamProcessing) مدرن و متن‌باز است که با هدفی روشن توسعه یافته:
💡 «تبدیل پردازش جریان از یک فناوری پیچیده و لوکس به ابزاری ساده و در دسترس، شبیه نوشتن یک کوئری SQL معمولی برای یک جدول پایگاه‌داده.»
این پروژه با هدف ساده‌سازی توسعه‌ی سیستم‌های پردازش آنی و حذف پیچیدگی‌های زیرساختی ایجاد شده ⚡️ و از فناوری‌های مدرنی مانند Apache Arrow 🏹 و DataFusion 🔗 بهره می‌برد تا عملکرد بالا و کارایی حافظه را تضمین کند.
✨ مهم‌ترین قابلیت‌های Arroyo:
✅ پشتیبانی کامل از SQL با بیش از ۳۰۰ تابع توکار برای تحلیل‌های زمانی، پنجره‌ای و آماری
✅ دقت بالا با Exactly-Once Semantics حتی در صورت بروز خطا یا دریافت داده‌های نامرتب
✅ پشتیبانی از انواع پنجره‌ها (گروه‌بندی زمانی رخدادها): sliding، tumbling و session ⏱️
✅ اتصال به منابع متنوع مانند #Kafka 🧩، #Redis 🔴، #RabbitMQ 🐰 و CDC
✅ مقیاس‌پذیری برای پردازش میلیون‌ها رویداد در ثانیه ⚡️
✅ پشتیبانی از UDF با #Python 🐍، پروتکل Protobuf و مدیریت TTL در وضعیت‌ها
✅ امکان ساخت lookup tables برای داده‌های جریانی 🧷
📸 برای اینکه دقیقا متوجه شوید منظور از پردازش جریان با Arroyo آنهم فقط به کمک SQL چیست، می‌توانید به عکس‌های پایین این پست دقت کنید.
اکنون با پیوستن Arroyo به زیرساخت گسترده‌ی Cloudflare، کاربران می‌توانند از مزایای ترکیب پردازش آنی SQL (به کمک Arroyo)، ذخیره‌سازی ابری (R2)، صف‌های توزیع‌شده (Queues) و اجرای بدون سرور (Workers) در قالب یک پلتفرم یکپارچه و مقیاس‌پذیر بهره‌مند شوند.
🔓کتابخانه Arroyo همچنان متن‌باز و قابل میزبانی مستقل باقی خواهد ماند، و با حمایت Cloudflare از توسعه‌ی پایدار، افزایش کارایی و رشد جامعه‌ی کاربران خود بهره‌مند خواهد شد.
🚀 برای مهندسان داده، استارتاپ‌ها، مدیران محصول، تحلیل‌گران داده و تیم‌هایی که به‌دنبال جایگزینی سریع‌تر و ساده‌تر برای #ApacheFlink یا سایر ابزارهای پردازش جریان هستند، Arroyo اکنون نه‌تنها یک انتخاب هوشمندانه، بلکه یک بستر قدرتمند برای آینده است.
🦀 همچنین Arroyo نمونه‌ای از موج نوین پروژه‌های مبتنی بر زبان برنامه‌نویسی Rust است؛ زبانی که با امنیت بالا و مدیریت حافظه‌ی بسیار دقیق، در حال گشودن مرزهای تازه‌ای در دنیای زیرساخت‌های داده و پردازش بلادرنگ است.
www.arroyo.dev
Arroyo is joining Cloudflare
Arroyo has been acquired by Cloudflare to bring serverless SQL stream processing to the Cloudflare Developer Platfrorm, integrated with Queues, Workers, and R2. The Arroyo Engine will remain open-source and self-hostable.
شرکت OpenAI چگونه کلاستر های کافکای خود را پایدار کرد و توان عملیاتی خود را ۲۰ برابر کرد؟ 🚀
در یک سال گذشته، OpenAI توان عملیاتی Kafka را در بیش از ۳۰ خوشه، بیست برابر افزایش داد و به پایداری خیره‌کننده ۹۹.۹۹۹٪ (پنج ۹) دست یافت. در ادامه، به سه بخش کلیدی این تحول می‌پردازیم:
🟩 ۱. گروه‌بندی خوشه‌ها (Cluster Groups)
چالش: با بیش از ۳۰ خوشه Kafka در محیط‌های متفاوت (هر کدام با تنظیمات مخصوص، احراز هویت‌های پراکنده و قوانین فایروال خاص خود)، استفاده از سیستم بسیار پیچیده شده بود. کاربران نمی‌دانستند برای ذخیره یا خواندن داده باید به کدام خوشه متصل شوند و سؤالات مکرری مثل «تاپیک X کجاست؟» زمان توسعه را تلف می‌کرد. اگر یکی از خوشه‌ها از کار می‌افتاد، کاربران باید به‌صورت دستی به خوشه دیگری مهاجرت می‌کردند، که هم وقت‌گیر بود و هم مستعد خطا.
راه‌حل: OpenAI خوشه‌ها را به شکل گروه‌های خوشه‌ای درآورد؛ یعنی مجموعه‌ای از خوشه‌ها که در یک منطقه جغرافیایی قرار دارند (مثلاً آمریکا یا اروپا) و با هم یک گروه منطقی را تشکیل می‌دهند. کاربران حالا با «تاپیک‌های منطقی» کار می‌کنند که به‌صورت خودکار به تاپیک‌های فیزیکی در خوشه‌های مختلف همان گروه متصل می‌شوند. این ساختار، زیرساخت پیچیده را از دید کاربران پنهان میکند و در صورت خرابی یک خوشه، خوشه‌های دیگر گروه جایگزین می‌شوند.
🟨 ۲. پراکسی تولیدکننده : Prism
چالش: پیش از این، هر اپلیکیشنی که داده تولید می‌کرد، مستقیماً به Kafka متصل می‌شد. این مدل باعث ایجاد تا ۵۰ هزار اتصال همزمان به هر بروکر می‌شد که منجر به مصرف شدید حافظه و کاهش پایداری می‌گردید. همچنین، توسعه‌دهندگان باید تنظیمات پیچیده‌ای مانند لیست بروکرها، پورت‌ها، و احراز هویت را به‌صورت دستی انجام می‌دادند. اگر یک خوشه از دسترس خارج می‌شد، برنامه‌ها باید دستی به خوشه دیگری متصل می‌شدند، که منجر به خطا و قطعی می‌شد.
راه‌حل: OpenAI یک پراکسی به نام Prism ایجاد کرد که با استفاده از gRPC به‌عنوان واسط ارتباطی، پیچیدگی Kafka را از کاربران پنهان می‌سازد. برنامه‌ها فقط داده را به Prism می‌فرستند و Prism مسئول هدایت آن به بروکرهای مناسب است. در صورت خرابی یک خوشه، داده‌ها به‌طور خودکار به خوشه‌های دیگر گروه ارسال می‌شود.
🟧 ۳. پراکسی مصرف‌کننده : uForwarder
چالش: مصرف‌کنندگان Kafka هم با مشکلاتی مشابه روبه‌رو بودند. برنامه‌ها باید به‌صورت دستی تنظیمات Kafka، انتخاب خوشه، مدیریت offset و احراز هویت را انجام می‌دادند. این فرآیند زمان‌بر و مستعد خطا بود. از طرف دیگر، مدل pull سنتی Kafka برای خواندن داده‌ها، موجب تأخیر و محدودیت در مصرف همزمان می‌شد. در صورت خرابی خوشه‌ها، اتصال مجدد مصرف‌کنندگان به صورت دستی نیاز بود، که کارآمد نبود.
راه‌حل: OpenAI از uForwarder (یک پروژه متن‌باز از Uber) بهره گرفت که مدل مصرف را از pull به push تغییر می‌دهد. در این مدل، uForwarder خودش داده‌ها را از Kafka دریافت کرده و به اپلیکیشن‌ها تحویل می‌دهد. این پراکسی ویژگی‌های پیشرفتهای دارد مثل: بازارسال خودکار، صف پیام‌های ناموفق (DLQ)، مصرف همزمان از چند خوشه، و موازی‌سازی پیشرفته. همچنین از مشکلاتی مثل Head-of-Line Blocking جلوگیری میکند.
نتیجه: مصرف‌کنندگان می‌توانند بدون دانش خاصی از Kafka داده‌ها را دریافت کنند؛ توسعه آسان‌تر، پایداری بالاتر و عملکرد مقیاس‌پذیرتر حاصل شد.
منبع:
https://lnkd.in/dVpS5ZaD
در یک سال گذشته، OpenAI توان عملیاتی Kafka را در بیش از ۳۰ خوشه، بیست برابر افزایش داد و به پایداری خیره‌کننده ۹۹.۹۹۹٪ (پنج ۹) دست یافت. در ادامه، به سه بخش کلیدی این تحول می‌پردازیم:
🟩 ۱. گروه‌بندی خوشه‌ها (Cluster Groups)
چالش: با بیش از ۳۰ خوشه Kafka در محیط‌های متفاوت (هر کدام با تنظیمات مخصوص، احراز هویت‌های پراکنده و قوانین فایروال خاص خود)، استفاده از سیستم بسیار پیچیده شده بود. کاربران نمی‌دانستند برای ذخیره یا خواندن داده باید به کدام خوشه متصل شوند و سؤالات مکرری مثل «تاپیک X کجاست؟» زمان توسعه را تلف می‌کرد. اگر یکی از خوشه‌ها از کار می‌افتاد، کاربران باید به‌صورت دستی به خوشه دیگری مهاجرت می‌کردند، که هم وقت‌گیر بود و هم مستعد خطا.
راه‌حل: OpenAI خوشه‌ها را به شکل گروه‌های خوشه‌ای درآورد؛ یعنی مجموعه‌ای از خوشه‌ها که در یک منطقه جغرافیایی قرار دارند (مثلاً آمریکا یا اروپا) و با هم یک گروه منطقی را تشکیل می‌دهند. کاربران حالا با «تاپیک‌های منطقی» کار می‌کنند که به‌صورت خودکار به تاپیک‌های فیزیکی در خوشه‌های مختلف همان گروه متصل می‌شوند. این ساختار، زیرساخت پیچیده را از دید کاربران پنهان میکند و در صورت خرابی یک خوشه، خوشه‌های دیگر گروه جایگزین می‌شوند.
🟨 ۲. پراکسی تولیدکننده : Prism
چالش: پیش از این، هر اپلیکیشنی که داده تولید می‌کرد، مستقیماً به Kafka متصل می‌شد. این مدل باعث ایجاد تا ۵۰ هزار اتصال همزمان به هر بروکر می‌شد که منجر به مصرف شدید حافظه و کاهش پایداری می‌گردید. همچنین، توسعه‌دهندگان باید تنظیمات پیچیده‌ای مانند لیست بروکرها، پورت‌ها، و احراز هویت را به‌صورت دستی انجام می‌دادند. اگر یک خوشه از دسترس خارج می‌شد، برنامه‌ها باید دستی به خوشه دیگری متصل می‌شدند، که منجر به خطا و قطعی می‌شد.
راه‌حل: OpenAI یک پراکسی به نام Prism ایجاد کرد که با استفاده از gRPC به‌عنوان واسط ارتباطی، پیچیدگی Kafka را از کاربران پنهان می‌سازد. برنامه‌ها فقط داده را به Prism می‌فرستند و Prism مسئول هدایت آن به بروکرهای مناسب است. در صورت خرابی یک خوشه، داده‌ها به‌طور خودکار به خوشه‌های دیگر گروه ارسال می‌شود.
🟧 ۳. پراکسی مصرف‌کننده : uForwarder
چالش: مصرف‌کنندگان Kafka هم با مشکلاتی مشابه روبه‌رو بودند. برنامه‌ها باید به‌صورت دستی تنظیمات Kafka، انتخاب خوشه، مدیریت offset و احراز هویت را انجام می‌دادند. این فرآیند زمان‌بر و مستعد خطا بود. از طرف دیگر، مدل pull سنتی Kafka برای خواندن داده‌ها، موجب تأخیر و محدودیت در مصرف همزمان می‌شد. در صورت خرابی خوشه‌ها، اتصال مجدد مصرف‌کنندگان به صورت دستی نیاز بود، که کارآمد نبود.
راه‌حل: OpenAI از uForwarder (یک پروژه متن‌باز از Uber) بهره گرفت که مدل مصرف را از pull به push تغییر می‌دهد. در این مدل، uForwarder خودش داده‌ها را از Kafka دریافت کرده و به اپلیکیشن‌ها تحویل می‌دهد. این پراکسی ویژگی‌های پیشرفتهای دارد مثل: بازارسال خودکار، صف پیام‌های ناموفق (DLQ)، مصرف همزمان از چند خوشه، و موازی‌سازی پیشرفته. همچنین از مشکلاتی مثل Head-of-Line Blocking جلوگیری میکند.
نتیجه: مصرف‌کنندگان می‌توانند بدون دانش خاصی از Kafka داده‌ها را دریافت کنند؛ توسعه آسان‌تر، پایداری بالاتر و عملکرد مقیاس‌پذیرتر حاصل شد.
منبع:
https://lnkd.in/dVpS5ZaD
Linkedin
OpenAI’s Kafka throughput grew 20x in the last year across 30+ clusters. | Stanislav Kozlovski
OpenAI’s Kafka throughput grew 20x in the last year across 30+ clusters.
Their setup achieves five 9s (99.999%).
Here’s how they did it 👇
〰️〰️〰️〰️
🟩 𝗖𝗹𝘂𝘀𝘁𝗲𝗿 𝗚𝗿𝗼𝘂𝗽𝘀
They group clusters into groups. Each cluster lives in a separate region.
Through an…
Their setup achieves five 9s (99.999%).
Here’s how they did it 👇
〰️〰️〰️〰️
🟩 𝗖𝗹𝘂𝘀𝘁𝗲𝗿 𝗚𝗿𝗼𝘂𝗽𝘀
They group clusters into groups. Each cluster lives in a separate region.
Through an…
👏2👍1
راهنمای حرفهای ساخت پایپ‌لاین‌های ETL/ELT با Apache Airflow
📘 نگاهی خلاصه به ایبوک ۴۴ صفحه‌ای Astronomer
در سال‌های اخیر، Apache Airflow به استانداردی در حوزه‌ی مدیریت وظایف زمان‌بندی‌شده و ارکستراسیون داده‌ها تبدیل شده است. نسخه‌ی ۳ این ابزار، با ویژگی‌های حرفه‌ای‌تری همچون:
✅ پشتیبانی از Multi-DAG Deployment
✅ اجرای مبتنی بر event از طریق Triggerer
✅ قابلیت DAG Versioning
✅ مصرف مستقیم از Kafka
✅ امکان XCom backendهای سفارشی
✅ Dynamic Task Mapping و Data-driven Scheduling
آن را به انتخابی قدرتمند برای محیط‌های پیچیده داده‌ای و تولیدی تبدیل کرده است.
🔍 اخیراً شرکت Astronomer که خدمات Airflow در فضای ابری را ارائه می‌دهد، یک راهنمای جامع ۴۴ صفحه‌ای با عنوان Best Practices for ETL and ELT Pipelines with Apache Airflow منتشر کرده است که شامل نکات کاربردی و به‌روز برای ساخت پایپ‌لاین‌های حرفهای است.
🗂 خلاصه فهرست مطالب ایبوک:
📌 مفاهیم پایه‌ای
تعریف ETL و ELT، بررسی تفاوت‌ها و سناریوهای ترکیبی (ETLT)
📌 تصمیمات مهم معماری
انتخاب بین XCom یا storage خارجی، اجرای محاسبات درون Airflow یا بیرون، انتخاب اپراتورها، بررسی کیفیت داده
📌 بهترین شیوه‌های نوشتن DAG
ساختار اتمی، idempotent و ماژولار — جلوگیری از top-level code — تنظیم Retry — پیاده‌سازی CI/CD و تست
📌 مقیاس‌پذیری و محیط اجرا
تنظیمات مقیاس در سطح DAG، تسک و محیط — توصیه‌های زیرساختی برای استقرار تولیدی
📌 ویژگی‌های حرفهای Airflow
• امکان Dynamic Task Mapping
• تولید DAGها به‌صورت برنامه‌نویسی‌شده
• امکان Task Group ماژولار
• زمان‌بندی مبتنی بر Dataset
• مدیریت فضای ذخیره سازی - Airflow Object Storage
• استفاده از Kafka و قابلیت DAG Versioning
📌 اتصالات و Providerهای مهم
مروری بر AWS, GCP, Azure, Snowflake, dbt, Spark, Ray, PostgreSQL و Cosmos برای dbt
📌 چک‌لیست نهایی + معرفی Astronomer
چک‌لیستی کامل برای ارزیابی پایپ‌لاین‌ها و مرور امکانات پلتفرم Astronomer
📥 دانلود فایل PDF در پست بعدی 👇
#ApacheAirflow #Kafka #ETL #ELT #DataEngineering #OpenSource #Python #مهندسی_داده #پایپ‌لاین_داده #Airflow3
📘 نگاهی خلاصه به ایبوک ۴۴ صفحه‌ای Astronomer
در سال‌های اخیر، Apache Airflow به استانداردی در حوزه‌ی مدیریت وظایف زمان‌بندی‌شده و ارکستراسیون داده‌ها تبدیل شده است. نسخه‌ی ۳ این ابزار، با ویژگی‌های حرفه‌ای‌تری همچون:
✅ پشتیبانی از Multi-DAG Deployment
✅ اجرای مبتنی بر event از طریق Triggerer
✅ قابلیت DAG Versioning
✅ مصرف مستقیم از Kafka
✅ امکان XCom backendهای سفارشی
✅ Dynamic Task Mapping و Data-driven Scheduling
آن را به انتخابی قدرتمند برای محیط‌های پیچیده داده‌ای و تولیدی تبدیل کرده است.
یکی از رایج‌ترین کاربردهای Airflow، ساخت پایپ‌لاین‌های ETL/ELT است. اما در دنیای امروز با حجم بالای داده، معماری‌های پیچیده و نیاز به مقیاس‌پذیری بالا، پیاده‌سازی این پایپ‌لاین‌ها به‌گونه‌ای که قابل‌اعتماد، مانیتورپذیر و توسعه‌پذیر باشند، چالش‌برانگیز شده است.
🔍 اخیراً شرکت Astronomer که خدمات Airflow در فضای ابری را ارائه می‌دهد، یک راهنمای جامع ۴۴ صفحه‌ای با عنوان Best Practices for ETL and ELT Pipelines with Apache Airflow منتشر کرده است که شامل نکات کاربردی و به‌روز برای ساخت پایپ‌لاین‌های حرفهای است.
🗂 خلاصه فهرست مطالب ایبوک:
📌 مفاهیم پایه‌ای
تعریف ETL و ELT، بررسی تفاوت‌ها و سناریوهای ترکیبی (ETLT)
📌 تصمیمات مهم معماری
انتخاب بین XCom یا storage خارجی، اجرای محاسبات درون Airflow یا بیرون، انتخاب اپراتورها، بررسی کیفیت داده
📌 بهترین شیوه‌های نوشتن DAG
ساختار اتمی، idempotent و ماژولار — جلوگیری از top-level code — تنظیم Retry — پیاده‌سازی CI/CD و تست
📌 مقیاس‌پذیری و محیط اجرا
تنظیمات مقیاس در سطح DAG، تسک و محیط — توصیه‌های زیرساختی برای استقرار تولیدی
📌 ویژگی‌های حرفهای Airflow
• امکان Dynamic Task Mapping
• تولید DAGها به‌صورت برنامه‌نویسی‌شده
• امکان Task Group ماژولار
• زمان‌بندی مبتنی بر Dataset
• مدیریت فضای ذخیره سازی - Airflow Object Storage
• استفاده از Kafka و قابلیت DAG Versioning
📌 اتصالات و Providerهای مهم
مروری بر AWS, GCP, Azure, Snowflake, dbt, Spark, Ray, PostgreSQL و Cosmos برای dbt
📌 چک‌لیست نهایی + معرفی Astronomer
چک‌لیستی کامل برای ارزیابی پایپ‌لاین‌ها و مرور امکانات پلتفرم Astronomer
📥 دانلود فایل PDF در پست بعدی 👇
#ApacheAirflow #Kafka #ETL #ELT #DataEngineering #OpenSource #Python #مهندسی_داده #پایپ‌لاین_داده #Airflow3
❤1
راهنمای حرفهای ساخت پایپ‌لاین‌های ETL/ELT با Apache Airflow
📘 نگاهی خلاصه به ایبوک ۴۴ صفحه‌ای Astronomer
در سال‌های اخیر، Apache Airflow به استانداردی در حوزه‌ی مدیریت وظایف زمان‌بندی‌شده و ارکستراسیون داده‌ها تبدیل شده است. نسخه‌ی ۳ این ابزار، با ویژگی‌های حرفه‌ای‌تری همچون:
✅ پشتیبانی از Multi-DAG Deployment
✅ اجرای مبتنی بر event از طریق Triggerer
✅ قابلیت DAG Versioning
✅ مصرف مستقیم از Kafka
✅ امکان XCom backendهای سفارشی
✅ امکان Dynamic Task Mapping و Data-driven Scheduling
آن را به انتخابی قدرتمند برای محیط‌های پیچیده داده‌ای و تولیدی تبدیل کرده است.
🔍 اخیراً شرکت Astronomer که خدمات Airflow در فضای ابری را ارائه می‌دهد، یک راهنمای جامع ۴۴ صفحه‌ای با عنوان Best Practices for ETL and ELT Pipelines with Apache Airflow منتشر کرده است که شامل نکات کاربردی و به‌روز برای ساخت پایپ‌لاین‌های حرفهای است.
🗂 خلاصه فهرست مطالب ایبوک:
📌 مفاهیم پایه‌ای
تعریف ETL و ELT، بررسی تفاوت‌ها و سناریوهای ترکیبی (ETLT)
📌 تصمیمات مهم معماری
انتخاب بین XCom یا storage خارجی، اجرای محاسبات درون Airflow یا بیرون، انتخاب اپراتورها، بررسی کیفیت داده
📌 بهترین شیوه‌های نوشتن DAG
ساختار اتمی، idempotent و ماژولار — جلوگیری از top-level code — تنظیم Retry — پیاده‌سازی CI/CD و تست
📌 مقیاس‌پذیری و محیط اجرا
تنظیمات مقیاس در سطح DAG، تسک و محیط — توصیه‌های زیرساختی برای استقرار تولیدی
📌 ویژگی‌های حرفهای Airflow
• امکان Dynamic Task Mapping
• تولید DAGها به‌صورت برنامه‌نویسی‌شده
• امکان Task Group ماژولار
• زمان‌بندی مبتنی بر Dataset
• مدیریت فضای ذخیره سازی - Airflow Object Storage
• استفاده از Kafka و قابلیت DAG Versioning
📌 اتصالات و Providerهای مهم
مروری بر AWS, GCP, Azure, Snowflake, dbt, Spark, Ray, PostgreSQL و Cosmos برای dbt
📌 چک‌لیست نهایی + معرفی Astronomer
چک‌لیستی کامل برای ارزیابی پایپ‌لاین‌ها و مرور امکانات پلتفرم Astronomer
📥 دانلود فایل PDF در پست بعدی 👇
#ApacheAirflow #Kafka #ETL #ELT #DataEngineering #OpenSource #Python #مهندسی_داده #پایپ‌لاین_داده #Airflow3
📘 نگاهی خلاصه به ایبوک ۴۴ صفحه‌ای Astronomer
در سال‌های اخیر، Apache Airflow به استانداردی در حوزه‌ی مدیریت وظایف زمان‌بندی‌شده و ارکستراسیون داده‌ها تبدیل شده است. نسخه‌ی ۳ این ابزار، با ویژگی‌های حرفه‌ای‌تری همچون:
✅ پشتیبانی از Multi-DAG Deployment
✅ اجرای مبتنی بر event از طریق Triggerer
✅ قابلیت DAG Versioning
✅ مصرف مستقیم از Kafka
✅ امکان XCom backendهای سفارشی
✅ امکان Dynamic Task Mapping و Data-driven Scheduling
آن را به انتخابی قدرتمند برای محیط‌های پیچیده داده‌ای و تولیدی تبدیل کرده است.
یکی از رایج‌ترین کاربردهای Airflow، ساخت پایپ‌لاین‌های ETL/ELT است. اما در دنیای امروز با حجم بالای داده، معماری‌های پیچیده و نیاز به مقیاس‌پذیری بالا، پیاده‌سازی این پایپ‌لاین‌ها به‌گونه‌ای که قابل‌اعتماد، مانیتورپذیر و توسعه‌پذیر باشند، چالش‌برانگیز شده است.
🔍 اخیراً شرکت Astronomer که خدمات Airflow در فضای ابری را ارائه می‌دهد، یک راهنمای جامع ۴۴ صفحه‌ای با عنوان Best Practices for ETL and ELT Pipelines with Apache Airflow منتشر کرده است که شامل نکات کاربردی و به‌روز برای ساخت پایپ‌لاین‌های حرفهای است.
🗂 خلاصه فهرست مطالب ایبوک:
📌 مفاهیم پایه‌ای
تعریف ETL و ELT، بررسی تفاوت‌ها و سناریوهای ترکیبی (ETLT)
📌 تصمیمات مهم معماری
انتخاب بین XCom یا storage خارجی، اجرای محاسبات درون Airflow یا بیرون، انتخاب اپراتورها، بررسی کیفیت داده
📌 بهترین شیوه‌های نوشتن DAG
ساختار اتمی، idempotent و ماژولار — جلوگیری از top-level code — تنظیم Retry — پیاده‌سازی CI/CD و تست
📌 مقیاس‌پذیری و محیط اجرا
تنظیمات مقیاس در سطح DAG، تسک و محیط — توصیه‌های زیرساختی برای استقرار تولیدی
📌 ویژگی‌های حرفهای Airflow
• امکان Dynamic Task Mapping
• تولید DAGها به‌صورت برنامه‌نویسی‌شده
• امکان Task Group ماژولار
• زمان‌بندی مبتنی بر Dataset
• مدیریت فضای ذخیره سازی - Airflow Object Storage
• استفاده از Kafka و قابلیت DAG Versioning
📌 اتصالات و Providerهای مهم
مروری بر AWS, GCP, Azure, Snowflake, dbt, Spark, Ray, PostgreSQL و Cosmos برای dbt
📌 چک‌لیست نهایی + معرفی Astronomer
چک‌لیستی کامل برای ارزیابی پایپ‌لاین‌ها و مرور امکانات پلتفرم Astronomer
📥 دانلود فایل PDF در پست بعدی 👇
#ApacheAirflow #Kafka #ETL #ELT #DataEngineering #OpenSource #Python #مهندسی_داده #پایپ‌لاین_داده #Airflow3
👍2❤1
شروعی حرفهای برای ورود به دنیای مهندسی داده – رایگان و بین‌المللی🎓
در دنیای امروز، یادگیری مهارت‌های عملی و نزدیک به پروژه‌های واقعی، مهم‌ترین مزیت رقابتی برای ورود به بازار کار حوزه داده است.
اگر شما هم به دنبال فرصتی برای یادگیری ساخت‌یافته، کاربردی، و تحت نظر یک تیم متخصص بین‌المللی هستید، این بوتکمپ رایگان مهندسی داده یک فرصت بی‌نظیر است.
👨🏫 برگزارکننده: Zach Wilson
مؤسس DataExpert.io و از شناخته‌شده‌ترین چهره‌های حوزه داده با بیش از ۱ میلیون دنبال‌کننده در شبکه‌های اجتماعی.
او به‌واسطه تجربه بالا، سادگی در بیان مفاهیم پیچیده، و طراحی مسیرهای یادگیری عملی، توانسته اعتماد هزاران نفر در سراسر دنیا را جلب کند.
🏫 درباره بوتکمپ:
بوتکمپ ۶ هفته‌ای "Community Edition" با هدف توانمندسازی علاقه‌مندان به مهندسی داده، به صورت رایگان و با تمرکز بر مهارت‌های کاربردی برگزار می‌شود.
این برنامه آموزشی، ترکیبی از ویدیوهای آموزشی، تمرین‌های هفتگی با ارزیابی خودکار، پروژه‌های واقعی، و در نهایت صدور مدرک پایان دوره است.
🧠 سرفصل‌های آموزشی:
📚 مدل‌سازی داده‌های بعدی و واقعی – طراحی ساختارهای تحلیلی پیشرفته
📚 پردازش داده‌های کلان با سرعت بالا - Apache Spark و PySpark
📚 ساخت پایپ‌لاین‌های بلادرنگ و مدیریت جریان داده - Apache Flink و Kafka
📚 الگوهای تحلیلی و طراحی شاخص‌های کلیدی عملکرد (KPI)
📚 کیفیت داده و مستندسازی حرفهای مانند Airbnb
📚 مصورسازی داده با Tableau و ارائه اثرگذار یافته‌ها
📚نگهداری و بهبود پایپ‌لاین‌های داده‌ای در محیط واقعی
🎯 چرا این بوتکمپ ارزشمند است؟
🔹 نگاه عملیاتی و واقعی به مسائل مهندسی داده
🔹 طراحی شده توسط تیمی با تجربه بین‌المللی و پروژه‌های کلان
🔹 یادگیری مبتنی بر سناریوهای واقعی شغلی
🔹 مناسب برای افرادی که به‌دنبال مهاجرت شغلی، ارتقای جایگاه کاری یا ورود به بازارهای جهانی هستند
🔹 امکان تعامل با جامعه جهانی مهندسان داده در Discord
🔹 دریافت مدرک پایان دوره به‌صورت رسمی
📥 مراحل ثبت‌نام:
ثبت‌نام رایگان در سایت: learn.dataexpert.io
دریافت هندبوک و تمرین‌ها: https://github.com/DataExpert-io/data-engineer-handbook
عضویت در کامیونیتی و گروه پشتیبانی در دیسکورد: لینک عضویت
ارسال تمرین‌های هفتگی – برای حفظ نظم و یادگیری تدریجی
📌 تا امروز بیش از ۵۰ هزار نفر از سراسر دنیا ثبت‌نام کرده‌اند
🎯 زک ویلسون پیش‌بینی کرده تنها حدود ۵۰۰ نفر به پایان مسیر و دریافت گواهی می‌رسند
اگر دنبال تعهد، رشد حرفهای و یادگیری واقعی هستی، تو هم یکی از آن‌ها باش.
جزو ۱٪ افراد مصمم باش!
#بوتکمپ_داده #مهندسی_داده #DataEngineering #ApacheSpark #Flink #Kafka #SQL #Python #DataQuality #Tableau #آموزش_کاربردی #مدرک_بین‌المللی #ZackWilson #DataExpert #دوره_رایگان #DataCareer
در دنیای امروز، یادگیری مهارت‌های عملی و نزدیک به پروژه‌های واقعی، مهم‌ترین مزیت رقابتی برای ورود به بازار کار حوزه داده است.
اگر شما هم به دنبال فرصتی برای یادگیری ساخت‌یافته، کاربردی، و تحت نظر یک تیم متخصص بین‌المللی هستید، این بوتکمپ رایگان مهندسی داده یک فرصت بی‌نظیر است.
👨🏫 برگزارکننده: Zach Wilson
مؤسس DataExpert.io و از شناخته‌شده‌ترین چهره‌های حوزه داده با بیش از ۱ میلیون دنبال‌کننده در شبکه‌های اجتماعی.
او به‌واسطه تجربه بالا، سادگی در بیان مفاهیم پیچیده، و طراحی مسیرهای یادگیری عملی، توانسته اعتماد هزاران نفر در سراسر دنیا را جلب کند.
🏫 درباره بوتکمپ:
بوتکمپ ۶ هفته‌ای "Community Edition" با هدف توانمندسازی علاقه‌مندان به مهندسی داده، به صورت رایگان و با تمرکز بر مهارت‌های کاربردی برگزار می‌شود.
این برنامه آموزشی، ترکیبی از ویدیوهای آموزشی، تمرین‌های هفتگی با ارزیابی خودکار، پروژه‌های واقعی، و در نهایت صدور مدرک پایان دوره است.
🧠 سرفصل‌های آموزشی:
📚 مدل‌سازی داده‌های بعدی و واقعی – طراحی ساختارهای تحلیلی پیشرفته
📚 پردازش داده‌های کلان با سرعت بالا - Apache Spark و PySpark
📚 ساخت پایپ‌لاین‌های بلادرنگ و مدیریت جریان داده - Apache Flink و Kafka
📚 الگوهای تحلیلی و طراحی شاخص‌های کلیدی عملکرد (KPI)
📚 کیفیت داده و مستندسازی حرفهای مانند Airbnb
📚 مصورسازی داده با Tableau و ارائه اثرگذار یافته‌ها
📚نگهداری و بهبود پایپ‌لاین‌های داده‌ای در محیط واقعی
🎯 چرا این بوتکمپ ارزشمند است؟
🔹 نگاه عملیاتی و واقعی به مسائل مهندسی داده
🔹 طراحی شده توسط تیمی با تجربه بین‌المللی و پروژه‌های کلان
🔹 یادگیری مبتنی بر سناریوهای واقعی شغلی
🔹 مناسب برای افرادی که به‌دنبال مهاجرت شغلی، ارتقای جایگاه کاری یا ورود به بازارهای جهانی هستند
🔹 امکان تعامل با جامعه جهانی مهندسان داده در Discord
🔹 دریافت مدرک پایان دوره به‌صورت رسمی
📥 مراحل ثبت‌نام:
ثبت‌نام رایگان در سایت: learn.dataexpert.io
دریافت هندبوک و تمرین‌ها: https://github.com/DataExpert-io/data-engineer-handbook
عضویت در کامیونیتی و گروه پشتیبانی در دیسکورد: لینک عضویت
ارسال تمرین‌های هفتگی – برای حفظ نظم و یادگیری تدریجی
📌 تا امروز بیش از ۵۰ هزار نفر از سراسر دنیا ثبت‌نام کرده‌اند
🎯 زک ویلسون پیش‌بینی کرده تنها حدود ۵۰۰ نفر به پایان مسیر و دریافت گواهی می‌رسند
اگر دنبال تعهد، رشد حرفهای و یادگیری واقعی هستی، تو هم یکی از آن‌ها باش.
جزو ۱٪ افراد مصمم باش!
#بوتکمپ_داده #مهندسی_داده #DataEngineering #ApacheSpark #Flink #Kafka #SQL #Python #DataQuality #Tableau #آموزش_کاربردی #مدرک_بین‌المللی #ZackWilson #DataExpert #دوره_رایگان #DataCareer
GitHub
GitHub - DataExpert-io/data-engineer-handbook: This is a repo with links to everything you'd ever want to learn about data engineering
This is a repo with links to everything you'd ever want to learn about data engineering - DataExpert-io/data-engineer-handbook
❤1
چطور تسلا با ClickHouse یک پلتفرم مشاهده‌پذیری در مقیاس نجومی ساخت؟
مشاهده‌پذیری در مقیاس کوادریلیون (هزار بیلیارد) با ClickHouse و پروژه‌ای به نام Comet
داستان تغییر زیرساخت observability تسلا از کجا شروع شد ؟
👨💻 مهندس ارشد تسلا Alon Tal، می‌گوید:
«ما به سیستمی نیاز داشتیم که بتونه ده‌ها میلیون ردیف در ثانیه را ingest کنه، سال‌ها داده رو نگه داره، و همچنان real-time پاسخ بده.»
چرا Prometheus کافی نبود؟
🔸 مقیاس‌پذیری افقی محدود
🔸 وابستگی به یک سرور واحد (ریسک از دست دادن کل متریک‌ها)
🔸 مشکلات نگهداری بلندمدت و زبان کوئری محدود
✅ راه‌حل: ساخت یک سیستم جدید به نام Comet
💡 با استفاده از ClickHouse به عنوان هسته‌ی اصلی، تسلا یک پلتفرم metrics محور ساخت که:
📥 داده‌ها را از طریق OTLP و Kafka ingest میکند
⚙️ با ETLهای سفارشی داده‌ها را به شکل ساخت‌یافته وارد ClickHouse میکند
🔄 و مهم‌تر از همه:
کوئری‌های PromQL را به SQL معادل در ClickHouse ترجمه میکند بدون اینکه مهندسان متوجه تفاوت شوند!
🧠 یعنی داشبوردهای موجود (Grafana، Alertmanager، و...) بدون تغییر کار می‌کنند!
💥 مقیاس واقعی؟
یک میلیارد ردیف در ثانیه! به مدت ۱۱ روز پیاپی!
نتیجه؟
🔹 بدون یک خطا
🔹 مصرف ثابت RAM و CPU
🔹 بیش از ۱ کوادریلیون رکورد با موفقیت ingest شده!
📊 سیستم هنوز هم در حال scale شدن برای تیم‌های داخلی تسلاست!
✨ چرا ClickHouse؟
🔹 سرعت بی‌رقیب در پاسخ به کوئری‌های پیچیده
🔹 UDFهای اجرایی برای کوئری‌های غیر trivial
🔹 پشتیبانی از PromQL و TraceQL
🔹 نگهداری بلندمدت داده‌ها با حجم بالا
🔹 و مهم‌تر از همه: قابلیت اطمینان بالا در مقیاس تسلا!
🔭 آینده‌ی Comet؟
🔧 پشتیبانی از distributed tracing
🌍 احتمال open-source شدن
🎯 گسترش به دیگر واحدهای عملیاتی در تسلا
📎 جمع‌بندی
تسلا با پروژه‌ی Comet ثابت کرد که observability در مقیاس سیاره‌ای ممکن است—اگر ابزار مناسب انتخاب شود!
✅ حالا واقعا پرومتئوس حذف شد؟
تسلا Prometheus رو به‌طور مستقیم حذف نکرد، ولی:
🌟دیگه از خود Prometheus برای ذخیره‌سازی و کوئری استفاده نمی‌کنه.
🌟 به‌جاش، پلتفرمی به نام Comet ساخت که خودش می‌تونه PromQL (زبان کوئری Prometheus) رو اجرا کنه و پشت صحنه با کلیک‌هوس ارتباط بگیره و خروجی بده بدون اینکه واقعاً Prometheus وجود داشته باشه!
🔗 منبع اصلی:
https://clickhouse.com/blog/how-tesla-built-quadrillion-scale-observability-platform-on-clickhouse
#ClickHouse #Observability #Tesla #PromQL #DataEngineering #Scalability #TimeSeries #Kafka #DevOps #OpenTelemetry #Infrastructure
مشاهده‌پذیری در مقیاس کوادریلیون (هزار بیلیارد) با ClickHouse و پروژه‌ای به نام Comet
داستان تغییر زیرساخت observability تسلا از کجا شروع شد ؟
🔧 چند میلیون خودرو متصل، هزاران زیرسیستم توزیع‌شده، و گیگافکتوری‌هایی که شبانه‌روز داده می‌فرستند. تسلا در چنین مقیاسی نمی‌توانست روی Prometheus حساب باز کند...
👨💻 مهندس ارشد تسلا Alon Tal، می‌گوید:
«ما به سیستمی نیاز داشتیم که بتونه ده‌ها میلیون ردیف در ثانیه را ingest کنه، سال‌ها داده رو نگه داره، و همچنان real-time پاسخ بده.»
چرا Prometheus کافی نبود؟
🔸 مقیاس‌پذیری افقی محدود
🔸 وابستگی به یک سرور واحد (ریسک از دست دادن کل متریک‌ها)
🔸 مشکلات نگهداری بلندمدت و زبان کوئری محدود
✅ راه‌حل: ساخت یک سیستم جدید به نام Comet
💡 با استفاده از ClickHouse به عنوان هسته‌ی اصلی، تسلا یک پلتفرم metrics محور ساخت که:
📥 داده‌ها را از طریق OTLP و Kafka ingest میکند
⚙️ با ETLهای سفارشی داده‌ها را به شکل ساخت‌یافته وارد ClickHouse میکند
🔄 و مهم‌تر از همه:
کوئری‌های PromQL را به SQL معادل در ClickHouse ترجمه میکند بدون اینکه مهندسان متوجه تفاوت شوند!
🧠 یعنی داشبوردهای موجود (Grafana، Alertmanager، و...) بدون تغییر کار می‌کنند!
💥 مقیاس واقعی؟
یک میلیارد ردیف در ثانیه! به مدت ۱۱ روز پیاپی!
نتیجه؟
🔹 بدون یک خطا
🔹 مصرف ثابت RAM و CPU
🔹 بیش از ۱ کوادریلیون رکورد با موفقیت ingest شده!
📊 سیستم هنوز هم در حال scale شدن برای تیم‌های داخلی تسلاست!
✨ چرا ClickHouse؟
🔹 سرعت بی‌رقیب در پاسخ به کوئری‌های پیچیده
🔹 UDFهای اجرایی برای کوئری‌های غیر trivial
🔹 پشتیبانی از PromQL و TraceQL
🔹 نگهداری بلندمدت داده‌ها با حجم بالا
🔹 و مهم‌تر از همه: قابلیت اطمینان بالا در مقیاس تسلا!
🔭 آینده‌ی Comet؟
🔧 پشتیبانی از distributed tracing
🌍 احتمال open-source شدن
🎯 گسترش به دیگر واحدهای عملیاتی در تسلا
📎 جمع‌بندی
تسلا با پروژه‌ی Comet ثابت کرد که observability در مقیاس سیاره‌ای ممکن است—اگر ابزار مناسب انتخاب شود!
✅ حالا واقعا پرومتئوس حذف شد؟
تسلا Prometheus رو به‌طور مستقیم حذف نکرد، ولی:
🌟دیگه از خود Prometheus برای ذخیره‌سازی و کوئری استفاده نمی‌کنه.
🌟 به‌جاش، پلتفرمی به نام Comet ساخت که خودش می‌تونه PromQL (زبان کوئری Prometheus) رو اجرا کنه و پشت صحنه با کلیک‌هوس ارتباط بگیره و خروجی بده بدون اینکه واقعاً Prometheus وجود داشته باشه!
🔗 منبع اصلی:
https://clickhouse.com/blog/how-tesla-built-quadrillion-scale-observability-platform-on-clickhouse
#ClickHouse #Observability #Tesla #PromQL #DataEngineering #Scalability #TimeSeries #Kafka #DevOps #OpenTelemetry #Infrastructure
ClickHouse
How Tesla built a quadrillion-scale observability platform on ClickHouse
“Data in ClickHouse is better than data anywhere else. No other system lets you slice and dice your data, ask interesting questions, and get answers in an acceptable amount of time. There’s nothing out there that competes with ClickHouse.” Alon Tal, Senio
👍4❤1
آپاچی کافکا، ستون فقرات معماری‌های داده‌محور... اما نه همیشه!
برای بسیاری از ما، آپاچی کافکا #Kafka نماد مقیاس‌پذیری، پایداری و قدرت در طراحی معماری‌های real-time و event-driven است.
اما اگر نیاز ما صرفاً یک ورود ساده‌ی داده (ingestion) بدون نیاز به بازپخش (replay) یا چند مصرف‌کننده مستقل (consumer) باشد، آیا باز هم کافکا انتخاب درستی است؟
🧵 در یک مقاله دقیق از تیم ThreadSafe Diaries، همین سؤال مطرح شده و آن‌ها تلاش کردند برای بخشی از سیستم خود، راه‌حلی ساده‌تر و کارآمدتر پیدا کنند. این پست، چکیده‌ای از تجربه‌ی آن‌هاست:
🔗 لینک مقاله کامل
📉 چالش‌ها و مشکلات معماری مبتنی بر آپاچی کافکا:
🔸 استفاده از کافکا + ZooKeeper با خوشه‌ای ۳ نودی برای ingest داده‌های تحلیلی
🔸 تنها با ۱۸هزار رویداد در ثانیه، سیستم دچار مشکلات زیر شد:
⚠️ تأخیرهای مداوم در مصرف‌کننده‌ها (Consumer Lag)
⚠️ اختلالات در offset و هماهنگی (Coordination)
⚠️ فشار زیاد روی دیسک و هزینه بالای زیرساخت (EC2 + EBS)
⚠️ نیاز مداوم به پشتیبانی عملیاتی و تیم DevOps
در نهایت تیم متوجه شد که بسیاری از قابلیت‌های کافکا (مثل replayability، چند مصرف‌کننده، یا تحمل‌پذیری بالا) اصلاً در این سناریو مورد نیاز نبود.
✅ راه‌حل ساده‌تر و مؤثرتر چه بود؟
🔹 استفاده از ترکیب Redis Streams و یک مجموعه Go workerهای بدون‌حالت (stateless)
معماری پیشنهادی به شکل زیر پیاده‌سازی شد:
📨 ارسال دسته‌ای رویدادها از سمت فرانت‌اند (هر ۳ تا ۵ ثانیه)
🧩 یک API سبک برای دریافت و ذخیره در Redis Streams
⚙️ مجموعه‌ای از Go workerها که داده‌ها را از stream خوانده و به Postgres، S3 یا سرویس‌های ML می‌فرستند
📊 دستاوردهای معماری جدید با Redis Streams:
- افزایش نرخ پردازش: از ۱۸هزار به ۴۲هزار رویداد در ثانیه (۲.۳×)
- کاهش تأخیر: از ۲۵ms به ۳.۲ms (۷.۸× سریع‌تر)
- صرفه‌جویی در هزینه: از ۳,۲۰۰ دلار به ۱,۰۵۰ دلار در ماه (۶۷٪ کاهش)
- کاهش هشدارهای عملیاتی: از ۴–۵ بار در ماه به صفر تماس اضطراری
💡 آیا این یعنی آپاچی کافکا دیگر مفید نیست؟ قطعاً نه!
کافکا همچنان در معماری‌هایی که به قابلیت بازپخش، fan-out، تحمل خطا، یا مصرف‌کننده‌های موازی نیاز دارند، ابزاری بی‌رقیب است.
اما وقتی نیازها ساده‌ترند، این ابزار سنگین تبدیل به سربار می‌شود:
🔸 پیچیدگی عملیاتی، هزینه و زمان توسعه و نگهداری بیشتر
📚 درس‌هایی که تیم آموخت:
🔹 تا زمانی که واقعاً به ویژگی‌هایی مانند دوام بالا، بازپخش رویدادها و چند مصرف‌کننده همزمان نیاز ندارید، سراغ آپاچی کافکا نروید.
🔹 طراحی باید بر اساس جریان داده انجام شود، نه با فرض اینکه ابزار خاصی الزاماً باید در معماری وجود داشته باشد. در این پروژه، نیاز فقط دریافت، پردازش و ارسال ساده رویدادها بود.
🔹 بنچمارک واقعی همیشه بهتر از فرضیات است؛ Redis در تست‌های عملی، عملکرد بهتری از کافکا داشت — نه صرفاً روی کاغذ یا در مستندات.
🔹 هزینه زیرساخت بخشی از معماری است؛ قدرت کافکا "رایگان" نیست و در قالب منابع محاسباتی، عملیات پشتیبانی و زمان توسعه‌دهندگان خود را نشان می‌دهد.
🔹 پیچیدگی مهاجرت و نگهداری مهم است؛ گاهی فقط نیاز به ارتقاء (مثل مهاجرت از ZooKeeper به KRaft) می‌تواند دلیلی کافی برای بازطراحی معماری باشد.
✅ نتیجه‌گیری:
انتخاب ابزار مناسب، بیش از آنکه به «قدرت» آن مربوط باشد، به تناسبش با نیاز واقعی سیستم شما بستگی دارد. سادگی، وقتی به‌درستی انتخاب شود، می‌تواند بهترین ابزار مهندسی باشد.
برای بسیاری از ما، آپاچی کافکا #Kafka نماد مقیاس‌پذیری، پایداری و قدرت در طراحی معماری‌های real-time و event-driven است.
اما اگر نیاز ما صرفاً یک ورود ساده‌ی داده (ingestion) بدون نیاز به بازپخش (replay) یا چند مصرف‌کننده مستقل (consumer) باشد، آیا باز هم کافکا انتخاب درستی است؟
🧵 در یک مقاله دقیق از تیم ThreadSafe Diaries، همین سؤال مطرح شده و آن‌ها تلاش کردند برای بخشی از سیستم خود، راه‌حلی ساده‌تر و کارآمدتر پیدا کنند. این پست، چکیده‌ای از تجربه‌ی آن‌هاست:
🔗 لینک مقاله کامل
📉 چالش‌ها و مشکلات معماری مبتنی بر آپاچی کافکا:
🔸 استفاده از کافکا + ZooKeeper با خوشه‌ای ۳ نودی برای ingest داده‌های تحلیلی
🔸 تنها با ۱۸هزار رویداد در ثانیه، سیستم دچار مشکلات زیر شد:
⚠️ تأخیرهای مداوم در مصرف‌کننده‌ها (Consumer Lag)
⚠️ اختلالات در offset و هماهنگی (Coordination)
⚠️ فشار زیاد روی دیسک و هزینه بالای زیرساخت (EC2 + EBS)
⚠️ نیاز مداوم به پشتیبانی عملیاتی و تیم DevOps
در نهایت تیم متوجه شد که بسیاری از قابلیت‌های کافکا (مثل replayability، چند مصرف‌کننده، یا تحمل‌پذیری بالا) اصلاً در این سناریو مورد نیاز نبود.
✅ راه‌حل ساده‌تر و مؤثرتر چه بود؟
🔹 استفاده از ترکیب Redis Streams و یک مجموعه Go workerهای بدون‌حالت (stateless)
معماری پیشنهادی به شکل زیر پیاده‌سازی شد:
📨 ارسال دسته‌ای رویدادها از سمت فرانت‌اند (هر ۳ تا ۵ ثانیه)
🧩 یک API سبک برای دریافت و ذخیره در Redis Streams
⚙️ مجموعه‌ای از Go workerها که داده‌ها را از stream خوانده و به Postgres، S3 یا سرویس‌های ML می‌فرستند
📊 دستاوردهای معماری جدید با Redis Streams:
- افزایش نرخ پردازش: از ۱۸هزار به ۴۲هزار رویداد در ثانیه (۲.۳×)
- کاهش تأخیر: از ۲۵ms به ۳.۲ms (۷.۸× سریع‌تر)
- صرفه‌جویی در هزینه: از ۳,۲۰۰ دلار به ۱,۰۵۰ دلار در ماه (۶۷٪ کاهش)
- کاهش هشدارهای عملیاتی: از ۴–۵ بار در ماه به صفر تماس اضطراری
💡 آیا این یعنی آپاچی کافکا دیگر مفید نیست؟ قطعاً نه!
کافکا همچنان در معماری‌هایی که به قابلیت بازپخش، fan-out، تحمل خطا، یا مصرف‌کننده‌های موازی نیاز دارند، ابزاری بی‌رقیب است.
اما وقتی نیازها ساده‌ترند، این ابزار سنگین تبدیل به سربار می‌شود:
🔸 پیچیدگی عملیاتی، هزینه و زمان توسعه و نگهداری بیشتر
📚 درس‌هایی که تیم آموخت:
🔹 تا زمانی که واقعاً به ویژگی‌هایی مانند دوام بالا، بازپخش رویدادها و چند مصرف‌کننده همزمان نیاز ندارید، سراغ آپاچی کافکا نروید.
🔹 طراحی باید بر اساس جریان داده انجام شود، نه با فرض اینکه ابزار خاصی الزاماً باید در معماری وجود داشته باشد. در این پروژه، نیاز فقط دریافت، پردازش و ارسال ساده رویدادها بود.
🔹 بنچمارک واقعی همیشه بهتر از فرضیات است؛ Redis در تست‌های عملی، عملکرد بهتری از کافکا داشت — نه صرفاً روی کاغذ یا در مستندات.
🔹 هزینه زیرساخت بخشی از معماری است؛ قدرت کافکا "رایگان" نیست و در قالب منابع محاسباتی، عملیات پشتیبانی و زمان توسعه‌دهندگان خود را نشان می‌دهد.
🔹 پیچیدگی مهاجرت و نگهداری مهم است؛ گاهی فقط نیاز به ارتقاء (مثل مهاجرت از ZooKeeper به KRaft) می‌تواند دلیلی کافی برای بازطراحی معماری باشد.
✅ نتیجه‌گیری:
انتخاب ابزار مناسب، بیش از آنکه به «قدرت» آن مربوط باشد، به تناسبش با نیاز واقعی سیستم شما بستگی دارد. سادگی، وقتی به‌درستی انتخاب شود، می‌تواند بهترین ابزار مهندسی باشد.
👍7❤2
پردازش ۱.۲ میلیون پیام در ثانیه با Kafka و Go — معماری سبک اما حرفهای 🎯
وقتی نرخ ورود داده به میلیون‌ها پیام در ثانیه می‌رسد، عامل تعیین‌کننده در یک معماری بهینه و سریع و موثر، نه ارتقای پرهزینه‌ی سخت‌افزار است و نه تکیه بر زیرساخت‌های سنگین ابری، بلکه یک طراحی دقیق، ساده و هوشمندانه است که می‌تواند تفاوت واقعی را رقم بزند.
📖 اخیراً با مقاله‌ای مواجه شدم که دقیقاً همین رویکرد را نشان می‌داد: تیمی که با استفاده از مفاهیم سبک‌وزن مانند goroutine در Go و چند تصمیم مهندسی‌شده، توانسته بودند تنها با یک سخت‌افزار معمولی، بیش از ۱ میلیون پیام در ثانیه را به‌صورت پایدار پردازش کنند.
در این پست، به مرور نکات کلیدی این معماری ساده اما تأثیرگذار می‌پردازیم — روایتی کاربردی از دنیای مهندسی داده و سیستم‌های توزیع‌شده.
📄 مقاله اصلی:
Kafka at 1M Messages/Second with Go – Our Exact Pipeline Setup 👉 https://freedium.cfd/https://medium.com/@harishsingh8529/kafka-at-1m-messages-second-with-go-our-exact-pipeline-setup-aa2c5473b139
📦 چالش‌ها:
⚠️هجوم سنگین داده‌ها از دستگاه‌های IoT و کاربران
⚠️نیاز به پردازش بلادرنگ و ارسال همزمان به چند سرویس
⚠️تضمین پایداری، مانیتورینگ دقیق و ریکاوری خودکار در خطا
🛠 مکانیزم‌هایی که این معماری را ممکن کردند:
✅ کامیت دستی offsetها:
تأیید دریافت فقط زمانی انجام می‌شود که پیام کاملاً و با موفقیت پردازش شده باشد — جلوگیری از گم‌شدن یا پردازش تکراری داده‌ها.
✅ مکانیزم Worker Pool کنترل‌شده با goroutine:
به‌جای ایجاد goroutine برای هر پیام، یک استخر ثابت از goroutineها (به ازای هر پارتیشن کافکا) با طول کانال مشخص و محدود، تعریف شده است که پیام‌ها را موازی اما کنترل‌شده پردازش می‌کنند.
✅ یک Worker Pool به ازای هر پارتیشن Kafka:
مثلاً با ۱۰ پارتیشن و ۵ goroutine برای هر پارتیشن، در مجموع ۵۰ goroutine داریم — بدون هم‌پوشانی، بدون رقابت اضافه.
✅ الگوی Dispatcher برای جداسازی دریافت از پردازش:
- بخش اول: فقط دریافت پیام و ارسال به کانال داخلی (یک کانسیومر به ازای هر پارتیشن)
- بخش دوم: پردازش پیام از صف به کمک Worker Pool
✅ دسته بندی پیام ها یا Batching در ارسال خروجی:
پیام‌های پردازش‌شده به‌صورت گروهی ارسال می‌شوند، مثلاً به دیتابیس یا تاپیک‌های دیگر Kafka. این کار فشار ارتباطی را کاهش داده و throughput را بالا برده است.
✅مکانیزم Backpressure هوشمند:
با محدود کردن ظرفیت صف‌ها، اگر سیستم تحت فشار شدید قرار گیرد، مصرف از Kafka موقتاً کند یا متوقف می‌شود تا منابع آزاد شوند. این مکانیزم، از overload جلوگیری کرده و سیستم را در حالت پایدار نگه می‌دارد.
✅مانیتورینگ دقیق با Prometheus و Grafana:
شاخص‌هایی مثل تأخیر پردازش، consumer lag و مصرف CPU به‌صورت لحظه‌ای مانیتور می‌شوند — برای تنظیم سریع و واکنش فوری.
📊 نتایج:
- نرخ پردازش: ۱.۲M msg/sec
- تأخیر کل مسیر: <۳ms
- مصرف CPU: ۹۰٪ (پایدار و قابل پیش‌بینی)
💡 نکات مهم برای مهندسان داده و سیستم‌های توزیع‌شده:
🔹طراحی درست مهم‌تر از افزایش منابع
🔹 طراحی commit دقیق، batching و backpressure = ستون‌های یک سیستم مقاوم
🔹تفکیک دریافت/پردازش + تقسیم کار بین پارتیشن‌ها = مقیاس‌پذیری مؤثر
🔹مانیتورینگ لحظه‌ای = پاسخ سریع به فشارها و خطاها
#Kafka #GoLang #DataEngineering #HighThroughput #Concurrency #RealTime #ScalableArchitecture #مهندسی_داده #سیستم_توزیع_یافته #معماری_مقیاس‌پذیر
وقتی نرخ ورود داده به میلیون‌ها پیام در ثانیه می‌رسد، عامل تعیین‌کننده در یک معماری بهینه و سریع و موثر، نه ارتقای پرهزینه‌ی سخت‌افزار است و نه تکیه بر زیرساخت‌های سنگین ابری، بلکه یک طراحی دقیق، ساده و هوشمندانه است که می‌تواند تفاوت واقعی را رقم بزند.
📖 اخیراً با مقاله‌ای مواجه شدم که دقیقاً همین رویکرد را نشان می‌داد: تیمی که با استفاده از مفاهیم سبک‌وزن مانند goroutine در Go و چند تصمیم مهندسی‌شده، توانسته بودند تنها با یک سخت‌افزار معمولی، بیش از ۱ میلیون پیام در ثانیه را به‌صورت پایدار پردازش کنند.
در این پست، به مرور نکات کلیدی این معماری ساده اما تأثیرگذار می‌پردازیم — روایتی کاربردی از دنیای مهندسی داده و سیستم‌های توزیع‌شده.
📄 مقاله اصلی:
Kafka at 1M Messages/Second with Go – Our Exact Pipeline Setup 👉 https://freedium.cfd/https://medium.com/@harishsingh8529/kafka-at-1m-messages-second-with-go-our-exact-pipeline-setup-aa2c5473b139
📦 چالش‌ها:
⚠️هجوم سنگین داده‌ها از دستگاه‌های IoT و کاربران
⚠️نیاز به پردازش بلادرنگ و ارسال همزمان به چند سرویس
⚠️تضمین پایداری، مانیتورینگ دقیق و ریکاوری خودکار در خطا
🛠 مکانیزم‌هایی که این معماری را ممکن کردند:
✅ کامیت دستی offsetها:
تأیید دریافت فقط زمانی انجام می‌شود که پیام کاملاً و با موفقیت پردازش شده باشد — جلوگیری از گم‌شدن یا پردازش تکراری داده‌ها.
✅ مکانیزم Worker Pool کنترل‌شده با goroutine:
به‌جای ایجاد goroutine برای هر پیام، یک استخر ثابت از goroutineها (به ازای هر پارتیشن کافکا) با طول کانال مشخص و محدود، تعریف شده است که پیام‌ها را موازی اما کنترل‌شده پردازش می‌کنند.
✅ یک Worker Pool به ازای هر پارتیشن Kafka:
مثلاً با ۱۰ پارتیشن و ۵ goroutine برای هر پارتیشن، در مجموع ۵۰ goroutine داریم — بدون هم‌پوشانی، بدون رقابت اضافه.
✅ الگوی Dispatcher برای جداسازی دریافت از پردازش:
- بخش اول: فقط دریافت پیام و ارسال به کانال داخلی (یک کانسیومر به ازای هر پارتیشن)
- بخش دوم: پردازش پیام از صف به کمک Worker Pool
✅ دسته بندی پیام ها یا Batching در ارسال خروجی:
پیام‌های پردازش‌شده به‌صورت گروهی ارسال می‌شوند، مثلاً به دیتابیس یا تاپیک‌های دیگر Kafka. این کار فشار ارتباطی را کاهش داده و throughput را بالا برده است.
✅مکانیزم Backpressure هوشمند:
با محدود کردن ظرفیت صف‌ها، اگر سیستم تحت فشار شدید قرار گیرد، مصرف از Kafka موقتاً کند یا متوقف می‌شود تا منابع آزاد شوند. این مکانیزم، از overload جلوگیری کرده و سیستم را در حالت پایدار نگه می‌دارد.
✅مانیتورینگ دقیق با Prometheus و Grafana:
شاخص‌هایی مثل تأخیر پردازش، consumer lag و مصرف CPU به‌صورت لحظه‌ای مانیتور می‌شوند — برای تنظیم سریع و واکنش فوری.
📊 نتایج:
- نرخ پردازش: ۱.۲M msg/sec
- تأخیر کل مسیر: <۳ms
- مصرف CPU: ۹۰٪ (پایدار و قابل پیش‌بینی)
💡 نکات مهم برای مهندسان داده و سیستم‌های توزیع‌شده:
🔹طراحی درست مهم‌تر از افزایش منابع
🔹 طراحی commit دقیق، batching و backpressure = ستون‌های یک سیستم مقاوم
🔹تفکیک دریافت/پردازش + تقسیم کار بین پارتیشن‌ها = مقیاس‌پذیری مؤثر
🔹مانیتورینگ لحظه‌ای = پاسخ سریع به فشارها و خطاها
#Kafka #GoLang #DataEngineering #HighThroughput #Concurrency #RealTime #ScalableArchitecture #مهندسی_داده #سیستم_توزیع_یافته #معماری_مقیاس‌پذیر
شمارش بازدیدها و اکشن‌های کاربر با فناوری‌های مدرن داده
در پست قبلی درباره روش‌های کلاسیک شمارش بازدید محصولات یا تماشای ویدئو صحبت کردم.
https://t.iss.one/bigdata_ir/445
اما امروز می‌خواهیم به سراغ راهکارهای مدرن‌تر برویم. پیشرفتهای اخیر در استک‌های داده، امکانات جدیدی برای ما فراهم کرده که فقط محدود به شمارش ساده نیستند.
🎯 هدف ما فقط شمارش نیست!
آنچه امروز اهمیت دارد، ذخیره‌سازی دقیق تمام اکشن‌های کاربر است.
چرا؟
✅برای شخصی‌سازی تجربه کاربری بر اساس رفتار هر فرد
✅برای تحلیل عمیق روی محصولات یا ویدئوها و بهبود تجربه کاربران
پس راهکار ایده‌آل باید هم شمارش و هم ذخیره‌سازی کامل داده‌ها را پوشش دهد.
🛠 سه راهکار مدرن برای شمارش و ذخیره اکشن‌ها
1️⃣ استفاده از Cassandra / ScyllaDB و قابلیت Distributed Counter
🎯برای هر کاربر و هر محصول، یک جدول بازدید ایجاد می‌کنیم
🎯هر اکشن را در هر دو جدول ذخیره می‌کنیم (مدل داده این دیتابیس‌ها بر اساس Query طراحی می‌شود)
🎯شمارش اکشن‌ها با Distributed Counter انجام می‌شود
🎯امکان تعریف شمارنده برای بازه‌های زمانی مختلف (ساعتی، روزانه و...) وجود دارد
✅مزیت اصلی: مقیاس‌پذیری بالا و سرعت فوق‌العاده
2️⃣ ذخیره خام داده‌ها در قالب Apache Iceberg با AutoMQ
🎯جایگزین Kafka سنتی با AutoMQ
🎯 پیام رسان AutoMQ که دقیقا منطبق بر استاندارد کافکا است، پیام‌ها را مستقیماً در Iceberg ذخیره میکند
🎯شمارش با Flink + Redis انجام می‌شود
🎯امکان تحلیل بعدی رفتار کاربران با ابزارهایی مثل ClickHouse یا Spark
✅مزیت اصلی: فشار کمتر روی دیتابیس اصلی و نگهداری داده‌های خام برای تحلیل‌های آینده
3️⃣ استفاده از دیتابیس جریانی RisingWave – سریع، مدرن و چندکاره 🚀
دیتابیس RisingWave یک دیتابیس جریانی (Streaming Database) است که با استاندارد PostgreSQL توسعه یافته و از SQL به‌عنوان زبان اصلی پردازش داده‌های جریانی استفاده میکند.
📌 ویژگی‌ها و مزایا:
🎯شمارش و پردازش جریانی با SQL ساده → ایجاد Materialized Viewها برای شمارش بازدیدها و اکشن‌ها در لحظه
🎯ذخیره اکشن‌ها در S3 و Iceberg → امکان نگهداری داده‌های خام برای تحلیل‌های آینده
🎯سرعت بالا به لطف Rust → هسته سیستم با زبان Rust نوشته شده و از مزایای کارایی و مصرف کم منابع بهره می‌برد
🎯پشتیبانی از Sinkهای متنوع → خروجی مستقیم به دیتابیس‌ها، سیستم‌های پیام‌رسان، S3، Kafka و...
🎯پردازش رویدادهای پیچیده → اجرای Queryهای تحلیلی پیشرفته بر روی جریان داده بدون نیاز به ابزار جداگانه
✅ نتیجه؟
با RisingWave می‌توان علاوه بر شمارش بازدید و اکشن‌ها، بسیاری از پردازش‌های همزمان و تحلیل‌های اولیه را نیز انجام داد، بدون نیاز به زیرساخت پیچیده و چندلایه.
📌 جمع‌بندی
این سه راهکار نسبت به روش‌های سنتی و حتی رویکرد Kafka + Flink، مدرن‌تر هستند و از فناوری‌های جدید حوزه داده بهره می‌برند.
اگر در حال طراحی یا ارتقای بخش شمارش بازدید و اکشن‌ها هستید، پیشنهاد میکنم این گزینه‌ها را نیز بررسی کنید.
#DataEngineering #StreamingData #RealTimeAnalytics #Kafka #Flink #Iceberg #ClickHouse #RisingWave #ScyllaDB #BigData #UserAnalytics #TechInnovation #RustLang #SQL
در پست قبلی درباره روش‌های کلاسیک شمارش بازدید محصولات یا تماشای ویدئو صحبت کردم.
https://t.iss.one/bigdata_ir/445
به‌طور خلاصه گفتیم که در بار ترافیکی بالا، بهتر است بازدیدها را در حافظه نگهداری و جمع‌بندی کرده، سپس در بازه‌های زمانی مشخص وارد دیتابیس کنیم. همچنین به رویکرد پیشرفته‌تری با Kafka + Flink برای ایجاد بافر و بروزرسانی دوره‌ای دیتابیس اشاره شد.
اما امروز می‌خواهیم به سراغ راهکارهای مدرن‌تر برویم. پیشرفتهای اخیر در استک‌های داده، امکانات جدیدی برای ما فراهم کرده که فقط محدود به شمارش ساده نیستند.
🎯 هدف ما فقط شمارش نیست!
آنچه امروز اهمیت دارد، ذخیره‌سازی دقیق تمام اکشن‌های کاربر است.
چرا؟
✅برای شخصی‌سازی تجربه کاربری بر اساس رفتار هر فرد
✅برای تحلیل عمیق روی محصولات یا ویدئوها و بهبود تجربه کاربران
پس راهکار ایده‌آل باید هم شمارش و هم ذخیره‌سازی کامل داده‌ها را پوشش دهد.
🛠 سه راهکار مدرن برای شمارش و ذخیره اکشن‌ها
1️⃣ استفاده از Cassandra / ScyllaDB و قابلیت Distributed Counter
🎯برای هر کاربر و هر محصول، یک جدول بازدید ایجاد می‌کنیم
🎯هر اکشن را در هر دو جدول ذخیره می‌کنیم (مدل داده این دیتابیس‌ها بر اساس Query طراحی می‌شود)
🎯شمارش اکشن‌ها با Distributed Counter انجام می‌شود
🎯امکان تعریف شمارنده برای بازه‌های زمانی مختلف (ساعتی، روزانه و...) وجود دارد
✅مزیت اصلی: مقیاس‌پذیری بالا و سرعت فوق‌العاده
2️⃣ ذخیره خام داده‌ها در قالب Apache Iceberg با AutoMQ
🎯جایگزین Kafka سنتی با AutoMQ
🎯 پیام رسان AutoMQ که دقیقا منطبق بر استاندارد کافکا است، پیام‌ها را مستقیماً در Iceberg ذخیره میکند
🎯شمارش با Flink + Redis انجام می‌شود
🎯امکان تحلیل بعدی رفتار کاربران با ابزارهایی مثل ClickHouse یا Spark
✅مزیت اصلی: فشار کمتر روی دیتابیس اصلی و نگهداری داده‌های خام برای تحلیل‌های آینده
3️⃣ استفاده از دیتابیس جریانی RisingWave – سریع، مدرن و چندکاره 🚀
دیتابیس RisingWave یک دیتابیس جریانی (Streaming Database) است که با استاندارد PostgreSQL توسعه یافته و از SQL به‌عنوان زبان اصلی پردازش داده‌های جریانی استفاده میکند.
📌 ویژگی‌ها و مزایا:
🎯شمارش و پردازش جریانی با SQL ساده → ایجاد Materialized Viewها برای شمارش بازدیدها و اکشن‌ها در لحظه
🎯ذخیره اکشن‌ها در S3 و Iceberg → امکان نگهداری داده‌های خام برای تحلیل‌های آینده
🎯سرعت بالا به لطف Rust → هسته سیستم با زبان Rust نوشته شده و از مزایای کارایی و مصرف کم منابع بهره می‌برد
🎯پشتیبانی از Sinkهای متنوع → خروجی مستقیم به دیتابیس‌ها، سیستم‌های پیام‌رسان، S3، Kafka و...
🎯پردازش رویدادهای پیچیده → اجرای Queryهای تحلیلی پیشرفته بر روی جریان داده بدون نیاز به ابزار جداگانه
✅ نتیجه؟
با RisingWave می‌توان علاوه بر شمارش بازدید و اکشن‌ها، بسیاری از پردازش‌های همزمان و تحلیل‌های اولیه را نیز انجام داد، بدون نیاز به زیرساخت پیچیده و چندلایه.
📌 جمع‌بندی
این سه راهکار نسبت به روش‌های سنتی و حتی رویکرد Kafka + Flink، مدرن‌تر هستند و از فناوری‌های جدید حوزه داده بهره می‌برند.
اگر در حال طراحی یا ارتقای بخش شمارش بازدید و اکشن‌ها هستید، پیشنهاد میکنم این گزینه‌ها را نیز بررسی کنید.
#DataEngineering #StreamingData #RealTimeAnalytics #Kafka #Flink #Iceberg #ClickHouse #RisingWave #ScyllaDB #BigData #UserAnalytics #TechInnovation #RustLang #SQL
👍5
آیا ردیس همچنان پادشاه حافظه‌هاست ؟ 👑
در دنیای فناوری، حتی محبوب‌ترین ابزارها هم برای ادامه مسیر به رقیب نیاز دارند. همان‌طور که در حوزه پردازش جریان، ظهور #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
آغاز به کار رسمی مدرسه مهندسی داده سپهرام
با افتخار اعلام میکنم که وب‌سایت 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
از 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
کافکا 4.1 و قابلیت جدید Share Groups: نزدیک شدن Kafka به یک صف توزیع شده واقعی
🎯 راهکار Kafka 4.1 با KIP-932
در نسخه ۴.۱ و با معرفی KIP-932، یک لایه مدیریتی جدید اضافه شد که پیام‌ها را از پارتیشن‌ها دریافت میکند و سپس آن‌ها را به کانسیومرهای اشتراکی تحویل می‌دهد. این لایه، مدیریت کامیت‌ها و تخصیص پیام‌ها را خودش انجام می‌دهد و به Kafka اجازه می‌دهد بدون تغییر معماری اصلی، رفتاری مشابه صف‌های توزیع‌شده واقعی ارائه دهد. قبلا مدیریت دریافت پیام‌ها با خود کانسیومرها بود و هر کانسیومر هنگام جوین شدن به یک گروه مصرف کننده و بعد از عملیات Rebalance، پارتیشن‌هایی که به او اختصاص داده شده بود را دریافت می‌کرد و مستقیما به لیدر آن پارتیشن‌ها پیام می فرستاد. الان پیام ها از این لایه جدید دریافت می‌شوند.
🟢نحوه کار Share Groups
🔰معرفی Share Group Coordinator در بروکرها
🔰مدیریت و پیگیری وضعیت پردازش پیام‌ها برای هر کانسیومر
🔰تخصیص پیام‌ها به کانسیومرها به‌صورت اشتراکی
🔰مدیریت acknowledgment پیام‌ها به‌صورت فردی
🟠ویژگی‌های اصلی Share Groups
🔰تعداد کانسیومرها بیشتر از پارتیشن‌ها → انعطاف بالا در پردازش موازی
🔰تایید acknowledgment فردی → پردازش دقیق‌تر و مدیریت خطاها
🔰پردازش موازی → افزایش کارایی و throughput سیستم
❓ وضعیت فعلی در Python
تا نسخه ۴.۱، کلاینت‌های Python مانند confluent-kafka و kafka-python از Share Groups پشتیبانی نمی‌کنند.
در حال حاضر فقط کلاینت Java از این ویژگی بهره‌مند است و انتظار می‌رود در آینده به سایر کلاینت‌ها اضافه شود.
🚀 سایر بهبودهای نسخه ۴.۱ برای توسعه‌دهندگان
✨ ارتقای مکانیزم Kafka Streams (KIP-1071) → پروتکل rebalance جدید برای کاهش زمان بازتخصیص و رفتار پیش‌بینی‌پذیرتر وظایف
✨ امنیت بهتر با JWT (KIP-1139) → پشتیبانی از jwt_bearer برای احراز هویت امن بدون credential ثابت
✨ بهبود متریک‌ها و مانیتورینگ (KIP-877 & KIP-1109) → استانداردسازی متریک‌ها، اضافه شدن تگ‌های مفید و اصلاح نام تاپیک‌ها
✨ امکان Shutdown نرم‌تر کانسیومرها (KIP-1092) → جلوگیری از ریبالانس غیرضروری هنگام توقف کانسیومرها
✨ رفع deadlock در send callbackها (KIP-1118) → بهبود ثبات تولیدکننده پیام
✨ مدیریت شفاف‌تر تراکنش‌ها (KIP-1050) → دسته‌بندی بهتر خطاها و مدیریت هوشمندتر تراکنش‌ها
💡 نسخه ۴.۱ Kafka با این تغییرات، تجربه کار با پردازش موازی، صف‌گونه و Event-Driven را بهبود داده و ابزارهای توسعه‌دهنده را برای مدیریت امنیت، متریک‌ها و rebalance ساده‌تر و قابل اعتمادتر کرده است.
✅ پی‌نوشت: دوره کافکا از مدرسه مهندسی داده سپهرام Sepahram Data Eng. School در حال برگزاری است و این مباحث را با جزییات بیشتر در آن بررسی می کنیم . https://sepahram.ir/courses/apachekafka-redpanda/
✅کانال تلگرام سپهرام : https://t.iss.one/sepahram_school
یکی از چالش‌های قدیمی #Kafka این بود که وقتی می‌خواستید آن را مانند یک صف واقعی استفاده کنید و هر تعداد کانسیومر لازم برای پردازش سریع پیام‌ها داشته باشید، محدودیت پارتیشن‌ها مانع می‌شد.
یعنی اگر یک تاپیک ۴ پارتیشن داشت، فقط ۴ کانسیومر می‌توانستند همزمان پیام بخوانند و بقیه باید منتظر می‌ماندند. این محدودیت باعث می‌شد انعطاف لازم برای استفاده از Kafka به‌عنوان یک صف توزیع‌شده واقعی وجود نداشته باشد، در حالی که قدرت Kafka در مقیاس‌پذیری و توان عملیاتی بالا یکی از نقاط قوت اصلی‌اش است.
🎯 راهکار Kafka 4.1 با KIP-932
در نسخه ۴.۱ و با معرفی KIP-932، یک لایه مدیریتی جدید اضافه شد که پیام‌ها را از پارتیشن‌ها دریافت میکند و سپس آن‌ها را به کانسیومرهای اشتراکی تحویل می‌دهد. این لایه، مدیریت کامیت‌ها و تخصیص پیام‌ها را خودش انجام می‌دهد و به Kafka اجازه می‌دهد بدون تغییر معماری اصلی، رفتاری مشابه صف‌های توزیع‌شده واقعی ارائه دهد. قبلا مدیریت دریافت پیام‌ها با خود کانسیومرها بود و هر کانسیومر هنگام جوین شدن به یک گروه مصرف کننده و بعد از عملیات Rebalance، پارتیشن‌هایی که به او اختصاص داده شده بود را دریافت می‌کرد و مستقیما به لیدر آن پارتیشن‌ها پیام می فرستاد. الان پیام ها از این لایه جدید دریافت می‌شوند.
🟢نحوه کار Share Groups
🔰معرفی Share Group Coordinator در بروکرها
🔰مدیریت و پیگیری وضعیت پردازش پیام‌ها برای هر کانسیومر
🔰تخصیص پیام‌ها به کانسیومرها به‌صورت اشتراکی
🔰مدیریت acknowledgment پیام‌ها به‌صورت فردی
🟠ویژگی‌های اصلی Share Groups
🔰تعداد کانسیومرها بیشتر از پارتیشن‌ها → انعطاف بالا در پردازش موازی
🔰تایید acknowledgment فردی → پردازش دقیق‌تر و مدیریت خطاها
🔰پردازش موازی → افزایش کارایی و throughput سیستم
❓ وضعیت فعلی در Python
تا نسخه ۴.۱، کلاینت‌های Python مانند confluent-kafka و kafka-python از Share Groups پشتیبانی نمی‌کنند.
در حال حاضر فقط کلاینت Java از این ویژگی بهره‌مند است و انتظار می‌رود در آینده به سایر کلاینت‌ها اضافه شود.
🚀 سایر بهبودهای نسخه ۴.۱ برای توسعه‌دهندگان
✨ ارتقای مکانیزم Kafka Streams (KIP-1071) → پروتکل rebalance جدید برای کاهش زمان بازتخصیص و رفتار پیش‌بینی‌پذیرتر وظایف
✨ امنیت بهتر با JWT (KIP-1139) → پشتیبانی از jwt_bearer برای احراز هویت امن بدون credential ثابت
✨ بهبود متریک‌ها و مانیتورینگ (KIP-877 & KIP-1109) → استانداردسازی متریک‌ها، اضافه شدن تگ‌های مفید و اصلاح نام تاپیک‌ها
✨ امکان Shutdown نرم‌تر کانسیومرها (KIP-1092) → جلوگیری از ریبالانس غیرضروری هنگام توقف کانسیومرها
✨ رفع deadlock در send callbackها (KIP-1118) → بهبود ثبات تولیدکننده پیام
✨ مدیریت شفاف‌تر تراکنش‌ها (KIP-1050) → دسته‌بندی بهتر خطاها و مدیریت هوشمندتر تراکنش‌ها
💡 نسخه ۴.۱ Kafka با این تغییرات، تجربه کار با پردازش موازی، صف‌گونه و Event-Driven را بهبود داده و ابزارهای توسعه‌دهنده را برای مدیریت امنیت، متریک‌ها و rebalance ساده‌تر و قابل اعتمادتر کرده است.
✅ پی‌نوشت: دوره کافکا از مدرسه مهندسی داده سپهرام Sepahram Data Eng. School در حال برگزاری است و این مباحث را با جزییات بیشتر در آن بررسی می کنیم . https://sepahram.ir/courses/apachekafka-redpanda/
✅کانال تلگرام سپهرام : https://t.iss.one/sepahram_school
❤3🙏1
لیک‌هوس در مسیر بلوغ: نگاهی به نسخه جدید #RisingWave و ادغام عمیق آن با #Iceberg
در دنیای امروز که هر سازمان مجموعه‌ای از سرویس‌ها و جریان‌های داده‌ای متنوع دارد، نیاز به بستری متمرکز برای ذخیره و مدیریت «خودِ داده‌ها» بیش از همیشه احساس می‌شود: بستری مستقل از ابزارها و موتورهای پردازشی، جایی که داده‌ها به‌صورت خام و ساخت‌یافته نگهداری شوند.
این معماری نه‌تنها نظم داده‌ها را تضمین میکند، بلکه بستر ایده‌آلی برای توسعه سامانه‌های هوش مصنوعی و مدل‌های یادگیری ماشین فراهم می‌سازد؛ زیرا داده‌های تمیز و استاندارد، پایه‌ی هر سیستم هوشمند هستند.
🚀با این حال، فناوری‌هایی چون Iceberg هنوز در مدیریت متادیتا، snapshotها و عملیات نگهداری، چالش‌هایی دارند. در همین نقطه است که نسخه‌ی جدید #RisingWave v2.6 می‌تواند فرآیند به کارگیری و مدیریت لیک‌هوس را تسهیل کند ✨
⚡️ترکیب #RisingWave + #ApacheIceberg + #Lakekeeper = ترکیب برنده!
✅ در این نسخه، RisingWave، به‌عنوان یک پایگاه داده جریانی سازگار با #PostgreSQL، به‌صورت بومی با Iceberg ادغام شده است. داده‌ها به‌صورت لحظه‌ای از #Kafka دریافت، در RisingWave پردازش، و سپس به شکل استاندارد در Lakehouse ذخیره می‌شوند.
✅این ارتباط از طریق #Lakekeeper برقرار می‌شود: یک #REST Catalog استاندارد که رابط رسمی میان RisingWave و Iceberg است.
✅ کتابخانه Lakekeeper علاوه بر مدیریت متادیتا و کنترل دسترسی‌ها (با پشتیبانی از #OpenFGA)، امکان راه‌اندازی و تنظیم #Lakehouse را به‌دلخواه شما فراهم میکند؛ مثلاً با استفاده از #MinIO یا هر فایل‌سیستم دیگر.
✅ سپس RisingWave با تنظیمات شما و در «لیک‌هوس شما» شروع به درج داده‌ها میکند.
✅ داده‌های غیرجریانی سازمان نیز می‌توانند با ابزارهایی مانند #ApacheSpark یا #PyIceberg به این بستر منتقل شوند تا یک Lakehouse کامل شکل گیرد: جایی که RisingWave بخش داده‌های جریانی را مدیریت میکند.
این ترکیب، از نظر فنی استاندارد و از نظر معماری، منعطف و آینده‌نگر است.
همچنین، عملیات نگهداشت و بهینه‌سازی داده‌ها مستقیماً در خود RisingWave انجام می‌شود، و بار سنگین مدیریت #Lakehouse از دوش تیم‌های داده برداشته می‌شود. 💪
🧠 ویژگی‌های کلیدی نسخه‌ی RisingWave ۲.۶
🔰 پشتیبانی از داده‌های برداری (Vector) برای جست‌وجوی شباهت
🔰حالت جدید Copy-on-Write برای snapshotهای تمیزتر در Iceberg
🔰دستور VACUUM FULL برای پاک‌سازی و فشرده‌سازی داده‌ها
🔰سازگاری کامل با #Lakekeeper REST Catalog
🔰تنوع sinkهای جدید برای #Snowflake، #Redshift، #Elasticsearch
🔰حالت Memory-Only برای پردازش‌های فوق‌سریع
🎥 به‌زودی ویدیویی منتشر میکنم که در آن ساخت یک #Lakehouse عملی با
#MinIO + #Lakekeeper + #Spark + #Trino + #StarRocks
را گام‌به‌گام بررسی می‌کنیم. 🚀
به باور من، مسیر آینده‌ی زیرساخت‌های داده به‌سمتی پیش می‌رود که #Lakehouse بستر اصلی ذخیره و تحلیل داده‌ها شود،
و ترکیب #RisingWave + #ApacheIceberg + #Lakekeeper یکی از گزینه‌های خوب سازمانی برای شروع این مسیر است. 🌟
در دنیای امروز که هر سازمان مجموعه‌ای از سرویس‌ها و جریان‌های داده‌ای متنوع دارد، نیاز به بستری متمرکز برای ذخیره و مدیریت «خودِ داده‌ها» بیش از همیشه احساس می‌شود: بستری مستقل از ابزارها و موتورهای پردازشی، جایی که داده‌ها به‌صورت خام و ساخت‌یافته نگهداری شوند.
این معماری نه‌تنها نظم داده‌ها را تضمین میکند، بلکه بستر ایده‌آلی برای توسعه سامانه‌های هوش مصنوعی و مدل‌های یادگیری ماشین فراهم می‌سازد؛ زیرا داده‌های تمیز و استاندارد، پایه‌ی هر سیستم هوشمند هستند.
📌 اینجا همان جایی است که مفهوم #Lakehouse اهمیت خود را نشان می‌دهد: ترکیبی از داده‌های ساخت‌یافته‌ی خام به همراه یک استاندارد سازمان‌دهی مانند #ApacheIceberg که باعث می‌شود داده‌ها در مقیاس وسیع قابل ذخیره‌سازی، مدیریت و تحلیل باشند.
🚀با این حال، فناوری‌هایی چون Iceberg هنوز در مدیریت متادیتا، snapshotها و عملیات نگهداری، چالش‌هایی دارند. در همین نقطه است که نسخه‌ی جدید #RisingWave v2.6 می‌تواند فرآیند به کارگیری و مدیریت لیک‌هوس را تسهیل کند ✨
⚡️ترکیب #RisingWave + #ApacheIceberg + #Lakekeeper = ترکیب برنده!
✅ در این نسخه، RisingWave، به‌عنوان یک پایگاه داده جریانی سازگار با #PostgreSQL، به‌صورت بومی با Iceberg ادغام شده است. داده‌ها به‌صورت لحظه‌ای از #Kafka دریافت، در RisingWave پردازش، و سپس به شکل استاندارد در Lakehouse ذخیره می‌شوند.
✅این ارتباط از طریق #Lakekeeper برقرار می‌شود: یک #REST Catalog استاندارد که رابط رسمی میان RisingWave و Iceberg است.
✅ کتابخانه Lakekeeper علاوه بر مدیریت متادیتا و کنترل دسترسی‌ها (با پشتیبانی از #OpenFGA)، امکان راه‌اندازی و تنظیم #Lakehouse را به‌دلخواه شما فراهم میکند؛ مثلاً با استفاده از #MinIO یا هر فایل‌سیستم دیگر.
✅ سپس RisingWave با تنظیمات شما و در «لیک‌هوس شما» شروع به درج داده‌ها میکند.
✅ داده‌های غیرجریانی سازمان نیز می‌توانند با ابزارهایی مانند #ApacheSpark یا #PyIceberg به این بستر منتقل شوند تا یک Lakehouse کامل شکل گیرد: جایی که RisingWave بخش داده‌های جریانی را مدیریت میکند.
این ترکیب، از نظر فنی استاندارد و از نظر معماری، منعطف و آینده‌نگر است.
همچنین، عملیات نگهداشت و بهینه‌سازی داده‌ها مستقیماً در خود RisingWave انجام می‌شود، و بار سنگین مدیریت #Lakehouse از دوش تیم‌های داده برداشته می‌شود. 💪
🧠 ویژگی‌های کلیدی نسخه‌ی RisingWave ۲.۶
🔰 پشتیبانی از داده‌های برداری (Vector) برای جست‌وجوی شباهت
🔰حالت جدید Copy-on-Write برای snapshotهای تمیزتر در Iceberg
🔰دستور VACUUM FULL برای پاک‌سازی و فشرده‌سازی داده‌ها
🔰سازگاری کامل با #Lakekeeper REST Catalog
🔰تنوع sinkهای جدید برای #Snowflake، #Redshift، #Elasticsearch
🔰حالت Memory-Only برای پردازش‌های فوق‌سریع
🎥 به‌زودی ویدیویی منتشر میکنم که در آن ساخت یک #Lakehouse عملی با
#MinIO + #Lakekeeper + #Spark + #Trino + #StarRocks
را گام‌به‌گام بررسی می‌کنیم. 🚀
به باور من، مسیر آینده‌ی زیرساخت‌های داده به‌سمتی پیش می‌رود که #Lakehouse بستر اصلی ذخیره و تحلیل داده‌ها شود،
و ترکیب #RisingWave + #ApacheIceberg + #Lakekeeper یکی از گزینه‌های خوب سازمانی برای شروع این مسیر است. 🌟
👍3
Forwarded from مدرسه مهندسی داده سپهرام
وقتی Kafka ساده‌تر، سریع‌تر و سبک‌تر می‌شود: آشنایی با Redpanda در دوره تخصصی کافکا 🎥
در بخش تازه‌ای از دوره آموزش تخصصی کافکا در مدرسه مهندسی داده سپهرام، با یکی از جایگزین‌های قدرتمند و مدرن Kafka یعنی Redpanda آشنا می‌شویم.
در این ویدیو که به‌صورت کارگاهی و کاملاً عملی برگزار شده است، مراحل زیر را گام‌به‌گام انجام می‌دهیم 👇
🔹 راه‌اندازی یک کلاستر تک‌نودی از Redpanda به همراه Redpanda Console
🔹 اجرای دو رابط کاربری معروف دنیای Kafka یعنی AKHQ و Kafka-UI (Kafbat) و بررسی سازگاری کامل آن‌ها با Redpanda
🔹 کار با ابزار خط فرمان rpk برای مدیریت کلاستر و پیکربندی‌ها
🔹 ساخت یک پایپ‌لاین واقعی با Redpanda Connect و زبان Bloblang برای پردازش فایل‌های CSV
🔹 و در نهایت، اجرای PostgreSQL CDC با استفاده از Kafka Connect + Debezium برای همگام‌سازی بلادرنگ داده‌ها
این بخش از دوره، دیدی جامع از توانایی‌های Redpanda در دنیای استریم دیتا و جایگاه آن در اکوسیستم Kafka ارائه می‌دهد.
📺 ویدیو کامل این کارگاه را می‌توانید از طریق لینک زیر در یوتیوب مشاهده کنید:
👉 🔗 https://youtu.be/nu_L4OSRUZc
🎓 این ویدیو بخشی از دوره آموزش تخصصی Kafka از مدرسه مهندسی داده سپهرام (Sepahram) است.
برای مشاهده دوره‌ها به آدرس زیر مراجعه کنید:
🌐 https://sepahram.ir/courses/
📢 کانال رسمی سپهرام در تلگرام:
📬 https://t.iss.one/sepahram_school
🔖 #Kafka #Redpanda #StreamingData #DataEngineering #Debezium #PostgreSQL #KafkaConnect #RealTimeData #Sepahram #مدرسه_مهندسی_داده #کافکا #داده_جاری #مهندسی_داده
در بخش تازه‌ای از دوره آموزش تخصصی کافکا در مدرسه مهندسی داده سپهرام، با یکی از جایگزین‌های قدرتمند و مدرن Kafka یعنی Redpanda آشنا می‌شویم.
در این ویدیو که به‌صورت کارگاهی و کاملاً عملی برگزار شده است، مراحل زیر را گام‌به‌گام انجام می‌دهیم 👇
🔹 راه‌اندازی یک کلاستر تک‌نودی از Redpanda به همراه Redpanda Console
🔹 اجرای دو رابط کاربری معروف دنیای Kafka یعنی AKHQ و Kafka-UI (Kafbat) و بررسی سازگاری کامل آن‌ها با Redpanda
🔹 کار با ابزار خط فرمان rpk برای مدیریت کلاستر و پیکربندی‌ها
🔹 ساخت یک پایپ‌لاین واقعی با Redpanda Connect و زبان Bloblang برای پردازش فایل‌های CSV
🔹 و در نهایت، اجرای PostgreSQL CDC با استفاده از Kafka Connect + Debezium برای همگام‌سازی بلادرنگ داده‌ها
این بخش از دوره، دیدی جامع از توانایی‌های Redpanda در دنیای استریم دیتا و جایگاه آن در اکوسیستم Kafka ارائه می‌دهد.
📺 ویدیو کامل این کارگاه را می‌توانید از طریق لینک زیر در یوتیوب مشاهده کنید:
👉 🔗 https://youtu.be/nu_L4OSRUZc
🎓 این ویدیو بخشی از دوره آموزش تخصصی Kafka از مدرسه مهندسی داده سپهرام (Sepahram) است.
برای مشاهده دوره‌ها به آدرس زیر مراجعه کنید:
🌐 https://sepahram.ir/courses/
📢 کانال رسمی سپهرام در تلگرام:
📬 https://t.iss.one/sepahram_school
🔖 #Kafka #Redpanda #StreamingData #DataEngineering #Debezium #PostgreSQL #KafkaConnect #RealTimeData #Sepahram #مدرسه_مهندسی_داده #کافکا #داده_جاری #مهندسی_داده
❤7👍2