Як hadoop допомагає вирішити проблему з великими даними

Великі дані … ну … великі розміри! Точно, скільки даних можна віднести до великих даних, не дуже зрозуміло, тому не будемо зациклюватися на цій дискусії. Для невеликої компанії, яка звикла працювати з даними в гігабайтах, 10 ТБ даних було б великим. Однак для таких компаній, як Facebook та Yahoo, петабайт великий.

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

Тут ми розглянемо великі дані, її виклики та те, як Hadoop може допомогти їх вирішити. По-перше, найбільші проблеми для великих даних.

Великі дані неструктуровані або напівструктуровані

Багато великих даних неструктуровані. Наприклад, дані журналу потоку кліків можуть виглядати так:

часова марка, user_id, сторінка, reference_page

Відсутність структури робить реляційні бази даних не дуже придатними для зберігання великих даних. Крім того, не багато баз даних можуть впоратися зі збереженням мільярдів рядків даних.

Немає сенсу зберігати великі дані, якщо ми не можемо їх обробити

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

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

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

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

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

Як Hadoop вирішує велику задачу даних

Hadoop побудований для роботи на скупченні машин

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

Саме так будується Hadoop. Hadoop розроблений для роботи на скупченні машин з початку руху.

Скупчення Hadoop масштабуються горизонтально

Більше запам'ятовування та обчислювальної потужності можна досягти, додавши більше вузлів до кластеру Hadoop. Це позбавляє від необхідності купувати все більш потужне та дороге обладнання.

Hadoop може обробляти неструктуровані / напівструктуровані дані

Hadoop не застосовує схему даних, що зберігаються. Він може обробляти довільний текст та двійкові дані. Тож Hadoop може легко перетравити будь-які неструктуровані дані.

Кластери Hadoop забезпечують зберігання та обчислення

Ми побачили, як наявність окремих кластерів для зберігання та обробки не найкраще підходить для великих даних. Однак кластери Hadoop забезпечують зберігання та розподілені обчислення все в одному.

Ділова справа Hadoop

Hadoop забезпечує зберігання великих даних за розумною вартістю

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

Одне дослідження Cloudera припускає, що підприємства зазвичай витрачають від 25 000 до 50 000 доларів за терабайт на рік. У Hadoop ця вартість падає до кількох тисяч доларів за терабайт на рік. Оскільки обладнання стає дешевшим і дешевшим, ця вартість продовжує знижуватися.

Hadoop дозволяє збирати нові або більше даних

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

Одним із прикладів можуть бути журнали натискань на веб-сайті. Оскільки обсяг цих журналів може бути дуже високим, не багато організацій їх захопили. Тепер з Hadoop можна збирати та зберігати журнали.

За допомогою Hadoop ви можете зберігати дані довше

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

Наприклад, візьміть журнали кліків з веб-сайту. Кілька років тому ці журнали зберігалися на короткий проміжок часу для обчислення статистичних даних, як популярні сторінки. Тепер із Hadoop ці журнали кліків можна зберігати протягом більш тривалого періоду часу.

Hadoop забезпечує масштабовану аналітику

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

Hadoop забезпечує багату аналітику

Native MapReduce підтримує Java як основну мову програмування. Також можуть бути використані інші мови, такі як Ruby, Python та R.

Звичайно, написання спеціального коду MapReduce - не єдиний спосіб аналізу даних у Hadoop. Доступно зменшення карт вищого рівня. Наприклад, інструмент під назвою Pig використовує англійську мову як потік даних та переводить їх у MapReduce. Інший інструмент, Hive, приймає запити SQL і запускає їх за допомогою MapReduce.

Інструменти бізнес-аналітики (BI) можуть забезпечити ще більш високий рівень аналізу. Існують також інструменти для цього типу аналізу.

Цей вміст витягнутий із "Hadoop Illuminated" Марка Керзнера та Суджі Маніям. Він був доступний через непідконтрольну ліцензію Creative Commons Attribution-NonCom Commercial-ShareAlike 3.0.