‍ وقتی Excel به ClickHouse متصل می‌شود
در سال‌های اخیر، با رشد تصاعدی حجم داده در شرکت‌های بزرگ ایرانی، زیرساخت‌های سنتی مانند Oracle و SQL Server که سال‌ها نقش ستون فقرات ذخیره‌سازی داده‌ها را داشتند، دیگر پاسخ‌گوی نیازهای تحلیلی جدید نیستند. بسیاری از این سازمان‌ها در گزارش‌گیری و تحلیل داده‌های حجیم دچار کندی محسوس شده‌اند.
در نتیجه، تمایل به سمت استفاده از دیتابیس‌های تحلیلی نوین مانند hashtag#ClickHouse و hashtag#StarRocks افزایش یافته است، فناوری‌هایی که با معماری columnar و توان پردازشی بالا، به‌خوبی برای تحلیل‌های سنگین و بلادرنگ طراحی شده‌اند.
در یکی از مشاوره‌های اخیرم با یکی از فروشگاه‌های زنجیره‌ای بزرگ کشور، در حال بررسی #ClickHouse برای ذخیره و سرویس‌دهی تراکنش‌های روزانه هستیم.

🔥اما چالش اصلی این بود که تیم فنی و کاربران نهایی سال‌ها با استک مایکروسافت کار کرده بودند؛ بیشتر گزارش‌ها از طریق Excel و با استفاده از SSAS و Power Pivot تولید می‌شد. بنابراین به دنبال راهکاری بودیم که بدون تغییر اساسی در محیط گزارش‌گیری کاربران، بتوان از ClickHouse نیز بهره برد.
در این مسیر، به دنبال یک ROLAP Engine بودیم که از MDX پشتیبانی کند و به پروژه‌ای جالب به نام eMondrian رسیدیم.

🔰 پروژه eMondrian در واقع نسخه‌ای توسعه‌یافته از Mondrian OLAP Engine است که امکان اتصال به دیتابیس‌های مدرن از جمله ClickHouse را فراهم می‌کند. با این ابزار می‌توان:
✔️همان مدل چند‌بعدی (Cube) را روی داده‌های ClickHouse تعریف کرد،
✔️همچنان از MDX Query‌ها استفاده نمود،
✔️و حتی گزارش‌ها را مستقیماً از طریق Excel یا Power BI به‌صورت Live Connection مشاهده کرد.
در تست‌های اولیه، سرعت اجرای کوئری‌ها روی داده‌های چندصدمیلیونی بسیار قابل‌قبول بود و ساختار XML‌-محور schema نیز اجازه تعریف دقیق ابعاد و اندازه‌ها را می‌دهد. تنها نکته مهم، نیاز به دقت در طراحی schema است، چرا که برخلاف SSAS در اینجا خبری از Wizard نیست.

✅ مزیت اصلی eMondrian
راه‌حل کم‌هزینه و سریع برای «نگه داشتن لایهٔ گزارش‌گیری فعلی (Excel/MDX)» و در عین حال انتقال داده‌ها به ClickHouse؛ مخصوصاً مناسب برای مهاجرت تدریجی و جلوگیری از بازنویسی کامل داشبوردها.

ریسک‌ها / محدودیت‌ها:
🔴قابلیت‌های کامل SSAS را ندارد، برخی امکانات پیشرفته ممکن است موجود نباشند یا متفاوت اجرا شوند.

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

🔴پروژه هنوز وابسته به به‌روزرسانی‌ها و رفع باگ‌هاست؛ ممکن است نیاز به توسعه یا patch محلی باشد.

🔴طراحی schema و tune کردن ClickHouse برای عملکرد مطلوب حیاتی است، بدون این، ممکن است سرعت یا مصرف منابع مشکل‌ساز شود.

🔴سازگاری کامل با همه نسخه‌های Excel/Power BI سرویس ممکن نیست، بعضی ابزارها رفتار متفاوتی دارند.

در حال حاضر دو نسخه از این موتور موجود است:
🔹 نسخه اصلی Pentaho Mondrian که سال‌هاست در پروژه‌های BI استفاده می‌شود،
🔹 و نسخه توسعه‌یافته eMondrian که برای اتصال به دیتابیس‌های مدرن مانند ClickHouse بهینه‌سازی شده است.
ما در حال تست نسخه دوم هستیم که برای ClickHouse مناسب‌تر است.
اگر تجربه‌ای در استفاده از Mondrian یا eMondrian دارید، به‌ویژه در ترکیب با ClickHouse، خوشحال می‌شویم از تجربه شما هم بتوانیم استفاده کنیم 🙌

‍ چرا Intuit به‌جای ClickHouse، سراغ StarRocks رفت؟

امروزه حجم عظیم داده در بسیاری از شرکت‌ها و سازمان‌های ایرانی، ضرورت استفاده از دیتابیس‌های تحلیلی مدرن را بیش از هر زمان دیگری آشکار کرده است. مجموعه‌هایی که می‌خواهند تحلیل‌های Real-Time، گزارش‌های سریع، داشبوردهای منعطف و زیرساخت داده قابل‌اتکا داشته باشند، ناچارند بین نسل جدید OLAPها، مثل #ClickHouse، #StarRocks یا Apache #Doris انتخاب کنند.

اخیراً تیم IPS در شرکت Intuit (سازنده QuickBooks، TurboTax، CreditKarma و ده‌ها سرویس مالی دیگر) تجربه بسیار جالبی منتشر کرده‌اند.

https://celerdata-com.cdn.ampproject.org/c/s/celerdata.com/blog/how-intuit-achieved-sub-4-second-real-time-analytics-at-100k-events-per-second?hs_amp=true

آن‌ها سالانه ۱۴۰ میلیارد تراکنش پردازش می‌کنند و در پیک کاری به ۱۰۰,۰۰۰ رویداد در ثانیه می‌رسند.

💡 نیاز اصلی‌شان: تاخیر سرتاسری کمتر از ۴ ثانیه برای تغذیه مدل‌های ML و تحلیل رفتار لحظه‌ای کاربران.

در این سطح از Scale و Real-Time، معماری قبلی آن‌ها (Apache Druid) دیگر جوابگو نبود. Intuit چند گزینه را بررسی کرد: ClickHouse، Pinot، DuckDB … اما در نهایت StarRocks را انتخاب کرد.

دلایل انتخاب آنها برای ما - به‌خصوص شرکت‌های ایرانی - کاملاً کاربردی و قابل تعمیم است.

🔥 چرا #StarRocks انتخاب شد؟

1) پشتیبانی Native از Upsert و جداول منطبق بر منطق Primary Key

در معماری‌های Real-Time، داشتن State برای هر کاربر، تراکنش یا session ضروری است.

در کلیک‌هوس، upsert واقعی وجود ندارد و نیاز به workaround‌هایی مثل ReplacingMergeTree یا CollapsingMergeTree است. StarRocks این مشکل را به‌صورت بومی حل کرده.

2) پرفورمنس بسیار قوی روی Multi-Table Join

در سناریوهایی مثل:

✔️ترکیب داده‌های کلیک‌استریم با پروفایل کاربر

✔️عملیات Join بین چند دامنه مختلف (مثلاً محصولات مالی Intuit)

✔️ساخت Featureهای پیچیده ML

کلیک‌هوس به دلیل طراحی column-oriented pure و join planner محدود، در joins سنگین، عقب می‌ماند.

✅ در همین بخش، #StarRocks مزیت قطعی دارد.

3) تاخیر بسیار کم در Query (زیر ۵۰۰ms در TP99)

برای مدل‌های ML که روی آخرین ۳۰ کلیک کاربر تصمیم‌گیری می‌کنند، هر میلی‌ثانیه اهمیت دارد.

دستاورد StarRocks در تست Intuit:

✔️درج صدهزار رکورد در ثانیه

✔️ ۰.۵ ثانیه latency در ۹۹٪ کوئری‌ها

✔️ تازگی داده‌ها : زیر ۱ ثانیه

این سطح از پرفورمنس با ClickHouse سخت‌تر و پرهزینه‌تر است.

4) معماری Shared-Data مشابه Lakehouse با تکیه بر S3

استارراکز می‌تواند:

✔️ جدا کردن Compute از Storage

✔️داشتن چند warehouse مجزا

✔️ قابلیت resource group برای multi-tenancy واقعی

کلیک هوس در نسخه Cloud این مسیر را آغاز کرده، اما اکوسیستم cloud-native StarRocks پخته‌تر است.

5) سادگی عملیاتی (Operational Simplicity)

کلیک‌هوس ابزارهای عملیاتی خوب دارد، اما scale-out پیشرفته نیازمند:

✔️ عملیات sharding دستی

✔️معماری پیچیده ReplicatedMergeTree

✔️ابزارهای جانبی custom

استارراکز این‌ها را تقریباً به‌صورت plug-and-play ارائه می‌کند.

⭐️ جمع‌بندی

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

اگر real-time واقعی، joins سنگین، upsert و latency زیر ۲–۳ ثانیه نیاز دارید، StarRocks انتخاب بسیار مناسب‌تری خواهد بود.

اگر batch analytics با مقیاس بسیار بزرگ دارید، ClickHouse همچنان پادشاه است.

‍ از Kafka تا Iceberg در کمتر از یک دقیقه؛ تجربه عملی AutoMQ
در مدرسه مهندسی داده سپهرام، همیشه تلاش کرده‌ایم جدیدترین فناوری‌های حوزه داده را به‌صورت کاربردی و قابل استفاده در پروژه‌های واقعی ارائه کنیم. در ویدئویی که اخیراً در کانال یوتیوب مدرسه منتشر شده است، به‌صورت کاملاً عملی کار با AutoMQ، جایگزین نوآورانه و cloud-first برای #Kafka و همچنین ذخیره‌سازی مستقیم داده‌های Kafka در Apache Iceberg و کوئری‌گیری آن با #DuckDB را بررسی کرده‌ایم.
این جلسه بخشی از رویکرد ما برای آموزش معماری‌های مدرن داده مانند Lakehouse، Zero-ETL و استریم‌پردازی ابری است.

🔰 اما AutoMQ‌ دقیقا چیست ؟
کتابخانه AutoMQ یک کافکای بازنویسی شده است که مستقیماً بر پایه کدهای Kafka توسعه یافته و تنها لایه ذخیره‌سازی آن بازطراحی شده است. در این معماری، پیام‌ها به جای ذخیره روی دیسک هر بروکر، در یک فضای ذخیره‌سازی خارجی مانند S3 یا MinIO قرار می‌گیرند. این تغییر مهم باعث می‌شود بتوان بروکرهای بدون دیسک داشت، مقیاس‌پذیری را بسیار ساده‌تر کرد و عملیات نگه‌داری را کاهش داد. علاوه بر این، AutoMQ در مدیریت خودکار مقیاس‌پذیری هنگام افزایش حجم داده، عملکردی به‌مراتب بهتر از Kafka سنتی ارائه می‌دهد و همین موضوع آن را به یک گزینه مناسب برای تیم‌های دواپس و محیط‌های با بار سنگین داده تبدیل کرده است

در این ویدئو، مباحث زیر به‌صورت مرحله‌به‌مرحله و عملی ارائه شده است:
✔️آشنایی با معماری AutoMQ و تفاوت آن با Kafka سنتی
✔️راه‌اندازی کامل AutoMQ، MinIO، Iceberg، Schema Registry و DuckDB با Docker Compose
✔️معرفی و تشریح قابلیت AutoMQ Table Topic
✔️ارسال داده Avro از طریق یک Producer پایتونی
✔️ذخیره‌سازی خودکار داده‌ها از Kafka در جداول Iceberg بدون Kafka Connect و بدون Flink/Spark
✔️بررسی قابلیت Zero-ETL در سناریوی واقعی
✔️یکپارچگی Schema Registry و انتقال خودکار اسکیمـا به Iceberg
✔️مشاهده داده‌های ذخیره‌شده در Iceberg و اجرای کوئری‌های تحلیلی با DuckDB
✔️بررسی قابلیت Time Travel، تکامل اسکیمـا (Schema Evolution) و Partitioning
✔️نکات مهم برای استقرار AutoMQ در محیط Production و تنظیمات پیشنهادی

برای مشاهده این آموزش کاربردی می‌توانید ویدئو را در کانال یوتیوب مدرسه مشاهده کنید:
🎥 پیوند ویدئو:
https://lnkd.in/d4ZHK4n8
#Kafka #ApacheIceberg #AutoMQ #DataEngineering #DataPipeline #ZeroETL #DuckDB #Lakehouse

‍ فراتر از Kafka: معماری و مقیاس‌پذیری واقعی با Pulsar

سال‌هاست در حوزه زیرساخت و مهندسی داده با سامانه‌های پیام‌رسانی مختلف مثل Kafka, NATS و RabbitMQ کار کرده‌ام. بارها نام Apache Pulsar را شنیده بودم، حتی از حدود ده سال پیش، اما چون ابزارهای فعلی نیازهای ما را پوشش می‌دادند، سمتش نرفتم.

برای دوره Kafka در مدرسه مهندسی داده سپهرام فرصتی شد تا مستندات Pulsar را دقیق مطالعه و محیط آن را عملی بالا بیاورم و چندین مثال واقعی اجرا کنم. واقعاً باید به دوراندیشی و معماری فوق‌العاده تیم یاهو برای رفع ضعف‌های Kafka تحسین گفت: پایداری، چابکی، مقیاس‌پذیری، چنداجاره‌ای واقعی و مدیریت عملیاتی ساده‌تر.

اگر شما هم در سازمان متوسط یا بزرگی Kafka استفاده می‌کنید، پیشنهاد می‌کنم Pulsar را جدی بررسی کنید؛ پروژه‌ای قدیمی، battle-tested و محبوب در شرکت‌های بزرگ دنیا.

چند قابلیت کلیدی Pulsar:

✔️ مدل پردازش جریان و پیام‌رسانی: هم Streaming مشابه Kafka و هم Messaging شبیه RabbitMQ، برای مدیریت داده‌های جریان بالا و پردازش رویداد محور.

✔️ جداسازی Compute از Storage (Apache BookKeeper): پولسار معماری خود را به گونه‌ای طراحی کرده که بخش پردازش پیام‌ها (Brokers) و ذخیره‌سازی داده‌ها (Bookies) کاملاً جدا هستند. این جداسازی باعث می‌شود مقیاس‌پذیری بسیار ساده‌تر باشد، می‌توان به راحتی بروکرها یا بوکی‌ها را بدون تأثیر روی هم افزایش یا کاهش داد، و کنترل کلاستر و مدیریت منابع در بارهای سنگین بسیار مؤثرتر شود. این معماری همچنین به پایداری و تحمل خطای بالاتر در سازمان‌های بزرگ کمک می‌کند.

✔️ چنداجاره‌ای و تعریف Workspace: ایجاد tenant و namespace برای تیم‌ها، با میلیون‌ها topic و مدیریت ساده سرویس‌های اشتراکی

✔️ مقیاس‌پذیری و Elasticity دینامیک: مصرف منابع متناسب با بار، افزودن consumer و افزایش throughput بدون توقف سیستم.

✔️ مدل‌های متنوع مصرف پیام: Shared، Key_Shared، Exclusive و Failover برای سناریوهای پیچیده در مقابل مدل ساده Consumer Group کافکا.

✔️ تکرار جغرافیایی (Geo-Replication): همگام‌سازی پیام‌ها بین چند کلاستر بدون پیچیدگی بدون نیاز به Mirror-Maker یا ابزارهای دیگر .

✔️ مدیریت اسکیما و پردازش سبک: Schema Registry داخلی و Pulsar Functions برای پردازش‌های سبک روی پیام‌‌ها

✔️ هماهنگی با پروتکل‌ها و سیستم‌های موجود: KoP برای کافکا یعنی می‌توانید همان تجربه کافکا را برای سرویس‌های فعلی با پولسار هم فراهم‌ کنید، Starlight برای RabbitMQ و پشتیبانی از MQTT و AMQP.

✔️ امکان Offloading به Cloud Storage: انتقال Ledgerها به S3 یا سایر سرویس‌های ابری، کاهش هزینه و نگهداری آسان.

✔️ تحلیل داده: Pulsar SQL و Trino Integration برای اجرای کوئری و تحلیل بدون استخراج داده.

✔️ ابزارهای مدیریت و پایش: Pulsar Manager، مانیتورینگ، delayed messages و dead-letter queues.

و نکتهٔ تکمیلی: Pulsar توسط شرکت‌های بزرگی مثل Tencent, Verizon Media, Splunk, Comcast, Yahoo/Japan, Overstock, Nutanix و بسیاری دیگر استفاده می‌شود. پروژه کاملاً فعال است، با صدها مشارکت‌کننده، هزاران ستاره در GitHub و اکوسیستمی بالغ و قابل اتکا برای سازمان‌های بزرگ.

اگر سازمان شما هم در سطح متوسط یا بزرگ از Kafka استفاده می‌کند، ارزش دارد Pulsar را به‌عنوان گزینهٔ بعدی یا مکمل جدی بررسی کنید.

معرفی یکی از پروژه‌های عملی دوره مهندسی داده سپهرام

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

امروز خوشحالیم یکی از پروژه‌های ارزشمند خروجی دوره مبانی مهندسی داده را معرفی کنیم؛ پروژه‌ای که توسط محمد ابراهیمی عزیز توسعه داده شده و در ریپوی زیر قابل مشاهده است:

🔗 https://github.com/MohamadDesign/basic_dataengineer

🔍 این پروژه چیست و چه کاری انجام می‌دهد؟

این ریپو یک نمونه‌ی کاملاً عملی از ساخت یک پایپ‌لاین داده کامل از مبدا داده‌ها تا بصری‌سازی و گزارشات (End-to-End Data Pipeline) است که مخاطب دوره را با مفاهیم بنیادین مهندسی داده به‌صورت کاربردی آشنا می‌کند. هنرجو در این پروژه تجربه می‌کند که داده چگونه تولید، منتقل، پردازش و در نهایت تحلیل می‌شود؛ فرآیندی که در مهندسی داده واقعی هر روز اتفاق می‌افتد.

🏗 معماری پروژه و جریان داده

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

جریان داده در این پروژه به شکل زیر است:

1) تولید داده کاربران

- داده‌های تصادفی شامل نام، کشور و زمان ثبت‌نام تولید می‌شوند.

- این داده‌ها ابتدا در PostgreSQL ذخیره می‌شوند.

- این مرحله معمولاً از طریق یک DAG در Apache Airflow یا یک اسکریپت پایتون مدیریت می‌شود.

2) انتقال داده به Kafka

- یک DAG دیگر در Airflow داده‌ها را از Postgres خوانده و به یک Topic در Apache Kafka ارسال می‌کند.

- کافکا در این معماری نقش Message Broker را ایفا می‌کند و امکان انتقال صفی و استریمی داده‌ها را فراهم می‌سازد.

3) پردازش و ذخیره‌سازی نهایی

- داده‌ها از Kafka توسط یک ابزار پردازشی مثل Logstash خوانده می‌شوند.

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

4) بصری‌سازی و تحلیل

- داده‌های ذخیره‌شده در Elasticsearch در Kibana ویژوالایز می‌شوند.

- داشبوردهایی مانند توزیع کاربران، روند ثبت‌نام، و تحلیل‌های زمانی در این بخش قابل ساخت هستند.

در یک نگاه کلی، هنرجو با چرخه واقعی یک Data Pipeline شامل Extract → Transform → Load → Analyze آشنا می‌شود؛ چرخه‌ای که هسته‌ی اصلی مهندسی داده در صنعت است.

✨ سخن پایانی

دیدن چنین پروژه‌هایی از سمت هنرجویان، برای ما در سپهرام بسیار ارزشمند است؛ چون نشان می‌دهد مسیر آموزش دقیقاً با نیازهای روز صنعت مهندسی داده همسو شده و خروجی‌ها به مهارت واقعی منجر شده‌اند.

برای محمد ابراهیمی عزیز آرزوی موفقیت داریم و امیدواریم این پروژه‌ها الهام‌بخش قدم‌های بعدی علاقه‌مندان به دنیای داده باشد. 🚀

توضیح پروژه فوق توسط محمد ابراهیمی عزیز .

‍ چرا Iggy مهم است؟ بررسی یک پروژه Rust-محور در دنیای پردازش جریان

امروزه در بنیاد Apache مجموعه‌ای بزرگ از سامانه‌های پیام‌رسان و پردازش جریان داریم: از Kafka و Pulsar تا RocketMQ، ActiveMQ و حالا تازه‌ترین عضو این خانواده یعنی Apache Iggy.

بیایید ببینیم چرا پروژه‌های جدیدتر، به‌ویژه آن‌هایی که با Rust ساخته شده‌اند، اهمیت بیشتری پیدا کرده‌اند.

⚡️ موج جدید: سیستم‌هایی که با Rust بازنویسی می‌شوند

امروز بسیاری از سیستم‌های پردازش داده یا کاملاً با Rust نوشته می‌شوند یا بخش‌های کلیدی خود را برای بهبود کارایی با #Rust بازنویسی می‌کنند.

نمونه‌ها: Polars، DataFusion، Ballista و پروژه‌های نوین در حوزه AI. در همین مسیر، Apache Iggy یک عضو تازه و جاه‌طلب در اکوسیستم Apache است.


🚀 پروژه Apache Iggy؛ نسل جدید پیام‌رسان‌های سریع

اگر با Kafka، Flink یا RocketMQ کار کرده باشید، می‌دانید سیستم‌های پیام‌رسان چه نقش مهمی در جریان داده دارند. Iggy تازه‌ترین عضو این خانواده است؛ مدرن، سبک و ساخته‌شده با Rust.

🔄 چرا Iggy مهم شده؟

دنیا «جریانی» شده است:

💳 پرداخت آنلاین → جریان رویداد

🌡 اینترنت اشیاء یا IoT → جریان داده

🧠 هوش مصنوعی و AI → ورودی لحظه‌ای

⭐️ توصیه‌گرها → رفتار زنده کاربران

ابزارهای قدیمی‌تر (عمدتاً Java) قدرتمندند، اما همیشه برای تأخیر بسیار کم یا پرفورمنس شدیداً بالا مناسب نیستند؛ جایی که Rust و سپس Iggy وارد میدان می‌شوند.

🧩 پروژه Iggy دقیقا چیست؟

پیام‌رسانی فوق سریع، مینیمال و مدرن که می‌تواند میلیون‌ها پیام در ثانیه را با کمترین تأخیر مدیریت کند.

⭐️ مزیت‌های کلیدی Iggy

⚡️ سرعت بسیار بالا (io_uring + معماری هر هسته یک نخ)

⚡️ پایداری و قابلیت Replay

⚡️ چندزبانه (Rust، Go، Java، Python، Node.js، ...)

⚡️ امنیت داخلی (Auth، ACL، Encryption)

⚡️ آماده برای آینده (پروتکل MCP برای اتصال مستقیم به مدل‌های AI)


🏛 چرا وارد بنیاد Apache شد؟

⚡️ اعتماد و حاکمیت متن‌باز

⚡️ جامعه توسعه گسترده‌تر

⚡️ مسیر رشد پایدار برای امکانات سازمانی


🧭 جایگاه Iggy در کنار دیگر پیام‌رسان‌ها

کتابخانه Iggy یک پیام‌رسان نسل جدید و پلتفرم پردازش جریان است؛ یعنی دقیقاً در همان جایگاهی قرار می‌گیرد که ابزارهایی مانند Kafka و RabbitMQ سال‌ها بازیگران اصلی آن بوده‌اند.

اگر برای شما انتقال پیام با سرعت بسیار بالا در یک کلاستر توزیع‌شده اهمیت دارد و به دنبال سیستمی هستید که با طراحی مدرن ساخته شده و مفاهیمی مانند MCP و عامل‌های هوشمند (Intelligent Agents) را نیز در معماری خود لحاظ کرده باشد،

پروژه Iggy یک موتور تازه‌نفس و فوق‌العاده کارآمد برای چنین نیازهایی است.


🔄 می‌تواند جایگزین چه ابزارهایی باشد؟

🚀 کافکا→ برای سناریوهای سبک‌تر با نیاز به latency بسیار پایین

🐇 کتابخانه RabbitMQ → برای تحویل پیام سریع با معماری ساده‌تر

📩 پروژه قدیمی و کلاسیک ActiveMQ → جایگزین مدرن‌تر برای سناریوهای JMS‌ گونه

☁️ پروژه پیام‌‌رسان علی‌بابا : RocketMQ → در کاربردهای Cloud-native که ساختار ساده‌تری می‌خواهید



🏁 جمع‌بندی

ایگی Iggy تنها یک ابزار جدید نیست؛ نشانه‌ای از نسل تازه‌ای از سیستم‌های Real-time است. نسلی:

⚡️ سریع‌تر

🔐 ایمن‌تر

🤖 هماهنگ‌تر با AI

🔋 کم‌مصرف‌تر

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


کانال مدرسه مهندسی داده سپهرام : @sepahram_school

‍ چرا باید به Schema Registryهای متن‌باز فکر کنیم؟ نگاهی به Karapace

در Kafka، پیام‌ها به شکل بایت‌های سریال‌شده منتقل می‌شوند. تولیدکننده پیام را می‌فرستد و فرض می‌کند مصرف‌کننده می‌داند چگونه آن را دی‌سریالایز (بازخوانی) کند.
اما در پیاده‌سازی‌های واقعی:
✔️ چندین تیم روی یک کلاستر کار می‌کنند
✔️ سرویس‌ها مستقل منتشر و به‌روزرسانی می‌شوند
✔️ تغییرات اسکیما همیشه خطرناک‌اند
✔️ مصرف‌کننده‌ها ممکن است حتی بیرون از سازمان ساخته شده باشند

به همین دلیل، وجود یک Schema Registry مرکزی ضروری است تا:
🔰 مصرف‌کننده و تولیدکننده از هم جدا شوند (Decoupling)
🔰 نسخه‌بندی و تکامل اسکیما ایمن شود
🔰 سازگاری قبل از هر تغییر چک شود
🔰 جریان‌های داده قابل اعتماد و پایدار بمانند

چرا به دنبال جایگزین Confluent Schema Registry باشیم؟

اگرچه Confluent Schema Registry استاندارد رایج است، اما:
🔰 امکانات پیشرفته در نسخه‌های پولی
🔰 وابستگی شدید به Confluent Stack
🔰 استفاده از Kafka فقط به‌عنوان Backend
🔰 عدم وجود یک REST Proxy یکپارچه

به همین دلیل، بسیاری از تیم‌ها به‌دنبال گزینه‌های سبک‌تر، متن‌باز و بدون Vendor Lock-in هستند.

کتابخانه‌ Karapace : بهترین Drop-In Replacement سبک و کامل برای Kafka
کاراپیس Karapace یکی از محبوب‌ترین انتخاب‌هاست چون دقیقاً برای جایگزینی Confluent ساخته شده است،
بدون اینکه لازم باشد حتی یک خط کد را تغییر دهید.

🔥 چرا Karapace یک انتخاب حرفه‌ای است؟

✔️ یک Drop-in Replacement واقعی برای Schema Registry و Kafka REST Proxy

✔️ سازگاری کامل با APIها و کلاینت‌های Confluent

✔️ پشتیبانی از Avro، JSON Schema، Protobuf

✔️ معماری Async و بسیار سبک مبتنی بر aiohttp

✔️ مصرف حافظه پایین و استقرار ساده

✔️ امکان Leader/Replica برای HA و Load Balancing

✔️ قابلیت Observability کامل با Metrics و OpenTelemetry

✔️ استفاده از aiokafka (rdkafka) برای عملکرد بالا

✔️ و Schema Registry مبتنی بر FastAPI - سریع و مدرن


🔥 نتیجه: یک انتخاب ایده‌آل برای تیم‌هایی که می‌خواهند بدون دردسر از Confluent جدا شوند اما همان API و همان Behavior را داشته باشند.

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

اگر نیاز دارید علاوه بر پیام‌های Kafka، انواع API Spec و Artifact دیگر را هم مدیریت کنید، Apicurio انتخاب بهتری است:

✔️ پشتیبانی از Avro / Protobuf / JSON Schema و همچنین OpenAPI، AsyncAPI، GraphQL

✔️ قوانین قابل تنظیم برای اعتبار، سازگاری و تکامل اسکیما

✔️ پشتیبانی از ذخیره‌سازی روی Kafka یا دیتابیس‌هایی مثل PostgreSQL

✔️ حاوی یک استودیو برای طراحی API

🔰 نکته: Apicurio جایگزین یک‌به‌یک Confluent نیست و بیشتر یک API & Schema Registry چندمنظوره است.

جمع‌بندی

✔️ اگر هدف شما جایگزینی مستقیم Confluent Schema Registry + REST Proxy است → Karapace بهترین انتخاب شماست.

✔️ اگر می‌خواهید انواع مختلف Artifact و API Spec را در یک پلتفرم مدیریت کنید → Apicurio گزینه منعطف‌تری است.

‍ وقتی حجم داده ورودی به ClickHouse بالا می‌رود، مشکل اصلی CPU نیست: Write Amplification است!
ترکیب Apache Flink به‌عنوان یک موتور پردازش جریانی Stateful و قابل اتکا و استفاده از درج زمان‌بندی‌شده (Batch Inserts) در ClickHouse می‌تواند به‌طرز چشمگیری عملکرد سیستم شما را متحول کند.

اگر با ClickHouse کار کرده باشید می‌دانید که هر INSERT یک Part جدید ایجاد می‌کند و این Partها پشت‌صحنه مرتب ادغام (Merge) می‌شوند.
بنابراین هرچه تعداد INSERT کمتر اما حجیم‌تر باشد، بار Merge-Tree کمتر شده و کارایی به شکل محسوسی افزایش می‌یابد.

در سناریوهای پرترافیک، نوشتن رکورد به‌ازای هر پیام، به‌معنای فشار شدید روی دیسک و CPU است. اینجاست که Flink در نقش یک موتور پردازش جریان + مدیریت State + تجمیع هوشمند وارد می‌شود

🔎 بیایید این پست لینکدین را با هم واکاوی کنیم

پست اصلی: https://www.linkedin.com/posts/vijay-vishnu-7ab184337_apacheflink-databaseoptimization-streamprocessing-activity-7398355140300349440-svd2

در این مثال، داده ورودی ۱ میلیون رویداد در ثانیه بوده و به‌جای اینکه هر رویداد یک INSERT باشد، نویسنده از Flink برای تجمیع یک‌دقیقه‌ای (Tumbling Window) استفاده کرده است. نتیجه؟
به‌جای ۶۰ میلیون INSERT در دقیقه، تنها ۶۰ هزار INSERT اتفاق می‌افتد — یعنی حدود ۹۹.۹٪ کاهش عملیات نوشتن!

🔥 چرا این معماری (Flink + ClickHouse) مؤثر است؟

۱) کاهش چشمگیر عملیات نوشتن
⚡️فلینک رویدادها را در پنجره‌های زمانی جمع و تبدیل به Batchهای بزرگ می‌کند.
⚡️این کار write amplification را کاهش داده و MergeTree را سبک می‌کند.

۲) صرفه‌جویی جدی در منابع پایگاه‌داده : وقتی تعداد INSERT کم شود

⚡️ فشار IO کم می‌شود
⚡️ کوئری‌های read سریع‌تر می‌شوند
⚡️ کلیک‌هوس ظرفیت بیشتری برای تحلیل دارد

۳) پایداری و اعتبار داده : Flink با checkpointing و exactly-once تضمین می‌کند

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

۴) زمان‌بندی و پنجره‌بندی هوشمند : پنجره‌های زمانی (مثلاً ۶۰ ثانیه‌ای):

⚡️داده را برای ذخیره‌سازی بهینه می‌کند
⚡️امکان محاسبه min/max/avg/count را فراهم می‌سازد
⚡️دیتابیس را سبک و گزارش‌ها را سریع می‌کند

۵) نگهداری داده خام در Object Storage : رویدادهای خام در S3 / MinIO ذخیره می‌شوند:

⚡️بدون فشار به ClickHouse
⚡️هر زمان لازم شد می‌توانیم Replay یا تحلیل تاریخی انجام دهیم

۶) مقیاس‌پذیری بالا با هزینه کمتر

وقتی نوشتن ۹۹٪ کاهش یابد:
⚡️تعداد نودهای ClickHouse کمتر می‌شود
⚡️هزینه‌ها کاهش می‌یابد
⚡️توان سیستم برای ترافیک بالاتر افزایش پیدا می‌کند

🧠 جمع‌بندی
اگر جریان ورود رخدادهای و داده‌های شما سنگین است و ClickHouse با «Partهای زیاد» مشکل دارد، بهترین کار این است که:

🔰خام را در object storage نگه دارید (یا لیک‌هوس)
🔰تجمیع‌شده را در ClickHouse بنویسید
🔰 با Flink پنجره‌بندی و Stateful Aggregation انجام دهید

‍ پیشنهاد ویژه Black Friday – مدرسه مهندسی داده سپهرام

به مناسبت Black Friday، امکان استفاده از ۴۰٪ تخفیف برای تمامی دوره‌های مدرسه مهندسی داده سپهرام فراهم شده است.

تنها کافی است هنگام خرید دوره، کد BLK1404 را وارد کنید.

در این کمپین، تمام دوره‌ها شامل این تخفیف می‌شوند:

🔰مبانی مهندسی داده

🔰 آپاچی کافکا

🔰آپاچی اسپارک ( از این هفته شروع می‌شود)

🔰 آپاچی ایرفلو

🔰 پستگرس

🔰 کلیک‌هوس

فهرست تمامی دوره‌ها:
https://sepahram.ir/courses/

اگر قصد ارتقای مهارت‌های فنی، ورود به دنیای مهندسی داده یا رشد شغلی دارید، این فرصت را از دست ندهید.

⏳ اعتبار: محدود و ویژه Black Friday (تا دهم آذرماه)

🎟 کد تخفیف: BLK1404

برای اطلاعات بیشتر و ثبت‌نام: https://t.iss.one/sepahram_ir