نحوه ثبت نام توی بوت کمپ شش هفته ای مهندسی داده . 👆👆

عاشقان دیتا لیک‌هوس، این ریپو گنج واقعی مهندسی داده است! 💻

اگر در حوزه دیتا لیک‌هوس فعالیت می‌کنید یا تازه به این دنیای پرهیجان و آینده‌دار مهندسی داده علاقه‌مند شدید، مخزن کد awesome-lakehouse-guide یه منبع بی‌نظیره که نباید از دستش بدید! 🌟

اینجا یه مجموعه کامل و به‌روز برای تسلط بر فرمت‌های جدولی باز (Apache Hudi، Apache Iceberg، Delta Lake) و معماری لیک‌هوس پیدا می‌کنید:

🔍 مقالات تحقیقاتی: از BtrBlocks و Apache Arrow تا AWS Glue و Apache Flink، با تحلیل‌های عمیق درباره بهینه‌سازی ذخیره‌سازی، عملکرد کوئری‌ها و قابلیت‌های ACID.

📝 بلاگ‌های کاربردی: آموزش‌های عملی برای حل چالش‌هایی مثل metadata bloat، بهینه‌سازی با Z-ordering و مدیریت داده‌های نزدیک به real-time.

💻 کد و نوت‌بوک: مثال‌های آماده برای ایجاد جدول‌های Hudi و Iceberg روی Amazon S3، اجرای کلاستریگ و پیاده‌سازی CDC (Change Data Capture).

📣 پست‌های لینکدین: نکات سریع و به‌روز درباره موضوعاتی مثل پردازش برداری و Apache Arrow.

🗂 فعالیت اخیر: به‌روزرسانی‌های دو هفته پیش (تا ۱۵ تیر ۱۴۰۴) شامل README و پست‌های لینکدین، نشون‌دهنده نگهداری فعال این ریپوئه. یه تصویر معماری (lkh_res.png) هم برای درک بهتر لیک‌هوس موجوده!

این ریپو یه نقشه راه کامل برای حرفه‌ای شدن در لیک‌هوسه، چه بخواید تئوری یاد بگیرید، چه دست به کد بشید! 🚀

🔗 مشاهده ریپو : https://github.com/dipankarmazumdar/awesome-lakehouse-guide

#DataEngineering #Lakehouse #BigData #OpenSource #DataLakehouse

‍ نقشه راه Data 3.0 در عصر Lakehouse

خلاصه‌ای از گزارش Bessemer Venture Partners که معماری لیک‌هوس را در دوران مدرن، بسیار آینده‌دار دانسته است. بیایید آنرا با هم مرور کنیم.

📌 https://www.bvp.com/atlas/roadmap-data-3-0-in-the-lakehouse-era

شرکت سرمایه‌گذاری Bessemer Venture Partners (BVP) که سابقه‌ای بیش از یک قرن در حمایت از شرکت‌های نوآور در حوزه‌های ابری، فین‌تک، 🤖 هوش مصنوعی و 🛡 امنیت سایبری دارد، اخیراً گزارشی با عنوان «نقشه راه: Data 3.0 در عصر #Lakehouse» منتشر کرده است. این گزارش با تکیه بر تجربه BVP در سرمایه‌گذاری بر برندهایی مانند Shopify، LinkedIn، Pinterest و Databricks، چشم‌اندازی دقیق از نسل سوم زیرساخت‌های داده ارائه می‌دهد.

🔍 چرا Data 3.0 اهمیت دارد؟

مدیریت داده‌ها طی سه نسل دستخوش تحولات عظیمی شده است:

📦 نسخه اول - Data 1.0 (۱۹۷۰–۲۰۰۰):

✅ تمرکز بر پایگاه‌های داده رابطه‌ای (Oracle، MySQL)

✅ استفاده از انبارهای داده‌ای

❌ محدودیت در مقیاس‌پذیری

❌ ناتوان در پردازش داده‌های غیرساختاریافته

🌊 نسخه دوم - Data 2.0 (از ۲۰۱۰ به بعد):

✅ ظهور Hadoop و Spark برای پردازش داده‌های متنوع و حجیم

✅ انعطاف‌پذیری بیشتر

❌ باتلاق داده‌ای (Data Swamp) به‌دلیل ضعف در کیفیت و حاکمیت

🚀 نسخه سوم - Data 3.0 (از ۲۰۲۰ به بعد):

✅ یکپارچگی

✅ پردازش لحظه‌ای

✅ استفاده از هوش مصنوعی

📌 ابزارهای کلیدی: Lakehouse، Delta Lake، Iceberg، Hudi، خطوط لوله AI-driven


💡 معماری Lakehouse چیست و چرا انقلابی است؟

لیک‌هوس ترکیبی از قدرت Data Warehouse و انعطاف Data Lake است.

ویژگی‌های کلیدی:

📌 پشتیبانی از داده‌های ساختاریافته و غیرساختاریافته

📌 فرمت‌های باز با قابلیت‌های ACID، Time Travel، پردازش لحظه‌ای

📌 کاهش افزونگی داده و وابستگی به Vendorها

این معماری پایه‌ای برای توسعه ابزارهای تحلیلی و برنامه‌های AI در مقیاس بزرگ است.


🔮 چهار روند کلیدی در Data 3.0 به روایت BVP

1️⃣ خطوط لوله هوشمند و لحظه‌ای

🛠 ابزارهای جدید: Prefect، Windmill، dltHub

⚙️ فناوری‌های جریانی: Apache Flink، Kafka

⚡️ پلتفرم‌های بلادرنگ مانند Chalk برای تصمیم‌گیری سریع


2️⃣ متادیتا به‌عنوان منبع حقیقت

🛠 ابزارهایی مانند Datastrato، Acryl Data

💡 بهینه‌سازهایی مثل Flarion.io و Greybeam


3️⃣ تحول در موتورهای محاسباتی:

🛠 موتورهای سبک و سریع: DuckDB، ClickHouse، Daft

🌕 بسترهای Iceberg-native مثل Mooncake و Bauplan و RisingWave


4️⃣ ادغام مهندسی داده و نرم‌افزار:

🧩 ابزارهایی مانند dbt و Gable

🔄 یکپارچه‌سازی با CI/CD، نسخه‌سازی، تست خودکار


💸 فرصت‌های سرمایه‌گذاری و نوآوری

BVP باور دارد که Data 3.0 فرصت بی‌سابقه‌ای برای بنیان‌گذاران ایجاد کرده تا:

🔧 ابزارهای منبع‌باز و ابری جدید بسازند

🚀 موتورهای بهینه‌شده برای AI ارائه دهند

📊 راه‌حل‌های هوشمند برای متادیتا خلق کنند


📌 جمع‌بندی : معماری Lakehouse نماد تحول در مدیریت داده‌هاست:

✔️ عملکرد بالا

✔️ تحلیل لحظه‌ای

✔️ پشتیبانی از AI

✔️ مقیاس‌پذیری بالا

آینده از آن تیم‌هایی است که به جای مدیریت زیرساخت‌های پیچیده، بر خلق ارزش از داده‌ها تمرکز می‌کنند.

🏷 #Data3 #Lakehouse #AI #Metadata #StreamingData #DuckDB #Iceberg #DeltaLake #BVP #DataEngineering #ModernDataStack #RealTimeAnalytics #OpenSource #DataInfra #Startup #DataPlatform #VentureCapital #FutureOfData

‍ از استانداردسازی تا ساده‌سازی: آینده‌ی Iceberg در مهندسی داده

🔍تحلیلی بر دو تحول مهم: DuckLake و مقاله جدید MinIO


احتمالاً توی یک سال گذشته، بارها چشم‌تون به مقالات، ابزارها، یا گفتگوهایی افتاده که حول‌وحوش موضوعی به اسم #Iceberg می‌چرخن — یه استاندارد باز و ساخت‌یافته برای ذخیره داده‌ها به‌صورت خام، اما با قابلیت‌هایی شبیه پایگاه داده:

📌امکان اجرای کوئری‌های تحلیلی مستقیم روی فایل‌های Parquet

📌پشتیبانی از schema evolution و تراکنش‌های ACID

📌و جداسازی کامل ذخیره‌سازی از موتور پردازش

🧊 به‌جرات میشه گفت که #Iceberg یکی از ترندهای داغ این روزهای مهندسی داده‌ست — از Google BigQuery گرفته تا AWS S3، از Dremio تا Snowflake و پروژه Polaris، همگی در حال پشتیبانی مستقیم یا بومی از Iceberg هستن.

و البته این موضوع فقط جهانی نیست — همین چند هفته پیش، در یکی از جلسات مشاوره‌ که با یکی از شرکت‌های بزرگ فولادی کشور بود، موضوع جلسه بررسی بهترین راه برای طراحی، راه‌اندازی، و مدیریت یک Lakehouse مبتنی بر Iceberg بود. کاری که تیم فنی این شرکت، نسخه اولیه آنرا راه اندازی کرده بود. 🚀

🔄 اما دو اتفاق باعث شد که احساس کنم : آینده‌ی Iceberg بسیار ساده‌تر و سبک‌تر خواهد بود.

🌟 اولی معرفی DuckLake بود - https://ducklake.select.

در دنیایی که پر بود از سرویس‌های کاتالوگ مختلف (Hive Metastore، Glue، Project Nessie، JDBC Metastore و...)، #DuckLake اومد و گفت:

«همه‌ی اینا رو بذارید کنار! من با یه دیتابیس SQL ساده، همه کارهای مدیریت متادیتا و فایل‌های داده رو انجام می‌دم.»

📦 داده‌ها همون Parquet هستن روی object storage، اما متادیتا داخل یه دیتابیس ساده مثل #DuckDB یا #Postgres ذخیره می‌شن. همه چیز از طریق #SQL مدیریت می‌شه. بدون نیاز به سرویس‌های جانبی، بدون پیچیدگی. دقیقاً شبیه #SQLite برای دیتالیک‌ها.

🔥 و استقبال خوبی هم ازش شده. چون ساده‌تر از Iceberg معمولی راه می‌افته و سربار کمتری داره.

🧠 دومین اتفاق، مقاله‌ای بود که همین چند روز پیش از طرف MinIO منتشر شد.
https://blog.min.io/the-case-for-native-iceberg-catalog-apis-and-unified-governance-in-object-storage

این مقاله به یه نقطه‌ضعف مهم در معماری‌های فعلی دیتالیک اشاره می‌کرد:

«متادیتا و دسترسی به فایل‌های واقعی داده، در دو سیستم جداگانه کنترل می‌شن. همین باعث می‌شه امنیت و حاکمیت داده ناقص باقی بمونه.»

یعنی ممکنه کاربر به جدول Iceberg مجوز نداشته باشه، ولی هنوز بتونه مستقیم فایل‌های #Parquet رو از #S3 یا #MinIO بخونه! 😬

استوریج MinIO پیشنهاد داده که APIهای Iceberg Catalog به‌صورت بومی در خود پلتفرم ذخیره‌سازی تعبیه بشن، طوری که هم متادیتا و هم دسترسی به فایل‌ها، از یک‌جا و با یک مدل امنیتی مدیریت بشن. این یعنی سادگی بیشتر، امنیت بهتر، و مدیریت یکپارچه‌تر.

🔮 پیش‌بینی من؟
ما داریم به سمتی می‌ریم که: Iceberg دیگه یه «ابزار حرفه‌ای مخصوص متخصص‌ها» نیست — بلکه تبدیل می‌شه به یک استاندارد ساده، امن، و در دسترس برای همه تیم‌های داده

🌊 به‌زودی، ساخت یک دریاچه‌داده قدرتمند، به اندازه راه‌اندازی یک دیتابیس ساده خواهد بود. و Iceberg ستون اصلی این تحول باقی می‌مونه.

#ApacheIceberg #DuckLake #MinIO #DataLakehouse #MetadataGovernance #ObjectStorage #OpenTableFormats #SQL #دیتالیک #مهندسی_داده #Parquet #BigData

چطور تسلا با ClickHouse یک پلتفرم مشاهده‌پذیری در مقیاس نجومی ساخت؟

مشاهده‌پذیری در مقیاس کوادریلیون (هزار بیلیارد) با ClickHouse و پروژه‌ای به نام Comet

داستان تغییر زیرساخت observability تسلا از کجا شروع شد ؟

🔧 چند میلیون خودرو متصل، هزاران زیرسیستم توزیع‌شده، و گیگافکتوری‌هایی که شبانه‌روز داده می‌فرستند. تسلا در چنین مقیاسی نمی‌توانست روی Prometheus حساب باز کند...

👨‍💻 مهندس ارشد تسلا Alon Tal، می‌گوید:

«ما به سیستمی نیاز داشتیم که بتونه ده‌ها میلیون ردیف در ثانیه را ingest کنه، سال‌ها داده رو نگه داره، و همچنان real-time پاسخ بده.»

چرا Prometheus کافی نبود؟

🔸 مقیاس‌پذیری افقی محدود

🔸 وابستگی به یک سرور واحد (ریسک از دست دادن کل متریک‌ها)

🔸 مشکلات نگهداری بلندمدت و زبان کوئری محدود

✅ راه‌حل: ساخت یک سیستم جدید به نام Comet

💡 با استفاده از ClickHouse به عنوان هسته‌ی اصلی، تسلا یک پلتفرم metrics محور ساخت که:

📥 داده‌ها را از طریق OTLP و Kafka ingest می‌کند

⚙️ با ETLهای سفارشی داده‌ها را به شکل ساخت‌یافته وارد ClickHouse می‌کند

🔄 و مهم‌تر از همه:

کوئری‌های PromQL را به SQL معادل در ClickHouse ترجمه می‌کند بدون اینکه مهندسان متوجه تفاوت شوند!

🧠 یعنی داشبوردهای موجود (Grafana، Alertmanager، و...) بدون تغییر کار می‌کنند!

💥 مقیاس واقعی؟

یک میلیارد ردیف در ثانیه! به مدت ۱۱ روز پیاپی!

نتیجه؟

🔹 بدون یک خطا

🔹 مصرف ثابت RAM و CPU

🔹 بیش از ۱ کوادریلیون رکورد با موفقیت ingest شده!

📊 سیستم هنوز هم در حال scale شدن برای تیم‌های داخلی تسلاست!

✨ چرا ClickHouse؟

🔹 سرعت بی‌رقیب در پاسخ به کوئری‌های پیچیده

🔹 UDFهای اجرایی برای کوئری‌های غیر trivial

🔹 پشتیبانی از PromQL و TraceQL

🔹 نگهداری بلندمدت داده‌ها با حجم بالا

🔹 و مهم‌تر از همه: قابلیت اطمینان بالا در مقیاس تسلا!

🔭 آینده‌ی Comet؟

🔧 پشتیبانی از distributed tracing

🌍 احتمال open-source شدن

🎯 گسترش به دیگر واحدهای عملیاتی در تسلا

📎 جمع‌بندی

تسلا با پروژه‌ی Comet ثابت کرد که observability در مقیاس سیاره‌ای ممکن است—اگر ابزار مناسب انتخاب شود!


✅ حالا واقعا پرومتئوس حذف شد؟

تسلا Prometheus رو به‌طور مستقیم حذف نکرد، ولی:

🌟دیگه از خود Prometheus برای ذخیره‌سازی و کوئری استفاده نمی‌کنه.

🌟 به‌جاش، پلتفرمی به نام Comet ساخت که خودش می‌تونه PromQL (زبان کوئری Prometheus) رو اجرا کنه و پشت صحنه با کلیک‌هوس ارتباط بگیره و خروجی بده بدون اینکه واقعاً Prometheus وجود داشته باشه!


🔗 منبع اصلی:

https://clickhouse.com/blog/how-tesla-built-quadrillion-scale-observability-platform-on-clickhouse

#ClickHouse #Observability #Tesla #PromQL #DataEngineering #Scalability #TimeSeries #Kafka #DevOps #OpenTelemetry #Infrastructure

جزوه آموزشی هوش تجاری در SQL Server - دکتر حداد

‍ داستان Apache Gluten: بازنویسی سرعت در دنیای کلان‌داده

اگر از اسپارک و بخصوص Spark SQL در حجم کلان استفاده می‌کنید، گلوتن یک هدیه به شماست!

بنیاد Apache، به‌عنوان یکی از پیشگامان توسعه پروژه‌های متن‌باز در دنیای مهندسی داده، در سال‌های اخیر پروژه‌های متعددی را به اکوسیستم خود اضافه کرده است. این پروژه‌ها اغلب با هدف بهبود عملکرد، ارتقاء مقیاس‌پذیری، و ساده‌سازی زیرساخت‌های موجود طراحی می‌شوند.

🔍 در مجموعه‌ای از پست‌ها قصد دارم به معرفی این پروژه‌ها بپردازم و بررسی کنم که هر کدام چگونه به حل مسائل رایج دنیای داده کمک می‌کنند.
برای شروع، سراغ یکی از پروژه‌های جذاب این اکوسیستم می‌رویم: Apache Gluten.

💡 چرا Apache Gluten مهم است؟

درست است که امروز ابزارهای گوناگونی برای پردازش داده‌ها در دسترس داریم، اما واقعیت این است که نمی‌توان به‌راحتی زیرساخت‌هایی را که سال‌ها در سازمان‌ها پیاده‌سازی، بهینه‌سازی و توسعه داده شده‌اند، کنار گذاشت. به‌ویژه Apache Spark، که در طول بیش از یک دهه به یکی از ستون‌های اصلی تحلیل داده در شرکت‌های بزرگ تبدیل شده است، همچنان بخش مهمی از معماری داده بسیاری از سازمان‌ها را تشکیل می‌دهد. اما Spark نیز محدودیت‌هایی دارد؛ از جمله سربارهای JVM و مصرف بالای حافظه و پردازنده.

اینجاست که پروژه‌هایی مانند Apache Gluten شکل می‌گیرند: پروژه‌هایی که به‌جای جایگزینی، به بهینه‌سازی و بازنویسی موتورهای موجود برای بهره‌وری بالاتر کمک می‌کنند.

⚙️ آپاچی Gluten دقیقاً چه می‌کند؟
آپاچی Gluten یک پلاگین شفاف برای Apache Spark است که هدف آن افزایش سرعت و کاهش مصرف منابع در اجرای کوئری‌های SQL است — بدون اینکه نیاز به تغییر در کوئری‌های فعلی یا اپلیکیشن‌ها باشد.

گلوتن این کار را با انتقال اجرای کوئری‌ها از JVM به موتورهای native مانند Velox (توسعه‌یافته توسط Meta) و ClickHouse انجام می‌دهد.

🚀 چگونه Gluten این شتاب را ایجاد می‌کند؟
🔧 گلوتن Pipeline اجرای Spark را بازنویسی می‌کند:

🛠 تبدیل Query Plan به فرمت Substrait

⚙️ اجرای native از طریق JNI

🌱 مصرف حافظه کمتر (تا ۱۰٪ کمتر نسبت به Spark استاندارد)

🔄 استفاده از Columnar Shuffle برای بهبود سرعت انتقال داده

🛡 بازگشت هوشمند به JVM در صورت عدم پشتیبانی Native

📊 نتایج عملکرد

طبق بنچمارک‌های رسمی:

✅ تا ۳.۳ برابر افزایش سرعت در TPC-H

✅ تا ۲ برابر بهبود در TPC-DS

✅ کاهش محسوس در مصرف CPU و RAM

✅ حفظ کامل مانیتورینگ در UI اسپارک

🔌 موتورهایی که توسط Gluten پشتیبانی می‌شوند:
- موتور پردازشی Velox: کتابخانه C++ برای پردازش برداری، با عملکرد بسیار بالا

- کلیک هوس : دیتابیس columnar سریع با پشتیبانی خوب از queryهای تحلیلی

🚀 پشتیبانی در حال توسعه از GPU و FPGA برای پردازش‌های خاص

🌍 چه شرکت‌هایی از آن استفاده می‌کنند؟
آپاچی Gluten به‌سرعت در حال پذیرش توسط شرکت‌های بزرگی است:

علی‌بابا Cloud: پردازش داده در زیرساخت‌های ابری

مایکروسافت Fabric: پلتفرم یکپارچه داده

شرکت IBM: بهینه‌سازی مبتنی بر Velox

و غول‌هایی مانند Google، Baidu، Meituan و NetEase در تحلیل‌های real-time

🌟 مزایای کلیدی برای تیم‌های مهندسی داده
⚡️ عملکرد بالا: تا ۳.۳ برابر سریع‌تر

💾 کاهش مصرف منابع: حافظه و پردازنده

📊 سازگاری کامل با UI اسپارک

🌐 پشتیبانی از شتاب‌دهنده‌های سخت‌افزاری (GPU/FPGA)

🧩 بدون نیاز به بازنویسی کدهای SQL موجود


🔜 برنامه توسعه تا ۲۰۲۵ شامل:

پشتیبانی از معماری ARM

پشتیبانی از Apache Flink

آمادگی برای Apache Spark 4.0

‍ آپاچی کافکا، ستون فقرات معماری‌های داده‌محور... اما نه همیشه!

برای بسیاری از ما، آپاچی کافکا #Kafka نماد مقیاس‌پذیری، پایداری و قدرت در طراحی معماری‌های real-time و event-driven است.

اما اگر نیاز ما صرفاً یک ورود ساده‌ی داده (ingestion) بدون نیاز به بازپخش (replay) یا چند مصرف‌کننده مستقل (consumer) باشد، آیا باز هم کافکا انتخاب درستی است؟

🧵 در یک مقاله دقیق از تیم ThreadSafe Diaries، همین سؤال مطرح شده و آن‌ها تلاش کردند برای بخشی از سیستم خود، راه‌حلی ساده‌تر و کارآمدتر پیدا کنند. این پست، چکیده‌ای از تجربه‌ی آن‌هاست:

🔗 لینک مقاله کامل


📉 چالش‌ها و مشکلات معماری مبتنی بر آپاچی کافکا:

🔸 استفاده از کافکا + ZooKeeper با خوشه‌ای ۳ نودی برای ingest داده‌های تحلیلی

🔸 تنها با ۱۸هزار رویداد در ثانیه، سیستم دچار مشکلات زیر شد:

⚠️ تأخیرهای مداوم در مصرف‌کننده‌ها (Consumer Lag)

⚠️ اختلالات در offset و هماهنگی (Coordination)

⚠️ فشار زیاد روی دیسک و هزینه بالای زیرساخت (EC2 + EBS)

⚠️ نیاز مداوم به پشتیبانی عملیاتی و تیم DevOps

در نهایت تیم متوجه شد که بسیاری از قابلیت‌های کافکا (مثل replayability، چند مصرف‌کننده، یا تحمل‌پذیری بالا) اصلاً در این سناریو مورد نیاز نبود.

✅ راه‌حل ساده‌تر و مؤثرتر چه بود؟

🔹 استفاده از ترکیب Redis Streams و یک مجموعه Go workerهای بدون‌حالت (stateless)

معماری پیشنهادی به شکل زیر پیاده‌سازی شد:

📨 ارسال دسته‌ای رویدادها از سمت فرانت‌اند (هر ۳ تا ۵ ثانیه)

🧩 یک API سبک برای دریافت و ذخیره در Redis Streams

⚙️ مجموعه‌ای از Go workerها که داده‌ها را از stream خوانده و به Postgres، S3 یا سرویس‌های ML می‌فرستند



📊 دستاوردهای معماری جدید با Redis Streams:

- افزایش نرخ پردازش: از ۱۸هزار به ۴۲هزار رویداد در ثانیه (۲.۳×)

- کاهش تأخیر: از ۲۵ms به ۳.۲ms (۷.۸× سریع‌تر)

- صرفه‌جویی در هزینه: از ۳,۲۰۰ دلار به ۱,۰۵۰ دلار در ماه (۶۷٪ کاهش)

- کاهش هشدارهای عملیاتی: از ۴–۵ بار در ماه به صفر تماس اضطراری



💡 آیا این یعنی آپاچی کافکا دیگر مفید نیست؟ قطعاً نه!

کافکا همچنان در معماری‌هایی که به قابلیت بازپخش، fan-out، تحمل خطا، یا مصرف‌کننده‌های موازی نیاز دارند، ابزاری بی‌رقیب است.

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

🔸 پیچیدگی عملیاتی، هزینه و زمان توسعه و نگهداری بیشتر



📚 درس‌هایی که تیم آموخت:

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

🔹 طراحی باید بر اساس جریان داده انجام شود، نه با فرض اینکه ابزار خاصی الزاماً باید در معماری وجود داشته باشد. در این پروژه، نیاز فقط دریافت، پردازش و ارسال ساده رویدادها بود.

🔹 بنچمارک واقعی همیشه بهتر از فرضیات است؛ Redis در تست‌های عملی، عملکرد بهتری از کافکا داشت — نه صرفاً روی کاغذ یا در مستندات.

🔹 هزینه زیرساخت بخشی از معماری است؛ قدرت کافکا "رایگان" نیست و در قالب منابع محاسباتی، عملیات پشتیبانی و زمان توسعه‌دهندگان خود را نشان می‌دهد.

🔹 پیچیدگی مهاجرت و نگهداری مهم است؛ گاهی فقط نیاز به ارتقاء (مثل مهاجرت از ZooKeeper به KRaft) می‌تواند دلیلی کافی برای بازطراحی معماری باشد.

✅ نتیجه‌گیری:

انتخاب ابزار مناسب، بیش از آنکه به «قدرت» آن مربوط باشد، به تناسبش با نیاز واقعی سیستم شما بستگی دارد. سادگی، وقتی به‌درستی انتخاب شود، می‌تواند بهترین ابزار مهندسی باشد.

‍ نگاهی به OpenFGA؛ سیستم مجوزدهی گراف‌محور الهام‌گرفته از Google Zanzibar

در یکی از پروژه‌های اخیر مشاوره، در حال راه‌اندازی و تست زیرساخت یک Lakehouse با استفاده از LakeKeeper بودم — یک کاتالوگ سرور سبک برای Iceberg.

برای احراز هویت و کنترل دسترسی، این سیستم از ترکیب Keycloak و OpenFGA استفاده می‌کند.

کتابخانه #Keycloak را قبلاً می‌شناختم، اما #OpenFGA برایم جدید بود و کنجکاوم کرد. این پست خلاصه‌ای از بررسی اولیه‌ام درباره‌ی این ابزار مدرن مجوزدهی است.

🧠 نقطه‌ی آغاز: Google Zanzibar

در سال ۲۰۱۹، گوگل مقاله‌ای منتشر کرد با عنوان:

“Zanzibar: Google’s Consistent, Global Authorization System”

این مقاله مدل جدیدی برای مدیریت مجوزهای دسترسی در سیستم‌های بزرگ معرفی کرد؛ مدلی که بر پایه‌ی روابط گرافی میان کاربران، گروه‌ها و منابع طراحی شده بود. این مدل، به نام #ReBAC (Relationship-Based Access Control) شناخته می‌شود.

کتابخانه OpenFGA یکی از معروف‌ترین پیاده‌سازی‌های متن‌باز بر اساس این مدل است.


🔄 مدل ReBAC در برابر RBAC و ABAC

در سیستم‌های سنتی، ما با دو مدل رایج کار می‌کردیم:

مدل #RBAC می‌پرسد: «چه کسی هستید؟» (مثلاً: مدیر / کاربر)

مدل #ABAC می‌پرسد: «چه ویژگی‌هایی - Attribute -دارید؟» (مثلاً: دپارتمان = منابع انسانی)

اما در دنیای واقعی، سناریوهای پیچیده‌تری وجود دارد:

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

در این‌جا مدل ReBAC وارد می‌شود:

"چه رابطه‌ای با منبع دارید؟"



🔄کتابخانه OpenFGA چیست؟

پروژه OpenFGA یکی از پیاده‌سازی‌های متن‌باز، سریع و قابل‌اتکای مدل #ReBAC است که با زبان #Go توسعه یافته است.

این ابزار که توسط تیم Auth0 و Okta توسعه یافته، به شما امکان می‌دهد:

- دسترسی‌ها را در قالب گرافی از روابط بین کاربران، گروه‌ها و منابع مدل کنید

- منطق مجوزدهی را از کد جدا نگه دارید و از طریق API فراخوانی کنید

- با ابزارهای احراز هویت مانند Keycloak یا OIDC ادغام کنید

- شرط‌های پیچیده را اعمال کنید (مثلاً: دسترسی فقط اگر حساب کاربر فعال باشد)

✅ چه پروژه‌ها و شرکت‌هایی از این مدل استفاده می‌کنند؟

- نتفلیکس از پروژه‌ی مشابهی به نام SpiceDB (محصول AuthZed) استفاده کرده و آن را توسعه داده تا ویژگی‌های ABAC را نیز پشتیبانی کند.

- شرکت Airbnb سیستم داخلی خود به نام Himeji را بر پایه همین ایده ساخته است.

- پروژه OpenObserve یک کتابخانه مدیریت observability است که OpenFGA را مستقیماً به‌کار گرفته.

- پروژه Backstage (Spotify) امکان اتصال به OpenFGA از طریق پلاگین‌های متن‌باز را دارد.

- و ...


🔄 آیا فقط OpenFGA؟ نه الزاماً!

مقاله Google Zanzibar الهام‌بخش چندین پروژه متن‌باز دیگر نیز شده است که می‌توانید به‌جای OpenFGA از آن‌ها استفاده کنید.

مثلاً: Permify یک سیستم متن‌باز برای مجوزدهی ریزدانه (Fine-Grained Authorization) که کاملاً از مدل #Zanzibar پیروی می‌کند.

همچنین می‌توان به Ory Keto و SpiceDB نیز اشاره کرد که در زمینه مشابه فعال‌اند.

📌 جمع‌بندی

اگر در حال طراحی یک زیرساخت داده‌محور، داشبورد چندمستأجری، پلتفرم SaaS یا سامانه‌ی مشارکتی هستید، و مدل #RBAC دیگر جواب نیازهایتان را نمی‌دهد، حتماً نگاهی به #OpenFGA و سایر پروژه‌های مبتنی بر #ReBAC داشته باشید: به عنوان یک روش قابل اطمینان برای مدیریت دسترسی در مقیاس بالا و مناسب کاربردهای پیچیده مجوزدهی.

‍ الگوی Outbox و داستان یک راهکار هوشمندانه در پستگرس

اخیراً مقاله‌ای از صادق دوستی در Dev.to خواندم که نشان داد با تجربه و تسلط، می‌توان برای چالش‌های بزرگ، راه‌حل‌هایی هوشمندانه و ساده پیدا کرد. یعنی در دنیای فنی، گاهی غرق پیچیدگی‌ها می‌شویم و راه‌حل‌های ساده اما عمیق را نادیده می‌گیریم. این پست ادای دینی است به صادق عزیز Sadeq Dousti و مقالات ارزشمندش، و مروری بر مشکل پیاده‌سازی الگوی Outbox با PostgreSQL در حجم بالای داده و راه‌حلی خلاقانه برای آن.

https://dev.to/msdousti/postgresql-outbox-pattern-revamped-part-1-3lai/



🎯 الگوی Outbox چیست؟

در یک فروشگاه آنلاین، ثبت سفارش باید چند کار را انجام دهد:

✅ذخیره در پایگاه داده

✅ارسال ایمیل تأیید

✅به‌روزرسانی موجودی

✅اطلاع به واحد ارسال

این اکشن‌ها به بروکرهایی مثل Kafka ارسال می‌شوند تا هر واحد کار خود را انجام دهد.

❓ اگر ارسال پیام به بروکر با خطا مواجه شود؟

Outbox وارد می‌شود! سفارش در پایگاه داده ذخیره شده و یک پیام در جدول Outbox ثبت می‌شود. یک سرویس جداگانه پیام‌ها را خوانده و به بروکر می‌فرستد. در صورت خطا، پیام در جدول باقی می‌ماند تا دوباره برای پردازش ارسال شود اما ...



🔍 چالش: حجم بالای داده‌ها

با افزایش پیام‌ها در Outbox:

⚠️کوئری‌های خواندن پیام‌های منتشرنشده کند می‌شوند.

⚠️ایندکس‌ها به دلیل آپدیت‌های مکرر غیربهینه می‌شوند.

⚠️مصرف منابع سیستم افزایش می‌یابد.



💡 راه‌حل: پارتیشن‌بندی هوشمند

صادق دوستی پیشنهاد می‌کند جدول Outbox را به دو پارتیشن تقسیم کنیم:

outbox_unpublished: پیام‌های منتشرنشده (published_at IS NULL)

outbox_published: پیام‌های منتشرشده (published_at NOT NULL)

با این کار، پیام‌های جدید به outbox_unpublished می‌روند و پس از انتشار، به‌صورت خودکار به outbox_published منتقل می‌شوند. بنابراین کوئری‌ها فقط روی پارتیشن سبک‌تر اجرا می‌شوند.



🎉 مزایا:

✅سرعت بالا: کوئری‌ها روی پارتیشن کوچک‌تر اجرا می‌شوند.

✅مدیریت آسان: حذف پیام‌های قدیمی با TRUNCATE سریع است.

✅بهینه‌سازی منابع: ایندکس‌ها کوچک و کارآمد می‌مانند.



🏁 جمع‌بندی

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

🔗 برای جزئیات بیشتر، حتا مقاله صادق در Dev.to را بخوانید!

#outbox #postgres #performance #database #dataengineering

#مهندسی_داده

‍ بررسی تغییرات پایگاه‌های داده در نظرسنجی Stack Overflow 2025📊

نظرسنجی سالانه Stack Overflow برای سال 2025 منتشر شده و یافته‌های قابل‌توجهی را در خصوص روند استفاده از پایگاه‌های داده در میان توسعه‌دهندگان حرفه‌ای ارائه می‌دهد.

آدرس نظر سنجی :

Technology | 2025 Stack Overflow Developer Survey

در این پست نگاهی خواهیم داشت به وضعیت پستگرس‌کیوال (PostgreSQL)، رشدهای چشمگیر و همچنین کاهش‌ها و غیبت‌های معنادار. 🚀

🏆 پستگرس PostgreSQL: ادامه‌ سلطه با رشد پایدار

پستگرس با ثبت رشد ۱۰٪ نسبت به سال گذشته و رسیدن به نرخ استفاده ۵۵.۶٪، جایگاه نخست خود را در میان پایگاه‌های داده محبوب حفظ کرده است. از سال ۲۰۲۳، این پایگاه داده به‌عنوان "مطلوب‌ترین" (۴۶.۵٪) و "تحسین‌شده‌ترین" (۶۵.۵٪) گزینه نزد توسعه‌دهندگان شناخته می‌شود. 😍


🔍 دلایل اصلی محبوبیت PostgreSQL:

✅انعطاف‌پذیری بالا: پشتیبانی از داده‌های رابطه‌ای و غیررابطه‌ای مانند JSON.

✅جامعه متن‌باز قدرتمند: توسعه مداوم و اسناد جامع.

✅عملکرد مناسب برای سناریوهای پیچیده: پاسخ‌گویی به بارهای کاری سنگین و ساختارهای داده پیشرفته.

📈 پایگاه‌های داده با رشد چشمگیر

🎯 ردیس: با رشد ۱۰٪ به ۲۸٪ رسید و با عبور از MongoDB به رتبه پنجم صعود کرد. ⚡️ همچنین Valkey نیز با ۲.۵٪ ورود قابل‌توجهی به صحنه داشت.

🎯 الستیک سرچ: با افزایش ۵٪، به نرخ استفاده ۱۶.۷٪ رسید؛ رشدی معنادار برای این موتور جستجوی داده.

🎯 دیتابیس DuckDB: با دو برابر شدن سهم خود به ۳.۲٪، توجه‌ها را به سمت خود جلب کرده است.

🎯 خدمات ابری Supabase: از ۴.۱٪ به ۶٪ رسید و برای نخستین‌بار وارد جمع ۱۲ پایگاه داده برتر شد. 🎉

این رشد نشان‌دهنده‌ی پذیرش سریع این گزینه‌ی نوظهور به‌عنوان یک راهکار جایگزین و سبک برای پروژه‌های مدرن است.


📉 پایگاه‌های داده با کاهش استفاده

⚠️ مای اسکیوال MySQL: با کاهش جزئی به ۴۰.۵٪، روندی آهسته اما قابل مشاهده را تجربه کرده است.

⚠️مانگودی بی MongoDB: با رسیدن به ۲۴٪، افتی کمتر از پیش‌بینی‌ها داشته، اما جایگاه خود را در رقابت از دست داده است.


❌ غایب بزرگ

کلیک هوس: غیبت کامل این پایگاه داده تحلیلی از لیست نهایی، جای تعجب دارد. آیا این نتیجه‌ خطایی در داده‌هاست یا نشانه‌ای از کاهش استفاده که بعید به نظر می رسد؟ 🤔


🌟 تمایل توسعه‌دهندگان به یادگیری PostgreSQL

یکی از نکات جالب این گزارش، تمایل بالای کاربران Redis و MongoDB به یادگیری PostgreSQL است. این روند نشان می‌دهد مهارت در پایگاه‌های داده رابطه‌ای همچنان یکی از مزیت‌های کلیدی در مسیر حرفه‌ای توسعه‌دهندگان است. 📈


💡 چرا این موضوع تمایل به استفاده از پستگرس اهمیت دارد؟

انتخاب پایگاه داده مناسب، مستقیماً بر عملکرد، مقیاس‌پذیری و آینده‌پژوهی پروژه‌ها تأثیر می‌گذارد. PostgreSQL با ترکیبی از عملکرد قدرتمند، انعطاف‌پذیری بالا و جامعه پشتیبان گسترده، همچنان انتخاب نخست بسیاری از تیم‌های توسعه است.

#StackOverflow2025 #PostgreSQL #Database #توسعه_نرم‌افزار #فناوری #دیتابیس #تحلیل_داده

‍ معرفی رسمی ClickStack – استک Observability اپن‌سورس بر پایه ClickHouse

سال‌ها بود که با وجود قدرت بالای ClickHouse در ذخیره و کوئری‌گیری سریع داده‌ها، جای یک راه‌حل Observability واقعی در این اکوسیستم حس می‌شد.

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

اما حالا اوضاع فرق کرده.

با خرید HyperDX در ابتدای سال 2025، کلیک‌هوس قدم بزرگی در این حوزه برداشت و اخیرا از ClickStack رونمایی کرد:

یک استک کامل، اپن‌سورس و بسیار سریع برای Observability – ساخته‌شده بر قلب تپنده‌ی ClickHouse. ❤️‍🔥

آدرس : https://clickhouse.com/use-cases/observability

📦 مجموعه ابزار ClickStack چیست؟

🔹 یک پلتفرم سبک و قدرتمند برای مانیتورینگ و دیباگ

🔹 سازگار با OpenTelemetry

🔹 شامل رابط کاربری HyperDX، کلکتور سفارشی، و ClickHouse

🔹 آماده برای محیط‌های تولیدی، با نصب آسان و تجربه‌ای روان برای تیم‌ها


💡 چرا این اتفاق مهمه؟

تا پیش از این، حتی تیم‌هایی مثل نتفلیکس که سال‌ها از کلیک‌هوس برای تحلیل داده‌های Observability استفاده می‌کردند، مجبور بودند ابزارهای اختصاصی خودشون رو بسازند. حالا با ClickStack، همون قدرت و کارایی در اختیار همه هست آن‌ هم به سادگی و سهولت .


✨ ویژگی‌های جذاب ClickStack:
✅ جستجوی بسیار سریع در لاگ‌ها و تریس‌ها

✅ تجزیه‌وتحلیل داده‌های عظیم بدون نیاز به SQL

✅ مشاهده زنده‌ی لاگ‌ها و بازپخش جلسات

✅ پشتیبانی کامل از JSON و schemaهای پویا

✅ همبستگی خودکار بین لاگ، متریک، تریس و سشن

✅ طراحی‌شده برای کار با داده‌های با کاردینالیتی بالا

✅ هشداردهی، تحلیل روند و شناسایی ناهنجاری


🧱 معماری ClickStack

🎯 ClickHouse: قلب پردازش تحلیلی

🎯 OpenTelemetry Collector: جمع‌آورنده‌ی داده‌ها با ساختار بهینه

🎯HyperDX UI: رابط کاربری مدرن برای مشاهده و کاوش داده‌ها

می‌تونید این اجزا رو مستقل یا به‌صورت یکپارچه استفاده کنید. نسخه مبتنی بر مرورگر HyperDX UI هم در دسترسه که می‌تونه به استقرارهای موجود کلیک‌هوس متصل بشه – بدون نیاز به زیرساخت اضافه.


📚 طراحی ClickStack بر اساس چند اصل ساده شکل گرفته:

📌نصب سریع و بدون پیچیدگی

📌پشتیبانی از SQL و Lucene-style search برای راحتی توسعه‌دهنده‌ها

📌دید کامل از سیستم از سشن کاربر تا کوئری دیتابیس

📌سازگاری کامل با اکوسیستم OpenTelemetry

📌و مهم‌تر از همه: اپن‌سورس، قابل‌توسعه و شفاف

🎯 برای همه‌ی تیم‌هایی که دنبال یک راه‌حل سریع، منعطف و قابل‌اتکا برای Observability هستند، حالا یک گزینه جامع و بسیار سریع و در عین حال سبک و مقیاس پذیر داریم.

اگر از ClickHouse استفاده می‌کنید، می‌توانید به راحتی به ClickStack مهاجرت کنید و یا حداقل آنرا امتحان کنید.

#ClickStack #ClickHouse #Observability #OpenTelemetry #DevOps #SRE #OpenSource #HyperDX #MonitoringTools #DataEngineering

‍ پردازش ۱.۲ میلیون پیام در ثانیه با Kafka و Go — معماری سبک اما حرفه‌ای 🎯
وقتی نرخ ورود داده به میلیون‌ها پیام در ثانیه می‌رسد، عامل تعیین‌کننده در یک معماری بهینه و سریع و موثر، نه ارتقای پرهزینه‌ی سخت‌افزار است و نه تکیه بر زیرساخت‌های سنگین ابری، بلکه یک طراحی دقیق، ساده و هوشمندانه است که می‌تواند تفاوت واقعی را رقم بزند.
📖 اخیراً با مقاله‌ای مواجه شدم که دقیقاً همین رویکرد را نشان می‌داد: تیمی که با استفاده از مفاهیم سبک‌وزن مانند goroutine در Go و چند تصمیم مهندسی‌شده، توانسته بودند تنها با یک سخت‌افزار معمولی، بیش از ۱ میلیون پیام در ثانیه را به‌صورت پایدار پردازش کنند.
در این پست، به مرور نکات کلیدی این معماری ساده اما تأثیرگذار می‌پردازیم — روایتی کاربردی از دنیای مهندسی داده و سیستم‌های توزیع‌شده.
📄 مقاله اصلی:
Kafka at 1M Messages/Second with Go – Our Exact Pipeline Setup 👉 https://freedium.cfd/https://medium.com/@harishsingh8529/kafka-at-1m-messages-second-with-go-our-exact-pipeline-setup-aa2c5473b139

📦 چالش‌ها:
⚠️هجوم سنگین داده‌ها از دستگاه‌های IoT و کاربران
⚠️نیاز به پردازش بلادرنگ و ارسال همزمان به چند سرویس
⚠️تضمین پایداری، مانیتورینگ دقیق و ریکاوری خودکار در خطا

🛠 مکانیزم‌هایی که این معماری را ممکن کردند:
✅ کامیت دستی offsetها:
تأیید دریافت فقط زمانی انجام می‌شود که پیام کاملاً و با موفقیت پردازش شده باشد — جلوگیری از گم‌شدن یا پردازش تکراری داده‌ها.
✅ مکانیزم Worker Pool کنترل‌شده با goroutine:
به‌جای ایجاد goroutine برای هر پیام، یک استخر ثابت از goroutineها (به ازای هر پارتیشن کافکا) با طول کانال مشخص و محدود، تعریف شده است که پیام‌ها را موازی اما کنترل‌شده پردازش می‌کنند.
✅ یک Worker Pool به ازای هر پارتیشن Kafka:
مثلاً با ۱۰ پارتیشن و ۵ goroutine برای هر پارتیشن، در مجموع ۵۰ goroutine داریم — بدون هم‌پوشانی، بدون رقابت اضافه.
✅ الگوی Dispatcher برای جداسازی دریافت از پردازش:
- بخش اول: فقط دریافت پیام و ارسال به کانال داخلی (یک کانسیومر به ازای هر پارتیشن)
- بخش دوم: پردازش پیام از صف به کمک Worker Pool
✅ دسته بندی پیام ها یا Batching در ارسال خروجی:
پیام‌های پردازش‌شده به‌صورت گروهی ارسال می‌شوند، مثلاً به دیتابیس یا تاپیک‌های دیگر Kafka. این کار فشار ارتباطی را کاهش داده و throughput را بالا برده است.
✅مکانیزم Backpressure هوشمند:
با محدود کردن ظرفیت صف‌ها، اگر سیستم تحت فشار شدید قرار گیرد، مصرف از Kafka موقتاً کند یا متوقف می‌شود تا منابع آزاد شوند. این مکانیزم، از overload جلوگیری کرده و سیستم را در حالت پایدار نگه می‌دارد.
✅مانیتورینگ دقیق با Prometheus و Grafana:
شاخص‌هایی مثل تأخیر پردازش، consumer lag و مصرف CPU به‌صورت لحظه‌ای مانیتور می‌شوند — برای تنظیم سریع و واکنش فوری.

📊 نتایج:
- نرخ پردازش: ۱.۲M msg/sec
- تأخیر کل مسیر: <۳ms
- مصرف CPU: ۹۰٪ (پایدار و قابل پیش‌بینی)

💡 نکات مهم برای مهندسان داده و سیستم‌های توزیع‌شده:
🔹طراحی درست مهم‌تر از افزایش منابع
🔹 طراحی commit دقیق، batching و backpressure = ستون‌های یک سیستم مقاوم
🔹تفکیک دریافت/پردازش + تقسیم کار بین پارتیشن‌ها = مقیاس‌پذیری مؤثر
🔹مانیتورینگ لحظه‌ای = پاسخ سریع به فشارها و خطاها

#Kafka #GoLang #DataEngineering #HighThroughput #Concurrency #RealTime #ScalableArchitecture #مهندسی_داده #سیستم_توزیع_یافته #معماری_مقیاس‌پذیر

‍ کدام زبان: Rust یا Go؟ نگاهی دوباره از دل تجربه‌ی واقعی

چند وقت پیش مطلبی نوشتم با عنوان «آینده‌ی Rust در مهندسی داده» و یک مطلب دیگر در خصوص مهاجرت بخشی از کدهای #GO در دیسکورد به Rust. هنوز هم به آن حرف‌ها باور دارم:

بخش زیادی از ابزارهای آینده‌ی این حوزه یا با #Rust بازنویسی می‌شوند یا به شکل native با آن توسعه می‌یابند — دلیلش هم مشخص است: سرعت بالا، کنترل دقیق حافظه، و ویژگی‌هایی مثل «zero-cost abstractions»

اما بعد از چند ماه کار عملی با هر دو زبان، دیدگاهم واقع‌گرایانه‌تر شده است. Rust قدرت بالایی دارد، اما پیچیدگی توسعه و زمان بالای یادگیری، آن را برای همه‌ی پروژه‌ها مناسب نمی‌کند. Go در مقابل ساده، سریع، و برای توسعه‌ی روزمره بسیار کارآمد است.

🎯 یکی از تجربه‌های مهم برایم، پروژه‌ای بود که در آن یک تیم، یک سرویس واقعی را با سه زبان Rust، Go و Node.js پیاده‌سازی و در شرایط واقعی با ترافیک زنده تست کرد. تجربه‌ای که در زیر نتایج آنرا با هم مرور می‌کنیم. (لینک: https://freedium.cfd/https://medium.com/@kanishks772/we-didnt-benchmark-it-we-went-to-war-with-it-go-vs-rust-vs-node-at-1m-users-60565cd59b1f)

📌سرویسی که ساختند، شامل احراز هویت، پیام‌رسانی بلادرنگ، و آپلود فایل بود — چیزی شبیه به ستون فقرات یک اپلیکیشن پیام‌رسان. پیاده‌سازی اولیه با Node.js بود، اما دیگر جواب نمی‌داد: نشت حافظه، جهش‌های CPU، و زمان پاسخ‌هایی که باعث rage-quit کاربران می‌شد.

📚به‌جای فرضیه‌سازی، تیم دست‌به‌کار شد: همان سرویس را با Go و Rust هم نوشت و ترافیک را به‌طور مساوی بین هر سه تقسیم کرد. نتیجه چه شد؟

«Rust عملاً از نظر عملکرد، رقبا را پشت سر گذاشت.» اما آنچه این تیم یاد گرفت، چیزی بود که اغلب در بنچمارک‌ها دیده نمی‌شود:

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

⚠️توسعه با Rust 40٪ زمان بیشتری می‌برد. اشکال‌زدایی درگیر borrow checker می‌شد و اضافه‌کردن یک فیچر ساده، به جنگ با سیستم Typing منتهی می‌گردید.

✅در مقابل، Go سرعت توسعه‌ی بالایی داشت، کتابخانه استاندارد کافی و کاربردی، و راه‌اندازی ساده. هرچند کمی از Rust کندتر بود، اما برای تیم، توسعه با Go سه برابر سریع‌تر از Rust و دو برابر سریع‌تر از Node بود.

در نهایت، این تیم از هر سه زبان استفاده کرد:

🔹 Node.js برای ابزارهای مدیریتی و پروتوتایپ‌های سریع

🔹 #Go برای سرویس‌های اصلی و عمومی

🔹 #Rust برای بخش‌هایی که واقعاً performance-critical بودند


درس‌هایی از میدان نبرد

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

✅ تجربه‌ی تیم از زبان مهم‌تر است. زبانی که تیم در آن مهارت دارد، اغلب از زبان بهتری که تیم با آن غریبه است، نتیجه‌ی بهتری می‌دهد.

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

✅ چندزبانی بودن (polyglot) مزیت است، نه نقطه‌ضعف. گاهی بهترین راه این است که یک زبان را همه‌جا استفاده نکنیم. هر ابزار برای کاری ساخته شده.


💡 نتیجه‌گیری شخصی من

زبان Rust هنوز آینده‌ی ابزارهای مهندسی داده است — مخصوصاً در سطح زیرساخت. اما در بسیاری از پروژه‌های کاربردی، از سرویس‌های داخلی گرفته تا microserviceهای API، Go انتخابی‌ست منطقی‌تر و واقع‌گرایانه‌تر.

ما همه مثل Discord نیستیم. منابع، مقیاس و اولویت‌های تیم‌ها متفاوت‌اند.

اما مهم‌تر از انتخاب بین Rust یا Go، این است که انتخاب‌مان با چشمان باز باشد — از دل تجربه، نه فقط از روی بنچمارک‌ها یا توییت‌های ترند شده.

‍ چرا بسیاری از تیم‌ها ORM را کنار می‌گذارند و سراغ SQL خام می‌روند؟

اخیرا در مدیوم با تعداد زیادی از مقاله‌ها مواجه می‌شوم که یک پیام مشترک دارند:

🔁 «ما #ORM را کنار گذاشتیم و به #SQL خام مهاجرت کردیم — و دیگر برنمی‌گردیم.»

نکته جالب اینجاست که این تصمیم‌ها معمولاً از سر عشق به SQL گرفته نشده‌اند، بلکه از دل دردسرهای #ORM زاده شده‌اند.

در چند مقاله‌ی اخیر که مطالعه کردم، تیم‌های مختلفی با تکنولوژی‌های مختلف (از #Java + #Postgres گرفته تا #Go + #SQLAlchemy) تجربه‌ی مهاجرت از ORM را به اشتراک گذاشته‌اند — نه فقط برای بهبود سرعت، بلکه برای بازگشت به شفافیت، کنترل و عقلانیت.


⚠️مشکل کجا بود؟ چرا ORM جوابگو نبود؟

اگرچه ORM در شروع پروژه‌ها خیلی مفید است (خصوصاً برای CRUDهای سریع و MVPها)، اما با رشد سیستم، مشکلاتی کم‌کم خود را نشان می‌دهند:

🧨معضل N+1 Query

کوئری‌هایی که ساده به نظر می‌رسند، در باطن ده‌ها یا صدها درخواست اضافه تولید می‌کنند.

🌀 کدهای پیچیده اما غیرشفاف

برای کوئری‌های پیچیده‌تر مثل Window Function، CTE یا Join چندجدولی، باید به انواع annotationها، chainهای مبهم، یا زبان‌های خاص ORM (مثل JPQL) متوسل شد — که در نهایت باز هم می‌رسیم به نوشتن SQL، فقط با دردسر بیشتر.

🔍 ضعف در دیباگ و پروفایلینگ

در ORM، به‌سختی می‌شود فهمید دقیقاً چه کوئری‌ای به دیتابیس رفته. این یعنی دیباگِ کندی‌ها تقریباً کورکورانه است.

💡 ناسازگاری با مدل واقعی داده‌ها

دیتابیس با row و index و join کار می‌کند؛ ORM با کلاس و رابطه شی‌گرایانه. این تطبیق، به‌ویژه در سیستم‌های پیچیده، منجر به کدهایی می‌شود که بیشتر شبیه «جنگیدن با ORM» هستند.


🎯چرا SQL خام یک تفاوت واقعی ایجاد کرد؟

بعد از مهاجرت، همه تیم‌ها روی این دستاوردها تأکید داشتند:

✅ کنترل کامل

می‌دانیم چه کوئری نوشته‌ایم، چه زمانی اجرا می‌شود، و چگونه می‌توان آن را بهینه کرد.

✅ شفافیت

کوئری واضح است، بدون «جادوی مخفی». این یعنی همه تیم — از جونیور تا لید — متوجه می‌شود چه اتفاقی می‌افتد.

✅ هماهنگی بیشتر با منطق دامنه

به‌جای تعریف business logic در repository و annotation، همه‌چیز در لایه‌های مشخص خدماتی و use-case محور قرار می‌گیرد.

✅ استفاده کامل از قدرت دیتابیس

ویژگی‌هایی مثل Window Function، CTE، JSONB و Partial Index که در ORM اغلب یا پشتیبانی نمی‌شوند یا با پیچیدگی زیاد ممکن‌اند، در SQL خام به‌راحتی قابل استفاده‌اند.

📌نگهداری و مقیاس‌پذیری چطور مدیریت شد؟

برای جلوگیری از بی‌نظمی، تیم‌ها:

- کوئری‌ها را در فایل‌های جدا و نسخه‌دار نگه داشتند

- از template و query loaderهای سبک استفاده کردند

- روی هر کوئری تست (یا حداقل EXPLAIN) نوشتند

- قواعد ساده ولی سخت‌گیرانه‌ای برای امنیت (مثل پارامترگذاری) اعمال کردند

در نتیجه، برخلاف تصور اولیه، نگهداشت SQL خام هم قابل مدیریت و حتی لذت‌بخش شد.

💡کی باید ORM را کنار گذاشت؟

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

✅برای پروژه‌های کوچک، MVPها یا پنل‌های ادمین، ORM عالی است.

✅اما در پروژه‌های داده‌محور، با ترافیک بالا، کوئری‌های پیچیده و نیاز به کنترل عملکرد، ORM به‌جای کمک، تبدیل به مانع می‌شود.


📚 جمع‌بندی

بسیاری از ما با ORMها بزرگ شده‌ایم اما آیا هنوز ORM بهترین ابزار ماست؟ یا فقط آسان‌ترین است؟

در دنیایی که عملکرد، شفافیت و کنترل ارزش بیشتری از سرعت اولیه دارند، شاید وقت آن است که دوباره به SQL خام یا ترکیب آن با ORm فکر کنیم — این بار با بلوغ بیشتر و ابزارهای بهتر.

‍ تولد OpenSearch و قدرت بی‌مثال جامعه متن‌باز

در دنیای نرم‌افزارهای متن‌باز، گاهی تصمیمات تجاری یک شرکت می‌توانند موجی از تغییرات ساختاری در کل اکوسیستم ایجاد کنند. داستان #OpenSearch یکی از بارزترین نمونه‌های این تحولات است؛ نمونه‌ای که نشان می‌دهد چگونه جامعه، با تکیه بر اصول متن‌باز، مسیر خود را از دل یک بحران تعریف می‌کند.

تغییر لایسنس #Elasticsearch: نقطه‌ی آغاز بحران اعتماد

الستیک‌سرچ سال‌ها به‌عنوان یکی از محبوب‌ترین ابزارهای جست‌وجوی متنی و تحلیل داده‌های لاگ شناخته می‌شد. بسیاری از تیم‌های فنی در سراسر جهان، آن را به‌عنوان بخش اصلی زیرساخت‌های observability، جست‌وجو درون‌سیستمی و تحلیل رفتار کاربران به‌کار گرفته بودند.

اما در ژانویه ۲۰۲۱، شرکت Elastic تصمیم گرفت مجوز پروژه را از Apache 2.0 به SSPL تغییر دهد، تصمیمی که عملاً آن را از دایره‌ی پروژه‌های کاملاً متن‌باز خارج کرد. این تغییر، نگرانی‌های جدی درباره آینده توسعه، وابستگی به فروشنده (vendor lock-in) و پایداری بلندمدت این ابزار ایجاد کرد.

⚙️ اپن‌سرچ: پاسخی جامعه‌محور به محدودیت

در واکنش، AWS نسخه ۷.۱۰ Elasticsearch را فورک کرد و پروژه متن‌باز OpenSearch را راه‌اندازی نمود. OpenSearch کاملاً آزاد است، با مجوز Apache 2.0 و سازگار با Elasticsearch 7.10. این پروژه شامل OpenSearch Dashboards به عنوان جایگزین Kibana نیز می‌شود.


امروزه، اپن‌سرچ با حمایت بنیاد لینوکس و مشارکت فعال شرکت‌هایی مانند SAP، Uber، Canonical و ByteDance، به یک پلتفرم متن‌باز واقعی و پایدار تبدیل شده است. این یک نمونه بارز از قدرت جامعه متن‌باز است که توانست پس از بحران، مسیر جدیدی را برای زیرساخت‌های جست‌وجو و تحلیل داده تعریف کند.

🧩 قابلیت‌های متن‌باز در دسترس همه

اپن‌سرچ بسیاری از امکاناتی را که قبلاً صرفاً در نسخه‌های پولی الستیک‌سرچ بود، به‌صورت رایگان و باز در اختیار کاربران قرار می‌دهد:

✅مدیریت چرخه عمر ایندکس‌ها (ISM)

✅قابلیت‌های یادگیری ماشین برای تشخیص ناهنجاری و پیش‌بینی

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

✅ امنیت دقیق سطح ایندکس و کنترل دسترسی

✅پشتیبانی از جست‌وجوی برداری و تحلیل‌های معنایی (نسخه ۳.۰ در سال ۲۰۲۵)

📊 مهاجرت آسان و تاثیر مثبت

تجربه بسیاری از سازمان‌ها نشان می‌دهد مهاجرت از Elasticsearch 7.10 به OpenSearch بدون تغییر کد و با صرف کمترین زمان انجام می‌شود. این مهاجرت علاوه بر کاهش هزینه‌های زیرساختی تا حدود ۳۸٪، عملکرد بهتری مانند افزایش ۲۵٪ سرعت پردازش داده‌ها و کاهش مصرف حافظه را به همراه داشته است.

🚀 چشم‌انداز آینده: همگرایی جست‌وجو، هوش مصنوعی و جامعه

با نسخه ۳.۰ منتشر شده در ۲۰۲۵، OpenSearch علاوه بر امکانات سنتی، پشتیبانی قوی از جست‌وجوی برداری، ترکیب جست‌وجوی متنی و معنایی و یکپارچگی با مدل‌های زبان بزرگ (LLM) را ارائه می‌دهد. این تحولات نشان‌دهنده مسیر رو به رشد پروژه است که جامعه متن‌باز آن را هدایت می‌کند.


📌 جمع‌بندی: متن‌باز یعنی آزادی و پایداری

اپن‌سرچ فراتر از یک جایگزین فنی است؛ این پروژه تجسم قدرت جامعه متن‌باز است که با همکاری و شفافیت توانسته ابزارهایی را فراهم کند که نه تنها رایگان بلکه قابل توسعه و پایدارند.

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

‍ چالش‌های شمارش بازدید در مقیاس بزرگ

نمایش تعداد بازدید یک ویدیو یا محصول در ظاهر کار ساده‌ای‌ست؛ کافی است یک فیلد view_count در دیتابیس داشته باشیم و با هر بازدید، آن را افزایش دهیم. اما هنگامی که:

📌میلیون‌ها کاربر هم‌زمان بازدید ارسال می‌کنند

📌ویدیویی مانند «Baby Shark» با 16 میلیارد بازدید دارید

📌و نیاز دارید آمار را زیر 200ms نمایش دهید

چالش‌های اساسی زیر پیش می‌آید:
⚠️مقیاس‌پذیری (Scalability): ثبت میلیون‌ها رویداد در ثانیه بدون نقطه‌ی گلوگاه

⚠️عملکرد (Latency): پاسخ به کاربر در کمتر از ۲۰۰ میلی‌ثانیه

⚠️تکرارناپذیری (Idempotency): جلوگیری از شمارش یک بازدید بیش از یک‌بار

⚠️ماندگاری داده (Durability): حفظ رویدادها حتی در صورت خرابی سرویس

⚠️دقت نهایی (Accuracy): تضمین دقت آمار با حداکثر تأخیر ۱۰ دقیقه


بیایید روش‌های سنتی پیاده سازی این موضوع را با هم بررسی کنیم :

1️⃣ مدل ساده با یک دیتابیس و فیلد view_count
در ساده‌ترین حالت، یک جدول دیتابیس رابطه‌ای (مثلاً MySQL یا پستگرس) داریم که برای هر آیتم (مثلاً ویدیو) یک ردیف با فیلدی به نام view_count در آن ذخیره شده. با هر بازدید، این فیلد را با یک UPDATE افزایش می‌دهیم.
✅ چرا مناسب است؟
- پیاده‌سازی بسیار ساده
- برای MVP یا پروژه‌های آزمایشی سریع‌ترین راه
❌ محدودیت‌ها
- نقطه‌ی شکست واحد: اگر دیتابیس از کار بیفتد همه‌چیز متوقف می‌شود
- ظرفیت پایین: عدم توان پاسخ‌گویی به صدها هزار درخواست در ثانیه
- بدون کنترل تکراری: هر رفرش صفحه دوباره‌کاری می‌کند

2️⃣ شاردینگ (Sharding) دیتابیس
در این روش، داده‌ها را بین چند دیتابیس (شارد) تقسیم می‌کنیم.
- با کلید video_id % N، هر ویدیو به یکی از N شاردها می‌رسد
- هر آپدیت یا خواندن، تنها به شارد مربوطه هدایت می‌شود

✅ مزایا
- توزیع بار روی چند سرور
- مقیاس‌پذیری خطی با افزایش شاردها

❌ معایب
- هات‌پارتیشن: ویدیوهای وایرال ترافیک بیش از حد به یک شارد می‌فرستند
- خواندن توزیع‌شده: جمع‌آوری آمار از چند شارد پیچیده و کند می‌شود
- همچنان بدون کنترل کامل تکراری

3️⃣ تجمیع در حافظه با Cache
رویدادهای بازدید ابتدا به کش (مثلاً Redis) می‌روند:
- روی هر بازدید، یک کلید یکتا (user_id:video_id) با TTL کوتاه تنظیم می‌کنیم تا تکراری نشمارد
- در حافظه، بازدیدها را جمع می‌کنیم
- هر ۱۰ دقیقه یک بار، مجموع را در دیتابیس اصلی آپدیت می‌کنیم

✅ مزایا
- سرعت بالا: خواندن/نوشتن در حافظه زیر ۱ میلی‌ثانیه
- کاهش بار دیتابیس به دلیل آپدیت گروهی
کنترل تکراری: با TTL در Redis

❌ معایب
- ریسک از دست رفتن داده در صورت کرش سرویس کش
- مدیریت TTL و همگام‌سازی کش با دیتابیس پیچیده

4️⃣ معماری رویدادمحور با Kafka + Flink + Redis
در این معماری، هر بازدید یک رویداد است:
-کافکا: دریافت رویداد و نگهداری آن با پارتیشن‌بندی روی video_id
- فلینک: پردازش جریانی، تجمیع هر ۱۰ دقیقه و ارسال خروجی
- ردیس: نگهداری کلیدهای یکتا برای حذف رویدادهای تکراری
- دیتابیس/Cache: ذخیره‌شماری نهایی برای پاسخ لحظه‌ای

✅ مزایا
- مقیاس‌پذیری افقی بی‌نهایت با Kafka/Flink
- امکان بازیابی کامل رویدادها (Durability)
- کنترل تکراری با Redis
- نمایش زیر ۲۰۰ms با Cache

❌ چالش‌ها
- پیچیدگی عملیاتی: مدیریت خوشه‌های Kafka و Flink
- تأخیر جزئی در لحظه‌های انفجاری (Viral Burst)

🎯 این معماری فقط برای شمارش بازدید ویدیو نیست!
برای لایک، کلیک تبلیغ، بازدید صفحه و حتی شمارنده تعاملات در اپلیکیشن‌های اجتماعی یا فروشگاه‌ها هم کاربرد دارد.

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

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

https://t.iss.one/bigdata_ir/445

به‌طور خلاصه گفتیم که در بار ترافیکی بالا، بهتر است بازدیدها را در حافظه نگهداری و جمع‌بندی کرده، سپس در بازه‌های زمانی مشخص وارد دیتابیس کنیم. همچنین به رویکرد پیشرفته‌تری با Kafka + Flink برای ایجاد بافر و بروزرسانی دوره‌ای دیتابیس اشاره شد.

اما امروز می‌خواهیم به سراغ راهکارهای مدرن‌تر برویم. پیشرفت‌های اخیر در استک‌های داده، امکانات جدیدی برای ما فراهم کرده که فقط محدود به شمارش ساده نیستند.

🎯 هدف ما فقط شمارش نیست!

آنچه امروز اهمیت دارد، ذخیره‌سازی دقیق تمام اکشن‌های کاربر است.

چرا؟

✅برای شخصی‌سازی تجربه کاربری بر اساس رفتار هر فرد

✅برای تحلیل عمیق روی محصولات یا ویدئوها و بهبود تجربه کاربران

پس راهکار ایده‌آل باید هم شمارش و هم ذخیره‌سازی کامل داده‌ها را پوشش دهد.


🛠 سه راهکار مدرن برای شمارش و ذخیره اکشن‌ها

1️⃣ استفاده از Cassandra / ScyllaDB و قابلیت Distributed Counter

🎯برای هر کاربر و هر محصول، یک جدول بازدید ایجاد می‌کنیم

🎯هر اکشن را در هر دو جدول ذخیره می‌کنیم (مدل داده این دیتابیس‌ها بر اساس Query طراحی می‌شود)

🎯شمارش اکشن‌ها با Distributed Counter انجام می‌شود

🎯امکان تعریف شمارنده برای بازه‌های زمانی مختلف (ساعتی، روزانه و...) وجود دارد

✅مزیت اصلی: مقیاس‌پذیری بالا و سرعت فوق‌العاده


2️⃣ ذخیره خام داده‌ها در قالب Apache Iceberg با AutoMQ

🎯جایگزین Kafka سنتی با AutoMQ

🎯 پیام رسان AutoMQ که دقیقا منطبق بر استاندارد کافکا است، پیام‌ها را مستقیماً در Iceberg ذخیره می‌کند

🎯شمارش با Flink + Redis انجام می‌شود

🎯امکان تحلیل بعدی رفتار کاربران با ابزارهایی مثل ClickHouse یا Spark

✅مزیت اصلی: فشار کمتر روی دیتابیس اصلی و نگهداری داده‌های خام برای تحلیل‌های آینده

3️⃣ استفاده از دیتابیس جریانی RisingWave – سریع، مدرن و چندکاره 🚀

دیتابیس RisingWave یک دیتابیس جریانی (Streaming Database) است که با استاندارد PostgreSQL توسعه یافته و از SQL به‌عنوان زبان اصلی پردازش داده‌های جریانی استفاده می‌کند.

📌 ویژگی‌ها و مزایا:

🎯شمارش و پردازش جریانی با SQL ساده → ایجاد Materialized Viewها برای شمارش بازدیدها و اکشن‌ها در لحظه

🎯ذخیره اکشن‌ها در S3 و Iceberg → امکان نگهداری داده‌های خام برای تحلیل‌های آینده

🎯سرعت بالا به لطف Rust → هسته سیستم با زبان Rust نوشته شده و از مزایای کارایی و مصرف کم منابع بهره می‌برد

🎯پشتیبانی از Sinkهای متنوع → خروجی مستقیم به دیتابیس‌ها، سیستم‌های پیام‌رسان، S3، Kafka و...

🎯پردازش رویدادهای پیچیده → اجرای Queryهای تحلیلی پیشرفته بر روی جریان داده بدون نیاز به ابزار جداگانه

✅ نتیجه؟

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

📌 جمع‌بندی

این سه راهکار نسبت به روش‌های سنتی و حتی رویکرد Kafka + Flink، مدرن‌تر هستند و از فناوری‌های جدید حوزه داده بهره می‌برند.

اگر در حال طراحی یا ارتقای بخش شمارش بازدید و اکشن‌ها هستید، پیشنهاد می‌کنم این گزینه‌ها را نیز بررسی کنید.

#DataEngineering #StreamingData #RealTimeAnalytics #Kafka #Flink #Iceberg #ClickHouse #RisingWave #ScyllaDB #BigData #UserAnalytics #TechInnovation #RustLang #SQL