در چند ماه گذشته از کافکا کلا سوئیچ کرده ام به ردپاندا بابت مسایلی مثل بهینه‌تر بودن مصرف منابع و طراحی مدرن‌تر یک سامانه پیام رسان مبتنی بر پروتکل کافکا با امکانات کامل و یکپارچه.
حتی قصد داشتم خلاصه ای از مشاهدات آقای Wu را در کنفرانس ۲۰۲۴ کافکا و داده های جریانی در اینجا به اشتراک بگذارم با این محوریت که کافکا به نقطه حساسی رسیده است و اگر نتواند تغییرات مورد انتظار بازار را برآورده کند، بازار را به رقبا واگذار خواهد کرد و خریدن شرکت‌هایی مثل WarpStream توسط کانفلوئنت که هزینه نگهداری یک کلاستر کافکا را بسیار کاهش می‌دهد، باز هم به تنهایی به کافکا کمک نخواهد کرد :
https://medium.com/@yingjunwu/kafka-has-reached-a-turning-point-649bd18b967f
اگر در حوزه مهندسی داده فعالیت میکنید توصیه میکنم مقاله فوق را با دقت مطالعه کنید. .
اما مهم‌تر ازین مسائل پایه در انتخاب یک ابزار مانند مصرف منابع و سادگی کار با آن و یکپارچه بودن ابزار و اکوسیستم، دید و ویژن شرکت ردپاندا برایم جذاب بود .
دیدی که باعث شد چند ماه پیش، پروژه Benthos را خریده و به RedPanda Connect اضافه کند. یک پروژه عالی، سبک و حرفه ای برای کارهای ETL .
اخیرا هم دیدم ردپاندا، نوع جدیدی از تاپیک‌ها برای کار مستقیم با Apache Iceberg ایجاد کند، به این ویژن و توجه به نیازهای نوین بازار، باور بیشتری دارم.‌
توصیه میکنم اگر با کافکا کار میکنید، ردپاندا را هم حتما تست کنید (نیاز به تغییر خاصی در کدها ندارید و دقیقا از دید برنامه و ابزار،مثل یک کلاستر کافکا عمل میکند).
مقاله زیر را هم که راجع به افزوده شدن این نوع جدید از تاپیک ها و ذخیره مستقیم پیام‌ها در آپاچی آیس‌برگ است را هم حتما نگاهی بیندازید ....
Read “Apache Iceberg Topics: Stream directly into your data lake“ by Redpanda Data on Medium: https://redpanda-data.medium.com/apache-iceberg-topics-stream-directly-into-your-data-lake-0250a8dfdd76

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

‍ 🎉 آموزش ویدئویی جدید: راه‌اندازی انجین‌های توزیعی و تکرارشده در ClickHouse برای داده‌های تاکسی‌های نیویورک 🚖

وب سایت مهندسی داده که از بدو تاسیس خود در سال ۹۳ مبنای کار خود را گسترش مهارت‌ها و بینش‌های مهندسی در حوزه داده قرار داده است، به تازگی بخش آموزش‌ها و کارگاه‌های ویدئویی خود را راه اندازی کرده است که شاید بتواند تجربیات زیسته متخصصین این حوزه را به دوستان علاقه‌مند منتقل کند.

آدرس کانال یوتیوب مهندسی داده :

https://www.youtube.com/@irbigdata

در اولین کارگاه آموزشی، مهندس بنائی به بیان دو مفهوم توزیع شدگی و تکرارشدگی داده ها در کلیک هوس با بالاآوردن دو کلاستر مختلف و انجام یک مثال عملی با داکر می پردازد. اگر به این مبحث علاقه مند هستید، می توانید محتوای این کارگاه آموزشی دو ساعته را در لینک زیر دریافت کنید :

📌 مشاهده ویدئو در یوتیوب:

https://www.youtube.com/watch?v=mgg4rSCCrGI

📌 آدرس ریپوزیتوری گیت‌هاب:

https://github.com/IrBigDataWorkShops/clickhouse_distributed

در این ویدئو آموزشی، که به زبان فارسی ارائه شده، نحوه راه‌اندازی کلاسترهای ClickHouse برای مدیریت داده‌های NYC Taxi ذخیره‌شده در فرمت Parquet را پوشش می‌دهیم. این آموزش شامل بررسی و اعمال تنظیمات مهم برای ایجاد کلاسترهای توزیعی و تکرارشده کلیک‌هوس است تا قابلیت اجرای کوئری‌های کارآمد و همچنین مقاومت در برابر خطا بتوانیم برای این دیتابیس بسیار محبوب، فراهم کنیم.

موضوعات پوشش‌ داده‌ شده:
۱. تنظیم انجین توزیعی با ۳ نود --> ۳ شارد و ۱ رپلیکا
۲. تنظیم جدول‌های توزیعی و تکرارشده با ۴ نود --> ۲ شارد و ۲ رپلیکا


🔹 ویژگی‌های کلیدی این آموزش :
- اجرای کوئری‌های توزیعی موازی
- تکرارپذیری برای تحمل خطا
- مدیریت متادیتا بدون نیاز به Zookeeper

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

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

گروه تخصصی مهندسی داده : https://t.iss.one/bigdata_ir_discuss

#clickhouse #distributed_engine #clickhouse_cluster

‍ معرفی JuicsFS: راهکار مدرن برای ذخیره‌سازی توزیع‌شده داده

انتخاب یک راهکار مقیاس‌پذیر و کارآ برای ذخیره توزیع شده فایل‌ها در بسیاری از معماری‌های امروزی سیستم‌های اطلاعاتی یک تصمیم مهم در ایجاد یک زیرساخت ذخیره سازی مطمئن و قابل اتکاست .
برای سال‌ها این نقش را HDFS‌ هدوپ برای سازمان‌ها ایفا می‌کرد که البته برای نیازمندی‌های مدرن طراحی نشده بود و بیشتر ابزار ذخیره سازی هدوپ در عصر نخستین فناوری‌های مرتبط با کلان‌داده بود.
با محبوبیت S3 آمازون، گزینه متن‌باز آن یعنی Mino هم در چند سال اخیر بسیار رایج شده است و به یک De Facto استاندارد برای ایجاد یک زیرساخت ذخیره فایل توزیع شده تبدیل شده است که راه‌اندازی و کار با آن هم بسیار ساده است.
اما اگر سیستمی دارید که بخشی ازفایلهای آن در کلاد (S3، Google Cloud Storage، Azure Blob) و بخشی دیگر در سرورهای محلی و بخشی در سرورهای تخصصی استوریج مانند سرویس‌های S3 که امروزه اکثر شرکت‌های ایرانی هم ارائه می‌دهند، قرار گرفته است و به یک واسط استاندارد و یکپارچه برای دسترسی به تمام این استوریج‌ها نیاز دارید، JuiceFS برای شما طراحی شده است.

💡 مزایای کلیدی JuicsFS

• سازگاری کامل با POSIX: امکان استفاده مانند یک سیستم فایل معمولی
• پشتیبانی از انواع ذخیره‌سازی ابری
• عملکرد بالا: بهره‌گیری از کش محلی برای بهبود سرعت خواندن و نوشتن (واینکه با زبان Go نوشته شده است)
• قابلیت اطمینان و مقیاس‌پذیری: امکان گسترش آسان با رشد حجم داده‌ها
آدرس گیت‌هاب پروژه : https://github.com/juicedata/juicefs
سایت اصلی JuicFS
https://juicefs.com/en

🔑 JuiceFS رایگان و متن‌باز است و جامعه فعالی از توسعه‌دهندگان از آن پشتیبانی می‌کنند.
پی‌نوشت:
یکی از خوانندگان عزیز این مطلب در لینکدین هم نظری راجع به این پروژه داشتند که بهتر است دوستان حتما با دقت آنرا بررسی کنند :

این فایل سیستم در نسخه رایگان از Distributed Data Cache استفاده نمی کنه همچنین عدم پشتیبانی از ACL و کربروس و Apache Ranger یعینی عدم پشتیبانی از کلیه راه کارهای امنیت . در سازمان های بزرگ این این موارد نباشه اصلا توصیه نمیشه ولی شاید برای سازمان هایی که بخوان امنیت را در لایه application کنترل کنن شاید مفید باشه

»

#DataEngineering #BigData #Cloud #OpenSource #DistributedSystems

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


By : Alireza Sadeghi

What tools & technologies should aspiring data engineers pick to learn in 2025!?

https://www.pracdata.io/p/open-source-data-engineering-landscape-2025
Navigating and deciding what to learn in such a vast ecosystem of tools and services can feel overwhelming.

Here is my recommendation for a 𝙛𝙪𝙡𝙡-𝙨𝙩𝙖𝙘𝙠 𝙙𝙖𝙩𝙖 𝙚𝙣𝙜𝙞𝙣𝙚𝙚𝙧:

🌟 First and foremost, focus on 𝗺𝗮𝘀𝘁𝗲𝗿𝗶𝗻𝗴 𝘁𝗵𝗲 𝗳𝘂𝗻𝗱𝗮𝗺𝗲𝗻𝘁𝗮𝗹𝘀, as emphasised by other experts, while also striving to become expert in core technologies.

👉 𝗢𝗟𝗔𝗣 𝗗𝗮𝘁𝗮𝗯𝗮𝘀𝗲 𝗦𝘆𝘀𝘁𝗲𝗺𝘀
★ Master SQL and data warehouse data modeling techniques like the Star Schema. From technology perspective, most columnar MPP-based data warehouse technologies operate similarly.

★ If you get extra time master a specialised database in each OLAP category. Focus on how the data modeling is done in each engine:
★ 𝗖𝗹𝗶𝗰𝗸𝗛𝗼𝘂𝘀𝗲 for real-time OLAP
★ 𝗘𝗹𝗮𝘀𝘁𝗶𝗰𝗦𝗲𝗮𝗿𝗰𝗵 for search engines
★ 𝗖𝗮𝘀𝘀𝗮𝗻𝗱𝗿𝗮 for wide-column key-value engines
★ 𝗜𝗻𝗳𝗹𝘂𝘅𝗗𝗕 for time-series data

👉 𝗗𝗮𝘁𝗮 𝗟𝗮𝗸𝗲/𝗟𝗮𝗸𝗲𝗵𝗼𝘂𝘀𝗲
★ Understand the foundational concepts of data modeling on S3-compatible object stores (𝗦𝟯, 𝗠𝗶𝗻𝗜𝗢, etc), including the 𝗠𝗲𝗱𝗮𝗹𝗹𝗶𝗼𝗻 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲, partitioning, 𝗣𝗮𝗿𝗾𝘂𝗲𝘁 serialisation, and indexing options.
★ Familiarise yourself with Open Table Format technologies. 𝗗𝗲𝗹𝘁𝗮 𝗟𝗮𝗸𝗲, 𝗛𝘂𝗱𝗶, and 𝗜𝗰𝗲𝗯𝗲𝗿𝗴 all have the same foundation. Pick one to master.

👉 𝗗𝗮𝘁𝗮 𝗜𝗻𝘁𝗲𝗴𝗿𝗮𝘁𝗶𝗼𝗻
★ Here learning the fundamentals are really more vital. Master various data integration frameworks and paradigms, including ETL vs. ELT, incremental vs Batch, and the trade-offs involved.
★ Study event-driven architectures, log-based CDC, and get hands-on with 𝗞𝗮𝗳𝗸𝗮 𝗖𝗼𝗻𝗻𝗲𝗰𝘁 and 𝗗𝗲𝗯𝗲𝘇𝗶𝘂𝗺 plugins.

👉 𝗦𝘁𝗿𝗲𝗮𝗺 𝗣𝗿𝗼𝗰𝗲𝘀𝘀𝗶𝗻𝗴
★ Master 𝗔𝗽𝗮𝗰𝗵𝗲 𝗞𝗮𝗳𝗸𝗮. Similar products like Redpanda provide similar Kafka-compatible API.
★ Focus on learning 𝗦𝗽𝗮𝗿𝗸 𝗦𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲𝗱 𝗦𝘁𝗿𝗲𝗮𝗺𝗶𝗻𝗴, and 𝗙𝗹𝗶𝗻𝗸 for real-time and unified processing.
★ Learn the fundamentals of data processing with 𝗣𝘆𝘁𝗵𝗼𝗻 𝗗𝗮𝘁𝗮𝗙𝗿𝗮𝗺𝗲𝘀, as many technologies in this space (like Pandas, Polars, Dask and Ibis) share similar foundations.

👉 𝗪𝗼𝗿𝗸𝗳𝗹𝗼𝘄 𝗢𝗿𝗰𝗵𝗲𝘀𝘁𝗿𝗮𝘁𝗶𝗼𝗻
★ If you aim to work at a big tech company, mastering 𝗔𝗽𝗮𝗰𝗵𝗲 𝗔𝗶𝗿𝗳𝗹𝗼𝘄 for orchestration, and 𝗱𝗯𝘁 for data transformation is essential.

👉 𝗜𝗻𝗳𝗿𝗮𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲
★ If you are aiming high, gaining proficiency in 𝗞𝘂𝗯𝗲𝗿𝗻𝗲𝘁𝗲𝘀 and 𝗗𝗼𝗰𝗸𝗲𝗿 for container orchestration is essential.

👉 𝗔𝗻𝗮𝗹𝘆𝘁𝗶𝗰𝘀 & 𝗩𝗶𝘀𝘂𝗮𝗹𝗶𝘀𝗮𝘁𝗶𝗼𝗻
★ Experiment with 𝗔𝗽𝗮𝗰𝗵𝗲 𝗦𝘂𝗽𝗲𝗿𝘀𝗲𝘁 or 𝗠𝗲𝘁𝗮𝗯𝗮𝘀𝗲 for building dashboards.
★ Learn the fundamental of distributed query processing using 𝗧𝗿𝗶𝗻𝗼 and 𝗦𝗽𝗮𝗿𝗸.
★ For single-node processing, 𝗗𝘂𝗰𝗸𝗗𝗕 is an excellent choice to learn.

https://www.linkedin.com/posts/ramtin-safadoust_podman-containers-devops-activity-7295831613400109056-pvga?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAEPHcQBIu5rXaFgo5F_hVlrlaE66EdlQzQ

چرا باید به جای Docker از Podman استفاده کنیم؟
نویسنده : رامتین صفادوست

اگه با کانتینرها کار می‌کنی، احتمالاً Docker برات آشناست. ولی تا حالا Podman رو امتحان کردی؟ یه موتور کانتینر سبک، امن و بدون نیاز به daemon که کلی مزیت داره، مخصوصاً از نظر امنیت و یکپارچگی با سیستم.

چندتا دلیل که چرا Podman داره محبوب‌تر می‌شه:

✅ بدون نیاز به Root – کانتینرها رو بدون دسترسی root اجرا کن و ریسک امنیتی رو کم کن.

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

✅ سازگار با Docker CLI – اگه از Docker استفاده می‌کردی، راحت می‌تونی مهاجرت کنی (حتی alias docker=podman هم جواب می‌ده!).

✅ دوست‌داشتنی برای Kubernetes – فقط با یه دستور می‌تونی YAML مورد نیاز برای K8s رو بسازی (podman generate kube).

✅ یکپارچه با systemd – اگه می‌خوای کانتینرها رو مثل یه سرویس مدیریت کنی، Podman بهترین گزینه‌ست.

اگه دنبال یه جایگزین امن‌تر و بهینه‌تر برای Docker هستی، حتماً Podman رو امتحان کن.


#Podman #Containers #DevOps #Kubernetes

پ.ن:
نظرات ذیل پست فوق در لینکدین را هم نگاهی بیندازید ...

پستگرس و نیازمندی‌های تحلیلی نوین

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

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

✅ ذخیره‌سازی ستونی: افزونه‌هایی مانند Hydra و pg_analytics امکان ذخیره‌سازی داده‌ها به‌صورت ستونی (Columnar) را فراهم کرده‌اند که یکی از ویژگی‌های کلیدی پایگاه‌های داده تحلیلی مدرن است.

✅ تطابق با Lakehouse و Iceberg: ترکیب PostgreSQL با معماری Lakehouse و ذخیره‌سازی مستقیم داده‌های تحلیلی در قالب Parquet با افزونه‌هایی مانند pg_mooncake، گامی دیگر در مسیر ارتقای آن به یک پایگاه داده تحلیلی جامع است.

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

راجع به Mooncake

فرض کنید می‌خواهید داده‌های مربوط به رفتار کاربران در یک اپلیکیشن یا وب‌سایت را ذخیره کنید؛ برای مثال، اینکه روی چه محصولاتی کلیک کرده‌اند یا چه اکشن‌هایی انجام داده‌اند. چنین داده‌هایی معمولاً حجم بالایی دارند و اگر در پایگاه داده اصلی، مانند PostgreSQL، ذخیره شوند، ممکن است عملکرد آن را کند کنند. به همین دلیل، معمولاً از پایگاه داده‌های تحلیلی مانند ClickHouse استفاده می‌شود تا هم از سرعت بالای پردازش تحلیلی بهره ببریم و هم بار اضافی به دیتابیس عملیاتی تحمیل نکنیم.

اما با نصب pg_mooncake، می‌توان این داده‌های حجیم را مستقیماً در PostgreSQL ذخیره کرد، درحالی‌که داده‌ها در عمل در یک استوریج جداگانه، مانند MinIO، ذخیره می‌شوند. این افزونه امکان ذخیره داده‌ها را در قالب‌های Delta Lake (و به‌زودی Iceberg) به‌صورت فایل‌های Parquet فراهم می‌کند.

چگونه کار می‌کند؟

✅ داده‌ها در ظاهر از طریق PostgreSQL درج و کوئری می‌شوند.
✅ اما در پشت‌صحنه، داده‌ها در یک استوریج جداگانه مانند MinIO یا هر سرویس دیگری ذخیره می‌شوند.
✅ امکان ترکیب با ابزارهای پردازش داده‌های حجیم مانند DuckDB، Polars، Pandas و Spark وجود دارد.

مشاهده محل ذخیره‌سازی داده‌ها
برای یافتن مسیر دقیق فایل‌های مرتبط با جداول Mooncake، می‌توانید از کوئری زیر استفاده کنید:

SELECT * FROM mooncake.columnstore_tables;

خروجی این دستور مسیر دایرکتوری‌ای را نشان می‌دهد که داده‌ها به‌صورت Delta Lake (و در آینده Iceberg) در آن ذخیره شده‌اند و مستقیماً می‌توان آن‌ها را با Pandas، DuckDB، Polars یا Spark کوئری گرفت.

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

این پست آقای صادقی را هم در همین راستا می توانید مطالعه کنید.
https://www.linkedin.com/feed/update/urn:li:activity:7296864653039591424/

🚀 تبدیل PostgreSQL به یک دیتابیس HTAP با یک راهکار ساده و موثر!

🔍 این مطلب صرفاً برای اشاره به یک موج جدید در حوزه دیتابیس‌ها نوشته شده است—ایده‌ای که نشان می‌دهد می‌توان با ترکیب ابزارهای حرفه‌ای متن‌باز، سیستم‌هایی با توانایی بالا ساخت، بدون نیاز به توسعه یک موتور پایگاه داده از صفر!

اما چطور؟ 🤔 فرض کنید که به شما پیشنهاد شود که برای حل مشکل کندی PostgreSQL در کوئری‌های پیچیده و سنگین تحلیلی، یک راهکار سریع، ارزان و موثر پیدا کنید. اینجاست که با خودتان می‌گویید:

✅ ذخیره‌سازی داده‌ها به‌صورت ستونی: داده‌های PostgreSQL را در قالب ستونی ذخیره کنم تا برای اجرای کوئری‌های پیچیده و سنگین تحلیلی بهینه شود. چه گزینه‌ای بهتر از Parquet؟

✅ مدیریت و سازماندهی داده‌ها: وقتی حجم داده‌ها زیاد شود و تعداد فایل‌های Parquet بالا برود، چطور آن‌ها را مدیریت کنم؟ اینجاست که Open Table Format‌هایی مثل Apache Iceberg به کمک می‌آیند، چون دقیقاً برای همین منظور طراحی شده‌اند.

✅ انتقال داده از PostgreSQL به این ساختار: سریع‌ترین روش بدون نیاز به یک ETL پیچیده چیست؟ می‌توانیم یک Read Replica از PostgreSQL بسازیم که خودش تغییرات را ارسال کند و این تغییرات را مستقیماً در قالب Parquet و با استاندارد Iceberg ذخیره کنیم.

✅ اجرای سریع کوئری‌ها: حالا چطور روی این داده‌ها کوئری اجرا کنم؟ یکی از بهترین گزینه‌هایی که در سال‌های اخیر بلوغ بالایی پیدا کرده و از Iceberg و Parquet پشتیبانی می‌کند، DuckDB است! بنابراین می‌توانیم مستقیماً روی Iceberg کوئری بزنیم و نتایج را سریع دریافت کنیم.

✅ ایجاد یک واسط SQL سازگار با PostgreSQL: برای اجرای کوئری‌ها توسط کاربران، نیاز به یک لایه تبدیل SQL داریم که درخواست‌های PostgreSQL را به گرامر DuckDB تبدیل کند. خوشبختانه، گرامر DuckDB تا حد زیادی با استاندارد SQL سازگار است، بنابراین این مرحله هم به سادگی قابل انجام است.

🎯 نتیجه؟ به همین راحتی، PostgreSQL را به یک HTAP (دیتابیس ترکیبی تحلیلی/تراکنشی) تبدیل کردیم!

💡 اما این پایان ماجرا نیست!
دیتابیسی به نام BemiDB دقیقاً بر اساس همین معماری در حال توسعه است. این پروژه هنوز در ابتدای مسیر قرار دارد و در حال حاضر انتقال داده‌ها به‌صورت آفلاین انجام می‌شود. اما این تنها یک شروع است و مسیر رشد و تکامل آن می‌تواند بسیار هیجان‌انگیز باشد!
Bemi

🔥 و نکته‌ی هیجان‌انگیز؟
تست‌های اولیه روی دیتاست استاندارد TPC-H نشان داده که در برخی پرس‌وجوها، سرعت اجرای کوئری‌ها تا ۲۰۰۰ برابر سریع‌تر از PostgreSQL شده است! 😯🚀

📌 به نظر میرسد که ترکیب ابزارهای متن‌باز قدرتمند می‌تواند راهکارهایی نوآورانه برای چالش‌های دنیای دیتابیس ایجاد کند!


آدرس پروژه BemiDB :
https://github.com/BemiHQ/BemiDB

‍ در دنیای مهندسی داده که سرعت و کارایی اهمیت زیادی دارد، استفاده از ابزارهای نوین مدیریت پکیج‌ها و محیط‌های مجازی بسیار حیاتی است. uv به عنوان یک مدیر پکیج پایتون سریع و بهینه، مزایای قابل توجهی نسبت به روش‌های سنتی مانند pip و virtualenv ارائه می‌دهد.

ویژگی‌های کلیدی uv 🚀

⚖️ جایگزین بدون دردسر – کاملاً سازگار با pip، pip-tools، virtualenv و دیگر ابزارهای مدیریت پکیج.

⚡️ سرعت خیره‌کننده – بین ۱۰ تا ۱۰۰ برابر سریع‌تر از pip، pip-compile و pip-sync.

💾 بهینه در مصرف فضا – با استفاده از کش جهانی، وابستگی‌های تکراری را حذف کرده و فضای دیسک را ذخیره می‌کند.

🐍 نصب آسان و منعطف – قابل نصب از طریق curl، pip یا pipx بدون نیاز به Rust یا حتی نصب بودن Python.

🧪 تست‌شده در مقیاس بالا – عملکرد uv با ۱۰,۰۰۰ پکیج برتر PyPI بررسی و تأیید شده است.

🖥 سازگاری با تمام پلتفرم‌ها – کاملاً قابل اجرا روی macOS، Linux و Windows.

🔩 مدیریت پیشرفته وابستگی‌ها – امکان کنترل نسخه‌های وابستگی، حل تداخل‌ها و استفاده از استراتژی‌های مختلف نصب.

⁉️ خطاهای شفاف و قابل فهم – بهترین سیستم مدیریت خطا برای رفع سریع مشکلات توسعه‌دهندگان.

🤝 پشتیبانی از قابلیت‌های مدرن پایتون – نصب‌های قابل ویرایش، وابستگی‌های Git، URLهای مستقیم، مدیریت وابستگی‌های محلی و موارد دیگر.

🚀 ابزار همه‌کاره – ترکیبی از امکانات pip، pipx، poetry، pyenv، twine و ابزارهای دیگر در یک راهکار واحد.

🛠 مدیریت پیشرفته پروژه و اسکریپت‌ها – امکان اجرای اسکریپت‌ها، مدیریت نسخه‌های پایتون و کار با متادیتای وابستگی‌ها.

🗂 لاک‌فایل عمومی و پایدار – یکپارچه‌سازی وابستگی‌ها در پروژه‌های مختلف و تسهیل مدیریت نسخه‌ها.

🏢 پشتیبانی از ورک‌اسپیس‌ها – مناسب برای پروژه‌های مقیاس‌پذیر و چندبخشی، مشابه Cargo-style.


نمونه‌هایی از استفاده uv:

# نصب یک پکیج در محیط مجازی:

uv pip install pandas

# ایجاد یک محیط مجازی جدید:

uv venv .venv

# همگام‌سازی پکیج‌ها با فایل pyproject.toml:

uv pip sync

اگر به دنبال سرعت، کارایی و مدیریت بهتر وابستگی‌ها در پروژه‌های مهندسی داده هستید، uv گزینه‌ای ایده‌آل برای جایگزینی روش‌های سنتی است. 💡🔥

منابعی برای مطالعه بیشتر :

- https://www.kdnuggets.com/new-python-package-manager
- https://www.saaspegasus.com/guides/uv-deep-dive/
- https://codemaker2016.medium.com/introducing-uv-next-gen-python-package-manager-b78ad39c95d7

- https://docs.astral.sh/uv/getting-started/first-steps/

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

برای ذخیره و پردازش داده‌های جی‌سان کدام بانک‌اطلاعاتی را انتخاب کنیم ؟

🚀 مقایسه عملکرد ClickHouse با MongoDB، Elasticsearch، DuckDB و PostgreSQL در پردازش JSON

وبلاگ رسمی کلیک هوس اخیرا (اوایل سال ۲۰۲۵ – بهمن ماه ۱۴۳) مقاله ای منتشر کرده است با عنوان :

The billion docs JSON Challenge: ClickHouse vs. MongoDB, Elasticsearch, and more

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

پایگاه‌های داده‌ای که در این آزمایش شرکت داشتند عبارت‌اند از:


1️⃣ ClickHouse

2️⃣ MongoDB

3️⃣ Elasticsearch

4️⃣ DuckDB

5️⃣ PostgreSQL


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

در این آزمایش، JSONBench استفاده شده است که توسط خود کلیک هوس برای این گزارش توسعه داده شده است (آدرس گیت: https://github.com/ClickHouse/JSONBench) و همانطور که در خود مقاله فوق آمده است سعی شده است تمامی بهینه سازی‌های مرتبط با هر یک از دیتابیس های فوق در ذخیره و پردازش داده‌ها انجام شود که یک مقایسه عادلانه و جوانمردانه باشد.

🔹 علاوه بر بررسی میزان فضای مصرف شده برای ذخیره این حجم از داده، از پنج کوئری تحلیلی هم استفاده شده است که برای مشاهده لیست کامل کوئری ها به آدرس گیت بالا مراجعه کنید.

خلاصه نتایج را در فیلم زیر می توانید ببینید.

🔥 خلاصه نتایج

🎯 ClickHouse در تمام سناریوهای آزمایش‌شده از رقبا سریع‌تر و بهینه‌تر بود.

📉 فضای ذخیره‌سازی موردنیاز آن به‌شدت کمتر بود.

⚡️ در پردازش JSON، ClickHouse نسبت به سایر پایگاه‌های داده، عملکردی فراتر از انتظار داشت.

اگر به دنبال یک پایگاه داده فوق‌العاده سریع برای پردازش داده‌های JSON در مقیاس بزرگ هستید، ClickHouse یک انتخاب عالی است!

اما صبر کنید!

🔹 این جمله بالا، نتیجه‌گیری ClickHouse از اجرای بنچمارک فوق و انتخاب خودش به عنوان برنده بود. اما بهتر است موارد زیر را برای تصمیم نهایی در این خصوص در نظر بگیریم :

✅ اگر قصد ذخیره نتایج فراخوانی API ها، لاگ‌ها، و رخدادهایی را داریم که از نوع JSON هستند و قرار نیست آنها را به‌روز‌رسانی کنیم، ClickHouse می‌تواند گزینه‌ی اول باشد.

✅ اگر با داده‌های متنی کار می‌کنیم و علاوه بر ذخیره داده‌ها به‌صورت JSON، قرار است پردازش‌های مختلف متنی هم روی آنها انجام دهیم (مثلاً به ستون‌های مختلف یک سند، وزن بیشتری در کوئری‌های خود بدهیم)، Elasticsearch همچنان گزینه‌ی اول ما خواهد بود.

✅ اگر پایگاه داده‌ی اصلی ما PostgreSQL است و یا حجم دیتای ما در حد چند ده گیگابایت است، می‌توانیم از امکانات خود PostgreSQL برای ذخیره JSON استفاده کنیم.

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

#مهندسی‌_داده #کلیک_هوس

https://www.bigdata.ir/?p=8512

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

Warp

یک ترمینال مدرن و پیشرفته است که به نظر می رسد به طور خاص برای توسعه‌دهندگان و مهندسین داده طراحی شده است. این ترمینال با ویژگی‌های منحصر به فردی مانند:

✅ رابط کاربری مدرن و زیبا

✅ قابلیت تکمیل خودکار هوشمند (AI-powered)

✅ امکان اشتراک‌گذاری دستورات و نتایج

✅ امکان ساخت نوت‌بوک و ورک‌فلو برای مستند کردن دستورات پیچیده و راحت تر کردن انجام کارهای تکراری

✅ پشتیبانی از کار گروهی و همکاری تیمی

✅ قابلیت جستجوی سریع در تاریخچه دستورات

✅ بلوک‌های دستور که امکان اجرای مجدد آسان را فراهم می‌کند

تجربه کار با خط فرمان رو کاملاً متحول کرده است.
Warp
در اصل برای سیستم‌عامل macOS توسعه داده شد و بعداً پشتیبانی از لینوکس را نیز اضافه کرد. مدتها بود که منتظر نهایی شدن نسخه ویندوز این ترمینال بودم که چند ساعت پیش ایمیل دانلود این نسخه برایم آمد و حیفم آمد تجربه خوبی که از کار با این ترمینال به دست آوردم را با علاقه مندان به دنیای مهندسی داده و خط فرمان به اشتراک نگذارم.

امیدوارم این فیلم کوتاه برای این دوستان مفید باشد.

#Warp #Terminal #DeveloperTools #Productivity #TechTips

در دنیای هوش مصنوعی، نام DeepSeek این روزها بیش از پیش شنیده می‌شود. شرکتی که با مدل‌های قدرتمند خود توانسته توجه بسیاری را به خود جلب کند. یکی از مهم‌ترین درس‌های مهندسی که از دیپ‌سیک می‌توان گرفت، روش‌های نوآورانه‌ای است که این شرکت برای تأمین و پردازش حجم عظیم داده‌های مورد نیاز خود به کار گرفته است. 🔥
مقاله اصلی الهام بخش این پست :
https://mehdio.substack.com/p/duckdb-goes-distributed-deepseeks
شرکت دیپ‌سیک با انتشار بخشی از ابزارهای داخلی خود در گیت‌هاب در روزهای اخیر (اوایل اسفند 1403 - اواخر فوریه 2025)، به جامعه مهندسی داده نشان داد که چگونه می‌توان با ساده‌ترین ابزارها، کارآمدترین سیستم‌ها را ساخت. یکی از این پروژه‌ها، SmallPond نام دارد:

🔗https://github.com/deepseek-ai/smallpond

✅ SmallPond
یک کتابخانه بسیار ساده برای پردازش توزیع‌شده داده است که برای پردازش حجم عظیمی از داده‌ها آنهم فقط با توزیع داده‌ها بین چندین نسخه از دیتابیس DuckDB و دریافت نتایج از آنها طراحی شده است. برخلاف سیستم‌های مرسوم مانند Apache Spark که به زیرساخت‌های پیچیده و پرهزینه نیاز دارند، این پروژه با استفاده از چندین نسخه DuckDB - یک دیتابیس تحلیلی سبک‌وزن - توانسته به نتایجی خیره‌کننده دست یابد. همانطور که Mehdi Quazza اشاره می‌کند تیم DeepSeek موفق شده است ۱۱۰ ترابایت داده را به کمک این کتابخانه، تنها در نیم‌ساعت پردازش کند! آن هم بدون نیاز به کلاسترهای سنگین یا سرویس‌های ابری گران‌قیمت. این رویکرد نشان می‌دهد که معماری‌های ساده اما هوشمندانه می‌توانند جایگزینی برای ابزارهای سنتی باشند.

💪 نکته جالب‌تر اینکه این پروژه تنها توسط دو توسعه‌دهنده (طبق لیست گیت‌هاب) پیاده‌سازی شده است! 🔥 چنین نتیجه‌ای نشان می‌دهد که در دنیای امروز، خلاقیت مهم‌تر از منابع است.

🗂 اما راز اصلی این موفقیت در استفاده از چارچوب پردازشی Ray‌ (یک فریمورک بسیار حرفه‌ای در پردازش توزیع شده که سه سال پیش راجع به آن در سایت مهندسی داده نوشته بودم : https://www.bigdata.ir/?p=8104) و سیستم فایل توزیع‌شده‌ای به نام 3FS (توسعه داده شده توسط خود دیپ‌سیک) نهفته است:

🔗 https://github.com/deepseek-ai/3FS

پروژه 3FS یک سیستم فایل بهینه برای ذخیره‌سازی توزیع‌شده و مخصوص نیازهای پروژه‌های هوش مصنوعی طراحی شده است. ترکیب این سیستم فایل با SmallPond یک زنجیره پردازش سبک، سریع و مقرون‌به‌صرفه را به وجود آورده است.

🚀 در ماه‌های آینده انتظار داریم استفاده‌های نوآورانه بیشتری از DuckDB را در حوزه مهندسی داده بشنویم. 🔥

#مهندسی_داده #DistributedComputing #DuckDB #هوش_مصنوعی #DeepSeek #3FS #SmallPond

‏۱/ کوئرا با ۳۰۰ میلیون کاربر ماهانه، ۲۵,۰۰۰+ سوال روزانه، و ۱۰+ سال فعالیت، دیتابیسش میدونی چیه؟ MySQL 🫠 ! ده‌ها ترابایت داده و صدها هزار QPS. و اومدن شدیدا بهینه‌ش کردن، چطوری؟
‏۲/ اینا میبینن بار دیتابیس (Database Load) با رشد کاربران، پتابایت‌ها بیشتر و با ویژگی‌های ML محصولاتشون بالاتر هم می‌ره، و البته اسپمرها هم یه بخشی ازین بار بودن.

‏۳/ بار دیتابیسشون تو خواندن (Reads) (۷۰٪ ترافیک)، حجم داده (Data Volume) ( که رشد ۲۰۰٪ تو ۵ سال داشت)، و نوشتن (Writes) (کم اما حساس) بود. کوئرا برای بهینه‌سازی روی خواندن و حجم داده تمرکز کرد، چون ترافیک بیشترشون سمت خواندن بود.

‏۴/ اسکن‌های بزرگ رو با LIMIT و صفحه‌بندی (Pagination) بهینه کردن. این کار از اسکن‌ غیرضروری جلوگیری کرد و پرفومنس کوئری‌ها رو تا ۶۰٪ سریع‌تر کرد.

‏۵/ برای کوئری‌های کند، ایندکس‌ها رو دوباره طراحی کردن، ستون‌های غیرضروری حذف شدن، ORDER BY به کلاینت منتقل شد، و کوئری‌های غیرضروری هم حذف شدند. و بار CPU ۵۰٪ کم شد.

‏۶/ برای High QPS، کوئرا کش رو بهینه کرد. کلید کش (Cache Key) به uid تغییر داد تا QPS رو بیش از ۹۰٪ کم کنه.

برای حجم داده ها، کوئرا MyRocks که فیس‌بوک توسعه داده بود رو برای شاردهای قدیمی MySQL استفاده کرد. این کار فضا رو تا ۸۰٪ برای برخی جدول‌ها و ۵۰-۶۰٪ برای بقیه کاهش داد.

‏۷/ مای راک با فشرده‌سازی بهتر، IO رو کم کرد و زمان بکاپ/ریستور رو ۵۰٪ سریع‌تر کرد. شاردهای قدیمی (بیش از ۱۸ ماه) به MyRocks منتقل شدند.
برای نوشتن، lag رپلیکیشن رو با رپلیکیشن موازی Parallel ( توی mysql تنظیماتش slave_parallel_type یا شبیه شه) حل کردن تا بار رو بهتر توزیع کنه.


‏۸/ یعنی یه تاخیری بین دیتابیس مادر با رپلیکا به وجود میومد که رو برداشتن سیستمش رو موازی کردن، مشکلش چی بود؟ وقتی رپلیکا داره میخونه یا مینویسه ممکنه خیلی زمان بر بشه یا transaction دیتابیس مادر خیلی زمانبر باشه رپلیکا مجبور بشه صبر کنه تا تراکنش تموم بشه بعد تغییرات رو اعمال کنه

‏۸/ یعنی یه تاخیری بین دیتابیس مادر با رپلیکا به وجود میومد که رو برداشتن سیستمش رو موازی کردن، مشکلش چی بود؟ وقتی رپلیکا داره میخونه یا مینویسه ممکنه خیلی زمان بر بشه یا transaction دیتابیس مادر خیلی زمانبر باشه رپلیکا مجبور بشه صبر کنه تا تراکنش تموم بشه بعد تغییرات رو اعمال کنه

‏۹/ خلاصه اینکه نتیجه این شد که کوئرا:
- با بهینه‌سازی کش و کوئری‌ها
- استفاده از MyRocks،
- و رپلیکیشن موازی

بار رو برای ۳۰۰ میلیون کاربر روی دیتابیس‌ MySQL کاهش داد

مطالب به نقل از یوزر Saman(@teal33t) در توئیتر (X) نقل شده است
https://x.com/teal33t/status/1898117078168609173?s=19

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

دوستانی که از کلیک هوس استفاده میکنند، هنگام ایجاد جداول در ClickHouse، معمولاً اندازهٔ ریزدانگی (granularity) را برابر ۸۱۹۲ تنظیم می‌کنند(یا پشت صحنه تنظیم می‌شود) که البته همان مقدار پیش فرض است. این مقدار تعیین می‌کند که به ازای هر ۸۱۹۲ رکورد، یک ورودی در ایندکس ایجاد شود. یعنی اگر کلیک هوس بخواهد وجود رکوردی را در یک گرانول بررسی کند، باید کل آنرا اسکن و بررسی کند. مقاله زیر به طور خاص به همین موضوع میپردازد که شرکت SolarWinds با تغییر این مقدار، چگونه به بهبود قابل‌توجهی در عملکرد خود دست یافت.
https://clickhou.se/3QZ7m6L

سولارویندز با کاهش اندازهٔ ریزدانگی، موفق به افزایش ۶۰٪ سرعت پاسخ‌دهی شد. چون میزان اسکن سطرها به ازای کوئری ها کاهش یافت و نهایتا زمان پاسخ‌دهی بهبود یافت

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

افزایش مصرف حافظه: کاهش اندازهٔ ریزدانگی منجر به افزایش حجم فایلهای مارک که ورودی های اندیس ها را نگه می‌دارند و معمولا در حافظه نگه داری میشوند شد .‌ اما با این تغییر در ریزدانگی، از ده گیگابایت حافظه به ۳۲۰ گیگابایت حافظه نیاز پیدا شد که با هزینه دلاری معقولی قابل تهیه و پوشش دادن بود. این هزینه در قبال سرعتی که به همراه داشت، قابل قبول بود.

افزایش عملیات ادغام (Merge): با کاهش اندازه هر گرانول ، تعداد فایل‌هایی که باید پشت صحنه مرج و ادغام میشد افزایش یافت که خود فشار مضاعفی به دیسک و بخش ورودی/خروجی سیستم عامل وارد میکرد.

برای مدیریت این چالش‌ها، تیم مهندسی سولارویندز تصمیم گرفت تا pread_threadpool را حذف کند. این اقدام به سیستم اجازه داد تا مستقیماً از قابلیت‌های SSD استفاده کند، یعنی حذف واسطه‌های نرم‌افزاری که زمانی برای بهینه سازی کار با دیسک‌های قدیمی طراحی شده بودند و امروزه خود باعث بوجود آمدن وقفه و گلوگاه در سیستم شده بودند.

این تجربه نشان می‌دهد که چگونه تغییرات دقیق در تنظیمات یک سیستم پایگاه داده می‌تواند تأثیرات قابل‌توجهی بر عملکرد داشته باشد که البته مثل همه تغییرات، با مدیریت مناسب، هزینه‌های جانبی آن قابل کنترل است.
#clickhouse #کلیک‌هوس #بهینه‌سازی_دیتابیس

اگر پایپ لاین های مبتنی بر داده خود را با ایرفلو طراحی کرده‌اید اما وسوسه شده‌اید که از امکانات حرفه‌ای دگستر برای اجرای خودکار فرآیندهای متوالی پردازش داده(پایپ لاین) استفاده کنید، Airlift دقیقا این لیفت! را برای شما انجام میدهد.

https://www.linkedin.com/posts/dagsterlabs_airlift-is-a-powerful-new-tookit-that-makes-activity-7305287043285200897-Ze_f

نگاهی به خرید HyperDX‌ توسط کلیک‌هوس

🔍 Observability
دیگر یک انتخاب نیست، بلکه یک ضرورت است!

امروزه شرکت‌ها بخصوص تیم‌های مهندسی داده و دوستان دواپس نیاز مبرمی به یک پلتفرم یکپارچه نظارت (Observability) دارند که لاگ‌ها، تریس‌ها، خطاها و متریک‌ها را در یک محیط مجتمع گرد هم بیاورد. اما چیزی که امروزه علاوه بر این نیازمندی‌ها می‌تواند برای ما جذاب باشد، یک استک جدید و بهینه است که علاوه بر سرعت بالای جستجو و مصرف کم منابع، امکانات پیشرفته‌ای مثل بازاجرای خطاها (Session Replay) را نیز فراهم کند.

خرید HyperDX توسط ClickHouse دقیقاً در همین راستاست!

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

https://clickhouse.com/blog/clickhouse-acquires-hyperdx-the-future-of-open-source-observability

#Observability #ClickHouse #HyperDX #DataEngineering

‍ همزمان با فرا رسیدن سال جدید شمسی، نسخه Apache Kafka 4.0 منتشر شد و جامعه توسعه‌دهندگان بالاخره شاهد نهایی شدن یکی از بزرگ‌ترین تغییرات این پلتفرم یعنی حذف زوکیپر هستند. این نسخه جدید تغییرات مهمی را به همراه دارد که تأثیر زیادی بر نحوه استفاده از کافکا در پروژه‌های مختلف خواهد داشت. در ادامه، به بررسی ویژگی‌های کلیدی این نسخه می‌پردازیم و توضیح می‌دهیم که چرا این تغییرات برای توسعه‌دهندگان و تیم‌های مهندسی داده حیاتی هستند.

۱. حذف نهایی زوکیپر از کافکا
فرآیند حذف ZooKeeper از کافکا از نسخه ۲٫۸ آغاز شد، و اکنون در نسخه ۴ به‌طور کامل به پایان رسیده است. حذف زوکیپر به معنای تغییر اساسی در معماری مدیریت متادیتای کافکا است.

✅ چرا این تغییر مهم است؟

کاهش پیچیدگی زیرساخت: قبلاً برای راه‌اندازی یک کلاستر کافکا، نیاز به راه‌اندازی زوکیپر جداگانه‌ای بود که نگهداری و مدیریت آن، هزینه‌بر و پیچیده بود. با این تغییر، مدیریت کافکا ساده‌تر می‌شود.
افزایش پایداری و عملکرد: زوکیپر مشکلات مقیاس‌پذیری و پایداری خاص خود را داشت که باعث می‌شد در برخی شرایط، کلاسترهای کافکا دچار ناپایداری شوند. حذف آن باعث بهبود مدیریت متادیتا و افزایش مقیاس‌پذیری افقی (Horizontal Scalability) کافکا شده است.
بهینه‌سازی عملیات در DevOps: از آنجایی که دیگر نیازی به تنظیم و نگهداری زوکیپر نیست، تیم‌های DevOps و SRE می‌توانند مدیریت کلاسترهای کافکا را ساده‌تر کنند.
جایگزین زوکیپر چیست؟
آپاچی کافکا از مکانیزم جدیدی به نام KRaft (Kafka Raft) Metadata Mode برای مدیریت متادیتا استفاده می‌کند. این معماری بر پایه Raft Consensus Algorithm بنا شده که به طور ذاتی در خود کافکا تعبیه شده است.

۲. امکان Shared Partition در Apache Kafka 4.0: صف به سبک کافکا!
با انتشار Apache Kafka 4.0، یکی از مهم‌ترین ویژگی‌هایی که به این نسخه اضافه شده، امکان Shared Partition است. این قابلیت، به Kafka اجازه می‌دهد تا نقش یک صف پیام (Queue) را با انعطاف‌پذیری و قابلیت‌های خاص خودش ایفا کند.

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

چرا Shared Partition ضروری بود؟
تا پیش از این، در معماری Kafka، هر پارتیشن فقط به یک Consumer در داخل یک Consumer Group اختصاص داده می‌شد. این طراحی باعث ایجاد محدودیت‌هایی برای توسعه‌دهندگان می‌شد:

✅ اگر تعداد پارتیشن‌ها کمتر از تعداد Consumerها بود، برخی از Consumerها بی‌کار می‌ماندند.
✅ برای افزایش مقیاس‌پذیری و مصرف هم‌زمان داده‌ها، توسعه‌دهندگان مجبور بودند تعداد پارتیشن‌ها را بیش از نیاز واقعی افزایش دهند که به آن Over-Partitioning می‌گویند.
✅ پیاده‌سازی سناریوهای صف (Queue) که در آن پیام‌ها می‌توانند توسط چندین پردازشگر مستقل مصرف شوند، چالش‌برانگیز بود.
Shared Partition چیست و چگونه کار می‌کند؟
در Kafka 4.0، با معرفی Share Groups، محدودیت مصرف‌کنندگان در ارتباط با پارتیشن‌ها برداشته شده است. اکنون:

✅ یک پارتیشن می‌تواند به چندین Consumer تخصیص داده شود.
✅ مصرف‌کنندگان می‌توانند رکوردهای موجود را به صورت اشتراکی پردازش کنند.
✅ هر رکورد به‌صورت جداگانه تأیید (ack) می‌شود، نه کل پارتیشن!
✅ اگر یک رکورد پردازش نشود، پس از یک مدت مشخص، دوباره برای مصرف‌کننده‌های دیگر در دسترس قرار می‌گیرد.
✅ امکان کنترل تعداد دفعات تلاش برای پردازش هر رکورد وجود دارد.

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

اما با Shared Partition، می‌توان تنها یک پارتیشن داشت و چندین پردازشگر (Consumer) به‌صورت هم‌زمان روی آن کار کنند. هر پردازشگر، پیام‌هایی را دریافت کرده و پردازش می‌کند. اگر پردازش موفقیت‌آمیز باشد، پیام تأیید (acknowledge) می‌شود، اما اگر مشکلی وجود داشته باشد، پیام دوباره در اختیار دیگر پردازشگرها قرار می‌گیرد.

‍ چگونه Uber با ترکیب Apache Spark و Ray، عملکرد سیستم خود را بهبود داد؟🚖

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

در این نوشتار، به بررسی رویکرد Uber در بهینه‌سازی بخشی از خطوط پردازش داده خود می‌پردازیم؛ جایی که ترکیب Apache Spark و Ray، سرعت اجرای یکی از فرآیندهای کلیدی را ۴۰ برابر افزایش داد!

مقاله اصلی را که در ژانویه ۲۰۲۵ منتشر شده است، از لینک زیر می‌توانید مطالعه کنید :
https://www.uber.com/en-IN/blog/how-uber-uses-ray-to-optimize-the-rides-business/

🚖 مشکل چه بود؟

Uber برای تنظیم بودجه تخفیف مسافران و مشوق‌های رانندگان، نیاز به انجام محاسبات پیچیده‌ای داشت. این محاسبات باید هر هفته انجام می‌شد و پارامترهای آنها به ازای هر شهر متفاوت بود. هر محاسبه سبک و سریع بود (حدود ۱-۲ ثانیه برای هر شهر)، اما وقتی این کار باید برای هزاران شهر انجام می‌شد، سیستم موجود که بر اساس آپاچی اسپارک ایجاد شده بود، به شدت کند عمل می‌کرد.

دلیل اصلی کندی سیستم:

-اسپارک برای اجرای توابع سبک و پرتکرار بهینه نبود؛ این ابزار برای پردازش‌های حجیم طراحی شده است و سربار بالایی برای وظایف کوچک ایجاد می‌کرد.

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

۱- ادامه استفاده از Apache Spark: از آنجا که Spark اجرای توابع Python را به‌صورت موازی (بدون استفاده از APIهای مخصوص Spark) پشتیبانی نمی‌کند، تمام این توابع بهینه‌سازی برای شهرهای مختلف فقط روی نود اصلی Spark (Driver Node) و به‌صورت سریالی اجرا شوند، که باعث کاهش کارایی می‌شد.

۲- استفاده از Pandas UDF در Spark: این روش تا حدی سرعت اجرای عملیات روی DataFrameهای Pandas را افزایش می‌داد، اما بهبود عملکرد چشمگیر نبود. علاوه بر این، Pandas UDF نمی‌تواند کدهای عمومی Python را به‌صورت موازی اجرا کند، که محدودیت بزرگی محسوب می‌شد.

۳- اجرای یک Job مستقل برای هر شهر: این روش مستلزم اجرای یک کانتینر Docker برای هر شهر بود. اما این راهکار به دلیل سربار راه‌اندازی بالا و مصرف نامتناسب منابع محاسباتی، کارآمد نبود.


⚡️ چرا Uber از Ray در کنار Spark استفاده کرد؟

برای حل این مشکل، Uber تصمیم گرفت از یک راه‌حل ترکیبی استفاده کند. برای اتخاذ این تصمیم، اوبر این دو نکته را در نظر گرفت :

✔️ آپاچی اسپارک برای پردازش‌های حجیم (ETL، تبدیل داده‌ها، ذخیره‌سازی در HDFS) عالی است، اما برای اجرای وظایف کوچک با فرکانس بالا، عملکرد مناسبی ندارد.

✔️ پروژه Ray در اجرای موازی وظایف سبک و کوتاه‌مدت فوق‌العاده است، زیرا:
- امکان موازی‌سازی کدهای Python را بدون نیاز به تغییرات پیچیده فراهم می‌کند. (یک مثال ساده از Ray‌ را در انتهای این نوشته می‌بینید)
- مدیریت منابع را برای وظایف سبک و پرتکرار بهینه می‌کند.
- اجرای سریع‌تر را بدون نیاز به Docker و تغییر ساختار کد تسهیل می‌کند.

🔀 راه‌حل Uber: ترکیب Spark و Ray
🚀 اسپارک همچنان برای پردازش‌های حجیم داده‌ها و خواندن/نوشتن در HDFS استفاده شد.
⚡️ پروژه Ray برای اجرای سریع توابع Python، مدل‌های یادگیری ماشین و محاسبات بهینه‌سازی به کار گرفته شد.

نتیجه:

✅ ۴۰ برابر افزایش سرعت در اجرای فرآیند بهینه‌سازی

✅ سادگی توسعه؛ دانشمندان داده می‌توانند مستقیماً در Notebookها با Pandas کار کنند

✅ کاهش سربار پردازشی بدون نیاز به تغییرات گسترده در کدهای موجود

💡آموخته‌ها

✅ ابزارها را متناسب با نیاز انتخاب کنید! Apache Spark و Ray هرکدام در زمینه‌ی خود قوی هستند، اما ترکیب آن‌ها می‌تواند بسیاری از محدودیت‌ها را برطرف کند.

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

✅ ریشه‌ی مشکل را درست شناسایی کنید. در این مثال، مشکل اصلی کندی Spark نبود، بلکه ماهیت وظایف کوچک و پرتکرار بود که در Ray بهتر مدیریت شدند.

📌 نتیجه: به‌جای تغییر کل فناوری، روی بهینه‌سازی بخش‌هایی که نیاز دارند تمرکز کنید. 🚀

‍ 🚀 آیا Apache Spark در حال نابودی است؟ بیایید با هم صحبت کنیم!

در دنیای مهندسی داده، هر چند وقت یک‌بار یک ابزار جدید ظاهر می‌شود و ادعا می‌کند که بهتر، سریع‌تر و کارآمدتر از گزینه‌های قبلی است. این روزها برخی معتقدند که Apache Spark دیگر گزینه‌ی مناسبی برای پردازش داده‌های حجیم نیست و باید جای خود را به فناوری‌های جدید بدهد. اما آیا واقعاً این‌طور است؟ بیاییدمقاله ای که در مارس 2025 در مدیوم با عنوان «Is Apache Spark Really Dying? Let’s Talk» منتشر شده است را با هم مرور کنیم

https://medium.com/@afroinfotech/is-apache-spark-really-dying-lets-talk-9b104b20b5e9

⚡️ چرا برخی به دنبال جایگزین Spark هستند؟
🔴 مشکلات عملکردی: سربار JVM و مدیریت حافظه باعث کاهش کارایی در برخی پردازش‌ها می‌شود.
🔴 ضعف در یادگیری ماشین و تحلیل سریع: Spark MLlib در برابر TensorFlow و PyTorch حرفی برای گفتن ندارد. همچنین، برای کوئری‌های سریع و سبک، ابزارهایی مثل DuckDB و Polars گزینه‌های بهتری هستند.
🔴 پیچیدگی در تنظیمات، راه‌اندازی و دیباگینگ: پیام‌های خطای نامفهوم و نیاز به تنظیمات دقیق برای بهینه‌سازی عملکرد.

🔥 اما چرا Spark همچنان محبوب است؟
🟢 قدرت در پردازش‌های ETL حجیم، مناسب برای پردازش ترابایت‌ها و پتابایت‌های داده.
🟢 مقیاس‌پذیری بالا و پردازش توزیع‌شده، مناسب برای خوشه‌های بزرگ داده‌ای.
🟢 یکپارچگی عالی با ابزارهای داده‌ای مثل Delta Lake، Apache Iceberg و Hudi و سرویس‌های ابری AWS، Azure و GCP.
🟢 پذیرش گسترده در صنعت و جامعه‌ی متخصصان بزرگ، یافتن مهندسان Spark بسیار آسان‌تر از فناوری‌های جدیدی مانند Ray یا Polars است.

🤔 آیا وقت آن رسیده که Spark را کنار بگذاریم؟
✅ اگر پردازش‌های سنگین و توزیع‌شده دارید، Spark همچنان یکی از بهترین گزینه‌هاست.
⚡️ اما اگر به سرعت بالاتر روی یک سیستم واحد، پردازش یادگیری ماشین یا تحلیل بلادرنگ نیاز دارید، ابزارهایی مثل Flink، Polars، Ray و DuckDB انتخاب‌های بهتری هستند.

🔮 آینده‌ی Spark: نابودی یا تکامل؟
واقعیت این است که اسپارک به پایان راه نرسیده هر چند آن چیرگی چندسال پیش خود را در اکوسیستم داده ندارد و ابزارهای متنوع و سبک‌تری برای پردازش داده‌ها امروزه در دسترس ما قراردارند اما اسپارک علاوه بر بلوغ مناسب برای پروژه‌های پردازش داده حجیم، امروزه در حال سازگار کردن خودش با دنیای جدید داده است! 🚀💡

⚖️ انتخاب ابزار مناسب: کاهش پیچیدگی، افزایش بهره‌وری
امروزه گزینه‌های بسیار متنوعی برای پردازش داده‌های حجیم در دسترس ماست، و این وظیفه‌ی مهندسین داده است که تا حد امکان پیچیدگی اضافه به سیستم تحمیل نکنند. انتخاب ابزار مناسب باید بر اساس مصرف بهینه‌ی منابع، سادگی و مقیاس‌پذیری باشد.

به عنوان مثال، اخیراً دیپ‌سیک که یک موج جدید در دنیای مدل‌های زبانی ایجاد کرده، به جای استفاده از Spark از ترکیب DuckDB، یک سیستم فایل جدید و Ray استفاده کرده است. این ترکیب که توسط یک تیم چندنفره توسعه یافته، موفق شده است ۱۰۰ ترابایت داده را در کمتر از ۳۰ دقیقه با استفاده از ۵۰ نود محاسباتی پردازش کند—یک رکورد شگفت‌انگیز!

همچنین، مقاله‌ی چند ماه پیش علیرضا صادقی با عنوان The Rise of Single-Node Processing: Challenging the Distributed-First Mindset به همین موضوع اشاره دارد که برای بیش از ۹۰٪ کاربردهای امروزی، گزینه‌های بسیار بهینه‌تری از ابزارهای کلاسیک پردازش داده مانند Spark وجود دارد.

🔍 نتیجه: تکنولوژی‌هایی مانند Spark همچنان جایگاه خود را دارند، اما مهندسین داده باید فراتر از ابزارهای سنتی فکر کنند و به دنبال راهکارهایی باشند که هم سریع‌تر، هم ساده‌تر و هم کم‌هزینه‌تر باشند.

#ApacheSpark #BigData #مهندسی_داده #ETL #پردازش_داده #یادگیری_ماشین #SingleNodeProcessing