‍ تجربه استفاده از StarRocks در تیم دیتای اسنپ
پست رضا دهقانی در لینکدین

تجربه کار با StarRocks

تو پروژه‌های کاری دنبال یه راه‌حل بودیم که بتونیم داده‌هامون رو همزمان سریع و از منابع مختلف تحلیل کنیم. بعد از بررسی ابزارهای مختلف، StarRocks رو انتخاب کردم و تجربه واقعاً متفاوت و جالبی بود

.

💡 چرا StarRocks؟
استارراکس خودش رو یه دیتاوروس نسل جدید معرفی میکنه که میتونه داده‌ها رو هم بلادرنگ (Real-time) و هم Batch پردازش کنه. بدون نیاز به انتقال داده، میشه مستقیم روی Data Lake کوئری زد و با ابزارهای معمول مثل MySQL Client یا BI Tools وصل شد.

✨ تجربه شخصی من:

✅ اتصال به Iceberg خیلی خوب پشتیبانی میشه و کوئری‌ها روان اجرا میشن. کش دیتای قوی باعث میشه سرعت برخی کوئری‌ها حتی روی دیتالیک بالا باشه. این بخش تو هر نسخه جدید بهبود پیدا میکنه.

✅ جوین‌های پیچیده رو در زمان معقول اجرا میکنه بدون نیاز به تغییر ساختار داده‌ها. این قابلیت تو مدل‌سازی داده خیلی کمک کننده بود.

✅ قابلیت  Materialized View به صورت Async: میشه روی دیتالیک یا هر منبع داده دیگه زمان‌بندی مشخص داد. پشتیبانی از Incremental Refresh هم داره، یعنی لازم نیست کل ویو دوباره پردازش بشه.

✅ سازگاری با Kafka و Spark: امکان خوندن و نوشتن دیتا به صورت Batch، که تو پردازش‌های ما خیلی کمک کرد.


⚠️ چالش‌ها و نکات منفی:

«بهش میگم ابزار زیبا با طراحی زشت 😅»

❌ دیپلوی کلاستر خوب مستند نشده و بعضی مواقع نیاز به تغییرات دستی داره.

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

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

منبع :
https://www.linkedin.com/posts/reza-dehghani-572b3b154_dataengineering-starrocks-lakehouse-activity-7375817395812257793-B-J-

آپاچی دوریس و سرعت بالا در سناریوهای مبتنی بر JOIN
- توضیحی راجع به pdf بالا ـ
اخیراً گزارشی از سمت VeloDB (Powered by Apache Doris) منتشر شد که در آن، عملکرد Apache Doris و ClickHouse در سناریوهای سنگین مبتنی بر JOIN و کوئری‌های تحلیلی پیچیده با هم مقایسه شده‌اند.

من این گزارش را اینجا بازنشر می‌کنم تا برای دوستانی که به دنبال یک راهکار تحلیلی سریع و مشابه دنیای دیتابیس‌های رابطه‌ای هستند، مفید باشد. به‌ویژه برای کسانی که نیاز به تضمین یکتایی کلید اصلی و اجرای JOINهای متعدد دارند، اما امکان ایجاد جداول denormalized در ClickHouse برایشان مقدور نیست.


در همین زمینه، تجربه اخیر اسنپ‌فود با StarRocks (که رضا دهقانی در پست زیر به آن اشاره کرده بود) هم نشان می‌دهد که انتخاب دیتابیس تحلیلی تصمیمی وابسته به نیازها و شرایط سازمان است و یک پاسخ واحد برای همه سناریوها وجود ندارد.
https://lnkd.in/dvc76Dxa

خلاصه عملکرد (Benchmark Results)

در تست‌ها مشخص شد که در سناریوی CoffeeBench (که به شدت بر JOIN متکی است)، Doris حدود ۴ برابر سریع‌تر از ClickHouse عمل کرده است. در مجموعه تست‌های TPC-H که بار تحلیلی پیچیده‌تری دارند، سرعت Doris تا ۳۰ برابر بیشتر گزارش شد. و در نهایت در سناریوهای سنگین‌تر TPC-DS، Doris تا ۴۰ برابر سریع‌تر از ClickHouse نتیجه گرفت.

⚙️ مشخصات تست (Test Config):

- 2 × AWS m6i.8xlarge (هرکدام 32 vCPU و 128GiB RAM)

- Apache Doris v3.0.7 در برابر ClickHouse v25.8

- On-premises


📌 لازم به ذکر است که CoffeeBench در ابتدا توسط Josue “Josh” Bogran برای مقایسه Databricks و Snowflake طراحی شده بود، اما به دلیل ماهیت JOIN-heavy خود، اکنون به یکی از معیارهای پرکاربرد برای سنجش دیتابیس‌های تحلیلی تبدیل شده است.

#doris #starrocks #clickhouse

‍ شروع ثبت‌نام دوره تخصصی Apache Kafka – آموزش صفر تا صد

امروز داده‌ها فقط به صورت Batch پردازش نمی‌شوند؛ حجم عظیمی از رویدادها مثل 📈 تراکنش‌های بانکی، 🛒 سفارش‌های آنلاین، 🎬 رفتار کاربران و 📡 داده‌های حسگرها باید در لحظه پردازش شوند.

اینجاست که Apache Kafka به‌عنوان ستون فقرات جریان داده در معماری‌های مدرن وارد می‌شود؛ ابزاری توزیع‌شده و مقیاس‌پذیر که توانایی مدیریت میلیون‌ها پیام در ثانیه با حداقل تأخیر را دارد.

🔹 در این دوره جامع و کاملاً عملی شما:

🔰 از مفاهیم پایه Kafka (Broker، Topic، Partition، Offset، Producer و Consumer) تا ساخت اولین پایپ‌لاین داده‌ای خود را یاد می‌گیرید.

🔰 با ابزارهای کلیدی اکوسیستم مثل Kafka Connect، Schema Registry و KSQLDB کار می‌کنید.

🔰 پایپ‌لاین‌های بلادرنگ و مقاوم در برابر خطا طراحی می‌کنید.

🔰 با پروژه‌های پیشرفته مثل Redpanda، AutoMQ و ابزارهای پردازش جریان (Spark Streaming، FastStream، RisingWave و …) آشنا می‌شوید.

🔰در نهایت یک پایپ‌لاین ETL حرفه‌ای با Go پیاده‌سازی می‌کنید.


📚 جزئیات دوره:

مدت زمان: ۲۲ ساعت (۱۱ جلسه)

سطح: مقدماتی تا متوسط (با پیش‌نیاز آشنایی با داکر و پایتون)

شروع: پنج‌شنبه ۱۰ مهرماه ۱۴۰۴

ظرفیت: ۳۰ نفر

زمان برگزاری: پنج‌شنبه‌ها ساعت ۱۰ تا ۱۲ و یکشنبه‌ها ساعت ۲۰ تا ۲۲

مدرس : مجتبی بنائی

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

🎯 این دوره ترکیبی از آموزش تئوری + تمرین عملی + نکات بهینه‌سازی است تا شما را برای طراحی سیستم‌های واقعی و مقیاس‌پذیر آماده کند.



💡جزئیات تکمیلی دوره:

✅ دوره به صورت آنلاین برگزار می‌شود، اما هر جلسه بعد از ضبط و تدوین روی سایت قرار می‌گیرد و به صورت آفلاین نیز قابل مشاهده است (در داخل خود سایت سپهرام).

✅در این دوره با نسخه ۴ کافکا کار خواهیم کرد و همزمان از امکانات جدید این نسخه حرفه‌ای بهره می‌بریم.

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

برای مشاهده سرفصل‌های این دوره و ثبت نام از لینک زیر استفاده کنید:

https://sepahram.ir/courses/apachekafka-redpanda/

https://t.iss.one/sepahram_school

‍ زیرساخت پردازش داده در OpenAI با Kafka، Flink و GenAI

در رویداد Current 2025، مهندسان OpenAI از پشت‌صحنه‌ی یکی از مهم‌ترین بخش‌های هوش مصنوعی پرده برداشتند:

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

این سیستم بر پایه‌ی دو ابزار کلیدی ساخته شده:

✅ آپاچی کافکا برای جابجایی داده‌ها

✅ آپاچی فلینک برای پردازش لحظه‌ای

و همه این‌ها در خدمت Generative AI و Agentic AI قرار گرفته‌اند.

🎯 چرا مهم است؟

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

وقتی پای Agentic AI وسط باشد (جایی که هوش مصنوعی خودش تصمیم می‌گیرد، یاد می‌گیرد و واکنش نشان می‌دهد)، اهمیت داده‌ی لحظه‌ای حتی چند برابر می‌شود.

مهم‌ترین نکات از جلسات فنی OpenAI

1. ساخت پلتفرم پردازش جریانی با Flink و Kafka

✨ اجرای PyFlink در مقیاس بزرگ با تغییرات اختصاصی

✨استفاده از Kubernetes برای مدیریت و ایزوله‌سازی کلاسترها

✨ معماری چند-منطقه‌ای (Multi-Region) برای مدیریت Failover و تکرار داده

✨ کافکا هم به‌عنوان منبع (Source) و هم مقصد (Sink) در خط پردازش استفاده می‌شود

2. ساده‌سازی مصرف Kafka با Kafka Forwarder

✨تبدیل مصرف Pull-based به مدل Push-based با gRPC

✨مدیریت ساده‌تر پارتیشن‌ها، Retryها و DLQ

✨ارسال مستقیم داده‌ها به سرویس‌های پایین‌دستی مثل Databricks

✨معماری الهام‌گرفته از Uber uForwarder برای کاهش بار عملیاتی

3. مدیریت حرفه‌ای Kafka بدون Downtime

✨معماری چندکلاستری برای Kafka و Flink

✨مدیریت حرفه‌ای Rebalancing و Producer Redirection

✨تجربه‌های واقعی از مهاجرت در مقیاس جهانی

✨ابزارها و الگوهای عملی برای Failover و ارتقا ایمن

جزئیات بیشتر از Current London: پردازش Embeddings و Features لحظه‌ای

تیم OpenAI نشان داد چطور Flink را برای محیط AI-first و Python-heavy تغییر داده:

🔰ترکیب پایتون برای توسعه سریع و جاوا برای عملکرد بهتر

🔰مدیریت Orchestration از طریق Flink Kubernetes Operator

🔰افزایش دسترس‌پذیری Kafka با توسعه کانکتورها و Union کردن استریم‌ها

🔰ذخیره State با RocksDB و Blob Storage تا بتوانند کلاسترها را بدون از دست دادن داده جابه‌جا کنند

موارد کاربردی که ترکیب کافکا و فلینک برای OpenAI به همراه داشته است:

🔰تولید مداوم داده‌های آموزشی تازه برای مدل‌ها

🔰پردازش تست‌ها در لحظه برای تسریع توسعه

🔰ساخت Embedding لحظه‌ای برای جستجو و بازیابی سریع

🔰تولید Featureهای مدل ML در لحظه و استقرار خودکار

🔰پردازش داده‌های حجیم بدون قفل کردن جریان

💡 جمع‌بندی

آنچه OpenAI در Current 2025 نشان داد، یک نکته‌ی مهم دارد:

🌟 هوش مصنوعی قوی بدون زیرساخت داده‌ی قوی ممکن نیست.

🌟کافکا و Flink تبدیل به ستون فقرات پردازش داده در OpenAI شده‌اند؛ سیستمی که داده‌ها را لحظه‌ای و پایدار به مدل‌ها می‌رساند.


برای هر سازمانی که به فکر استفاده از AI است، درس روشن است:

اگر می‌خواهید سیستم هوشمند داشته باشید، از زیرساخت داده شروع کنید

.
این ارائه ارزشمند و ۴۵ دقیقه‌ای از OpenAI که در مورد این موضوع مهم و نحوه طراحی زیرساخت دیتای این شرکت صحبت می‌کند را از دست ندهید ؛

https://current.confluent.io/post-conference-videos-2025/building-stream-processing-platform-at-openai-lnd25

- شروع ثبت نام دوره کافکا و پستگرس مدرسه مهندسی داده سپهرام :

https://sepahram.ir/courses

‍ و قتی سادگی پشت تجربه پنهان است: نکات کلیدی نگهداری Kafka

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

یکی از نمونه‌های خوب آن، مصاحبه‌ای است که سال گذشته Stanislav Kozlovski، مهندس ارشد سابق در Confluent و کسی که در لینکدین به عنوان The Kafka Guy شناخته می‌شود، ارائه داد.

او کسی است که بیش از ۶ سال روی بزرگ‌ترین Kafka SaaS دنیا کار کرده، با هزاران مشتری و صدها رخداد (incident) سر و کار داشته و حاصل این تجربه را در قالب مجموعه‌ای از توصیه‌های ساده اما کلیدی، هم در حوزه رشد فردی و رهبری تیم‌های نرم‌افزاری و هم در زمینه مدیریت حرفه‌ای کلاسترهای Kafka با ما به اشتراک گذاشته است.

🔑 توصیه‌های کلیدی برای رشد شغلی مهندسان نرم‌افزار

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

🌟تمرکز هوشمندانه داشته باشید: سخت کار کردن کافی نیست؛ باید روی کارهایی تمرکز کنید که بیشترین اثر را می‌گذارند.

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

🌟 اشتباه را بپذیرید: تنها اشتباهی که غیرقابل قبول است، تکرار اشتباه قبلی است.

🌟 ایگو را کنار بگذارید: کنجکاوی و یادگیری از همکاران باتجربه بزرگ‌ترین سرمایه شماست.

👥 توصیه‌های او در رهبری تیم‌های نرم‌افزاری

✨ در دسترس باشید: جلسات One-on-One ساده‌ترین راه برای رفع موانع تیم است.

✨ اعتمادسازی کنید: بدون اعتماد، حقیقت مسائل تیم هیچ‌گاه به رهبر منتقل نمی‌شود.

✨ با عمل، نه با حرف: فرهنگ تیم حاصل رفتار رهبر است، نه صرفاً شعارهای او.

⚙️ توصیه‌های فنی و حرفه‌ای درباره Kafka

تجربه‌ی Stan از صدها incident در مقیاس جهانی باعث شده مجموعه‌ای از نکات به ظاهر ساده اما بسیار کاربردی را مطرح کند:

🔰مانیتورینگ و متریک‌ها:

بدون متریک‌های درست، شما در تاریکی حرکت می‌کنید. داشتن داشبوردهای شفاف برای latency، lag، throughput و error rates حیاتی است. هشدارها باید عملی باشند؛ یعنی اگر آلارمی به صدا درآمد، دقیقاً بدانید چه دستورالعمل (Runbook)‌ای را باید دنبال کنید.

🔰ارتقاء فعال (Proactive Upgrades):

برخلاف تصور رایج، Kafka به‌قدری پایدار است که بسیاری تیم‌ها به‌روزرسانی را به تعویق می‌اندازند. اما Stan تأکید می‌کند که این کار خطرناک است؛ چرا که باگ‌ها و تغییرات امنیتی در نسخه‌های جدید رفع می‌شوند و تنها راه استفاده از بهبودهای مهم، ارتقاء منظم است.

🔰استفاده از کلاینت‌های معتبر:

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

🔰 برنامه‌ریزی ظرفیت (Capacity Planning):

کلاستر Kafka باید همیشه فضای تنفسی داشته باشد. اگر همه بروکرها در بالاترین ظرفیت کار کنند، هر اتفاق کوچک (مثل افت یکی از نودها) می‌تواند بحران‌ساز شود. داشتن طرحی برای افزودن سریع بروکرهای جدید در مواقع فشار، یک اصل حیاتی است.

🔰تست عملکرد و استرس:

کافکا انعطاف‌پذیری فوق‌العاده‌ای دارد؛ اما این انعطاف بدون تست بی‌معنی است. سرمایه‌گذاری در تست‌های بار (load tests) و استرس تست‌ها باعث می‌شود قبل از مشتریان‌تان متوجه مشکلات احتمالی شوید. Stan حتی توصیه می‌کند تنظیمات کلاینت‌ها و سرورها را بارها تغییر دهید و تحت سناریوهای مختلف بسنجید.

🔰دستورالعمل‌های عملیاتی (Runbooks):

داشتن دستورالعمل روشن برای پاسخ به مشکلات رایج (از lag بالا گرفته تا broker failure) باعث می‌شود تیم در شرایط بحرانی به جای سراسیمگی، بر اساس رویه‌ای مستند عمل کند.

🔰آمادگی برای Incidentها:

استن تأکید می‌کند که کار با Kafka در مقیاس بزرگ "مین‌گذاری" است. باید انتظار رخدادها را داشته باشید، تیم را برای آن‌ها آماده کنید و بعد از هر حادثه، جلسه post-mortem واقعی داشته باشید تا یادگیری جمعی حاصل شود.


🎥 این ویدئو با عنوان Leveling up your Software Engineering Career در یوتیوب منتشر شده است و در آدرس زیر قابل مشاهده است :

https://www.youtube.com/watch?v=4EVPMpXPGdg

این صحبت‌ها برای من یادآوری بود که گاهی ساده‌ترین پاسخ‌ها، حاصل پیچیده‌ترین تجربه‌ها هستند.


شروع ثبت نام دوره تخصصی کافکا :‌ https://sepahram.ir/courses

‍ از Postgres تا Lakehouse زنده در کمتر از یک ثانیه -  نگاهی به Mooncake و استراتژی جسورانه Databricks

مدت‌ها بود که پروژه Pg_mooncake رو زیر نظر داشتم تا ببینم کی به مرحله نهایی می‌رسه ،  پروژه‌ای نوآور که می‌خواست Postgres رو با Iceberg ترکیب کنه و داده‌های تحلیلی و عملیاتی رو روی یک پایه مشترک بیاره.

و حالا… دیدم که Databricks این تیم خلاق رو هم خریداری کرده! درست مثل خرید قبلی‌شون یعنی Neon (نسخه‌ی cloud-native از Postgres).

لینک خبر :
https://www.linkedin.com/posts/databricks_were-excited-to-announce-that-databricks-activity-7379138538652696576-2pbr

به‌نظر می‌رسه دیتابریکز داره با قدرت وارد فضای Lakehouse + OLTP + AI می‌شه.  چیزی که خودشون اسمش رو گذاشتن Lakebase؛ پایگاه‌داده‌ای مبتنی بر Postgres که برای Agentهای هوش مصنوعی بهینه‌سازی شده و عملاً نیاز به ETL رو از بین می‌بره.

💡 اما Mooncake دقیقاً چی بود و چرا مهمه؟

به زبان ساده، Mooncake کمک می‌کنه داده‌هایی که در Postgres ذخیره می‌شن به کمک یک افزونه پستگرس که با rust نوشته شده، تقریباً بلافاصله و بدون نیاز به ابزارهای پیچیده، داخل یک لیک‌هوس با فرمت آیس‌برگ یا دلتا ذخیره شده و برای تحلیل و گزارش های سنگین با انواع کوئری انجین ها مثل ترینو، استارراکز، اسپارک و حتی کلیک‌هوس آماده بشن.
با ترکیب Postgres و Iceberg و با استفاده از امکانات خود mooncake:

🔰 داده‌ها به‌صورت زنده (real-time) همگام می‌شن حتی با آپدیت و حذف
🔰 تحلیل‌ها با کمک DuckDB سریع انجام می‌شن،
🔰 و همه‌چی بدون پیچیدگی ETL یا کپی‌کاری، در همون لحظه قابل استفاده‌ست.

یه جور پل بین ذخیره‌سازی عملیاتی و تحلیل زنده‌ست - دقیقاً همون چیزی که خیلی از شرکت‌ها مدت‌هاست دنبالش بودن.


🎯 واقعاً مشخص نیست دقیقاً چه استراتژی‌ بزرگی پشت این خریدهاست، اما چیزی که واضحه اینه که Databricks داره آینده پایگاه‌های داده Postgres-محور رو با هوش مصنوعی و تحلیل real-time بازتعریف می‌کنه.

👋 به تیم Mooncake تبریک می‌گم، و مشتاقم ببینم در ادامه چه اتفاقات بزرگی رقم می‌زنن!

شروع رسمی دوره پستگرس کاربردی در مدرسه مهندسی داده سپهرام:
https://sepahram.ir/courses/

#Databricks #Mooncake #Postgres #Iceberg #Lakehouse #OLTP #AI #Lakebase #DataEngineering #OpenSourc

همروندی و مدیریت تراکنش‌ها در Airflow: تجربه عملی از Postgres تا MinIO

🔹 در ادامه‌ی کارگاه‌های عملی مدرسه مهندسی داده سپهرام Sepahram Data Eng. School، یک ویدئو آموزشی یک‌ساعته آماده کردم که به یکی از مسائل بسیار مهم در طراحی پایپ‌لاین‌های داده با ایرفلو (Apache Airflow) می‌پردازد: موضوع همروندی (Concurrency).

در این ویدئو یک دگ (DAG) کاربردی را در ایرفلو نسخه 3.1 بررسی می‌کنیم که وظیفه‌اش انتقال تراکنش‌ها از پستگرس (Postgres) به MinIO است.


این دگ شامل چند مرحله است:

🔰سنسور برای انتظار تراکنش‌های جدید.

🔰تسک پردازش (Transform) برای استخراج تراکنش‌های خام از پایگاه داده.

🔰ذخیره‌سازی در MinIO به صورت JSON برای استفاده در مراحل بعدی (مثل ذخیره در Lakehouse).

🔰به‌روزرسانی وضعیت تراکنش‌ها در پستگرس به‌عنوان "پردازش‌شده".


❓ اما چالش کجا پیش می‌آید؟

وقتی چند بار این دگ را همزمان اجرا کنیم، هر بار ممکن است مجموعه‌ی مشابهی از تراکنش‌ها انتخاب شود و چندین بار پردازش شود. این همان مشکل اجرای ناخواسته‌ی موازی (Duplicate Processing) است.

برای حل این مسئله، در ویدئو چند راه‌حل بررسی شده است:

🟠 راه‌حل‌های محدود کردن همروندی

✨ گزینه depends_on_past: ایرفلو دگ یا تسک بعدی را تنها در صورتی اجرا می‌کند که اجرای قبلی همان تسک از دگ‌های قبلی تکمیل شده باشد.

✨ گزینه max_active_runs: می‌توانیم تعیین کنیم که حداکثر چند اجرای همزمان از یک دگ فعال باشد (مثلاً فقط یک اجرای فعال در لحظه).

✨ گزینه pool (در این دگ خاص بررسی نشد): ابزاری برای محدود کردن تعداد اجرای همزمان یک تسک مشخص.


🟢 راه‌حل‌های واقعی برای موازی‌سازی

اگر بخواهیم اجرای موازی واقعی برای سناریوی فوق (ترکیب ایرفلو و یک دیتابیس رابطه‌ای)، داشته باشیم، باید به سراغ تکنیک‌های سطح دیتابیس برویم. یکی از مهم‌ترین آنها:
- قفل‌گذاری موقت هنگام انتخاب سطرها با دستور FOR UPDATE SKIP LOCKED: با این تکنیک می‌توانیم در لحظه‌ی انتخاب رکوردها (SELECT) ردیف‌های انتخاب‌شده را قفل کنیم تا پردازش‌های دیگر نتوانند آنها را همزمان بردارند. این کار نیاز دارد که انتخاب (SELECT) و به‌روزرسانی (UPDATE) در همان تراکنش انجام شود تا رفتار اتمیک تضمین گردد.

💡 نکته‌ی اصلی این کارگاه این بود که:
طراحی پایپ‌لاین‌های داده با ایرفلو تنها به نوشتن چند تسک و اتصال آنها به هم خلاصه نمی‌شود. بلکه باید همه‌ی شرایط مرزی، اجرای همزمان دگ‌ها، قفل‌های دیتابیس و حتی طراحی ذخیره‌سازی (مثل MinIO یا Lakehouse) را با دقت بررسی کنیم.

📌 کدهای کامل این دگ در گیت‌هاب موجود است:

👉 https://github.com/sepahram-school/workshops/tree/main/2-Airflow-Concurrency-Control-SQL

🎥 امیدوارم این ویدئو برای تمام کسانی که در پروژه‌های واقعی با ایرفلو کار می‌کنند و دغدغه‌ی پایداری و دقت پایپ‌لاین‌های داده دارند، مفید و الهام‌بخش باشد.


کانال تلگرام BigData.IR - وب‌سایت مهندسی داده : https://t.iss.one/bigdata_ir

دوره‌های تخصصی سپهرام : https://sepahram.ir/courses

آدرس ویدئو در یوتیوب :

https://www.youtube.com/watch?v=sS6Ma40sngU

به تازگی کتاب Platform Engineering on Kubernetes نوشته‌ی Mauricio Salatino رو خوندم و واقعاً می‌تونم بگم یکی از منابع تحول‌آفرین در این حوزه‌ست.
پست اخیر Sajad Hamreh در لینکدین
چیزی که برای من خیلی جالب بود، این بود که کتاب فاصله بین دانش تئوری Kubernetes و عملیات واقعی Platform Engineering رو پر می‌کنه. یعنی نه صرفاً توضیح تئوریه و نه صرفاً دستورالعمل خشک، بلکه قدم‌به‌قدم نشون می‌ده چطور پلتفرمی بسازیم که واقعاً در دنیای واقعی کار کنه.
✅ از مباحث پایه Kubernetes شروع می‌کنه و به استراتژی‌های پیچیده‌تر مثل GitOps، progressive delivery، service mesh integration و multi-tenancy می‌رسه.
✅ فصل‌های مربوط به developer portals و self-service capabilities واقعاً برای من ارزشمند بودن؛ چون توی خیلی از منابع دیگه کمتر بهشون پرداخته می‌شه، در حالی که برای پذیرش موفق پلتفرم حیاتی هستن.
✅ نکته مهم دیگه اینه که با ابزارهایی مثل ArgoCD و Crossplane مثال‌های عملی زده که بلافاصله می‌شه در پروژه‌ها به‌کار برد.
✅ تجربه‌ی عمیق نویسنده هم در بخش‌های troubleshooting و هشدار درباره‌ی pitfalls کاملاً مشهوده؛ چیزهایی که به‌معنای واقعی کلمه جلوی سردردهای بعدی رو می‌گیرن.

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

کتاب Platform Engineering on Kubernetes

‍ کافکا 4.1 و قابلیت جدید Share Groups: نزدیک شدن Kafka به یک صف توزیع شده واقعی

یکی از چالش‌های قدیمی #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

‍ ورکشاپ جدید مدرسه مهندسی داده سپهرام - آشنایی با ساختار فیزیکی پستگرس منتشر شد!

در ادامه‌ی کارگاه‌های عملی مدرسه مهندسی داده سپهرام، این‌بار به سراغ سازوکار ذخیره‌سازی فیزیکی داده‌ها در #PostgreSQL رفتیم.

در این جلسه با اجرای #PostgreSQL نسخه ۱۸ در محیط Docker، ساختار درونی ذخیره داده‌ها را از نزدیک بررسی کردیم.

خلاصه اینکه : ✨فایل‌های داده در پستگرس از واحدهایی به نام Page (یا Block) تشکیل می‌شوند؛ هر Page معمولاً ۸ کیلوبایت حجم دارد و کوچک‌ترین بخش قابل خواندن یا نوشتن در دیسک است.

✨ هر Page شامل اطلاعات مدیریتی، اشاره‌گرهای رکوردها، فضای خالی، و خود داده‌هاست. هنگام درج یا به‌روزرسانی رکورد، #PostgreSQL بر اساس فضای خالی موجود تصمیم می‌گیرد که داده را در همان Page یا Page جدید ذخیره کند. این رفتار در عمل، پایه‌ی مفهومی به نام Heap است - یعنی ذخیره‌سازی بدون ترتیب خاص.

✨در کارگاه دیدیم که با به‌روزرسانی رکوردها، نسخه‌های جدید در انتهای Page درج می‌شوند و نسخه‌های قبلی تا اجرای فرآیند VACUUM در فایل باقی می‌مانند. همچنین با تعیین fillfactor=70 برای جدول users2، مشاهده کردیم که چگونه فضای آزاد در Page باعث درج نسخه‌های جدید در همان Page می‌شود.


📘 آنچه در این کارگاه انجام دادیم:

🔰راه‌اندازی PostgreSQL 18 با Docker

🔰بررسی ساختار پوشه‌های base و global و مفهوم OID

🔰درج و به‌روزرسانی داده‌ها و تحلیل رفتار Pageها

🔰بررسی عملی Heap و نقش پارامتر fillfactor


📺 فیلم کامل ورکشاپ در یوتیوب مدرسه:

🔗 https://youtu.be/H3ET3i7XsXw

💾 فایل‌ها و اسکریپت‌ها در گیت‌هاب سپهرام:

👉 https://github.com/sepahram-school/workshops

دوره در حال برگزاری پستگرس : https://sepahram.ir/courses/postgresql

‍ برای لیک‌هوس کدام استاندارد را انتخاب کنیم؟

نگهداری داده‌ها در چند پایگاه داده جدا وقتی حجم داده‌ها بسیار زیاد شود و نیازهای هوش مصنوعی هم در میان باشد، به سرعت دردسرساز می‌شود. دیتابیس‌هایی مثل Oracle یا SQL Server وقتی داده‌ها زیاد شوند، به مرور کند می‌شوند و نیاز به راهکاری مدرن داریم.

به همین دلیل، لیک‌هوس (Data Lakehouse) محبوب شده است: یک بستر متمرکز برای ذخیره دادهٔ خام به صورت منظم که حاکمیت داده، دیتاکاتالوگ و گزارش‌دهی سریع را ممکن می‌کند و همزمان امکان یکپارچه‌سازی کل داده‌های سازمان و سرویس‌دهی به بخش‌های تحلیل داده و هوش مصنوعی را ممکن می‌کند.

سؤال اصلی: بین Delta / Iceberg / Hudi کدام‌یک را برای سازمان خود انتخاب کنیم؟ (فرض می‌کنیم با اصول لیک‌هوس آشنا هستید)


⚡️ معیارهای مقایسه

قبل از انتخاب، معیارهای زیر را باید بررسی کنیم :

🔰روش به‌روزرسانی داده‌ها: رکوردها چطور آپدیت می‌شوند؟

🔰سازگاری با ابزارها: Spark، Flink، Trino/Presto و سایر ابزارها چقدر پشتیبانی می‌شوند؟

🔰محبوبیت در صنعت: چقدر استفاده می‌شوند؟

🔰مقیاس‌پذیری و هزینه عملیاتی: آیا در حجم بالا پایدار و مقرون‌به‌صرفه هستند؟

🔰قابلیت بازگشت به گذشته و ایزوله‌سازی: می‌توان وضعیت داده‌ها را در گذشته بازسازی کرد یا snapshot گرفت؟

🔰انعطاف تغییر ساختار داده‌ها: تغییرات ساختار جداول چقدر آسان است؟


🔄 روش‌های به‌روزرسانی

✅روش CoW (Copy-on-Write): فایل را بازنویسی می‌کنیم. خواندن سریع، نوشتن سنگین

✅ روش MoR (Merge-on-Read): آپدیت‌ها جدا نوشته می‌شوند و هنگام خواندن با فایل اصلی ادغام می‌شوند. نوشتن سریع، خواندن کمی پیچیده‌تر

✅ روش MERGE INTO: اگر رکورد هست آپدیت کن، نیست درج کن


📊 مرور استانداردهای لیک‌هوس

✨ قالب Delta: بهترین گزینه برای تیم‌های Spark-محور؛ MERGE آسان، OPTIMIZE برای فایل‌های کوچک، time travel خوب

✨ استاندارد Iceberg: محبوب و رایج، سازگار با انواع انجین‌ها، عالی برای مصرف‌کنندگان متعدد و اسکن‌های طولانی؛ snapshot و branching قوی

✨ قالب Hudi: مناسب CDC و نوشتن لحظه‌ای با محوریت MoR؛ نوشتن سریع اما کمتر در معماری‌های نوین دیده می‌شود

🏗 معماری پیشنهادی ساده

🎯لایه Bronze - داده خام:

📌با Spark از Kafka بخوانید و در قالب Delta ذخیره کنید.

🎯لایه Silver - داده پردازش‌شده:

📌پردازش‌ها را با Spark انجام دهید و خروجی را دوباره در Delta ذخیره کنید.

📌این کار آپدیت‌ها و پردازش سریع را بهینه می‌کند.

🎯لایه Gold - داده تحلیلی و مصرف‌کننده نهایی:

📌داده‌های آماده را به صورت منظم مثلا هر یک ساعت به Iceberg منتقل کنید.

📌مزیت‌ها: اسکن سریع، پارتیشن‌بندی دینامیک، امکان بازگشت به گذشته (مثلاً داشبورد روز گذشته).

📌ابزارهای BI و تحلیل را به این لایه متصل کنید.


✅ چک‌لیست ساده قبل از پیاده‌سازی

🔑یک catalog با قرارداد مشخص بسازید (مثل دفترچه راهنما برای داده‌ها)

🔑از فرمت ستونی استاندارد (مثل Parquet یا ORC) استفاده کنید

🔑قواعد پارتیشن‌بندی و مرتب‌سازی داده‌ها را تعیین کنید

🔑برنامه زمان‌بندی برای ادغام فایل‌ها (Compaction/OPTIMIZE) داشته باشید

🔑یک راهنمای تغییر ساختار جداول و تست صحت داده‌ها آماده کنید

🔑ممکن است متوجه شوید که قالب نادرستی را انتخاب کرده‌اید. مسیر تبدیل بین فرمت‌ها و خروج از هر استاندارد را طراحی کنید

📝 جمع‌بندی

هر روش نیاز به آزمون و بررسی دارد، اما به نظر می‌رسد با ترکیب Delta + Iceberg می‌توان یک لیک‌هوس مقیاس‌پذیر و منعطف برای سازمان ساخت.

کدام چارچوب نرم افزاری را برای ایجاد یک سامانه مبتنی بر عامل‌های هوشمند انتخاب کنیم ؟
چارچوب‌های ایجاد برنامه‌های مبتنی بر عامل‌های هوشمند بسیار متنوع شده‌اند و تصمیم گیری در خصوص انتخاب آنها خود نیاز به بررسی فراوان و دانش مناسب دارد.
این مقاله وب‌سایت کلیک‌هوس که به بررسی دوازده فریمورک جدید حوزه عامل‌های هوشمند پرداخته است می تواند یک منبع جدید و قابل اعتماد در این حوزه باشد.
https://clickhouse.com/blog/how-to-build-ai-agents-mcp-12-frameworks

‍ ظهور Apache Flink Agents: نقطه عطفی در پردازش جریان و هوش مصنوعی لحظه‌ای

در دنیای پردازش جریان سازمانی، دو فرمانروا داریم: Apache Spark و Apache Flink. اما فلینک به دلیل امکان پردازش تک رویداد به صورت مقیاس‌پذیر، در محیط‌هایی که به ازای هر رخداد نیاز به پردازش جداگانه است، تبدیل به de-facto standard شده است.

✨ چند روز پیش خبر جذابی منتشر شد: معرفی Flink Agents، زیرپروژه‌ای جدید که با حمایت شرکت #Confluent عرضه شده و یک گام بزرگ در ترکیب پردازش جریان با پیشرفت‌های هوش مصنوعی به حساب می‌آید.
https://flink.apache.org/2025/10/15/apache-flink-agents-0.1.0-release-announcement

🎯 عامل‌های هوشمند فلینک امکان ساخت عامل‌های هوشمند مبتنی بر رویداد را مستقیماً روی runtime جریان Flink فراهم می‌کند. این پروژه ترکیبی است از قدرت Flink در پردازش جریان با مقیاس بزرگ، تاخیر میلی‌ثانیه‌ای، تحمل خطا و مدیریت state با قابلیت‌های عامل‌های هوشمند مانند LLMها، ابزارها، حافظه و ارکستراسیون پویا.

💡 چرا این خبر مهم است؟

سیستم‌های هوشمند فعلی اغلب منتظر دستور کاربر هستند، اما در صنایع فروشگاه‌های آنلاین، مالی، IoT و لجستیک، تصمیمات حیاتی باید همین لحظه و بر اساس رویدادهای زنده گرفته شوند:

⚡️ شکست تراکنش

⚡️اختلال در سنسورها

⚡️فعالیت لحظه‌ای کاربر

عامل‌های هوشمند Flink این امکان را می‌دهد که عامل‌ها همیشه فعال، واکنش‌گرا و مقیاس‌پذیر باشند و مانند میکروسرویس‌های رویدادمحور عمل کنند.


نحوه کار Flink Agents

🔰هر عامل به عنوان میکروسرویس رویدادمحور روی جریان‌های داده Flink اجرا می‌شود.

🔰دو منبع داده DataStream و Table APIs به عنوان ورودی و خروجی عامل‌ها عمل می‌کنند، بنابراین عامل‌ها مستقیماً با داده‌های ساختاریافته و هوش مصنوعی تعامل دارند.

🔰حافظه عامل‌ها در Flink state مدیریت می‌شود و قابلیت replay و آزمایش مجدد فراهم می‌شود.

🔰تعامل با LLMها، vector DBها و ابزارهای MCP برای تصمیم‌گیری و پردازش پیچیده امکان‌پذیر است.

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

قابلیت‌های کلیدی

✅ مقیاس بزرگ و تاخیر میلی‌ثانیه‌ای – پردازش جریان‌های حجیم در زمان واقعی

✅ تضمین صحت عملیات و اثرات جانبی - Exactly-Once Action Consistency

✅ یکپارچگی داده و AI – ترکیب پردازش داده و هوش مصنوعی بدون کد glue

✅ چندزبان – پشتیبانی Python و Java

✅ همیشه فعال و خودمختار – بدون انتظار برای درخواست کاربر

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

پ.ن: عکس از مقاله زیر برداشته شده است :‌

https://www.kai-waehner.de/blog/2025/08/18/the-future-of-data-streaming-with-apache-flink-for-agentic-ai/

انواع دوره‌های تخصصی در حوزه مهندسی داده : https://t.iss.one/sepahram_school

‍ افزایش سرعت APIها: چگونه جایگزینی JSON با فرمت‌های باینری هزینه‌های پنهان را حذف می‌کند

📌 امروزه JSON در همه‌جا حضور دارد: از خروجی APIها و پیام‌های بین میکروسرویس‌ها تا فایل‌های لاگ و داده‌های بین سیستم‌ها.
با این حال، JSON برای مسیرهای حساس به تاخیر و حجم بالای داده همیشه بهینه نیست. Parsing متن و حجم payload باعث مصرف اضافی CPU و افزایش latency می‌شود و روی دستگاه‌های موبایل یا IoT، فشار حافظه و منابع را افزایش می‌دهد.

⚡️ خبر خوب این است که تنها با تغییر فرمت سریالایز داده‌ها هنگام ارسال در شبکه می‌توان به طور قابل توجهی هم سرعت انتقال داده‌ها و هم سرعت پردازش را افزایش داد. تجربه عملی نشان داده است که جایگزین‌های باینری می‌توانند سرعت APIها را تا ۵ برابر افزایش دهند و مصرف منابع را کاهش دهند.

🔹 گزینه‌های پیشنهادی:

🔰قالب Protobuf: مناسب RPCهای تایپ‌شده و میکروسرویس‌ها با اسکیمای ثابت. سرعت parse بالا و حجم payload کوچک از مزایای آن است. نیاز به تولید کد مصرف‌کننده (codegen) دارد و مدیریت نسخه‌بندی اسکیمای داده‌ها ضروری است.

🔰قالب FlatBuffers: سریع‌تر از Protobuf و توسط گوگل توسعه داده شده است. ایده‌آل برای مسیرهای خواندن پرتکرار (hot read paths) که هزینه ایجاد اشیاء اهمیت دارد. مانند Protobuf، نیاز به تولید کد مصرف‌کننده دارد و تغییر در ساختار داده نیازمند بازسازی schema است.

🔰کتابخانه MessagePack: ساختاری مشابه JSON دارد اما باینری و سریع‌تر است. نیازی به کامپایلر ندارد و تنها نصب کتابخانه کافی است. مناسب مسیرهایی که انعطاف JSON لازم است ولی می‌خواهید performance بالاتر داشته باشید.

🔰کتابخانه CBOR: مناسب دستگاه‌های IoT و موبایل با پهنای باند محدود و payloadهای کوچک. سبک، سریع و نیازی به تولید کد ندارد؛ تنها نصب کتابخانه کافی است.

💡 نکته عملی: یک endpoint حساس را انتخاب کنید، JSON را با یک فرمت باینری جایگزین کنید و عملکرد را اندازه‌گیری کنید. اغلب، تفاوت سرعت و مصرف منابع به وضوح قابل لمس خواهد بود.

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

📖 منبع: Forget JSON - These 4 Data Formats Made My APIs 5× Faster

دوره‌های تخصصی مهندسی داده: https://sepahram.ir/courses

آشنایی با الگوریتم Raft : بدون درد و خونریزی

امروز به وب‌سایتی برخوردم که با استفاده از اسلایدهای تعاملی، الگوریتم معروف Raft را به شکلی ساده و کاربردی توضیح داده است.

📎 https://thesecretlivesofdata.com/raft/

✨اگر با جزئیات این الگوریتم آشنا نیستید، پیشنهاد می‌کنم حتماً از این وب‌سایت استفاده کنید. در عرض چند دقیقه می‌توانید با اصول کلی Raft به صورت بصری، تعاملی و جذاب آشنا شوید و دیدی عملی نسبت به عملکرد آن پیدا کنید.

💡الگوریتم Raft امروزه به استانداردی رایج در حوزه سیستم‌های توزیع‌شده تبدیل شده و برای حل مسائل اجماع، انتخاب رهبر، و تکرار داده‌ها بین رهبر و پیروان (Leader/Follower) به کار می‌رود. این الگوریتم به‌قدری تأثیرگذار بوده که باعث شده Apache ZooKeeper از سیستم‌هایی مانند Kafka و ClickHouse حذف شود.

بیایید با هم این الگوریتم و موضوع اجماع را به صورت مفید و مختصر مرور کنیم:

🎯 الگوریتم اجماع (Raft) به زبان ساده

🔰هر نود در ابتدا در حالت Follower قرار دارد.

🔰اگر پس از یک مدت مشخص، هیچ پیامی از رهبر دریافت نکند، نود یک شمارنده انتخاب رهبر افزایش می‌دهد و خود را به عنوان Candidate معرفی می‌کند.

🔰 نود Candidate به سایر نودها پیام می‌فرستد و از آن‌ها می‌خواهد به او رأی دهند.

🔰هر نود فقط در صورتی رأی می‌دهد که قبلاً به همان شمارنده رأی نداده باشد.

🔰اگر Candidate اکثریت آراء را دریافت کند، تبدیل به Leader می‌شود و شروع به ارسال heartbeat و هماهنگ‌سازی داده‌ها با Followers می‌کند.

🔰اگر هیچ Candidate اکثریت آراء را به دست نیاورد، رأی‌گیری دوباره با یک timeout تصادفی شروع می‌شود تا احتمال رأی مساوی کاهش یابد.


📌چرا بعد از انتخاب رهبر، Log Replication مهم است؟

پس از انتخاب رهبر، یک چالش مهم پیش می‌آید: چگونه تضمین کنیم که همه نودها داده‌های یکسان و همگام داشته باشند؟

در سیستم‌های توزیع‌شده، ممکن است Followers داده‌های قدیمی یا ناقص داشته باشند. بدون یک مکانیزم هماهنگ‌سازی، اختلاف داده‌ها باعث ناسازگاری سیستم و خطاهای احتمالی می‌شود. Log Replication این مشکل را حل می‌کند: Leader تمام تغییرات را ابتدا در log خودش ثبت کرده و سپس به Followers ارسال می‌کند، تا همه سرورها در نهایت یک وضعیت یکسان و مطمئن داشته باشند.

🔄 تکرار داده‌ها Log Replication:

✅هر درخواست جدید از کلاینت ابتدا در Leader ثبت می‌شود و سپس به Followers کپی می‌شود.

✅داده‌ها زمانی committed محسوب می‌شوند که اکثر نودها آن را ذخیره کرده باشند.

✅ رهبر یا Leader پس از commit شدن داده، آن را نهایی کرده و پاسخ مناسب به کلاینت ارسال می‌کند.

✅اگر Leader سقوط کند، Followers با استفاده از آخرین log خود، مجدداً هماهنگ می‌شوند و رهبر جدید انتخاب می‌شود.


🚀 ایمنی و سازگاری داده‌ها

✨هیچ دو نودی نمی‌توانند برای یک شاخص log، داده متفاوتی داشته باشند.

✨Leader همواره آخرین داده‌های commit شده را در اختیار دارد.

✨سرورها تنها داده‌ها را append می‌کنند و عملیات overwrite یا delete انجام نمی‌دهند.

✨تغییر اعضای cluster با مکانیزم Joint Consensus انجام می‌شود تا سیستم در طول تغییر وضعیت همواره پاسخگو باقی بماند.


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


🎬 : فیلم زیر از سایت رسمی الگوریتم Raft در گیت‌هاب تهیه شده است. 👇👇👇

https://raft.github.io