«Большая вода»… «Большая руда»… Большие Данные!
Big Data Big Data

Термин "Big Data" родился 4 сентября 2008 года с лёгкой руки журнала "Nature" и его редактора Клиффорда Линча (Clifford Lynch). В этот день вышел номер журнала "Nature" с темой номера "Большие Данные. Наука петабайтной эры" ("Science in the Petabyte era").

Главная>Big Data>«Большая вода»… «Большая руда»… Большие Данные!
Big Data Тема номера

«Большая вода»… «Большая руда»… Большие Данные!

Дата публикации:
30.07.2012
Посетителей:
112
Просмотров:
108
Время просмотра:
5.4 мин.

Авторы

Автор
Андрей Лукичев В прошлом - бизнес-архитектор компании «Инфосистемы Джет»
Термин Big Data родился 4 сентября 2008 года с лёгкой руки журнала «Nature» и его редактора Клиффорда Линча (Clifford Lynch).

 

 

В этот день вышел номер журнала «Nature» с темой номера «Большие Данные. Наука петабайтной эры» («Science in the Petabyte era»). Метафора «Большие Данные» в соответствии с «Nature» представляет собой продолжение такого ряда понятий, как «Большая вода», «Большая руда», «Большая игра» и указывает не на размер (хотя это первое, что приходит в голову), а на появление нового качества у данных. Что это за качество, нагляднее всего можно продемонстрировать на примере другого определения термина «Большая вода» – половодье, наводнение. Таким образом, Big Data – это цифровое «наводнение» в наших ЦОД.


Когда с самим термином, как мне кажется, мы более-менее определились, становится понятно, что Big Data и связанные с ними проблемы затрагивают далеко не всех и не всегда.

 

Отсюда и такие полярные мнения по этому вопросу: «кто большой воды никогда не видел – тот и плавать никогда не учился». Тех же, кто уже столкнулся с необходимостью работы с Большими Данными или всерьёз собирается это сделать, волнуют вопросы о способах хранения и инструментах их обработки. Далее хочется сделать небольшое отступление об устройствах хранения и привести несколько графиков.

 

Обычно данные хранят на жёстких дисках/дисковых массивах. Большие Данные в этом вопросе не являются исключением просто по причине отсутствия альтернативы. Следующие два графика (см. рис. 1) демонстрируют два показателя примерно за один период: рост ёмкости единичного диска и снижение стоимости 1 Гб.

Рис. 1. По материалам: A History of Storage Cost by Matthew Komorowski «Kryder’s Law». Scientific American.The Performance Gap Dilemma. By BillM. Storageoptics

 

Конечно, возможны какие-то флуктуации цен, например, связанные с наводнением в Тайване в прошлом году, но в среднем всё достаточно ровно и линейно. Плотность записи на «пластину» в жёстком диске монотонно повышается, а стоимость падает. Производительность же одного диска (скорость чтения/записи) при этом, конечно, повышается, но ввиду технологических и физических ограничений достаточно медленно. Прорывом в этой области являются SSD-диски, но они сейчас существенно (в разы за 1 Гб) дороже традиционных решений. Эта тенденция сохранится ещё несколько лет.

 

В то же время есть другой ресурс, который также дешевеет, с одной стороны, и наращивает производительность – с другой. Речь о ресурсах центрального процессора (Central Processing Unit – CPU). На третьем графике (см. рис. 2) показаны рост производительности CPU в интервале 10 лет и в сравнении с ним рост производительности дисковых систем хранения данных за тот же период. Значительное расхождение этих кривых говорит о том, что рост производительности вычислительной составляющей сервера значительно опережает рост производительности его подсистемы ввода/вывода. Налицо performance gap.

 

Рис. 2. Рост производительности CPU в интервале 10 лет

 

Этот факт не является открытием для отрасли, и давно существуют механизмы его использования в «мирных целях». Основных механизма два.

 

Количественный метод. Консолидировать значительное количество физических устройств хранения данных (дисков) под управлением мощного сервера. Этот подход является традиционным и до сих пор с успехом используется. Количество «шпинделей», на которых требуется разместить данные СУБД для необходимой производительности, до сих пор является обязательным параметром опросника (процедура Capacity Planning).

 

Качественный метод. Можно сделать наоборот – не консолидировать диски десятками до заполнения их суммарной производительностью performance gap, а воспользоваться вычислительной мощностью процессора для его ликвидации. Например, практически любой современный дисковый массив имеет свой процессор (часто не один) и, кроме традиционных «умений» вроде кэш-памяти, управляющих контроллеров, snapshot’ов и т.д., может предложить дедупликацию «на лету». Она повышает ёмкость массива за счёт исключения из хранения дублирующихся порций информации и thin-provisioning, позволяющего гибко наращивать физическую ёмкость системы хранения данных в отрыве от ёмкости логической.

 

Возвращаясь к теме Больших Данных и методам их хранения и обработки, хочу отметить, что это – развитие качественного метода с привнесением прикладной логики в систему хранения данных (когда устройство хранения знает, какие данные на нём содержатся, и может осуществлять поиск по шаблону).

 

Традиционная количественная концепция хранения и работы с данными представлена на рисунке 3. В фокусе находится прикладная задача. Все традиционные СУБД сейчас построены именно таким образом. Ниже приведены основные фазы работы с данными:

 

  1. Вспомогательные системы готовят данные из разных источников для загрузки в систему.
  2. Проводится загрузка данных.
  3. По этому набору данных выполняются действия прикладной задачи.
  4. Выдаётся результат.
  5. Результат может передаваться в другую задачу.

 

Такой метод построения хранилища и работы с данными как нельзя лучше подходит для традиционных реляционных СУБД. Зная заранее, какая задача будет работать с данными и каковы будут её типовые запросы, мы можем максимально точно подогнать под них схему размещения данных, индексы, партиции и т.п. для обеспечения оперативного получения ответа. Но когда возникают нетрадиционный запрос или нетипичные данные, не подходящие по формату (например, задача сохранить 1 млн фотографий и искать по образу), то здесь как раз и возникают трудности.

 

Наиболее частый случай – на порядок возрастает время получения ответа или стоимость решения.

 

Рис. 3. Концепции работы с данными

 

Теперь поговорим о том, как изменяется эта концепция, когда речь идёт о хранении и обработке Больших Данных.

 

В центре – данные и их хранилище. Хранилище представляет собой распределённую вычислительную систему (grid), где каждый узел (node или нода) наделён собственной, относительно небольшой ёмкостью для хранения, за которую он отвечает и умеет по запросу управляющего узла искать в ней данные.

 

Ниже приведены основные фазы работы:

 

  1. Исходные документы загружаются в общее хранилище с описанием в едином формате (но можно и в разных).
  2. Прикладные задачи 1 и 2 в виде программных модулей загружаются и запускаются на всех нодах grid-системы хранилища, каждая нода работает со своим набором данных.
  3. Результаты, полученные на всех нодах, агрегируются, и формируется общий результат.
  4. Результат выдаётся потребителю и может быть передан им в другую задачу.

 

Этот подход отличается от предыдущего тем, что на этапе планирования хранилища мы можем позволить себе точно не знать тех запросов и даже форматов данных, с которыми к нам потом придут потребители. Мы обеспечиваем платформу хранения и диспетчеризацию задач и ожидаем, что параллельно запускаемые на каждом узле нашей системы в виде программных модулей задачи сами могут выбрать из хранящихся на этом узле данных то, что им нужно. Сравнивать производительность первого и второго решения будет не совсем корректно, потому что они не конкурируют, а дополняют друг друга: второе решение начинается там, где заканчиваются возможности первого.

 

Я постарался вкратце рассказать об истории возникновения термина «Большие Данные» и подготовить почву для дальнейших, гораздо более технических и экспертных статей моих коллег.

Уведомления об обновлении тем – в вашей почте

Большие Данные = большая проблема?

Одна из наиболее обсуждаемых тем в ИТ-изданиях в последнее время - феномен Big Data, или проблема Больших Данных. Стоит отметить, что проблема хранения и обработки большого объема данных существовала всегда, но с развитием ИТ она стала беспокоить не только ряд крупнейших корпораций, но и гораздо более широкий круг компаний.

Эволюция интеграции данных от компании Informatica

Любая компания – это живой организм, поэтому она проходит в своем развитии несколько этапов: от детства до зрелости.

Шерлок против Big Data

Шерлок Холмс: Но я-то не каждый, Ватсон, поймите: человеческий мозг — это пустой чердак, куда можно набить всё, что угодно.

Комплексные решения от Hitachi Data Systems

В настоящее время при построении ИТ-инфраструктур большое внимание уделяется таким показателям, как эффективность использования ресурсов.

Как не утопить ваши данные в болоте

Практика говорит: все больше и больше заказчиков приходит с идей построить единое хранилище, да еще на новых технологиях.

Цифровые недра, или ИТ–инфраструктуру 2025 года пора планировать уже сейчас. Часть 2

Литературный образ цифровых недр хорошо описывает те изменения, которые происходят на планете в ходе цифровой революции

Современный ритейлер трансформируется в цифровую компанию

Руководитель направления “Стратегия и инновации” ИТ-дирекции X5 Retail Group Виталий Порубов рассказал нам об особенностях цифровой трансформации одного из крупнейших отечественных ритейлеров в условиях, когда инновации стали важным способом оптимизации бизнеса.

«Мы строим с нуля и берем лучшие мировые технологии»

Несколько лет подряд Москва становится номинантом престижной международной премии World Smart City Awards.

Современный SSD — расходный материал

Иногда приходится сталкиваться с тем, что к крутящимся жестким дискам (HDD) относятся как к расходному материалу. Отчасти это верно, так как механический износ со временем приводит к их поломке. Но само перемагничивание диска при записи данных может происходить нескончаемое число раз.

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на тему







      Спасибо!
      Вы подписались на обновления наших статей
      Оформить
      подписку на журнал







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








            Оставить заявку

            Мы всегда рады ответить на любые Ваши вопросы

            * Обязательные поля для заполнения

            Спасибо!

            Благодарим за обращение. Ваша заявка принята

            Наш специалист свяжется с Вами в течение рабочего дня