مهندسی داده و ام‌ال‌آپس 🚀

یکی از اصلی‌ترین نیازهای فعلی سازمان‌های بزرگ دولتی در ایران؛ نیاز شدید و میرم به یک دیتاپلت‌فرم هست. سپاس از دکتر بنایی عزیز بابت اشتراک این مطلب. . @elmedadeir

‍ چطور یک 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

چقدر این دوتا تصویر، به طرز عجیبی بهم وابسته هستند . @elmedadeir

#نکته دوتا واژه داریم که خیلی عجیب بجای هم داریم استفادشون می‌کنیم ولی با هم فرق دارند: Incident & Disaster Incident (رخداد/حادثه): یک اختلال محدود و کوتاه ‌مدته که قابل مدیریت هست. مثال: ای‌پی‌آی (API) پرداخت برای ۵ دقیقه هنگ می‌کنه. تیم بک‌اند باید رفعش بکند. بعد از رفع سیستم سریع به حالت عادی برمی‌گرده. Disaster (فاجعه): یک اختلال گسترده و طولانی ‌مدته که کل سیستم یا کسب‌وکار را تهدید می‌کند و نیاز به طرح اضطرار (Disaster Recovery Plan) دارد. مثال: مرکز داده اصلی آتش گرفته و کل دیتابیس ۳ ساعت آفلاین شد. مجبور شدیم به منطقه دوم (DR Site) سوئیچ کنیم. پس فرقشون یکجورایی در دامنه و مدت زمان هست. . @elmedadeir

از صفحات اکسل تا امن نمودن سرویس‌های هوش مصنوعی سازمان - اولش فقط تحلیل داده بود. میومدیم اعداد رو نگاه میکردیم و دنبال این بودیم که بفهمیم چه خبر بوده. - بعد کمی گذشت و اعتماد بنفس پیدا کردیم. جلوتر رفتیم و رسیدیم به مدل‌سازی و پیش‌بینی آینده. دیگه نمی‌گفتیم «چه شد؟» گفتیم «چه خواهد شد؟» - ولی ناگهان گیر کردیم.  چون زیرساخت داده‌ی درست و حسابی نداشتیم. پس مجبور شدیم یک قدم عقب بریم. اینجا بود که «مهندســــی داده» وارد شد. لوله‌کشی داده، جابه‌جایی و ساختاردهی دیتا در مقیاس بزرگ و تلاش برای تحویل اطلاعاتِ تروتمیز به مصرف‌کنندگان تشنه‌ی دیتا. - مدتی که کارهای مهندسی داده رو بردیم جلو، فهمیدیم دستی و سنتی داریم کار می‌کنیم. این شد که دیتاآپس (DataOps) اومد؛ یعنی اتوماسیون، سی‌آی/سی‌دی برای داده، ورژن کنترل، تست خودکار و مانیتورینگ و در نهایت همکاری واقعی بین تیم‌ها. یعنی تقریبن همون دواپس، ولی اینبار برای داده. - حالا که دیتای خوب رسید دست اهلش، نوبت رسید به تمرکز روی مدل یادگیری ماشین. ضعف‌ها رو فهمیدیم. در این نقطه بود که ام‌ال‌آپس (MLOps) معرفی شد. یعنی مدل‌های یادگیری ماشین رو از نوت‌بوک دربیاریم و ببریم تو خط تولید. همون جوری که بچه‌های نرم‌افزار در جریان خلق یک محصول نرم‌افزاری استاندارهایی رو دارند، می‌بایست برای یک مدل یادگیری ماشین هم ما همین روش رو دنبال کنیم. - با اومدن مدل‌های زبانی بزرگ، ام‌ال‌آپس دیگه کافی نبود. هنوز ما استانداردهای بروزتری رو نیاز داشتیم. پس ال‌ال‌ام‌آپس (LLMOps) توسط توسعه دهندگان این نوع مدل‌ها پیشنهاد شد. مدیریت پرامپت، رگ (RAG)، هزینه‌های استنتاج. خلاصه همه چی در مرحله‌ی بکارگیری یک مدل زبانی بصورت سرویس در محیط پروداکشن باید در نظر گرفته بشود. - اما مدتی هست که عامل‌های خودمختار دارن همه کارها رو می‌گیرن دستشون، دیگه ال‌ال‌ام‌آپس هم یه جاهایی کم آورد. متخصصین ایجنت‌آپس (AgentOps) رو پیشنهاد دادند. یعنی مدیریت رفتار و تصمیم‌گیری این عامل‌ها. چون اگر درست محدود و هدایت نشوند، کل اکوسیستم سازمان رو ظرف چند ساعت به فنا خواهند داد. - و اما امروز؟ ام‌ال‌سک‌آپس (MLSecOps) و جن‌ای‌آی‌آپس (GenAIOps) اومدن بالای همه اینا؛ یعنی لایه‌‌ی امنیت و حکمرانی که تضمین می‌کنه هر چی تا الان ساختیم، واقعن قابل اعتماد باشه. من گمان می‌کنم خطرناک‌ترین شیوه‌ی چیدن تیم‌ها برای خلق یک محصول هوشمند اینه که ما به لایه‌ی آخر توجه نکنیم. چون اینجا اگر خوب عمل نکنیم، خفن‌ترین محصول هوشمند که براش شاید میلیاردها خرج شده، ظرف چند روز به چوخ برود. دوره‌ای که ما طراحی کردیم دقیقن همون مرحله‌ی نهمه؛ یعنی ام‌ال‌سک‌آپس. اونجا یاد می‌گیریم که چطور از کل این زنجیره در برابر حملات واقعی محافظت کنیم. نه تئوری، فقط کار عملی با ابزارهای روز. دقت کنید که من بشخصه یا هیچ فرد و سازمانی نمی‌تونیم از شما یک متخصص خفن امنیت مدل‌های یادگیری ماشین بسازیم. ما تنها سعی می‌کنیم که اون حالت ذهنی و طرز تفکر (mindset) فعلی شما رو بسمت امنیت هدایت کنیم. چطور؟ با نشون دادن چند مثال. آیا تمام حملات پوشش داده می‌شن؟ به هیچ وجه. چنین چیزی تنها یک ادعای احمقانه است. مابقی سئوالات شما، شاید در لینک زیر پاسخ داده شود https://www.m-fozouni.ir/mlsecops . #امنیت_سایبری #ام_ال_سک_آپس #یادگیری_ماشین #هوش_مصنوعی . @elmedadeir

این تصویر هم متن بالا رو خلاصه کرده. تروتمیز و مرتب . @elmedadeir

#باز_نشر یکی از اشتباه‌ترین سوال‌هایی که درباره Message Brokerها پرسیده میشه اینه: کافکا بهتره یا ربیت‌ام‌کیو؟ بنظرم سوال درست این نیست. سوال درست اینکه سیستم شما Command محوره یا Event محور؟ این تفاوت کوچیک، میتونه کل معماری سیستم را تغییر بده! فکر میکردم Message Broker فقط برای Async کردن Taskها استفاده میشه مثل ارسال Email، SMS یا ساخت PDF. فرض کنین یک سفارش ثبت میشه: اگر هدف فقط این باشد که یک Email یا SMS ارسال بشه، با یک Command طرف هستیم یعنی یک سرویس از سرویس دیگر میخواد که کاری را انجام بده. اما اگر بخوایم ثبت سفارش در اختیار Analytics، Recommendation، Fraud Detection، Search، Dashboard و حتی سرویس‌هایی که هنوز وجود ندارند قرار بگیره دیگه موضوع اجرای یک Task نیست موضوع انتشار یک Business Event است. اینجاست که تفاوت بین Queue و Event Log خودشو نشون میده😎. یکی از نکاتی که کمتر دربارش صحبت میشه اینکه Kafka صرفا یک Message Queue سریع‌تر نیست. کافکا بر پایه Append-Only Log طراحی شده یعنی Eventها برای مدتی مشخص (Retention Policy) نگهداری میشن و Consumerها با استفاده از Offset تصمیم میگیرن از کدام نقطه شروع به خواندن کنن. به همین دلیل اگر امروز یک Consumer جدید به سیستم اضافه بشه میتونن Eventهای گذشته را دوباره پردازش کن قابلیتی که در بسیاری از سناریوهای Analytics، Machine Learning و Event Replay اهمیت زیادی داره. از طرف دیگه، RabbitMQ برای پردازش Background Jobها طراحی شده جایی که قابلیت‌هایی مثل Routing، Retry، Dead Letter Queue (DLQ)، Priority Queue و مدیریت Workerها اهمیت بیشتری از نگهداری بلندمدت پیام‌ها دارن. نکته‌ای که برای من جالب بود در بسیاری از سیستم‌های بزرگ، Kafka و RabbitMQ رقیب هم نیستند مکمل هم هستند. الگوی رایجی که در معماری‌های Enterprise دیده میشه Kafka مسئول انتشار و توزیع Business Eventها هست و سرویس‌هایی که نیاز به اجرای Task دارن، اون Eventها را میگیرن و Jobهای خودشون از طریق RabbitMQ مدیریت کنن. شاید مهم‌ترین چیزی که از این مبحث یاد گرفتم انتخاب Message Broker نباید بر اساس محبوبیت ابزار باشه قبل از انتخاب هر تکنولوژی، باید به این سؤال جواب داد: ایا در حال انتقال یک Command هستیم یا انتشار یک Event؟ ✅ معمولا جواب همین سؤال، مسیر معماری را مشخص میکنه. ✍️ منبع: خانم مهندس زهرا سعادتی (توسعه دهنده‌ی بک‌اند) . @elmedadeir

This link appears safe now, but online threats evolve constantly. . @elmedadeir

یکی از دوستان در لینکدین به اشتراک گذاشته بودند. نمی‌دونم چکاری می‌کنند ولی ممکنه از جایی به بعد شخص گرفتار بشود. . @elmedadeir

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

وقتی وارد یک تیم جدید می‌شم، اولین چیزی که بررسی می‌کنم کیفیت کد نیست. قبل از اینکه حتی یک خط کد ببینم، دنبال جواب این سؤال‌ها می‌گردم: - ارتباط بین تیم محصول و تیم توسعه چطور تعریف شده؟ - آخرین Release چه زمانی بوده؟ - اگر امروز یکی از اعضای کلیدی در دسترس نباشه، چه اتفاقی می‌افته؟ - تیم برای انتشار نسخه به چند نفر وابسته است؟ - اگر یک باگ بحرانی در Production پیدا بشه، چند ساعت طول میکشه تا اصلاح و منتشر بشه؟ تجربه به من نشان داده که پاسخ این سؤال‌ها، بیشتر از هزار خط کد درباره بلوغ یک تیم حرف می‌زنه. شاید به همین دلیل است که امروز بیشتر از کیفیت کد، کیفیت فرآیندها و تصمیم‌های مهندسی توجهم رو جلب می‌کنه. . منبع: لینکدین میرحسین شایسته . @elmedadeir

رساندن مدل‌هایتان به مرحلهٔ تولید، چالش بنیادین یادگیری ماشین است. ام‌ال‌آپس یا Machine Learning Operations (MLOps) مجموعه‌ای از اصول آزموده ‌شده را ارائه می‌دهد که با هدف حل این مسئله به ‌شیوه‌ای قابل ‌اطمینان و خودکار طراحی شده‌اند. این راهنمای روشنگر شما را با چیستی MLOps (و تفاوت آن با DevOps) آشنا می‌کند و نشان می‌دهد که چگونه آن را در عمل به‌کار بگیرید تا مدل‌های یادگیری ماشین خود را عملیاتی کنید.

بخشی از مقدمه کتاب. . @elmedadeir

یکی از دوستان پستی منتشر کردند در خصوص اینکه «هوش مصنوعی داره قدرت تفکر رو از ماها می‌گیره و ...». همین‌جوری که می‌خوندم و با تکون‌ دادن سر تایید می‌کردم متن رو، وقتی به پاراگراف آخر رسیدم، متوجه شدم که پست توســـط هـــوش مصنــــوعی تولید شده، نشان بارزش هم کال تو اکشن بسیار ضایع و چند هشتگ داغون است (کال تو اکشن = یعنی از مخاطب بخواهیم یه چیزی اون زیر پست برامون بنویسه که الگوریتم‌ها ما رو آدم خفنی برچسب بزنند). و برای چند ثانیه مونده بودم چه عکس‌العملی (با کلاسش می‌شه ری‌اکشن 😎) نشون بدم، بخندم یا ناراحت بشم. باور کنید؛ اگر خودمون بنویسیم، در کوتاه‌ترین زمان ممکن نوشتــــــن رو یاد خواهیم گرفت. ما به آدمِ فنـــی‌نویس نیاز داریم. همه چیز رو نباید هوش مصنوعی برامون مستند کنه. یه چیزهایی باید از دست این پدرسوخــــته دور و محفوظ بمونه. واقعن چه بلایی داره سرمون میاد؟ . @elmedadeir

لینکدین «فرهاد زندشیراز»