‍ شروع ثبت‌نام دوره تخصصی ClickHouse

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

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

⚡️ چرا ClickHouse؟

در دنیای امروز که تحلیل داده در مقیاس بالا و نزدیک به زمان واقعی (Near Real-Time) مزیت رقابتی مهمی محسوب می‌شود، پایگاه‌های داده سنتی دیگر پاسخگو نیستند. ClickHouse به‌عنوان موتور تحلیلی فوق‌سریع (OLAP) می‌تواند کوئری‌های پیچیده را روی میلیاردها رکورد در کسری از ثانیه اجرا کند و در معماری‌های مدرن داده نقشی بی‌بدیل داشته باشد. هر چند روال کار دیتابیس‌های تحلیلی با دیتابیس‌های رابطه ای کمی متفاوت است و در این دوره سعی شده است زیر و بم این دیتابیس محبوب به صورت عملی و کاربردی، بررسی شود.


📚 مشخصات دوره جامع ClickHouse (کد: ۳۰۱)

👤 سطح: مقدماتی و متوسط

⏱️ مدت: ۱۸ ساعت

📌 پیش‌نیاز: آشنایی با SQL و Docker

🗓 شروع: پنج‌شنبه ۶ شهریور ۱۴۰۴

👥 ظرفیت: ۳۰ نفر

🕒 زمان برگزاری:

سه‌شنبه‌ها: ۲۰ تا ۲۲

پنج‌شنبه‌ها: ۱۴ تا ۱۸

🎓 امکان دریافت گواهینامه معتبر (با انجام پروژه عملی و پرداخت جداگانه)

🔍 سرفصل‌ها (کاملاً کاربردی):

- نصب و راه‌اندازی + معماری کلیک‌هوس

- طراحی بهینه جداول، ایندکس‌ها و Bloom Filter

- کوئری‌های پیشرفته SQL و clickhouse-local

- بهینه‌سازی پرس‌وجوها با Projection و MergeTree

- کار با داده‌های JSON، Map و Materialized View

- پردازش جریانی با Kafka Engine و glassflow

- مدیریت امنیت، RBAC، مانیتورینگ با Grafana

- پیاده‌سازی کلاسترهای توزیع‌شده (Sharding, Replication)

- مهاجرت داده و تیونینگ عملی با ابزارهای ETL


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

📩 همین حالا برای ثبت‌نام اقدام کنید :

https://sepahram.ir/courses/clickhouse-201/
کانال تلگرام مدرسه مهندسی داده سپهرام : @sepahram_school

‍ آشنایی با Temporal.io

امروز در لینکدین پستی منتشر شد درباره‌ی مزایای Temporal.io و نقاط قوت آن در مقایسه با Apache Airflow.

این یادداشت را به عنوان تکمیل همان تجربه آماده کرده ایم.

بیایید ابتدا مشکلاتی که برای کاربر در استفاده از Airflow پیش آمده بود را مرور کنیم :


🔹 چالش‌های Airflow در عمل

هرچند Airflow یک ابزار شناخته‌شده و استاندارد برای مدیریت ETL و پردازش دسته‌ای است، اما در سناریوهای پیچیده‌تر محدودیت‌هایی ایجاد می‌کند:

⚠️ماهیت Syncronous بودن بسیاری از Operatorها: اجرای Async در Airflow نیازمند طراحی جداگانه یا اپراتورهای سفارشی است و برای کار با APIهای Async ساده نیست.

⚠️مقیاس‌پذیری و مدیریت منابع: کلاسترکردن Executorها و مدیریت منابع در Airflow به‌ویژه در مقیاس بزرگ، پیچیدگی و سربار بالایی ایجاد می‌کند.

⚠️زمان‌بندی و Triggerها: هرچند می‌توان از طریق API یا Sensorها جریان‌ها را کنترل کرد، اما پیاده‌سازی شرط‌های پویا و وابستگی به رویدادها (Event-driven) نسبتاً دشوار است.

⚠️مدیریت خطا و Retry: Airflow قابلیت Retry دارد اما نسبتاً ساده است. استراتژی‌های پیچیده‌تر مانند backoff نمایی، timeout چندلایه یا مدیریت خطا در سطح گام‌های طولانی‌مدت نیاز به کدنویسی و کنترل دستی دارد.

⚠️تعامل انسانی (Human-in-the-Loop): Airflow به‌طور بومی امکان دخالت کاربر انسانی در میانه‌ی یک DAG را ندارد و چنین قابلیتی باید با توسعه‌ی خارجی یا ترکیب ابزارهای دیگر پیاده شود.


💡 مزایای Temporal در این زمینه

تمپورال رویکرد متفاوتی دارد: به جای تعریف DAG در پایتون، گردش‌های کاری را به شکل کد در زبان‌های مختلف پیاده‌سازی می‌کنید و هسته‌ی آن به‌صورت durable execution تضمین می‌کند که هیچ فعالیتی در اثر خطا یا قطعی از بین نرود. برخی نقاط قوت آن:

✅ پشتیبانی چندزبانه (Polyglot SDKs): تیم‌ها می‌توانند در زبان‌های مختلف (Go, Python, TypeScript, Java و ...) Workflow و Activity بنویسند و در یک سیستم یکپارچه اجرا کنند.

✅ Async-first: معماری Temporal از پایه برای پردازش Async طراحی شده و برخلاف Airflow، نیاز به اپراتورهای خاص یا راه‌حل‌های سفارشی ندارد.

✅ مقیاس‌پذیری بالا: توانایی اجرای میلیون‌ها Workflow در ثانیه، با معماری مقاوم و پشتیبانی از دیتابیس‌های مختلف (Postgres, MySQL, Cassandra و ElasticSearch).

✅ امکان Retry و Error Handling پیشرفته: مدیریت خطا، Retry خودکار با استراتژی‌های متنوع، timeoutهای چندلایه و تضمین اجرای دقیق (exactly-once execution) از ویژگی‌های بومی Temporal است.

✅ قابلیت متمایز و مهم Human-in-the-Loop: از طریق Signalها و Queryها می‌توان تعامل انسانی را به‌راحتی درون Workflow قرار داد (برای مثال تأیید یا رد یک مرحله).

✅ رویکرد Event-driven بودن واقعی: Workflowها می‌توانند توسط سیگنال‌ها یا رویدادهای بیرونی شروع و کنترل شوند؛ چیزی که در Airflow محدودتر و پیچیده‌تر است.

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


🔹 کجا Airflow و کجا Temporal؟

🎯اگر پروژه‌ی شما بیشتر شامل ETL دسته‌ای و پردازش‌های دوره‌ای است، Airflow همچنان یک ابزار استاندارد و مناسب است.

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

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

‍ مهارت‌های ضروری یک فعال حوزه IT
مخاطب این پست بچه های فعال حوزه آیتی در بازه سنی 20 تا 30 سال...
میدونم خیلی از شمایی که این متن رو میخونید آینده کاری خودتون در حوزه آیتی رو یکم مبهم میبینید ، با فراگیر شدن و تجاری شدن هوش مصنوعی قطعاً مهارت های لازم برای ورود و رشد و توسعه در بازار کار تغییر کرده.
به عنوان آدمی که حداقل چند بار تجربه کارکردن خارج از کشور رو دارم و ترند 15 سال اخیر در حوزه دیتا و فناوری اطلاعات رو عمیقاً به خاطر شغلم دنبال کردم چند تا نکته رو میخوام توضیح بدم که دونستنش میتونه آینده کاریتون رو تغییر بده

1- مهمترین زبان برنامه نویسی که همه باید یادبگیرن نه پایتون، نه جاوا ، نا گو ... بلکه زبان انگلیسی !
خیلی خیلی زود بسیاری از مهارت های بیسیک حوزه آیتی زبان محور میشن، به عنوان یک برنامه نویس جونیور تسلط به زبان انگلیسی یعنی تعامل درست با استیک هولدرهای پروژه ، درک نیازهاشون و انتقال صحیحش به محیط کار ، ضمن اینکه زبان انگلیسی مهمترین منبع شما برای یادگیری فناوری خواهد بود. به شخصه اگر برگردم به گذشته زمانی که برای تحصیل تو دوره ارشد رو تلف کردم صرف یادگیری یه زبان جدید میکنم
2- صنعت آیتی به یک بازار Fast Fashion تغییر کرده
یعنی دیگه شرکتی که هدفش تولید یک محصول با سرمایه گذاری کلان در بازه زمانی 1 ساله باشه مرده ! الان سرعت تولید محصولات نرم افزاری به اندازه سرعت تغییر سلیقه مردم در حوزه مد و فشن بالاست پس تسلط شما به تولید مبتنی بر هوش مصنوعی که معادل است با سرعت چشمگیر در تولید نرم افزار اولویت اول کارفرماست تجربه شخصی خودم تولید کل Backend یک سامانه مدیریت ایمیل هوشمند مبتنی بر AI بوده که با بیش از 45 اندپوینت برای API Gateway از مرحله R&D تا مرحله Production فقط سه هفته طول کشید و قطعاً خودم اگر کسی قرار بود این کار رو 3 ماه طول بده استخدامش نمیکردم
3-به جای تمرکز بر فناوری به یادگیری بازار فناوری بپردازین ای کاش یه دوره اقتصاد دیجیتال برای بچه های آیتی برگزار میشد تا فرق محصول واقعی با استارت آپ توهمی رو کامل توضیح بده. به عنوان یک آیتی من باید بدونید چیزی که یک محصول رو با ارزش و قابل مصرف میکنه صرفاً هزینه، درآمد و جمع جبری این دوتاست نه قدرت بک اند و نه جذابیت فرانت اند.
4- یادگیری Cloud Computing واجب تر از نون شب.
باور کنید یا نه خارج از ایران کسی قرار نیست سرور در اختیار شما بذاره که کانفیگ کنید ، همه شرکت های دسترسی کلاد به گوگل، آمازون و مایکروسافت دارن ، همه سرویس ها روی کلاد توسعه داده شده، تقریباً هر فعالیتی که بخواید انجام بدین تهش میرسید به سرویس های ابری. عدم آشنایی برنامه نویس های ایرانی با محیط Cloud بزرگترین نقطه ضعفه ماست . میدونم به خاطر شرایط ایران امکان استفاده و تست رو نداریم ولی این مانع یادگیری از طریق یوتیوب و دوره های آنلاین نیست. رزومه ای که توش تسلط به کلاد نباشه درجا ریجکته
5-نفوذ عمقی به صنعت تخصصی
دنیای هوش مصنوعی بی نهایت بزرگه ، اینکه میبینید یکی تو پروفایلش نوشته دیتاساینتیست یا مهندس هوش مصنوعی قشنگه ولی در دنیای بیرون از لینکدین ازتون میپرسن دیتاساینتیست در چه حوزه ای ؟ ایکامرس، پزشکی، الکترونیک، گیم، فشن، مهندسی، راه و شهرسازی ، اقتصاد ، مالی ... بدون داشتن یه حوزه تخصص تجاری شما شبیه یه آچار با کله گرد هستین که معلوم نیست چه پیچی رو سفت میکنه به نظرم حتما تو یکی دو تا از حوزه های تجاری اطلاعات کسب کنید تا آدم های بفهمن شما رو برای چه کاری باید استخدام کنن برای من این مسیر همیشه بازاریابی و فروش بوده

متن و عکس از این پست لینکدین برداشته شده است:
https://www.linkedin.com/posts/zarvandeh_مخاطب-این-پست-بچه-های-فعال-حوزه-آیتی-در-بازه-activity-7364601996378574850-s2CD

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

‍ نقشه راه مهندسی داده؛ چهار گام برای تبدیل شدن به یک مهندس داده حرفه‌ای

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

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



🔹 گام اول: اصول اولیه - Foundations

این گام مربوط به پیش‌نیاز ورود به مهندسی داده است.

📌 پایتون عمیق: یادگیری پایتون فراتر از سطح مقدماتی؛ از برنامه‌نویسی شی‌گرا و ماژولار تا مباحث پیشرفته مثل async/await، decorators و context managers.

📌 اصول توسعه سرویس‌ها: آشنایی با REST و gRPC، سریالیزیشن (JSON/Protobuf/Avro)، امنیت و ساخت سرویس‌های پایدار.

📌 مبانی پردازش داده: کار با Pandas/Numpy/Polars، آشنایی با ابزارهای پردازش توزیع‌شده (مثل Celery/Daft) و حتی وب‌کراولینگ برای جمع‌آوری داده.

برای مشاهده جزییات این گام به این لینک مراجعه کنید

🔹 گام دوم: مبانی مهندسی داده

در این مرحله با کلیت ابزارها و معماری‌های اصلی آشنا می‌شویم و یک دید عملیاتی پیدا می‌کنیم.

📌 محیط توسعه و ابزارهای پایه: کار با لینوکس، خط فرمان و Docker.

📌 دیتابیس‌ها: یادگیری PostgreSQL و SQL در کنار آشنایی با انواع دیتابیس‌های NoSQL، ستونی، سری‌زمانی و برداری.

📌 مدیریت جریان داده: طراحی و اجرای pipelineها با ابزارهایی مثل Airflow، Prefect، Kafka و Spark.


🔹 گام سوم: عمیق شدن در مهندسی داده

اینجا وارد بخش جدی‌تر و تخصصی‌تر می‌شویم.

📌 دیتابیس‌های غیررابطه‌ای: کار عملی با MongoDB، Redis، Cassandra و Elasticsearch و Qdrant برای ذخیره‌سازی و بازیابی داده‌های متنوع.

📌 دیتابیس‌های تحلیلی و Lakehouse: تسلط بر ClickHouse، StarRocks، Doris و همچنین طراحی Lakehouse با MinIO و Open Table Formats مثل Apache Iceberg.

📌 پردازش جریان و ETL حرفه‌ای: تسلط عملی بر Kafka و اکوسیستم آن، ابزارهای ETL/ELT (مثل dbt، Airbyte، Arroyo) و کار با دیتابیس‌های جریانی و پردازش توزیع‌شده.

🔹 گام چهارم: به سوی باشگاه حرفه‌ای‌ها

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

📌 استقرار مدرن سرویس‌ها: تسلط بر Kubernetes

📌 زیرساخت به‌عنوان کد (IaC): کار با Terraform، Ansible یا Pulumi.

📌 ابر داخلی و خارجی: آشنایی با AWS، Azure، Databricks، ستون و آروان برای طراحی زیرساخت‌های داده.

📌 عامل‌های هوشمند و MLOps : پیوند دادن داده با یادگیری ماشین (MLFlow) و استفاده از AI Agents برای پایش و اتوماسیون پایپ‌لاین‌ها.

📌 حاکمیت و کیفیت داده: آشنایی با اصول Data Governance و ابزارهایی مثل Great Expectations برای اطمینان از صحت و اعتمادپذیری داده.


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

🔗 نقشه راه : https://sepahram.ir/data-engineering-roadmap

‍ از دستیار کدنویس تا همکار هوشمند؛ از کابوس مستندسازی تا اتصال کدبیس دیوار به مدل‌های زبانی

ما در دیوار این هدف رو برای خودمون گذاشتیم که با استفاده از هوش مصنوعی، بهره‌وری مهندسی رو افزایش بدیم. در شروع سرویس‌های مکالمه‌محور مثل ChatGPT رو آوردیم و باهاشون کار کردیم. به مرور سرویس‌هایی مثل Copilot و Cursor رو هم امتحان کردیم. تجربه‌مون تا مدتی به این صورت بود که هر ابزار جدیدی که میومد تعدادی از مشکلات و اذیت‌هایی رو که با ورژن‌های قدیمی‌تر داشتیم، برطرف می‌کرد. برای مثال در کار با ChatGPT باید توضیحات خیلی مفصلی از مسئله ارائه می‌دادیم و تمام کدهای مورد نیازشو کپی پیست می‌کردیم و کد خروجیش رو داخل محیط توسعه‌مون می‌آوردیم و مشکلات سینتکسی که داشت رو برطرف می‌کردیم. برای دیباگ هم لاگ‌های خروجیش رو باز به GPT می‌دادیم. این تجربهٔ کاربری رفت و برگشتی تا حد خوبی در محصولاتی مثل Cursor برطرف شد اما همچنان مشکلات بزرگ دیگری داشتیم.
بخشی از مقاله :
محیط توسعه Cursor برای پروژه‌های کوچک و self-contained خیلی خوب عمل می‌کرد. اما برای پروژه‌های داخل یک سازمان به مشکل می‌خورد. مشکل این بود که همه اطلاعات مورد نیاز داخل پروژه در دسترس نیست و یا پیدا کردنش برای کسی که دانش قبلی از سازمان و کانونشن‌های پروژه نداره کار ساده‌ای نیست. خیلی از جاها هم زمان و هزینه‌ای که ایجنت‌ها برای پیدا کردن داده مورد نظر می‌ذاشتن خیلی بالا بود و حتی ممکن بود Context Window مدل به طور کامل پر بشه و به نتیجه نرسه. تمام محصولات دیگری که امتحانشون کردیم، هر چقدر هم پیشرفته بودن و از مدل‌های بهتر و توکن بیشتری استفاده می‌کردن، باز هم مشکل اصلی پابرجا بود. اینکه کانتکست دیواری و دانش کتابخانه‌های داخل سازمانی رو نداشتن و عملکردشون به همین علت، بهینه نبود. در خیلی از موارد هم مستندات معتبری داشتیم و یا ساخته بودیم که به خوبی ازشون استفاده نمی‌شد.

مکانیزم پیشنهادی برای حل کردن این مسائل در مدل‌های زبانی قابلیت استفاده از ابزار (tool calling) در عامل‌های (agents) هوش‌مصنوعی بود. اینطور که خود مدل بسیاری از داده‌هایی که نیاز داره رو به دست بیاره، و خودش اکشن‌هایی که پیشنهاد می‌ده رو انجام بده و خروجی‌شون رو بررسی کنه. این یعنی مسئولیت از دوش کاربر استفاده کننده برداشته بشه.

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

اینجا بود که با MCP آشنا شدیم. MCP یک پروتکل باز بر پایه JSON-RPC v2 هست که توسط Anthropic معرفی شده برای اینکه تعامل LLMها با بقیه APIهای موجود رو استاندارد کنه و از وقتی عرضه شده، استقبال زیادی داشته. در حال حاضر تقریبا هر LLM Application پراستفاده‌ای ازش پشتیبانی می‌کنه (لیست محصولاتی که از MCP پشتیبانی می‌کنند). برای همین ما هم تصمیم گرفتیم تعدادی سرور MCP توسعه بدیم و ببینیم که به مدل‌ها در انجام تسکشون کمک می‌کنه یا نه.

....

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

‍ پروژه گارنت : فرزند نوظهور مایکروسافت برای رفع محدودیت‌های ردیس
اخیراً پستی درباره‌ی جایگزین‌های اپن‌سورس 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

‍ وقتی شمارش دقیق خیلی گرون میشه: 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

‍ فشرده‌سازی 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

‍ جلسه اول دوره 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

‍ معرفی Icebox: ساده‌ترین راه برای تجربه Apache Iceberg و دنیای Lakehouse

اگر همیشه کنجکاو بودید که 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

‍ از 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

‍ فیلم آموزش عملی 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 در تلگرام پیام بدهید

‍ شروع ثبت‌نام دوره عملی 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/

‍ تجربه استفاده از StarRocks در تیم دیتای اسنپ
پست رضا دهقانی در لینکدین

تجربه کار با 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-

آپاچی دوریس و سرعت بالا در سناریوهای مبتنی بر JOIN
- توضیحی راجع به 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

‍ شروع ثبت‌نام دوره تخصصی 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

‍ زیرساخت پردازش داده در 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

‍ و قتی سادگی پشت تجربه پنهان است: نکات کلیدی نگهداری 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