چرا Discord بخش‌هایی از زیرساخت خود را از Go به Rust منتقل کرده است؟🦀
در سال‌های اخیر، Rust به یکی از محبوب‌ترین زبان‌های برنامه‌نویسی در میان مهندسان ارشد نرم‌افزار و معماران سیستم تبدیل شده است. در حالی که Go به دلیل سادگی و سرعت توسعه همچنان طرفداران خود را دارد، Rust با ایمنی حافظه بی‌نظیر، عملکرد قابل پیش‌بینی و اکوسیستم پویا، به‌ویژه در سیستم‌های حساس و پرترافیک، به گزینه‌ای برتر تبدیل شده است. نمونه بارز این تغییر رویکرد، تصمیم دیسکورد برای بازنویسی سرویس کلیدی "Read States" از Go به Rust است که در مقاله‌ای توسط جسی هووارث در سال 2020 شرح داده شده است. در این پست، دلایل این مهاجرت، مزایای Rust و روند روبه‌رشد پذیرش آن در صنعت بررسی می‌شود.
لینک مقاله اصلی :
https://discord.com/blog/why-discord-is-switching-from-go-to-rust
چرا Rust؟ روند روبه‌رشد در میان مهندسان ارشد
Rust به دلیل ویژگی‌های منحصربه‌فردش به‌سرعت در حال جایگزینی Go در پروژه‌های پیچیده است. مهندسان ارشد به دلایل زیر به این زبان روی می‌آورند:
✅ ایمنی حافظه و هم‌زمانی در زمان کامپایل: Rust با سیستم مالکیت (Ownership) و Borrow Checker، خطاهایی مانند استفاده پس از آزادسازی (Use-After-Free) یا شرایط رقابتی (Data Races) را در زمان کامپایل حذف می‌کند. این ویژگی برای پروژه‌های حساس مانند runtime امن IoT تیم Azure مایکروسافت حیاتی بود، جایی که وقفه‌های ناشی از GC یا باگ‌های هم‌زمانی قابل‌تحمل نبودند.
✅ عملکرد پایدار و بدون افت: بدون نیاز به جمع‌آوری زباله (GC)، Rust باینری‌های Native تولید می‌کند که عملکردی قابل پیش‌بینی دارند. این ویژگی در سرویس‌های پرترافیک مانند Read States دیسکورد، تاخیرهای لحظه‌ای را حذف کرد.
✅ نگهداری بلندمدت: ابزارهایی مانند Cargo، پیام‌های خطای دقیق و استانداردهای کدنویسی قوی، کدهای Rust را خوانا و پایدار نگه می‌دارند، که در پروژه‌های طولانی‌مدت ارزشمند است.
✅ اکوسیستم پویا: crates.io با رشد بیش از 2.1 برابر در سال و بیش از 430 میلیون دانلود در یک روز در سال 2024، نشان‌دهنده بلوغ کتابخانه‌های Rust در حوزه‌هایی مانند WebAssembly، بلاک‌چین و سیستم‌های ابری است.
✅ پذیرش گسترده در صنعت: پروژه‌هایی مانند Firecracker (آمازون)، Solana (بلاک‌چین) و سیستم‌های IoT مایکروسافت، Rust را به دلیل ایمنی و کنترل دقیق انتخاب کرده‌اند.
سرویس Read States دیسکورد: چالش‌های Go
سرویس Read States در دیسکورد وظیفه ردیابی وضعیت خوانده شدن پیام‌ها و کانال‌ها را بر عهده دارد. این سرویس در هر اتصال، ارسال یا خواندن پیام فعال می‌شود و باید تاخیری بسیار پایین داشته باشد تا تجربه کاربری روان بماند. نسخه Go این سرویس در اکثر مواقع سریع بود، اما هر چند دقیقه با تاخیرهای ناگهانی (Latency Spikes) مواجه می‌شد که به مدل حافظه و GC مربوط بود.
مشکلات Go:
❓ ساختار داده و مقیاس: Read States شامل میلیاردها شیء است که برای هر کاربر و کانال یک نمونه دارند. این اشیاء در یک کش LRU با میلیون‌ها نمونه ذخیره می‌شوند و صدها هزار به‌روزرسانی در ثانیه دارند.
❓ جمع‌آوری زباله: در Go، حافظه پس از اخراج از کش بلافاصله آزاد نمی‌شود. GC هر 2 دقیقه یک‌بار اجرا می‌شود و کل کش را اسکن می‌کند، که باعث تاخیرهای قابل‌توجه می‌شد.
❓تلاش‌های بهینه‌سازی: تنظیم درصد GC بی‌اثر بود، زیرا تخصیص حافظه به اندازه کافی سریع نبود. کاهش اندازه کش LRU تاخیرهای GC را کم کرد، اما به دلیل افزایش بارگذاری از پایگاه داده Cassandra، تاخیرهای 99th Percentile افزایش یافت.
با وجود بهینه‌سازی‌های متعدد، عملکرد Go همچنان ناکافی بود. دیسکورد که پیش‌تر از Rust در بخش‌هایی مانند کدگذاری ویدئو (Go Live) و NIFهای Elixir استفاده کرده بود، تصمیم گرفت این سرویس را به Rust منتقل کند.
✴️ ورود Rust به صحنه
تیم Discord پیش‌تر در بخش‌هایی مثل رمزنگاری و پردازش ویدئو از Rust استفاده کرده بود، و تصمیم گرفت یک نسخه‌ی کامل از Read States را با Rust بازنویسی کند.
📊 نتایج شگفت‌انگیز بودند:
✅ بدون GC → مدیریت حافظه در زمان کامپایل (مدل Ownership)
✅ تأخیر یکنواخت‌تر → حذف spikes ناشی از GC
✅ ایمنی حافظه در زمان کامپایل → بدون نیاز به چک‌های runtime
✅ پشتیبانی قوی از async → با استفاده از tokio و async/await
📈 نتایج نهایی:
✅ بهبود چشمگیر درصدهای ۹۹٪ و ۹۹.۹٪ در زمان پاسخ‌دهی
✅ تاخیر: تاخیرهای دوره‌ای حذف شدند، میانگین زمان پاسخ به میکروثانیه و حداکثر زمان برای @mentions به میلی‌ثانیه رسید.
✅ منابع: مصرف CPU و حافظه به‌طور چشمگیری کاهش یافت.
✅ افزایش ظرفیت کش: برخلاف Go، افزایش ظرفیت کش LRU به 8 میلیون Read State عملکرد را بهبود داد، زیرا Rust نیازی به GC نداشت.
🧠 جمع‌بندی برای مهندسین نرم‌افزار/داده:
در سال‌های اخیر، Rust به یکی از محبوب‌ترین زبان‌های برنامه‌نویسی در میان مهندسان ارشد نرم‌افزار و معماران سیستم تبدیل شده است. در حالی که Go به دلیل سادگی و سرعت توسعه همچنان طرفداران خود را دارد، Rust با ایمنی حافظه بی‌نظیر، عملکرد قابل پیش‌بینی و اکوسیستم پویا، به‌ویژه در سیستم‌های حساس و پرترافیک، به گزینه‌ای برتر تبدیل شده است. نمونه بارز این تغییر رویکرد، تصمیم دیسکورد برای بازنویسی سرویس کلیدی "Read States" از Go به Rust است که در مقاله‌ای توسط جسی هووارث در سال 2020 شرح داده شده است. در این پست، دلایل این مهاجرت، مزایای Rust و روند روبه‌رشد پذیرش آن در صنعت بررسی می‌شود.
لینک مقاله اصلی :
https://discord.com/blog/why-discord-is-switching-from-go-to-rust
چرا Rust؟ روند روبه‌رشد در میان مهندسان ارشد
Rust به دلیل ویژگی‌های منحصربه‌فردش به‌سرعت در حال جایگزینی Go در پروژه‌های پیچیده است. مهندسان ارشد به دلایل زیر به این زبان روی می‌آورند:
✅ ایمنی حافظه و هم‌زمانی در زمان کامپایل: Rust با سیستم مالکیت (Ownership) و Borrow Checker، خطاهایی مانند استفاده پس از آزادسازی (Use-After-Free) یا شرایط رقابتی (Data Races) را در زمان کامپایل حذف می‌کند. این ویژگی برای پروژه‌های حساس مانند runtime امن IoT تیم Azure مایکروسافت حیاتی بود، جایی که وقفه‌های ناشی از GC یا باگ‌های هم‌زمانی قابل‌تحمل نبودند.
✅ عملکرد پایدار و بدون افت: بدون نیاز به جمع‌آوری زباله (GC)، Rust باینری‌های Native تولید می‌کند که عملکردی قابل پیش‌بینی دارند. این ویژگی در سرویس‌های پرترافیک مانند Read States دیسکورد، تاخیرهای لحظه‌ای را حذف کرد.
✅ نگهداری بلندمدت: ابزارهایی مانند Cargo، پیام‌های خطای دقیق و استانداردهای کدنویسی قوی، کدهای Rust را خوانا و پایدار نگه می‌دارند، که در پروژه‌های طولانی‌مدت ارزشمند است.
✅ اکوسیستم پویا: crates.io با رشد بیش از 2.1 برابر در سال و بیش از 430 میلیون دانلود در یک روز در سال 2024، نشان‌دهنده بلوغ کتابخانه‌های Rust در حوزه‌هایی مانند WebAssembly، بلاک‌چین و سیستم‌های ابری است.
✅ پذیرش گسترده در صنعت: پروژه‌هایی مانند Firecracker (آمازون)، Solana (بلاک‌چین) و سیستم‌های IoT مایکروسافت، Rust را به دلیل ایمنی و کنترل دقیق انتخاب کرده‌اند.
سرویس Read States دیسکورد: چالش‌های Go
سرویس Read States در دیسکورد وظیفه ردیابی وضعیت خوانده شدن پیام‌ها و کانال‌ها را بر عهده دارد. این سرویس در هر اتصال، ارسال یا خواندن پیام فعال می‌شود و باید تاخیری بسیار پایین داشته باشد تا تجربه کاربری روان بماند. نسخه Go این سرویس در اکثر مواقع سریع بود، اما هر چند دقیقه با تاخیرهای ناگهانی (Latency Spikes) مواجه می‌شد که به مدل حافظه و GC مربوط بود.
مشکلات Go:
❓ ساختار داده و مقیاس: Read States شامل میلیاردها شیء است که برای هر کاربر و کانال یک نمونه دارند. این اشیاء در یک کش LRU با میلیون‌ها نمونه ذخیره می‌شوند و صدها هزار به‌روزرسانی در ثانیه دارند.
❓ جمع‌آوری زباله: در Go، حافظه پس از اخراج از کش بلافاصله آزاد نمی‌شود. GC هر 2 دقیقه یک‌بار اجرا می‌شود و کل کش را اسکن می‌کند، که باعث تاخیرهای قابل‌توجه می‌شد.
❓تلاش‌های بهینه‌سازی: تنظیم درصد GC بی‌اثر بود، زیرا تخصیص حافظه به اندازه کافی سریع نبود. کاهش اندازه کش LRU تاخیرهای GC را کم کرد، اما به دلیل افزایش بارگذاری از پایگاه داده Cassandra، تاخیرهای 99th Percentile افزایش یافت.
با وجود بهینه‌سازی‌های متعدد، عملکرد Go همچنان ناکافی بود. دیسکورد که پیش‌تر از Rust در بخش‌هایی مانند کدگذاری ویدئو (Go Live) و NIFهای Elixir استفاده کرده بود، تصمیم گرفت این سرویس را به Rust منتقل کند.
✴️ ورود Rust به صحنه
تیم Discord پیش‌تر در بخش‌هایی مثل رمزنگاری و پردازش ویدئو از Rust استفاده کرده بود، و تصمیم گرفت یک نسخه‌ی کامل از Read States را با Rust بازنویسی کند.
📊 نتایج شگفت‌انگیز بودند:
✅ بدون GC → مدیریت حافظه در زمان کامپایل (مدل Ownership)
✅ تأخیر یکنواخت‌تر → حذف spikes ناشی از GC
✅ ایمنی حافظه در زمان کامپایل → بدون نیاز به چک‌های runtime
✅ پشتیبانی قوی از async → با استفاده از tokio و async/await
📈 نتایج نهایی:
✅ بهبود چشمگیر درصدهای ۹۹٪ و ۹۹.۹٪ در زمان پاسخ‌دهی
✅ تاخیر: تاخیرهای دوره‌ای حذف شدند، میانگین زمان پاسخ به میکروثانیه و حداکثر زمان برای @mentions به میلی‌ثانیه رسید.
✅ منابع: مصرف CPU و حافظه به‌طور چشمگیری کاهش یافت.
✅ افزایش ظرفیت کش: برخلاف Go، افزایش ظرفیت کش LRU به 8 میلیون Read State عملکرد را بهبود داد، زیرا Rust نیازی به GC نداشت.
🧠 جمع‌بندی برای مهندسین نرم‌افزار/داده:
👍3
ادامه از پست قبل :
زبان Rust به‌دلایل زیر به انتخاب مهمی برای سیستم‌های mission-critical تبدیل شده است:
🔹 مدیریت حافظه بدون GC
🔹 پرفورمنس بالا و قابل پیش‌بینی
🔹 ایمنی حافظه و هم‌زمانی در زمان کامپایل
🔹 اکوسیستم async در حال رشد (tokio، actix و...)
🏢 شرکت‌هایی مثل AWS، Microsoft، Discord با مهاجرت به Rust، این مسیر را هم فنی و هم راهبردی می‌دانند.
💡 اما باید واقع‌بین بود:
⚠️ اکوسیستم Rust هنوز به بلوغ کامل نرسیده
⚠️ منحنی یادگیری بالا دارد
⚠️ توسعه آن نسبت به Go و Python سخت تر است.
اما در حوزه‌هایی مثل:
🚀 طراحی زیرساخت داده
🔁 پایپ‌لاین‌های پردازش مقیاس‌پذیر
💡 سامانه‌های real-time و سنگین
زبان Rust یک انتخاب اجتناب ناپذیر شده است.
در صنعت نیز، Rust در پروژه‌هایی مانند Firecracker، Solana و سیستم‌های IoT مایکروسافت به دلیل ایمنی و عملکرد بالا پذیرفته شده است. به گفته یکی از متخصصان:
«نبوغ Go در داشتن GC است. نبوغ Rust در این است که به آن نیازی ندارد.»
مهاجرت سرویس Read States از Go به Rust نمونه‌ای موفق از پذیرش فناوری‌های نوظهور برای حل مشکلات عملکرد است. Rust با حذف تاخیرهای GC، بهبود عملکرد و ارائه ایمنی حافظه، تجربه کاربری بهتری برای دیسکورد فراهم کرد. در دنیایی که امنیت، عملکرد و قابلیت اطمینان اهمیت روزافزونی دارند، Rust نه‌تنها یک انتخاب خاص، بلکه استانداردی جدید در معماری نرم‌افزار است. در دنیای مهندسی داده، که سرعت، پایداری و کنترل منابع اهمیت بالایی دارد، Rust می‌تواند مزایای چشمگیری ارائه دهد. این زبان در حال تبدیل شدن به یکی از اجزای کلیدی زیرساخت‌های داده‌ای نسل جدید است — نه فقط به‌عنوان زبان سیستم‌نویسی، بلکه به‌عنوان پلتفرمی برای ساخت سامانه‌های سریع، ایمن و مقیاس‌پذیر.
زبان Rust به‌دلایل زیر به انتخاب مهمی برای سیستم‌های mission-critical تبدیل شده است:
🔹 مدیریت حافظه بدون GC
🔹 پرفورمنس بالا و قابل پیش‌بینی
🔹 ایمنی حافظه و هم‌زمانی در زمان کامپایل
🔹 اکوسیستم async در حال رشد (tokio، actix و...)
🏢 شرکت‌هایی مثل AWS، Microsoft، Discord با مهاجرت به Rust، این مسیر را هم فنی و هم راهبردی می‌دانند.
💡 اما باید واقع‌بین بود:
⚠️ اکوسیستم Rust هنوز به بلوغ کامل نرسیده
⚠️ منحنی یادگیری بالا دارد
⚠️ توسعه آن نسبت به Go و Python سخت تر است.
اما در حوزه‌هایی مثل:
🚀 طراحی زیرساخت داده
🔁 پایپ‌لاین‌های پردازش مقیاس‌پذیر
💡 سامانه‌های real-time و سنگین
زبان Rust یک انتخاب اجتناب ناپذیر شده است.
در صنعت نیز، Rust در پروژه‌هایی مانند Firecracker، Solana و سیستم‌های IoT مایکروسافت به دلیل ایمنی و عملکرد بالا پذیرفته شده است. به گفته یکی از متخصصان:
«نبوغ Go در داشتن GC است. نبوغ Rust در این است که به آن نیازی ندارد.»
مهاجرت سرویس Read States از Go به Rust نمونه‌ای موفق از پذیرش فناوری‌های نوظهور برای حل مشکلات عملکرد است. Rust با حذف تاخیرهای GC، بهبود عملکرد و ارائه ایمنی حافظه، تجربه کاربری بهتری برای دیسکورد فراهم کرد. در دنیایی که امنیت، عملکرد و قابلیت اطمینان اهمیت روزافزونی دارند، Rust نه‌تنها یک انتخاب خاص، بلکه استانداردی جدید در معماری نرم‌افزار است. در دنیای مهندسی داده، که سرعت، پایداری و کنترل منابع اهمیت بالایی دارد، Rust می‌تواند مزایای چشمگیری ارائه دهد. این زبان در حال تبدیل شدن به یکی از اجزای کلیدی زیرساخت‌های داده‌ای نسل جدید است — نه فقط به‌عنوان زبان سیستم‌نویسی، بلکه به‌عنوان پلتفرمی برای ساخت سامانه‌های سریع، ایمن و مقیاس‌پذیر.
👍4
چرا مایکروسافت برای Clarity, دیتابیس تحلیلی کلیک‌هوس را برگزید؟
این پست ترجمه‌ای است از پست رسمی تیم ClickHouse درباره انتخاب این پایگاه داده قدرتمند توسط مایکروسافت.
پست اصلی :
https://www.linkedin.com/posts/clickhouseinc_when-microsoft-made-clarity-free-for-everyone-activity-7325580280390451200-fV_M
زمانی که مایکروسافت ابزار Clarity را به‌صورت رایگان برای عموم عرضه کرد، می‌دانست که باید این سرویس را به سرعت و در مقیاسی عظیم گسترش دهد — پردازش صدها تریلیون رویداد، صدها پتابایت داده، و میلیون‌ها پروژه در سطح جهانی.
برای چنین زیرساختی، انتخاب موتور تحلیلی بسیار مهم بود.
مایکروسافت پس از ارزیابی گزینه‌هایی مانند Elasticsearch و Apache Spark، در نهایت با تحقیقاتی گسترده و تست‌های متعدد، ClickHouse را برگزید.
چرا ClickHouse؟
در اکتبر ۲۰۲۰، Clarity با ClickHouse در قلب خود راه‌اندازی شد. این تصمیم حاصل هفته‌ها آزمایش، بررسی‌های عمیق، سنجش هزینه‌ها و عملکردها، و انتخابی مبتنی بر داده بود.
دلایل اصلی:
📥 عملکرد بارگذاری (Ingestion): موتور MergeTree در ClickHouse، نرخ ورودی بسیار بالایی را پشتیبانی می‌کند که کاملاً با نیاز بار عظیم Clarity هم‌خوانی دارد.
⚡ عملکرد کوئری: پرس‌وجو روی میلیاردها ردیف در کسری از ثانیه، با کارایی فوق‌العاده. این عملکرد سریع، نیاز به منابع پردازشی بیشتر را حذف و هزینه‌ها را کاهش میدهد.
💾 بهره‌وری در ذخیره‌سازی: ساختار ستونی و فشرده‌سازی پیشرفته، موجب صرفه‌جویی چشمگیر در فضای دیسک می‌شود. امکان تعریف دیسک‌های گرم و سرد نیز برای کاهش بیشتر هزینه‌ها فراهم است.
📈 مقیاس‌پذیری افقی: ClickHouse به‌صورت master-master توزیع شده و از replication پشتیبانی می‌کند. این یعنی مقیاس‌پذیری روان و آسان هنگام افزایش ترافیک.
🤝 جامعه‌ی متن‌باز و فعال: انتشار منظم نسخه‌ها، پاسخ‌گویی سریع در GitHub و تلگرام، و پشتیبانی قدرتمند. جالب‌تر اینکه تیم مایکروسافت نیز به پروژه کمک کرده و نام خود را در جدول system.contributors ثبت کرده‌اند!
و در نهایت، همان‌طور که در گزارش رسمی مایکروسافت آمده است:
> Compared to our POC system, ClickHouse outperformed Elastic Search and Spark in every aspect. Heat map generation became an instantaneous task to do, and it was even orders of magnitude cheaper to run. This is the reason why many products have migrated from Elastic Search to ClickHouse, experiencing significant enhancements in their services as a result.
آدرس مقاله اصلی مایکروسافت :
https://clarity-blogs-hbh0gkgebxgwfkgd.westus2-01.azurewebsites.net/why-microsoft-clarity-chose-clickhouse/
#ClickHouse #Microsoft #Clarity #داده_های_انبوه #تحلیل_داده #پایگاه_داده #BigData #DataEngineering #ElasticSearch #Spark #CloudArchitecture #OpenSource #مقیاس‌پذیری #StorageOptimization #DatabasePerformance #DistributedSystems
این پست ترجمه‌ای است از پست رسمی تیم ClickHouse درباره انتخاب این پایگاه داده قدرتمند توسط مایکروسافت.
پست اصلی :
https://www.linkedin.com/posts/clickhouseinc_when-microsoft-made-clarity-free-for-everyone-activity-7325580280390451200-fV_M
زمانی که مایکروسافت ابزار Clarity را به‌صورت رایگان برای عموم عرضه کرد، می‌دانست که باید این سرویس را به سرعت و در مقیاسی عظیم گسترش دهد — پردازش صدها تریلیون رویداد، صدها پتابایت داده، و میلیون‌ها پروژه در سطح جهانی.
برای چنین زیرساختی، انتخاب موتور تحلیلی بسیار مهم بود.
مایکروسافت پس از ارزیابی گزینه‌هایی مانند Elasticsearch و Apache Spark، در نهایت با تحقیقاتی گسترده و تست‌های متعدد، ClickHouse را برگزید.
چرا ClickHouse؟
در اکتبر ۲۰۲۰، Clarity با ClickHouse در قلب خود راه‌اندازی شد. این تصمیم حاصل هفته‌ها آزمایش، بررسی‌های عمیق، سنجش هزینه‌ها و عملکردها، و انتخابی مبتنی بر داده بود.
دلایل اصلی:
📥 عملکرد بارگذاری (Ingestion): موتور MergeTree در ClickHouse، نرخ ورودی بسیار بالایی را پشتیبانی می‌کند که کاملاً با نیاز بار عظیم Clarity هم‌خوانی دارد.
⚡ عملکرد کوئری: پرس‌وجو روی میلیاردها ردیف در کسری از ثانیه، با کارایی فوق‌العاده. این عملکرد سریع، نیاز به منابع پردازشی بیشتر را حذف و هزینه‌ها را کاهش میدهد.
💾 بهره‌وری در ذخیره‌سازی: ساختار ستونی و فشرده‌سازی پیشرفته، موجب صرفه‌جویی چشمگیر در فضای دیسک می‌شود. امکان تعریف دیسک‌های گرم و سرد نیز برای کاهش بیشتر هزینه‌ها فراهم است.
📈 مقیاس‌پذیری افقی: ClickHouse به‌صورت master-master توزیع شده و از replication پشتیبانی می‌کند. این یعنی مقیاس‌پذیری روان و آسان هنگام افزایش ترافیک.
🤝 جامعه‌ی متن‌باز و فعال: انتشار منظم نسخه‌ها، پاسخ‌گویی سریع در GitHub و تلگرام، و پشتیبانی قدرتمند. جالب‌تر اینکه تیم مایکروسافت نیز به پروژه کمک کرده و نام خود را در جدول system.contributors ثبت کرده‌اند!
و در نهایت، همان‌طور که در گزارش رسمی مایکروسافت آمده است:
> Compared to our POC system, ClickHouse outperformed Elastic Search and Spark in every aspect. Heat map generation became an instantaneous task to do, and it was even orders of magnitude cheaper to run. This is the reason why many products have migrated from Elastic Search to ClickHouse, experiencing significant enhancements in their services as a result.
آدرس مقاله اصلی مایکروسافت :
https://clarity-blogs-hbh0gkgebxgwfkgd.westus2-01.azurewebsites.net/why-microsoft-clarity-chose-clickhouse/
#ClickHouse #Microsoft #Clarity #داده_های_انبوه #تحلیل_داده #پایگاه_داده #BigData #DataEngineering #ElasticSearch #Spark #CloudArchitecture #OpenSource #مقیاس‌پذیری #StorageOptimization #DatabasePerformance #DistributedSystems
Linkedin
When Microsoft made Clarity free for everyone, they knew it had to scale -… | ClickHouse
When Microsoft made Clarity free for everyone, they knew it had to scale - fast - to hundreds of trillions of events, hundreds of petabytes of data, and millions of projects.
Their choice to power these workloads? ClickHouse. After testing Elasticsearch…
Their choice to power these workloads? ClickHouse. After testing Elasticsearch…
❤3🔥1
معرفی یک پروژه متن‌باز آموزشی : پایپ‌لاین بلادرنگ داده‌های رمزارز
پروژه‌ای ارزشمند و با اهداف آموزشی توسط آقای عارف فرزانه توسعه داده شده است؛ یک پایپ‌لاین داده‌ای مقیاس‌پذیر و بلادرنگ برای دریافت، پردازش و تحلیل قیمت رمزارزها در زمان واقعی.
این پروژه با هدف آموزش و توسعه ابزارهای تحلیل بلادرنگ طراحی شده و به‌صورت متن‌باز در اختیار علاقه‌مندان قرار گرفته است.
ویژگی‌های فنی پروژه:
✅ استفاده از Quix Streams در پایتون برای پردازش جریان داده‌ها
✅ بهره‌گیری از Redpanda (سازگار با Kafka) برای انتقال داده با کارایی بالا
✅ استفاده از Docker جهت کانتینرسازی و اجرای ماژولار
✅ محاسبه تحلیل‌های بلادرنگ مانند میانگین متحرک
✅ دریافت زنده قیمت رمزارزها از API سرویس CoinLore
✅ معماری مقاوم در برابر خطا با قابلیت بازیابی خودکار
✅ طراحی ماژولار و آماده برای توسعه‌هایی نظیر هشدارهای معاملاتی و داشبوردهای بصری
دسترسی به مخزن پروژه:
github.com/ArefFarzaneh/crypto_data_pipeline
این پروژه می‌تواند مرجع مناسبی برای علاقه‌مندان به شروع پردازش داده‌های بلادرنگ، تحلیل بازار رمزارزها، و توسعه سیستم‌های معاملاتی باشد.
پروژه‌ای ارزشمند و با اهداف آموزشی توسط آقای عارف فرزانه توسعه داده شده است؛ یک پایپ‌لاین داده‌ای مقیاس‌پذیر و بلادرنگ برای دریافت، پردازش و تحلیل قیمت رمزارزها در زمان واقعی.
این پروژه با هدف آموزش و توسعه ابزارهای تحلیل بلادرنگ طراحی شده و به‌صورت متن‌باز در اختیار علاقه‌مندان قرار گرفته است.
ویژگی‌های فنی پروژه:
✅ استفاده از Quix Streams در پایتون برای پردازش جریان داده‌ها
✅ بهره‌گیری از Redpanda (سازگار با Kafka) برای انتقال داده با کارایی بالا
✅ استفاده از Docker جهت کانتینرسازی و اجرای ماژولار
✅ محاسبه تحلیل‌های بلادرنگ مانند میانگین متحرک
✅ دریافت زنده قیمت رمزارزها از API سرویس CoinLore
✅ معماری مقاوم در برابر خطا با قابلیت بازیابی خودکار
✅ طراحی ماژولار و آماده برای توسعه‌هایی نظیر هشدارهای معاملاتی و داشبوردهای بصری
دسترسی به مخزن پروژه:
github.com/ArefFarzaneh/crypto_data_pipeline
این پروژه می‌تواند مرجع مناسبی برای علاقه‌مندان به شروع پردازش داده‌های بلادرنگ، تحلیل بازار رمزارزها، و توسعه سیستم‌های معاملاتی باشد.
GitHub
GitHub - ArefFarzaneh/crypto_data_pipeline
Contribute to ArefFarzaneh/crypto_data_pipeline development by creating an account on GitHub.
👍2❤1
کلیک‌هوس عالیه... ولی همیشه بهترین انتخاب نیست!🌟
در چند سال اخیر، ClickHouse به یکی از سریع‌ترین و محبوب‌ترین دیتابیس‌های تحلیلی تبدیل شده — و خود من هم یکی از کاربران و طرفداران پر و پا قرص این موتور قدرتمند هستم. 🚀
اما در کاربردهای واقعی، انتخاب دیتابیس تحلیلی فقط به سرعت خلاصه نمی‌شود. عواملی مثل پشتیبانی از داده‌های نیمه‌ساخت‌یافته، Joinهای پیچیده، امکان کار با منابع مختلف داده، انعطاف‌پذیری معماری، و قابلیت‌های نگهداری و توسعه، نقش مهمی در تصمیم نهایی دارند.
🛠 کلیک‌هوس ذاتاً برای پردازش‌های تک‌جدولی طراحی شده و برای پشتیبانی از کوئری‌های چندجدولی یا Joinهای پیچیده، معمولاً به راهکارهای جانبی مثل Data Virtualization نیاز دارد. این در حالی است که Doris چنین سناریوهایی را به‌صورت بومی و بهینه پشتیبانی می‌کند.
🎧 تجربه واقعی: مهاجرت Tencent Music Entertainment از ClickHouse به Apache Doris
شرکت Tencent Music Entertainment (TME) با بیش از ۸۰۰ میلیون کاربر فعال ماهانه، تصمیم گرفت معماری داده خود را بازطراحی کند. تیم مهندسی داده‌ی این شرکت با مشکلاتی مثل:
⚠️هزینه بالای ذخیره‌سازی در ClickHouse
⚠️عدم پشتیبانی از به‌روزرسانی جزئی (Partial Update)
⚠️پیچیدگی در اجرای کوئری‌های فدره بین ClickHouse و Elasticsearch
روبهرو بود.
🧭 نتیجه؟ مهاجرت به Doris
مزایای به‌دست‌آمده در این مهاجرت استراتژیک:
✅ کاهش ۴۲٪ در هزینه ذخیره‌سازی
✅ کاهش ۴۰٪ در هزینه توسعه
✅ تعریف یک لایه معنایی (Semantic Layer) برای مدیریت یکپارچه KPIها و تگ‌ها
✅ یکپارچگی بیشتر با Kafka و Flink
✅ کاهش تأخیر در دسترسی به داده‌ها
✅ استفاده از Doris Light Schema Change برای تغییرات ساختاری سریع و کم‌هزینه
🔬 مقایسه عملکردی Doris و ClickHouse در تست‌های واقعی:
در یک تست میدانی منتشر شده در وبلاگ دوریس :
📌 در ۱۰ کوئری از ۱۶ کوئری، Doris تا ۳۰ برابر سریع‌تر از ClickHouse بود!
🔹 ۴ میلیارد ردیف (Join کامل و فیلترشده): Doris بین ۲ تا ۵ برابر سریع‌تر بود؛ ClickHouse با مشکلات حافظه مواجه شد.
🔹 ۲۵ میلیارد ردیف: Doris کوئری‌ها را در چند ثانیه اجرا کرد؛ ClickHouse چند دقیقه زمان برد یا حتی در جداول بزرگ (بالای ۵۰ میلیون ردیف) اجرا نشد.
🔹 ۹۶ میلیارد ردیف: Doris به‌راحتی همه کوئری‌ها را اجرا کرد؛ ClickHouse از عهده‌ی این حجم داده برنیامد.
🔍 آیا Doris سهم ClickHouse را خواهد گرفت؟
با توجه به تجربه‌ی سازمان‌هایی مثل TME و قابلیت‌های جدید Doris، این پایگاه داده در حال تبدیل شدن به گزینه‌ای جدی برای تیم‌هایی‌ست که به استاندارد بودن SQL، ادغام ساده، و عملکرد بالا در مقیاس بزرگ نیاز دارند.
در مقابل، ClickHouse با وجود سرعت بالا، در سناریوهای واقعی با محدودیت‌هایی مثل ضعف در Joinهای پیچیده، ناتوانی در اجرای کوئری بین چند منبع داده مختلف بدون انتقال داده، و انعطاف‌پذیری پایین در تغییر ساختار جداول روبروست. اگر ClickHouse در این زمینه‌ها به‌روزرسانی نشود، ممکن است بخشی از جایگاه خود را در بازار سازمانی از دست بدهد.
منابع :
- https://www.pracdata.io/p/state-of-open-source-read-time-olap-2025
- https://doris.apache.org/blog/migrating-from-clickhouse-to-apache-doris-what-happened
- https://doris.apache.org/blog/Tencent-Data-Engineers-Why-We-Went-from-ClickHouse-to-Apache-Doris
در چند سال اخیر، ClickHouse به یکی از سریع‌ترین و محبوب‌ترین دیتابیس‌های تحلیلی تبدیل شده — و خود من هم یکی از کاربران و طرفداران پر و پا قرص این موتور قدرتمند هستم. 🚀
اما در کاربردهای واقعی، انتخاب دیتابیس تحلیلی فقط به سرعت خلاصه نمی‌شود. عواملی مثل پشتیبانی از داده‌های نیمه‌ساخت‌یافته، Joinهای پیچیده، امکان کار با منابع مختلف داده، انعطاف‌پذیری معماری، و قابلیت‌های نگهداری و توسعه، نقش مهمی در تصمیم نهایی دارند.
📈 در همین راستا، پروژه‌هایی مثل Apache Doris و StarRocks (که از Doris منشعب شده است) در حال رشد و جلب توجه هستند. Doris به‌ویژه با اضافه‌کردن قابلیت‌هایی مثل Inverted Index برای جستجوی سریع‌تر در لاگ‌ها و پشتیبانی بومی از Joinهای چندجدولی، موفق شده نظر بسیاری از تیم‌ها را به خود جلب کند — حتی برخی از تیم‌هایی که قبلاً از Elasticsearch استفاده می‌کردند!
🛠 کلیک‌هوس ذاتاً برای پردازش‌های تک‌جدولی طراحی شده و برای پشتیبانی از کوئری‌های چندجدولی یا Joinهای پیچیده، معمولاً به راهکارهای جانبی مثل Data Virtualization نیاز دارد. این در حالی است که Doris چنین سناریوهایی را به‌صورت بومی و بهینه پشتیبانی می‌کند.
🎧 تجربه واقعی: مهاجرت Tencent Music Entertainment از ClickHouse به Apache Doris
شرکت Tencent Music Entertainment (TME) با بیش از ۸۰۰ میلیون کاربر فعال ماهانه، تصمیم گرفت معماری داده خود را بازطراحی کند. تیم مهندسی داده‌ی این شرکت با مشکلاتی مثل:
⚠️هزینه بالای ذخیره‌سازی در ClickHouse
⚠️عدم پشتیبانی از به‌روزرسانی جزئی (Partial Update)
⚠️پیچیدگی در اجرای کوئری‌های فدره بین ClickHouse و Elasticsearch
روبهرو بود.
🧭 نتیجه؟ مهاجرت به Doris
مزایای به‌دست‌آمده در این مهاجرت استراتژیک:
✅ کاهش ۴۲٪ در هزینه ذخیره‌سازی
✅ کاهش ۴۰٪ در هزینه توسعه
✅ تعریف یک لایه معنایی (Semantic Layer) برای مدیریت یکپارچه KPIها و تگ‌ها
✅ یکپارچگی بیشتر با Kafka و Flink
✅ کاهش تأخیر در دسترسی به داده‌ها
✅ استفاده از Doris Light Schema Change برای تغییرات ساختاری سریع و کم‌هزینه
🔬 مقایسه عملکردی Doris و ClickHouse در تست‌های واقعی:
در یک تست میدانی منتشر شده در وبلاگ دوریس :
📌 در ۱۰ کوئری از ۱۶ کوئری، Doris تا ۳۰ برابر سریع‌تر از ClickHouse بود!
🔹 ۴ میلیارد ردیف (Join کامل و فیلترشده): Doris بین ۲ تا ۵ برابر سریع‌تر بود؛ ClickHouse با مشکلات حافظه مواجه شد.
🔹 ۲۵ میلیارد ردیف: Doris کوئری‌ها را در چند ثانیه اجرا کرد؛ ClickHouse چند دقیقه زمان برد یا حتی در جداول بزرگ (بالای ۵۰ میلیون ردیف) اجرا نشد.
🔹 ۹۶ میلیارد ردیف: Doris به‌راحتی همه کوئری‌ها را اجرا کرد؛ ClickHouse از عهده‌ی این حجم داده برنیامد.
🔍 آیا Doris سهم ClickHouse را خواهد گرفت؟
با توجه به تجربه‌ی سازمان‌هایی مثل TME و قابلیت‌های جدید Doris، این پایگاه داده در حال تبدیل شدن به گزینه‌ای جدی برای تیم‌هایی‌ست که به استاندارد بودن SQL، ادغام ساده، و عملکرد بالا در مقیاس بزرگ نیاز دارند.
در مقابل، ClickHouse با وجود سرعت بالا، در سناریوهای واقعی با محدودیت‌هایی مثل ضعف در Joinهای پیچیده، ناتوانی در اجرای کوئری بین چند منبع داده مختلف بدون انتقال داده، و انعطاف‌پذیری پایین در تغییر ساختار جداول روبروست. اگر ClickHouse در این زمینه‌ها به‌روزرسانی نشود، ممکن است بخشی از جایگاه خود را در بازار سازمانی از دست بدهد.
منابع :
- https://www.pracdata.io/p/state-of-open-source-read-time-olap-2025
- https://doris.apache.org/blog/migrating-from-clickhouse-to-apache-doris-what-happened
- https://doris.apache.org/blog/Tencent-Data-Engineers-Why-We-Went-from-ClickHouse-to-Apache-Doris
👍6👎1
فرمت‌های ستونی نوین Lance: راه‌حلی برای دنیای متن‌باز هوش مصنوعی
در دنیای داده‌های بزرگ ، یکی از گرایش‌های پرطرفدار اخیر، ایجاد زیرساخت‌های ذخیره و پردازش داده به صورت متن‌باز و بدون وابستگی به دیتابیس‌های خاص است. این رویکرد با ذخیره داده‌ها در قالب فایل‌های خام مانند #Parquet و ساختاردهی به این فایل‌ها با استفاده از تکنولوژی‌هایی مثل #ApacheIceberg ، به سرعت در حال گسترش است. مفهوم #LakeHouse و پشتیبانی دیتابیس‌های تحلیلی از این ایده در محصولات تجاری 📊، نشان از پذیرش این روش دارد.
با این حال، باید توجه داشت که فرمت پارکت به طور ویژه برای دسترسی Full Scan طراحی شده است و از پیشرفت‌های اخیر دیسک‌های جدید به‌طور کامل بهره نمی‌برد. همچنین برای ورک‌لودهای هوش مصنوعی 🤖 که نیاز به دسترسی تصادفی دارند، این فرمت چندان بهینه نیست. بنابراین، اگر قصد گسترش این ایده در دنیای هوش مصنوعی را داریم، به نگاه و استانداردهای جدید نیازمندیم.
📄 در مقاله‌ای که اخیراً تیم LanceDB منتشر کرده، فرمت جدیدی به نام Lance معرفی شده که به‌طور خاص برای ورک‌لودهای هوش مصنوعی طراحی شده است. این فرمت در مقایسه با پارکت، عملکرد دسترسی تصادفی را تا ۶۰ برابر سریع‌تر 🚀 ارائه میدهد و به‌ویژه برای تحلیل‌های پیچیده و ذخیره‌سازی داده‌های بزرگ، انتخاب مناسبی به‌نظر می‌رسد. خلاصه مقاله را در ادامه با هم مرور می‌کنیم.
آدرس مقاله : https://arxiv.org/pdf/2504.15247 - آوریل ۲۰۲۵
قالب نوین Lance از LanceDb
فرمت Lance که توسط LanceDB معرفی شده، برای حل مشکلات فرمت‌های سنتی مانند Parquet طراحی شده است. ویژگی‌های برجسته این فرمت عبارتند از:
✅ ساختار انکودینگ متفاوت: Lance با دو نوع انکودینگ، دسترسی تصادفی را سریع‌تر ⚡️ و اسکن کامل را بهینه‌تر 📊 می‌کند.
این انکودینگ‌ها شامل:
🛠 انکودینگ مبتنی بر عرض داده برای دسترسی تصادفی سریع‌تر 🔍
🛠 انکودینگ ساختاری برای داده‌های پیچیده مانند لیست‌ها و بردارها 📚
🛠 بهینه‌سازی برای NVMe: لنس از پهنای باند NVMe به‌طور بهینه استفاده می‌کند و عملکردی تا ۶۰ برابر بهتر از Parquet در دسترسی تصادفی دارد ⚡️.
✅ تعادل بین دسترسی تصادفی و اسکن کامل: برخلاف Parquet که برای اسکن کامل بهینه شده، Lance تعادلی را برای دسترسی سریع به داده‌های خاص و همچنین اسکن کل ستون فراهم می‌کند .
✅ پشتیبانی از ورک‌لودهای هوش مصنوعی: Lance به‌ویژه برای جستجوهای تمام‌متن 📑، جستجوهای برداری 📍 و آموزش مدل‌های یادگیری ماشین بهینه‌سازی شده است 🤖.
نتایج کلیدی:
✅ عملکرد دسترسی تصادفی: تا ۶۰ برابر سریع‌تر از Parquet ⚡️.
✅ مصرف RAM: به‌طور چشمگیری کاهش یافته که برای دیتاست‌های بزرگ 🏋️♂️ مهم است.
✅ مقایسه با NVMe: عملکرد بهینه با استفاده از سخت‌افزار مدرن 💻.
جمع‌بندی:
فرمت Lance یک راه‌حل قدرتمند برای ورک‌لودهای مدرن در حوزه ایجاد ساختارهای ذخیره و بازیابی داده‌ها با فرمت باز و بدون وابستگی به ابزارها و دیتابیس‌ها، به‌ویژه در حوزه هوش مصنوعی است 🤖. با بهینه‌سازی برای دسترسی تصادفی و پشتیبانی از داده‌های پیچیده 🔗، Lance می‌تواند جایگزینی عالی برای Parquet در این حوزه باشد، به‌خصوص در کاربردهایی که سرعت و کارایی اهمیت دارند 🚀.
ایده این نوشتار از این پست لینکدین گرفته شده است : https://www.linkedin.com/posts/dipankar-mazumdar_lakehouse-dataengineering-softwareengineering-activity-7326626194622197761-hrHy/
در دنیای داده‌های بزرگ ، یکی از گرایش‌های پرطرفدار اخیر، ایجاد زیرساخت‌های ذخیره و پردازش داده به صورت متن‌باز و بدون وابستگی به دیتابیس‌های خاص است. این رویکرد با ذخیره داده‌ها در قالب فایل‌های خام مانند #Parquet و ساختاردهی به این فایل‌ها با استفاده از تکنولوژی‌هایی مثل #ApacheIceberg ، به سرعت در حال گسترش است. مفهوم #LakeHouse و پشتیبانی دیتابیس‌های تحلیلی از این ایده در محصولات تجاری 📊، نشان از پذیرش این روش دارد.
با این حال، باید توجه داشت که فرمت پارکت به طور ویژه برای دسترسی Full Scan طراحی شده است و از پیشرفت‌های اخیر دیسک‌های جدید به‌طور کامل بهره نمی‌برد. همچنین برای ورک‌لودهای هوش مصنوعی 🤖 که نیاز به دسترسی تصادفی دارند، این فرمت چندان بهینه نیست. بنابراین، اگر قصد گسترش این ایده در دنیای هوش مصنوعی را داریم، به نگاه و استانداردهای جدید نیازمندیم.
📄 در مقاله‌ای که اخیراً تیم LanceDB منتشر کرده، فرمت جدیدی به نام Lance معرفی شده که به‌طور خاص برای ورک‌لودهای هوش مصنوعی طراحی شده است. این فرمت در مقایسه با پارکت، عملکرد دسترسی تصادفی را تا ۶۰ برابر سریع‌تر 🚀 ارائه میدهد و به‌ویژه برای تحلیل‌های پیچیده و ذخیره‌سازی داده‌های بزرگ، انتخاب مناسبی به‌نظر می‌رسد. خلاصه مقاله را در ادامه با هم مرور می‌کنیم.
آدرس مقاله : https://arxiv.org/pdf/2504.15247 - آوریل ۲۰۲۵
قالب نوین Lance از LanceDb
فرمت Lance که توسط LanceDB معرفی شده، برای حل مشکلات فرمت‌های سنتی مانند Parquet طراحی شده است. ویژگی‌های برجسته این فرمت عبارتند از:
✅ ساختار انکودینگ متفاوت: Lance با دو نوع انکودینگ، دسترسی تصادفی را سریع‌تر ⚡️ و اسکن کامل را بهینه‌تر 📊 می‌کند.
این انکودینگ‌ها شامل:
🛠 انکودینگ مبتنی بر عرض داده برای دسترسی تصادفی سریع‌تر 🔍
🛠 انکودینگ ساختاری برای داده‌های پیچیده مانند لیست‌ها و بردارها 📚
🛠 بهینه‌سازی برای NVMe: لنس از پهنای باند NVMe به‌طور بهینه استفاده می‌کند و عملکردی تا ۶۰ برابر بهتر از Parquet در دسترسی تصادفی دارد ⚡️.
✅ تعادل بین دسترسی تصادفی و اسکن کامل: برخلاف Parquet که برای اسکن کامل بهینه شده، Lance تعادلی را برای دسترسی سریع به داده‌های خاص و همچنین اسکن کل ستون فراهم می‌کند .
✅ پشتیبانی از ورک‌لودهای هوش مصنوعی: Lance به‌ویژه برای جستجوهای تمام‌متن 📑، جستجوهای برداری 📍 و آموزش مدل‌های یادگیری ماشین بهینه‌سازی شده است 🤖.
نتایج کلیدی:
✅ عملکرد دسترسی تصادفی: تا ۶۰ برابر سریع‌تر از Parquet ⚡️.
✅ مصرف RAM: به‌طور چشمگیری کاهش یافته که برای دیتاست‌های بزرگ 🏋️♂️ مهم است.
✅ مقایسه با NVMe: عملکرد بهینه با استفاده از سخت‌افزار مدرن 💻.
جمع‌بندی:
فرمت Lance یک راه‌حل قدرتمند برای ورک‌لودهای مدرن در حوزه ایجاد ساختارهای ذخیره و بازیابی داده‌ها با فرمت باز و بدون وابستگی به ابزارها و دیتابیس‌ها، به‌ویژه در حوزه هوش مصنوعی است 🤖. با بهینه‌سازی برای دسترسی تصادفی و پشتیبانی از داده‌های پیچیده 🔗، Lance می‌تواند جایگزینی عالی برای Parquet در این حوزه باشد، به‌خصوص در کاربردهایی که سرعت و کارایی اهمیت دارند 🚀.
ایده این نوشتار از این پست لینکدین گرفته شده است : https://www.linkedin.com/posts/dipankar-mazumdar_lakehouse-dataengineering-softwareengineering-activity-7326626194622197761-hrHy/
👍3
خرید پروژه‌ی متن‌باز Arroyo توسط Cloudflare 🔥
شرکت Cloudflare به‌تازگی اعلام کرده که پروژه‌ی Arroyo، یکی از نوآورانه‌ترین موتورهای پردازش جریان داده، را به مجموعه‌ی خود افزوده است. این پروژه که در سال ۲۰۲۲ با زبان #Rust 🦀 و توسط دو بنیان‌گذار راه‌اندازی شد، بر تجربه‌ای بی‌نیاز از مدیریت زیرساخت، عملکرد بالا و سادگی در توسعه متمرکز بوده است.
منبع خبر : https://www.arroyo.dev/blog/arroyo-is-joining-cloudflare
🔍 کتابخانه 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 است؛ زبانی که با امنیت بالا و مدیریت حافظه‌ی بسیار دقیق، در حال گشودن مرزهای تازه‌ای در دنیای زیرساخت‌های داده و پردازش بلادرنگ است.
شرکت 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 است؛ زبانی که با امنیت بالا و مدیریت حافظه‌ی بسیار دقیق، در حال گشودن مرزهای تازه‌ای در دنیای زیرساخت‌های داده و پردازش بلادرنگ است.
www.arroyo.dev
Arroyo is joining Cloudflare
Arroyo has been acquired by Cloudflare to bring serverless SQL stream processing to the Cloudflare Developer Platfrorm, integrated with Queues, Workers, and R2. The Arroyo Engine will remain open-source and self-hostable.
آیا دوران دیتابیس‌های خودتولیدشونده رسیده است؟
نگاهی به خرید Neon توسط Databricks و شروع عصر جدید معماری‌های AI-first
چند روز پیش خبری منتشر شد که در ظاهر، فقط یکی دیگر از خریدهای میلیاردی دنیای دیتا بود:
شرکت Databricks شرکت Neon را خرید.
منبع : https://www.databricks.com/blog/databricks-neon
اما پشت این خبر، نشانه‌هایی از یک تحول بنیادی در دنیای پایگاه داده و زیرساخت داده‌ای نهفته است:
🧠 تحول از چت‌بات‌ها به ایجنت‌های زیرساخت‌ساز
در چند سال اخیر، تمرکز اصلی اکوسیستم هوش مصنوعی بر تولید متن، تصویر یا کد بوده؛ اما حالا با رشد ایجنت‌های هوشمند (AI Agents)، با نسل جدیدی از ابزارها روبهرو هستیم:
⛔️ فقط "چه چیزی را تحلیل کنیم؟"
✅ بلکه: "کجا ذخیره کنیم؟ چطور ساختار بدهیم؟ چه دیتابیسی بسازیم؟"
ایجنت‌ها اکنون:
منطق کسب‌وکار را تحلیل می‌کنند،
ساختار داده‌ای را طراحی می‌کنند،
و در کمتر از یک ثانیه، دیتابیسی مبتنی بر PostgreSQL را به‌صورت کامل می‌سازند.
📌 نئون چیست و چرا این‌قدر مهم شد؟
نئون یک سرویس PostgreSQL کاملاً سرورلس، open-source و cloud-native است که با ویژگی‌هایی منحصربه‌فرد به محبوبیت بالایی رسید:
✅ساخت دیتابیس در کمتر از ۱ ثانیه
✅معماری تفکیک‌شده‌ی Storage/Compute
✅پشتیبانی از Branching/Forking برای دیتابیس (مثل Git)
✅مدل پرداخت بر اساس مصرف واقعی (usage-based billing)
✅کاملاً API-first و قابل استفاده در pipelineها و توسط ایجنت‌ها
و نسبت به سرویس محبوب Supabase، زیرساخت جداگانه‌ی Storage/Compute ارائه میدهد که آن را به‌مراتب مقیاس‌پذیرتر و اقتصادی‌تر کرده است
🧠 چرا Databricks این‌قدر به Neon علاقه داشت؟
دیتابریکز فقط به‌دنبال یک پایگاه داده نبود — بلکه دنبال قطعه‌ای گمشده برای زنجیره‌ی AI-first + Open-Source + Cloud-Native خودش بود.
📈 در ۳ سال گذشته، Databricks با خریدهای زیر این مسیر را به‌وضوح ترسیم کرده:
MosaicML (۲۰۲۳) → برای مدل‌های زبانی و آموزش اختصاصی (۱.۳ میلیارد دلار)
Tabular (۲۰۲۴) → برای تقویت آیس‌برگ در تحلیل‌های مدرن (بیش از ۱ میلیارد دلار)
Neon (۲۰۲۵) → لایه‌ی عملیاتی و سبک‌وزن برای پایگاه‌داده (حدود ۱ میلیارد دلار)
🎯 نتیجه؟
یک معماری end-to-end برای AI که در آن:
📌 MosaicML → لایه مدل و آموزش
📌 Tabular → لایه تحلیل و ذخیره‌سازی برداری (Data Lakehouse)
📌 Neon → لایه عملیات و دیتابیس سبک OLTP
و همه چیز open، قابل‌برنامه‌ریزی، و سازگار با ایجنت‌ها
🔭 معماری آینده: Lance، Neon، و دیتابیس‌هایی برای ایجنت‌ها
در این معماری نوین، جایگزینی فرمت‌های قدیمی مانند Parquet با فرمت‌های جدید مانند Lance برای تحلیل و ML کاملاً منطقی‌ست:
نئون - Neon برای داده‌های transaction و تنظیمات سریع ایجنت‌ها
لنس - Lance برای ذخیره و پردازش برداری (embedding، RAG، ML training)
آیس‌برگ - Delta/Iceberg برای versioning و تحلیلی سنگین
🧩 چرا این تغییر اهمیت دارد؟
چون ابزارهای آینده نه‌تنها باید مقیاس‌پذیر و سریع باشند، بلکه باید با هوش مصنوعی هم‌صحبت شوند، ساختار بگیرند و بازطراحی شوند.
معماری‌های آینده باید:
📌 مبتنی بر اصل API-first باشند
📌 برای تعامل با ایجنت‌ها طراحی شده باشند
📌 بر پایه‌ی open formats بنا شده باشند
📌 از مصرف‌کننده به معمار تغییر نقش داده شوند
برای مطالعه بیشتر :
https://www.linkedin.com/pulse/databricks-neon-deal-final-piece-ai-driven-enterprise-dmitriy-gerzon-orwic/
https://www-cnbc-com.cdn.ampproject.org/c/s/www.cnbc.com/amp/2025/05/14/databricks-is-buying-database-startup-neon-for-about-1-billion.html
https://www.linkedin.com/feed/update/urn:li:activity:7328542430599811072/
نگاهی به خرید Neon توسط Databricks و شروع عصر جدید معماری‌های AI-first
چند روز پیش خبری منتشر شد که در ظاهر، فقط یکی دیگر از خریدهای میلیاردی دنیای دیتا بود:
شرکت Databricks شرکت Neon را خرید.
منبع : https://www.databricks.com/blog/databricks-neon
اما پشت این خبر، نشانه‌هایی از یک تحول بنیادی در دنیای پایگاه داده و زیرساخت داده‌ای نهفته است:
بیش از ۸۰٪ از دیتابیس‌های ساخته‌شده در Neon توسط ایجنت‌های AI ساخته شده‌اند، نه انسان‌ها!
🧠 تحول از چت‌بات‌ها به ایجنت‌های زیرساخت‌ساز
در چند سال اخیر، تمرکز اصلی اکوسیستم هوش مصنوعی بر تولید متن، تصویر یا کد بوده؛ اما حالا با رشد ایجنت‌های هوشمند (AI Agents)، با نسل جدیدی از ابزارها روبهرو هستیم:
⛔️ فقط "چه چیزی را تحلیل کنیم؟"
✅ بلکه: "کجا ذخیره کنیم؟ چطور ساختار بدهیم؟ چه دیتابیسی بسازیم؟"
ایجنت‌ها اکنون:
منطق کسب‌وکار را تحلیل می‌کنند،
ساختار داده‌ای را طراحی می‌کنند،
و در کمتر از یک ثانیه، دیتابیسی مبتنی بر PostgreSQL را به‌صورت کامل می‌سازند.
📌 نئون چیست و چرا این‌قدر مهم شد؟
نئون یک سرویس PostgreSQL کاملاً سرورلس، open-source و cloud-native است که با ویژگی‌هایی منحصربه‌فرد به محبوبیت بالایی رسید:
✅ساخت دیتابیس در کمتر از ۱ ثانیه
✅معماری تفکیک‌شده‌ی Storage/Compute
✅پشتیبانی از Branching/Forking برای دیتابیس (مثل Git)
✅مدل پرداخت بر اساس مصرف واقعی (usage-based billing)
✅کاملاً API-first و قابل استفاده در pipelineها و توسط ایجنت‌ها
و نسبت به سرویس محبوب Supabase، زیرساخت جداگانه‌ی Storage/Compute ارائه میدهد که آن را به‌مراتب مقیاس‌پذیرتر و اقتصادی‌تر کرده است
🧠 چرا Databricks این‌قدر به Neon علاقه داشت؟
دیتابریکز فقط به‌دنبال یک پایگاه داده نبود — بلکه دنبال قطعه‌ای گمشده برای زنجیره‌ی AI-first + Open-Source + Cloud-Native خودش بود.
📈 در ۳ سال گذشته، Databricks با خریدهای زیر این مسیر را به‌وضوح ترسیم کرده:
MosaicML (۲۰۲۳) → برای مدل‌های زبانی و آموزش اختصاصی (۱.۳ میلیارد دلار)
Tabular (۲۰۲۴) → برای تقویت آیس‌برگ در تحلیل‌های مدرن (بیش از ۱ میلیارد دلار)
Neon (۲۰۲۵) → لایه‌ی عملیاتی و سبک‌وزن برای پایگاه‌داده (حدود ۱ میلیارد دلار)
🎯 نتیجه؟
یک معماری end-to-end برای AI که در آن:
📌 MosaicML → لایه مدل و آموزش
📌 Tabular → لایه تحلیل و ذخیره‌سازی برداری (Data Lakehouse)
📌 Neon → لایه عملیات و دیتابیس سبک OLTP
و همه چیز open، قابل‌برنامه‌ریزی، و سازگار با ایجنت‌ها
🔭 معماری آینده: Lance، Neon، و دیتابیس‌هایی برای ایجنت‌ها
در این معماری نوین، جایگزینی فرمت‌های قدیمی مانند Parquet با فرمت‌های جدید مانند Lance برای تحلیل و ML کاملاً منطقی‌ست:
نئون - Neon برای داده‌های transaction و تنظیمات سریع ایجنت‌ها
لنس - Lance برای ذخیره و پردازش برداری (embedding، RAG، ML training)
آیس‌برگ - Delta/Iceberg برای versioning و تحلیلی سنگین
🧩 چرا این تغییر اهمیت دارد؟
چون ابزارهای آینده نه‌تنها باید مقیاس‌پذیر و سریع باشند، بلکه باید با هوش مصنوعی هم‌صحبت شوند، ساختار بگیرند و بازطراحی شوند.
معماری‌های آینده باید:
📌 مبتنی بر اصل API-first باشند
📌 برای تعامل با ایجنت‌ها طراحی شده باشند
📌 بر پایه‌ی open formats بنا شده باشند
📌 از مصرف‌کننده به معمار تغییر نقش داده شوند
برای مطالعه بیشتر :
https://www.linkedin.com/pulse/databricks-neon-deal-final-piece-ai-driven-enterprise-dmitriy-gerzon-orwic/
https://www-cnbc-com.cdn.ampproject.org/c/s/www.cnbc.com/amp/2025/05/14/databricks-is-buying-database-startup-neon-for-about-1-billion.html
https://www.linkedin.com/feed/update/urn:li:activity:7328542430599811072/
👍5
با توجه به رواج و محبوبیت کافکا در میان اکثر سیستم‌های اطلاعاتی نوین و ضرورت آشنایی عمیق‌تر با این سامانه توزیع پیام قدرتمند، تصمیم به ترجمه مقاله If you’re learning Kafka, this article is for you گرفتیم و تمامی عکس ها هم از این مقاله برگرفته شده است.
آدرس مقاله :
https://vutr.substack.com/p/if-youre-learning-kafka-this-article
ترجمه آن در وب سایت مهندسی داده :
https://www.bigdata.ir/1404/02/%d9%86%da%af%d8%a7%d9%87%db%8c-%d8%a7%d8%b2-%d9%86%d8%b2%d8%af%db%8c%da%a9-%d8%a8%d9%87-%da%a9%d8%a7%d9%81%da%a9%d8%a7/
آدرس مقاله :
https://vutr.substack.com/p/if-youre-learning-kafka-this-article
ترجمه آن در وب سایت مهندسی داده :
https://www.bigdata.ir/1404/02/%d9%86%da%af%d8%a7%d9%87%db%8c-%d8%a7%d8%b2-%d9%86%d8%b2%d8%af%db%8c%da%a9-%d8%a8%d9%87-%da%a9%d8%a7%d9%81%da%a9%d8%a7/
👍4
مهندسی داده
با توجه به رواج و محبوبیت کافکا در میان اکثر سیستم‌های اطلاعاتی نوین و ضرورت آشنایی عمیق‌تر با این سامانه توزیع پیام قدرتمند، تصمیم به ترجمه مقاله If you’re learning Kafka, this article is for you گرفتیم و تمامی عکس ها هم از این مقاله برگرفته شده است. آدرس…
Kafka Deep Dive.pdf
3.6 MB
خلاصه مقاله فوق با تمامی شکل های استفاده شده در مقاله که مفاهیم اصلی کافکا و نحوه کارکرد داخلی آنرا توضیح میدهد.
👍2👏1
پروژه آموزشی : ساخت یک سامانه پردازش جریان به کمک ردپاندا، کلیک‌هوس و سوپرست
اخیرا پستی از یکی از دوستان در لینکدین مشاهده کردم که وظیفه خود دانستم آنرا برای علاقه مندان به انجام پروژه های عملی و کاربردی در دنیای مهندسی داده به اشتراک بگذارم.
آدرس پست اصلی : 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
برای سایه عزیز آرزوی موفقیت در آغاز یک دوره نوین تخصصی در دنیای مهندسی داده دارم. مطمئنم این پروژه تنها نقطه‌ی شروع برای دستاوردهای بزرگ‌تر و تأثیرگذارتر در آینده‌ی حرفه‌ای او خواهد بود. 🌟
پ.ن:
سایر دوستان هم اگر پروژه هایی مشابه با این را انجام داده اند که بار آموزشی برای علاقه مندان به مهندسی داده دارد، ممنون میشوم آنرا برای ادمین کانال ارسال کنید تا با سایر علاقه مندان به این حوزه هم به اشتراک گذاشته شود.
اخیرا پستی از یکی از دوستان در لینکدین مشاهده کردم که وظیفه خود دانستم آنرا برای علاقه مندان به انجام پروژه های عملی و کاربردی در دنیای مهندسی داده به اشتراک بگذارم.
آدرس پست اصلی : 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
برای سایه عزیز آرزوی موفقیت در آغاز یک دوره نوین تخصصی در دنیای مهندسی داده دارم. مطمئنم این پروژه تنها نقطه‌ی شروع برای دستاوردهای بزرگ‌تر و تأثیرگذارتر در آینده‌ی حرفه‌ای او خواهد بود. 🌟
پ.ن:
سایر دوستان هم اگر پروژه هایی مشابه با این را انجام داده اند که بار آموزشی برای علاقه مندان به مهندسی داده دارد، ممنون میشوم آنرا برای ادمین کانال ارسال کنید تا با سایر علاقه مندان به این حوزه هم به اشتراک گذاشته شود.
👍4
وقتی پای ۵۰۰هزار سیگنال در ثانیه وسط است ⚡️: انتخاب پایگاه داده برای داده‌های سری زمانی
چند روز پیش یکی از دوستان که روی پروژه‌های #SCADA در صنایع زیرساختی کار می‌کند، سوال جالبی مطرح کرد که باعث شد بشینم و یه بررسی دقیق‌تر انجام بدم و نتیجه را با شما هم به اشتراک بذارم 👇
سری زمانی یعنی چی؟ 🕒
داده‌های #TimeSeries معمولاً از سنسورها یا لاگ سیستم‌ها میان و بر اساس زمان مرتب می‌شن. ذخیره و تحلیل این داده‌ها با پایگاه‌داده‌های سنتی خیلی وقتا سخت یا ناکارآمده.
چالش مهم: کاردینالیتی بالا 🧠
در دیتابیس‌های سری زمانی، ستون‌هایی مثل Tag یا Label ممکنه میلیون‌ها مقدار یکتا داشته باشن (High Cardinality). مثلاً هر سنسور یا دستگاه یه شناسه خاص داره. دیتابیس‌هایی مثل #InfluxDB یا #Prometheus در این شرایط دچار مشکل می‌شن، چون ایندکس‌گذاری معکوس (Inverted Index) براشون گرونه.
بررسی گزینه‌های جدی برای ذخیره و تحلیل داده‌های سری زمانی 🧪
✅ دیتابیس TimescaleDB
بر پایه‌ی PostgreSQL، آشنا برای خیلی از تیم‌ها، ولی مقیاس‌پذیری افقی محدود داره.
✅ دیتابیس InfluxDB
معروف‌ترین دیتابیس سری زمانی، ولی در حجم و کاردینالیتی بالا ممکنه کم بیاره.
🔹 زبان اختصاصی Flux، نسخه Cloud و OSS
✅ دیتابیس QuestDB
سریع و سبک، با پشتیبانی از SQL و تحلیل‌های ساده Real-time.
🔹 مناسب پروژه‌های سبک تا متوسط
دیتابیس جدید 🚀 Apache HoraeDB
طراحی شده با زبان Rust برای کار با داده‌های سری زمانی با کاردینالیتی بالا.
از تکنیک scan+prune به جای inverted index استفاده می‌کنه.
🔹 سازگار با سیستم های ابری / Cloud-native و مقیاس‌پذیر
🔹 هنوز incubating ولی بسیار جذاب
🔹 معماری Zero-Disk و جداسازی بخش محاسبات و پردازش از بخش ذخیره سازی
گزینه‌های عمومی ولی قدرتمند برای تحلیل داده در مقیاس بالا 🔍
⚡️ دیتابیس ClickHouse
تحلیل سریع و فوق‌العاده روی داده‌های ستونی. اگر تحلیل پیچیده Real-time می‌خواید، عالیه.
🔹 مقیاس‌پذیر افقی
🔹 پشتیبانی از توابع Aggregation
🌀 دیتابیس ScyllaDB / Cassandra
طراحی‌شده برای نوشتن سریع با تأخیر کم.
اگر مدل داده‌ی خوبی طراحی کنید، خیلی خوب جواب می‌ده.
🔹 دیتابیس ScyllaDB سریع‌تر از Cassandra و با مصرف منابع کمتر
✳️ جمع‌بندی برای شرایط صنعتی با داده‌های حجیم:
اگر با سناریوهایی مثل ۵۰۰k در ثانیه، نیاز به واکشی سریع و تحلیل Real-time سروکار دارید، این سه گزینه بیشترین تطابق رو دارن:
🔹 Apache HoraeDB – طراحی‌شده برای مقیاس بالا + کاردینالیتی بالا
🔹 ClickHouse – برای تحلیل بلادرنگ در مقیاس بزرگ
🔹 ScyllaDB – اگر اولویت با نوشتن با نرخ بالا و توزیع‌پذیریه
🤝 دعوت به گفتگو
آیا تجربه‌ای در انتخاب یا مهاجرت از پایگاه‌داده‌های سنتی به TimeSeries DB داشتید؟
کدوم ابزار براتون بهتر جواب داده؟ چه چالش‌هایی داشتید؟👂 شاید این بحث به انتخاب بهتر برای پروژه‌های بعدی همه ما کمک کنه. نظراتتون را در بخش کامنت این پست می توانید با سایر دوستان به اشتراک بگذارید.
#SCADA #TimeSeriesDatabase #HoraeDB #ClickHouse #ScyllaDB #InfluxDB #QuestDB #DataEngineering #IoT #HighCardinality #RustLang
چند روز پیش یکی از دوستان که روی پروژه‌های #SCADA در صنایع زیرساختی کار می‌کند، سوال جالبی مطرح کرد که باعث شد بشینم و یه بررسی دقیق‌تر انجام بدم و نتیجه را با شما هم به اشتراک بذارم 👇
«ما داده‌های سری زمانی داریم و فعلاً در پایگاه‌داده #Oracle ذخیره می‌شن. ولی در پروژه‌های جدید ممکنه نرخ داده به ۵۰۰ هزار سیگنال در ثانیه برسه. دنبال دیتابیسی هستیم که بتونه این حجم رو مدیریت کنه، تحلیل Real-time بده، و قابلیت‌هایی مثل میانگین‌گیری، Sampling، و Backfill رو پشتیبانی کنه.»
سری زمانی یعنی چی؟ 🕒
داده‌های #TimeSeries معمولاً از سنسورها یا لاگ سیستم‌ها میان و بر اساس زمان مرتب می‌شن. ذخیره و تحلیل این داده‌ها با پایگاه‌داده‌های سنتی خیلی وقتا سخت یا ناکارآمده.
چالش مهم: کاردینالیتی بالا 🧠
در دیتابیس‌های سری زمانی، ستون‌هایی مثل Tag یا Label ممکنه میلیون‌ها مقدار یکتا داشته باشن (High Cardinality). مثلاً هر سنسور یا دستگاه یه شناسه خاص داره. دیتابیس‌هایی مثل #InfluxDB یا #Prometheus در این شرایط دچار مشکل می‌شن، چون ایندکس‌گذاری معکوس (Inverted Index) براشون گرونه.
بررسی گزینه‌های جدی برای ذخیره و تحلیل داده‌های سری زمانی 🧪
✅ دیتابیس TimescaleDB
بر پایه‌ی PostgreSQL، آشنا برای خیلی از تیم‌ها، ولی مقیاس‌پذیری افقی محدود داره.
✅ دیتابیس InfluxDB
معروف‌ترین دیتابیس سری زمانی، ولی در حجم و کاردینالیتی بالا ممکنه کم بیاره.
🔹 زبان اختصاصی Flux، نسخه Cloud و OSS
✅ دیتابیس QuestDB
سریع و سبک، با پشتیبانی از SQL و تحلیل‌های ساده Real-time.
🔹 مناسب پروژه‌های سبک تا متوسط
دیتابیس جدید 🚀 Apache HoraeDB
طراحی شده با زبان Rust برای کار با داده‌های سری زمانی با کاردینالیتی بالا.
از تکنیک scan+prune به جای inverted index استفاده می‌کنه.
🔹 سازگار با سیستم های ابری / Cloud-native و مقیاس‌پذیر
🔹 هنوز incubating ولی بسیار جذاب
🔹 معماری Zero-Disk و جداسازی بخش محاسبات و پردازش از بخش ذخیره سازی
گزینه‌های عمومی ولی قدرتمند برای تحلیل داده در مقیاس بالا 🔍
⚡️ دیتابیس ClickHouse
تحلیل سریع و فوق‌العاده روی داده‌های ستونی. اگر تحلیل پیچیده Real-time می‌خواید، عالیه.
🔹 مقیاس‌پذیر افقی
🔹 پشتیبانی از توابع Aggregation
🌀 دیتابیس ScyllaDB / Cassandra
طراحی‌شده برای نوشتن سریع با تأخیر کم.
اگر مدل داده‌ی خوبی طراحی کنید، خیلی خوب جواب می‌ده.
🔹 دیتابیس ScyllaDB سریع‌تر از Cassandra و با مصرف منابع کمتر
✳️ جمع‌بندی برای شرایط صنعتی با داده‌های حجیم:
اگر با سناریوهایی مثل ۵۰۰k در ثانیه، نیاز به واکشی سریع و تحلیل Real-time سروکار دارید، این سه گزینه بیشترین تطابق رو دارن:
🔹 Apache HoraeDB – طراحی‌شده برای مقیاس بالا + کاردینالیتی بالا
🔹 ClickHouse – برای تحلیل بلادرنگ در مقیاس بزرگ
🔹 ScyllaDB – اگر اولویت با نوشتن با نرخ بالا و توزیع‌پذیریه
🤝 دعوت به گفتگو
آیا تجربه‌ای در انتخاب یا مهاجرت از پایگاه‌داده‌های سنتی به TimeSeries DB داشتید؟
کدوم ابزار براتون بهتر جواب داده؟ چه چالش‌هایی داشتید؟👂 شاید این بحث به انتخاب بهتر برای پروژه‌های بعدی همه ما کمک کنه. نظراتتون را در بخش کامنت این پست می توانید با سایر دوستان به اشتراک بگذارید.
#SCADA #TimeSeriesDatabase #HoraeDB #ClickHouse #ScyllaDB #InfluxDB #QuestDB #DataEngineering #IoT #HighCardinality #RustLang
👍2👏1