Как управлять проектом категории “большие данные” – часть 2

23 Июня 2017
Перевод интервью с Джеймсом Кобилусом, Старшим директором программ в IBM, автор – Роберто Зикари.

Опубликовано на сайте ODBMS.ORG

Вопрос: Какие основные проблемы и сложности встречаются в проектах с «большими данными»?

Джеймс Кобилус: Основные проблемы и сложности связаны с интегрированным управлением жизненным циклом (ILM – integrated lyfecycle management).

ILM сталкивается с «неизведанным», когда речь идет о «больших данных». Основные сложности складываются из трех моментов: банальная неограниченность 
«больших данных», призрачная природа многих новых данных и сложность в обеспечении постоянного качества в процессе того, как данные растут по всем трем V (volume, velocity, variability): объем, скорость, разнообразие. ILM становится все более сложно обеспечить в системах с «большими данными», имея в виду стремительные изменения в следующих областях:

  • Новые платформы «больших данных»: «Большие данные» несут целый «зверинец» новых платформ – Hadoop, NoSQL, «в памяти» и графовые базы данных в корпоративное окружение наряду с проверенными технологиями как базы данных для массивной параллельной обработки (MPP – massively parallel processing), столбцовые и размерные базы данных. Вероятность того, что ваши существующие средства для ILM будут сразу работать со всем этим – весьма мала. И если вы занимаетесь «большими данными» в публичном облаке, вам придется использовать те функции ILM – сильного, слабого или среднего уровня – которые использует ваш провайдер. Чтобы снизить ваши риски в новом, гетерогенном мире и быть уверенным в своих основных данных, вам придется внимательно разбираться с новыми платформами «больших данных», чтобы убедиться, что у них есть ILM-функции – безопасность данных, управление, архивирование и сохранение, которые соответствуют тем ролям, для которых вы планируете использовать эти платформы.
  • Новые предметные области «больших данных»: «Большие данные» не изменили требования к узлам управления данными, где вы храните и управляете офисными системами записей (клиенты, финансы, HR). Это роль вашего существующего «склада данных» предприятия, который как правило работает на традиционных платформах реляционных баз данных и имеет сильные функции ILM. Но эти системы могут быть весьма далеки от ваших более новых платформ «больших данных», многие из которых сфокусированы на данных из соцсетей, гео-пространственных данных, записях кликов пользователей на сайте и других новых источниках. Эти новые области данных часто являются «эфемерными», то есть в них может не быть необходимости сохранять большой объем данных навсегда.
  • Новые объемы «больших данных»: «Большие данные» - это не значит, что ваши новые платформы должны поддерживать бесконечный объем, мгновенную скорость и неограниченное разнообразие. Сам масштаб новых данных будет таков, что скорее всего их невозможно будет где-либо хранить, учитывая технологические и финансовые ограничения. Эта реальность заставит менеджеров проектов с «большими данными» сфокусироваться на творческой настройке политик хранения, архивирования и сохранения данных. По мере масштабирования «больших данных» вам нужно будет убедиться, что требования ILM будут поддерживаться с учетом ваших ограничений по объему, скорости и разнообразию.
Если облака для вас
не просто теория
Широкий спектр услуг
по выделенным северам
и мультиклауд-решениям
Конфигурация VPS и бесплатный тест уже через 2 минуты
Организация вашей IT-инфраструктуры на основе мультиклауд-решения

Вопрос: с чего лучше всего начать проект с «большими данными»?

Джеймс Кобилус: Организуйте проект таким образом, чтобы быстро начать показывать выгоду для бизнеса. Создайте «проект-ядро», которые сможет служить основой для дальнейших проектов в области «больших данных».

Нужно осознать, что изначальная технология баз данных, которую вы будете использовать в своем стартовом проекте будет всего лишь одним из многих слоев хранения, которому придется работать в гибридной, многоуровневой архитектуре ваших «больших данных» в будущем.

В более далекой эволюционной перспективе, «большие данные» в гибридную парадигму, в которой Hadoop, массивная параллельная обработка, «склады данных» предприятия, базы данных «в-памяти», NoSQL, базы данных документов и другие подходы поддерживают облачную аналитику.

Гибридная архитектура реагирует на гетерогенную реальность «больших данных» и отвечает необходимости объединить как существующие, так и новые подходы к аналитике в общей архитектуре.

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

  • Сбор данных
  • Накопление
  • Преобразование
  • Перенос
  • Очистка
  • Демонстрация
  • «Песочница»
  • Моделирование
  • Управление
  • Обеспечение доступа
  • Интерактивное исследование
  • Архивирование

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

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

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

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

Гибридные проекты уже широко распространены в реальном мире «больших данных». Наиболее типичной является трехуровневая архитектура. Как правило используется Hadoop (например в IBM InfoSphere BingInsights) как слой сбора и накопления данных, предварительной обработки и преобразования; реляционный MPP-«склад данных» (например IBM PureData System for Analytics) в качестве слоя управления; и базы данных «в памяти» (например, IBM Cognos TM1) в качестве слоя доступа и взаимодействия.

Гибридные архитектуры «больших данных» будут оставаться экономически выгодными, если будет выполняться следующий многосторонний подход к оптимизации распределенного хранения:

  • Применяйте построенные под задачу базы данных для конкретных случаев использования «больших данных».
  • Соотнесите модели данных со структурами и приложениями
  • Сжимайте и управляйте данными разумно. Гибридная архитектура должна позволять разумно сжимать «большие данные», чтобы уменьшить требуемые для них ресурсы хранения.