‍ کافکا 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

توضیح سریع و ساده الگوریتم اجماع Raft - در ادامه مطللب آموزشی بالا

‍ دو منبع عالی برای یادگیری سریع و عمیق Airflow 3 📚

چند ماه از انتشار رسمی Airflow 3 می‌گذرد و حالا وقت آن است که ببینیم دقیقاً چه چیزهایی تغییر کرده و چرا این نسخه نقطه عطف مهمی در مسیر این پلتفرم محبوب مدیریت جریان کاری داده (workflow orchestration) محسوب می‌شود.

در این نوشته می‌خواهیم دو منبع فوق‌العاده را معرفی کنیم که به‌جای خواندن ده‌ها صفحه مستندات یا تماشای ویدیوهای پراکنده، شما را مستقیم و مؤثر به قلب Airflow 3 می‌برند.
گاهی برای درک عمیق‌تر و تجربه‌ی واقعی، باید سراغ منابعی رفت که با نگاه حرفه‌ای نوشته شده‌اند - منابعی که نه‌تنها توضیح می‌دهند چطور کار می‌کند، بلکه کمک می‌کنند در عمل بهتر بسازید.

حالا که چند ماه از انتشار نسخه ۳ می‌گذرد، اگر هنوز با نسخه ۲ کار می‌کنید، باید بدانید از خیلی از قابلیت‌های جدید و بهینه‌سازی‌های Airflow 3 بی‌نصیب مانده‌اید.

دو منبع زیر بهترین نقطه‌ی شروع برای درک تفاوت‌ها و یادگیری عملی نسخه ۳ هستند 👇

1️⃣ جزوه مروری بر امکانات ایرفلو ۳ از Astronomer

یک مرور سریع و فشرده (حدود ۹ صفحه) از همه‌ی قابلیت‌های جدید Airflow 3 - ایده‌آل برای کسانی که می‌خواهند در چند دقیقه بفهمند دقیقاً چه تغییراتی در انتظارشان است. البته با این پیش‌فرض که با ایرفلو قبلا آشنا هستید.

2️⃣ کتاب Practical Guide to Apache Airflow 3 از Manning

اگر می‌خواهید با Airflow 3 به‌صورت واقعی و پروژه‌محور کار کنید، این کتاب انتخاب فوق‌العاده‌ای است.

از ساخت اولین pipeline تا معماری جدید، UI به‌روز، نسخه‌بندی DAGها و حتی اجرای inference با OpenAI - همه‌چیز در قالب مثال‌های عملی و توضیحات تصویری ارائه شده است آنهم در ۱۴۰ صفحه، مفید و مختصر

📘 فهرست فصل‌ها در یک نگاه:

✅آشنایی با Airflow 3

✅ساخت اولین pipeline

✅قابلیت اطمینان و زمان‌بندی

✅ واسط کاربری جدید و DAG Versioning

✅معماری داخلی نسخه ۳

✅حرکت به محیط Production

✅اجرای inference

✅مهاجرت از نسخه ۲

✅آینده Airflow


💡 اگر به دنبال یادگیری جدی نسخه ۳ و امکانات جذاب و کاربردی آن هستید:

✨ با جزوه Astronomer شروع کنید تا دید کلی بگیرید،

✨ و سپس با کتاب Manning جلو بروید تا Airflow 3 را به‌صورت عملی و حرفه‌ای تجربه کنید.

برای دانلود این دو pdf به دو پست قبلی، مراجعه کنید. 👆👆👆

کانال مدرسه مهندسی داده سپَهرام : آموزش‌های تخصصی مهندسی داده : @sepahram_school

#ApacheAirflow #DataEngineering #ETL #WorkflowAutomation #ManningBooks #Astronomer #OpenAI #Airflow3 #DataOps

🎥 ویدئوی جدید منتشر شد: رپلیکیشن در کافکا — درک عمیق از مکانیزم تکثیر داده‌ها

در این جلسه از دوره تخصصی آموزش کافکا، به یکی از بنیادی‌ترین و در عین حال کمتر درک‌شده‌ترین بخش‌های کافکا یعنی رپلیکیشن (Replication) پرداخته‌ایم.
📦 جایی که داده‌های هر پارتیشن در چندین بروکر تکرار می‌شوند تا سیستم در برابر خطا، قطعی و از دست رفتن داده مقاوم بماند.

در این ویدئو موارد زیر بررسی می‌شوند:

🔹 رپلیکیشن در سطح پارتیشن چگونه عمل می‌کند؟

🔹 تفاوت نقش رهبر (Leader) و پیرو (Follower) چیست؟

🔹 مفهوم ISR (In-Sync Replicas) دقیقاً چه نقشی در پایداری داده دارد؟

🔹شاخص High Watermark چگونه تعیین می‌شود و چرا در مصرف داده حیاتی است؟

🔹 ارتباط بین تنظیمات replication.factor، min.insync.replicas و acks چیست و چطور باید مقدار مناسب را انتخاب کنیم؟

🔹 در صورت خرابی بروکر یا تأخیر در همگام‌سازی، چه اتفاقی می‌افتد و چطور می‌توان از unclean leader election جلوگیری کرد؟

🎯 اگر می‌خواهید بدانید کافکا در پشت‌صحنه چگونه با چند بروکر داده‌ها را همگام نگه می‌دارد و چه مکانیزم‌هایی باعث حفظ پایداری سیستم می‌شود، این ویدئو را از دست ندهید.

📺 تماشای کامل ویدئو در یوتیوب:
👉 https://youtu.be/l30jp3iXooE

🔗 سایر دوره‌ها و آموزش‌های مدرسه مهندسی داده سپهرام:
https://sepahram.ir/courses

‍ آشنایی با مکانیزم همروندی در پستگرس و ضرورت اجرای منظم Vacuum

یکی از پرسش‌های کلیدی در طراحی پایگاه داده این است که:

🔍 وقتی چندین تراکنش به‌صورت همزمان قصد تغییر رکوردهای مشابه را دارند، سیستم چگونه تصمیم می‌گیرد کدام تغییر اعمال شود؟

پستگرس برای پاسخ به این چالش از مکانیزم MVCC (Multi-Version Concurrency Control) استفاده می‌کند - روشی که اجازه می‌دهد تراکنش‌ها بدون قفل‌های سنگین، همزمان روی داده‌ها کار کنند.


مکانیزم MVCC در پستگرس

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

برخلاف تصور رایج، کل صفحه کپی نمی‌شود - بلکه فقط ردیف(های) جدید افزوده می‌شود و نسخه‌ی قبلی به‌عنوان «مرده» (dead tuple) علامت‌گذاری می‌شود.
اگر تراکنش commit شود، نسخه‌ی جدید قابل مشاهده می‌شود؛ در غیر این صورت، ردیف‌های جدید هرگز برای سایر تراکنش‌ها دیده نمی‌شوند.

✨ مفهوم Page در پستگرس چیست؟

در PostgreSQL، داده‌ها مستقیماً به‌صورت خطی روی دیسک ذخیره نمی‌شوند، بلکه در قالب واحدهایی به نام Page (صفحه) سازمان‌دهی می‌شوند.

هر Page معمولاً حجمی برابر با ۸ کیلوبایت دارد و شامل چندین tuple (یا همان ردیف داده) است.

وقتی داده‌ای جدید درج می‌شود، PostgreSQL ابتدا بررسی می‌کند که آیا در یکی از صفحات موجود فضای کافی برای آن وجود دارد یا نه:

✅ اگر فضا کافی باشد، ردیف جدید در همان صفحه قرار می‌گیرد.

📦 اگر صفحه پر باشد، ردیف جدید در صفحه‌ای دیگر ذخیره می‌شود و ممکن است اندازهٔ فایل جدول افزایش پیدا کند.

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

🔹 نکته جالب اینجاست که ساختار داخلی جداول در پستگرس به‌صورت #Heap (پشته‌ای/درهم/بدون هیچ ترتیب‌ خاصی) پیاده‌سازی شده است؛
یعنی برخلاف ساختارهای مرتب‌شده مثل B-Tree، ردیف‌ها به‌ترتیب خاصی ذخیره نمی‌شوند : هر رکورد «هرجا که یک پیج، فضای خالی داشته باشد» درج می‌شود.

🎯 ضرورت فرآیند VACUUM

با گذر زمان، رکوردهای قدیمی (dead tuples) باید پاک‌سازی شوند تا فضای جدول بی‌دلیل افزایش نیابد. این وظیفه بر عهده‌ی فرآیند #VACUUM است.

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

در کارگاه عملی این جلسه، با استفاده از PostgreSQL 18 در محیط Docker و ابزار DBeaver، گام‌به‌گام بررسی کردیم که:

🔰مکانیزم MVCC چگونه نسخه‌های مختلف رکوردها را مدیریت می‌کند،

🔰و VACUUM چگونه فضا را بازیابی و از wraparound جلوگیری می‌کند.


🎥 مشاهده ویدئوی کامل در یوتیوب:

👉 https://youtu.be/TtHSDJgFI6g

📌 نکته: در محیط‌های تولیدی، هرگز autovacuum را غیرفعال نکنید - این گزینه فقط برای اهداف آموزشی در این کارگاه موقتاً خاموش شده بود.

Sepahram Data Eng. School

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

‍ لیک‌هوس در مسیر بلوغ: نگاهی به نسخه جدید #RisingWave و ادغام عمیق آن با #Iceberg

در دنیای امروز که هر سازمان مجموعه‌ای از سرویس‌ها و جریان‌های داده‌ای متنوع دارد، نیاز به بستری متمرکز برای ذخیره و مدیریت «خودِ داده‌ها» بیش از همیشه احساس می‌شود: بستری مستقل از ابزارها و موتورهای پردازشی، جایی که داده‌ها به‌صورت خام و ساخت‌یافته نگهداری شوند.

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

📌 اینجا همان جایی است که مفهوم #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 یکی از گزینه‌های خوب سازمانی برای شروع این مسیر است. 🌟

ما در داتین به‌دنبال همکاری متخصص و پرانگیزه هستیم تا در نقش کارشناس ارشد زیرساخت کلان داده تیم پایگاه داده را همراهی کند. کارشناس ارشد زیرساخت کلان داده در داتین با پذیرفتن مسئولیت‌های زیر به پیش‌برد اهداف تیم کمک می‌کند:
- نصب و راه اندازی دیتابیس های NoSQL ای مثل Cassandra, elastic
- نصب و راه اندازی دیتابیس PostgreSQL
- نصب و راه اندازی Kafka
- راه اندازی کلاسترینگ و HA
- مانیتورینگ دیتابیس ها
دانش و مهارت های مورد نیاز:
- آشنا با مفاهیم NoSQL , SQL
- آشنا با مفاهیم دیتابیس های NoSQL ای نظیر elastic, Arangodb , Cassandra
- آشنا با مفاهیم دیتابیس PostgreSQL
- آشنا با مفاهیم Partitioning و Sharding
- آشنا با مفاهیم HA . کلاسترینگ و Replica Set
- آشنا با سیستم عامل Linux , windows Server
نکات حائز اهمیت:
محیط کاری پویا و یادگیری بالا
کار تیمی

آدرس ارسال رزومه ‌:
[email protected]
آی دی تلگرام برای ارسال رزومه و مشاوره :
@AliMirkhan

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

فرض کنید یک دستیار هوش مصنوعی داشتید که:

👌متریک‌های دیتابیس را دائم بررسی می‌کرد،

👌کوئری‌های غیر‌بهینه را شناسایی و بهبود می‌داد،

👌ایندکس‌های قدیمی را بازسازی می‌کرد،

👌روند مصرف منابع را در بازه‌های زمانی تحلیل می‌کرد،

👌و حتی وقتی نزدیک به کمبود منابع بودید، پیشاپیش هشدار می‌داد.

دقیقاً همین تصویری است که نسل جدید سامانه‌های مدیریت دیتابیس در حال ساخت آن است.


🧩 چالش‌های امروز در مدیریت دیتابیس

ابزارهای مدیریتی سنتی دیتابیس، بیشتر ناظر هستند تا کنش‌گر.

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

در بسیاری از سازمان‌ها، هنوز هم:

⚠️شناسایی کوئری‌های کند به صورت دستی انجام می‌شود،

⚠️بهینه‌سازی ایندکس‌ها فراموش یا به تعویق می‌افتد،

⚠️تنظیم منابع سخت‌افزاری نیازمند دخالت مستقیم DBA است،

⚠️و تصمیم‌های بهبود عملکرد، بدون تحلیل روند بلندمدت گرفته می‌شود.

در حالی که نیاز امروز تیم‌های داده، سامانه‌ای است که بتواند:

✨ پیش از بروز خطا، الگوهای خطر را شناسایی کند،

✨خودش پیشنهاد اصلاح یا بهبود بدهد (و حتی اجرا کند)،

✨از رفتار دیتابیس در طول زمان یاد بگیرد و هوشمندتر شود،

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


⚙️ معرفی : Incerto : کوپایلوت واقعی دیتابیس

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

https://incerto.in

سامانه‌ای که خود را «Real Co-Pilot for Databases» می‌نامد و عملاً مثل یک همکار هوشمند در کنار DBA یا Data Engineer قرار می‌گیرد.

🧠 ویژگی‌های کلیدی آن شامل:

✅ تشخیص خودکار بیش از ۱۰۰ نوع مشکل در محیط‌های تولیدی

✅ بهینه‌سازی خودکار کوئری‌ها با کمک AI و بازخورد انسانی

✅ پشتیبانی از چندین نوع DBMS در یک محیط

✅ تحلیل بار کاری و پیشنهاد تنظیمات منابع

✅ تبدیل زبان طبیعی به وظیفه دیتابیسی («ایندکس‌های بلااستفاده را حذف کن»، «منابع این سرور را بررسی کن»)

✅ یادگیری مستمر از رفتار دیتابیس‌ها برای بهبود تصمیم‌ها

💡 نتیجه؟ صرفه‌جویی چشمگیر در زمان، کاهش خطای انسانی و تمرکز بیشتر تیم‌ها بر تحلیل و تصمیم‌سازی به جای نگهداری روزمره.


🚀 از پایش تا خودکارسازی

ابزارهایی مثل Incerto تنها یک محصول نیستند؛ بلکه نشانه‌ی تحولی بزرگ‌ترند:

🌟 حرکت از پایش و هشدار به درک، پیش‌بینی و اقدام.

🌟از ابزارهای کمکی به عامل‌های هوشمند وظیفه‌گرا (Agentic Systems).

شاید در آینده‌ای نه‌چندان دور، مدیریت دیتابیس‌ها هم مثل رانندگی، از «کوپایلوت» به «اتوپایلوت» برسد البته با قابلیت Human-in-the-Loop؛ یعنی هر جا نیاز به قضاوت انسانی باشد، سیستم صبر کند تا کارشناس تأیید کند و پس از آن، اکشن به‌صورت خودکار اجرا شود.

✨ به نظر شما آیا زمان آن رسیده که مدیریت دیتابیس‌ها را هم به دست دستیارهای هوش مصنوعی بسپاریم؟

‍ 💫 آنچه خوبان همه دارند، تو تنها داری: معرفی OpenObserve

بیش از یک دهه پیش، مسیر من در دنیای مشاهده‌پذیری زیرساخت‌ها (#Observability) با پشته‌ی کلاسیک ELK (Elasticsearch, Logstash, Kibana) آغاز شد.
در سال‌های بعد، ابزارهایی چون #VictoriaMetrics و #Signoz را نیز تجربه کردم، هر یک با ویژگی‌هایی ارزشمند در حوزه‌ی متریک‌ها، لاگ‌ها و تریس‌ها.

اما در این مسیر، اخیراً با پلتفرمی مواجه شدم که به نظرم می‌رسد حرف تازه‌ای برای گفتن دارد:
🚀 OpenObserve (O2)
openobserve.ai

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

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

پروژه #OpenObserve از Apache Parquet به‌عنوان فرمت ذخیره‌سازی ستونی و از DataFusion Query Engine برای اجرای مستقیم کوئری‌ها استفاده می‌کند. (دیتافیوژن مشابه با #duckdb است که با زبان rust توسعه یافته و متعلق به بنیاد آپاچی است)
این طراحی نشان‌دهنده‌ی حرکت آگاهانه به سمت همان معماری‌ای است که در نسل جدید سیستم‌های داده دیده می‌شود:
> جداسازی کامل لایه‌ی ذخیره‌سازی (Storage Layer) از لایه‌ی محاسبات (Compute Layer)
و تعامل از طریق فرمت‌های باز، ستونی و بهینه مثل #Parquet.

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

⚙️ آنچه در بررسی اولیه توجه من را جلب کرد

🔰 امکان Full-Stack Observability برای Logs، Metrics و Traces در یک بستر واحد

🔰 پشتیبانی از Session Replay و Real User Monitoring (RUM) برای تحلیل تجربه‌ی واقعی کاربران

🔰 معماری Stateless با مقیاس‌پذیری افقی آسان

🔰 قابلیت High Compression (~40×) و هزینه‌ی ذخیره‌سازی تا ۱۴۰× کمتر از Elasticsearch

🔰 پشتیبانی از ذخیره‌سازی در S3، MinIO، GCS و Azure Blob

🔰 کوئری با SQL، PromQL و VRL

🔰 سیستم Observability Pipelines برای پردازش، پالایش و غنی‌سازی داده‌ها در لحظه

🔰 طراحی High Availability و Clustering برای نیازهای سازمانی بزرگ

⚡ عملکرد و مقیاس

در بنچمارک داخلی، OpenObserve توانسته است ۱ پتابایت داده را در کمتر از ۲ ثانیه کوئری بگیرد، عددی که حتی برای سیستم‌های تحلیلی مدرن نیز قابل توجه است.
معماری Stateless Node آن امکان گسترش افقی بدون پیچیدگی Replication یا وابستگی داده را فراهم می‌کند.

🌍 جامعه و مسیر رشد

این پروژه‌ی متن‌باز اکنون بیش از ۱۶٬۰۰۰ ستاره در GitHub دارد و توسط جامعه‌ای فعال از متخصصان DevOps، SRE و مهندسان داده توسعه می‌یابد.
مستندات رسمی و نمونه‌های کاربردی در openobserve.ai/docs در دسترس است.

🧭 دعوت از تیم‌های DevOps و SRE

اگر در زمینه‌ی DevOps، SRE، Data Platform یا Observability فعالیت می‌کنید، پیشنهاد می‌کنم OpenObserve را از نزدیک بررسی کنید.
ترکیب زبان Rust، طراحی چندلایه‌ی مبتنی بر Parquet و DataFusion، و مجموعه‌ی کامل قابلیت‌ها از Session Replay تا Alerting و Metrics Analysis
آن را به یکی از جامع‌ترین و آینده‌نگرترین پلتفرم‌های مشاهده‌پذیری حال حاضر تبدیل کرده است.
کانال مهندسی داده:
https://t.iss.one/bigdata_ir