آیا هدوپ در حال انقراض است؟
مدتی پیش مقالهای از آقای مارک لیتوینشیک که اغلب درباره مباحث کلانداده و بانکهای اطلاعاتی به صورت عملی مطالبی را در وبلاگ شخصیاش منتشر میکند، دیدم با عنوان آیا هدوپ مرده است؟ . از سری مقالات آقای لیتوینشیک در پردازش ۱.۱ میلیارد داده تاکسیهای نیویورک با تکنولوژیها و بانکهای اطلاعاتی مختلف و مقایسه آنها، بسیار استفاده کردهام و ایشان را آدمی مسلط به اکوسیستم کلانداده میدانم بنابراین تصمیم گرفتم خلاصهای از این مقاله مفید را از دید یک آدم حرفهای و به روز در این حوزه در اختیار علاقهمندان به مباحث کلانداده قرار دهم. قبل از ورود به این مقاله، توصیه میکنم مقایسهای که توسط آقای لیتوینشیک در خصوص سرعت اجرای چهار کوئری مختلف روی یک میلیارد داده سفرهای تاکسیهای نیویورک با نرمافزارها و دیتابیسهای مختلف انجام شده است را حتماً و با دقت مشاهده کنید.
با بررسی مقایسه فوق درمییابید هنگامی که حجم دادهها بسیار زیاد میشود دیتابیسهایی مانند پستگرس و الاستیکسرچ هم سرعت اجرای مناسبی ندارند، اسپارک و پرستو (Presto) در مقابل کلیکهوس (ClickHouse) که محصولی متنباز و رایگان است، ضعیفتر عمل میکنند، قالب ذخیره دادهها (ORC/Parquet/Flat File) تاثیر شگرفی بر بهبود پاسخ ابزارهایی مانند پرستو و اسپارک دارند و نهایتاً دیتابیسهای مبتنی بر GPU در پرسوجوهای تحلیلی از همه ابزار بررسی شده، موفقتر ظاهر شدهاند.
دیباچه
چندی پیش خبری منتشر شد مبنی بر ادغام دو شرکت بزرگ Hortonworks و Cloudera و اخیراً هم دو شرکت Cloudera و MapR که توزیع کنندگان اصلی هدوپ (نسخههای سفارشی و سازمانی) در بازار هستند، از شرایط سخت مالی خود گلایهمند بودهاند و پشتبند بیان این مطلب از این دو شرکت، مجموعه مقالاتی در دنیا منتشر شد با عنوان آیا هدوپ مرده است ؟ که کافی است این عنوان را در گوگل جستجو کنید تا مقالات فزاینده اخیر در این زمینه مشاهده کنید.
رصد بازار کلانداده در چند سال اخیر هم اینگونه به ما القا میکند که هدوپ و فناوریهای مرتبط از از بازار و صنعت عقب مانده است. رشد استفاده از سامانههای مبتنی بر رایانش ابری شرکتهای معتبر در حوزه کلانداده مانند خدمات آنلاین آمازون، مایکروسافت و گوگل در کنار ابداع قالبهای جدید ذخیره دادهها به صورت ستونی که نیاز به فرآيندهایی مانند توزیع و تجمیع ( Map/Reduce
) را به حداقل رسانده است، گویی عرصه را بر این سلطان قدیمی تنگ کرده است و نفسهای او را به شماره انداخته است.
توضیحی راجع به هدوپ
منظور ما از هدوپ، اکوسیستمی از کتابخانههایی است که امروزه حول هسته اصلی هدوپ شکل گرفتهاند و اکثر آنها امروزه جزء بنیاد آپاچی هستند (هر چند پروژههایی مانند Presto
، Hue
و ClickHouse
خارج از این بنیاد قرار دارند). این اکوسیستم که امروزه از میلیونها خط کد و هزاران توسعهدهنده داوطلب تشکیل شده است، روزانه صدها کامیت و به روزرسانی دارد که نشاندهنده جامعه کاربری بسیار فعال آن در دنیاست.
اما حقیقت ماجرا، چیز دیگری است و آقای لیتوینشیک به عنوان یکی از فعالان فنی حوزه بیگدیتا، در مقاله فوق به توضیح این مطلب پرداخته که چه عواملی باعث شده است که فکر کنیم هدوپ در حال انقراض است. ادامه این نوشتار، خلاصهای از مطالب ایشان است.
رقابت با ابزار رایگان
مهمترین مسالهای که باعث شروع جریان آیا هدوپ مرده است ؟ شد،اعلام وضعیت سخت مالی توسط دو شرکت بزرگ توزیع کننده هدوپ یعنی MapR
و Cloudera
بود اما نکته اینجاست که این دو شرکت در حقیقت با ابزار رایگانی در حال رقابت بودند که به سادگی از اینترنت قابل دانلود و استفاده است. خود این موضوع، کار بازاریابی و توسعه خدمات را برای این شرکتها سخت میکند.
از طرفی خیلی از توسعهدهندگان پروژه هدوپ یعنی برنامهنویسان داوطلب آن، از این دو شرکت هستند و شرایط سخت مالی این دو شرکت هم باعث میشود که خیلی از پروژهها و توسعههای کلید خورده در این شرکتها، با وقفه مواجه شود و به تبع آن، مشارکت و تولید نسخههای جدید هدوپ کمی کند شود.
این که دماسنج سلامت هدوپ را شرایط مالی این دو شرکت بدانیم و هدوپ را به دُم آنها گره بزنیم، کار عاقلانهای نیست. امروزه شرکتهایی که حول و حوش پروژههایی مانند اسپارک و پِرِستو، شکل گرفتهاند سعی کردهاند خطای این شرکتها را تکرار نکنند و محصولات و خدماتی را ارائه کنند که به رایگان قابل دستیابی نیست.
رواج بسترهای آنلاین پردازش داده
آقای لیتوینشیک خاطرهای نقل میکند که چند سال پیش (در سال ۲۰۱۲) درگیر پروژه بزرگی برای راهاندازی یک کلاستر بزرگ از هدوپ وکتابخانههای وابسته بوده است که ۲۶ نفر در آن مشغول کار بودند که برای به سرانجام رسیدن آن، بودجه زیادی صرف نیروی انسانی و تلاش برای هماهنگ کردن کل سیستم با هم بود. با ورود Amazon EMR
که نصب و راهاندازی هدوپ و مدیریت کلاستر را تنها با چند کلیک ممکن میکٰرد، امروزه تمام این کارها را میتوان با یک نفر نیروی متخصص و با صرف هزینهای بسیار اندک و آنهم با امکانات مدیریتی فوق العاده راحت، انجام داد.
این موضوع هم، کاهش شدید درآمد شرکتهای توزیعکننده هدوپ را به دنبال داشته است که نشانهای از افول هدوپ محسوب نمیشود و فقط بیانگر یک تغییر پارادایم از سرویسهای خانگی به سرویسهای ابری است که امروزه حرف اول را در دنیای پردازش داده میزند.
تغییر نیازهای پردازشی
یکی از مهمترین کارکردهای هدوپ در سالیان اولیه رشد و گسترش آن، پردازش حجم عظیم دادههای موجود در فایلهای متنی (مشابه با CSV
) و استخراج اطلاعاتی مانند دادههای آماری (میانگین، ماکزیمم، مینیمم و ….) و یا یافتن رکوردهایی با شرایط خاص (مثلا فلان خطا) بود. با معرفی قالب ذخیره اطلاعات پارکت (Parquet) و ORC و مانند آن که دادهها را به صورت ستونی، ذخیره میکنند، استخراج بسیاری از این اطلاعات، به راحتی و بدون استفاده از هدوپ، ممکن گشته است. امری که کاربردهای کلاسیک هدوپ را تا حدود زیادی تحت تاثیر قرار داده است.
از طرفی، با معرفی چارچوبهای نوین پردازش داده مانند اسپارک و فلینک که علاوه بر دو عملیات اصلی پردازش داده در هدوپ یعنی توزیع و تجمیع ( Map/Reduce
)، عملیات متنوعتری را به کاربران ارائه کردهاند ( Filter/Union/SQL On Hadoop/...
)، حجم زیادی از نیاز بازار را به سمت خود جذب نمودهاند. هر چند این چارچوبهای پردازشی هم میتوانند بر بستر هدوپ اجرا شوند اما فاصله خود را از هدوپ حفظ کردهاند و حتی گاهی تاکید دارند که مستقلاً و بدون نیاز به هدوپ هم قابل اجرا هستند.
این موضوع هم باعث کاهش تقاضا در استفاده مستقیم از هدوپ و جایگزینی چارچوبهایی مانند اسپارک با بخش پردازشی هدوپ شده است اما به خاطر داشته باشید که هدوپ یک نرم افزار نیست و اکوسیستم هدوپ، امروزه شامل کتابخانه و پروژههای بزرگی شده است که در تمامی چارچوبهای پردازشی نوین هم از آنها مسقیم یا غیر مستقیم استفاده میشود و کنارگذاشتن بخش پردازشی آن (عملیات Map/Reduce
) نمیتواند نشانگر ضعف و کاهش محبوبیت هدوپ باشد.
فراز و فرودها
همانطور که در بالا اشاره شد، اکوسیستم هدوپ در طی بیش از ده سال گذشته، شاهد ورود نرمافزارهای مختلف بوده است که برخی از آنها به دلایل گوناگون از جمله جایگزینی با محصولی جدیدتر و کاملتر، کنار گذاشته شدهاند بنابراین اگر به صورت مستقل به این افول محبوبیت نرمافزار نگاه کنیم، ممکن است نتیجه بگیریم که هدوپ در حال منزوی شدن است اما اگر بدانیم که این نرمافزارها و کتابخانهها با جایگزینهای بهتری مواجه شدهاند، این سوءتفاهم هم برطرف خواهد شد.
مثلاً در گذشته برای اجرای خودکار کارها از Oozie
استفاده میشد که امروزه با Airflow
که حدود هزار نفر برنامهنویس از سرتاسر دنیا در آن مشارکت دارند، جایگزین شده است. در ابتدای معرفی هدوپ، برای پردازشهای ساده و معمول دادهها از Pig
که یک زبان اسکریپتی قابل ترجمه به فرآیند توزیع و تجمیع ( Map/Reduce
) بود استفاده زیادی میشد که امروزه با معرفی و رواج انواع ابزارهای SQL On Hadoop
مانند ایمپالا و دریل ( Impala
/ Drill
)، به تاریخ پیوسته است.
کاهش جستجوهای هدوپ
موضوع دیگری که ممکن است نشانهای از احتضار هدوپ باشد، بررسی ترند و میزان محبوبیت هدوپ بر اساس میزان جستجوهای انجام شده در سالیان اخیر باشد.
در مورد نمودار فوق، دو نکته باید مد نظر قرار گیرد. اول اینکه در سالیانی نه چندان دور، شرکتهای توزیع کننده نسخههای تجاری هدوپ سرمایه گذاری عظیمی روی محصولات و تبلیغات و جذب نیرو انجام داده بودند که این امر، امروزه به حداقل رسیده است.
نکته دوم و مهمتر این که همانطور که اشاره شد، هدوپ از دهها پروژه تشکیل شده است و معمولاً افراد به جای جستجوی مستقیم کلمه هدوپ، کتابخانه مورد نیاز خود را جستجو میکنند بنابراین اگر بخواهیم منصفانه به این نمودار نگاه کنیم باید سهم هر یک از این کتابخانهها و ابزار را به سهم هدوپ اضافه کنیم تا مشاهده کنیم که چه رشد عظیمی در حوزه هدوپ و بیگدیتا در چند سال اخیر رخ داده است.
باورهای رایج اما اشتباه
در کنار مسایل فوق، باورهایی هم در بین برخی توسعهگران و کادر فنی شرکتها وجود دارد که این باورها هم به تصور اینکه به هدوپ و کتابخانههای حوزه کلانداده نیاز نداریم، دامن میزند. با هم برخی از این تصورات رایج اما اشتباه را بررسی میکنیم :
- باور اول : تو دنیای امروز، کسی به بیگدیتا و ابزارهای آن، نیاز ندارد : حجم داده بسیاری از شرکتها و استارتاپها اصلاً برایشان مساله ساز نشده است و با راهکارهای معمول و سنتی مدیریت داده مانند استفاده از بانکهای اطلاعاتی و نهایتاً تقسیم (
Sharding
) یا تکرار داده (Replication
) نیازشان برطرف شده است. بالتبع، این گونه شرکتها کاملاً حق دارند بگویند که کار آنها بدون ابزارهای خاص کلانداده، به خوبی جواب میدهد و به اشتباه تصور کنند که اصلاً کلانداده و مسایل مترتب بر آن، وجود خارجی ندارد چون اصلاً حجم و تنوع و سرعت تولید و پردازش داده آنها در حد کلانداده نبوده است. بنابراین اگر کسی این جمله و باور را تکرار کرد بررسی کنید ببنید کجا و با چه حجم دادهای سر و کار دارد. از طرف دیگر، بسیاری از تیمهای حرفهای و شرکتهای بزرگی که درگیر مسایل کلانداده هستند، کمتر راجع به آن به صورت عمومی صحبت میکنند و این امر خود به این تصور دامن میزند که اصلاً با رشد فناوریهای پایگاهداده، مسالهای به نام کلانداده امروزه مطرح نیست. به قول سعدی علیه الرحمه، اين مدعيان در طلبش بی خبرانند / کانرا که خبر شد خبری باز نيامد. - باور دوم : مهندسی بیش از حد برای هر کار پردازش داده : گاهی اوقات هم افراد از سمت دیگر اسب می افتند یعنی راهکاری که به راحتی با پردازشهای سنتی و پایگاههای داده رایج قابل انجام است را با ابزار و کتابخانههای کلانداده بازنویسی میکنند و ناخواسته درگیر مشکلات و اعصاب خردکنیهای آن میشوند و گرهی را که با دست به راحتی باز میشود با دندان باز میکنند. این گونه افراد هم بعد از مدتی و با برگشتن به دنیای سنتی پردازش داده، جزء طرفداران این نظریه میشوند که اصلاً کلانداده و اکوسیستم آن، زیادی بزرگ شده است و چندان کارآیی ندارد.
- باور سوم : پستگرس برای همه نیازهای امروز کافی است : خود بنده (نویسنده این مقاله فارسی) جزء طرفداران پروپاقرص پستگرس هستم و بی سبب هم نیست که این دیتابیس در دو سال گذشته به عنوان دیتابیس برتر دنیا از دید سایت DB-Engines معرفی شده است چون علاوه بر قدرتمندی انجین اصلی آن، ابزارها و دیتابیسهای که امروزه در کنار آن و به عنوان مکمل پستگرس شکل گرفتهاند یک مجموعه یکدست و کامل را در اختیار یک تیم توسعه قرار میدهند از افزونه پردازش دادههای جغرافیایی (
PostGIS
) تا ذخیره دادههای سری زمانی (TimeScaleDB
) و دادههای گراف (AgensGraph
) و حتی ذخیره دادههای ستونی برای مقاصد تحلیلی، همه و همه امروزه در کنار پستگرس در دسترس هستند. حتی با معرفی قابلیت جدید جداول خارجی (FDW) میتوان کاساندرا و مانند آنرا هم به پستگرس متصل کرد. با این وجود، زمانی که حجم دادهها زیاد شود و سرعت تولید یا تنوع قالبهای داده بیش از حد انتظار باشد، پستگرس هم جوابگوی کار ما نیست. کافی است به ابتدای مقاله و مقایسهای که آقای لیتوینشیک بین راهکارها و دیتابیسهای مختلف در پردازش یک میلیارد داده تاکسی انجام داده است نظری دقیقتر بیندازید تا ببینید که این تصور که پستگرس برای همه چیز خوب است، تا چه اندازه بی اساس است.
سخن آخر
در اینکه با ورود بسترهای ابری و افزایش امکانات دیتابیسهای رایج، ارج و قرب هدوپ تحت شعاع قرار گرفته است هیچ شکی نیست اما این امر نه به این معناست که هدوپ به پایان عمر خود نزدیک شده است فقط امروزه شاهد یک پارادایم شیفت هستیم از ابزارهای کلاسیک کلانداده از جمله خود هدوپ به سمت ابزارهای راحتتر و با امکانات بیشتر و بخصوص مناسب برای پردازش جریانهای داده.
امروزه تنوع کتابخانههای موجود در اکوسیستم هدوپ از هر زمان دیگری بیشتر شده است و این امر خود نشانهای از بالنده بودن و رشد این اکوسیستم است.
سلام و عرض ادب
بنده در حال تعریف یک پروژه هستم که در سال در کمترین حالت ۱۰,۰۰۰,۰۰۰ رکورد رو ذخیره می کنه، چیزی در حدود ۳۰۰۰۰ رکورد در روز که ممکنه با توجه به تغییر سیاست ها در آینده شاید نیاز به ذخیره ۱۰۰,۰۰۰,۰۰۰ رکورد در سال هم احساس بشه و یا شاید بیشتر
بنده بیشتر پایگاه داده های nosql، newsql و… با معماری های گراف، اسنادی، ستونی و … رو از نظر عملکرد و ویژگی ها در سایت های خارجی و ایرانی بررسی کردم
در مقالات فارسی و انگلیسی به این نکته برخورد کردم فیسبوک که خودش cassandra رو پایه گذاری کرده الان متوجه شده که باید سمت پایگاه داده ای بره که هم رابطه ای باشه و هم غیر رابطه ای و یک نسخه آزمایشی از یک پایگاه داده جدید ارائه کرده که دقیقا دستوراتش مانند cassandra هست و شاید مانند postgre عمل کنه، یعنی هم nosql و هم sql
از طرفی postgresql دیتابیس قوی هست و از nosql پشتیبانی می کنه ولی در مقایسه با بعضی پایگاه های داده هم رده خودش مانند timescale قدرت کم تری داره و در مقابل کاساندرا تقریبا حرفی برای گفتن نداره و نمی دونم برای این حجم از داده و اینکه سالیانه قرار هست رکورد های بیشتری اضافه بشه چه عملکردی خواهد داشت
پایگاه داده های nosql مانند mongodb و بعضی های دیگه دارای ضعف های اساسی هستن و دلیل محبوبیتشون بیشتر مستندات زیاد و پشتیبانی بهتر و استفاده بیشتر در فریم وورک های معروف مانند nodejs و … هست
چیزی که حائز اهمیت هست سرعت خواندن داده و جستجوی تگ برای بنده بیشتر مد نظر هست و اینکه در مقالات زیادی درباره آینده پایگاه داده مطالعه کردم که نشون می داد اقبال پایگاه داده های ترکیبی sql با nosql (مانند postgre) بیشتر هست چون این نیاز احساس شده که یک پایگاه داده باید هم مفاهیم رابطه ای و هم غیر رابطه ای رو پشتیبانی کنه ( و همونطور که عرض کردم فیسبوک هم پایگاه داده جدید نسخه آزمایشی رو ارائه کرده)
با این تفاسیر برای بنده بسیار سخت شده که چه نوع انتخابی داشته باشم، با توجه به اینکه ممکنه پروژه از جهات مختلف توسعه داده بشه
با توجه به تجربه ای که شما به عنوان کارشناس حوزه علوم داده دارین چه پیشنهادی در مورد انتخاب پایگاه داده مناسب به بنده می کنین و چه انتخابی بر چه اساسی می تونم داشته باشم که در آینده به مشکل برنخورم
از شما سپاسگزارم
سلام . در مورد تعداد دادهها و رکوردهایی که مطرح کردهاید با هیچ یک از دیتابیسهای رابطهای موجود مشکل خاصی نخواهید داشت چون اصلا در سطح بیگدیتا و داده های کلان محسوب نمی شوند مگر اینکه نیازمندی خاصی داشته باشید مثلا تعداد درخواستهای بسیار زیاد در یک لحظه یا نیاز به سرعت بالا هنگام خواندن اطلاعات . برای پاسخگویی مناسب باید نیازمندی اطلاعاتی شما را بدانم اما به صورت کلی، اگر بحث مقیاس پذیری خیلی برایتان مهم است و ساختار کاملا رابطهای دارید، میتوانید از cockroachdb که با الهام از Google Spanner ساخته شده و در زمره NewSQL ها قرار میگیرد استفاده کنید اما اگر نیاز مقیاس پذیری شما خیلی حیاتی نیست (برای این حجم داده خیلی نگران نباشید) و داده هایتان سازمانی رابطهای دارند از پستگرس به عنوان دیتابیس اصلی و در کنار آن از TimeScaleDBبرای ذخیره دادههای زمانمند و حتی سطرگسترده استفاده کنید.
سپاسگزارم
بله مقیاس پذیری بسیار مهم هست، ممکنه در یک زمان تعداد زیادی درخواست به سمت سرور هدایت بشه
ممکنه در آینده روزانه تا ۴۰۰ هزار کاربر به سرور درخواست ارسال کنند و هر کاربر چند درخواست request رو داشته باشه و ممکنه ساعت هایی از روز تعداد درخواست ها بیشتر از ساعت های دیگه باشه
در حال حاضر اطلاعات خیلی رابطه ای نیست به جز تگ tag که برای جست و جو استفاده می شه که یا باید روی اون ایندکس صورت بگیره و یا از پایگاه داده رابطه ای استفاده بشه، یعنی تگ ها در جدول دیگری ذخیره شود و از طریق شناسه با محتوا ارتباط پیدا کنه
البته نمی دونم کدوم عملکرد بهتری خواهند داشت
کار به همینجا ختم نمیشه و توسعه سیستم برای آینده غیر قابل پیشبینی هست به همین دلیل ترجیح بنده استفاده از پایگاه داده های ترکیبی بوده مانند yugabyte ولی همونطور که مستحضر هستین منابع اطلاعاتی و پشتیبانی کم تر و تعداد توسعه دهندگان کم این نوع از پایگاه داده ها تردید ایجاد می کنه که برای توسعه مشکل ایجاد نشه
از راهنماییتون بابت انتخاب پایگاه داده سپاسگزارم