Hadoop і зберігання Великих даних: Від «експерименту» до продукту

Примітка перекладача: Автор оригінального матеріалу Ендрю Уорфілд працює в якості CTO компанії Coho Data, крім того він є доцентом напряму комп'ютерних наук в Університеті Британської Колумбії. Це перший матеріал на тему хмарної інфраструктури та інтеграції Big Data у традиційні ІТ-системи. Переклад другої примітки буде опублікований в нашому блозі на цьому тижні.



Пару років тому я почав спілкуватися з представниками компаній зі списку Fortune 500 і цікавився тим, як вони використовують інструменти на зразок Apache Hadoop або Spark для роботи з big data. Мені це було цікаво, оскільки я сподівався почути щось про гігантських обсягах розгортання складних аналітичних програмах, і різних командах, чию роботу полегшують всі ці технології.

Я працюю CTO стартапу, який займається enterprise-інфраструктурою, і хотів зрозуміти, як великі компанії інтегрують величезні масиви великих даних з вже існуючою інфраструктурою, особливо з точки зору сховищ даних. Загалом, хотів дізнатися про больових точках.

Результати подібних опитувань були дивовижними. За рідкісними винятками використання великих даних у великих організаціях характеризується декількома загальними рисами.

Багато невеликих кластерів Big Data

Дуже часто на запитання про «власника великих даних» мені представляли цілий ряд людей, кожен з яких відповідав за кластер з 8-12 вузлів. ІТ-керівники компаній називали це «розростанням аналітики», а деякі навіть жартували про те, що упаковка і розгортання Cloudera CDH з допомогою Docker зробило створення і підтримку нових кластерів «занадто простим справою.



Схема роботи Cloudera з офіційного сайту проекту

Нестандартні установки, навіть на стандартних платформах

У згаданих невеликих кластерів як правило використовуються відомі платформи для роботи з великими даними на кшталт Cloudera або Hortonworks — вони об'єднують безліч аналітичних інструментів в одну добре документовану і легко управлемую середу. Цікаво, що зазвичай ці платформи використовуються лише як основа, в яку вручну додаються інші корисні інструменти.

Приклад — кастомізація ETL (extract, transform, load — витяг, траспортировка, завантаження), тобто вивантаження даних з існуючих ресурсів. Також часто додаються нові аналітичні інструменти (H2o, Naiad та інші). Екосистема навколо Big Data розвивається так швидко, що коробкові продукти не можуть охопити всі важливі для інженерів аспекти, тому їм доводиться вручну розширювати функціональність використовуваних систем.



Схема роботи H2O з офіційного сайту проекту

Неефективності

Як правило, аналітична інфраструктура розгортається окремо від традиційних ІТ-систем, тобто у власних стійках, зі своїми свитчами і так далі. Дані копіюються з enterprise-систем хранениия в HDFS, запускаються процеси обробки, а потім дані копіюються з HDFS назад в основну систему.

Поділ обчислювальної інфраструктури призводить до неефективної витрати ресурсів і збільшення операційних витрат бізнесу. Також бізнес сильно переживає про збереження даних і вирішує цю проблему за допомогою створення дублюючої інфраструктури в різних фізичних локаціях, і в кожному з цих місць виконується одна і та ж робота.

Більше одного способу побудови великих даних

Важливо відзначити, що все вищеописане не обов'язково є чимось неправильним. За великим рахунком компанії тільки починають серйозно працювати з великими даними, що виливається в різноманітні експерименти. Однак, коли такі кошти стануть вже критично важливими для бізнесу, операційні потреби різко зміняться.

У розмовах з інженерами Big Data і працівниками, відповідальними за «звичайну» ІТ-інфраструктуру, мені часто доводилося чути, що всі ці великі дані в компанії сприймаються як «експериментальний науковий проект». Це не негативний опис, але воно пояснює тенденції до створення окремих ізольованих інфраструктурних кластерів для роботи з великими даними.

Зараз однією з головних завдань ІТ-команд великих компаній є питання про те, як зробити так, щоб великі дані стали надійним і відтворюваним «продуктом» (це не кажучи про ефективність і вартості), таким як сховища, віртуальні машини, бази даних та інші інфраструктурні сервіси в наші дні.

Від наукового проекту до наукового продукту

Складність полягає не у виборі хмарної платформи для роботи з Big Data. Плинність стека пов'язаних з ними технологій і переважання «кустарного» підходу до розробки систем (з «допиливанием» готових продуктів руками) найближчим часом не зміняться.

Для того, щоб «науковий проект» трансформувався в життєздатне і ефективне рішення для бізнесу, потрібно переосмислення багатьох речей від вендорів і компаній, які впроваджують їх вирішення в своєї інфраструктурі. Ця еволюція відбувається прямо на наших очах, і дуже скоро ми побачимо, як компанії різних розмірів і форм, будуть працювати зі своїми великими даними для зростання бізнесу та стануть використовувати їх для кращого обслуговування своїх клієнтів і розуміння їх потреб.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.