‍ آینده مهندسی داده از نگاه نتفلیکس، Airbnb و Databricks 🚀

📌 اوایل خرداد، نتفلیکس در رویداد سالانه‌ی خود یعنی Data Engineering Open Forum 2025، پنلی جذاب با عنوان «آینده مهندسی داده» برگزار کرد که در آن سه متخصص از غول‌های فناوری دیدگاه‌های‌شان را درباره آینده این حوزه به اشتراک گذاشتند.

🔸 Tikica (مدیر پنل – مهندس ارشد نتفلیکس)

🔸 Ryan Blue (هم‌بنیان‌گذار Databricks و سازنده Iceberg)

🔸 Jerry (مهندس ارشد Airbnb)

🔸 Ena (مهندس داده در نتفلیکس)

در این پنل، از مسیرهای شغلی تا چالش‌های امروز و مهارت‌های فردا صحبت شد. خلاصه‌ای از نکات مطرح‌شده را در ادامه می‌خوانید:

🎥 ویدئوی ۲۰ دقیقه‌ای این پنل: https://www.youtube.com/watch?v=VVWjdsuNrwE&ab_channel=NetflixEngineering

🔮 ۱. هوش‌مصنوعی؛ دستیار قدرتمند، نه تهدید

💬 برخلاف تصور رایج، #GenAI شغل مهندس داده را تهدید نمی‌کند، بلکه ابزار توانمندی برای کمک در کارهای پیچیده و تکراری‌ست:

✅ بازنویسی کوئری و کمک در مهاجرت

✅ بهبود مستندسازی و تسهیل پلتفرم

✅ تمرکز بیشتر بر حل مسائل کسب‌وکار

✅ ارتقاء کیفیت کد

🔍 اما این تحولات، نیاز به داده‌ی باکیفیت، مستند و شفاف را دوچندان می‌کند.

⚠️۲. چالش‌های فعلی در #مهندسی_داده

مهندسی داده دیگر فقط ساختن چند جدول و اجرای ETL نیست.

با رشد داده‌ها، ابزارها و انتظارات، چالش‌ها هم رشد کرده‌اند:

🚨 بررسی مشکلات کیفی در داده‌هایی که وارد مدل‌های LLM می‌شوند بسیار سخت‌تر است. برخلاف داشبورد یا A/B تست‌ها، این مدل‌ها شفاف نیستند.

🌐 اتصال بین انباره‌های داده آفلاین، آنلاین و اپلیکیشن‌های واقعی محصول‌محور، باعث شده دیتاپایپ‌لاین‌ها بسیار پیچیده‌تر شوند.

🛡 نگرانی‌های جدیدی درباره‌ی حریم خصوصی، لو رفتن اطلاعات حساس و نحوه‌ی کنترل داده‌های تولیدشده توسط LLMها شکل گرفته است.

🎥 مهاجرت به داده‌های چندرسانه‌ای (متن، تصویر، ویدیو) نیاز به مهارت و ابزارهایی دارد که خیلی از ما هنوز با آنها آشنا نیستیم.


🧠 ۳. مهارت‌های کلیدی برای آینده

پنلیست‌ها تاکید کردند که مسیر موفقیت همچنان از «پایه‌های مهندسی قوی» می‌گذرد:

📌 مدل‌سازی دقیق داده

📌 درک ساختارها

📌 تعهد به کیفیت


اما برای آینده، باید مهارت‌های زیر را نیز توسعه داد:

🔹 پردازش real-time و event-driven

🔹 آشنایی با جستجوی معنایی و vector DBها

🔹 توانایی پردازش داده‌های multimodal

🔹 یادگیری ابزارهای مدرن مانند #DBT، #DuckDB، #PyIceberg و...


🧭 ۴. تشخیص ابزار مفید از ترندهای هیجانی

چطور بین ابزارهای واقعی و ترندهای زودگذر فرق بگذاریم؟

پنل نکات خوبی درباره‌ی انتخاب تکنولوژی مناسب داشت:

✅ آیا این ابزار واقعاً کار ما را ساده‌تر می‌کند؟

✅ فقط نحوه‌ی استفاده‌اش را بلدم یا می‌دانم چرا و چطور کار می‌کند؟

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

✅ آیا به نیاز واقعی بیزینس پاسخ می‌دهد؟

📌 جمع‌بندی:

آینده‌ی مهندسی داده، ترکیبی‌ست از پایه‌های محکم فنی و یادگیری هوشمندانه‌ی ابزارهای جدید.

اگر هوشمند انتخاب کنیم و یاد بگیریم، GenAI حامی ماست، نه جایگزین ما.


#مهندسی_داده #GenAI #LLM #DataEngineering #Netflix #Airbnb #Databricks #DataQuality #AItools #OpenSource #TechTrends #آینده_شغلی

‍ لیک‌هوس در مسیر بلوغ: نگاهی به نسخه جدید #RisingWave و ادغام عمیق آن با #Iceberg

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

این معماری نه‌تنها نظم داده‌ها را تضمین می‌کند، بلکه بستر ایده‌آلی برای توسعه سامانه‌های هوش مصنوعی و مدل‌های یادگیری ماشین فراهم می‌سازد؛ زیرا داده‌های تمیز و استاندارد، پایه‌ی هر سیستم هوشمند هستند.

📌 اینجا همان جایی است که مفهوم #Lakehouse اهمیت خود را نشان می‌دهد: ترکیبی از داده‌های ساخت‌یافته‌ی خام به همراه یک استاندارد سازمان‌دهی مانند #ApacheIceberg که باعث می‌شود داده‌ها در مقیاس وسیع قابل ذخیره‌سازی، مدیریت و تحلیل باشند.

🚀با این حال، فناوری‌هایی چون Iceberg هنوز در مدیریت متادیتا، snapshotها و عملیات نگهداری، چالش‌هایی دارند. در همین نقطه است که نسخه‌ی جدید #RisingWave v2.6 می‌تواند فرآیند به کارگیری و مدیریت لیک‌هوس را تسهیل کند ✨


⚡️ترکیب #RisingWave + #ApacheIceberg + #Lakekeeper = ترکیب برنده!

✅ در این نسخه، RisingWave، به‌عنوان یک پایگاه داده جریانی سازگار با #PostgreSQL، به‌صورت بومی با Iceberg ادغام شده است. داده‌ها به‌صورت لحظه‌ای از #Kafka دریافت، در RisingWave پردازش، و سپس به شکل استاندارد در Lakehouse ذخیره می‌شوند.

✅این ارتباط از طریق #Lakekeeper برقرار می‌شود: یک #REST Catalog استاندارد که رابط رسمی میان RisingWave و Iceberg است.

✅ کتابخانه Lakekeeper علاوه بر مدیریت متادیتا و کنترل دسترسی‌ها (با پشتیبانی از #OpenFGA)، امکان راه‌اندازی و تنظیم #Lakehouse را به‌دلخواه شما فراهم می‌کند؛ مثلاً با استفاده از #MinIO یا هر فایل‌سیستم دیگر.

✅ سپس RisingWave با تنظیمات شما و در «لیک‌هوس شما» شروع به درج داده‌ها می‌کند.

✅ داده‌های غیرجریانی سازمان نیز می‌توانند با ابزارهایی مانند #ApacheSpark یا #PyIceberg به این بستر منتقل شوند تا یک Lakehouse کامل شکل گیرد: جایی که RisingWave بخش داده‌های جریانی را مدیریت می‌کند.

این ترکیب، از نظر فنی استاندارد و از نظر معماری، منعطف و آینده‌نگر است.

همچنین، عملیات نگهداشت و بهینه‌سازی داده‌ها مستقیماً در خود RisingWave انجام می‌شود، و بار سنگین مدیریت #Lakehouse از دوش تیم‌های داده برداشته می‌شود. 💪

🧠 ویژگی‌های کلیدی نسخه‌ی RisingWave ۲.۶

🔰 پشتیبانی از داده‌های برداری (Vector) برای جست‌وجوی شباهت

🔰حالت جدید Copy-on-Write برای snapshotهای تمیزتر در Iceberg

🔰دستور VACUUM FULL برای پاک‌سازی و فشرده‌سازی داده‌ها

🔰سازگاری کامل با #Lakekeeper REST Catalog

🔰تنوع sinkهای جدید برای #Snowflake، #Redshift، #Elasticsearch

🔰حالت Memory-Only برای پردازش‌های فوق‌سریع


🎥 به‌زودی ویدیویی منتشر می‌کنم که در آن ساخت یک #Lakehouse عملی با

#MinIO + #Lakekeeper + #Spark + #Trino + #StarRocks

را گام‌به‌گام بررسی می‌کنیم. 🚀

به باور من، مسیر آینده‌ی زیرساخت‌های داده به‌سمتی پیش می‌رود که #Lakehouse بستر اصلی ذخیره و تحلیل داده‌ها شود،

و ترکیب #RisingWave + #ApacheIceberg + #Lakekeeper یکی از گزینه‌های خوب سازمانی برای شروع این مسیر است. 🌟