شمارش بازدیدها و اکشن‌های کاربر با فناوری‌های مدرن داده
در پست قبلی درباره روش‌های کلاسیک شمارش بازدید محصولات یا تماشای ویدئو صحبت کردم.
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