.png "Дмитрий Волков")
Технологии Spark, Tez, Solr, Hive, Storm и MapReduce позволили закачивать в репозитории петабайты данных разной природы — от лoгов работы приложений и записей в социальных сетях до графов описания маршрутов доставки заказов. Однако если в реляционном мире основные усилия тратились на то, чтобы затолкать все данные в конкретную схему или структуру, то теперь — часто на то, как узнать, что именно находится в репозитории, как оно туда попало и зачем нужно. Аналитики всерьез заговорили о проблеме «темных», или скрытых, данных, которые собрали, запомнили, а потом забыли.
Конечно, в идеале все данные должны аккуратно индексироваться и рационально раскладываться по «полкам» с целью их дальнейшей обработки всеми заинтересованными лицами с помощью любых удобных инструментов. Однако не все люди мыслят одинаково, и обычно каждый использует собственную схему представления и обработки: один менеджер хранит данные по сделкам в алфавитном порядке, другой — по дате, а третий — по вероятности их заключения. В результате компании взялись осваивать технологии стека Hadoop и NoSQL, позволяющие хранить данные без их привязки к заранее определенным жестким схемам, что можно считать преимуществом, особенно когда заранее неизвестно, что будут спрашивать и какие типы вопросов применять.
Однако за все приходится платить — есть риск потерять полезные сведения в огромных складах квазиструктурированных данных, что означает упущенные для компании возможности, убытки и усугубление и без того острой проблемы «темных» данных. Действительно, как отмечают аналитики, 64% корпораций, инвестировавших в проекты Больших Данных, не могут разобраться с тем, что у них накоплено, и это на фоне того, что только 28% всех потенциально доступных компаниям данных хоть как-то учитывается. Не удивительно, что аналитики Gartner в своем последнем отчете «Hype Cycle for Emerging Technologies» вообще исключили Большие Данные из списка прорывных технологий, хотя еще два года назад ставили их на пик интереса. Возможно, они переместились на «плато продуктивности» кривой Hype Cycle, но, скорее всего, растворились в других новых прорывных технологиях, к которым сегодня относятся IoT, машинное обучение, расширенную аналитику с элементами самообслуживания, биосенсоры и др. Подтверждение этому можно найти в статье «Системы для Больших Данных: конвергенция архитектур» этого номера журнала, авторы которой отмечают, что само по себе проектирование архитектур систем, предназначенных для работы с большими объемами данных, связано с множеством трудностей. В частности, чтобы удовлетворить всем требованиям к качеству решения, архитектуру распределенного ПО надо увязать со структурами данных и архитектурой развертывания — масштаб проектов Больших Данных, обусловленный консолидацией функционала, уже не позволяет по отдельности рассматривать особенности архитектур.
Как отмечается в статье «Аналитика реального времени для ситуационного центра», системы индексации типа Solr и Elasticsearch могут сыграть определенную роль в обнаружении скрытых данных, особенно когда контекст неизвестен, однако без структуры обойтись трудно, если требуется отбросить ненужные данные и оставить необходимые. Вместе с тем для конкретных применений, будь то анализ социальных сетей или мониторинг работы распределенной инфраструктуры средств связи, эффективные решения возможны. По мнению авторов статьи «Анализ работы телекоммуникационной системы», данные телеметрии, полученные от телекоммуникационного оборудования, можно анализировать средствами распределенного объектного хранилища Swift, организованного по принципу ключ-значение, где в качестве ключа выступает имя файла, а в качестве значения — файлы в любом формате.
Разобравшись с технологиями стека Hadoop и построив хранилище, куда складываются все биты и байты, доселе остававшиеся вне поля зрения компаний, самое время проанализировать накопленное, однако на пути успешной аналитики лежит фрагментация данных, полученная в наследство от времен, когда каждый ИТ-производитель снабжал своих заказчиков собственными средствами создания разнообразных репозиториев. В результате нередки ситуации, когда в одной корпорации применяются сотни ERP — разные сотрудники могут получить доступ к разным хранилищам, но никто не имеет целостного представления. Как отмечается в статьях этого номера, аналогичная ситуация складывается и при решении задачи мониторинга различных социальных сетей — несложно выделить все связи какого-то человека внутри одного сообщества, однако наибольшую ценность представляют его связи вне конкретной группы, с субъектами других сетей. Фрагментация информационного пространства обесценивает аналитику, поэтому, по мнению наших авторов, для того чтобы компании, стремящиеся к демократизации доступа к своим данным, имели конкурентные преимущества, а исследователи получали целостное представление об объекте изучения, им всем нужны средства анализа, независимые от хранилища, например Apache Spark.
Количество различных данных, генерируемых компаниями и организациями, удваивается каждые 18 месяцев, почти в точности по закону Мура, однако когда львиная доля данных остается в тени, это может дискредитировать инициативы, связанные с Большими Данными, прежде, чем они успеют оказаться на плато продуктивности.
