‍ شمارش بازدیدها و اکشن‌های کاربر با فناوری‌های مدرن داده

در پست قبلی درباره روش‌های کلاسیک شمارش بازدید محصولات یا تماشای ویدئو صحبت کردم.

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

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