Пазарът за разпределени изчисления и големи данни, според , нараства с 18-19% годишно. Това означава, че въпросът за избора на софтуер за тези цели остава актуален. В тази публикация ще започнем с това защо имаме нужда от разпределено изчисление, ще се спрем по-подробно на избора на софтуер, ще говорим за използването на Hadoop с Cloudera и накрая ще говорим за избора на хардуер и как той влияе върху производителността по различни начини.
Защо се нуждаем от разпределени изчисления в обикновения бизнес? Всичко е просто и сложно едновременно. Просто – защото в повечето случаи извършваме относително прости изчисления за единица информация. Трудно – защото има много такава информация. Толкова много. В резултат на това човек трябва . По този начин случаите на използване са доста универсални: изчисленията могат да се прилагат навсякъде, където се изисква да се вземат предвид голям брой показатели върху още по-голям масив от данни.
Един скорошен пример: Dodo Pizza въз основа на анализ на клиентската база от поръчки, когато избират пица с произволни гарнитури, потребителите обикновено работят само с шест основни комплекта съставки плюс няколко произволни. Съответно пицарията коригира покупките. Освен това успя да препоръча по-добре на потребителите допълнителни продукти, предлагани на етапа на поръчката, което увеличи печалбите.
Още един пример: стоките позволиха на H&M да намали асортимента в отделните магазини с 40%, като същевременно запази нивото на продажбите. Това беше постигнато чрез изключване на слабо продаваеми позиции, а при изчисленията беше взета предвид сезонността.
Избор на инструмент
Индустриалният стандарт за този вид компютри е Hadoop. Защо? Тъй като Hadoop е отлична, добре документирана рамка (същият Habr дава много подробни статии по тази тема), която е придружена от цял набор от помощни програми и библиотеки. Можете да подадете огромни набори както от структурирани, така и от неструктурирани данни като вход и самата система ще ги разпредели между изчислителната мощност. Нещо повече, същите тези капацитети могат да бъдат увеличени или деактивирани по всяко време - същата хоризонтална мащабируемост в действие.
През 2017 г. влиятелната консултантска компания Gartner че Hadoop скоро ще стане остарял. Причината е доста банална: анализаторите смятат, че компаниите масово ще мигрират към облака, тъй като там ще могат да плащат въз основа на използването на изчислителна мощност. Вторият важен фактор, за който се предполага, че може да "погребе" Hadoop, е скоростта на работа. Тъй като опции като Apache Spark или Google Cloud DataFlow са по-бързи от MapReduce в основата на Hadoop.
Hadoop се основава на няколко стълба, най-забележителните от които са технологиите MapReduce (система за разпространение на данни за изчисления между сървъри) и файловата система HDFS. Последният е специално проектиран да съхранява информация, разпределена между възлите на клъстера: всеки блок с фиксиран размер може да бъде поставен на няколко възела и благодарение на репликацията системата е устойчива на повреди на отделни възли. Вместо файлова таблица се използва специален сървър, наречен NameNode.
Илюстрацията по-долу показва как работи MapReduce. На първия етап данните се разделят по определен признак, на втория етап се разпределят по изчислителна мощност, на третия етап се извършва изчислението.
MapReduce първоначално е създаден от Google за нуждите на неговото търсене. След това MapReduce премина към безплатен код и Apache пое проекта. Е, Google постепенно мигрира към други решения. Интересен нюанс: в момента Google има проект, наречен Google Cloud Dataflow, позициониран като следваща стъпка след Hadoop, като негова бърза замяна.
По-внимателен поглед показва, че Google Cloud Dataflow е базиран на вариация на Apache Beam, докато Apache Beam включва добре документираната рамка Apache Spark, която ни позволява да говорим за почти същата скорост на изпълнение на решението. Е, Apache Spark работи добре на файловата система HDFS, което ви позволява да го разположите на Hadoop сървъри.
Добавете тук обема на документацията и готовите решения за Hadoop и Spark срещу Google Cloud Dataflow и изборът на инструмент става очевиден. Освен това инженерите могат сами да решат кой код - под Hadoop или Spark - ще изпълнят, като се фокусират върху задачата, опита и квалификацията.
Облак или локален сървър
Тенденцията към всеобщия преход към облака дори доведе до такъв интересен термин като Hadoop-as-a-service. При такъв сценарий администрирането на свързаните сървъри стана много важно. Защото, уви, въпреки популярността си, чистият Hadoop е доста труден инструмент за конфигуриране, тъй като трябва да правите много на ръка. Например, можете да конфигурирате сървърите поотделно, да наблюдавате тяхната производителност и да настройвате фино много параметри. Общо взето работете любителски и има голям шанс да се прецакате някъде или да пропуснете нещо.
Поради това различни дистрибуции станаха много популярни, които първоначално са оборудвани с удобни инструменти за внедряване и администриране. Една от по-популярните дистрибуции, която поддържа Spark и прави нещата лесни, е Cloudera. Има както платени, така и безплатни версии - като във втората е налична цялата основна функционалност и без ограничаване на броя на възлите.
По време на настройката Cloudera Manager ще се свърже чрез SSH към вашите сървъри. Интересен момент: при инсталирането е по-добре да се уточни то да се извършва от т.нар колети: специални пакети, всеки от които съдържа всички необходими компоненти, конфигурирани да работят един с друг. Всъщност това е толкова подобрена версия на пакетния мениджър.
След инсталирането получаваме конзола за управление на клъстери, където можете да видите телеметрия за клъстери, инсталирани услуги, плюс можете да добавяте / премахвате ресурси и да редактирате конфигурацията на клъстера.
В резултат на това пред вас се появява разрезът на онази ракета, която ще ви отведе в светлото бъдеще на BigData. Но преди да кажем „да вървим“, нека бързо напред под капака.
хардуерни изисквания
На своя уебсайт Cloudera споменава различни възможни конфигурации. Общите принципи, по които са изградени, са показани на илюстрацията:
MapReduce може да замъгли тази оптимистична картина. Поглеждайки отново диаграмата в предишния раздел, става ясно, че в почти всички случаи задание на MapReduce може да удари тясно място при четене на данни от диск или мрежа. Това също е отбелязано в блога на Cloudera. В резултат на това за всякакви бързи изчисления, включително чрез Spark, който често се използва за изчисления в реално време, I/O скоростта е много важна. Ето защо, когато използвате Hadoop, е много важно балансираните и бързи машини да попаднат в клъстера, което, меко казано, не винаги се предоставя в облачната инфраструктура.
Балансът в разпределението на натоварването се постига чрез използването на виртуализация Openstack на сървъри с мощни многоядрени процесори. На възлите за данни се разпределят собствени процесорни ресурси и определени дискове. В нашето решение Atos Codex Data Lake Engine постига се широка виртуализация, поради което печелим както по отношение на производителността (въздействието на мрежовата инфраструктура е сведено до минимум), така и TCO (допълнителните физически сървъри са елиминирани).
В случай на използване на сървъри BullSequana S200 получаваме много равномерно натоварване, лишено от някои от тесните места. Минималната конфигурация включва 3 сървъра BullSequana S200, всеки с два JBOD, плюс допълнителни S200, съдържащи четири възела за данни, които са свързани по избор. Ето примерно натоварване в тест TeraGen:
Тестовете с различни обеми данни и стойности на репликация показват едни и същи резултати по отношение на разпределението на натоварването между възлите на клъстера. По-долу е дадена графика на разпределението на достъпа до диска по тестове за производителност.
Изчисленията са базирани на минимална конфигурация от 3 сървъра BullSequana S200. Той включва 9 възела за данни и 3 главни възела, както и запазени виртуални машини в случай на внедряване на защита, базирана на OpenStack Virtualization. Резултат от теста TeraSort: Размерът на блока от 512 MB с коефициент на репликация три с криптиране е 23,1 минути.
Как може да се разшири системата? Налични са различни типове разширения за Data Lake Engine:
- Възли за данни: за всеки 40 TB използваемо пространство
- Аналитични възли с възможност за инсталиране на GPU
- Други опции в зависимост от нуждите на бизнеса (например, ако имате нужда от Kafka и други подобни)
Комплексът Atos Codex Data Lake Engine включва както самите сървъри, така и предварително инсталиран софтуер, включително комплекта Cloudera с лиценз; Самият Hadoop, OpenStack с виртуални машини, базирани на ядрото RedHat Enterprise Linux, репликация на данни и системи за архивиране (включително използване на резервен възел и Cloudera BDR - Backup and Disaster Recovery). Atos Codex Data Lake Engine е първото сертифицирано решение за виртуализация .
Ако се интересувате от подробности, ще се радваме да отговорим на нашите въпроси в коментарите.
Източник: www.habr.com