مفاهیم پایه

سيستم‌هاي فايلي در عصر کلان داده

۰

میانگین امتیاز

به این متن امتیاز دهید!

امتیاز کاربران: ۴٫۶۸ ( ۲ رای)

اين مطلب يكي از مقالات بخش ويژه نشريه ماهنامه شبكه در شماره ۱۳۳ با عنوان جنبش NoSQL مي‌باشد. جهت دريافت اين بخش ويژه به بخش پرونده‌هاي ويژه سايت مراجعه نمائيد.

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

google-hdd-techs-4f1647b-intro

شکل ۱- مرکز داده Monks Corner، واقع در کاروليناي جنوبي: کارمندان شرکت گوگل وضعيت ديسک‌هاي ذخيره‌سازي داده را بررسي

سيستم ذخيره‌سازي استفاده شده در موتور جست‌وجوي گوگل بايد بتواند در هر روز به ميليون‌ها درخواست خواندن و نوشتن اطلاعات پاسخ دهد. اين درخواست‌ها توسط پردازش‌‌هايي ارسال مي‌شود که به صورت مستقل روي هزاران سرور، در حال اجرا هستند. فرآيند پشتيبان‌گيري يا نگه‌داري از سيستم، تحت هيچ شرايطي نبايد منجر به غير‌فعال شدن اين سرويس‌ها شوند. از طرف ديگر اين مجموعه داده‌اي ناچار است به صورت بي‌وقفه در حال رشد و گسترش باشد. اين قابليت از آن جهت اهميت دارد که زيرساخت ذخيره‌سازي بايد بتواند صفحات يافته شده توسط روبات‌هاي جست‌وجو‌گر اينترنت را که هر روز بر تعداد آن‌ها افزوده مي‌شود، ذخيره کنند. در حال حاضر، روبات‌هاي موتور جست‌وجوي گوگل روزانه بيش از بیست پتابايت داده را پردازش مي‌کنند. شرکت گوگل براي پاسخ‌گويي به چنين نيازي نمي‌تواند حتي به قوي‌ترين معماري‌هاي ذخيره‌سازي که به صورت معمول در ساير پروژه‌هاي بزرگ استفاده مي‌شوند تکيه کند. ساير غول‌هاي دنياي وب و ابرشرکت‌هاي ارائه دهنده محيط پردازش ابري و مراکز داده فوق‌العاده بزرگ نيز با چالش‌هاي مشابهي روبه‌رو هستند. از جمله اين ابر شرکت‌ها مي‌توان به آمازون و شبکه‌های اجتماعی اشاره کرد. بيشتر مراکز داده سعي دارند تا فرآيند مقياس‌پذيري فضاي ذخيره‌سازي داده را از طريق افزودن به ظرفيت‌هاي ديسک‌ها و تعداد سرورهاي پايگاه‌داده و سرورهاي متصل به رسانه‌هاي ذخيره‌سازي، به انجام برسانند. اما اين رويکرد معمولاً با شکست مواجه مي‌شود زيرا محدوديت‌ها و التزام‌هاي موجود در محيط ابري جهت رسيدن به سطح کارايي و عملکرد بالا، چالشي است که روش مذکور نمي‌تواند پاسخ‌گوي آن باشد. در محيط ابري ممکن است در هر زمان با هزاران کاربر فعال مواجه باشيم که بايد به داده‌ها دسترسي داشته‌باشند و داده‌هايي که بايد در هر لحظه نوشته يا خوانده شوند، از چندين هزار ترابايت فراتر می‌رود.
اينجا مسئله چيزي غير از سرعت خواندن و نوشتن ديسک است. وقتي جريان داده در سطح شبکه ذخيره‌سازي به اين حد مي‌رسد، عملکرد و بازدهي شبکه ذخيره‌سازي داده است که مشکل‌ساز مي‌شود. حتي در صورت استفاده از بهترين سرورها و رسانه‌هاي ذخيره‌سازي، باز هم ممکن است تجهيزات SAN مورد استفاده، تبديل به گلوگاهي در مسير دسترسي و پردازش داده، شوند. معمولاً در اين وضعيت، با مشکلات مرتبط با محدوديت در مقياس‌پذيري سيستم مواجه مي‌شويم. با در نظر گرفتن سرعت افزايش ظرفيت مراکز داده در شرکت‌هاي بزرگ مبتني بر وب (براي نمونه به گفته جيمز هميلتون، نايب رئيس آمازون، در حال حاضر اين شرکت، روزانه به اندازه کل فضاي مورد استفاده توسط شرکت در سال ۲۰۰۱ ، به ظرفيت مرکز داده خود مي‌افزايد.) با استفاده از روش‌هاي معمولي که در مراکز داده کنوني براي ارتقاي ظرفيت به کار مي‌رود،‌هزينه‌هاي نرم‌افزاري، سخت‌افزاري و مديريتي اين فرآيند، بسيار زياد خواهد بود.

اين هزينه‌ها به ويژه زماني که پايگاه‌هاي داده رابطه‌اي به اين مجموعه افزوده شود، پيچيده‌تر مي‌شود و ميزان اين پيچيدگي به نحوه توزيع داده و تهيه مرکز داده پشتيبان براي مرکز اصلي، وابسته است. نياز به چنين سطحي از مقياس‌پذيري و افزايش مداوم حجم مرکز داده و همچنين نياز به محيط ذخيره‌سازي پایدار، شرکت‌هاي عظيم ارائه‌دهنده خدمات مبتني بر وب را وادار کرده است تا براي رفع نياز خود، نوع ديگري از رسانه‌هاي ذخيره‌سازي را انتخاب کنند: سيستم‌هاي مديريت فايل توزيع‌شده بر‌اساس رسانه‌ذخيره‌سازي از نوع object-based. اين سيستم‌ها، حداقل تا حدودي از ساير سيستم‌هاي فايلي توزيع شده و خوشه‌اي نظير Global File System شرکت ردهت و فناوري General Parallel Filesystem شرکت آی‌بی‌ام الهام گرفته‌اند. معماري سيستم‌فايلي در محيط شرکت‌هاي فراهم‌آورنده خدمات ابري، فرا داده یا متاديتا (داده در مورد محتويات داده)‌ را مستقل از خود داده ذخيره‌شده در نظر مي‌گيرد. اين کار امکان آن‌را فراهم مي‌آورد تا حجم عظيمي از نوشتن و خواندن روي کپي‌هاي متعدد داده فراهم شود و به اين ترتيب مفاهيم و مشکلاتي نظير قفل شدن فايل از ميان مي‌رود. تأثير سيستم‌هاي فايلي توزيع‌شده، فراتر از محدوده مراکز داده بسيار عظيمي است که از اين نوع سيستم‌فايلي استفاده مي‌کنند. اين سيستم‌هاي فايلي تأثير مستقيمي بر نحوه توسعه و پياده‌سازي برنامه‌هايي دارد که کاربران خدمات ابري همگاني نظير EC2 آمازون، App Engine گوگل يا Azure مايکروسافت در حال توليد آن هستند. همچنين دانشگاه‌ها و شرکت‌ها و نمايندگان دولت به دنبال راهي هستند تا بتواند به سرعت داده‌هاي مورد نياز خود را ذخيره کنند. فراهم کردن امکان دسترسي به حجم عظيمي از داده، باعث شده است تا نياز به نوع جديدي از سيستم‌هاي ذخيره‌سازي احساس شود که بتواند مقادير عظيمي از داده را ذخيره کند و اين نياز توسط محصولات غول‌هاي ارائه دهنده سيستم‌هاي مبتني بر محيط ابري، برآورده مي‌شود. بنابراين صرف وقت براي درک تاريخچه هر يک از اين فناوري‌ها و رويکردهاي فني و ضعف‌هاي هر يک، کاري عاقلانه به شمار مي‌رود.
گوگل، يکي از نخستين غول‌هاي اينترنتي بود که با مشکل مقياس‌پذيري رسانه ذخيره‌سازي و مسائل مرتبط با آن روبه‌رو شد و ايجاد يک سيستم‌فايلي توزيع شده، راه‌حلي بود که مهندسان گوگل در سال ۲۰۰۳ براي اين مشکل ارائه کردند. اين سيستم‌فایلی که Google File System يا GFS ناميده مي‌شود، به طور سفارشي و متناسب با راهبرد مورد استفاده در مراکز داده شرکت گوگل ايجاد شده و به کار گرفته شد. GFS زيرساختار اصلي براي تقريباً تمام سرويس‌هاي مبتني بر محيط ابري است که شرکت گوگل عرضه مي‌کند. اين سيستم‌فايلي نيازهاي متنوع مرتبط با ذخيره‌سازي داده را مرتفع مي‌کند که از جمله آن‌ها مي‌توان به پايگاه‌داده BigTable و همچنين داده‌هاي پلتفرم AppEngine اشاره کرد. سيستم‌فايلي GFS، همچنين داده مورد نياز براي موتور جستجوي گوگل و ساير برنامه‌هاي شرکت را فراهم مي‌کند. انتخاب‌هاي انجام شده در مرحله طراحي GFS، تأثير زيادي بر معماري و نرم‌افزار محيط ابري اين شرکت داشته که البته اين تأثير حالت دو سويه دارد. گوگل تمايل دارد تا داده‌هاي مورد نياز برنامه‌ها را در فايل‌هاي بسيار بزرگ ذخيره کند و از فايل‌ها به روش “producer-consumer queues”، استفاده مي‌کند.

در اين روش ممکن است صدها ماشين که در حال جمع‌آوري اطلاعات هستند، نتيجه کار خود را در يک فايل مشترک ذخيره کنند. در عين حال، ممکن است اين فايل توسط برنامه‌ ديگري مورد استفاده قرار گيرد که وظيفه ترکيب و تحليل داده را بر عهده دارد و حتي ممکن است اين فرآيند نيز به موازات فرآيند قبلي ذخيره داده در فايل، انجام شود.
گوگل، بيشتر جزئيات تکنيکي معماري GFS را به دلايل کاملاً مشخص محرمانه نگاه داشته‌است. اما در مقاله‌‌اي که در سال ۲۰۰۳ توسط سان‌جاي گماوات (Sanjay Ghemawat) عضو گروه تحقيقاتي شرکت گوگل، هوارد گوبيوف (Howard Gobioff) مهندس پايه و شان‌تک‌ليونگ (Shun-Tak Leung) عضو گروه مهندسان ارشد منتشر شد، اين‌ طور عنوان شده که سيستم‌فايلي GFS با در نظر گرفتن اولويت‌هاي بسيار خاصي طراحي شده است. اين مقاله عنوان مي‌کند که هدف از طراحي GFS، تبديل تعداد زيادي از سرورها و هاردديسک‌هاي ارزان‌قيمت، به مجموعه‌اي است که بتواند صدها ترابايت داده را ذخیره و مديريت کرده و در صورت بروز خطا يا نقص‌های سخت‌افزاري بتواند مشکل به وجود آمده را برطرف کند. اين سيستم‌فايلي به طور سفارشي و متناسب با روش جمع‌آوري و خواندن داده توسط گوگل،‌ طراحي شده است و مي‌تواند به چندين برنامه امکان دهد تا به طور همزمان حجم‌ بزرگي از داده‌ها را به سيستم بيافزايند و با بالاترين سرعت ممکن به داده‌ها دسترسي داشته‌باشند.

نحوه عملکرد GFS بسيار شبيه روش انجام فرآيند RAID5 در رسانه‌هاي ذخيره‌سازي است که در آن داده به صورت تکه‌تکه در سطح تمام ديسک‌ها ذخيره مي‌شود تا جلوي از دست رفتن داده، گرفته شود

نحوه عملکرد GFS بسيار شبيه روش انجام فرآيند RAID5 در رسانه‌هاي ذخيره‌سازي است که در آن داده به صورت تکه‌تکه در سطح تمام ديسک‌ها ذخيره مي‌شود تا جلوي از دست رفتن داده، گرفته شود. در GFS نيز فايل‌ها به صورت تکه‌هایي با اندازه ثابت در سطح خوشه‌اي از سرورها کپي شده و توزيع مي‌شود. از آنجا که در اين روش از کامپيوترها و هاردديسک‌هاي ارزان قيمت استفاده مي‌شود، ممکن است اين سرورها به طور ناخواسته با مشکل مواجه شوند. در نتيجه GFS،‌ طوري طراحي شده‌است که بتواند بدون از دست دادن حجم قابل توجهي از داده براي اين گونه خطاها، راهکار ارائه دهد. اما شباهت‌هاي مکانيزم RAID 5 و GFS به همين موارد ختم مي‌شود. در GFS مي‌توان سرورهاي مورد بحث را در سطح شبکه توزيع کرد. به اين ترتيب، سرورها مي‌توانند در يک يا چند مرکز داده توزيع شوند و تصميم‌گيري در اين مورد به کاربرد داده بستگي دارد. GFS براي آن طراحي شده تا بتواند حجم عظيمي از داده را به صورت گروهي، پردازش کند. آنچه که در اين فرآيند اهميت دارد، خواندن سريع داده است و فاکتورهايي نظير سرعت دسترسي به يک قسمت خاص از فايل يا سرعت نوشتن داده در سيستم‌فايلي اهميت چنداني ندارد. GFS براي سريع کار کردن، ‌داده‌ها را به صورت تکه‌‌تکه و از سطح چندين رسانه مي‌خواند يا مي‌نويسد. هزينه دستيابي به سرعت بالا در سيستم‌فايلي GFS، نوشتن و خواندن قطعه‌بندي شده روي چندين ديسک است. به گفته گماوات در مقاله ذکر شده «نوشتن قطعات کوچک داده در آدرس‌هاي متعدد و متفاوت توسط اين سيستم‌فايلي پشتيباني مي‌شود اما لزوماً کارايي بالايي ندارد.» ماهيت توزيع شده GFS و حجم بسيار زياد داده‌اي که توسط اين سيستم‌فايلي مديريت مي‌شود (ميليون‌ها فايل که حجم بيشتر آن‌ها بالاي صد مگابايت و معمولاً در محدوده گيگابايت است.) به معني هزينه‌ها و اثرات جانبي مشخصي است و اين اثرات جانبي باعث مي‌شود تا سيستم‌فايلي GFS براي نصب روي يک سرور مستقل و منفرد، گزينه نامناسبي به شمار آيد. از آنجا که صدها نفر ممکن است به طور همزمان در حال نوشتن يا خواندن از يک فايل باشند، لازم است که سيستم‌فايلي تا حد ممکن از فرآيند تکه‌تکه کردن و ايجاد قطعات کوچک داده پشتيباني کرده و بدون تأثير بر ساير برنامه‌ها از فرآيند بازگرداندن و معکوس کردن فرآيندهاي ناموفق نیز، پشتيباني کند. همچنين اين سيستم‌فايلي بايد جامعيت داده‌ها را تضمين کرده و سربار ناشي از فرآيند همزمان‌سازي را نيز به حداقل برساند تا از هر گونه کاهش کارايي ناشي از انجام اين‌گونه فرآيندها، جلوگيري شود. GFS از سه لايه تشکيل شده‌است: يک کلاينت GFS که وظيفه آن پاسخ‌گويي به درخواست داده از جانب برنامه‌ها است؛ يک مرجع که با استفاده از يک انديس مقيم در حافظه به رديابي فايل‌هاي داده و مکان قطعات هر فايل داده در حافظه مي‌پردازد. المان بعدي اين معماري خود سرورهاي ارائه خدمات است که “chunk servers” نام دارند.

GFS از سه لايه تشکيل شده‌است: يک کلاينت GFS که وظيفه آن پاسخ‌گويي به درخواست داده از جانب برنامه‌ها است؛ يک مرجع که با استفاده از يک انديس مقيم در حافظه به رديابي فايل‌هاي داده و مکان قطعات هر فايل داده در حافظه مي‌پردازد. المان بعدي اين معماري خود سرورهاي ارائه خدمات است که “chunk servers” نام دارند.

در ابتدا به منظور حفظ سادگي اين روش، GFS از يک مرجع به ازاي هر کلاستر يا خوشه استفاده مي‌کرد. به اين ترتيب وظيفه سيستم اين بود که تا حد ممکن بار کاري پردازش مرجع را در جهت تعيين روش دسترسي به داده، به حداقل برساند. اما اکنون گوگل يک سيستم مرجع توزيع شده فراهم کرده است که مي‌تواند مديريت صدها مرجع را انجام دهد و هر يک از اين مرجع‌ها نيز مي‌تواند حدود صد ميليون فايل را مديريت کند. زماني که کلاينت فايل سيستم GFS، درخواستي را به منظور دسترسي به يک فايل داده خاص دريافت مي‌کند، درخواستي را براي سرور مرجع ارسال مي‌کند تا آدرس فايل را به دست آورد. سرور مرجع آدرس يکي از کپي‌هاي داده مورد نظر را اعلام مي‌کند و کلاينت نيز به طور مستقيم با آن chunk server تعامل مي‌کند و به اين ترتيب فرآيند نوشتن و خواندن داده انجام مي‌شود. سرور مرجع ديگر در اين فرآيند نقشي نخواهد داشت، مگر آن‌که بخشي از اين فرآيند و عملکردها، با خطا مواجه شود. سيستم‌فايلي GFS براي تضمين بالاترين ميزان دسترسي به اين مجموعه داده، بعضي از هزينه‌ها را پذیرفته و برخی قابلیت‌ها را قربانی می‌کند، نظير اصل ثبات و تشابه داده به ازاي کليه کپي‌هاي داده. همچنين GFS اصل تکه‌تکه‌کردن داده را تا حد ممکن اعمال مي‌کند. اگر يکي از فرآيندهاي نوشتن داده با خطا مواجه شود، در اين صورت فرآيند بازگرداندن متاديتا به وضعيت قبلي انجام مي‌شود و يک کپي از داده قبلي را دوباره در اختيار درخواست مورد نظر قرار مي‌دهد. اما از طرفي عدم مشارکت سرور مرجع در فرآيندهاي نوشتن به آن معنا است که به موازات نوشته شدن داده در سيستم اين تغييرات به طور آني در ساير کپي‌هاي آن داده که در سطح هر خوشه وجود دارند، منعکس نمي‌شود. اين سيستم از فرآيندي بهره ‌می‌برد که گوگل آن را “relaxed consistency model” مي‌نامد. اين مدل به واسطه نيازهايي که در صورت دسترسي همزمان به داده‌ها مطرح مي‌شد و همچنين به دليل محدوديت‌هايي که شبکه ايجاد مي‌کرد، طراحي شده است. استفاده از اين فرآيند،‌ به معناي آن است که سيستم GFS هيچ مشکلي با ارائه اطلاعات کهنه و قديمي ندارد. به عبارت ديگر اگر در آن لحظه خاص داده جديد هنوز در سطح سيستم توزيع نشده باشد و کپي‌هاي در دسترس، نسخه‌هاي قديمي باشد، GFS همان داده هاي قديمي را به درخواست کننده تحويل خواهد داد. البته پردازه مرجع تا حد امکان سعي خواهد کرد داده‌ها را به روز نگه دارد و براي اين کار به رديابي تغييرات مي‌پردازد و براي اين منظور به ازاي هر کپي، شماره نگارش قطعات داده را با هم مقايسه مي‌کند. به محض این‌که بعضي از کپي‌هاي داده از فرآيند به روزرساني عقب ‌مانده و به اصطلاح بيات می‌شوند، پردازه مرجع GFS اين اطمينان را ايجاد مي‌کند که آدرس اين قطعات در اختيار کلاينت‌ها قرار نمي‌گيرد و اين محدوديت تا زماني اعمال مي‌شود که داده آن chunk به‌روزرساني شود. اما اين مسئله لزوماً درباره پردازه‌هايي که از قبل آدرس آن chunk را در اختيار گرفته‌اند، انجام نمي‌شود. متا‌ديتاي مربوط به تغييرات تا زماني که پردازه مرجع، تغييرات را بررسي نکرده و آن‌ها را در متا‌ديتا منعکس نکرده‌باشد، اعمال نمي‌شود. همچنين لازم است تا خود متادیتا نيز در چندين مکان مختلف کپي شود تا در صورت بروز خطا در کپي اصلي، جايگزيني براي آن، موجود باشد. اگر اين فرآيند انجام نشود، با از دست رفتن داده‌های مرجع، کل اطلاعات مورد نياز جهت استفاده از اين سيستم‌فايلي، از دست مي‌رود. همچنين اگر در طول فرآيند نوشتن، پردازه مرجع با خطا مواجه شود، در اين صورت نيز تغييرات به طور کامل از دست مي‌رود. البته با توجه به نحوه تعامل گوگل با داده‌ها، اين مسئله، مشکل بزرگي به شمار نمي‌رود زيرا اکثريت نسبي داده‌هاي مورد استفاده توسط برنامه‌هاي اين شرکت، به ندرت تغيير مي‌کنند و تغييرات هم به جاي به‌روزرساني اطلاعات موجود، در قالب افزوده شدن داده به سيستم، انجام مي‌شود. سيستم‌فايلي GFS براي پاسخ‌گويي به برنامه‌هايي تهيه شد که گوگل در سال ۲۰۰۳ به کاربران خود معرفي کرده بود، يعني زماني که گوگل هنوز با مشکلات مرتبط با مقياس‌پذيري سيستم‌ها مواجه نشده‌بود. حتي قبل از تملک یوتیوب نيز استفاده از سيستم‌فايلي GFS با مشکلاتي مواجه شد. اين مسئله بيشتر از آن جهت بروز کرده‌بود که برنامه‌هاي جديد گوگل در تعامل با اندازه فايل ايده‌آل ۶۴ مگابايتي شرکت، عملکرد درستي نداشتند. براي برطرف کردن اين مشکل، گوگل براي ذخيره‌سازي داده به سراغ روش مبتني بر Bigtable رفت که روي زيرساخت و سيستم‌فايلي GFS قرار مي‌گيرد. اين روش به شکل بسيار مبهمي ساختار پايگاه‌داده را در ذهن تداعي مي‌کند. ماهيت Bigtable نيز همانند سيستم‌فايلي GFS «فقط يک‌بار نوشتن» است. در نتيجه کليه تغييرات در قالب افزوده شدن داده به جدول‌ها، بروز مي‌کند. به عنوان مثال، گوگل از اين راهکار در برنامه‌هايي نظير Google Docs استفاده مي‌کند تا مسئله کنترل نگارش داده را مديريت کند.

اگر در گوگل کار نمي‌کنيد، ‌بقيه داستان براي شما حالتي آکادميک و رسمي خواهد داشت. هر چند مي‌تواند به کاربران App Engine،‌سيستم ‌ذخيره‌سازي ابري و حتي ساير خدمات گوگل کمک کند تا درک بهتري از زيرساخت مورد استفاده‌شان داشته باشند. در حالي‌که محيط Google Cloud Storage، راهکاري را فراهم مي‌کند تا عموم کاربران بتوانند آنچه را مي‌خواهند از طريق يک رابط تحت وب، در سطح سيستم‌فايلي GFS، ذخيره کنند و به آن دسترسي داشته باشند اما اطلاعات دقيق در مورد رابط‌ها و ابزارهاي اصلي براي دسترسي به سيستم‌فايلي GFS، منتشر نشده‌است. البته مستنداتي که سيستم‌فايلي GFS را تشريح مي‌کنند منجر به ارائه يک سيستم‌فايلي توزيع‌شده ديگر بسيار شبيه GFS شد که کاربردهاي بسیار گسترده‌تري يافته است. اين سيستم فايلی با نام هدوپ Distributed File System معرفي شده‌است.

1 2 3 4برگهٔ بعدی

مجتبی بنائی

دانشجوی دکترای نرم‌افزار دانشگاه تهران (yun.ir/smbanaie)، مدرس دانشگاه و فعال در حوزه توسعه نرم‌افزار و مهندسی داده که تمرکز کاری خود را در چند سال اخیر بر روی مطالعه و تحقیق در حوزه کلان‌داده و زیرساخت‌های پردازش داده و تولید محتوای تخصصی و کاربردی به زبان فارسی و انتشار آنها در سایت مهندسی داده گذاشته است. مدیریت پروژه‌های نرم‌افزاری و طراحی سامانه‌های مقیاس‌پذیر اطلاعاتی از دیگر فعالیتهای صورت گرفته ایشان در چند سال گذشته است.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

جای خالی در معادله زیر را با کی برد انگلیسی وارد کنید : * Time limit is exhausted. Please reload CAPTCHA.

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

دکمه بازگشت به بالا