Ринок розподілених обчислень та великих даних, якщо вірити зростає на 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:
Тести з різними обсягами даних та значеннями реплікації показують однакові результати з погляду розподілу навантаження між вузлами кластера. Нижче наведено графік розподілу доступу до диска за тестами продуктивності.
Розрахунки виконані з урахуванням мінімальної конфігурації з трьох серверів BullSequana S3. Вона включає 200 вузлів даних і 9 головні вузли, а також зарезервовані віртуальні машини на випадок розгортання захисту на базі OpenStack Virtualization. Результат тесту TeraSort: розмір блоку 3 МБ коефіцієнта реплікування, що дорівнює трьом із шифруванням, становить 512 хв.
Як можна розширити систему? Для 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