Рынак размеркаваных вылічэнняў і вялікіх дадзеных, калі верыць , Расце на 18-19% у год. Значыць, пытанне выбару софту для гэтых мэт застаецца актуальным. У гэтым пасце мы пачнем з таго, навошта патрэбныя размеркаваныя вылічэнні, падрабязней спынімся на выбары ПЗ, раскажам аб ужыванні Hadoop з дапамогай Cloudera, а напрыканцы пагаворым пра выбар жалеза і пра тое, як яно рознымі спосабамі ўплывае на прадукцыйнасць.
Навошта патрэбны размеркаваныя вылічэнні ў звычайным бізнэсе? Тут усё проста і складана адначасова. Проста - таму што ў большасці выпадкаў мы выконваем адносна нескладаныя разлікі на адзінку інфармацыі. Складана - таму што такой інфармацыі шмат. Вельмі шмат. Як следства, даводзіцца . Такім чынам сцэнары выкарыстання даволі ўніверсальныя: разлікі могуць прымяняцца ўсюды, дзе патрабуецца ўлічыць вялікую колькасць метрык на яшчэ большым масіве дадзеных.
Адзін з нядаўніх прыкладаў: сетка піцэрый Дадо Піца на падставе аналізу базы заказаў кліентаў, што пры выбары піцы з адвольным начыннем карыстачы звычайна аперуюць толькі шасцю базавымі наборамі інгрэдыентаў плюс парай выпадковых. У адпаведнасці з гэтым піцэрыя падстроіла закупкі. Акрамя таго, у яе атрымалася лепш рэкамендаваць карыстальнікам дадатковыя тавары, прапанаваныя на этапе замовы, што дазволіла павысіць прыбытак.
Яшчэ адзін прыклад: таварных пазіцый дазволіў краме H&M скараціць асартымент у асобных крамах на 40%, захаваўшы пры гэтым узровень продажаў. Гэтага ўдалося дасягнуць, выключыўшы пазіцыі, якія дрэнна прадаюцца, прычым у разліках улічвалася сезоннасць.
Выбар інструмента
Галіновым стандартам вылічэнняў такога роду з'яўляецца Hadoop. Чаму? Таму што Hadoop - гэта выдатны, добра дакументаваны фрэймворк (той жа Хабр выдае мноства падрабязных артыкулаў на гэтую тэму), які суправаджаецца цэлым наборам утыліт і бібліятэк. Вы можаце падаваць на ўваход вялізныя наборы як структураваных, так і неструктураваных дадзеных, а сістэма сама будзе іх размяркоўваць паміж вылічальнымі магутнасцямі. Прычым гэтыя самыя магутнасці можна ў любы момант нарасціць або адключыць - тая самая гарызантальная маштабаванасць у дзеянні.
У 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 можа сутыкнуцца з «бутэлькавым горлышком» пры чытанні дадзеных з дыска або з сеткі. Гэта таксама адзначаецца ў блогу Сloudera. У выніку для любых хуткіх вылічэнняў, у тым ліку і праз Spark, які часта выкарыстоўваецца для разлікаў у рэальным часе, вельмі важная хуткасць уводу/высновы. Таму пры выкарыстанні 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 МБ каэфіцыента рэплікавання роўным тром з шыфраваннем складае 23,1 мін.
Як можна пашырыць сістэму? Для Data Lake Engine даступныя розныя віды пашырэнняў:
- Вузлы перадачы даных: для кожных 40 ТБ карыснай прасторы
- Аналітычныя вузлы з магчымасцю ўстаноўкі графічнага працэсара
- Іншыя варыянты ў залежнасці ад запатрабаванняў бізнэсу (напрыклад, калі патрэбна Kafka і таму падобнае)
У склад комплексу Atos Codex Data Lake Engine уваходзяць як самі сервера, так і папярэдне ўсталяванае праграмнае забеспячэнне, якое ўключае камплект Cloudera з ліцэнзіяй; сам Hadoop, OpenStack з віртуальнымі машынамі на аснове ядра RedHat Enterprise Linux, сістэмы рэплікацыі дадзеных і бэкапу (у тым ліку з дапамогай ноды рэзервовага капіявання і Cloudera BDR – Backup and Disaster Recovery). Atos Codex Data Lake Engine стаў першым рашэннем з ужываннем віртуалізацыі, якое было сертыфікавана .
Калі вам цікавыя падрабязнасці, мы будзем рады адказаць на нашыя пытанні ў каментарах.
Крыніца: habr.com