پروژه گارنت : فرزند نوظهور مایکروسافت برای رفع محدودیت‌های ردیس
اخیراً پستی درباره‌ی جایگزین‌های اپن‌سورس Redis نوشتم که در بخش نظرات، یکی از دوستان اشاره‌ای به پروژه‌ای به نام Garnet کرد که تا آن زمان کمتر درباره‌اش شنیده بودم. همین باعث شد کمی بررسی کنم و به نتایج جالبی برسم؛ نتایجی که به نظر می‌رسد پروژه Garnet آینده روشنی در حوزه دیتابیس‌های مقیم در حافظه و یک Distributed Cache دارد. بیایید این پروژه را با هم مرور کنیم:
🔹 چرا مایکروسافت به سمت Garnet رفت؟
مایکروسافت در سرویس‌های گسترده‌اش (از Windows & Web Experiences گرفته تا Azure Resource Manager) نیاز به یک remote cache-store داشت که هم از نظر کارایی و هم مقیاس‌پذیری فراتر از گزینه‌های موجود باشد. Redis با وجود محبوبیت بالا، محدودیت‌هایی مثل تک‌ریسمانی بودن (تا نسخه‌های اخیر) داشت که در بارهای کاری عظیم و موازی، گلوگاه ایجاد می‌کرد.
تیم Microsoft Research با تکیه بر تجربه پروژه FASTER (۲۰۱۶–۲۰۱۸) از سال ۲۰۲۱ شروع به طراحی Garnet کرد؛ سیستمی که بتواند:
✅مقیاس‌پذیری چندریسمانی واقعی داشته باشد.
✅تاخیر بسیار کم و توان عملیاتی بالا ارائه کند.
✅با ذخیره‌سازی لایه‌ای (RAM، SSD و حتی Azure Storage) کار کند.
✅و مهم‌تر از همه، با اکوسیستم موجود Redis سازگار باشد.
🔹 چه زمانی اپن‌سورس شد؟
در ۱۸ مارس ۲۰۲۴، مایکروسافت به‌طور رسمی Garnet را معرفی و همزمان آن را تحت مجوز MIT اپن‌سورس کرد:
https://github.com/microsoft/garnet👉
🔹 ویژگی‌ها و معماری
گارنت Garnet یک remote cache-store است که برای کارایی بالا، extensibility و تاخیر پایین طراحی شده. برخی ویژگی‌های کلیدی:
🎯 امکان Thread-scalable روی یک نود و پشتیبانی از cluster sharding، replication، failover و transactions.
🎯استفاده از Tsavorite (storage engine مقیاس‌پذیر با tiered storage).
🎯طراحی شبکه pluggable برای رسیدن به throughput بالا و latency در حد صدها میکروثانیه.
🎯پشتیبانی از پروتکل RESP، یعنی می‌توانید Garnet را با کلاینت‌های Redis موجود (مثل StackExchange.Redis) استفاده کنید.
🎯پیاده‌سازی با .NET مدرن، بهینه روی ویندوز و لینوکس، بدون overhead ناشی از garbage collection.
🎯امکان TLS داخلی، extensibility با data structures جدید در .NET.
🔹 جایگاه Garnet در مایکروسافت
طبق اعلام رسمی، نسخه‌هایی از Garnet هم‌اکنون در Windows & Web Experiences Platform، Azure Resource Manager و Azure Resource Graph به کار گرفته شده‌اند.
💡 چرا Garnet خاص است؟
در مقایسه با Redis و حتی Dragonfly، Garnet توانسته:
✅توان عملیاتی بالاتر و Latency پایین‌تر ارائه دهد
✅ مقیاس‌پذیری بهتری در ارتباطات همزمان کلاینت‌ها داشته باشد
✅روی لینوکس و ویندوز یکسان اجرا شود
✅به دلیل Extensibility بالا با نیازهای آینده سازگار بماند
🔄 ردیس هم بیکار ننشسته!
درست است که Garnet بسیار چشمگیر ظاهر شده، اما تیم Redis هم پیشرفت مهمی داشته:
📌 در Redis 8.2 (اوت ۲۰۲۵) مشکل تک‌ریسمانی تا حد زیادی برطرف شده
📌بهبود معماری پردازش چندریسمانی باعث ۴۹٪ افزایش Throughput نسبت به نسخه‌های قبلی شده است
📌 Garnet می‌خواهد همان چیزی باشد که Redis در دنیای مقیاس عظیم هنوز به‌طور کامل نتوانسته باشد؛ یک cache-store سازگار، سریع‌تر، مقیاس‌پذیرتر و مدرن‌تر.
کانال تلگرام مدرسه مهندسی داده سپهرام : @sepahram_school
اخیراً پستی درباره‌ی جایگزین‌های اپن‌سورس Redis نوشتم که در بخش نظرات، یکی از دوستان اشاره‌ای به پروژه‌ای به نام Garnet کرد که تا آن زمان کمتر درباره‌اش شنیده بودم. همین باعث شد کمی بررسی کنم و به نتایج جالبی برسم؛ نتایجی که به نظر می‌رسد پروژه Garnet آینده روشنی در حوزه دیتابیس‌های مقیم در حافظه و یک Distributed Cache دارد. بیایید این پروژه را با هم مرور کنیم:
🔹 چرا مایکروسافت به سمت Garnet رفت؟
مایکروسافت در سرویس‌های گسترده‌اش (از Windows & Web Experiences گرفته تا Azure Resource Manager) نیاز به یک remote cache-store داشت که هم از نظر کارایی و هم مقیاس‌پذیری فراتر از گزینه‌های موجود باشد. Redis با وجود محبوبیت بالا، محدودیت‌هایی مثل تک‌ریسمانی بودن (تا نسخه‌های اخیر) داشت که در بارهای کاری عظیم و موازی، گلوگاه ایجاد می‌کرد.
تیم Microsoft Research با تکیه بر تجربه پروژه FASTER (۲۰۱۶–۲۰۱۸) از سال ۲۰۲۱ شروع به طراحی Garnet کرد؛ سیستمی که بتواند:
✅مقیاس‌پذیری چندریسمانی واقعی داشته باشد.
✅تاخیر بسیار کم و توان عملیاتی بالا ارائه کند.
✅با ذخیره‌سازی لایه‌ای (RAM، SSD و حتی Azure Storage) کار کند.
✅و مهم‌تر از همه، با اکوسیستم موجود Redis سازگار باشد.
🔹 چه زمانی اپن‌سورس شد؟
در ۱۸ مارس ۲۰۲۴، مایکروسافت به‌طور رسمی Garnet را معرفی و همزمان آن را تحت مجوز MIT اپن‌سورس کرد:
https://github.com/microsoft/garnet👉
🔹 ویژگی‌ها و معماری
گارنت Garnet یک remote cache-store است که برای کارایی بالا، extensibility و تاخیر پایین طراحی شده. برخی ویژگی‌های کلیدی:
🎯 امکان Thread-scalable روی یک نود و پشتیبانی از cluster sharding، replication، failover و transactions.
🎯استفاده از Tsavorite (storage engine مقیاس‌پذیر با tiered storage).
🎯طراحی شبکه pluggable برای رسیدن به throughput بالا و latency در حد صدها میکروثانیه.
🎯پشتیبانی از پروتکل RESP، یعنی می‌توانید Garnet را با کلاینت‌های Redis موجود (مثل StackExchange.Redis) استفاده کنید.
🎯پیاده‌سازی با .NET مدرن، بهینه روی ویندوز و لینوکس، بدون overhead ناشی از garbage collection.
🎯امکان TLS داخلی، extensibility با data structures جدید در .NET.
🔹 جایگاه Garnet در مایکروسافت
طبق اعلام رسمی، نسخه‌هایی از Garnet هم‌اکنون در Windows & Web Experiences Platform، Azure Resource Manager و Azure Resource Graph به کار گرفته شده‌اند.
💡 چرا Garnet خاص است؟
در مقایسه با Redis و حتی Dragonfly، Garnet توانسته:
✅توان عملیاتی بالاتر و Latency پایین‌تر ارائه دهد
✅ مقیاس‌پذیری بهتری در ارتباطات همزمان کلاینت‌ها داشته باشد
✅روی لینوکس و ویندوز یکسان اجرا شود
✅به دلیل Extensibility بالا با نیازهای آینده سازگار بماند
🔄 ردیس هم بیکار ننشسته!
درست است که Garnet بسیار چشمگیر ظاهر شده، اما تیم Redis هم پیشرفت مهمی داشته:
📌 در Redis 8.2 (اوت ۲۰۲۵) مشکل تک‌ریسمانی تا حد زیادی برطرف شده
📌بهبود معماری پردازش چندریسمانی باعث ۴۹٪ افزایش Throughput نسبت به نسخه‌های قبلی شده است
📌 Garnet می‌خواهد همان چیزی باشد که Redis در دنیای مقیاس عظیم هنوز به‌طور کامل نتوانسته باشد؛ یک cache-store سازگار، سریع‌تر، مقیاس‌پذیرتر و مدرن‌تر.
کانال تلگرام مدرسه مهندسی داده سپهرام : @sepahram_school
👍2❤1
وقتی شمارش دقیق خیلی گرون میشه: HyperLogLog 🔢
وقتی با داده‌های بزرگ سروکار داریم، خیلی وقت‌ها لازم داریم بدانیم:
✅چند کاربر یکتا در سایت بوده‌اند؟
✅چند IP مختلف به API ما وصل شده‌اند؟
✅چند محصول متفاوت در یک بازه دیده شده؟
💡 راه ساده این است که همه شناسه‌ها را نگه داریم و آخرش بشماریم.
اما در دیتابیس‌های توزیع‌شده، این یعنی انفجار حافظه و فشار شدید روی شبکه.
برای همین سراغ ساختارهای داده‌ی «تقریبی» می‌رویم که با مصرف کم حافظه، جواب نزدیک به درست بدهند. یکی از معروف‌ترین‌ها: #HyperLogLog.
🎲 مثال با تاس: رخدادهای نادر
فرض کن کسی مدام تاس می‌ریزد. تو نمی‌دانی چند بار تاس انداخته، فقط نتایج را می‌بینی.
🔹 اگه فقط یک بار ۶ آمد → عادی است.
🔹 اگه دو بار پشت سر هم ۶ آمد → کمی نادرتر.
🔹 اگه چهار بار پشت سر هم ۶ آمد → خیلی خیلی نادر.
این رخدادهای نادر سرنخ خوبی هستند. وقتی چیزی خیلی نادر دیدی، می‌توانی حدس بزنی که احتمالا تعداد دفعات تاس انداختن خیلی زیاد بوده است.
🔑 ارتباط با #HyperLogLog
حالا این ایده را می‌بریم به دنیای هش:
📌هر آیتم (مثل IP یا UserID) را هش می‌کنیم → یک رشته‌ی طولانی صفر و یک.
📌به ابتدای این رشته نگاه می‌کنیم: چند صفر پشت سر هم آمده؟
📌هرچه صفرهای بیشتری پشت سر هم باشد، اتفاق نادرتر است → پس احتمالاً داده‌های یکتای زیادی وارد شده‌اند.
📌در نسخه‌ی ساده‌ی الگوریتم، همیشه بیشترین تعداد صفر دیده‌شده را نگه می‌داریم.
مثلاً اگر حداکثر ۶ صفر دیده‌ایم، می‌گوییم:
تقریباً 6^2 = 64 آیتم یکتا داشته‌ایم. (بر اساس فرمول‌های آماری)
🚨 ایراد نسخه‌ی ساده
این روش یک اشکال بزرگ دارد:
اگر همان اوّل کار شانسی هشی بیاید با ۲۰ صفر پشت سر هم، الگوریتم می‌گوید: «اینجا باید حدود یک میلیون آیتم یکتا دیده شده باشد!»
در حالی که شاید فقط ۱۰ آیتم وارد شده‌اند.
مثل این است که دفعه‌ی اوّل ۴ تا شش پشت سر هم بیاید و ما فکر کنیم هزار بار تاس ریخته‌ایم!
🪣 راه‌حل: باکتینگ
برای حل این مشکل، #HyperLogLog واقعی از باکت‌ها استفاده می‌کند:
🎯چند بیت اول هش → تعیین می‌کند آیتم در کدام باکت قرار بگیرد.
🎯بقیه بیت‌ها → برای شمردن تعداد صفرهای ابتدای رشته استفاده می‌شود.
🎯در هر باکت، فقط «بیشترین تعداد صفر» ذخیره می‌شود.
🎯در پایان، الگوریتم همه باکت‌ها را با هم ترکیب می‌کند (با میانگین هارمونیک + اصلاح خطا).
به این ترتیب، یک رخداد نادر شانسی نمی‌تواند کل تخمین را خراب کند.
🏗 کجاها استفاده می‌شود؟
الگوریتم شمارش #HyperLogLog امروز در خیلی از دیتابیس‌ها و ابزارهای بزرگ به‌کار می‌رود:
🧩ردیس → دستورات PFADD و PFCOUNT برای شمارش یکتاها
🧩بیگ‌کوئری→ پشت APPROX_COUNT_DISTINCT
🧩ترینو/Presto و #ClickHouse → توابع شمارش تقریبی
🧩اسپارک و #Snowflake → در approx_count_distinct
🧩و حتی سیستم‌هایی مثل Cassandra / ScyllaDB که برای کم کردن بار IO از ساختارهای مشابه استفاده می‌کنند
✨ خلاصه اینکه:
الگوریتم HyperLogLog به‌جای شمردن دقیق، «حدس تقریبی اما پایدار» می‌زند؛ و همین باعث شده در مقیاس وب و دیتای عظیم، تبدیل به یک ابزار استاندارد شود.
کانال مدرسه مهندسی داده سپهرام: @sepahram_school
وقتی با داده‌های بزرگ سروکار داریم، خیلی وقت‌ها لازم داریم بدانیم:
✅چند کاربر یکتا در سایت بوده‌اند؟
✅چند IP مختلف به API ما وصل شده‌اند؟
✅چند محصول متفاوت در یک بازه دیده شده؟
💡 راه ساده این است که همه شناسه‌ها را نگه داریم و آخرش بشماریم.
اما در دیتابیس‌های توزیع‌شده، این یعنی انفجار حافظه و فشار شدید روی شبکه.
برای همین سراغ ساختارهای داده‌ی «تقریبی» می‌رویم که با مصرف کم حافظه، جواب نزدیک به درست بدهند. یکی از معروف‌ترین‌ها: #HyperLogLog.
🎲 مثال با تاس: رخدادهای نادر
فرض کن کسی مدام تاس می‌ریزد. تو نمی‌دانی چند بار تاس انداخته، فقط نتایج را می‌بینی.
🔹 اگه فقط یک بار ۶ آمد → عادی است.
🔹 اگه دو بار پشت سر هم ۶ آمد → کمی نادرتر.
🔹 اگه چهار بار پشت سر هم ۶ آمد → خیلی خیلی نادر.
این رخدادهای نادر سرنخ خوبی هستند. وقتی چیزی خیلی نادر دیدی، می‌توانی حدس بزنی که احتمالا تعداد دفعات تاس انداختن خیلی زیاد بوده است.
🔑 ارتباط با #HyperLogLog
حالا این ایده را می‌بریم به دنیای هش:
📌هر آیتم (مثل IP یا UserID) را هش می‌کنیم → یک رشته‌ی طولانی صفر و یک.
📌به ابتدای این رشته نگاه می‌کنیم: چند صفر پشت سر هم آمده؟
📌هرچه صفرهای بیشتری پشت سر هم باشد، اتفاق نادرتر است → پس احتمالاً داده‌های یکتای زیادی وارد شده‌اند.
📌در نسخه‌ی ساده‌ی الگوریتم، همیشه بیشترین تعداد صفر دیده‌شده را نگه می‌داریم.
مثلاً اگر حداکثر ۶ صفر دیده‌ایم، می‌گوییم:
تقریباً 6^2 = 64 آیتم یکتا داشته‌ایم. (بر اساس فرمول‌های آماری)
🚨 ایراد نسخه‌ی ساده
این روش یک اشکال بزرگ دارد:
اگر همان اوّل کار شانسی هشی بیاید با ۲۰ صفر پشت سر هم، الگوریتم می‌گوید: «اینجا باید حدود یک میلیون آیتم یکتا دیده شده باشد!»
در حالی که شاید فقط ۱۰ آیتم وارد شده‌اند.
مثل این است که دفعه‌ی اوّل ۴ تا شش پشت سر هم بیاید و ما فکر کنیم هزار بار تاس ریخته‌ایم!
🪣 راه‌حل: باکتینگ
برای حل این مشکل، #HyperLogLog واقعی از باکت‌ها استفاده می‌کند:
🎯چند بیت اول هش → تعیین می‌کند آیتم در کدام باکت قرار بگیرد.
🎯بقیه بیت‌ها → برای شمردن تعداد صفرهای ابتدای رشته استفاده می‌شود.
🎯در هر باکت، فقط «بیشترین تعداد صفر» ذخیره می‌شود.
🎯در پایان، الگوریتم همه باکت‌ها را با هم ترکیب می‌کند (با میانگین هارمونیک + اصلاح خطا).
به این ترتیب، یک رخداد نادر شانسی نمی‌تواند کل تخمین را خراب کند.
🏗 کجاها استفاده می‌شود؟
الگوریتم شمارش #HyperLogLog امروز در خیلی از دیتابیس‌ها و ابزارهای بزرگ به‌کار می‌رود:
🧩ردیس → دستورات PFADD و PFCOUNT برای شمارش یکتاها
🧩بیگ‌کوئری→ پشت APPROX_COUNT_DISTINCT
🧩ترینو/Presto و #ClickHouse → توابع شمارش تقریبی
🧩اسپارک و #Snowflake → در approx_count_distinct
🧩و حتی سیستم‌هایی مثل Cassandra / ScyllaDB که برای کم کردن بار IO از ساختارهای مشابه استفاده می‌کنند
✨ خلاصه اینکه:
الگوریتم HyperLogLog به‌جای شمردن دقیق، «حدس تقریبی اما پایدار» می‌زند؛ و همین باعث شده در مقیاس وب و دیتای عظیم، تبدیل به یک ابزار استاندارد شود.
کانال مدرسه مهندسی داده سپهرام: @sepahram_school
👌4❤1🔥1
فشرده‌سازی JSON — انتخاب الگوریتم مناسب برای سرعت و بهره‌وری بیشتر
JSON همه‌جا هست: از APIها و سرویس‌های میکروسرویس تا ذخیره‌سازی لاگ و داده‌های تحلیلی. اما اغلب فراموش می‌کنیم که یک انتخاب ساده در الگوریتم فشرده‌سازی می‌تواند سرعت، مصرف CPU و پهنای‌باند را به شدت بهبود دهد.
در ادامه نگاهی دقیق‌تر به الگوریتم‌های مرسوم و نتایج عملی بنچمارک داریم:
🔹 GZIP
🎯چطور کار می‌کند: در واقع ZLIB (ترکیبی از الگوریتم LZ77 برای یافتن الگوهای تکراری و کدگذاری هافمن) است که یک پوسته اضافه دارد و متادیتای فایل و CRC را اضافه می‌کند.
🧩ویژگی‌ها: همان مزایای ZLIB (نسبت فشرده‌سازی بالا، پشتیبانی گسترده در اکثر زبان‌ها و سیستم‌ها) با کمی قابلیت سازگاری بیشتر.
🛠محدودیت‌ها: نسبت فشرده‌سازی و سرعت مشابه ZLIB، اما کمی سنگین‌تر در متادیتا.
🔹 Snappy (گوگل)
🎯چطور کار می‌کند: تمرکز روی سرعت؛ از الگوریتم‌های ساده فشرده‌سازی برای پیدا کردن الگوهای کوتاه استفاده می‌کند.
🧩ویژگی‌ها: سرعت فوق‌العاده بالا، مصرف CPU کم.
🛠محدودیت‌ها: نسبت فشرده‌سازی پایین‌تر از ZLIB/Zstd.
✨کجا استفاده شود: سیستم‌های زمان‌واقعی، پیام‌رسانی، پردازش جریان داده (Streaming).
🔹 Zstandard (Zstd)
🎯چطور کار می‌کند: ترکیبی از الگوریتم‌های LZ77 و Huffman، با طراحی مدرن و قابلیت تنظیم سطح فشرده‌سازی از سریع تا بسیار فشرده.
🧩ویژگی‌ها: نسبت فشرده‌سازی خوب، سرعت بالا، امکان تنظیم دقیق برای تعادل بین سرعت و حجم.
🛠محدودیت‌ها: کمی مصرف حافظه بیشتر از Snappy.
✨کجا استفاده شود: ذخیره‌سازی حجیم، انتقال داده‌های بزرگ، زمانی که نیاز به تعادل بین سرعت و حجم داریم.
🔹 Brotli (گوگل)
🎯چطور کار می‌کند: طراحی شده برای وب و HTTPS، از دیکشنری‌های از پیش تعریف شده و الگوریتم‌های هافمن پیچیده استفاده می‌کند.
🧩ویژگی‌ها: بهترین نسبت فشرده‌سازی برای متن، مخصوصا JSON و HTML.
🛠محدودیت‌ها: سرعت فشرده‌سازی کندتر، مصرف حافظه بیشتر.
✨کجا استفاده شود: وب‌اپلیکیشن‌ها، کاربران موبایل، شبکه‌های با پهنای‌باند محدود.
⚙️ بنچمارک عملی
آدرس بنچمارک : https://lnkd.in/d6iBwzPQ
⚡️ روش کار (Methodology):
⚡️دیتاست: ۱۰,۰۰۰ آبجکت JSON با ساختارهای تو در تو، هر کدام حدود ۱KB
⚡️ابزارها: Node.js zlib, snappy, zstd-codec, brotli
معیارها:
🔰نسبت فشرده‌سازی: اندازه اصلی ÷ اندازه فشرده‌شده
🔰سرعت: MB/s (فشرده‌سازی + بازگشایی)
🔰مصرف CPU و حافظه: اندازه‌گیری شده با Linux perf
محیط اجرا:
📌 زبان Node.js v20.11.1
📌شبکه شبیه‌سازی شده ۱۰۰ Mbps
🔑 نتایج کلیدی
توازن سرعت و نسبت فشرده‌سازی
🎯الگوریتم Snappy سریع‌ترین است، ۴ برابر سریع‌تر از ZLIB، ایده‌آل برای برنامه‌های زمان واقعی.
🎯الگوریتم‌های Brotli و Zstd نسبت فشرده‌سازی بهتری دارند (۵.۱x و ۴.۵x) اما سرعت کمتری دارند.
مصرف CPU و حافظه
🎯 الگوریتم Snappy حدود ۷۰٪ کمتر از ZLIB/Brotli CPU مصرف می‌کند.
الگوریتم Zstd تعادل خوبی بین CPU (۶۰٪ مصرف) و نسبت فشرده‌سازی ارائه می‌دهد.
تأثیر روی شبکه
🎯 الگوریتم Brotli حجم payload را تا ۸۰٪ کاهش می‌دهد، مخصوص شبکه‌های با تأخیر بالا.
الگوریتم Snappy تأخیر را برای سیستم‌های زمان واقعی (مثل گیمینگ و IoT) به حداقل می‌رساند.
💡 جمع‌بندی برای انتخاب الگوریتم
- سرعت مهم است؟ → Snappy
- کمترین حجم و صرفه‌جویی پهنای باند؟ → Brotli یا Zstd
- تعادل و همه‌کاره بودن؟ → Zstd
- سازگاری با سیستم‌های قدیمی؟ → ZLIB/GZIP
JSON همه‌جا هست: از APIها و سرویس‌های میکروسرویس تا ذخیره‌سازی لاگ و داده‌های تحلیلی. اما اغلب فراموش می‌کنیم که یک انتخاب ساده در الگوریتم فشرده‌سازی می‌تواند سرعت، مصرف CPU و پهنای‌باند را به شدت بهبود دهد.
در ادامه نگاهی دقیق‌تر به الگوریتم‌های مرسوم و نتایج عملی بنچمارک داریم:
🔹 GZIP
🎯چطور کار می‌کند: در واقع ZLIB (ترکیبی از الگوریتم LZ77 برای یافتن الگوهای تکراری و کدگذاری هافمن) است که یک پوسته اضافه دارد و متادیتای فایل و CRC را اضافه می‌کند.
🧩ویژگی‌ها: همان مزایای ZLIB (نسبت فشرده‌سازی بالا، پشتیبانی گسترده در اکثر زبان‌ها و سیستم‌ها) با کمی قابلیت سازگاری بیشتر.
🛠محدودیت‌ها: نسبت فشرده‌سازی و سرعت مشابه ZLIB، اما کمی سنگین‌تر در متادیتا.
🔹 Snappy (گوگل)
🎯چطور کار می‌کند: تمرکز روی سرعت؛ از الگوریتم‌های ساده فشرده‌سازی برای پیدا کردن الگوهای کوتاه استفاده می‌کند.
🧩ویژگی‌ها: سرعت فوق‌العاده بالا، مصرف CPU کم.
🛠محدودیت‌ها: نسبت فشرده‌سازی پایین‌تر از ZLIB/Zstd.
✨کجا استفاده شود: سیستم‌های زمان‌واقعی، پیام‌رسانی، پردازش جریان داده (Streaming).
🔹 Zstandard (Zstd)
🎯چطور کار می‌کند: ترکیبی از الگوریتم‌های LZ77 و Huffman، با طراحی مدرن و قابلیت تنظیم سطح فشرده‌سازی از سریع تا بسیار فشرده.
🧩ویژگی‌ها: نسبت فشرده‌سازی خوب، سرعت بالا، امکان تنظیم دقیق برای تعادل بین سرعت و حجم.
🛠محدودیت‌ها: کمی مصرف حافظه بیشتر از Snappy.
✨کجا استفاده شود: ذخیره‌سازی حجیم، انتقال داده‌های بزرگ، زمانی که نیاز به تعادل بین سرعت و حجم داریم.
🔹 Brotli (گوگل)
🎯چطور کار می‌کند: طراحی شده برای وب و HTTPS، از دیکشنری‌های از پیش تعریف شده و الگوریتم‌های هافمن پیچیده استفاده می‌کند.
🧩ویژگی‌ها: بهترین نسبت فشرده‌سازی برای متن، مخصوصا JSON و HTML.
🛠محدودیت‌ها: سرعت فشرده‌سازی کندتر، مصرف حافظه بیشتر.
✨کجا استفاده شود: وب‌اپلیکیشن‌ها، کاربران موبایل، شبکه‌های با پهنای‌باند محدود.
⚙️ بنچمارک عملی
آدرس بنچمارک : https://lnkd.in/d6iBwzPQ
⚡️ روش کار (Methodology):
⚡️دیتاست: ۱۰,۰۰۰ آبجکت JSON با ساختارهای تو در تو، هر کدام حدود ۱KB
⚡️ابزارها: Node.js zlib, snappy, zstd-codec, brotli
معیارها:
🔰نسبت فشرده‌سازی: اندازه اصلی ÷ اندازه فشرده‌شده
🔰سرعت: MB/s (فشرده‌سازی + بازگشایی)
🔰مصرف CPU و حافظه: اندازه‌گیری شده با Linux perf
محیط اجرا:
📌 زبان Node.js v20.11.1
📌شبکه شبیه‌سازی شده ۱۰۰ Mbps
🔑 نتایج کلیدی
توازن سرعت و نسبت فشرده‌سازی
🎯الگوریتم Snappy سریع‌ترین است، ۴ برابر سریع‌تر از ZLIB، ایده‌آل برای برنامه‌های زمان واقعی.
🎯الگوریتم‌های Brotli و Zstd نسبت فشرده‌سازی بهتری دارند (۵.۱x و ۴.۵x) اما سرعت کمتری دارند.
مصرف CPU و حافظه
🎯 الگوریتم Snappy حدود ۷۰٪ کمتر از ZLIB/Brotli CPU مصرف می‌کند.
الگوریتم Zstd تعادل خوبی بین CPU (۶۰٪ مصرف) و نسبت فشرده‌سازی ارائه می‌دهد.
تأثیر روی شبکه
🎯 الگوریتم Brotli حجم payload را تا ۸۰٪ کاهش می‌دهد، مخصوص شبکه‌های با تأخیر بالا.
الگوریتم Snappy تأخیر را برای سیستم‌های زمان واقعی (مثل گیمینگ و IoT) به حداقل می‌رساند.
💡 جمع‌بندی برای انتخاب الگوریتم
- سرعت مهم است؟ → Snappy
- کمترین حجم و صرفه‌جویی پهنای باند؟ → Brotli یا Zstd
- تعادل و همه‌کاره بودن؟ → Zstd
- سازگاری با سیستم‌های قدیمی؟ → ZLIB/GZIP
👍4
جلسه اول دوره ClickHouse در مدرسه مهندسی داده سپهرام برگزار شد و فیلم بخش نصب و راه‌اندازی و شروع به کار با ClickHouse اکنون در یوتیوب و صفحه درس دوره منتشر شده است.
دوستانی که تاکنون فرصت نصب و کار کردن با ClickHouse را نداشته‌اند اما علاقه دارند با این دیتابیس پرقدرت و سریع تحلیلی آشنا شوند، می‌توانند در یک جلسه کوتاه نیم‌ساعته به صورت عملی کار با آن را تجربه کنند.
در این ویدئو خواهید دید:
ـ نصب ClickHouse روی ویندوز با استفاده از WSL
ـ راه‌اندازی سرور و اتصال اولیه
ـ کار با محیط clickhouse-client
ـ ایجاد دیتابیس و جداول اولیه برای شروع کار
📺 مشاهده ویدئوی جلسه اول:
👉 https://www.youtube.com/watch?v=gGpSbMpfAiM
برای دیدن بخش دوم و ادامه ویدئوهای آموزشی به آدرس زیر مراجعه کنید:
👉 https://sepahram.ir/courses/clickhouse-201/
#ClickHouse #DataEngineering #BigData #Analytics #OLAP #HandsOn
کانال تلگرام سپهرام : @sepahram_school
دوستانی که تاکنون فرصت نصب و کار کردن با ClickHouse را نداشته‌اند اما علاقه دارند با این دیتابیس پرقدرت و سریع تحلیلی آشنا شوند، می‌توانند در یک جلسه کوتاه نیم‌ساعته به صورت عملی کار با آن را تجربه کنند.
در این ویدئو خواهید دید:
ـ نصب ClickHouse روی ویندوز با استفاده از WSL
ـ راه‌اندازی سرور و اتصال اولیه
ـ کار با محیط clickhouse-client
ـ ایجاد دیتابیس و جداول اولیه برای شروع کار
📺 مشاهده ویدئوی جلسه اول:
👉 https://www.youtube.com/watch?v=gGpSbMpfAiM
برای دیدن بخش دوم و ادامه ویدئوهای آموزشی به آدرس زیر مراجعه کنید:
👉 https://sepahram.ir/courses/clickhouse-201/
#ClickHouse #DataEngineering #BigData #Analytics #OLAP #HandsOn
کانال تلگرام سپهرام : @sepahram_school
🔥1🙏1
معرفی Icebox: ساده‌ترین راه برای تجربه Apache Iceberg و دنیای Lakehouse
اگر همیشه کنجکاو بودید که Apache Iceberg را امتحان کنید، اما حوصله‌ی راه‌اندازی‌های پیچیده، کانفیگ‌های سنگین و کلاسترهای پرهزینه را نداشتید، خبر خوب اینجاست:
کتابخانه Icebox مثل یک Flight Simulator برای Iceberg عمل می‌کند:
✨بدون نیاز به Docker یا JVM
✨یک باینری ساده، با نصب صفر و شروع سریع
✨موتور تحلیلی DuckDB برای اجرای کوئری‌های SQL
✨استوریج MinIO داخلی برای شبیه‌سازی فضای S3
✨و مهم‌تر از همه، پشتیبانی از تمام امکانات Iceberg (ACID, Time Travel, Schema Evolution)
🎯 چرا Apache Iceberg ترند شده است؟
ترکیب انعطاف و مقیاس‌پذیری Data Lake با قابلیت‌های قوی Data Warehouse.
و اینجاست که Apache Iceberg نقش اصلی را بازی می‌کند:
✅ ACID Transactions
✅ Schema Evolution
✅ Time Travel
✅ Performance Optimizations
✅ Open & Vendor-neutral
به همین خاطر است که امروز Iceberg به یکی از ترندترین فناوری‌های دنیای داده تبدیل شده است.
برای یک مهندس داده مدرن، یادگیری Iceberg دیگر یک انتخاب نیست؛ یک ضرورت است.
اما ببینیم وقتی یک جدول در Lakehouse تعریف می‌کنیم چه اتفاقی می‌افتد؟
در ظاهر مثل دیتابیس سنتی می‌نویسیم:
اما پشت صحنه:
🎯یک جدول در Iceberg فقط یک متادیتا + مجموعه‌ای از فایل‌ها (Parquet/ORC) است.
🎯هر بار داده اضافه یا حذف می‌شود، فایل جدید ساخته می‌شود و یک snapshot جدید در متادیتا ثبت می‌گردد.
🎯این snapshotها امکان time travel و versioning را فراهم می‌کنند.
🎯کامیت تغییرات از طریق فایل متادیتا انجام می‌شود (atomic commit) → این همان چیزی است که #ACID را تضمین می‌کند.
🎯موقع اجرای یک کوئری، فقط متادیتا بررسی می‌شود تا بفهمد کدام فایل‌ها باید خوانده شوند → باعث افزایش کارایی می‌شود.
پس در عمل، یک جدول Iceberg چیزی جز این نیست:
metadata.json + snapshots + فایل‌های parquet
این مکانیزم همان چیزی است که Lakehouse را از یک Data Lake ساده متمایز می‌کند.
💡 تجربه عملی در سه قدم:
✅ تبریک! حالا شما یک Lakehouse واقعی روی لپ‌تاپ خودتان دارید.
🔰 آیس‌باکس: شبیه‌ساز سریع برای یادگیری Iceberg
حالا که می‌دانیم چرا Iceberg مهم است و در پشت صحنه چطور کار می‌کند، سوال این است: چطور می‌توانیم به‌سادگی آن را تجربه کنیم؟ اینجاست که Icebox وارد بازی می‌شود.
امکانات کلیدی Icebox:
📌 شروع سریع: فقط یک فایل باینری، بدون نصب و دردسر
📌 کاتالوگ داخلی SQLite برای مدیریت متادیتا
📌 استوریج MinIO داخلی برای شبیه‌سازی S3 و تست workflowهای ابری
📌 دیتابیس DuckDB تعبیه‌شده برای اجرای سریع SQL
📌 سازگار با همه امکانات Iceberg: تراکنش‌ها، تغییر اسکیمای جداول، time travel
چرا Icebox ارزش امتحان کردن دارد؟
🔰برای یادگیری Iceberg و Lakehouse بدون نیاز به کلود یا کلاستر
🔰برای تست و پروتوتایپ کردن پایپ‌لاین‌های داده‌ای
🔰برای درک عملی امکانات Iceberg (time travel, schema evolution, ACID)
🔰برای داشتن یک محیط سبک، ساده و همیشه آماده روی لپ‌تاپ
🔗 سورس‌کد و مستندات: https://github.com/TFMV/icebox
✨ اگر شما هم دوست دارید Apache Iceberg را یاد بگیرید، Icebox یک نقطه‌ی شروع عالی و بدون دردسر است.
کانال مدرسه مهندسی داده سپهرام : https://t.iss.one/sepahram_school
اگر همیشه کنجکاو بودید که Apache Iceberg را امتحان کنید، اما حوصله‌ی راه‌اندازی‌های پیچیده، کانفیگ‌های سنگین و کلاسترهای پرهزینه را نداشتید، خبر خوب اینجاست:
آیس‌باکس یک ابزار ساده نوشته‌شده با زبان Go است که به شما امکان می‌دهد روی لپ‌تاپ شخصی‌تان در کمتر از ۵ دقیقه یک #Lakehouse واقعی را تجربه کنید.
کتابخانه Icebox مثل یک Flight Simulator برای Iceberg عمل می‌کند:
✨بدون نیاز به Docker یا JVM
✨یک باینری ساده، با نصب صفر و شروع سریع
✨موتور تحلیلی DuckDB برای اجرای کوئری‌های SQL
✨استوریج MinIO داخلی برای شبیه‌سازی فضای S3
✨و مهم‌تر از همه، پشتیبانی از تمام امکانات Iceberg (ACID, Time Travel, Schema Evolution)
🎯 چرا Apache Iceberg ترند شده است؟
ترکیب انعطاف و مقیاس‌پذیری Data Lake با قابلیت‌های قوی Data Warehouse.
و اینجاست که Apache Iceberg نقش اصلی را بازی می‌کند:
✅ ACID Transactions
✅ Schema Evolution
✅ Time Travel
✅ Performance Optimizations
✅ Open & Vendor-neutral
به همین خاطر است که امروز Iceberg به یکی از ترندترین فناوری‌های دنیای داده تبدیل شده است.
برای یک مهندس داده مدرن، یادگیری Iceberg دیگر یک انتخاب نیست؛ یک ضرورت است.
اما ببینیم وقتی یک جدول در Lakehouse تعریف می‌کنیم چه اتفاقی می‌افتد؟
در ظاهر مثل دیتابیس سنتی می‌نویسیم:
CREATE TABLE sales (
id BIGINT,
amount DOUBLE,
created_at TIMESTAMP
);
اما پشت صحنه:
🎯یک جدول در Iceberg فقط یک متادیتا + مجموعه‌ای از فایل‌ها (Parquet/ORC) است.
🎯هر بار داده اضافه یا حذف می‌شود، فایل جدید ساخته می‌شود و یک snapshot جدید در متادیتا ثبت می‌گردد.
🎯این snapshotها امکان time travel و versioning را فراهم می‌کنند.
🎯کامیت تغییرات از طریق فایل متادیتا انجام می‌شود (atomic commit) → این همان چیزی است که #ACID را تضمین می‌کند.
🎯موقع اجرای یک کوئری، فقط متادیتا بررسی می‌شود تا بفهمد کدام فایل‌ها باید خوانده شوند → باعث افزایش کارایی می‌شود.
پس در عمل، یک جدول Iceberg چیزی جز این نیست:
metadata.json + snapshots + فایل‌های parquet
این مکانیزم همان چیزی است که Lakehouse را از یک Data Lake ساده متمایز می‌کند.
💡 تجربه عملی در سه قدم:
./icebox init my-lakehouse
./icebox import data.parquet --table sales
./icebox sql "SELECT COUNT(*) FROM sales"
✅ تبریک! حالا شما یک Lakehouse واقعی روی لپ‌تاپ خودتان دارید.
🔰 آیس‌باکس: شبیه‌ساز سریع برای یادگیری Iceberg
حالا که می‌دانیم چرا Iceberg مهم است و در پشت صحنه چطور کار می‌کند، سوال این است: چطور می‌توانیم به‌سادگی آن را تجربه کنیم؟ اینجاست که Icebox وارد بازی می‌شود.
امکانات کلیدی Icebox:
📌 شروع سریع: فقط یک فایل باینری، بدون نصب و دردسر
📌 کاتالوگ داخلی SQLite برای مدیریت متادیتا
📌 استوریج MinIO داخلی برای شبیه‌سازی S3 و تست workflowهای ابری
📌 دیتابیس DuckDB تعبیه‌شده برای اجرای سریع SQL
📌 سازگار با همه امکانات Iceberg: تراکنش‌ها، تغییر اسکیمای جداول، time travel
چرا Icebox ارزش امتحان کردن دارد؟
🔰برای یادگیری Iceberg و Lakehouse بدون نیاز به کلود یا کلاستر
🔰برای تست و پروتوتایپ کردن پایپ‌لاین‌های داده‌ای
🔰برای درک عملی امکانات Iceberg (time travel, schema evolution, ACID)
🔰برای داشتن یک محیط سبک، ساده و همیشه آماده روی لپ‌تاپ
🔗 سورس‌کد و مستندات: https://github.com/TFMV/icebox
✨ اگر شما هم دوست دارید Apache Iceberg را یاد بگیرید، Icebox یک نقطه‌ی شروع عالی و بدون دردسر است.
کانال مدرسه مهندسی داده سپهرام : https://t.iss.one/sepahram_school
👌4👍3
از CQRS تا یک سامانه حافظه‌محور : داستان بازطراحی Tudum در نتفلیکس
الگوی #CQRS و معماری‌های event-driven ابزارهای قدرتمندی برای مقیاس‌پذیری هستند. اما وقتی تأخیر بین «نوشتن» و «نمایش تغییر» زیاد شود، به‌خصوص برای سناریوهای real-time مثل preview محتوا، همین الگوها می‌توانند به گلوگاه تبدیل شوند.
📌 داستان Tudum (وب‌سایت طرفداران نتفلیکس) دقیقاً ناظر به همین مساله است.
⚡️ معماری اولیه: #CQRS + #Kafka + #Cassandra
نتفلیکس وب‌سایت طرفداران Tudum را در ۲۰۲۱ راه‌اندازی کرد تا محتوای جانبی مرتبط با برنامه‌ها را به کاربران ارائه دهد و ویراستاران بتوانند تغییرات را پیش‌نمایش کنند.
داده‌ها ابتدا از CMS به سرویس ingestion می‌رفت، پردازش و روی #Kafka منتشر می‌شد، سپس در #Cassandra ذخیره و با near cache سریع‌تر به سرویس ساخت صفحات می‌رسید تا صفحات HTML برای کاربران ساخته و نمایش داده شوند. مسیر انتشار و نمایش داده‌ها جدا شد تا مقیاس‌پذیری بهتر شود، اما مشکل تأخیر cache همچنان باقی بود.
⚡️مزایا؟ تفکیک write و read و امکان scale مستقل.
⚠️ مشکل؟ ⏳ تغییرات محتوا در CMS با تأخیر زیاد روی سایت دیده می‌شد.
🔍 دلیل اصلی این تاخیر طبق گزارش نتفلیکس:
🔹کش با یک چرخه‌ی refresh به‌روزرسانی می‌شد.
🔹مثلاً اگر ۶۰ کلید داشتی و هر ثانیه یکی refresh می‌شد، تغییرات حداقل ۶۰ ثانیه بعد قابل مشاهده بود.
🔹با رشد محتوا، این زمان حتی به چند ده ثانیه می‌رسید.
🔹 برای نویسندگان و ویراستاران، این یعنی تجربه‌ی preview عملاً بی‌فایده بود.
🚀 بازطراحی: RAW Hollow به‌جای Kafka و Cassandra
به جای وصله‌پینه روی کش یا افزایش سرعت Kafka، تیم نتفلیکس یک مسیر جدید انتخاب کرد: جایگزینی کل CQRS pipeline با یک دیتابیس in-memory به نام RAW Hollow.
آدرس پروژه : https://hollow.how
ویژگی‌ها:
🔰کل dataset در حافظه‌ی هر process ذخیره می‌شود → latency بسیار پایین.
🔰پشتیبانی از strong read-after-write consistency → تغییرات بلافاصله قابل مشاهده‌اند.
🔰فشرده‌سازی Hollow حجم داده را تا ۲۵٪ نسخه‌ی اصلی کاهش می‌دهد → کل داده جا می‌شود.
🔰معماری ساده‌تر: حذف Kafka، Cassandra و cache → کمتر شدن لایه‌ها = کمتر شدن delay.
📊 نتایج برای Tudum
✨تأخیر در نمایش تغییرات: از چند ده ثانیه → به چند ثانیه.
✨زمان ساخت صفحه: از ~۱.۴s → به ~۰.۴s.
✨تجربه‌ی preview برای نویسندگان روان شد.
✨معماری تمیزتر و بدون گره‌های زائد.
💬 واکنش‌ها در Hacker News و Reddit
انتشار این تجربه بحث‌های زیادی ایجاد کرد:
🎯بعضی گفتند مشکل صرفاً cache invalidation بود و می‌شد ساده‌تر حل کرد.
🎯عده‌ای این تغییر را over-engineering دانستند برای سایتی شبیه یک بلاگ.
🎯گروهی دیگر تأکید داشتند که با مقیاس و نیاز به personalization نتفلیکس، این تصمیم منطقی است.
🎯برخی هم انتقاد کردند که مسئله‌ی کوچک به شکل یک چالش بزرگ بیان شده است.
🔑 جمع‌بندی:
پیچیدگی تکنیکی همیشه کارآمد نیست؛ Tudum نشان داد که حذف لایه‌های اضافی و نگهداری داده‌ها در حافظه می‌تواند تجربه‌ی کاربری سریع‌تر و واقعی‌تری فراهم کند. انتخاب معماری همواره یک trade-off بین سرعت و سازگاری است، و در این مورد نتفلیکس سرعت را در اولویت گذاشت.
مدرسه مهندسی داده سپهرام : @sepahram_school
مقاله اصلی : https://www.infoq.com/news/2025/08/netflix-tudum-cqrs-raw-hollow
الگوی #CQRS و معماری‌های event-driven ابزارهای قدرتمندی برای مقیاس‌پذیری هستند. اما وقتی تأخیر بین «نوشتن» و «نمایش تغییر» زیاد شود، به‌خصوص برای سناریوهای real-time مثل preview محتوا، همین الگوها می‌توانند به گلوگاه تبدیل شوند.
📌 داستان Tudum (وب‌سایت طرفداران نتفلیکس) دقیقاً ناظر به همین مساله است.
⚡️ معماری اولیه: #CQRS + #Kafka + #Cassandra
نتفلیکس وب‌سایت طرفداران Tudum را در ۲۰۲۱ راه‌اندازی کرد تا محتوای جانبی مرتبط با برنامه‌ها را به کاربران ارائه دهد و ویراستاران بتوانند تغییرات را پیش‌نمایش کنند.
داده‌ها ابتدا از CMS به سرویس ingestion می‌رفت، پردازش و روی #Kafka منتشر می‌شد، سپس در #Cassandra ذخیره و با near cache سریع‌تر به سرویس ساخت صفحات می‌رسید تا صفحات HTML برای کاربران ساخته و نمایش داده شوند. مسیر انتشار و نمایش داده‌ها جدا شد تا مقیاس‌پذیری بهتر شود، اما مشکل تأخیر cache همچنان باقی بود.
⚡️مزایا؟ تفکیک write و read و امکان scale مستقل.
⚠️ مشکل؟ ⏳ تغییرات محتوا در CMS با تأخیر زیاد روی سایت دیده می‌شد.
🔍 دلیل اصلی این تاخیر طبق گزارش نتفلیکس:
🔹کش با یک چرخه‌ی refresh به‌روزرسانی می‌شد.
🔹مثلاً اگر ۶۰ کلید داشتی و هر ثانیه یکی refresh می‌شد، تغییرات حداقل ۶۰ ثانیه بعد قابل مشاهده بود.
🔹با رشد محتوا، این زمان حتی به چند ده ثانیه می‌رسید.
🔹 برای نویسندگان و ویراستاران، این یعنی تجربه‌ی preview عملاً بی‌فایده بود.
🚀 بازطراحی: RAW Hollow به‌جای Kafka و Cassandra
به جای وصله‌پینه روی کش یا افزایش سرعت Kafka، تیم نتفلیکس یک مسیر جدید انتخاب کرد: جایگزینی کل CQRS pipeline با یک دیتابیس in-memory به نام RAW Hollow.
آدرس پروژه : https://hollow.how
ویژگی‌ها:
🔰کل dataset در حافظه‌ی هر process ذخیره می‌شود → latency بسیار پایین.
🔰پشتیبانی از strong read-after-write consistency → تغییرات بلافاصله قابل مشاهده‌اند.
🔰فشرده‌سازی Hollow حجم داده را تا ۲۵٪ نسخه‌ی اصلی کاهش می‌دهد → کل داده جا می‌شود.
🔰معماری ساده‌تر: حذف Kafka، Cassandra و cache → کمتر شدن لایه‌ها = کمتر شدن delay.
📊 نتایج برای Tudum
✨تأخیر در نمایش تغییرات: از چند ده ثانیه → به چند ثانیه.
✨زمان ساخت صفحه: از ~۱.۴s → به ~۰.۴s.
✨تجربه‌ی preview برای نویسندگان روان شد.
✨معماری تمیزتر و بدون گره‌های زائد.
💬 واکنش‌ها در Hacker News و Reddit
انتشار این تجربه بحث‌های زیادی ایجاد کرد:
🎯بعضی گفتند مشکل صرفاً cache invalidation بود و می‌شد ساده‌تر حل کرد.
🎯عده‌ای این تغییر را over-engineering دانستند برای سایتی شبیه یک بلاگ.
🎯گروهی دیگر تأکید داشتند که با مقیاس و نیاز به personalization نتفلیکس، این تصمیم منطقی است.
🎯برخی هم انتقاد کردند که مسئله‌ی کوچک به شکل یک چالش بزرگ بیان شده است.
🔑 جمع‌بندی:
پیچیدگی تکنیکی همیشه کارآمد نیست؛ Tudum نشان داد که حذف لایه‌های اضافی و نگهداری داده‌ها در حافظه می‌تواند تجربه‌ی کاربری سریع‌تر و واقعی‌تری فراهم کند. انتخاب معماری همواره یک trade-off بین سرعت و سازگاری است، و در این مورد نتفلیکس سرعت را در اولویت گذاشت.
مدرسه مهندسی داده سپهرام : @sepahram_school
مقاله اصلی : https://www.infoq.com/news/2025/08/netflix-tudum-cqrs-raw-hollow
👍5
Forwarded from مدرسه مهندسی داده سپهرام
فیلم آموزش عملی Kafka در یوتیوب – از نصب تا اجرای اولین Producer و Consumer
در جلسه چهارم 🕑، ما با مفاهیم اصلی #Kafka آشنا شدیم و یاد گرفتیم چگونه آن را به صورت لوکال و بدون Docker نصب و راه‌اندازی کنیم 🖥.
این جلسه ترکیبی از تئوری و تمرین عملی بود و شامل موارد زیر شد:
✨ مفاهیم اصلی Kafka
⚡️بروکرها، تاپیک‌ها و پارتیشن‌ها
⚡️پرودیوسرها و کانسیومرها
⚡️عملکرد #Kafka در پیام‌رسانی با توان بالا و توزیع‌شده
💻 تمرین‌های عملی با خط فرمان
⚡️راه‌اندازی بروکر Kafka به صورت محلی
⚡️ایجاد تاپیک‌ها، ارسال پیام با پرودیوسر و دریافت آن با کانسیومر
⚡️مشاهده مسیر پیام‌ها و رفتار توزیع آنها در پارتیشن‌ها
🐍 تمرین‌های عملی با پایتون
⚡️نوشتن اسکریپت‌های ساده پرودیوسر و کانسیومر
⚡️درک توزیع پیام‌ها و گروه‌های کانسیومر
⚡️مشاهده حفظ ترتیب پیام‌ها در هر پارتیشن
✅ دستاوردهای کلیدی
🔰توانایی راه‌اندازی Kafka به صورت لوکال
🔰تجربه عملی در ارسال و دریافت پیام‌ها
🔰درک پارتیشن‌ها و گروه‌های کانسیومر
🔰پایه‌ای محکم برای ساخت pipelineهای داده real-time و مقیاس‌پذیر
در جلسه دوم 🕑، نصب و راه‌اندازی Kafka با Docker و کار با انواع UI موجود در بازار آموزش داده شد. همچنین Redpanda به عنوان یک جایگزین Kafka معرفی شد. تمرین‌های عملی شامل:
🔰خواندن خودکار فایل‌ها و ارسال آنها به Kafka با Redpanda Connect
🔰راه‌اندازی یک پایپ‌لاین CDC ساده برای انتقال داده‌های درج شده و آپدیت شده در Postgres به Kafka
🎥 لینک آموزش در یوتیوب – کانال مدرسه مهندسی داده سپهرام:
https://www.youtube.com/watch?v=hLT0xOEmNQ8
📚 لیست سایر دوره‌های مدرسه مهندسی داده سپهرام:
https://sepahram.ir/courses/
💡 اگر قصد یادگیری مهندسی داده را دارید:
- هم اکنون می‌توانید سرفصل‌های دوره را مرور کنید
- برای دریافت کد تخفیف ثبت نام، به آی‌دی @sepahram_ir در تلگرام پیام بدهید
دوستانی که تاکنون با کافکا کار نکرده‌اند و می‌خواهند به صورت سریع و کاربردی با آن آشنا شوند، این دوره و به ویژه جلسات چهارم و پنجم برای شماست!
در جلسه چهارم 🕑، ما با مفاهیم اصلی #Kafka آشنا شدیم و یاد گرفتیم چگونه آن را به صورت لوکال و بدون Docker نصب و راه‌اندازی کنیم 🖥.
این جلسه ترکیبی از تئوری و تمرین عملی بود و شامل موارد زیر شد:
✨ مفاهیم اصلی Kafka
⚡️بروکرها، تاپیک‌ها و پارتیشن‌ها
⚡️پرودیوسرها و کانسیومرها
⚡️عملکرد #Kafka در پیام‌رسانی با توان بالا و توزیع‌شده
💻 تمرین‌های عملی با خط فرمان
⚡️راه‌اندازی بروکر Kafka به صورت محلی
⚡️ایجاد تاپیک‌ها، ارسال پیام با پرودیوسر و دریافت آن با کانسیومر
⚡️مشاهده مسیر پیام‌ها و رفتار توزیع آنها در پارتیشن‌ها
🐍 تمرین‌های عملی با پایتون
⚡️نوشتن اسکریپت‌های ساده پرودیوسر و کانسیومر
⚡️درک توزیع پیام‌ها و گروه‌های کانسیومر
⚡️مشاهده حفظ ترتیب پیام‌ها در هر پارتیشن
✅ دستاوردهای کلیدی
🔰توانایی راه‌اندازی Kafka به صورت لوکال
🔰تجربه عملی در ارسال و دریافت پیام‌ها
🔰درک پارتیشن‌ها و گروه‌های کانسیومر
🔰پایه‌ای محکم برای ساخت pipelineهای داده real-time و مقیاس‌پذیر
در جلسه دوم 🕑، نصب و راه‌اندازی Kafka با Docker و کار با انواع UI موجود در بازار آموزش داده شد. همچنین Redpanda به عنوان یک جایگزین Kafka معرفی شد. تمرین‌های عملی شامل:
🔰خواندن خودکار فایل‌ها و ارسال آنها به Kafka با Redpanda Connect
🔰راه‌اندازی یک پایپ‌لاین CDC ساده برای انتقال داده‌های درج شده و آپدیت شده در Postgres به Kafka
🎥 لینک آموزش در یوتیوب – کانال مدرسه مهندسی داده سپهرام:
https://www.youtube.com/watch?v=hLT0xOEmNQ8
📚 لیست سایر دوره‌های مدرسه مهندسی داده سپهرام:
https://sepahram.ir/courses/
💡 اگر قصد یادگیری مهندسی داده را دارید:
- هم اکنون می‌توانید سرفصل‌های دوره را مرور کنید
- برای دریافت کد تخفیف ثبت نام، به آی‌دی @sepahram_ir در تلگرام پیام بدهید
❤4
Forwarded from مدرسه مهندسی داده سپهرام
شروع ثبت‌نام دوره عملی PostgreSQL
در این دوره عملی، شما:
🔰 از نصب و راه‌اندازی تا طراحی دیتابیس با ERD و ایجاد جداول را یاد می‌گیرید.
🔰 نوشتن کوئری‌های پیچیده تحلیلی با JOIN، CTE و Window Function را تمرین می‌کنید.
🔰 با بهینه‌سازی کوئری‌ها، ایندکس‌ها، View و Materialized View آشنا می‌شوید.
🔰 قابلیت‌های پیشرفته‌ای مثل افزونه‌ها، MVCC، WAL، بکاپ و بازیابی، Replication و امنیت سطح ردیف را یاد می‌گیرید.
جزئیات تکمیلی دوره:
✅ دوره به صورت آنلاین برگزار می‌شود، اما هر جلسه بعد از ضبط و تدوین روی سایت قرار می‌گیرد و به صورت آفلاین نیز قابل مشاهده است (در داخل خود سپهرام).
✅در این دوره با نسخه ۱۸ PostgreSQL کار خواهیم کرد و همزمان از امکانات جدید این نسخه حرفه‌ای که در مهرماه 1404 منتشر شده است بهره می‌بریم.
✅ شرکت‌کنندگان علاوه بر گروه اختصاصی و امکان مشاهده دائمی فیلم‌های جدید دوره که به تدریج و با نسخه‌های جدید پستگرس، به روز خواهد شد، به گیت اختصاصی دوره دسترسی خواهند داشت.
با گذراندن این دوره، مهارت عملی طراحی، توسعه و نگهداری یک دیتابیس PostgreSQL حرفه‌ای را به دست خواهید آورد و می‌توانید از آن در پروژه‌های واقعی و ابزارهای تحلیلی حرفه‌ای مانند Superset، Airflow و Metabase استفاده کنید.
ثبت‌نام کنید و قدم به دنیای حرفه‌ای مدیریت داده‌های رابطه‌ای با دیتابیس محبوب پستگرس بگذارید!
https://sepahram.ir/courses/postgresql/
حتی با گسترش انواع دیتابیس‌های NoSQL و سیستم‌های تحلیلی، قلب اکثر سیستم‌های اطلاعاتی هنوز بر پایگاه‌های داده رابطه‌ای استوار است. PostgreSQL به‌عنوان یک دیتابیس متن‌باز و حرفه‌ای، ترکیبی از قدرت سنتی دیتابیس‌های رابطه‌ای و امکانات مدرن مانند JSONB، Array و افزونه‌های متنوع را ارائه می‌دهد.
در این دوره عملی، شما:
🔰 از نصب و راه‌اندازی تا طراحی دیتابیس با ERD و ایجاد جداول را یاد می‌گیرید.
🔰 نوشتن کوئری‌های پیچیده تحلیلی با JOIN، CTE و Window Function را تمرین می‌کنید.
🔰 با بهینه‌سازی کوئری‌ها، ایندکس‌ها، View و Materialized View آشنا می‌شوید.
🔰 قابلیت‌های پیشرفته‌ای مثل افزونه‌ها، MVCC، WAL، بکاپ و بازیابی، Replication و امنیت سطح ردیف را یاد می‌گیرید.
جزئیات تکمیلی دوره:
✅ دوره به صورت آنلاین برگزار می‌شود، اما هر جلسه بعد از ضبط و تدوین روی سایت قرار می‌گیرد و به صورت آفلاین نیز قابل مشاهده است (در داخل خود سپهرام).
✅در این دوره با نسخه ۱۸ PostgreSQL کار خواهیم کرد و همزمان از امکانات جدید این نسخه حرفه‌ای که در مهرماه 1404 منتشر شده است بهره می‌بریم.
✅ شرکت‌کنندگان علاوه بر گروه اختصاصی و امکان مشاهده دائمی فیلم‌های جدید دوره که به تدریج و با نسخه‌های جدید پستگرس، به روز خواهد شد، به گیت اختصاصی دوره دسترسی خواهند داشت.
با گذراندن این دوره، مهارت عملی طراحی، توسعه و نگهداری یک دیتابیس PostgreSQL حرفه‌ای را به دست خواهید آورد و می‌توانید از آن در پروژه‌های واقعی و ابزارهای تحلیلی حرفه‌ای مانند Superset، Airflow و Metabase استفاده کنید.
ثبت‌نام کنید و قدم به دنیای حرفه‌ای مدیریت داده‌های رابطه‌ای با دیتابیس محبوب پستگرس بگذارید!
https://sepahram.ir/courses/postgresql/
👍6
Forwarded from tech-afternoon (Amin Mesbahi)
🔥 🐘 انتشار PostgreSQL 18، و اهمیت تغییراتش!
طبق روال سال‌های گذشته حوالی سپتامبر ریلیز نسخه جدید PostgreSQL انجام شد. حالا چرا این نسخه برای برخی سیستم‌ها میتونه قابل توجه و مهم باشه؟
- تغییرات انقلابی در I/O (Asyn I/O):
بالاخره! این قابلیت اومد و سرعت عملیات Read رو «تا» ۳ برابر افزایش می‌ده! معطلی‌های CPU برای I/O خیلی کمتر میشه و برای کارهای مثل VACUUM و اسکن‌های بزرگ، تاثیرش چشمگیره (من روی نسخه‌های پیش‌نمایش تست کردم و عالی بود).
- پشتیبانی از UUIDv7:
برای توسعه‌دهنده‌ها این شاید خیلی مهم باشه! (اگر دوست دارید در مورد انواع UUIDها بیشتر توضیح بدم:🤪 )
پشتیبانی Native از UUIDv7 یعنی Primary Keyها به صورت گلوبال یونیک میشن و هم چون بر اساس زمان مرتب هستن، عملکرد ایندکس B-tree به شکل چشمگیری بهتر میشه. (یعنی Page Split بی مورد نداریم!)
- قابلیت Virtual Generated Columns:
حالا ستون‌های محاسباتی به‌صورت پیشفرض مجازی هستن، یعنی فقط موقع خوانش محاسبه میشن و فضای دیسک رو اشغال نمی‌کنن. (البته اگه لازم باشه، می‌تونید همچنان STORED هم تعریف کنین).
افزودن NOT NULL بدون Downtime: کابوس اضافه کردن NOT NULL به جدول‌های بزرگ تموم شد! حالا میشه قید NOT NULL رو به‌صورت NOT VALID اضافه کنیم و بلافاصله برای ردیف‌های جدید اعمال بشه. اعتبارسنجی ردیف‌های موجود رو هم می‌تونیم بعداً بدون قفل کامل جدول انجام بدیم.
- امکان Skip Scan برای B-tree:
یه بهبود عالی برای بهینه‌سازی کوئری؛ اگه توی ایندکس‌های چند ستونی، ستون اول رو در WHERE فیلتر نکرده باشیم، باز هم ایندکس کار میکنه و کوئری‌های تحلیلی/گزارش‌گیری خیلی سریع‌تر میشن.
- امکان RETURNING هوشمند:
حالا میشه توی یک دستور UPDATE یا DELETE به هر دو مقدار قدیمی (OLD) و جدید (NEW) یک ستون در بخش RETURNING دسترسی داشته باشیم.
- آپگرید آسون‌تر:
قابلیت حفظ Planner Statistics حین آپگرید با pg_upgrade باعث میشه دیتابیس جدید خیلی سریع‌تر به پرفورمنس دلخواه برگرده.
طبق روال سال‌های گذشته حوالی سپتامبر ریلیز نسخه جدید PostgreSQL انجام شد. حالا چرا این نسخه برای برخی سیستم‌ها میتونه قابل توجه و مهم باشه؟
- تغییرات انقلابی در I/O (Asyn I/O):
بالاخره! این قابلیت اومد و سرعت عملیات Read رو «تا» ۳ برابر افزایش می‌ده! معطلی‌های CPU برای I/O خیلی کمتر میشه و برای کارهای مثل VACUUM و اسکن‌های بزرگ، تاثیرش چشمگیره (من روی نسخه‌های پیش‌نمایش تست کردم و عالی بود).
- پشتیبانی از UUIDv7:
برای توسعه‌دهنده‌ها این شاید خیلی مهم باشه! (اگر دوست دارید در مورد انواع UUIDها بیشتر توضیح بدم:
پشتیبانی Native از UUIDv7 یعنی Primary Keyها به صورت گلوبال یونیک میشن و هم چون بر اساس زمان مرتب هستن، عملکرد ایندکس B-tree به شکل چشمگیری بهتر میشه. (یعنی Page Split بی مورد نداریم!)
- قابلیت Virtual Generated Columns:
حالا ستون‌های محاسباتی به‌صورت پیشفرض مجازی هستن، یعنی فقط موقع خوانش محاسبه میشن و فضای دیسک رو اشغال نمی‌کنن. (البته اگه لازم باشه، می‌تونید همچنان STORED هم تعریف کنین).
افزودن NOT NULL بدون Downtime: کابوس اضافه کردن NOT NULL به جدول‌های بزرگ تموم شد! حالا میشه قید NOT NULL رو به‌صورت NOT VALID اضافه کنیم و بلافاصله برای ردیف‌های جدید اعمال بشه. اعتبارسنجی ردیف‌های موجود رو هم می‌تونیم بعداً بدون قفل کامل جدول انجام بدیم.
- امکان Skip Scan برای B-tree:
یه بهبود عالی برای بهینه‌سازی کوئری؛ اگه توی ایندکس‌های چند ستونی، ستون اول رو در WHERE فیلتر نکرده باشیم، باز هم ایندکس کار میکنه و کوئری‌های تحلیلی/گزارش‌گیری خیلی سریع‌تر میشن.
- امکان RETURNING هوشمند:
حالا میشه توی یک دستور UPDATE یا DELETE به هر دو مقدار قدیمی (OLD) و جدید (NEW) یک ستون در بخش RETURNING دسترسی داشته باشیم.
- آپگرید آسون‌تر:
قابلیت حفظ Planner Statistics حین آپگرید با pg_upgrade باعث میشه دیتابیس جدید خیلی سریع‌تر به پرفورمنس دلخواه برگرده.
اگر جزو افرادی هستین که به مهاجرت به PostgreSQL فکر می‌کنید، یه تعداد کارت‌های شسته‌رُفته برای مهاجرت از SQL Server به PostgreSQL با هشتگ #MSSQL_to_PGSQL توی کانال داریم (کارت‌های قرمز رنگ از بخش تصاویر هم قابل پیدا کردنه)
Please open Telegram to view this post
VIEW IN TELEGRAM
🎉3👍1
تجربه استفاده از StarRocks در تیم دیتای اسنپ
پست رضا دهقانی در لینکدین
تجربه کار با StarRocks
💡 چرا StarRocks؟
استارراکس خودش رو یه دیتاوروس نسل جدید معرفی میکنه که میتونه داده‌ها رو هم بلادرنگ (Real-time) و هم Batch پردازش کنه. بدون نیاز به انتقال داده، میشه مستقیم روی Data Lake کوئری زد و با ابزارهای معمول مثل MySQL Client یا BI Tools وصل شد.
✨ تجربه شخصی من:
✅ اتصال به Iceberg خیلی خوب پشتیبانی میشه و کوئری‌ها روان اجرا میشن. کش دیتای قوی باعث میشه سرعت برخی کوئری‌ها حتی روی دیتالیک بالا باشه. این بخش تو هر نسخه جدید بهبود پیدا میکنه.
✅ جوین‌های پیچیده رو در زمان معقول اجرا میکنه بدون نیاز به تغییر ساختار داده‌ها. این قابلیت تو مدل‌سازی داده خیلی کمک کننده بود.
✅ قابلیت Materialized View به صورت Async: میشه روی دیتالیک یا هر منبع داده دیگه زمان‌بندی مشخص داد. پشتیبانی از Incremental Refresh هم داره، یعنی لازم نیست کل ویو دوباره پردازش بشه.
✅ سازگاری با Kafka و Spark: امکان خوندن و نوشتن دیتا به صورت Batch، که تو پردازش‌های ما خیلی کمک کرد.
⚠️ چالش‌ها و نکات منفی:
«بهش میگم ابزار زیبا با طراحی زشت 😅»
❌ دیپلوی کلاستر خوب مستند نشده و بعضی مواقع نیاز به تغییرات دستی داره.
❌ کانفیگ‌های زیاد: از یه زاویه خوبه ولی میتونه گیج‌کننده باشه. مقادیر پیشفرض بعضاً بهینه نیستن.
❌ امنیت هنوز جای کار داره. بعضی تنظیمات پیشفرض باز هستن، ولی سازگاری با LDAP و متدهای احراز هویت خوبه و با کمی تنظیمات قابل اصلاحه.
منبع :
https://www.linkedin.com/posts/reza-dehghani-572b3b154_dataengineering-starrocks-lakehouse-activity-7375817395812257793-B-J-
پست رضا دهقانی در لینکدین
تجربه کار با StarRocks
تو پروژه‌های کاری دنبال یه راه‌حل بودیم که بتونیم داده‌هامون رو همزمان سریع و از منابع مختلف تحلیل کنیم. بعد از بررسی ابزارهای مختلف، StarRocks رو انتخاب کردم و تجربه واقعاً متفاوت و جالبی بود.
💡 چرا StarRocks؟
استارراکس خودش رو یه دیتاوروس نسل جدید معرفی میکنه که میتونه داده‌ها رو هم بلادرنگ (Real-time) و هم Batch پردازش کنه. بدون نیاز به انتقال داده، میشه مستقیم روی Data Lake کوئری زد و با ابزارهای معمول مثل MySQL Client یا BI Tools وصل شد.
✨ تجربه شخصی من:
✅ اتصال به Iceberg خیلی خوب پشتیبانی میشه و کوئری‌ها روان اجرا میشن. کش دیتای قوی باعث میشه سرعت برخی کوئری‌ها حتی روی دیتالیک بالا باشه. این بخش تو هر نسخه جدید بهبود پیدا میکنه.
✅ جوین‌های پیچیده رو در زمان معقول اجرا میکنه بدون نیاز به تغییر ساختار داده‌ها. این قابلیت تو مدل‌سازی داده خیلی کمک کننده بود.
✅ قابلیت Materialized View به صورت Async: میشه روی دیتالیک یا هر منبع داده دیگه زمان‌بندی مشخص داد. پشتیبانی از Incremental Refresh هم داره، یعنی لازم نیست کل ویو دوباره پردازش بشه.
✅ سازگاری با Kafka و Spark: امکان خوندن و نوشتن دیتا به صورت Batch، که تو پردازش‌های ما خیلی کمک کرد.
⚠️ چالش‌ها و نکات منفی:
«بهش میگم ابزار زیبا با طراحی زشت 😅»
❌ دیپلوی کلاستر خوب مستند نشده و بعضی مواقع نیاز به تغییرات دستی داره.
❌ کانفیگ‌های زیاد: از یه زاویه خوبه ولی میتونه گیج‌کننده باشه. مقادیر پیشفرض بعضاً بهینه نیستن.
❌ امنیت هنوز جای کار داره. بعضی تنظیمات پیشفرض باز هستن، ولی سازگاری با LDAP و متدهای احراز هویت خوبه و با کمی تنظیمات قابل اصلاحه.
منبع :
https://www.linkedin.com/posts/reza-dehghani-572b3b154_dataengineering-starrocks-lakehouse-activity-7375817395812257793-B-J-
Linkedin
#dataengineering #starrocks #lakehouse #warehouse #استارراکس | Reza Dehghani
تو جریان پروژه های کاری دنبال راه‌حلی بودیم که بتونیم داده‌هامون رو همزمان سریع و از منابع مختلف تحلیل کنیم. بعد از مقایسه ابزارهای مختلف، در نهایت StarRocks رو انتخاب کردم و تجربه متفاوت و جالبی بود.
استارراکس خودش رو یه دیتاورهوس نسل جدید معرفی میکنه…
استارراکس خودش رو یه دیتاورهوس نسل جدید معرفی میکنه…
❤1👍1🙏1
مهندسی داده
Apache Doris vs ClickHouse.pdf
آپاچی دوریس و سرعت بالا در سناریوهای مبتنی بر JOIN
- توضیحی راجع به pdf بالا ـ
اخیراً گزارشی از سمت VeloDB (Powered by Apache Doris) منتشر شد که در آن، عملکرد Apache Doris و ClickHouse در سناریوهای سنگین مبتنی بر JOIN و کوئری‌های تحلیلی پیچیده با هم مقایسه شده‌اند.
در همین زمینه، تجربه اخیر اسنپ‌فود با StarRocks (که رضا دهقانی در پست زیر به آن اشاره کرده بود) هم نشان می‌دهد که انتخاب دیتابیس تحلیلی تصمیمی وابسته به نیازها و شرایط سازمان است و یک پاسخ واحد برای همه سناریوها وجود ندارد.
https://lnkd.in/dvc76Dxa
خلاصه عملکرد (Benchmark Results)
در تست‌ها مشخص شد که در سناریوی CoffeeBench (که به شدت بر JOIN متکی است)، Doris حدود ۴ برابر سریع‌تر از ClickHouse عمل کرده است. در مجموعه تست‌های TPC-H که بار تحلیلی پیچیده‌تری دارند، سرعت Doris تا ۳۰ برابر بیشتر گزارش شد. و در نهایت در سناریوهای سنگین‌تر TPC-DS، Doris تا ۴۰ برابر سریع‌تر از ClickHouse نتیجه گرفت.
⚙️ مشخصات تست (Test Config):
- 2 × AWS m6i.8xlarge (هرکدام 32 vCPU و 128GiB RAM)
- Apache Doris v3.0.7 در برابر ClickHouse v25.8
- On-premises
📌 لازم به ذکر است که CoffeeBench در ابتدا توسط Josue “Josh” Bogran برای مقایسه Databricks و Snowflake طراحی شده بود، اما به دلیل ماهیت JOIN-heavy خود، اکنون به یکی از معیارهای پرکاربرد برای سنجش دیتابیس‌های تحلیلی تبدیل شده است.
#doris #starrocks #clickhouse
- توضیحی راجع به pdf بالا ـ
اخیراً گزارشی از سمت VeloDB (Powered by Apache Doris) منتشر شد که در آن، عملکرد Apache Doris و ClickHouse در سناریوهای سنگین مبتنی بر JOIN و کوئری‌های تحلیلی پیچیده با هم مقایسه شده‌اند.
من این گزارش را اینجا بازنشر می‌کنم تا برای دوستانی که به دنبال یک راهکار تحلیلی سریع و مشابه دنیای دیتابیس‌های رابطه‌ای هستند، مفید باشد. به‌ویژه برای کسانی که نیاز به تضمین یکتایی کلید اصلی و اجرای JOINهای متعدد دارند، اما امکان ایجاد جداول denormalized در ClickHouse برایشان مقدور نیست.
در همین زمینه، تجربه اخیر اسنپ‌فود با StarRocks (که رضا دهقانی در پست زیر به آن اشاره کرده بود) هم نشان می‌دهد که انتخاب دیتابیس تحلیلی تصمیمی وابسته به نیازها و شرایط سازمان است و یک پاسخ واحد برای همه سناریوها وجود ندارد.
https://lnkd.in/dvc76Dxa
خلاصه عملکرد (Benchmark Results)
در تست‌ها مشخص شد که در سناریوی CoffeeBench (که به شدت بر JOIN متکی است)، Doris حدود ۴ برابر سریع‌تر از ClickHouse عمل کرده است. در مجموعه تست‌های TPC-H که بار تحلیلی پیچیده‌تری دارند، سرعت Doris تا ۳۰ برابر بیشتر گزارش شد. و در نهایت در سناریوهای سنگین‌تر TPC-DS، Doris تا ۴۰ برابر سریع‌تر از ClickHouse نتیجه گرفت.
⚙️ مشخصات تست (Test Config):
- 2 × AWS m6i.8xlarge (هرکدام 32 vCPU و 128GiB RAM)
- Apache Doris v3.0.7 در برابر ClickHouse v25.8
- On-premises
📌 لازم به ذکر است که CoffeeBench در ابتدا توسط Josue “Josh” Bogran برای مقایسه Databricks و Snowflake طراحی شده بود، اما به دلیل ماهیت JOIN-heavy خود، اکنون به یکی از معیارهای پرکاربرد برای سنجش دیتابیس‌های تحلیلی تبدیل شده است.
#doris #starrocks #clickhouse
Linkedin
#dataengineering #starrocks #lakehouse #warehouse #استارراکس | Reza Dehghani
تو جریان پروژه های کاری دنبال راه‌حلی بودیم که بتونیم داده‌هامون رو همزمان سریع و از منابع مختلف تحلیل کنیم. بعد از مقایسه ابزارهای مختلف، در نهایت StarRocks رو انتخاب کردم و تجربه متفاوت و جالبی بود.
استارراکس خودش رو یه دیتاورهوس نسل جدید معرفی میکنه…
استارراکس خودش رو یه دیتاورهوس نسل جدید معرفی میکنه…
👍2🙏1
Forwarded from عکس نگار
شروع ثبت‌نام دوره تخصصی Apache Kafka – آموزش صفر تا صد
امروز داده‌ها فقط به صورت Batch پردازش نمی‌شوند؛ حجم عظیمی از رویدادها مثل 📈 تراکنش‌های بانکی، 🛒 سفارش‌های آنلاین، 🎬 رفتار کاربران و 📡 داده‌های حسگرها باید در لحظه پردازش شوند.
اینجاست که Apache Kafka به‌عنوان ستون فقرات جریان داده در معماری‌های مدرن وارد می‌شود؛ ابزاری توزیع‌شده و مقیاس‌پذیر که توانایی مدیریت میلیون‌ها پیام در ثانیه با حداقل تأخیر را دارد.
🔹 در این دوره جامع و کاملاً عملی شما:
🔰 از مفاهیم پایه Kafka (Broker، Topic، Partition، Offset، Producer و Consumer) تا ساخت اولین پایپ‌لاین داده‌ای خود را یاد می‌گیرید.
🔰 با ابزارهای کلیدی اکوسیستم مثل Kafka Connect، Schema Registry و KSQLDB کار می‌کنید.
🔰 پایپ‌لاین‌های بلادرنگ و مقاوم در برابر خطا طراحی می‌کنید.
🔰 با پروژه‌های پیشرفته مثل Redpanda، AutoMQ و ابزارهای پردازش جریان (Spark Streaming، FastStream، RisingWave و …) آشنا می‌شوید.
🔰در نهایت یک پایپ‌لاین ETL حرفه‌ای با Go پیاده‌سازی می‌کنید.
📚 جزئیات دوره:
مدت زمان: ۲۲ ساعت (۱۱ جلسه)
سطح: مقدماتی تا متوسط (با پیش‌نیاز آشنایی با داکر و پایتون)
شروع: پنج‌شنبه ۱۰ مهرماه ۱۴۰۴
ظرفیت: ۳۰ نفر
زمان برگزاری: پنج‌شنبه‌ها ساعت ۱۰ تا ۱۲ و یکشنبه‌ها ساعت ۲۰ تا ۲۲
مدرس : مجتبی بنائی
همراه با پروژه‌های عملی، دسترسی به گیت اختصاصی دوره و پشتیبانی مدرس
🎯 این دوره ترکیبی از آموزش تئوری + تمرین عملی + نکات بهینه‌سازی است تا شما را برای طراحی سیستم‌های واقعی و مقیاس‌پذیر آماده کند.
💡جزئیات تکمیلی دوره:
✅ دوره به صورت آنلاین برگزار می‌شود، اما هر جلسه بعد از ضبط و تدوین روی سایت قرار می‌گیرد و به صورت آفلاین نیز قابل مشاهده است (در داخل خود سایت سپهرام).
✅در این دوره با نسخه ۴ کافکا کار خواهیم کرد و همزمان از امکانات جدید این نسخه حرفه‌ای بهره می‌بریم.
✅ شرکت‌کنندگان علاوه بر گروه اختصاصی و امکان مشاهده دائمی فیلم‌های جدید دوره که به تدریج و با نسخه‌های جدید کافکا، به روز خواهد شد، به گیت اختصاصی دوره دسترسی خواهند داشت.
برای مشاهده سرفصل‌های این دوره و ثبت نام از لینک زیر استفاده کنید:
https://sepahram.ir/courses/apachekafka-redpanda/
https://t.iss.one/sepahram_school
امروز داده‌ها فقط به صورت Batch پردازش نمی‌شوند؛ حجم عظیمی از رویدادها مثل 📈 تراکنش‌های بانکی، 🛒 سفارش‌های آنلاین، 🎬 رفتار کاربران و 📡 داده‌های حسگرها باید در لحظه پردازش شوند.
اینجاست که Apache Kafka به‌عنوان ستون فقرات جریان داده در معماری‌های مدرن وارد می‌شود؛ ابزاری توزیع‌شده و مقیاس‌پذیر که توانایی مدیریت میلیون‌ها پیام در ثانیه با حداقل تأخیر را دارد.
🔹 در این دوره جامع و کاملاً عملی شما:
🔰 از مفاهیم پایه Kafka (Broker، Topic، Partition، Offset، Producer و Consumer) تا ساخت اولین پایپ‌لاین داده‌ای خود را یاد می‌گیرید.
🔰 با ابزارهای کلیدی اکوسیستم مثل Kafka Connect، Schema Registry و KSQLDB کار می‌کنید.
🔰 پایپ‌لاین‌های بلادرنگ و مقاوم در برابر خطا طراحی می‌کنید.
🔰 با پروژه‌های پیشرفته مثل Redpanda، AutoMQ و ابزارهای پردازش جریان (Spark Streaming، FastStream، RisingWave و …) آشنا می‌شوید.
🔰در نهایت یک پایپ‌لاین ETL حرفه‌ای با Go پیاده‌سازی می‌کنید.
📚 جزئیات دوره:
مدت زمان: ۲۲ ساعت (۱۱ جلسه)
سطح: مقدماتی تا متوسط (با پیش‌نیاز آشنایی با داکر و پایتون)
شروع: پنج‌شنبه ۱۰ مهرماه ۱۴۰۴
ظرفیت: ۳۰ نفر
زمان برگزاری: پنج‌شنبه‌ها ساعت ۱۰ تا ۱۲ و یکشنبه‌ها ساعت ۲۰ تا ۲۲
مدرس : مجتبی بنائی
همراه با پروژه‌های عملی، دسترسی به گیت اختصاصی دوره و پشتیبانی مدرس
🎯 این دوره ترکیبی از آموزش تئوری + تمرین عملی + نکات بهینه‌سازی است تا شما را برای طراحی سیستم‌های واقعی و مقیاس‌پذیر آماده کند.
💡جزئیات تکمیلی دوره:
✅ دوره به صورت آنلاین برگزار می‌شود، اما هر جلسه بعد از ضبط و تدوین روی سایت قرار می‌گیرد و به صورت آفلاین نیز قابل مشاهده است (در داخل خود سایت سپهرام).
✅در این دوره با نسخه ۴ کافکا کار خواهیم کرد و همزمان از امکانات جدید این نسخه حرفه‌ای بهره می‌بریم.
✅ شرکت‌کنندگان علاوه بر گروه اختصاصی و امکان مشاهده دائمی فیلم‌های جدید دوره که به تدریج و با نسخه‌های جدید کافکا، به روز خواهد شد، به گیت اختصاصی دوره دسترسی خواهند داشت.
برای مشاهده سرفصل‌های این دوره و ثبت نام از لینک زیر استفاده کنید:
https://sepahram.ir/courses/apachekafka-redpanda/
https://t.iss.one/sepahram_school
زیرساخت پردازش داده در OpenAI با Kafka، Flink و GenAI
در رویداد Current 2025، مهندسان OpenAI از پشت‌صحنه‌ی یکی از مهم‌ترین بخش‌های هوش مصنوعی پرده برداشتند:
این سیستم بر پایه‌ی دو ابزار کلیدی ساخته شده:
✅ آپاچی کافکا برای جابجایی داده‌ها
✅ آپاچی فلینک برای پردازش لحظه‌ای
و همه این‌ها در خدمت Generative AI و Agentic AI قرار گرفته‌اند.
🎯 چرا مهم است؟
مدل‌های بزرگ هوش مصنوعی بدون داده‌ی درست و به‌موقع عملاً بی‌فایده‌اند.
وقتی پای Agentic AI وسط باشد (جایی که هوش مصنوعی خودش تصمیم می‌گیرد، یاد می‌گیرد و واکنش نشان می‌دهد)، اهمیت داده‌ی لحظه‌ای حتی چند برابر می‌شود.
مهم‌ترین نکات از جلسات فنی OpenAI
1. ساخت پلتفرم پردازش جریانی با Flink و Kafka
✨ اجرای PyFlink در مقیاس بزرگ با تغییرات اختصاصی
✨استفاده از Kubernetes برای مدیریت و ایزوله‌سازی کلاسترها
✨ معماری چند-منطقه‌ای (Multi-Region) برای مدیریت Failover و تکرار داده
✨ کافکا هم به‌عنوان منبع (Source) و هم مقصد (Sink) در خط پردازش استفاده می‌شود
2. ساده‌سازی مصرف Kafka با Kafka Forwarder
✨تبدیل مصرف Pull-based به مدل Push-based با gRPC
✨مدیریت ساده‌تر پارتیشن‌ها، Retryها و DLQ
✨ارسال مستقیم داده‌ها به سرویس‌های پایین‌دستی مثل Databricks
✨معماری الهام‌گرفته از Uber uForwarder برای کاهش بار عملیاتی
3. مدیریت حرفه‌ای Kafka بدون Downtime
✨معماری چندکلاستری برای Kafka و Flink
✨مدیریت حرفه‌ای Rebalancing و Producer Redirection
✨تجربه‌های واقعی از مهاجرت در مقیاس جهانی
✨ابزارها و الگوهای عملی برای Failover و ارتقا ایمن
جزئیات بیشتر از Current London: پردازش Embeddings و Features لحظه‌ای
تیم OpenAI نشان داد چطور Flink را برای محیط AI-first و Python-heavy تغییر داده:
🔰ترکیب پایتون برای توسعه سریع و جاوا برای عملکرد بهتر
🔰مدیریت Orchestration از طریق Flink Kubernetes Operator
🔰افزایش دسترس‌پذیری Kafka با توسعه کانکتورها و Union کردن استریم‌ها
🔰ذخیره State با RocksDB و Blob Storage تا بتوانند کلاسترها را بدون از دست دادن داده جابه‌جا کنند
موارد کاربردی که ترکیب کافکا و فلینک برای OpenAI به همراه داشته است:
🔰تولید مداوم داده‌های آموزشی تازه برای مدل‌ها
🔰پردازش تست‌ها در لحظه برای تسریع توسعه
🔰ساخت Embedding لحظه‌ای برای جستجو و بازیابی سریع
🔰تولید Featureهای مدل ML در لحظه و استقرار خودکار
🔰پردازش داده‌های حجیم بدون قفل کردن جریان
💡 جمع‌بندی
آنچه OpenAI در Current 2025 نشان داد، یک نکته‌ی مهم دارد:
🌟 هوش مصنوعی قوی بدون زیرساخت داده‌ی قوی ممکن نیست.
🌟کافکا و Flink تبدیل به ستون فقرات پردازش داده در OpenAI شده‌اند؛ سیستمی که داده‌ها را لحظه‌ای و پایدار به مدل‌ها می‌رساند.
برای هر سازمانی که به فکر استفاده از AI است، درس روشن است:
.
این ارائه ارزشمند و ۴۵ دقیقه‌ای از OpenAI که در مورد این موضوع مهم و نحوه طراحی زیرساخت دیتای این شرکت صحبت می‌کند را از دست ندهید ؛
https://current.confluent.io/post-conference-videos-2025/building-stream-processing-platform-at-openai-lnd25
- شروع ثبت نام دوره کافکا و پستگرس مدرسه مهندسی داده سپهرام :
https://sepahram.ir/courses
در رویداد Current 2025، مهندسان OpenAI از پشت‌صحنه‌ی یکی از مهم‌ترین بخش‌های هوش مصنوعی پرده برداشتند:
چطور داده‌های عظیم و لحظه‌ای را مدیریت می‌کنند تا مدل‌های هوش مصنوعی همیشه تازه، سریع و قابل اعتماد باشند.
این سیستم بر پایه‌ی دو ابزار کلیدی ساخته شده:
✅ آپاچی کافکا برای جابجایی داده‌ها
✅ آپاچی فلینک برای پردازش لحظه‌ای
و همه این‌ها در خدمت Generative AI و Agentic AI قرار گرفته‌اند.
🎯 چرا مهم است؟
مدل‌های بزرگ هوش مصنوعی بدون داده‌ی درست و به‌موقع عملاً بی‌فایده‌اند.
وقتی پای Agentic AI وسط باشد (جایی که هوش مصنوعی خودش تصمیم می‌گیرد، یاد می‌گیرد و واکنش نشان می‌دهد)، اهمیت داده‌ی لحظه‌ای حتی چند برابر می‌شود.
مهم‌ترین نکات از جلسات فنی OpenAI
1. ساخت پلتفرم پردازش جریانی با Flink و Kafka
✨ اجرای PyFlink در مقیاس بزرگ با تغییرات اختصاصی
✨استفاده از Kubernetes برای مدیریت و ایزوله‌سازی کلاسترها
✨ معماری چند-منطقه‌ای (Multi-Region) برای مدیریت Failover و تکرار داده
✨ کافکا هم به‌عنوان منبع (Source) و هم مقصد (Sink) در خط پردازش استفاده می‌شود
2. ساده‌سازی مصرف Kafka با Kafka Forwarder
✨تبدیل مصرف Pull-based به مدل Push-based با gRPC
✨مدیریت ساده‌تر پارتیشن‌ها، Retryها و DLQ
✨ارسال مستقیم داده‌ها به سرویس‌های پایین‌دستی مثل Databricks
✨معماری الهام‌گرفته از Uber uForwarder برای کاهش بار عملیاتی
3. مدیریت حرفه‌ای Kafka بدون Downtime
✨معماری چندکلاستری برای Kafka و Flink
✨مدیریت حرفه‌ای Rebalancing و Producer Redirection
✨تجربه‌های واقعی از مهاجرت در مقیاس جهانی
✨ابزارها و الگوهای عملی برای Failover و ارتقا ایمن
جزئیات بیشتر از Current London: پردازش Embeddings و Features لحظه‌ای
تیم OpenAI نشان داد چطور Flink را برای محیط AI-first و Python-heavy تغییر داده:
🔰ترکیب پایتون برای توسعه سریع و جاوا برای عملکرد بهتر
🔰مدیریت Orchestration از طریق Flink Kubernetes Operator
🔰افزایش دسترس‌پذیری Kafka با توسعه کانکتورها و Union کردن استریم‌ها
🔰ذخیره State با RocksDB و Blob Storage تا بتوانند کلاسترها را بدون از دست دادن داده جابه‌جا کنند
موارد کاربردی که ترکیب کافکا و فلینک برای OpenAI به همراه داشته است:
🔰تولید مداوم داده‌های آموزشی تازه برای مدل‌ها
🔰پردازش تست‌ها در لحظه برای تسریع توسعه
🔰ساخت Embedding لحظه‌ای برای جستجو و بازیابی سریع
🔰تولید Featureهای مدل ML در لحظه و استقرار خودکار
🔰پردازش داده‌های حجیم بدون قفل کردن جریان
💡 جمع‌بندی
آنچه OpenAI در Current 2025 نشان داد، یک نکته‌ی مهم دارد:
🌟 هوش مصنوعی قوی بدون زیرساخت داده‌ی قوی ممکن نیست.
🌟کافکا و Flink تبدیل به ستون فقرات پردازش داده در OpenAI شده‌اند؛ سیستمی که داده‌ها را لحظه‌ای و پایدار به مدل‌ها می‌رساند.
برای هر سازمانی که به فکر استفاده از AI است، درس روشن است:
اگر می‌خواهید سیستم هوشمند داشته باشید، از زیرساخت داده شروع کنید
.
این ارائه ارزشمند و ۴۵ دقیقه‌ای از OpenAI که در مورد این موضوع مهم و نحوه طراحی زیرساخت دیتای این شرکت صحبت می‌کند را از دست ندهید ؛
https://current.confluent.io/post-conference-videos-2025/building-stream-processing-platform-at-openai-lnd25
- شروع ثبت نام دوره کافکا و پستگرس مدرسه مهندسی داده سپهرام :
https://sepahram.ir/courses
👍4
و قتی سادگی پشت تجربه پنهان است: نکات کلیدی نگهداری Kafka
یکی از نمونه‌های خوب آن، مصاحبه‌ای است که سال گذشته Stanislav Kozlovski، مهندس ارشد سابق در Confluent و کسی که در لینکدین به عنوان The Kafka Guy شناخته می‌شود، ارائه داد.
او کسی است که بیش از ۶ سال روی بزرگ‌ترین Kafka SaaS دنیا کار کرده، با هزاران مشتری و صدها رخداد (incident) سر و کار داشته و حاصل این تجربه را در قالب مجموعه‌ای از توصیه‌های ساده اما کلیدی، هم در حوزه رشد فردی و رهبری تیم‌های نرم‌افزاری و هم در زمینه مدیریت حرفه‌ای کلاسترهای Kafka با ما به اشتراک گذاشته است.
🔑 توصیه‌های کلیدی برای رشد شغلی مهندسان نرم‌افزار
🌟خواسته‌تان را شفاف کنید: اگر رشد می‌خواهید، آن را علنی بیان کنید و از مدیر خود بپرسید چه مسیری برای رسیدن به سطح بالاتر لازم است.
🌟تمرکز هوشمندانه داشته باشید: سخت کار کردن کافی نیست؛ باید روی کارهایی تمرکز کنید که بیشترین اثر را می‌گذارند.
🌟 فراتر از نقش خود بیندیشید: حتی در جایگاه جونیور، دید کلان به سیستم داشته باشید.
🌟 اشتباه را بپذیرید: تنها اشتباهی که غیرقابل قبول است، تکرار اشتباه قبلی است.
🌟 ایگو را کنار بگذارید: کنجکاوی و یادگیری از همکاران باتجربه بزرگ‌ترین سرمایه شماست.
👥 توصیه‌های او در رهبری تیم‌های نرم‌افزاری
✨ در دسترس باشید: جلسات One-on-One ساده‌ترین راه برای رفع موانع تیم است.
✨ اعتمادسازی کنید: بدون اعتماد، حقیقت مسائل تیم هیچ‌گاه به رهبر منتقل نمی‌شود.
✨ با عمل، نه با حرف: فرهنگ تیم حاصل رفتار رهبر است، نه صرفاً شعارهای او.
⚙️ توصیه‌های فنی و حرفه‌ای درباره Kafka
تجربه‌ی Stan از صدها incident در مقیاس جهانی باعث شده مجموعه‌ای از نکات به ظاهر ساده اما بسیار کاربردی را مطرح کند:
🔰مانیتورینگ و متریک‌ها:
بدون متریک‌های درست، شما در تاریکی حرکت می‌کنید. داشتن داشبوردهای شفاف برای latency، lag، throughput و error rates حیاتی است. هشدارها باید عملی باشند؛ یعنی اگر آلارمی به صدا درآمد، دقیقاً بدانید چه دستورالعمل (Runbook)ای را باید دنبال کنید.
🔰ارتقاء فعال (Proactive Upgrades):
برخلاف تصور رایج، Kafka به‌قدری پایدار است که بسیاری تیم‌ها به‌روزرسانی را به تعویق می‌اندازند. اما Stan تأکید می‌کند که این کار خطرناک است؛ چرا که باگ‌ها و تغییرات امنیتی در نسخه‌های جدید رفع می‌شوند و تنها راه استفاده از بهبودهای مهم، ارتقاء منظم است.
🔰استفاده از کلاینت‌های معتبر:
بسیاری از مشکلات بزرگ Kafka نه در خود بروکرها، بلکه در کلاینت‌های ناسازگار یا تنظیمات ضعیف به وجود می‌آید. انتخاب کلاینت‌های رسمی یا کلاینت‌های به‌خوبی پشتیبانی‌شده یکی از کلیدهای ثبات است.
🔰 برنامه‌ریزی ظرفیت (Capacity Planning):
کلاستر Kafka باید همیشه فضای تنفسی داشته باشد. اگر همه بروکرها در بالاترین ظرفیت کار کنند، هر اتفاق کوچک (مثل افت یکی از نودها) می‌تواند بحران‌ساز شود. داشتن طرحی برای افزودن سریع بروکرهای جدید در مواقع فشار، یک اصل حیاتی است.
🔰تست عملکرد و استرس:
کافکا انعطاف‌پذیری فوق‌العاده‌ای دارد؛ اما این انعطاف بدون تست بی‌معنی است. سرمایه‌گذاری در تست‌های بار (load tests) و استرس تست‌ها باعث می‌شود قبل از مشتریان‌تان متوجه مشکلات احتمالی شوید. Stan حتی توصیه می‌کند تنظیمات کلاینت‌ها و سرورها را بارها تغییر دهید و تحت سناریوهای مختلف بسنجید.
🔰دستورالعمل‌های عملیاتی (Runbooks):
داشتن دستورالعمل روشن برای پاسخ به مشکلات رایج (از lag بالا گرفته تا broker failure) باعث می‌شود تیم در شرایط بحرانی به جای سراسیمگی، بر اساس رویه‌ای مستند عمل کند.
🔰آمادگی برای Incidentها:
استن تأکید می‌کند که کار با Kafka در مقیاس بزرگ "مین‌گذاری" است. باید انتظار رخدادها را داشته باشید، تیم را برای آنها آماده کنید و بعد از هر حادثه، جلسه post-mortem واقعی داشته باشید تا یادگیری جمعی حاصل شود.
🎥 این ویدئو با عنوان Leveling up your Software Engineering Career در یوتیوب منتشر شده است و در آدرس زیر قابل مشاهده است :
https://www.youtube.com/watch?v=4EVPMpXPGdg
این صحبت‌ها برای من یادآوری بود که گاهی ساده‌ترین پاسخ‌ها، حاصل پیچیده‌ترین تجربه‌ها هستند.
شروع ثبت نام دوره تخصصی کافکا : https://sepahram.ir/courses
گاهی وقتی از یک متخصص واقعی در حوزه نرم‌افزار سوالات فنی می‌پرسید، پاسخ‌ها در ظاهر بسیار ساده‌اند؛ اما در عمل پر از نکات عمیق و تجربه‌های ارزشمند هستند.
یکی از نمونه‌های خوب آن، مصاحبه‌ای است که سال گذشته Stanislav Kozlovski، مهندس ارشد سابق در Confluent و کسی که در لینکدین به عنوان The Kafka Guy شناخته می‌شود، ارائه داد.
او کسی است که بیش از ۶ سال روی بزرگ‌ترین Kafka SaaS دنیا کار کرده، با هزاران مشتری و صدها رخداد (incident) سر و کار داشته و حاصل این تجربه را در قالب مجموعه‌ای از توصیه‌های ساده اما کلیدی، هم در حوزه رشد فردی و رهبری تیم‌های نرم‌افزاری و هم در زمینه مدیریت حرفه‌ای کلاسترهای Kafka با ما به اشتراک گذاشته است.
🔑 توصیه‌های کلیدی برای رشد شغلی مهندسان نرم‌افزار
🌟خواسته‌تان را شفاف کنید: اگر رشد می‌خواهید، آن را علنی بیان کنید و از مدیر خود بپرسید چه مسیری برای رسیدن به سطح بالاتر لازم است.
🌟تمرکز هوشمندانه داشته باشید: سخت کار کردن کافی نیست؛ باید روی کارهایی تمرکز کنید که بیشترین اثر را می‌گذارند.
🌟 فراتر از نقش خود بیندیشید: حتی در جایگاه جونیور، دید کلان به سیستم داشته باشید.
🌟 اشتباه را بپذیرید: تنها اشتباهی که غیرقابل قبول است، تکرار اشتباه قبلی است.
🌟 ایگو را کنار بگذارید: کنجکاوی و یادگیری از همکاران باتجربه بزرگ‌ترین سرمایه شماست.
👥 توصیه‌های او در رهبری تیم‌های نرم‌افزاری
✨ در دسترس باشید: جلسات One-on-One ساده‌ترین راه برای رفع موانع تیم است.
✨ اعتمادسازی کنید: بدون اعتماد، حقیقت مسائل تیم هیچ‌گاه به رهبر منتقل نمی‌شود.
✨ با عمل، نه با حرف: فرهنگ تیم حاصل رفتار رهبر است، نه صرفاً شعارهای او.
⚙️ توصیه‌های فنی و حرفه‌ای درباره Kafka
تجربه‌ی Stan از صدها incident در مقیاس جهانی باعث شده مجموعه‌ای از نکات به ظاهر ساده اما بسیار کاربردی را مطرح کند:
🔰مانیتورینگ و متریک‌ها:
بدون متریک‌های درست، شما در تاریکی حرکت می‌کنید. داشتن داشبوردهای شفاف برای latency، lag، throughput و error rates حیاتی است. هشدارها باید عملی باشند؛ یعنی اگر آلارمی به صدا درآمد، دقیقاً بدانید چه دستورالعمل (Runbook)ای را باید دنبال کنید.
🔰ارتقاء فعال (Proactive Upgrades):
برخلاف تصور رایج، Kafka به‌قدری پایدار است که بسیاری تیم‌ها به‌روزرسانی را به تعویق می‌اندازند. اما Stan تأکید می‌کند که این کار خطرناک است؛ چرا که باگ‌ها و تغییرات امنیتی در نسخه‌های جدید رفع می‌شوند و تنها راه استفاده از بهبودهای مهم، ارتقاء منظم است.
🔰استفاده از کلاینت‌های معتبر:
بسیاری از مشکلات بزرگ Kafka نه در خود بروکرها، بلکه در کلاینت‌های ناسازگار یا تنظیمات ضعیف به وجود می‌آید. انتخاب کلاینت‌های رسمی یا کلاینت‌های به‌خوبی پشتیبانی‌شده یکی از کلیدهای ثبات است.
🔰 برنامه‌ریزی ظرفیت (Capacity Planning):
کلاستر Kafka باید همیشه فضای تنفسی داشته باشد. اگر همه بروکرها در بالاترین ظرفیت کار کنند، هر اتفاق کوچک (مثل افت یکی از نودها) می‌تواند بحران‌ساز شود. داشتن طرحی برای افزودن سریع بروکرهای جدید در مواقع فشار، یک اصل حیاتی است.
🔰تست عملکرد و استرس:
کافکا انعطاف‌پذیری فوق‌العاده‌ای دارد؛ اما این انعطاف بدون تست بی‌معنی است. سرمایه‌گذاری در تست‌های بار (load tests) و استرس تست‌ها باعث می‌شود قبل از مشتریان‌تان متوجه مشکلات احتمالی شوید. Stan حتی توصیه می‌کند تنظیمات کلاینت‌ها و سرورها را بارها تغییر دهید و تحت سناریوهای مختلف بسنجید.
🔰دستورالعمل‌های عملیاتی (Runbooks):
داشتن دستورالعمل روشن برای پاسخ به مشکلات رایج (از lag بالا گرفته تا broker failure) باعث می‌شود تیم در شرایط بحرانی به جای سراسیمگی، بر اساس رویه‌ای مستند عمل کند.
🔰آمادگی برای Incidentها:
استن تأکید می‌کند که کار با Kafka در مقیاس بزرگ "مین‌گذاری" است. باید انتظار رخدادها را داشته باشید، تیم را برای آنها آماده کنید و بعد از هر حادثه، جلسه post-mortem واقعی داشته باشید تا یادگیری جمعی حاصل شود.
🎥 این ویدئو با عنوان Leveling up your Software Engineering Career در یوتیوب منتشر شده است و در آدرس زیر قابل مشاهده است :
https://www.youtube.com/watch?v=4EVPMpXPGdg
این صحبت‌ها برای من یادآوری بود که گاهی ساده‌ترین پاسخ‌ها، حاصل پیچیده‌ترین تجربه‌ها هستند.
شروع ثبت نام دوره تخصصی کافکا : https://sepahram.ir/courses
👍4❤1
از Postgres تا Lakehouse زنده در کمتر از یک ثانیه - نگاهی به Mooncake و استراتژی جسورانه Databricks
مدت‌ها بود که پروژه Pg_mooncake رو زیر نظر داشتم تا ببینم کی به مرحله نهایی می‌رسه ، پروژه‌ای نوآور که می‌خواست Postgres رو با Iceberg ترکیب کنه و داده‌های تحلیلی و عملیاتی رو روی یک پایه مشترک بیاره.
و حالا… دیدم که Databricks این تیم خلاق رو هم خریداری کرده! درست مثل خرید قبلی‌شون یعنی Neon (نسخه‌ی cloud-native از Postgres).
لینک خبر :
https://www.linkedin.com/posts/databricks_were-excited-to-announce-that-databricks-activity-7379138538652696576-2pbr
💡 اما Mooncake دقیقاً چی بود و چرا مهمه؟
به زبان ساده، Mooncake کمک میکنه داده‌هایی که در Postgres ذخیره میشن به کمک یک افزونه پستگرس که با rust نوشته شده، تقریباً بلافاصله و بدون نیاز به ابزارهای پیچیده، داخل یک لیک‌هوس با فرمت آیس‌برگ یا دلتا ذخیره شده و برای تحلیل و گزارش های سنگین با انواع کوئری انجین ها مثل ترینو، استارراکز، اسپارک و حتی کلیک‌هوس آماده بشن.
با ترکیب Postgres و Iceberg و با استفاده از امکانات خود mooncake:
🔰 داده‌ها به‌صورت زنده (real-time) همگام میشن حتی با آپدیت و حذف
🔰 تحلیل‌ها با کمک DuckDB سریع انجام میشن،
🔰 و همه‌چی بدون پیچیدگی ETL یا کپی‌کاری، در همون لحظه قابل استفاده‌ست.
یه جور پل بین ذخیره‌سازی عملیاتی و تحلیل زنده‌ست - دقیقاً همون چیزی که خیلی از شرکت‌ها مدت‌هاست دنبالش بودن.
🎯 واقعاً مشخص نیست دقیقاً چه استراتژی بزرگی پشت این خریدهاست، اما چیزی که واضحه اینه که Databricks داره آینده پایگاه‌های داده Postgres-محور رو با هوش مصنوعی و تحلیل real-time بازتعریف میکنه.
👋 به تیم Mooncake تبریک میگم، و مشتاقم ببینم در ادامه چه اتفاقات بزرگی رقم می‌زنن!
شروع رسمی دوره پستگرس کاربردی در مدرسه مهندسی داده سپهرام:
https://sepahram.ir/courses/
#Databricks #Mooncake #Postgres #Iceberg #Lakehouse #OLTP #AI #Lakebase #DataEngineering #OpenSourc
مدت‌ها بود که پروژه Pg_mooncake رو زیر نظر داشتم تا ببینم کی به مرحله نهایی می‌رسه ، پروژه‌ای نوآور که می‌خواست Postgres رو با Iceberg ترکیب کنه و داده‌های تحلیلی و عملیاتی رو روی یک پایه مشترک بیاره.
و حالا… دیدم که Databricks این تیم خلاق رو هم خریداری کرده! درست مثل خرید قبلی‌شون یعنی Neon (نسخه‌ی cloud-native از Postgres).
لینک خبر :
https://www.linkedin.com/posts/databricks_were-excited-to-announce-that-databricks-activity-7379138538652696576-2pbr
به‌نظر می‌رسه دیتابریکز داره با قدرت وارد فضای Lakehouse + OLTP + AI میشه. چیزی که خودشون اسمش رو گذاشتن Lakebase؛ پایگاه‌داده‌ای مبتنی بر Postgres که برای Agentهای هوش مصنوعی بهینه‌سازی شده و عملاً نیاز به ETL رو از بین می‌بره.
💡 اما Mooncake دقیقاً چی بود و چرا مهمه؟
به زبان ساده، Mooncake کمک میکنه داده‌هایی که در Postgres ذخیره میشن به کمک یک افزونه پستگرس که با rust نوشته شده، تقریباً بلافاصله و بدون نیاز به ابزارهای پیچیده، داخل یک لیک‌هوس با فرمت آیس‌برگ یا دلتا ذخیره شده و برای تحلیل و گزارش های سنگین با انواع کوئری انجین ها مثل ترینو، استارراکز، اسپارک و حتی کلیک‌هوس آماده بشن.
با ترکیب Postgres و Iceberg و با استفاده از امکانات خود mooncake:
🔰 داده‌ها به‌صورت زنده (real-time) همگام میشن حتی با آپدیت و حذف
🔰 تحلیل‌ها با کمک DuckDB سریع انجام میشن،
🔰 و همه‌چی بدون پیچیدگی ETL یا کپی‌کاری، در همون لحظه قابل استفاده‌ست.
یه جور پل بین ذخیره‌سازی عملیاتی و تحلیل زنده‌ست - دقیقاً همون چیزی که خیلی از شرکت‌ها مدت‌هاست دنبالش بودن.
🎯 واقعاً مشخص نیست دقیقاً چه استراتژی بزرگی پشت این خریدهاست، اما چیزی که واضحه اینه که Databricks داره آینده پایگاه‌های داده Postgres-محور رو با هوش مصنوعی و تحلیل real-time بازتعریف میکنه.
👋 به تیم Mooncake تبریک میگم، و مشتاقم ببینم در ادامه چه اتفاقات بزرگی رقم می‌زنن!
شروع رسمی دوره پستگرس کاربردی در مدرسه مهندسی داده سپهرام:
https://sepahram.ir/courses/
#Databricks #Mooncake #Postgres #Iceberg #Lakehouse #OLTP #AI #Lakebase #DataEngineering #OpenSourc
Linkedin
Databricks Acquires Mooncake Labs to Boost Lakebase | Databricks posted on the topic | LinkedIn
We’re excited to announce that Databricks has acquired Mooncake Labs to accelerate the vision of Lakebase, a new category of OLTP database built on Postgres and optimized for AI agents!
AI agents are transforming application development, and traditional…
AI agents are transforming application development, and traditional…
👍3😱1
Forwarded from مدرسه مهندسی داده سپهرام
همروندی و مدیریت تراکنش‌ها در Airflow: تجربه عملی از Postgres تا MinIO
در این ویدئو یک دگ (DAG) کاربردی را در ایرفلو نسخه 3.1 بررسی می‌کنیم که وظیفه‌اش انتقال تراکنش‌ها از پستگرس (Postgres) به MinIO است.
این دگ شامل چند مرحله است:
🔰سنسور برای انتظار تراکنش‌های جدید.
🔰تسک پردازش (Transform) برای استخراج تراکنش‌های خام از پایگاه داده.
🔰ذخیره‌سازی در MinIO به صورت JSON برای استفاده در مراحل بعدی (مثل ذخیره در Lakehouse).
🔰به‌روزرسانی وضعیت تراکنش‌ها در پستگرس به‌عنوان "پردازش‌شده".
❓ اما چالش کجا پیش می‌آید؟
وقتی چند بار این دگ را همزمان اجرا کنیم، هر بار ممکن است مجموعه‌ی مشابهی از تراکنش‌ها انتخاب شود و چندین بار پردازش شود. این همان مشکل اجرای ناخواسته‌ی موازی (Duplicate Processing) است.
برای حل این مسئله، در ویدئو چند راه‌حل بررسی شده است:
🟠 راه‌حل‌های محدود کردن همروندی
✨ گزینه depends_on_past: ایرفلو دگ یا تسک بعدی را تنها در صورتی اجرا می‌کند که اجرای قبلی همان تسک از دگ‌های قبلی تکمیل شده باشد.
✨ گزینه max_active_runs: می‌توانیم تعیین کنیم که حداکثر چند اجرای همزمان از یک دگ فعال باشد (مثلاً فقط یک اجرای فعال در لحظه).
✨ گزینه pool (در این دگ خاص بررسی نشد): ابزاری برای محدود کردن تعداد اجرای همزمان یک تسک مشخص.
🟢 راه‌حل‌های واقعی برای موازی‌سازی
اگر بخواهیم اجرای موازی واقعی برای سناریوی فوق (ترکیب ایرفلو و یک دیتابیس رابطه‌ای)، داشته باشیم، باید به سراغ تکنیک‌های سطح دیتابیس برویم. یکی از مهم‌ترین آنها:
- قفل‌گذاری موقت هنگام انتخاب سطرها با دستور FOR UPDATE SKIP LOCKED: با این تکنیک می‌توانیم در لحظه‌ی انتخاب رکوردها (SELECT) ردیف‌های انتخاب‌شده را قفل کنیم تا پردازش‌های دیگر نتوانند آنها را همزمان بردارند. این کار نیاز دارد که انتخاب (SELECT) و به‌روزرسانی (UPDATE) در همان تراکنش انجام شود تا رفتار اتمیک تضمین گردد.
💡 نکته‌ی اصلی این کارگاه این بود که:
طراحی پایپ‌لاین‌های داده با ایرفلو تنها به نوشتن چند تسک و اتصال آنها به هم خلاصه نمی‌شود. بلکه باید همه‌ی شرایط مرزی، اجرای همزمان دگ‌ها، قفل‌های دیتابیس و حتی طراحی ذخیره‌سازی (مثل MinIO یا Lakehouse) را با دقت بررسی کنیم.
📌 کدهای کامل این دگ در گیت‌هاب موجود است:
👉 https://github.com/sepahram-school/workshops/tree/main/2-Airflow-Concurrency-Control-SQL
🎥 امیدوارم این ویدئو برای تمام کسانی که در پروژه‌های واقعی با ایرفلو کار می‌کنند و دغدغه‌ی پایداری و دقت پایپ‌لاین‌های داده دارند، مفید و الهام‌بخش باشد.
کانال تلگرام BigData.IR - وب‌سایت مهندسی داده : https://t.iss.one/bigdata_ir
دوره‌های تخصصی سپهرام : https://sepahram.ir/courses
آدرس ویدئو در یوتیوب :
https://www.youtube.com/watch?v=sS6Ma40sngU
🔹 در ادامه‌ی کارگاه‌های عملی مدرسه مهندسی داده سپهرام Sepahram Data Eng. School، یک ویدئو آموزشی یک‌ساعته آماده کردم که به یکی از مسائل بسیار مهم در طراحی پایپ‌لاین‌های داده با ایرفلو (Apache Airflow) می‌پردازد: موضوع همروندی (Concurrency).
در این ویدئو یک دگ (DAG) کاربردی را در ایرفلو نسخه 3.1 بررسی می‌کنیم که وظیفه‌اش انتقال تراکنش‌ها از پستگرس (Postgres) به MinIO است.
این دگ شامل چند مرحله است:
🔰سنسور برای انتظار تراکنش‌های جدید.
🔰تسک پردازش (Transform) برای استخراج تراکنش‌های خام از پایگاه داده.
🔰ذخیره‌سازی در MinIO به صورت JSON برای استفاده در مراحل بعدی (مثل ذخیره در Lakehouse).
🔰به‌روزرسانی وضعیت تراکنش‌ها در پستگرس به‌عنوان "پردازش‌شده".
❓ اما چالش کجا پیش می‌آید؟
وقتی چند بار این دگ را همزمان اجرا کنیم، هر بار ممکن است مجموعه‌ی مشابهی از تراکنش‌ها انتخاب شود و چندین بار پردازش شود. این همان مشکل اجرای ناخواسته‌ی موازی (Duplicate Processing) است.
برای حل این مسئله، در ویدئو چند راه‌حل بررسی شده است:
🟠 راه‌حل‌های محدود کردن همروندی
✨ گزینه depends_on_past: ایرفلو دگ یا تسک بعدی را تنها در صورتی اجرا می‌کند که اجرای قبلی همان تسک از دگ‌های قبلی تکمیل شده باشد.
✨ گزینه max_active_runs: می‌توانیم تعیین کنیم که حداکثر چند اجرای همزمان از یک دگ فعال باشد (مثلاً فقط یک اجرای فعال در لحظه).
✨ گزینه pool (در این دگ خاص بررسی نشد): ابزاری برای محدود کردن تعداد اجرای همزمان یک تسک مشخص.
🟢 راه‌حل‌های واقعی برای موازی‌سازی
اگر بخواهیم اجرای موازی واقعی برای سناریوی فوق (ترکیب ایرفلو و یک دیتابیس رابطه‌ای)، داشته باشیم، باید به سراغ تکنیک‌های سطح دیتابیس برویم. یکی از مهم‌ترین آنها:
- قفل‌گذاری موقت هنگام انتخاب سطرها با دستور FOR UPDATE SKIP LOCKED: با این تکنیک می‌توانیم در لحظه‌ی انتخاب رکوردها (SELECT) ردیف‌های انتخاب‌شده را قفل کنیم تا پردازش‌های دیگر نتوانند آنها را همزمان بردارند. این کار نیاز دارد که انتخاب (SELECT) و به‌روزرسانی (UPDATE) در همان تراکنش انجام شود تا رفتار اتمیک تضمین گردد.
💡 نکته‌ی اصلی این کارگاه این بود که:
طراحی پایپ‌لاین‌های داده با ایرفلو تنها به نوشتن چند تسک و اتصال آنها به هم خلاصه نمی‌شود. بلکه باید همه‌ی شرایط مرزی، اجرای همزمان دگ‌ها، قفل‌های دیتابیس و حتی طراحی ذخیره‌سازی (مثل MinIO یا Lakehouse) را با دقت بررسی کنیم.
📌 کدهای کامل این دگ در گیت‌هاب موجود است:
👉 https://github.com/sepahram-school/workshops/tree/main/2-Airflow-Concurrency-Control-SQL
🎥 امیدوارم این ویدئو برای تمام کسانی که در پروژه‌های واقعی با ایرفلو کار می‌کنند و دغدغه‌ی پایداری و دقت پایپ‌لاین‌های داده دارند، مفید و الهام‌بخش باشد.
کانال تلگرام BigData.IR - وب‌سایت مهندسی داده : https://t.iss.one/bigdata_ir
دوره‌های تخصصی سپهرام : https://sepahram.ir/courses
آدرس ویدئو در یوتیوب :
https://www.youtube.com/watch?v=sS6Ma40sngU
GitHub
workshops/2-Airflow-Concurrency-Control-SQL at main · sepahram-school/workshops
Hands-on short workshops for data engineers! Explore popular tools and projects like DBT, Great Expectations, DuckDB, Kafka, Spark, and more, with ready-to-use materials for practice - sepahram-sch...
👍7
به تازگی کتاب Platform Engineering on Kubernetes نوشته‌ی Mauricio Salatino رو خوندم و واقعاً می‌تونم بگم یکی از منابع تحول‌آفرین در این حوزه‌ست.
پست اخیر Sajad Hamreh در لینکدین
چیزی که برای من خیلی جالب بود، این بود که کتاب فاصله بین دانش تئوری Kubernetes و عملیات واقعی Platform Engineering رو پر میکنه. یعنی نه صرفاً توضیح تئوریه و نه صرفاً دستورالعمل خشک، بلکه قدم‌به‌قدم نشون می‌ده چطور پلتفرمی بسازیم که واقعاً در دنیای واقعی کار کنه.
✅ از مباحث پایه Kubernetes شروع میکنه و به استراتژی‌های پیچیده‌تر مثل GitOps، progressive delivery، service mesh integration و multi-tenancy می‌رسه.
✅ فصل‌های مربوط به developer portals و self-service capabilities واقعاً برای من ارزشمند بودن؛ چون توی خیلی از منابع دیگه کمتر بهشون پرداخته میشه، در حالی که برای پذیرش موفق پلتفرم حیاتی هستن.
✅ نکته مهم دیگه اینه که با ابزارهایی مثل ArgoCD و Crossplane مثال‌های عملی زده که بلافاصله میشه در پروژه‌ها به‌کار برد.
✅ تجربه‌ی عمیق نویسنده هم در بخش‌های troubleshooting و هشدار درباره‌ی pitfalls کاملاً مشهوده؛ چیزهایی که به‌معنای واقعی کلمه جلوی سردردهای بعدی رو می‌گیرن.
برای من، پیام اصلی کتاب این بود که Platform Engineering یک تمرین صرفاً فنی نیست، بلکه یک محصوله؛ محصولی برای توسعه‌دهنده‌ها که اگر درست طراحی بشه، میتونه بهره‌وری کل سازمان رو متحول کنه.
پست اخیر Sajad Hamreh در لینکدین
چیزی که برای من خیلی جالب بود، این بود که کتاب فاصله بین دانش تئوری Kubernetes و عملیات واقعی Platform Engineering رو پر میکنه. یعنی نه صرفاً توضیح تئوریه و نه صرفاً دستورالعمل خشک، بلکه قدم‌به‌قدم نشون می‌ده چطور پلتفرمی بسازیم که واقعاً در دنیای واقعی کار کنه.
✅ از مباحث پایه Kubernetes شروع میکنه و به استراتژی‌های پیچیده‌تر مثل GitOps، progressive delivery، service mesh integration و multi-tenancy می‌رسه.
✅ فصل‌های مربوط به developer portals و self-service capabilities واقعاً برای من ارزشمند بودن؛ چون توی خیلی از منابع دیگه کمتر بهشون پرداخته میشه، در حالی که برای پذیرش موفق پلتفرم حیاتی هستن.
✅ نکته مهم دیگه اینه که با ابزارهایی مثل ArgoCD و Crossplane مثال‌های عملی زده که بلافاصله میشه در پروژه‌ها به‌کار برد.
✅ تجربه‌ی عمیق نویسنده هم در بخش‌های troubleshooting و هشدار درباره‌ی pitfalls کاملاً مشهوده؛ چیزهایی که به‌معنای واقعی کلمه جلوی سردردهای بعدی رو می‌گیرن.
برای من، پیام اصلی کتاب این بود که Platform Engineering یک تمرین صرفاً فنی نیست، بلکه یک محصوله؛ محصولی برای توسعه‌دهنده‌ها که اگر درست طراحی بشه، میتونه بهره‌وری کل سازمان رو متحول کنه.
Linkedin
#platformengineering #kubernetes #devops #cloudnative #gitops #developerexperience #argocd #crossplane #backstage #charisma | Sajad…
به تازگی کتاب Platform Engineering on Kubernetes نوشته‌ی Mauricio Salatino رو خوندم و واقعاً می‌تونم بگم یکی از منابع تحول‌آفرین در این حوزه‌ست.
چیزی که برای من خیلی جالب بود، این بود که کتاب فاصله بین دانش تئوری Kubernetes و عملیات واقعی Platform Engineering…
چیزی که برای من خیلی جالب بود، این بود که کتاب فاصله بین دانش تئوری Kubernetes و عملیات واقعی Platform Engineering…
مهندسی داده
به تازگی کتاب Platform Engineering on Kubernetes نوشته‌ی Mauricio Salatino رو خوندم و واقعاً می‌تونم بگم یکی از منابع تحول‌آفرین در این حوزه‌ست. پست اخیر Sajad Hamreh در لینکدین چیزی که برای من خیلی جالب بود، این بود که کتاب فاصله بین دانش تئوری Kubernetes…
2023 - Platform Engineering on Kubernetes.pdf
31.3 MB
کتاب Platform Engineering on Kubernetes
🙏7👍1