«Управление данными 2019»: узкие места больших данных и как их обойти
Руководитель бизнес-направления Big Data Solutions компании «Неофлекс» о том, что позволит уменьшить стоимость и упростить современные проекты больших данных.
В России пока не так много предприятий, которые имеют достаточный опыт в реализации проектов больших данных, поэтому сегодня особенно ценно узнать мнение экспертов в этой области. В ходе форума «Управление данными 2019» Артем Меркулов, руководитель бизнес-направления Big Data Solutions компании «Неофлекс», рассказал нам об основных сложностях, возникающих в проектах больших данных, и о путях их преодоления.
- Какие аспекты систем больших данных вызывают трудности у заказчиков?
Многие организации сейчас только начинают осваивать область больших данных и ведут пилотные проекты. Им часто не хватает внутренней экспертизы — в первую очередь по администрированию приложений, конфигурированию системных компонентов, кластеров. Нехватка квалифицированных кадров, пожалуй, главная проблема на сегодня.
Что касается технических аспектов, то, и по нашим наблюдениям, и по оценкам экспертов, до 80% всех объемов работ приходится на предварительную подготовку и обработку данных, поэтому именно эти процессы требуют от заказчиков наибольшего напряжения.
- При реализациии каких компонентов систем больших данных возникают наибольшие трудности?
Всегда присутствует рутинная часть – например, загрузка информационного «сырья» в хранилище или озеро данных. Такого рода процессы нужно автоматизировать, и мы в нашей платформе Datagram эту функцию реализовали. Вторая группа трудоемких компонентов связана со сложной настройкой трансформации данных. Зачастую загрузка данных происходит отдельно от их преобразования (например, средствами языка Scala). Наша платформа позволяет использовать трансформацию любой сложности, при необходимости прибегая к помощи внешних инструментов. Третья группа связана с DevOps, непрерывной интеграцией и развертыванием создаваемых приложений. Эти инструменты должны пронизывать все решение, поддерживая работу большой, в том числе распределенной команды. Реализация таких инструментальных конвейеров посредством одного лишь ПО с открытым кодом оказывается весьма трудоемкой.
- Какие компоненты являются самыми дорогостоящими?
Аппаратные компоненты систем больших данных по стоимости сопоставимы с теми, что применяются в «традиционных» проектах, при этом ПО зачастую обходится практически бесплатно, поскольку для работы с большими данными широко применяются продукты с открытым кодом. Самое дорогое – высококвалифицированный персонал. Такие специалисты дефицитны, поэтому их труд ценится. Но, даже если вы готовы предложить им достаточно денег, найти этих сотрудников на рынке и привлечь их все равно будет сложно.
- Нередко компаниям приходится анализировать данные из новых источников. Насколько трудоемкой и затратной оказывается интеграция с ними?
Просто подключить новый источник и обеспечить загрузку данных из него несложно – это вопрос нескольких дней или, возможно, недель. Гораздо труднее интегрировать данные из него в существующие системы. Главный фактор здесь – прозрачность алгоритмов, по которым планируется объединять данные. Если основой объединения служат простые ключи – это одна задача, если же, к примеру, требуется дополнить информацию о клиентах информацией из соцсетей, то задача значительно усложняется.
При подключении новых источников нередко приходится изменять бизнес-процессы заказчика – это нужно либо для того, чтобы полученные данные были задействованы и использовались, либо чтобы сотрудники им доверяли. Как известно, изменение бизнес-процессов – процесс достаточно трудоемкий и болезненный для любой организации.
- Как влияет на архитектуру и реализацию систем больших данных требование анализировать данные Интернета вещей?
Для Интернета вещей характерны две ключевые особенности. Первая – обработка потоков данных в реальном времени. Если система изначально не была спроектирована в расчете на потоковую аналитику, то, скорее всего, в нее придется внести серьезные изменения. Насколько это необходимо, будет зависеть от решаемой задачи. Одно дело – сбор потоковых данных и их анализ с определенной периодичностью (например, раз в сутки) и совсем другое – обработка данных «на лету»: чтобы выявлять аномалии или иные события, на которые надо реагировать немедленно, здесь требуется другая архитектура.
Вторая особенность – очень быстрый рост объемов данных при подключении источников Интернета вещей. Чтобы справляться с их потоком, нужна масштабируемая архитектура. Если возможности масштабирования недостаточны, то проблемы неизбежны, это касается и оборудования, и нагрузок на системные компоненты ПО. Проектируя системы больших данных для Интернета вещей, необходимо это учитывать и закладывать в них некоторый запас.
- Как правило, в проектах больших данных приходится сталкиваться с большим разнообразием источников, типов и форматов данных, а также с разными требованиями к их хранению и обработке. Охватить их одним ИТ-инструментарием часто не удается, поэтому решения получаются сложными. Как можно уменьшить эту сложность?
Первый, широко распространенный путь – использовать готовые дистрибутивы Hadoop. Самые популярные среди них — от Cloudera, объединившейся с Hortonworks, и от российской компании Arenadata. В эти дистрибутивы включены компоненты, которые покрывают около 80% потребностей, возникающих на предприятиях, к тому же они уже интегрированы между собой. Это существенно упрощает реализацию проектов и снижает их стоимость. Недостающие компоненты можно найти на рынке, заказать или разработать самостоятельно.
Второй путь основан на умении работать с различными источниками данных, придерживаясь единых форматов и подходов. В нашей платформе Datagram мы унифицировали подключение ко всем источникам, в том числе потоковым, чтобы инженеры по данным и аналитики могли объединить и трансформировать данные из любых источников с помощью единого интерфейса.
- Есть ли возможность снизить общую стоимость владения решениями для работы с большими данными?
Здесь можно выделить две области. Первая – вычислительные мощности: для проектов больших данных можно применять стандартные серверы среднего и начального уровня производительности, объединяя их в легко масштабируемые кластеры. Вторая – использование облачных сервисов: заказчик арендует те объемы для хранения данных, которые ему реально нужны, и таким образом эффективно управляет своими запасами.
Сэкономить на ПО позволяют компоненты с открытыми кодами – их на рынке сейчас очень много, дистрибутивы многих из них бесплатны. Еще на стадии пилотного проекта заказчик оценивает, поддержка каких компонентов ему потребуется в ходе дальнейшей эксплуатации системы, и затем приобретает только эти услуги. Снизить совокупную стоимость владения помогает также модель приобретения ПО по подписке, ее сегодня применяют многие вендоры, в том числе и наша компания.