‍ آیا در حال ورود به عصر جدید مهندسی داده مبتنی بر عامل‌های هوشمند هستیم ؟
امروزه ایجنت‌های هوشمند (AI #Agents) در همه‌جا جولان می‌دهند؛ حتی به عمیق‌ترین لایه‌های زیرساخت داده نیز نفوذ کرده‌اند!
این روزها شخصاً مشغول طراحی یک کلاستر توزیع‌شده #ClickHouse برای یک سامانه ترید (Trading) هستم. ایجنت‌ها حتی در ستاپ کلاستر روی سرور اصلی هم به همیار اصلی من تبدیل شده‌اند؛ اما اعتراف می‌کنم که هنوز با ترس، لرز و احتیاط کامل از آن‌ها استفاده می‌کنم.

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

بیایید کمی این دغدغه را واکاوی کنیم؛ واگذاری تصمیم‌گیری به ایجنت‌های خودمختار در زیرساخت داده چه چالش‌های جدیدی برای ما ایجاد کرده است؟
۱. ⚠️ خطاهای خاموش (Silent Failures):
در سیستم‌های سنتی، یک کد اشتباه ارور مشخص (مثل 5xx) می‌دهد. اما ایجنت‌ها ممکن است بدون هیچ خطایی، صرفاً «تصمیم اشتباهی» بگیرند! (مثلاً واکشی بی‌سروصدای داده از یک جدول تستی به‌جای دیتای اصلی بدون آنکه ما متوجه شویم).
۲. 🔄 حلقه‌های بی‌نهایت (Infinite Retries):
تلاش ایجنت برای اصلاح خودکار و مداوم یک کوئری خطادار، می‌تواند به اسپم شدن دیتابیس و از کار افتادن سرورهای عملیاتی (DDoS ناخواسته!) منجر شود.
۳. 🛑 دسترسی‌های خطرناک:
دادن سطح دسترسی Write/Update به یک سیستم خودمختار ریسک وحشتناکی است. ایجنت ممکن است با درک اشتباه از درخواست «بهینه‌سازی یا پاکسازی»، هزاران رکورد حیاتی سامانه را تغییر داده یا حذف کند.
۴. 🔐 نشت داده‌های حساس (Data Privacy):
همیشه این ریسک وجود دارد که ایجنت‌ها داده‌های محرمانه مشتریان (PII) را برای قالب‌بندی یا پردازش بهتر، به API مدل‌های زبانی خارجی (LLMs) ارسال کنند.

🧩 استراتژی ما در این دوران گذار چیست؟
در حال حاضر امن‌ترین رویکرد، استفاده از معماری ترکیبی (Hybrid) است. یعنی اجرای پردازش‌های سنگین و حساس با ابزارهای قطعی و اثبات‌شده (مانند #ApacheSpark یا خود انجین‌های دیتابیس)، و استفاده از ایجنت‌ها صرفاً برای «درک هدف کاربر» و «تولید کدهای پیشنهادی» تحت نظارت انسان.

💡 خلاصه کلام:
نقش ما به عنوان مهندس داده دیگر صرفاً «توسعه پایپ‌لاین و مدیریت اجرای کدها» نیست؛ ما در حال گذار به جایگاه حساسِ «مدیریت کیفیت تصمیم‌گیری هوش مصنوعی» هستیم. اصول بنیادین مهندسی داده پابرجا می‌مانند، اما اکنون رسالت جدید ما این است که یاد بگیریم این همکاران باهوش اما غیرقابل‌پیش‌بینی را در چارچوبی امن و استاندارد مهار کنیم.

برای موفقیت در این پارادایم جدید، باید جعبه‌ابزار مهارتی خود را به‌روز کنیم. وقت آن رسیده که خود را به کار با فریم‌ورک‌های ارکستراسیون و ابزارهای تخصصی مدیریت ایجنت‌های هوشمند (مانند #Hermes و موارد مشابه) مجهز کنیم تا بتوانیم رفتار آن‌ها را کانالیزه کنیم.

مهم‌تر از همه؛ پیش از آنکه به این ایجنت‌ها اجازه دهیم مستقیماً با زیرساخت داده و دیتابیس‌های حیاتی ما تعامل داشته باشند، باید قوانین سفت‌وسخت و محدودکننده‌ای (Guardrails) برایشان تعریف کنیم. در این معماری جدید، مانیتورینگ دقیق و لحظه‌ای تغییرات داده‌ها و اعمال سخت‌گیرانه‌ترین مجوزهای دسترسی (Permissions) دیگر یک توصیه نیست، بلکه خط قرمز ما برای جلوگیری از فاجعه است!

🚀 وبینار تخصصی: بررسی معماری استریمینگ و تحلیل بلادرنگ با پروژه‌های نوظهور آپاچی
سلام به همراهان عزیز کانال، 🌟
همان‌طور که احتمالاً در اکانت رسمی لینکدین VeloDB دیده‌اید، قرار است سه‌شنبه هفته آینده (۲۳ تیرماه) رویداد بسیار جذابی برگزار شود. این وبینار فرصت فوق‌العاده‌ای است تا به بررسی دو ابزار قدرتمند و آینده‌دار از اکوسیستم داده Apache بپردازیم؛ پروژه‌هایی که با سرعت بالایی در حال تثبیت جایگاه خود در معماری‌های نوین داده هستند:
🔹آپاچی ایگی (Apache Iggy (Incubating: پلتفرم استریم پیام فوق‌سریع، پایدار و مقیاس‌پذیر (توسعه‌یافته با زبان Rust).
🔹آپاچی دوریس Apache Doris: پایگاه‌داده تحلیلی با قابلیت پردازش بلادرنگ (Real-time) و سرعت پاسخ‌گویی زیر یک ثانیه (Sub-second).
در این رویداد، علاوه بر واکاوی معماری مرجع برای تحلیل‌های بلادرنگ، یک دموی زنده (Live Demo) از یکپارچه‌سازی این دو ابزار از طریق کانکتور Iggy Sink نیز ارائه خواهد شد.
🗓 زمان برگزاری: سه‌شنبه آینده، ۲۳ تیر، ساعت ۲۱:۳۰ به وقت تهران - لینک ثبت نام
🎤 سخنرانان: Kranti Parisa (بنیان‌گذار LaserData) و Yuankai Shen (مدیر ارشد محصول VeloDB)

‍ نگاهی به موضوع گسترش کدنویسی مبتنی بر هوش مصنوعی و مشکلاتی که برای جامعه متن‌باز دنیا به وجود آورده است.

بیایید به همین چند وقت پیش برگردیم؛ روزگاری که دنیای پروژه‌های متن‌باز (اوپن‌سورس) شبیه یک کارگا بزرگ و دوستانه بود. 🤝

در آن روزها، اگر کسی می‌خواست کمکی بکند و کدی به پروژه اضافه کند (همان PR زدن)، راه میان‌بُری نداشت. باید آستین‌ها را بالا می‌زد، می‌نشست و خط به خطِ کدهای قبل می‌خواند 🧐 تا اصلاً بفهمد ماجرا از چه قرار است. بعد با کلی دقت تغییرات خودش را می‌نوشت ، بارها روی سیستم خودش تست می‌کرد تا خرابکاری نکرده باشد ✅، و در نهایت آن را برای صاحبان پروژه (Maintainer ها) می‌فرستاد.

همین «عرق ریختن و یاد گرفتن»، جادوی پنهان و راز موفقیت پروژه‌های اوپن‌سورس بود. ✨ نگهدارنده‌های پروژه می‌دانستند کدی که دستشان رسیده، حاصل ساعت‌ها فکر و تلاش یک انسان است؛ برای همین با آغوش باز از این مشارکت‌ها استقبال می‌کردند.

🚨 اما ناگهان ورق برگشت! 🌪

سر و کله‌ی هوش مصنوعی و ربات‌های هوشمند پیدا شد و آن مسیر طولانیِ «خواندن، فهمیدن و تست کردن» را به یک دکمه خلاصه کرد. حالا هر کسی می‌تواند بدون اینکه حتی یک خط از منطقِ کد را بفهمد، از هوش مصنوعی بخواهد ده‌ها کدِ ظاهرالصلاح بنویسد و برای پروژه‌های مختلف بفرستد.

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

💥 نتیجه؟ پدیده‌ای که محققان به آن “AI-DDoS” می‌گویند. (به آن AI-Slop هم می ‌گوییم)


تحقیقات سال ۲۰۲۶ روی نزدیک به ۳۰۰ ریپازیتوری نشان می‌دهد که با وجود انفجار تعداد Pull Requestها (PR)، نرخ تایید (Merge Rate) به شدت سقوط کرده است. https://arxiv.org/abs/2607.04003

نگاهی به وضعیت پروژه‌های بزرگ بیندازیم:

📉 آپاچی ایرفلو: زیر بهمنی از PRهای تولیدشده با AI غرق شده است؛ کدهایی که در ظاهر بی‌نقص اما در معماری کاملاً غلط هستند.

📉 آپاچی سوپرست: مینتینرها (Maintainers) در حال دریافت PR از توسعه‌دهندگانی هستند که حتی پروژه را یک‌بار هم روی سیستم خودشان (Local) اجرا (Run) نکرده‌اند!

📉 ابزار cURL: پس از ۶ سال، برنامه Bug Bounty خود را متوقف کرد. دلیل؟ ۲۰ درصد گزارش‌ها صرفاً “زباله‌های هوش مصنوعی” (AI Slop) بودند که هیچ آسیب‌پذیری واقعی در آن‌ها وجود نداشت.

🛑 کار به جایی رسیده که پروژه‌هایی مثل Ghostty و tldraw سیاست «تحمل صفر» اتخاذ کرده‌اند: ارسال کدِ بی‌ارزش هوش مصنوعی = بن شدن همیشگی!

⚠️ اما ریشه مشکل کجاست؟ “عدم تقارن تلاش” (Asymmetry of Effort)

تولید کد با AI در یک ثانیه انجام می‌شود، اما بررسی (Code Review) همان کد توسط یک مینتینرِ داوطلب، نیاز به ساعت‌ها زمان و تمرکز دارد. هر PR فیک، زمانِ طلایی برای رفع باگ‌های واقعی را می‌دزدد.

💡 چه باید کرد؟

ما به قوانین صریح‌تر برای مشارکت، ابزارهای اتوماسیون برای فیلتر کردن زباله‌های کدی، و از همه مهم‌تر «احساس مسئولیت» نیاز داریم.

قبل از اینکه به هوش مصنوعی بگویید «این مشکل را حل کن و PR بزن»، از خود بپرسید:

آیا می‌توانم خط به خط این تغییر را توضیح دهم؟ آیا آن را تست کرده‌ام؟ دارم کمک می‌کنم یا فقط به سروصداها اضافه می‌کنم؟

مینتینرها داوطلبند؛ آن‌ها به ما بدهکار نیستند. اگر خسته شوند و بروند، همه ما می‌بازیم.

‍ چطور یک Lakehouse مدرن را راحت روی لپ‌تاپمان بالا بیاوریم؟
این روزها همه‌جا صحبت از معماری #Lakehouse است؛ ترکیبی جذاب از انعطاف‌پذیری #DataLake و قدرت #DataWarehouse. روی کاغذ همه‌چیز عالی به نظر می‌رسد، اما وقتی می‌خواهیم خودمان دست به کار شویم و این ابزارها را کنار هم بچینیم، تازه دردسرها شروع می‌شود.
اگر دوست دارید بدون درد و خونریزی و به سرعت، یک محیط کامل و مدرن مهندسی داده مبتنی بر #LakeHouse را خیلی راحت روی لپ‌تاپ خودتان تجربه کنید، پیشنهاد می‌کنم حتماً نگاهی به مخزن SoloLakehouse بیندازید. این پروژه مثل یک زمین بازی (Sandbox) فوق‌العاده است که با Docker Compose خیلی راحت بالا می‌آید و به شما اجازه می‌دهد با ابزارهای روز دنیا کار کنید.

🎯 چرا این پروژه دوست‌داشتنی است؟
توسعه‌دهنده خوش‌ذوق این پروژه، یک پشته داده مدرن (Modern Data Stack) واقعی را دور هم جمع کرده است:
⚡️برای ذخیره‌سازی از ترکیب MinIO و فرمت جذاب Apache Iceberg استفاده کرده است.
⚡️موتور قدرتمند Trino را برای پردازش داده‌ها قرار داده است.
⚡️برای مدیریت جریان کارها از Dagster استفاده کرده که کار با آن واقعاً لذت‌بخش است.
⚡️ابزارهایی مثل OpenMetadata برای مدیریت داده‌ها و Superset برای ساخت داشبورد هم در این مجموعه حضور دارند.
نکته جالب اینجاست که کدهای این پروژه خیلی تمیز و اصولی نوشته شده‌اند و مسیر توسعه آینده آن (مثل رفتن به سمت اجرای نهایی روی کوبرنتیز) خیلی شفاف و منطقی طراحی شده است.

💡 یک ایده دوستانه برای تنوع: اگر خواستید این محیط را برای خودتان حتی سبک‌تر هم بکنید، می‌توانید به جای ترکیب Trino و Hive، به سراغ ترکیب DuckDB و Lakekeeper بروید. برای اجرا روی یک سیستم شخصی، طبق تجربه شخصی، این ترکیب، به استک‌های داده مدرن نزدیک‌تر و امکانات بیشتری به شما ارائه میدهد.

در کل، اگر می‌خواهید با چالش‌های واقعی ساخت یک #Lakehouse آشنا شوید و مهارت‌هایتان را ارتقا دهید، گشت‌وگذار در کدهای این پروژه یک کلاس درس عالی و رایگان است.
🔗 این هم آدرس مخزن گیت‌هاب برای شروع:
https://github.com/Jiahong-Que-9527/SoloLakehouse

‍ آپاچی OSSIE: زبان مشترک داده‌ها در عصر هوش مصنوعی و پایان چالش «انحراف معنایی»
اگر از یک عامل هوش مصنوعی (AI Agent) بپرسید «نرخ ریزش مشتریان (Churn) ماه گذشته چقدر بوده؟»، احتمالاً پاسخی با اعتمادبه‌نفس اما نه چندان منطبق بر فرهنگ سازمان دریافت می‌کنید!
چرا؟ چون با وجود معماری‌های مدرن داده و پیشرفت‌های هوش مصنوعی، ما همچنان درگیر چالش «انحراف معنایی» (Semantic Drift) هستیم.


مشکل کجاست؟ 🚨
انحراف معنایی زمانی رخ می‌دهد که مفاهیم کلیدی کسب‌وکار در ابزارهای BI، پروژه‌های dbt و کدهای پایتون به شکل‌های متناقض و پراکنده تعریف شوند. این پراکندگیِ قفل‌شده در فرمت‌های انحصاری، نه‌تنها تیم‌های داده را مجبور به تطبیق دستی اعداد می‌کند، بلکه برای هوش مصنوعی یک نقص کشنده است؛ چرا که AI نمی‌داند کدام‌یک از این تعاریفِ پراکنده، «منبع حقیقت» (Source of Truth) سازمان شماست.

اینجاست که Apache OSSIE (Open Semantic Interchange) به عنوان استاندارد مرجع مفاهیم سازمانی عمل می‌کند.


🌍 اتحاد بی‌سابقه رقبا؛ چرا آپاچی و چرا الان؟

در عصر هوش مصنوعی، مسئله اصلی توان محاسباتی نیست؛ به عبارتی «تبدیل متن به SQL بخش سخت ماجرا نیست، چالش اصلی تبدیل متن به SQLِ درست و منطبق بر منطق تجاری است».

دقیقاً به همین دلیل است که رقبای سرسخت دنیای داده، از پلتفرم‌هایی نظیر Snowflake، Databricks، Google و AWS گرفته تا dbt Labs، ابزارهای حاکمیت داده مثل OpenMetadata و شرکت‌های هوش مصنوعی مانند Mistral، حول این پروژه گرد هم آمده‌اند. آن‌ها متوجه شدند که اکوسیستم، به یک استاندارد خنثی و مستقل از ارائه‌دهنده (Vendor-neutral) نیاز دارد. بنیاد آپاچی با پذیرش OSSIE در ژوئن ۲۰۲۶، بستر ایجاد این زبان مشترک جهانی و بی‌طرف را فراهم کرده است.

آدرس پروژه : https://ossie.apache.org


💡 راهکار OSSIE: «یک‌بار تعریف کن، همه‌جا استفاده کن»

این پروژه یک استاندارد باز (بر پایه YAML/JSON) برای تعریف یکپارچه مفاهیم معنایی (متریک‌ها، ابعاد و روابط) ارائه می‌دهد.

یک مثال عینی:

فرض کنید تیم بازاریابی، کاربر فعال (MAU) را «هر کاربر با حداقل 1 بار ورود» و تیم محصول آن را «کاربری با حداقل 3 اقدام» تعریف کرده‌اند. نتیجه این اختلاف، ۲ داشبورد مختلف با اعداد کاملاً متفاوت است!

با Apache OSSIE، این شاخص را تنها یک‌بار و به شکل استاندارد زیر تعریف می‌کنید تا به مرجع واحد حقیقت تبدیل شود:

metric:

  name: "Monthly Active Users"

  description: "Number of unique users with at least one login per month"

  type: "standard"

  formula: 

    sql_expression: "COUNT(DISTINCT user_id)"

  filter:

    condition: "event_date >= DATE_TRUNC('month', CURRENT_DATE)"

پس از این تعریف واحد، تمامی ابزارها (از موتورهای پردازشی و Tableau گرفته تا AI Agents) با استفاده از مبدل‌های (Converters) استاندارد، متادیتا را مستقیماً از این لایه می‌خوانند و به طور یکسان تفسیر می‌کنند.

⚡️ اجزای اصلی این معماری عبارتند از:
۱. مشخصات هسته (Core Spec): فرمت استاندارد مدل‌سازی.
۲. مبدل‌ها (Converters): مترجم‌هایی برای تبدیل به دایالکت‌های موجود (مثل dbt یا Apache Polaris).

🎯 خلاصه کلام:
در تقاطع تکامل پشته مدرن داده و بلوغ عامل‌های هوش مصنوعی، تضمین یکپارچگی معنایی امروز بیش از هر زمان دیگری حیاتی است. آپاچی OSSIE صرفاً یک ابزار جدید نیست؛ بلکه یک «مترجم جهانی» است تا داده‌های ما را برای جریان‌های کاری نسل بعدی هوش مصنوعی، کاملاً قابل‌اعتماد و تعامل‌پذیر کند.

‍ هنر تقریب: چرا دیتابیس‌های مدرن به اسکچ‌های داده (Data #Sketches) وابسته‌اند؟
آیا تا به حال داشبوردی داشته‌اید که به خاطر یک کوئری COUNT(DISTINCT) روی میلیاردها رکورد، به کندی بارگذاری شده و کاربر را منتظر بگذارد؟ ⏳
اخیراً در پروژه‌ای در حوزه خرده‌فروشی برای داشبوردهای روزانه‌ی شعب و نواحی (شامل تعداد محصولات یکتا، سود و ...)، به این نتیجه رسیدیم که دقت مطلق برای داشبوردها هزینه‌بر و کند است و با توابع تخمینی کلیک‌هاوس، به سرعت بالا و دقت >۹۹٪ دست یافتیم.

اهمیت این ساختارهای تقریبی در مهندسی داده آن‌قدر بالاست که بنیاد آپاچی یک پروژه مستقل و قدرتمند به نام Apache DataSketches را به توسعه آن‌ها اختصاص داده است و امروزه ردپای آن‌ها را در تمامی دیتابیس‌های مدرن می‌بینیم.
https://datasketches.apache.org/

⚡️ اما این اسکچ‌ها دقیقا چه هستند؟
اسکچ‌ها (Sketches) در واقع «اثر انگشت‌های آماری بسیار کوچکی» از داده‌های عظیم ما هستند. ما می‌پذیریم که در ازای مثلاً ۱تا ۲ درصد خطای محاسباتی، سرعت پردازش را هزاران برابر کنیم و مصرف رم (RAM) را به شدت کاهش دهیم.
بیایید با ۳ مثال شهودی، الگوریتم‌های اصلی تخمینی مدرن را بررسی کنیم:
۱. 🔹 الگوریتم‌های HLL و CPC (متخصص شمارش یکتا):
چطور میلیاردها کاربر یکتا (Unique Users) را بشماریم؟
در یک اجتماع بزرگ، از همه کاربران می‌خواهیم اپلیکیشن شیر و خط را باز کنند و تعداد خط‌های پیاپی را قبل از رسیدن به شیر برای ما پیامک بفرستند (و به ازای هر گزارش، جایزه بگیرند). اگر کسی گزارش دهد که ۱۰ بار پشت‌سر هم خط آورده (احتمالی حدود ۱ در ۱۰۰۰)، می‌فهمیم جمعیت آن‌قدر زیاد است (حدود هزار نفر) که چنین شانس نادری رخ داده است. الگوریتم‌های HLL و CPC نیز دقیقاً با همین منطق، با شمارش طولانی‌ترین توالی صفرهای پیشرو در هش داده‌ها، جمعیت یکتا را تخمین می‌زنند.

۲. 🔹 الگوریتم Theta (متخصص عملیات مجموعه‌ها و همپوشانی):
چطور اشتراک محصولات ده‌ها شعبه فروشگاه را پیدا کنیم؟
به‌جای نگهداری لیست کامل محصولات، قانونی ساده وضع می‌کنیم: «فقط محصولاتی را نگه دار که ۳ رقم آخر کدشان ۱۲۳ باشد.» این یک نمونه‌گیری تصادفی قطعی است. سپس لیست‌های چندصدتایی حاصل را بین شعبه‌ها مقایسه می‌کنیم؛ اگر مثلاً ۱۰ محصول مشترک یافت شد، با تناسب ریاضی، همپوشانی کل را در مقیاس میلیونی تخمین می‌زنیم.

۳. 🔹 الگوریتم KLL (متخصص توزیع داده و صدک‌ها مثل P99):
چطور نمره یک درصد برتر را بین یک میلیون دانش‌آموز پیدا کنیم؟
برگه‌ها را دسته‌بندی و مرتب کنید. نیمی را دور بریزید و به نیمی دیگر وزن ۲ بدهید. این کار را تکرار کنید و هر بار وزن باقی‌مانده را دو برابر کنید. با این فشرده‌سازی لایه‌به‌لایه و وزنی، در نهایت دسته‌ای کوچک نمایندۀ کل یک‌میلیون نفر می‌شود و مرز P99 را به‌راحتی مشخص می‌کند.

✨ جادوی اصلی: ادغام‌پذیری (Mergeability)
چرا این اسکچ‌ها در سیستم‌های توزیع‌شده (Distributed Systems) شاهکار هستند؟ چون شما می‌توانید اسکچِ سرور A را با اسکچِ سرور B ترکیب کنید و به یک اسکچ واحد برسید، بدون اینکه نیاز باشد به داده‌های خام برگردید!

در کلیک‌هاوس، این کار با ساخت Materialized Viewها و استفاده از توابع State (برای ساخت اسکچ هنگام ورود داده) و Merge (برای ترکیب اسکچ‌ها زمان کوئری گرفتن) انجام می‌شود. نتیجه؟ داشبوردی که در کسری از ثانیه لود می‌شود.

تغییر مدل ذهنی از «دقت مطلق و پرهزینه» به «تقریب هوشمندانه و سریع»، یکی از ضروری‌ترین مهارت‌های مهندسی داده در معماری‌های مدرن است.

‍ فراتر از یک دیتابیس تراکنشی: بررسی قابلیت‌های #HTAP، جستجوی برداری و اتصال مستقیم به Iceberg در #AliSQL
سال‌هاست که سیستم‌های داده را بر اساس یک قانون نانوشته می‌سازیم: جداسازی دیتابیس‌های عملیاتی (#OLTP) از موتورهای تحلیلی (#OLAP).
همگام نگه‌داشتن این دو محیط، به معنای درگیری با پایپ‌لاین‌های پیچیده #ETL، کانکتورهای شکننده #CDC و بحث‌های همیشگی «تازگی داده‌ها» (Data Freshness) است. این در واقع هزینه‌ای بود که برای پایداری سیستم می‌پرداختیم؛ اما چه می‌شد اگر می‌توانستیم با چند تصمیم معماری هوشمندانه، این مرزها را پاک کنیم؟ آن هم بدون تغییرات گسترده در کدها و با حفظ پایداری همیشگی سیستم؟

این دقیقاً همان تغییری است که تیم دیتابیس ابری علی‌بابا با معرفی نسخه متن‌باز AliSQL 8.0.44-2 (انشعاب بهینه‌شده MySQL نسخه ۸) ایجاد کرده است. فرمولی برنده از ترکیب پایداری MySQL، سرعت خیره‌کننده DuckDB و قابلیت‌های پیشرفته هوش مصنوعی.

🎯 این یک ایده آزمایشگاهی نیست؛ این معماری طی یک دهه برای زنده ماندن در هرج‌ومرج ترافیکی رویداد جمعه سیاه آب‌دیده شده و امروز روی بیش از ۱۰۰۰ نود پروداکشن در حال اجراست. نتیجه؟ تا ۷۰٪ پرفورمنس بهتر و ۹۵.۲٪ کاهش زمان ریکاوری (Crash Recovery) نسبت به #MySQL کامیونیتی.

اگر درگیر طراحی سیستم‌های داده‌محور هستید و دنبال یک پلتفرم جامع و مقیاس‌پذیر هستید و یا به دنبال بهبود #MySQL خود هستید، این ۴ تغییر زیربنایی در AliSQL قطعا توجه شما را جلب خواهد کرد:
🚀 ۱. موتور تحلیلی بومی #DuckDB (یکپارچگی HTAP)
دیتابیس #AliSQL حالا #DuckDB را به عنوان یک Storage Engine در کنار InnoDB به رسمیت می‌شناسد. این یعنی کوئری‌های تحلیلی ستونی تا ۲۰۰ برابر سریع‌تر اجرا می‌شوند. نکته جذاب؟ نیازی به درایور جدید یا تغییر Connection String نیست؛ برنامه‌های شما همچنان با پروتکل استاندارد MySQL ارتباط برقرار می‌کنند.

🧠 ۲. جستجوی برداری بومی برای عصر AI
ورک‌لودهای مدرن نیازمند جستجوی معنایی هستند. این نسخه از نوع داده #VECTOR (تا ۱۶,۳۸۳ بعد) همراه با ایندکس‌های #HNSW پشتیبانی می‌کند. با این قابلیت، می‌توانید الگوهای #RAG، موتورهای پیشنهادگر و جستجوی معنایی را مستقیماً داخل سیستم OLTP خود اجرا کنید.

🌊 ۳. نوشتن مستقیم روی Apache #Iceberg (پلی به سوی #Lakehouse)
اینجا همان نقطه عطف ماجراست! از طریق پلاگین DuckDB Iceberg، دیتابیس دیتای تراکنشی را مستقیماً روی جداول Iceberg (درون S3) می‌نویسد.
نتیجه؟ حذف کامل پایپ‌لاین‌های CDC. دیتا به محض Commit شدن، توسط موتورهایی مثل #Spark، #Flink و #Trino قابل کوئری گرفتن است. دیتابیس عملیاتی شما دیگر فقط «منبع بالادستی» دیتا لیک نیست، بلکه تبدیل به بخشی از خود دیتا لیک شده است.

⏪ ۴. بهینه‌سازی‌های عمیق و Native Flashback
امکان کوئری زدن به دیتای گذشته با AS OF TIMESTAMP و بهینه‌سازی‌های سطح پایین Binlog که باعث کاهش شدید I/O اضافی و تاخیر در Commit تراکنش‌های بزرگ شده است.

✨تصویر بزرگ‌تر: عصر Lakebase
هرچند مفهوم “Lakebase” اخیراً توسط بازیگرانی مثل Databricks مطرح شده، اما معماری‌ای که AliSQL فراهم کرده، دقیقاً به همان الگوی یکپارچه OLTP + Lakehouse می‌رسد. این نشان‌دهنده یک همگرایی جدی در صنعت است؛ صنعتی که قاطعانه به سمت پاک کردن مرز بین تراکنش‌ها و تحلیل‌ها حرکت می‌کند.
این بازطراحی اساسی نشان می‌دهد که معماری‌های HTAP و همگرایی OLTP و Lakehouseها جدی‌تر از همیشه در حال توسعه هستند .
https://github.com/alibaba/AliSQL

‍ جنبش Local-First و آینده همگام‌سازی: چگونه CRDTها قوانین بازی را تغییر می‌دهند؟

در سال‌های اخیر، در دنیای توسعه نرم‌افزارهای توزیع‌شده شاهد رشد تدریجی و جذاب جنبشی هستیم به نام Local-First. البته این رویکرد قطعا برای تمام کاربردها مناسب نیست، اما ایده اصلی آن می‌تواند الهام‌بخش سیستم‌های توزیع‌شده مدرن باشد: به جای وابستگی همیشگی به دیتابیس‌های ابریِ مرکزی و سینک مداوم با سرور (که نیازمند اینترنت پایدار است)، هر کاربر روی نسخه لوکال سیستم خودش کار کند. این نسخه معمولاً حاوی داده‌های خود کاربر است.

نتیجه این رویکرد، سرعت بی‌نظیر و تجربه کاربری روان است. کاربر بدون هیچ تأخیری کارهایش را انجام می‌دهد و در نهایت، در بازه‌های منظم یا زمان اتصال مجدد به اینترنت، تغییرات به سرور ارسال می‌شوند.

اما یک چالش بزرگ وجود دارد! 🚨

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

برای حل این مشکل ذاتی، نیازمند ساختار داده‌هایی هستیم که Conflict-Free باشند. یعنی بتوانند به‌راحتی مقادیری که بین چند کاربر مشترکاً تغییر کرده‌اند را ردیابی کنند و مقدار نهایی آن متغیر را بدون هیچ‌گونه تعارض و بدون رد کردن حتی یک درخواست، به‌طور قطعی مشخص کنند.


ظهور منجیِ سیستم‌های توزیع‌شده: CRDT 💡

به این ساختمان‌های داده‌ای که دقیقاً برای همین رفع تعارض‌ها در سیستم‌های غیرمتمرکز طراحی شده‌اند، CRDT (مخفف Conflict-free Replicated Data Types) می‌گوییم.

برای درک بهتر، یک مثال ساده می‌زنم:

فرض کنید یک سیستم شمارنده (مثلاً تعداد لایک) داریم. در حالت آفلاین، نود A تعداد 10 لایک جدید و نود B تعداد 5 لایک جدید ثبت می‌کند. در روش‌های سنتی، ترکیب این دو ممکن است باعث بازنویسی داده‌ها شود و عدد نهایی اشتباه به دست بیاید. اما در ساختار CRDT داده‌ها به جای یک عدد ساده، با هویتِ نودِ تولیدکننده ذخیره می‌شوند (نقشه‌ای مثل A:10 و B:5). هنگام سینک شدن در سرور مرکزی، سیستم به سادگی مقادیر مستقل را می‌خواند و تجمیع می‌کند (مجموع = 15). هیچ لایکی گم نمی‌شود، هیچ تداخلی رخ نمی‌دهد و ترتیبِ رسیدن داده‌ها به سرور هم مهم نیست!

⚡️ امروزه ردپای CRDTها را در دیتابیس‌ها و سامانه‌های نوین می‌بینیم. از معماری Active-Active در Redis Enterprise گرفته، تا نرم‌افزارهای طراحی مشارکتی مثل Figma و فریم‌ورک‌هایی نظیر Yjs، همگی روی دوش این مفهوم جذاب ریاضی و نرم‌افزاری ایستاده‌اند.


چگونه سیستم‌های مدرن از CRDTها استفاده می‌کنند؟ ⚙️

ساختارهای داده بدون تعارض (CRDTs) با تضمین «سازگاری نهایی قوی» بدون نیاز به قفل‌گذاری، سنگ‌بنای سیستم‌های توزیع‌شده مدرن و معماری‌های Local-First هستند. نودها برای همگام‌سازی در این سیستم‌ها البته نیاز به مکانیزم‌های همگام سازی جدیدی دارند که برای مطالعه عمیق‌تر جزئیات فنی، الگوریتم‌ها و پیاده‌سازی‌های عملی این معماری، به مرجع تخصصی https://crdt.tech/ مراجعه کنید.

آینده لزوماً تنها در انحصار این معماری‌ها یا دیتابیس‌های خاص نیست؛ بلکه نیازمندی‌های جدید و معماری‌های نوین داده، ساختارهای جدیدی (مانند CRDTها) را بنا گذاشته‌اند که دست توسعه‌دهندگان را برای طراحی سیستم‌های توزیع‌شده مدرن، منعطف و بدون تعارض باز می‌گذارد.

کتاب «توسعه مبتنی بر مشخصات در عصر هوشواره» را منتشر میکنم؛ حاصل تجربه، مطالعه و مسیری که در پروژه اجرایی در شرکت داتین از ایده تا اجرا طی شد.

در این کتاب درباره عبور از وایبکدینگ، تدوین Spec، کنترل عامل‌های هوشواره‌ای، Spec Kit، MCP و پیاده‌سازی عملی با Codex و .NET 10 نوشته‌ام.

خوشحال میشوم پس از مطالعه، نظرها و تجربه‌های شما را بشنوم.

https://github.com/oroumand/SDD

منبع :
علیرضا ارومند

آشنایی با محصولات ابری حوزه داده (آمازون، آژور، گوگل) بر روی سیستم شخصی؛ بدون تحریم، بدون هزینه ارزی! 🚀☁️
کار با محیط‌های ابری (Cloud Environments) دیگر یک انتخاب نیست، بلکه یکی از الزامات قطعی مهندسان داده و معماران سیستم‌های نرم‌افزاری مدرن است. چالشی که به دلیل تحریم‌ها و هزینه‌های سنگین ارزی، فعالان زیرساخت و دیتای ایرانی را غالباً مجبور به استفاده از جایگزین‌های Open-Source و معماری‌های Local-First کرده است.
ابزار Floci یک شبیه‌ساز (Emulator) فوق‌سریع و بومی (Native) برای اجرای سرویس‌های کلاد است. هرچند این ابزار در اصل برای دور زدن تحریم‌ها ساخته نشده و در سطح جهانی برای افزایش سرعت تست و توسعه محلی (Local Development) میان مهندسان محبوبیت بالایی پیدا کرده است، اما برای ما مهندسان داده ایرانی یک فرصت مغتنم و دریچه‌ای به جهان زیرساخت‌های ابری دنیاست.
کافی است با یک دستور ساده، انواع سرویس‌های ابری رایج دنیا شامل AWS, Azure, GCP را بدون نیاز به اکانت یا توکن احراز هویت روی سیستم خودتان بالا بیاورید و عیناً با همان خط فرمان‌ها (CLI)، ابزارهای IaC (مثل Terraform) و SDKهای اصلی شروع به کار کنید!
چرا خانواده Floci یک Game-Changer برای مهندسی داده است؟
این ابزار کاملاً متن‌باز (MIT) و Credential-free است و سه کلود پروایدر اصلی را در قالب باینری‌های مستقل و فوق‌سریع ارائه می‌کند:
🟠 نسخه AWS (floci):
یک جایگزین مستقیم (Drop-in replacement) برای LocalStack. دقیقاً روی پورت 4566 کار می‌کند، از ۶۸ سرویس (شامل S3, Lambda, EKS) پشتیبانی کرده و زمان استارت آن فقط چند ده میلی‌ثانیه است!
🔵 نسخه Azure (floci-az):
روی پورت 4577 اجرا می‌شود و ۲۲ سرویس کلیدی آژور را پوشش می‌دهد. نکته جذاب؟ مصرف مموری آن در حالت Idle فقط ۱۳ مگابایت (13 MiB) است!
🟢 نسخه GCP (floci-gcp):
روی پورت 4588 در دسترس است و ۲۲ سرویس اصلی گوگل کلود (از جمله GCS, Pub/Sub, BigQuery) را به صورت لوکال در اختیارتان می‌گذارد.

ویژگی‌های طلایی برای معماران و توسعه‌دهندگان:
✅ بدون نیاز به تغییر کد (Zero Code Change): سیستم شما دقیقاً فکر می‌کند به کلود واقعی متصل است.
✅ سبک و مستقل (Standalone): درگیر کانتینرهای سنگین و مصرف بالای منابع رم نمی‌شوید.
✅ ایده‌آل برای پایپ‌لاین‌های CI/CD: سرعت بالا و ایزوله بودن آن، محیطی بی‌نقص برای تست‌های خودکار و اعتبارسنجی معماری داده فراهم می‌کند.
فرقی نمی‌کند می‌خواهید یک پایپ‌لاین دیتای جدید را تست کنید یا معماری سیستم توزیع‌شده خود را دیباگ کنید؛ Floci در حال حاضر سریع‌ترین مسیر برای تعامل واقعی با اکوسیستم کلود است.
🔗 آشنایی بیشتر و گیت‌هاب: https://floci.io - https://github.com/floci-io/

#DataEngineering #CloudNative #AWS #Azure #GCP #LocalDevelopment #DevOps #ModernDataStack #مهندسی_داده #زیرساخت #معماری_نرم_افزار

شروع کار با سرویس های ابری رایج دنیا روی سیستم شخصی - راهنمای نصب سریع Floci - 👆👆

‍ هشت سنگ‌بنای اصلی مهندسی داده - آنچه ابزارها بر روی آنها بنا می‌شوند.

اگر از کسی بپرسید: «چطور یک جراح ماهر شوم؟» و پاسخ بشنوید: «اول کار با تیغ را یاد بگیر، بعد دستکش و در نهایت بخیه زدن را»، قطعاً به او می‌خندید! جراحان با حفظ کردن کاتالوگ تجهیزات به مهارت نمی‌رسند؛ تخصص آن‌ها در درک آناتومی و تفکر سیستمی است.

اما متأسفانه ما مهندسی داده را شبیه لیست خرید آموزش 📚 می‌دهیم: #Spark, #Kafka, dbt, Apache #Iceberg و لوگوهای رنگارنگی که وایرال می‌شوند. اگر فکر می‌کنید چون کار با ۱۷ فریم‌ورک مختلف را نمی‌دانید از بقیه «عقب مانده‌اید»، خیالتان راحت باشد؛ فقط دارید به نقشه اشتباهی نگاه می‌کنید

.

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

1️⃣ مهندسی نرم‌افزار، فونداسیون سیستم: داده‌ها خودبه‌خود جابه‌جا نمی‌شوند. پیش از رسیدن داده به Warehouse، باید از APIها، سرویس‌های لاگینتگ و فریم‌ورک‌های اعتبارسنجی عبور کند. پایتون در محیط پروداکشن به معنای حل الگوریتم‌های LeetCode نیست؛ بلکه به معنای لوله‌کشی (Plumbing) اصولی است: مدیریت HTTP Retries، تضمین Idempotency، تعیین مرزهای خطا (Error Boundaries) و سریالیزیشن. این لایه، پایداری سیستم را بسیار بیشتر از تنظیمات دیتابیس تضمین می‌کند.

2️⃣ پایپ‌لاین‌های مقیاس‌پذیر و پایدار (Reliable Pipelines): چه در پردازش Batch و چه Streaming، اصول غیرقابل‌مذاکره یکسان‌اند: آشنایی با Exactly-once، مدیریت Backpressure، صف‌های پیام‌های مرده (DLQ) و رؤیت‌پذیری (Observability). ابزارهای ارکستریشن (مثل Airflow یا Dagster) می‌آیند و می‌روند، اما این تضمین‌ها ثابت‌اند.

3️⃣ معماری ذخیره‌سازی (بر اساس Access Pattern): این الگو را در کارتان رعایت کنید: استوریج آبجکت برای Data Lake، ذخیره‌سازی ستونی (#Columnar) برای تحلیل و OLAP، ذخیره سازی سطری برای OLTP و دیتابیس‌های برداری برای #Embeddings. اشتباه اصلی، انتخاب یک موتور ذخیره‌سازیِ غلط نیست؛ اشتباه، استفاده از یک موتور برای تمام نیازهاست. فرمت‌هایی مثل Iceberg یا Delta Lake مشکل «نسخه واحد حقیقت» را حل می‌کنند، اما نیاز به موتورهای پردازشیِ تخصصی را از بین نمی‌برند.

4️⃣ طراحی و تکامل اسکیما: سخت‌ترین تغییر در محیط پروداکشن، تغییر نام یک ستون است! رویکرد Schema-on-read تنها صورت مسئله را پاک می‌کرد؛ امروز قابلیت Schema Evolution در فرمت‌هایی مثل Iceberg آن را مدیریت‌پذیر کرده، اما همچنان بی‌هزینه نیست. شکستن Data Contractها در پایین‌دست (Downstream)، ده‌ها برابر بیشتر از طراحی درست آن‌ها در همان ابتدا هزینه دارد.

5️⃣ کیفیت و رؤیت‌پذیری داده: توافق‌نامه‌های تازگی داده (SLA)، مانیتورینگ نرخ Nullها، پایش توزیع داده و رهگیری Lineage. این موارد امکاناتِ «لوکس» نیستند؛ بلکه تنها مرزِ متمایزکننده یک پلتفرم داده‌ی قابل‌اعتماد از یک باتلاق داده (Data Swamp) هستند.

6️⃣ متادیتا و کشف‌پذیری: کاتالوگی که بگوید چه داده‌ای وجود دارد، چه معنایی می‌دهد، مالکیت آن با کیست و آخرین بار کی به‌روز شده است (مثل OpenMetadata). بدون این کاتالوگ، هر تحلیل‌گر جدیدی باید چرخ را از نو اختراع کند. فراموش نکنید که Agentهای هوش مصنوعی نیز به متادیتای ماشین‌خوان (Machine-readable) نیاز دارند، نه صرفاً داکیومنت‌های متنی.

7️⃣ حاکمیت و امنیت:امنیت در سطح ردیف (RLS)، ماسک کردن ستون‌ها (Column-level Masking)، لاگ‌های حسابرسی و سیاست‌های نگهداری (Retention). ابزارها تغییر می‌کنند اما این الزام که «افرادِ درست به داده‌هایِ درست دسترسی داشته باشند و نه هیچ‌کس دیگر»، همیشگی است.

8️⃣ هوشمندی و نظارت بر هزینه‌ها: ارزان‌ترین کوئری، کوئری‌ای است که هرگز اجرا نشود! و گران‌ترین پایپ‌لاین، پایپ‌لاینی است که کسی وجودش را به خاطر نمی‌آورد. ذخیره‌سازی ارزان است، اما پردازش (Compute) نه؛ و پایپ‌لاین‌های یتیم (Orphaned Pipelines)، بدهی‌هایی هستند که سودشان ماهانه مرکب می‌شود.

این ۸ ستون اهمیتی نمی‌دهند که از #Spark استفاده می‌کنید یا #Flink. همان‌طور که مارتین کلپمن در انجیل مهندسان داده (DDIA) می‌گوید:
اتکاپذیری (Reliability)، مقیاس‌پذیری (Scalability) و نگهداری‌پذیری (Maintainability) پایه‌های اصلی هستند؛ هر چیز دیگری صرفاً جزئیات پیاده‌سازی است.

ابزارها مدام تغییر می‌کنند، اما این ستون‌ها پابرجا می‌مانند.

‍ مقادیر پیش‌فرض؛ دشمنِ خاموشِ محیط پروداکشن

داستانِ ۲۰۰ گیگابایت لاگِ اضافی و درسی که گرفتم

چند هفته پیش در یک پروژه‌ی مشاوره، یک کلاستر ۶ نودیِ ClickHouse (شامل ۳ شارد و ۳ رپلیکا) طراحی کردیم. طبق استراتژی ذخیره‌سازی، داده‌ها باید تا ۳۰ روز روی سرور اصلی می‌ماندند و سپس توسط مکانیزم TTL به Object Storage منتقل می‌شدند. روی کاغذ همه‌چیز بی‌نقص بود؛ تا اینکه روز گذشته برای پروفایلینگِ مجدد منابع، سراغ کلاستر رفتم.

در کمال تعجب دیدم پیش از رسیدن به روز سی‌ام، حجم داده‌ها به نزدیک ۱ ترابایت (ظرفیت هارد اصلی) رسیده است! مقصر اصلی؟ جدول سیستمی system.text_log به‌تنهایی ۲۰۰ گیگابایت فضا اشغال کرده بود. دلیل این فاجعه ساده بود: مقدار پیش‌فرضِ سطح لاگ در کلیک‌هاوس روی trace (بالاترین سطح جزئیات) قرار دارد و من تغییر آن به warning را فراموش کرده بودم.

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



چند مقدار پیش‌فرضِ خطرناک که در دنیای دیتا کمین کرده‌اند

🧨 PostgreSQL → random_page_cost = 4.0

این عدد میراث دوران هارددیسک‌های مکانیکی (HDD) است. روی درایوهای SSD/NVMe باید این مقدار را به حدود 1.1 کاهش دهید؛ در غیر این‌صورت، Optimizer پستگرس همچنان با فرض کندی هارد، تصمیم میگیرد.

🧨 PostgreSQL → shared_buffers = 128MB

مهم نیست سرور شما چقدر RAM داشته باشد، پیش‌فرضِ پستگرس فقط 128 مگابایت است! این مقدار باید به حدود 25% از RAM فیزیکی تغییر کند. در غیر این‌صورت، دیتابیس برای کش کردن به سیستم‌عامل متوسل می‌شود که کارایی کوئری‌های سنگین را به‌شدت افت می‌دهد.

🧨 Redis → maxmemory = 0 & maxmemory-policy = noeviction

بدون تعیین سقف حافظه، ردیس تا آخرین بایتِ RAM سرور را می‌بلعد و سیستم را وارد وضعیت Swap می‌کند. با سیاست noeviction، به‌محض پر شدن حافظه، تمامی درخواست‌های Write با خطا مواجه می‌شوند.

🧨 Apache Spark → spark.sql.shuffle.partitions = 200

برای دیتاست‌های کوچک، ایجاد 200 پارتیشن، سربار (Overhead) شبکه‌ایِ بالایی دارد و پردازش را کند می‌کند. متقابلاً برای کلان‌داده‌ها، این عدد بسیار کم است و به تولید پارتیشن‌های حجیم و کاهش نرخ موازی‌سازی (Parallelism) منجر می‌شود.

🧨 MongoDB → WiredTiger Cache = 50% of (RAM - 1GB)

اگر قصد دارید چند اینستنس از مونگو را روی یک ماشین اجرا کنید، این پیش‌فرض خطرناک است؛ زیرا هر اینستنس نیمی از کل حافظه را رزرو می‌کند و به‌سرعت با پدیده‌ی OOM (Out of Memory) مواجه می‌شوید.

🧨 SQL Server →MAXDOP = 0 & Cost Threshold = 5

این ترکیب باعث می‌شود حتی کوئری‌های سبکِ OLTP نیز به‌صورت Parallel اجرا شوند و برای منابع CPU با یکدیگر رقابت کنند. نتیجه‌ی این رقابت، افزایش CXPACKET waitها و ناپایداری توان عملیاتی (Throughput) سیستم است.

🧨 Apache Kafka → log.retention.hours = 168 (فقط بر اساس زمان)

پاک‌سازی داده‌ها به‌طور پیش‌فرض فقط بر اساس زمان (۷ روز) است و هیچ سقف حجمی (log.retention.bytes) ندارد. اگر ورودی دیتا ناگهان اسپایک بزند، دیسکِ بروکر بدون هیچ هشداری صددرصد پر خواهد شد.

🧨 MySQL → innodb_buffer_pool_size = 128MB

این مقدار برای هر سروری با بیش از چندصد مگابایت داده کاملاً ناکافی است. برای جلوگیری از تبدیل شدن I/O دیسک به گلوگاهِ اصلی، این پارامتر باید روی 60% تا 80% از حافظه‌ی فیزیکی تنظیم شود.

‍ قهرمان خاموشِ پرفورمنس در کلیک‌هوس: ترکیب جادویی PREWHERE و Skip Indexes

ما هر روز با SQL و ابزارهای Modern Data Stack مثل ClickHouse سر و کار داریم؛ کوئری می‌نویسیم، پایپ‌لاین می‌سازیم و داشبوردها را تحویل می‌دهیم.

اما تسلط بر سینتکس (Syntax) همیشه کافی نیست. برای رساندن پرفورمنسِ پایپ‌لاین‌ها به بالاترین سطح ممکن، باید مکانیسم‌های درونی و معماری پایه‌ی این موتورها را درک کنیم و پابه‌پای تکامل آن‌ها آپدیت بمانیم.

یکی از قدرتمندترین و در عین حال مهجورترین قابلیت‌های کلیک‌هاوس، PREWHERE است.

در دیتابیس‌های ستونی (Columnar)، عملیات I/O گلوگاه اصلیِ هزینه‌هاست. فرض کنید یک ستون سنگینِ JSON با حجم 2KB را از روی دیسک می‌خوانید، فقط برای اینکه 99% از رکوردها را در شرط WHERE دور بریزید؛ این یعنی اتلاف محضِ منابع دیسک و پردازنده (CPU).

اینجا است که PREWHERE با یک تغییر فلسفه‌ی مهم وارد می‌شود: «ابتدا فیلتر کن، سپس کمتر بخوان.»



🚀 این مکانیزم ابتدا فقط ستون‌های سبکِ فیلتر را به کمک ایندکس‌ها می‌خواند، بلاک‌های نامربوطِ داده (Granules) را بر اساس شرط PREWHERE حذف می‌کند و تنها پس از آن، ستون‌های اصلی را برای رکوردهای باقی‌مانده از حالت فشرده (Decompress) خارج می‌کند و فیلتر اصلی (شرط WHERE) را بعدا روی این ستون‌ها اعمال می‌کند.


🧠اما نکته‌ی جذابِ نسخه‌های مدرن چیست؟

در نسخه‌های اخیر کلیک‌هاوس، این بهینه‌سازی به‌صورت پیش‌فرض فعال است. Optimizer به‌طور هوشمند و در صورت نیاز، شروط WHERE را به PREWHERE منتقل می‌کند (حتی از نسخه v23.11 به بعد، این شروط را بر اساس Data Selectivity به‌صورت داینامیک مرتب می‌کند!).

با این حال، بهینه‌سازی خودکار هم محدودیت‌هایی دارد. برای اینکه PREWHERE را به یک قدرتِ بلامنازع تبدیل کنید، باید معماری جداول را هوشمندانه طراحی کنید؛ مشخصاً با استفاده از Skip Indexes (مثل minmax، set، bloom_filter). این ایندکس‌ها به کلیک‌هاوس «نقشه‌ای» می‌دهند تا بتواند بدون خواندنِ حتی یک بایت از ستون فیلتر، از روی بلاک‌های کاملِ داده بر اساس شرط PREWHERE پرش کند.


در فایل PDF زیر، یک بررسی عمیق، بصری و مرحله‌به‌مرحله از این مفاهیم آماده کرده‌ایم:

📦 فلسفه‌ی «فیلترِ زودهنگام، خواندنِ کمتر»

📦 نحوه‌ی عملکرد خودکار PREWHERE در کلیک‌هاوس مدرن (و زمان‌هایی که باید دستی تغییرش دهیم)

📦 اهمیت تفاوت پارت‌های Wide در برابر Compact

📦 چگونه ترکیب PREWHERE + Skip Indexes سرعت کوئری‌ها را ۵ تا ۱۰ برابر افزایش می‌دهد

امیدواریم مفید و بینش افزا باشد...

آشنایی با PREWHERE در کلیک هوس - مرتبط با پست بالا 👆👆

‍ دیتابیسی که مخصوص DataFrameها ساخته شده؛ پایان درگیری با زیرساخت!
همه ما داده‌چی‌ها (مشابه با گاری‌چی/تلفن‌چی البته بلانسبت) این مسیر را رفته‌ایم: خواندن دیتا از فایل‌های اکسل، Parquet یا دیتابیس‌های سنتی، و بعد ساعت‌ها صرفِ تمیزکاری و تبدیل داده‌ها. در تمام این سناریوها، پیش‌فرض ما این بوده که باید داده را از یک منبع خارجی بخوانیم و تازه بعد از آن پردازش را شروع کنیم.
اما چه می‌شد اگر دیتابیسی داشتیم که دقیقاً برای کسانی طراحی شده بود که با #DataFrameها زندگی می‌کنند؟ ابزاری که اجازه دهد خودشان داده‌ها را بارگذاری کنند، تغییرات را ذخیره کنند و دیگر وابسته به تیم زیرساخت یا مهندسی داده نباشند؟
اینجاست که #ArcticDB ❄️ با همین ایده متولد شد؛ پاسخی به همین نیاز ساده که حالا به یک دیتابیس جذاب و کارآمد برای تیم‌های تحلیل داده تبدیل شده است. با این ابزار، دیگر نیازی نیست دانشمندان داده (Data Scientists) برای هر تغییری منت مهندسین داده را بکشند!
فقط کافی است یک Object Storage مقیاس‌پذیر مثل #MinIO (یا #S3 و Azure Blob) یا حتی استوریج محلی (LMDB) داشته باشند و بدون نیاز به پایپ‌لاین‌های پیچیده ETL، با میلیاردها رکورد با سرعت بالا کار کنند.

✅ چرا ArcticDB یک تغییر بزرگ (Game-Changer) برای تیم‌های تحلیلی است؟
این ابزار یک دیتابیس Serverless است که توسط Man Group (یکی از بزرگترین Hedge Fundهای دنیا) و با موتور پردازشی C++ توسعه یافته تا چالش‌های واقعی تحلیلگران را حل کند.

ویژگی‌های کلیدی که باید بدانید:
⚡️ عملکرد در مقیاس عظیم: پردازش ۱۰۰ میلیون سطر در ثانیه برای یک کلاینت و تا یک میلیارد سطر در ثانیه به‌صورت موازی!
⚡️ کاملاً Serverless و منعطف: با یک pip install arcticdb ساده نصب می‌شود و مستقیماً به استوریج شما (S3/Azure/Local) متصل می‌گردد.
⚡️ بی‌نیاز از Schema (Schema-less): برخلاف دیتابیس‌های سنتی، برای ذخیره داده نیازی به تعریف دقیق اسکیما ندارید؛ دیتافریم را همان‌طور که هست بنویسید و بخوانید (با قابلیت انتخاب Static یا Dynamic Schema برای آپدیت‌ها).
⚡️ پردازش تنبل (Lazy Evaluation): با API مشابه Polars، عملیات فیلترینگ و تجمیع داده‌ها (Aggregations) مستقیماً در موتور C++ انجام می‌شود تا مصرف مموری (RAM) به حداقل برسد.
⚡️ ورژن‌کنترل خودکار (Time Travel): هر تغییری که می‌دهید (Append/Update) به‌عنوان یک نسخه جدید ذخیره می‌شود. می‌توانید در تاریخچه داده‌ها سفر کنید که برای Backtesting و ممیزی بی‌نظیر است.
⚡️ طراحی‌شده برای Throughput بالا: برای رسیدن به بالاترین سرعت در بارهای کاری تحلیلی، معماری تراکنش‌های سنتی (ACID Isolation) کنار گذاشته شده تا عملیات خواندن و نوشتن بدون قفل‌گذاری (Locking) با حداکثر سرعت انجام شود.
⚡️ منبع حقیقت واحد (SSOT): سازماندهی داده‌ها در قالب “Library” و “Symbol” به جای مسیر فایل‌ها، برای کار تیمی بی‌نقص.

💡 نتیجه‌گیری:
استفاده از این معماری، زمان رسیدن به بینش (Time-to-insight) را در سازمان‌های وابسته به تیم‌های تحلیل داده، از ۶ ماه به ۱.۵ ماه کاهش داده و خروجی پروژه‌ها را بیش از ۱۰ برابر کرده است. #ArcticDB نشان می‌دهد که آینده زیرساخت داده برای تیم‌های تحلیلی، در پیچیدگی کمتر و نزدیکی بیشتر به ابزارهای Native پایتون (Pandas, Polars, DuckDB) خلاصه می‌شود.
اگر از جنگیدن با زیرساخت داده خسته شده‌اید و می‌خواهید روی تحلیل‌هایتان تمرکز کنید، ArcticDB ارزش بررسی را دارد.
اگر احیانا در حوزه تحلیل داده فعالیت میکنید و می خواهید کمی بیشتر در مورد این دیتابیس بدانید، فیلم سه دقیقه ای زیر در یوتیوب می تواند نقطه شروع مناسبی باشد : https://www.youtube.com/watch?v=5_AjD7aVEEM

‍ دیتابیس #TigerBeetle: دیتابیسی بسیار سریع و مقیاس‌پذیر و پایدار برای سامانه‌های پرداخت
اکثر ما هنگام یادگیری مفهوم «تراکنش» (Transaction) در دیتابیس‌ها، با این مثال معروف مواجه شده‌ایم: “فرض کنید مبلغی از حساب A کسر و به حساب B واریز می‌شود؛ این عملیات باید کاملاً اتمیک (Atomic) باشد (یا همه یا هیچ).”
اما همین عملیاتِ به‌ظاهر ساده، پایه و اساس تمامی سیستم‌های پرداخت و فین‌تک دنیا با حجم تراکنش روزانه بسیار بالاست. بیایید دیتابیسی را با هم بررسی کنیم که دقیقاً حول همین عملیات، و بهینه‌سازی آن در مقیاس‌های نجومی شکل گرفته است: TigerBeetle.
دیتابیس‌های سنتی (مثل MySQL یا Postgres) همه‌منظوره هستند. وقتی حجم تراکنش‌ها ۱۰۰۰ برابر می‌شود، وادار کردن این دیتابیس‌ها به مدیریت چنین مقیاسی، مساوی است با شاردینگ‌های پیچیده، درگیری شدید بر سر قفل‌ها (Lock Contention) و دست‌به‌دعا شدن برای حفظ یکپارچگی داده‌ها!

تایگر‌بیتل (#TigerBeetle) یک دیتابیس توزیع‌شده است که از پایه برای یک هدف ساخته شده: جابه‌جایی پول با بالاترین سرعت و دقت و در حجم بسیار بالا.

اما معماری این دیتابیس چه تفاوت‌هایی دارد؟ 👇
🔹 بدون SQL، فقط زبان کسب‌وکار: اینجا خبری از سربار کوئری‌ها نیست. ساختار اصلی داده‌های آن به صورت بومی بر محور «بدهکار/بستانکار» است و هر انتقال تنها یک ساختار (Struct) بهینه ۱۲۸ بایتی است.
🔹 تجمبع (Batching) در بالاترین سطح: ارسال تا ۸,۱۹۰ تراکنش تنها در یک درخواست ۱ مگابایتی! یعنی یک فراخوانی شبکه برای ثبت هزاران تراکنش در Write-Ahead Log.
🔹 معماری LSM-Forest: به جای LSM-Treeهای سنتی که در زمان فشرده‌سازی (Compaction) باعث توقف و کندی در نوشتن می‌شوند، این ساختار جلوی هرگونه توقف سیستم (Jitter) را می‌گیرد.
🔹 تحمل خطای پارانوئید: تایگربیتل فرض می‌کند که هارد دیسک قطعا خراب می‌شود. با استفاده از حدنصاب خواندن و چک‌سام‌های دقیق، حتی اگر چند رپلیکا همزمان خراب شوند، داده‌ها بدون مشکل بازیابی می‌شوند (https://www.infoq.com/presentations/tigerbeetle/)
🔹 اجماع VSR (بهتر از Raft): برای انتخاب رهبر (Leader Election) در کلاستر، از پروتکل VSR استفاده می‌کند که در شرایط خرابی لاگ‌ها، بسیار منعطف‌تر از Raft عمل کرده و از قفل شدن کلاستر جلوگیری می‌کند.
🔹 توسعه‌یافته با زبان سریع Zig (بدون زباله‌روب): اجرای تک‌رشته‌ای، بدون تخصیص حافظه پویا (Zero Malloc). نتیجه؟ تاخیر کاملاً قطعی و بدون پرش. این سیستم با قوانین سخت‌گیرانه «توان ۱۰ ناسا» تست شده است! یعنی با همان استانداردی نوشته شده که ناسا سفینه‌هایش را به فضا می‌فرستد؛ بدون اجازه رخداد خطا!

🚀 اعداد و ارقام؟
پردازش حدود ۱,۰۰۰,۰۰۰ تراکنش در ثانیه (TPS) با تاخیر صدک ۹۹ (p99 latency) زیر ۱۰۰ میلی‌ثانیه روی درایوهای NVMe!

💡 جمع‌بندی:

تایگربیتل قرار نیست جایگزین Postgres برای ذخیره پروفایل کاربران شما شود. بلکه Data Plane سیستم‌های حساس است. ابزاری بی‌نظیر برای: پرداخت‌های در لحظه (Real-time Payments)، تسویه‌حساب‌های مالی، و سیستم‌های مدیریت موجودی با رقابت بالا.

دوران شاردینگ‌های طاقت‌فرسا برای هندل کردن تراکنش‌های مالی سرآمده است.
پ.ن: «تایگربیتل» (سوسک ببری) نام یکی از سریع‌ترین و شکارچی‌ترین حشرات دنیاست. واقعاً نمی‌دانم چرا در دنیای مهندسی داده، سیستم‌های توزیع‌شدهِ مقیاس‌پذیر و جان‌سخت را روی خانواده سوسک‌ها نام‌گذاری می‌کنند؛ آن از CockroachDB و این هم از TigerBeetle! 😅🪲

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

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

• اطلاعات لازم داخل کانتکست نبوده
• سیستم RAG اطلاعات درست رو پیدا نکرده
• مدل ابزار مناسب نداشته
• جریان کار یا اعتبارسنجی ایراد داشته
• آزمونی نداریم که ثابت کنه تغییر جدید بهتره

اگر یکی از این‌ها درست باشه، پرامپت چاق‌تر احتمالاً راه‌حل نیست.

مدل هم جواب آماده‌ای توی کشو نداره. با توجه به چیزهایی که دیده، توکن بعدی رو پیش‌بینی می‌کنه و این روند رو ادامه می‌ده.

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

کتاب «LLM به زبان آدمیزاد» رو با همین نگاه نوشتم: یک راهنمای فارسی ۲۶۵ صفحه‌ای، رایگان و متن‌باز؛ از مفاهیم پایه تا پرامپت‌نویسی، کار با API، سیستم‌های RAG، ایجنت‌ها، امنیت، مدیریت هزینه و ارزیابی.

سعی کردم مطالب ساده و خودمونی باشن، اما سطحی نه.

کتاب را از ریپوی زیر می تونید دانلود کنید .
https://github.com/3lf/llm-for-humans
چند صفحه اول کتاب هم در پست بعدی گذاشته شده است.

چند صفحه نمونه از کتاب ۲۵۶ صفحه ای : LLM به زبان آدمیزاد - علی نجفی 👆👆

نسخه کامل کتاب LLMs-4-Humans