خرید پروژه‌ی متن‌باز 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

‍ چرا UUID7 و ULID گزینه‌های بهتری برای کلیدهای اصلی در پایگاه داده هستند؟
در طراحی پایگاه‌های داده، انتخاب نوع شناسه (ID) یکی از تصمیم‌های کلیدی است که می‌تواند تأثیر زیادی بر عملکرد، مقیاس‌پذیری و امنیت سیستم داشته باشد.
در سناریوهایی مثل سیستم‌های توزیع‌شده، APIهای پرترافیک یا صفحات محصول در وب‌سایت‌ها که نیاز به درج سریع داده و جلوگیری از افشای الگوی رکوردها وجود دارد، استفاده از کلیدهای auto-increment معمولاً گزینه مناسبی نیست. چون:
⛔️باعث قفل شدن جدول در شرایط همزمانی بالا می‌شود،
⛔️امکان حدس زدن تعداد یا ترتیب رکوردها را فراهم می‌کند.

💡 راه‌حل سنتی چیست؟
استفاده از UUID (نسخه ۴) به‌عنوان کلید اصلی مزایای خوبی دارد: یکتایی جهانی بدون نیاز به هماهنگی بین سرورها، مناسب برای محیط‌های توزیع‌شده، و جلوگیری از افشای الگوهای داده. اما یک مشکل جدی دارد.
🔍 چرا UUID تصادفی (مثلاً UUIDv4) در دیتابیس‌ها عملکرد خوبی ندارد؟
اکثر پایگاه‌های داده رابطه‌ای مانند PostgreSQL، MySQL و SQL Server برای ایندکس‌گذاری — مخصوصاً روی کلید اصلی — از ساختاری به‌نام B-Tree (Balanced Tree) استفاده می‌کنند.
این ساختار کمک می‌کند:
✳️جستجوی کلیدها با پیچیدگی O(log n) انجام شود (سریع و مقیاس‌پذیر)،
✳️داده‌ها به‌صورت مرتب نگه داشته شوند،
✳️ و درج، حذف یا به‌روزرسانی به‌شکل کارآمد مدیریت شود.
اما مشکل از جایی شروع می‌شود که کلیدهایی با ترتیب تصادفی (مثل UUIDv4) در جدول وارد می‌شوند.

📉 چه اتفاقی می‌افتد؟
وقتی داده‌های زیادی با کلید تصادفی وارد جدول می‌شوند:
⛔️ دیتابیس نمی‌تواند آن‌ها را در انتهای ساختار درختی اضافه کند (مثل auto-increment IDs)،
⛔️ باید آن‌ها را بین صفحات مختلف B-Tree پراکنده کند،
⛔️ این پراکندگی باعث عملیات مکرر Page Split (شکستن صفحات)، جابه‌جایی نودها و بازچینش ساختار درختی می‌شود.

🧨 نتیجه؟
🧱کند شدن محسوس عملیات درج (INSERT)،
🧱 مصرف بالای I/O و حافظه،
🧱 کاهش عملکرد کلی سیستم در سناریوهای پرترافیک.

✅ راه‌حل‌های مدرن: UUID7 و ULID
برای رفع این مشکلات، دو استاندارد جدید معرفی شده‌اند:
🔹 استاندارد ULID (Lexicographically sortable): ترکیبی از timestamp و داده تصادفی
🔹 استاندارد UUIDv7: نسخه‌ای از UUID با ترتیب زمانی، سازگار با استاندارد UUID

مزیت اصلی این دو چیست؟
🔸 با حفظ یکتایی و امنیت، کلیدها به‌صورت ترتیبی در ایندکس درج می‌شوند.
🔸 این یعنی:
✅کاهش شدید Page Split و پراکندگی
✅بهبود درج‌های پرترافیک
✅جست‌وجوی سریع‌تر بر اساس بازه‌های زمانی

📊 چه زمانی از هرکدام استفاده کنیم؟
اگر خوانایی و طول کوتاه‌تر مهم است → ULID
اگر سازگاری با UUID استاندارد اهمیت دارد → UUIDv7

📐 قالب ULID
قالب ULID یک رشته ۲۶ نویسه‌ای است که با Crockford’s Base32 کدگذاری می‌شود (حروف I, L, O, U حذف شده‌اند تا اشتباه نشوند).
→ طول: ۲۶ نویسه - کاراکترهای ابتدایی مهرزمان هستند.
→ مثال: 01AN4Z07BY79KA1307SR9X4MV3

📐 قالب UUIDv7
→ نمایش به‌صورت استاندارد UUID در مبنای ۱۶ (hex) با خط تیره
→ طول شامل خط تیره: ۳۶ نویسه - کاراکترهای ابتدایی مهرزمان هستند.
→ قالب: 8-4-4-4-12
→ مثال: 017f45e0-7e1a-7a3f-8bbc-4dbf7e6d9c3a
→ طول بدون خط تیره: ۳۲ نویسه hex

بنابراین UUID7 طول بیشتری نسبت به ULID دارد اما چون با استاندارد UUID سازگاراست، برای سیستم‌های موجود گزینه بهتری است.

#Database #Backend #DistributedSystems #UUID #ULID #PostgreSQL #SystemDesign #Performance #مهندسی_داده

شرکت DoorDash چگونه پلتفرم پردازش بلادرنگ خود را با Iceberg متحول کرد؟

شرکت DoorDash برای پردازش رویدادهای بلادرنگ خودش، یک پلتفرم استریم داخلی توسعه داده که امکان تصمیم‌گیری سریع و هوشمند را برای تیم‌های تجاری فراهم می‌کند.
در ساعات اوج فعالیت، این پلتفرم با حجم بالایی از داده روبه‌رو می‌شود — بیش از ۳۰ میلیون پیام در هر ثانیه، معادل حدود ۵ گیگابایت داده در ثانیه که از سمت مشتریان، رانندگان (Dashers)، فروشندگان و اپلیکیشن‌های داخلی DoorDash ارسال می‌شود.

ساختار اولیه به این صورت بود:
🧱دریافت و بافر داده‌ها با Kafka
🧱پردازش با Apache Flink
🧱ذخیره در Amazon S3
🧱 در نهایت، انتقال داده‌ها به Snowflake از طریق یک پایپ‌لاین به نام Snowpie

اما این معماری در عمل با چند مشکل جدی مواجه شد:
⛔️هزینه‌های بالای Snowflake
⛔️دوبار نوشتن داده‌ها (هم در S3 و هم در Snowflake)
⛔️وابستگی به یک فروشنده خاص ( Snowflake)

برای حل این چالش‌ها، DoorDash تصمیم گرفت به سراغ Apache Iceberg برود تا زیرساخت داده‌ای بلادرنگ خود را بازطراحی کند؛ راه‌حلی متن‌باز، مقیاس‌پذیر و مستقل از فروشنده.
خلاصه آنرا در PDF الصاق شده مشاهده کنید👆

‍ اوج بلوغ تیم‌های مهندسی داده: محیط Staging و چک‌لیست تغییرات دیتابیس 🔴

وقتی یه دستور ساده می‌تونه کل سیستم رو بخوابونه!

چند روز پیش یکی از دوستان تماس گرفت و گفت روی یک جدول بزرگ در ClickHouse دستور OPTIMIZE FINAL زده. جدول مربوط به دیتای اصلی سیستمشون بوده و چند میلیارد رکورد داشته. نتیجه؟ تمام CPUها پر شدن، کوئری‌های عادی از کار افتادن و سیستم عملاً فلج شده. 🧨

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

🧑‍💻 ما باید عادت کنیم مثل مهندسان نرم‌افزار، محیط‌های جدا برای تست و اجرا داشته باشیم.

🚫 داده‌های حساس و عملیاتی هیچ‌وقت نباید محل آزمایش باشن.


اینا چند تا نکته‌ کلیدی هستن که هر مهندس داده باید رعایت کنه:

🔹 محیط staging جداگانه داشته باشیم که شبیه production باشه (نه لزوماً با همون حجم دیتا)

🔹 دیتا رو نمونه‌گیری (sample) کنیم و روی کپی‌ها تست کنیم، نه روی دیتای اصلی

🔹 دستورات سنگین مثل OPTIMIZE, VACUUM, یا REINDEX رو اول روی محیط تست اجرا کنیم

🔹 حتماً از ابزارهای مانیتورینگ، لاگ‌گیری و EXPLAIN استفاده کنیم قبل از اجرای کوئری‌های پرهزینه 📊



✨ جادوی چک‌لیست 📝

قبل از اجرای هر عملیات دیتابیسی سنگین، باید یه چک‌لیست ساده ولی جدی داشته باشیم:

✅ تست انجام شده؟

✅ دیتای درگیر چقدره؟

✅ منابع مورد نیاز؟

✅ توقف اضطراری یا rollback چطوریه؟

✅ مانیتور فعال هست؟

✅ روی staging امتحان شده؟

چک‌لیست‌ها نه فقط جلوی اشتباهات انسانی رو می‌گیرن، بلکه فرهنگ مسئولیت‌پذیری، نظم و آرامش به تیم می‌دن. 🧠

حتی برای بدترین سناریوها، اگر از قبل فکر شده باشه، می‌شه از فاجعه جلوگیری کرد. 🚨

چک‌لیست‌ها تو مهندسی داده جادو می‌کنن.

#مهندسی_داده #DataEngineering #ClickHouse #StagingMatters #ChecklistMagic #DatabaseOps #ProductionReady