‍ وقتی Kafka ساده‌تر، سریع‌تر و سبک‌تر می‌شود: آشنایی با Redpanda در دوره تخصصی کافکا 🎥

در بخش تازه‌ای از دوره آموزش تخصصی کافکا در مدرسه مهندسی داده سپهرام، با یکی از جایگزین‌های قدرتمند و مدرن Kafka یعنی Redpanda آشنا می‌شویم.

در این ویدیو که به‌صورت کارگاهی و کاملاً عملی برگزار شده است، مراحل زیر را گام‌به‌گام انجام می‌دهیم 👇

🔹 راه‌اندازی یک کلاستر تک‌نودی از Redpanda به همراه Redpanda Console

🔹 اجرای دو رابط کاربری معروف دنیای Kafka یعنی AKHQ و Kafka-UI (Kafbat) و بررسی سازگاری کامل آن‌ها با Redpanda

🔹 کار با ابزار خط فرمان rpk برای مدیریت کلاستر و پیکربندی‌ها

🔹 ساخت یک پایپ‌لاین واقعی با Redpanda Connect و زبان Bloblang برای پردازش فایل‌های CSV

🔹 و در نهایت، اجرای PostgreSQL CDC با استفاده از Kafka Connect + Debezium برای همگام‌سازی بلادرنگ داده‌ها

این بخش از دوره، دیدی جامع از توانایی‌های Redpanda در دنیای استریم دیتا و جایگاه آن در اکوسیستم Kafka ارائه می‌دهد.

📺 ویدیو کامل این کارگاه را می‌توانید از طریق لینک زیر در یوتیوب مشاهده کنید:

👉 🔗 https://youtu.be/nu_L4OSRUZc

🎓 این ویدیو بخشی از دوره آموزش تخصصی Kafka از مدرسه مهندسی داده سپهرام (Sepahram) است.

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

🌐 https://sepahram.ir/courses/

📢 کانال رسمی سپهرام در تلگرام:

📬 https://t.iss.one/sepahram_school

🔖 #Kafka #Redpanda #StreamingData #DataEngineering #Debezium #PostgreSQL #KafkaConnect #RealTimeData #Sepahram #مدرسه_مهندسی_داده #کافکا #داده_جاری #مهندسی_داده

‍ وقتی SQL هم حلقه For دارد! نگاهی به Lateral Join در PostgreSQL

اگر در حوزه نرم‌افزار، تحلیل داده یا دیتابیس کار می‌کنید، احتمالاً با انواع JOIN‌های معمول در SQL مثل INNER JOIN و LEFT JOIN آشنا هستید.

اما یکی از جوین‌هایی که کمتر درباره‌اش صحبت می‌شود و در عین حال بسیار مفید و کاربردی محسوب می‌شود، LATERAL JOIN است.

بیایید با یک مثال شروع کنیم 👇

فرض کنید یک جدول از محصولات دارید و می‌خواهید برای هر محصول، آمارهایی مثل:

🔰 مجموع کل فروش،

🔰حجم فروش،

🔰تعداد مشتریان منحصربه‌فرد،

🔰و میانگین فروش

در سه ماه گذشته را به‌دست آورید (به تفکیک ماه).

اگر بخواهید این کار را با زبان‌هایی مثل Python یا JavaScript انجام دهید، معمولاً یک حلقه (for) روی تمام محصولات اجرا می‌کنید و درون آن، برای هر محصول، محاسبات آماری مربوط به فروش را انجام می‌دهید.

در واقع، یک حلقه بیرونی برای محصولات و یک حلقه داخلی برای فروش‌های هر محصول دارید. در SQL هم می‌توان دقیقاً همین رفتار را شبیه‌سازی کرد: با استفاده از LATERAL JOIN.

اینجاست که Lateral مثل یک پل ارتباطی عمل می‌کند:

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

به همین دلیل معمولاً از CROSS JOIN LATERAL استفاده می‌کنیم، چون شرط اتصال درون زیرکوئری و با WHERE تعریف می‌شود و در اینجا Inner Join معنا نخواهد داشت.

💫 نتیجه این رهیافت

می‌توانید به‌سادگی کوئری‌هایی بنویسید که مثلاً:

🌟 «ده محصول پرفروش هر کتگوری» را پیدا کند،

🌟یا برای هر مشتری، آخرین تراکنش ثبت‌شده‌اش را نمایش دهد،

🌟یا حتی تحلیل‌های زمانی و Top-N را مستقیماً داخل SQL انجام دهد: بدون نیاز به کدهای پیچیده و توابع پنجره‌ای


🎥 برای آشنایی دقیق‌تر با این مفهوم، یک ویدئوی آموزشی حدود ۴۰ دقیقه‌ای آماده کرده‌ام که در آن، با مثال‌های واقعی و کاربردی نحوه‌ی استفاده از LATERAL JOIN را گام‌به‌گام توضیح داده‌ام.

🔗 لینک مشاهده ویدئو در یوتیوب:

👉 https://youtu.be/vVc2EewTSQU


💡 در این ویدئو یاد موارد زیر را به صورت عملی مرور می‌کنیم:

✅ایده‌ی اصلی و کاربرد LATERAL JOIN

✅تفاوت آن با جوین‌های معمول

✅نوشتن کوئری‌های Top-N per Group

✅تحلیل داده‌های واقعی (مشتریان، فروش، زمان)

✅و نکات مهم برای بهینه‌سازی عملکرد کوئری


📚 این ویدئو بخشی از دوره‌ی PostgreSQL Practical Course در مدرسه مهندسی داده سپهرام است.

👉 https://sepahram.ir/courses


#PostgreSQL #SQL #DataEngineering #Database #LateralJoin #Sepahram #BigData #PostgresTutorial #Analytics

‍ 🔹 نگاهی به معماری چرخش به چپ در طراحی سامانه‌های بلادرنگ مقیاس‌پذیر
  پردازش جریانی (Streaming)، چارچوب‌ها و دیتابیس‌های بلادرنگ، بخش جدایی‌ناپذیر از زیرساخت داده مدرن هستند و مرز بین پردازش دسته‌‌ای و پردازش جریانی در حال محو شدن است یعنی حتی پردازش دسته ای را هم میتوانیم نوع خاصی از پردازش جریانی در نظر بگیریم .
از Kafka و Pulsar گرفته تا Flink و اسپارک، همه به ما یاد داده‌اند که داده‌ها را می‌توان همان لحظه‌ای که تولید می‌شوند، تحلیل و استفاده کرد.
اما در عمل، هنوز بسیاری از سازمان‌ها با ذهنیت قدیمی کار می‌کنند:

عادت کرده‌ایم داده را ابتدا ذخیره کنیم و بعد پردازش کنیم.
فرآیندهای ETL اغلب در انتهای شب یا ابتدای صبح اجرا می‌شوند تا داده‌ها را برای گزارش‌های فردا آماده کنند.

به زبان ساده، هنوز داده را مثل «کالا» می‌بینیم که باید در انبار (Data Lake / Warehouse) جمع شود و بعداً مصرف گردد.
💡 مفهوم جدید: چرخش به چپ (Shift Left)
مدتی است در ادبیات داده، مفهومی تازه مطرح شده به نام «چرخش به چپ» (Shift Left) - دعوتی برای تغییر همین چارچوب ذهنی.
ایده‌اش ساده ولی کاربردی است:
بیایید داده را مثل جریان آب ببینیم، نه کالا.
آن را همان لحظه ورود، تصفیه، غنی‌سازی و مصرف کنیم.
در این رویکرد، پردازش داده به‌جای انتهای زنجیره (در انبار یا Lakehouse)،
به ابتدای مسیر - یعنی نزدیک به محل تولید داده - منتقل می‌شود.
برای مثال:
در یک بانک، تراکنش مشکوک به تقلب همان لحظه شناسایی و مسدود می‌شود.
در یک فروشگاه آنلاین، تغییر رفتار کاربر بلافاصله در موتور پیشنهاددهنده تأثیر می‌گذارد.
⚙️ معماری Shift Left در عمل چگونه کار می‌کند؟
در معماری Shift Left، ما پردازش را به لبه‌ی جریان داده منتقل می‌کنیم -
اما همچنان داده‌ها را در مراحل مختلف در Lakehouse (مثل Iceberg) ذخیره می‌کنیم تا تاریخچه و تداوم داده حفظ شود.
مراحل پیشنهادی برای پیاده‌سازی:
- کافکا یا Pulsar را به‌عنوان لایه‌ی اصلی جریان داده در نظر بگیرید.
همه‌ی رویدادهای اپلیکیشن‌ها از این مسیر عبور می‌کنند.
- فلینک یا Spark Streaming را برای پردازش لحظه‌ای داده به‌کار بگیرید.
این لایه داده‌ها را در حین عبور، پالایش و غنی‌سازی می‌کند.
- خروجی جریان را هم‌زمان به دو مقصد بفرستید:
یک مسیر برای مصرف بلادرنگ (مانند API، موتور تصمیم‌گیری، مانیتورینگ)،
و یک مسیر برای ذخیره‌سازی تحلیلی در Iceberg.
در Iceberg داده‌ها را در سه لایه نگهدارید تا هم داده‌ی خام و هم پردازش‌شده قابل دسترس باشد:
🔸 لایه برنز :
داده‌های خام (Raw) مستقیماً از Kafka یا CDC Stream.
🔸  لایه نقره :
داده‌های پاک‌سازی‌شده و استانداردشده - خروجی Jobهای Flink یا Spark.
🔸  لایه طلا:
داده‌های تجمیع‌شده و تحلیلی، آماده برای BI، ML یا گزارش‌ها.
هر سه لایه در Iceberg ذخیره می‌شوند تا بتوانید با قابلیت‌هایی مانند نسخه‌بندی، Snapshot، و Schema Evolution، داده را از هر مرحله بازیابی کنید.
در Flink می‌توانید Sinkهای همزمان (Dual Sink) تعریف کنید:
یکی برای Iceberg و دیگری برای سامانه‌های بلادرنگ مثل Elastic، Redis یا Kafka Topic دیگر.
🚀 نتیجه
با این الگو، داده از لحظه‌ی تولید،
هم برای تحلیل و تصمیم‌گیری در لحظه در دسترس است،
و هم در لایه‌های ساختارمند Iceberg برای تحلیل تاریخی و یادگیری ماشین ذخیره می‌شود.

‍ کار با جداول بزرگ در PostgreSQL: همه چیز درباره پارتیشنینگ و کاربردهایش

در ادامه دوره #Postgres in Action و بخش کار با دیتابیس‌های بزرگ، به یکی از مهم‌ترین مباحث PostgreSQL یعنی پارتیشنینگ جداول (Table Partitioning) پرداختیم.

🌟 اما اصلاً پارتیشنینگ چیست و چرا باید از آن استفاده کنیم؟

پارتیشنینگ یعنی تقسیم یک جدول بزرگ به چند زیرجدول کوچکتر و قابل مدیریت بر اساس یک قاعده مشخص (مثل تاریخ، کشور یا شناسه).

مزایای اصلی آن شامل:

🚀 افزایش سرعت کوئری‌ها: کوئری‌ها فقط روی پارتیشن‌های مرتبط اجرا می‌شوند و زمان پاسخ کاهش می‌یابد.

🛠 سهولت نگهداری: داده‌های قدیمی یا آرشیو را راحت‌تر مدیریت و حذف می‌کنیم.

📊 بهینه‌سازی ایندکس‌ها و منابع: حجم هر پارتیشن کمتر است و ایندکس‌ها کارایی بهتری دارند.

در این ویدئوی نیم‌ساعته، که بخش مفاهیم پایه پارتیشنینگ را پوشش می‌دهد، مطالب زیر مرور شد:

📌 مباحث مطرح‌شده:

✅مفهوم پارتیشنینگ و نقش آن در مدیریت داده‌های بزرگ

✅انواع پارتیشنینگ در پستگرس: List، Range و Hash

✅پارتیشن‌بندی ترکیبی (Composite Partitioning) برای سناریوهای پیچیده

✅جدول اصلی به عنوان روتر/پروکسی و نحوه تعامل آن با پارتیشن‌ها

✅فرآیند Partition Pruning برای بهینه‌سازی کوئری‌ها

✅استفاده از Partition By Expression برای کنترل کامل روی پارتیشن‌بندی

✅دستورات Attach و Detach و مدیریت پارتیشن‌ها


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

📺 مشاهده ویدئو: https://youtu.be/gs2Rnp2kAOg

📚 برای مشاهده سایر ویدئوهای مدرسه مهندسی داده سپهرام:

🌐 https://sepahram.ir/courses/

کانال مهندسی داده: https://t.iss.one/bigdata_ir

نگاهی به اهمیت پشتیبانی DuckDB از ٰVortex و شروع رواج نسل جدید فرمت‌های ذخیره داده
سال‌ها Apache Parquet استاندارد اصلی برای ذخیره‌سازی داده‌های خام بوده است؛ فرمتی که داده‌ها را به‌صورت فشرده، ستون‌محور و آماده برای تحلیل و پردازش‌های سنگین ذخیره می‌کند و عملاً ستون فقرات بسیاری از پلتفرم‌های تحلیلی بخصوص در حوزه hashtag#Lakehouse به شمار می‌رود.

اما در سال‌های اخیر، نیازهای جدیدی مانند بازیابی سریع ویژگی‌ها در هوش مصنوعی، جستجوی برداری، اسکورینگ کم‌تأخیر و پردازش‌های بلادرنگ باعث شده‌اند نسل تازه‌ای از فرمت‌های ستونی معرفی شوند، فرمت‌هایی که علاوه بر حفظ مزایای پارکت، قابلیت‌های کاملاً جدیدی ارائه می‌کنند:

🔥 سرعت اسکن بسیار بالاتر
🔥 دسترسی تصادفی (Random Access) فوق‌العاده سریع به رکوردها
🔥 ذخیره آمار توکار (Statistics) برای حذف سریع فایل‌های نامرتبط با کوئری
🔥 سازگاری کامل و Zero-Copy با Apache Arrow برای لود بسیار سریع داده

یکی از مهم‌ترین این فرمت‌ها hashtag#Vortex است که بر پایه معماری قابل‌گسترش و با امکان استفاده از encodingها و layoutهای جدید طراحی شده.
طبق گزارش‌ها، Vortex حدود ۱۰۰ برابر دسترسی تصادفی سریع‌تر و ۱۰ تا ۲۰ برابر اسکن سریع‌تر نسبت به hashtag#Parquet ارائه می‌دهد.

خبر خوب این که hashtag#DuckDB در نسخه 4.2 رسماً از Vortex پشتیبانی می‌کند؛ اتفاقی که می‌تواند در کاربردهایی مثل فیلترینگ، جوین‌ها، نرمال‌سازی داده، Feature Engineering و بسیاری از پردازش‌های تحلیلی، تحول جدی ایجاد کند.

همچنین کار روی پشتیبانی Apache hashtag#Iceberg از Vortex نیز آغاز شده و به‌نظر می‌رسد به‌زودی این فرمت به‌صورت کامل وارد اکوسیستم hashtag#Lakehouse شود که این می‌تواند نقطه عطفی در این حوزه باشد.
مرجع اصلی پست : https://www.linkedin.com/feed/update/urn:li:activity:7394922128225144832/

‍ وقتی 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