خرید پروژه‌ی متن‌باز Arroyo توسط Cloudflare 🔥

شرکت Cloudflare به‌تازگی اعلام کرده که پروژه‌ی Arroyo، یکی از نوآورانه‌ترین موتورهای پردازش جریان داده، را به مجموعه‌ی خود افزوده است. این پروژه که در سال ۲۰۲۲ با زبان #Rust 🦀 و توسط دو بنیان‌گذار راه‌اندازی شد، بر تجربه‌ای بی‌نیاز از مدیریت زیرساخت، عملکرد بالا و سادگی در توسعه متمرکز بوده است.

منبع خبر : https://www.arroyo.dev/blog/arroyo-is-joining-cloudflare

این خرید از دو جهت برای من مهم است:

🧠 کلودفلیر با افزودن قابلیت پردازش جریان با SQL 📊 به سرویس‌هایی مثل R2 ، Workers ⚙️ و Queues ، یک گام مهم به‌سوی ساخت پلتفرم ابری کامل، مقیاس‌پذیر و بی‌نیاز از مدیریت زیرساخت برداشته است—رقابتی جدی برای #AWS و #GoogleCloud.

🧠 پروژه‌ی متن‌باز Arroyo تنها با تلاش دو نفر در ۲۰۲۲ آغاز شد و امروز توسط یکی از بزرگ‌ترین شرکت‌های اینترنتی خریداری شده است؛ نمونه‌ای الهام‌بخش از اینکه تیم‌های کوچک هم می‌توانند به موفقیت‌های بزرگ برسند. 🚀

جزییات این خبر و این پروژه را با هم کمی مرور می‌کنیم.


🔍 کتابخانه Arroyo : ساده‌سازی پردازش جریان بلادرنگ برای همه ⚙️

پروژه Arroyo یک موتور پردازش جریان (#StreamProcessing) مدرن و متن‌باز است که با هدفی روشن توسعه یافته:

💡 «تبدیل پردازش جریان از یک فناوری پیچیده و لوکس به ابزاری ساده و در دسترس، شبیه نوشتن یک کوئری SQL معمولی برای یک جدول پایگاه‌داده.»

این پروژه با هدف ساده‌سازی توسعه‌ی سیستم‌های پردازش آنی و حذف پیچیدگی‌های زیرساختی ایجاد شده ⚡️ و از فناوری‌های مدرنی مانند Apache Arrow 🏹 و DataFusion 🔗 بهره می‌برد تا عملکرد بالا و کارایی حافظه را تضمین کند.



✨ مهم‌ترین قابلیت‌های Arroyo:

✅ پشتیبانی کامل از SQL با بیش از ۳۰۰ تابع توکار برای تحلیل‌های زمانی، پنجره‌ای و آماری

✅ دقت بالا با Exactly-Once Semantics حتی در صورت بروز خطا یا دریافت داده‌های نامرتب

✅ پشتیبانی از انواع پنجره‌ها (گروه‌بندی زمانی رخدادها): sliding، tumbling و session ⏱️

✅ اتصال به منابع متنوع مانند #Kafka 🧩، #Redis 🔴، #RabbitMQ 🐰 و CDC

✅ مقیاس‌پذیری برای پردازش میلیون‌ها رویداد در ثانیه ⚡️

✅ پشتیبانی از UDF با #Python 🐍، پروتکل Protobuf و مدیریت TTL در وضعیت‌ها

✅ امکان ساخت lookup tables برای داده‌های جریانی 🧷


📸 برای اینکه دقیقا متوجه شوید منظور از پردازش جریان با Arroyo آنهم فقط به کمک SQL‌ چیست، می‌توانید به عکس‌های پایین این پست دقت کنید.


اکنون با پیوستن Arroyo به زیرساخت گسترده‌ی Cloudflare، کاربران می‌توانند از مزایای ترکیب پردازش آنی SQL (به کمک Arroyo)، ذخیره‌سازی ابری (R2)، صف‌های توزیع‌شده (Queues) و اجرای بدون سرور (Workers) در قالب یک پلتفرم یکپارچه و مقیاس‌پذیر بهره‌مند شوند.

🔓کتابخانه Arroyo همچنان متن‌باز و قابل میزبانی مستقل باقی خواهد ماند، و با حمایت Cloudflare از توسعه‌ی پایدار، افزایش کارایی و رشد جامعه‌ی کاربران خود بهره‌مند خواهد شد.

🚀 برای مهندسان داده، استارتاپ‌ها، مدیران محصول، تحلیل‌گران داده و تیم‌هایی که به‌دنبال جایگزینی سریع‌تر و ساده‌تر برای #ApacheFlink یا سایر ابزارهای پردازش جریان هستند، Arroyo اکنون نه‌تنها یک انتخاب هوشمندانه، بلکه یک بستر قدرتمند برای آینده است.

🦀 همچنین Arroyo نمونه‌ای از موج نوین پروژه‌های مبتنی بر زبان برنامه‌نویسی Rust است؛ زبانی که با امنیت بالا و مدیریت حافظه‌ی بسیار دقیق، در حال گشودن مرزهای تازه‌ای در دنیای زیرساخت‌های داده و پردازش بلادرنگ است.

‍ پروژه آموزشی : ساخت یک سامانه پردازش جریان به کمک ردپاندا، کلیک‌هوس و سوپرست
اخیرا پستی از یکی از دوستان در لینکدین مشاهده کردم که وظیفه خود دانستم آنرا برای علاقه مندان به انجام پروژه های عملی و کاربردی در دنیای مهندسی داده به اشتراک بگذارم.
آدرس پست اصلی : https://lnkd.in/d6i7Eiti

این پست گزارش یک پروژه انجام شده توسط سایه حجازی Saieh Hejazi است. در چند سال گذشته، سایه با پشتکار و علاقه‌ای ستودنی، مسیر حرفه‌ای خود را از حوزه‌ی هوش تجاری (BI) به‌سمت مهندسی داده گسترش داده است. من در طول این مسیر شاهد یادگیری‌های عمیق، پیگیری‌های فنی، و تلاش‌های مستمر او بوده‌ام.

به‌تازگی، سایه یکی از پروژه‌های مهم و واقعی خود را منتشر کرده که واقعاً برای بسیاری از علاقه‌مندان به یادگیری پایپ‌لاین‌های داده‌ای real-time، الهام‌بخش است:

🎯 Build a Real-Time Data Pipeline with Redpanda, ClickHouse, and Superset


پروژه‌ای کامل، کاربردی، و مبتنی بر ابزارهای مدرن و سریع.

🔧 فلو‌ی اصلی پروژه به این صورت است:

📁 منبع داده‌ها به‌شکل فایل‌هایی (مثلاً CSV یا JSON) است که در یک فولدر مشخص قرار می‌گیرند و از طریق FTP Server قابل دسترسی هستند.

🛠 ابزار Redpanda Connect که یک کتابخانه قدرتمند ingestion بدون کدنویسی است، به‌صورت مداوم این پوشه را مانیتور می‌کند. به‌محض ورود فایل جدید، آن را می‌خواند و محتوای آن را به‌صورت یک پیام (event) وارد Redpanda می‌کند.

🧠 این‌جا، #Redis وارد عمل می‌شود: با استفاده از Redis، برای هر فایل ورودی یا رکورد، یک مکانیسم #deduplication پیاده‌سازی شده تا از ورود چندباره‌ی داده‌ها جلوگیری شود. این کار ریسک رکوردهای تکراری را از بین می‌برد و کیفیت داده را در مرحله‌ی ingestion تضمین می‌کند. این کار البته توسط خود ردپاندا کانکت انجام می شود اما تنظیمات لازم برای این منظور باید انجام شود.

🚀 داده‌هایی که وارد Redpanda شده‌اند، به‌کمک Kafka engine در ClickHouse به‌صورت real-time مصرف می‌شوند و مستقیماً وارد یک جدول تحلیلی می‌گردند.

📊 در نهایت، Apache Superset به این جدول در ClickHouse# متصل است و به‌صورت بلادرنگ (real-time) داشبوردهایی از این داده‌ها ایجاد کرده که تحلیل سریع و قابل مشاهده برای کاربر نهایی را ممکن می‌سازد.



🧰 ابزارهای کلیدی مورد استفاده در این پروژه عبارتند از:

👉 #Redpanda: موتور سریع و سبک استریم داده (جایگزین Kafka)

👉 Redpanda Connect (Benthos سابق): ابزار ingestion بدون کدنویسی برای ارسال/دریافت داده با حجم بالا

👉 #Redis: برای deduplication و جلوگیری از ingest دوباره رکوردها

👉 #ClickHouse: پایگاه‌داده ستونی برای ذخیره و تحلیل سریع داده‌ها

👉 Superset: داشبورد تحلیلی متن‌باز برای نمایش داده‌های real-time


📌 تمامی کدها، کانفیگ‌ها و مستندات راه‌اندازی در این ریپوی گیت‌هاب در دسترس هستند:

https://github.com/saiehhejazi/Project_2

برای سایه عزیز آرزوی موفقیت در آغاز یک دوره نوین تخصصی در دنیای مهندسی داده دارم. مطمئنم این پروژه تنها نقطه‌ی شروع برای دستاوردهای بزرگ‌تر و تأثیرگذارتر در آینده‌ی حرفه‌ای او خواهد بود. 🌟

پ.ن:
سایر دوستان هم اگر پروژه هایی مشابه با این را انجام داده اند که بار آموزشی برای علاقه مندان به مهندسی داده دارد، ممنون میشوم آنرا برای ادمین کانال ارسال کنید تا با سایر علاقه مندان به این حوزه هم به اشتراک گذاشته شود.

‍ آیا ردیس همچنان پادشاه حافظه‌هاست ؟ 👑

در دنیای فناوری، حتی محبوب‌ترین ابزارها هم برای ادامه مسیر به رقیب نیاز دارند. همان‌طور که در حوزه پردازش جریان، ظهور #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 هنوز پادشاه دنیای پایگاه داده‌های درون‌حافظه‌ای است، اما حالا باید برای حفظ جایگاهش بیشتر تلاش کند. برای ما مهندسان نرم‌افزار، این یعنی گزینه‌های بیشتر، آزادی انتخاب بالاتر و آینده‌ای پر از نوآوری.

‍ معماری‌های مدرن؛ زمان بازنگری در نقش لایه‌ کش فرا رسیده است؟

برای سال‌ها، Redis سلطان بی‌رقیب کش کردن داده در حافظه است.

تقریباً هر معماری استانداردی یک «لایه کش» دارد:

✨ درخواست می‌آید → اول سراغ Redis → اگر نبود → می‌رود سراغ دیتابیس → و نتیجه دوباره در Redis ذخیره می‌شود.

این الگو آن‌قدر جا افتاده است که کمتر کسی جرئت می‌کند بپرسد:

«آیا واقعاً همیشه به Redis نیاز داریم؟»

اما با پیشرفت‌های اخیر دیتابیس‌ها - مخصوصاً #PostgreSQL - حالا این سؤال دوباره ارزش پرسیدن دارد.

و داستان تیمی که اخیراً توانست کل لایه Redis خود را حذف کند، یک نمونه جذاب برای ما مهندسین داده است.

👉 https://freedium-mirror.cfd/https://medium.com/@ArkProtocol1/why-postgres-18-let-me-delete-a-whole-cache-tier-bba2b4f1c742

🔹 بیایید داستان را با هم مرور کنیم…

یک تیم محصول، مثل بسیاری از ما، سال‌ها بود که برای پاسخ‌های سریع از Redis استفاده می‌کرد. اما در روزهای پر ترافیک، خود Redis یک پای داستان بود:

⚠️بار CPU بالا

⚠️ تاخیرهای عجیب

⚠️شبکه تحت فشار

درحالی‌که دیتابیس… نسبتاً آرام و بی‌کار نشسته!

نقطه عطف زمانی بود که آن‌ها PostgreSQL 18 را تست کردند، نسخه‌ای با تغییرات جدی:

⚡️امکان I/O ناهمگام واقعی

⚡️بهبودهای چشمگیر در استفاده از ایندکس‌ها

⚡️امکان virtual generated columns برای محاسبات سریع‌تر و بدون لایه جانبی

این‌ها فقط «بهبود» نبود؛ بازی را عوض کرد.

تیم تصمیم گرفت یک آزمایش مخفیانه انجام دهد:

یک endpoint بسیار شلوغ را مستقیم روی #PostgreSQL بگذارد، بدون #Redis.

انتظار داشتند کندتر شود.

اما نتیجه دقیقاً برعکس بود:

🔰 معیار p95 از ۷۲ میلی‌ثانیه → رسید به ۵۴ میلی‌ثانیه

🔰 نرخ hit rate از ۹۱٪ → شد ۱۰۰٪

🔰 و دیگر خبری از فشار شبکه و CPU نبود.

در واقع لایه کش نه‌تنها کمکی نکرده بود، بلکه گلوگاه اصلی سیستم شده بود.

در نهایت، آن‌ها با خیال راحت Redis را کنار گذاشتند.

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

از آن مهم‌تر: عملکرد بهتر شد.

رد پای یک روند بزرگ‌تر: تجربه #ScyllaDB

سال گذشته هم در وبلاگ ScyllaDB نمونه مشابهی دیدم: جایی که تیم SecurityScorecard به این نتیجه رسیده بود که با توجه به سرعت بالا، معماری توزیع‌شده و کش داخلی ScyllaDB، دیگر نیازی به یک لایه Redis جداگانه ندارند. آن‌ها نیز مانند مثال بالا دریافتند که پیچیدگی همگام‌سازی دیتابیس و کش، در برابر توان پردازشی دیتابیس‌های مدرن، برای برخی سناریوها توجیه خود را از دست داده است.
https://www.scylladb.com/compare/scylladb-vs-cache

✅ بنابراین اگر در پروژه‌های خود به‌صورت پیش‌فرض همه‌چیز را به Redis می‌سپارید، شاید وقت آن رسیده باشد که امکانات دیتابیس‌های جدید، یا حتی توان واقعی دیتابیس اصلی‌تان، را دوباره بررسی کنید. گاهی پاسخ سریع‌تر و ساده‌تر، همان‌جایی است که سال‌ها از آن عبور کرده‌ایم.

🔹 درس ماجرا چیست؟

این داستان نمی‌گوید «Redis را حذف کنید».

ردیس همچنان یک ابزار قدرتمند و ضروری برای بسیاری از سناریوهاست.

اما یک نکته مهم را روشن می‌کند:

گاهی فناوری‌های پایه آن‌قدر جلو می‌روند که معماری‌های کهنه دیگر بهترین انتخاب نیستند.

💡شاید وقت آن باشد که به جای تکرار الگوهای سال‌های گذشته، دوباره از خود بپرسیم:

⚡️ آیا دیتابیس ما امروز آن‌قدر قدرتمند شده که خودش نقش کش را بازی کند؟

⚡️ آیا لایه کش واقعاً سرعت‌دهنده است یا ناخواسته گره اضافه کرده‌ایم؟

⚡️ آیا پیچیدگی اضافه همیشه ارزشش را دارد؟

‍ کافکا کانکت؛ ستون اتصال کافکا به دنیای واقعی

در معماری‌های داده مدرن، تنها داشتن یک پلتفرم قدرتمند برای پردازش و انتقال پیام‌ها کافی نیست، ما باید بتوانیم به‌سادگی و بدون نوشتن کد اضافی، داده را از سیستم‌های مختلف به کافکا وارد کنیم یا از کافکا به مقصدهای متنوع منتقل کنیم. Kafka Connect یک فریم‌ورک استاندارد، مقیاس‌پذیر و قابل‌اعتماد برای اتصال Kafka به دنیای بیرون است.

کافکا کانکت سرویس جانبی و رایج کافکاست که وظیفه آن مدیریت و اجرای پایدار کانکتورها است؛ اجزایی پیکربندی‌محور که مشخص می‌کنند داده چگونه باید از یک سیستم خارجی وارد کافکا شود (Source) یا از کافکا به جایی دیگر برود (Sink). هر Connector تنها یک تعریف پیکربندی‌شده است که روی یک Plugin (مجموعه‌ای از کلاس‌های جاوا که باید نصب شود) سوار می‌شود و مشخص می‌کند داده چگونه باید از سیستم‌های خارجی وارد Kafka شود یا از Kafka به مقصد دیگری منتقل گردد. منطق تعامل، درون Plugin است، اما Kafka Connect مسئول اجرای مداوم، نظارت، مدیریت خطا، مقیاس‌پذیری و هماهنگی Taskها که در قالب کانکتورها تعریف می‌شوند را برعهده دارد.

از Datagen برای تولید داده‌های نمونه، تا #Debezium برای CDC روی دیتابیس‌ها و تا #Redis Sink برای انتقال داده به سیستم‌های کش، Kafka Connect پایه‌ اصلی ساخت Data Pipelineهای استاندارد، قابل اطمینان و Production-Grade است.

در ویدئوی جدید کانال یوتیوب مدرسه مهندسی داده سپهرام، یک کارگاه عملی کامل آماده کرده‌ایم که در آن:

⚙️ یک کلاستر Kafka Connect با Docker Compose راه‌اندازی می‌کنیم

📥کانکتور Datagen را اجرا می‌کنیم

🔄 کانکتور Debezium را روی PostgreSQL راه می‌اندازیم و تغییرات جدول‌ها را به کافکا استریم می‌کنیم

📤 داده‌ها را با Redis Sink Connector به Redis منتقل می‌کنیم

اگر می‌خواهید Kafka Connect را در عمل ببینید، این ویدئو مخصوص شماست

▶️ مشاهده در یوتیوب: https://youtu.be/Uxn5pJRhmjM

این بخش بخشی از دوره آموزشی کافکا در مدرسه مهندسی داده سپهرام است.