Пазарот за дистрибуирани компјутери и големи податоци, според , расте за 18-19% годишно. Ова значи дека прашањето за избор на софтвер за овие цели останува релевантно. Во овој пост, ќе започнеме со тоа зошто е потребно дистрибуирано пресметување, ќе навлеземе во повеќе детали за изборот на софтвер, ќе разговараме за користење на Hadoop со користење на Cloudera и на крајот ќе разговараме за изборот на хардвер и како тоа влијае на перформансите на различни начини.
Зошто се потребни дистрибуирани компјутери во редовниот бизнис? Сè овде е едноставно и комплицирано во исто време. Едноставно - затоа што во повеќето случаи вршиме релативно едноставни пресметки по единица информации. Тешко е затоа што има многу такви информации. Премногу. Како последица на тоа, неопходно е . Така, случаите на употреба се доста универзални: пресметките може да се користат секаде каде што е неопходно да се земат предвид голем број метрики на уште поголема низа податоци.
Еден од последните примери: синџирот пицерии Dodo Pizza врз основа на анализа на базата на податоци за нарачки од клиенти, дека при изборот на пица со случаен прелив, корисниците обично работат со само шест основни групи состојки плус неколку случајни. Во согласност со ова, пицеријата ги приспособи своите набавки. Покрај тоа, таа можеше подобро да препорача дополнителни производи што им се нудат на корисниците во фазата на нарачка, што го зголеми профитот.
Уште еден пример: артиклите на производите и овозможија на продавницата на H&M да го намали асортиманот во поединечни продавници за 40%, додека го одржуваше нивото на продажба. Тоа е постигнато со исклучување на слабо продадените артикли, а во пресметките била земена предвид и сезонската.
Избор на алатка
Индустрискиот стандард за овој тип на пресметување е Hadoop. Зошто? Бидејќи Hadoop е одлична, добро документирана рамка (истиот Habr обезбедува многу детални статии на оваа тема), која е придружена со цел сет на комунални услуги и библиотеки. Можете да внесете огромни групи на структурирани и неструктурирани податоци, а самиот систем ќе ги дистрибуира меѓу компјутерската моќ. Покрај тоа, истите овие капацитети може да се зголемат или оневозможат во секое време - истата хоризонтална приспособливост во акција.
Во 2017 година влијателната консултантска компанија Гартнер дека Хадуп наскоро ќе застари. Причината е сосема банална: аналитичарите веруваат дека компаниите масовно ќе мигрираат во облакот, бидејќи таму ќе можат да плаќаат бидејќи користат компјутерска моќ. Вториот важен фактор што наводно може да го „закопа“ Хадуп е неговата брзина. Бидејќи опциите како 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 виртуелизација на сервери со моќни повеќејадрени процесори. На податочните јазли им се доделуваат сопствени процесорски ресурси и специфични дискови. Во нашата одлука Атос Кодекс податоци Езерски мотор Постигната е широка виртуелизација, поради што имаме корист и во однос на перформансите (влијанието на мрежната инфраструктура е минимизирано) и во 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 употреблив простор
- Аналитички јазли со можност за инсталирање графички процесор
- Други опции во зависност од деловните потреби (на пример, ако ви треба Кафка и слично)
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