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

ویژگی‌های فنی پروژه:
✅ استفاده از Quix Streams در پایتون برای پردازش جریان داده‌ها

✅ بهره‌گیری از Redpanda (سازگار با Kafka) برای انتقال داده با کارایی بالا

✅ استفاده از Docker جهت کانتینرسازی و اجرای ماژولار

✅ محاسبه تحلیل‌های بلادرنگ مانند میانگین متحرک

✅ دریافت زنده قیمت رمزارزها از API سرویس CoinLore

✅ معماری مقاوم در برابر خطا با قابلیت بازیابی خودکار

✅ طراحی ماژولار و آماده برای توسعه‌هایی نظیر هشدارهای معاملاتی و داشبوردهای بصری

دسترسی به مخزن پروژه:
github.com/ArefFarzaneh/crypto_data_pipeline
این پروژه می‌تواند مرجع مناسبی برای علاقه‌مندان به شروع پردازش داده‌های بلادرنگ، تحلیل بازار رمزارزها، و توسعه سیستم‌های معاملاتی باشد.

‍ کلیک‌هوس عالیه... ولی همیشه بهترین انتخاب نیست!🌟

در چند سال اخیر، 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

‍ فرمت‌های ستونی نوین 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/

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

‍ آیا دوران دیتابیس‌های خودتولیدشونده رسیده است؟

نگاهی به خرید 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/

با توجه به رواج و محبوبیت کافکا در میان اکثر سیستم‌های اطلاعاتی نوین و ضرورت آشنایی عمیق‌تر با این سامانه توزیع پیام قدرتمند، تصمیم به ترجمه مقاله 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://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

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

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

‍ وقتی پای ۵۰۰هزار سیگنال در ثانیه وسط است ⚡️: انتخاب پایگاه داده برای داده‌های سری زمانی

چند روز پیش یکی از دوستان که روی پروژه‌های #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

‍ مهندسین یا راهی خواهند یافت یا راهی خواهند ساخت — نمونه‌ای واقعی به نام GlassFlow 👷‍♂️

می‌گویند مهندسین یا راهی خواهند یافت یا راهی خواهند ساخت. پروژه GlassFlow دقیقاً مصداق همین جمله است. وقتی با محدودیت‌هایی در ابزارهایی مثل ClickHouse مواجه می‌شویم — ابزارهایی که با تمام قدرت و کارایی‌شان، در معماری و عملکردشان ضعف‌هایی دارند — بعضی از ما به‌جای منتظر ماندن، خودمان دست به کار می‌شویم و راه‌حل می‌سازیم.

✨ گلس‌فلو یکی از همین راه‌حل‌های هوشمندانه است؛ یک ابزار ساده، سبک و تخصصی برای برطرف کردن مشکلات رایج در مسیر داده از Kafka به ClickHouse.


🚨 مشکل از کجا شروع می‌شود؟
کلیک‌هوس یکی از سریع‌ترین پایگاه‌های داده ستونی در دنیاست، اما در دنیای real-time و Kafka ضعف‌هایی دارد (هر چند در نسخه های اخیر خود سعی کرده است که مشکل داده های تکراری در کافکا را با ذخیره آفست آخرین داده درج شده از هر تاپیک کافکا، به نحوی حل کند - البته باید این قابلیت را فعال کنید):


🔁 کافکا بدون deduplication است
→ حذف داده‌های تکراری در Kafka نیاز به کانکتورهای سفارشی و مدیریت state دارد، که پیچیده و شکننده‌اند.
🐢 عملیات FINAL در ClickHouse کند و پرهزینه است
→ اجرای FINAL برای پاک‌سازی داده‌ها منابع زیادی مصرف می‌کند و برای real-time قابل اتکا نیست.
⛔️ کلیک‌هوس برای Joinهای زنده طراحی نشده
→ داده‌های دیررس پشتیبانی نمی‌شوند و اجرای join بهینه نیست.
🧱 فلینک یا Kafka Streams معماری سنگینی دارند
→ پیاده‌سازی و نگهداری آن‌ها زمان‌بر است و نیاز به تیم فنی پیشرفته دارد، مخصوصاً وقتی بخواهیم به ClickHouse متصل شویم.


✅ گلس‌فلو چه راهی ساخته است؟
گلس‌فلو دقیقاً برای این محدودیت‌ها ساخته شده و با راهکارهای ساده ولی عمیق، همه‌ی این چالش‌ها را حل کرده:
🔑 انجام Deduplication با یک کلیک!
→ فقط کلیدهای اولیه را مشخص کنید و GlassFlow به‌صورت خودکار داده‌های تکراری را در بازه ۷ روزه تشخیص داده و حذف می‌کند.
🔗 انجام Joinهای ساده‌شده
→ فقط فیلدهای لازم را مشخص کنید. GlassFlow تمام logic و state را خودش مدیریت می‌کند.
🕓 ورود داده زمان‌محور، اندازه‌محور یا خودکار
→ ingestion بر اساس زمان یا حجم انجام می‌شود؛ کاملاً قابل تنظیم.
🔌 کانکتور Kafka و ClickHouse مدیریت‌شده
→ توسط تیم GlassFlow توسعه داده شده و نیازی به تنظیمات خاص یا نگهداری ندارد.
📈 مقیاس‌پذیری خودکار با افزایش پارتیشن‌ها
→ هرجا نیاز باشد، Workerهای جدید فعال می‌شوند.
🧠 پردازش حالت‌مند (Stateful) با حافظه کم
→ ذخیره و پردازش سریع در حافظه داخلی، بدون نیاز به معماری پیچیده.
🚀 اجرای سبک، معماری serverless
→ بدون Flink یا Kafka Streams هم می‌توانید جریان‌های پرحجم را دقیق و بدون دردسر پردازش کنید.


❤️ چرا باید GlassFlow را جدی گرفت؟
اگر با ClickHouse و Kafka کار می‌کنید، GlassFlow ابزاری است که:
✔️ داده‌ها را قبل از ورود، پاک‌سازی و join می‌کند
✔️ بار روی ClickHouse را کم می‌کند
✔️ نیاز به FINAL و JOINهای گران را حذف می‌کند
✔️ معماری شما را ساده و مقیاس‌پذیر نگه می‌دارد
✔️ و مهم‌تر از همه، در کمترین زمان قابل راه‌اندازی است 🧰⚡️

با Glassflow داده‌ای که وارد ClickHouse می‌شود، از قبل join و deduplicate شده، یعنی ClickHouse شما سبک‌تر، سریع‌تر و دقیق‌تر خواهد بود — بدون نیاز به ترفندهای پیچیده یا عملیات هزینه‌بر داخل پایگاه داده.

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

glassflow.dev

‍ وقت آن رسیده که از JSON استاندارد یک گام جلوتر برویم!

اگر تاکنون هنگام نوشتن فایل‌های پیکربندی، با محدودیت‌هایی مثل ممنوعیت کامنت، اجبار به دابل‌کوتیشن یا خطاهای ناشی از کاماهای انتهایی مواجه شده‌اید، شاید زمان آن رسیده باشد که با JSON5 آشنا شوید — نسخه‌ای توسعه‌یافته و انسان‌محور از JSON که برای خوانایی و راحتی توسعه‌دهنده طراحی شده است.

🛠 جی‌سان ۵ - JSON5 چه چیزهایی را ممکن می‌کند؟

✅ پشتیبانی از کامنت‌ها

✅ کلیدهای بدون کوتیشن

✅ رشته‌های تکی (Single-quoted strings)

✅ کاماهای پایانی مجاز (Trailing commas)

✅ پشتیبانی از رشته‌های چندخطی

✅ عددهای هگزادسیمال (Hex)

✅ مقادیر ویژه مثل NaN, Infinity, -Infinity, و +Infinity

✅ عدد با علامت مثبت (مثل +42)

✅ فضای بیشتر برای نوشتن تنظیمات قابل‌فهم برای انسان‌ها


🎯 مناسب برای: فایل‌های تنظیمات پروژه، محیط‌های توسعه، ابزارهای داخلی، و هرجا که خوانایی و سادگی اولویت دارد.

🚫 نه‌چندان مناسب برای: تبادل داده با APIها یا ارتباط میان‌سیستمی — جایی که JSON استاندارد با پشتیبانی وسیع، انتخاب امن‌تری است.

👨‍💻 مقاله پیشنهادی برای مطالعه:

“JSON vs. JSON5: More flexible and human-readable configuration files”

✍🏻 نوشته‌ی Tihomir Manushev

📎 https://freedium.cfd/https://medium.com/@tihomir.manushev/json-vs-json5-7753f5060c90

#JSON #JSON5 #ConfigFiles #DeveloperExperience #DX #SoftwareEngineering #WebDev #CleanCode