Перевод интервью с Джеймсом Кобилусом, Старшим директором программ в 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) в качестве слоя доступа и взаимодействия.
Гибридные архитектуры «больших данных» будут оставаться экономически выгодными, если будет выполняться следующий многосторонний подход к оптимизации распределенного хранения:
- Применяйте построенные под задачу базы данных для конкретных случаев использования «больших данных».
-
Соотнесите модели данных со структурами и приложениями
-
Сжимайте и управляйте данными разумно. Гибридная архитектура должна позволять разумно сжимать «большие данные», чтобы уменьшить требуемые для них ресурсы хранения.