Процесс обработки Больших Данных поддерживается сегодня сложным конгломератом решений, состоящих как минимум из трех технологических уровней (рис. 1). На уровне приложений, привязанном к конкретному языковому стандарту, платформе и программной методологии, формируются комплексные запросы к данным непосредственно на языке запросов или посредством инструментария их генерации. Запросы строятся с учетом специфики и возможностей приложения, ограничений или особенностей применяемой программной модели и схем данных, а также подчас с некоторыми элементами обучения приложения типовым запросам. Уровень аналитики или автоматической обработки данных («движок» или ядро) содержит основные алгоритмы работы с данными. Системный уровень — это среда хранения данных.
.png "Рис. 1. Пример экосистемы Больших Данных") |
| Рис. 1. Пример экосистемы Больших Данных |
Продукты, применяемые сегодня в контексте технологического стека Больших Данных, были изначально предназначены для вполне определенных задач — например, движки Flume и Dremel, используемые соответственно прикладными уровнями Apache и Google, выросли непосредственно из технологий СУБД. Введя специальные инструменты оценки уровней вложенности, для определения избыточности, а также решив проблему оптимальной работы с разреженными данными, эти инструменты существенно увеличили эффективность обработки. Технология Teradata построена на принципах параллельной обработки данных, эффективность которой достигается только при наличии соответствующей структуры базы данных, позволяющей вывить малозависимые логические сущности внутри базы. Фактически данный движок является технологически близким к Hadoop, с использованием HDFS, но с некоторым инструментальным обвесом, позволяющим подкручивать приоритизацию пользовательских запросов и управлять доступом к внешним источникам данных и их предварительной подготовкой.
Для эффективного решения бизнес-задач необходимы сбалансированная работа и хорошо налаженное взаимодействие всех уровней стека технологий, однако сегодня эти уровни существуют самостоятельно. Использование тех или иных инструментов на каждом из уровней накладывает технологические ограничения на применение инструментов следующего слоя. Например, инструменты с открытым кодом требуют, как правило, дополнительных разработок либо оптимизации имеющихся. Однако производители, занимаясь продвижением собственного инструментария и технологий (рис. 2), при построении цельного программно-аппаратного решения для работы с Большими Данными выступают исключительно в интересах собственных разработок. Как следствие, очень трудно получить какую-либо информацию по особенностям взаимодействия технологических инструментов разных уровней стека либо по успешной практике их внедрения. Складывается впечатление, что предлагаемые сегодня решения в области Больших Данных носят фрагментарный характер и не покрывают всего спектра бизнес-задач. Многие коммерческие компании, обладая достаточно эффективным продуктом для одного лишь сегмента стека, выдают его за панацею для решения всех задач, связанных с Большими Данными, предполагая, что возможный частный эффект, полученный при модернизации общей инфраструктуры, позволит хотя бы в какой-то степени достичь обещанной эффективности и оправдать инвестиции клиента. Тем не менее ясно, что, например, пришло время новых СУБД для работы с Большими Данными, а круг бизнес-задач, решаемых традиционными монолитными приложениями, неуклонно сужается.
.png "Рис. 2. Один из вариантов стека технологий для Больших Данных") |
| Рис. 2. Один из вариантов стека технологий для Больших Данных |
По мнению аналитиков KPMG, 75% руководителей испытывают трудности с принятием решений по выбору технологий работы с Большими Данными, хотя 96% признают, что анализ всех имеющихся в их компаниях данных необходим, но сейчас проводится недостаточно эффективно. Одним из препятствий является неспособность определить, какие именно данные необходимо анализировать, — фактически речь идет о смене традиционного представления об основных информационных потоках, использующихся для решения бизнес-задач, и очень немногие менеджеры пока находят в себе силы разорвать шаблоны традиционных подходов. Да и опытные ИТ-специалисты не всегда готовы принять новые алгоритмы, интегрированные в структуру данных, которые основаны на выполнении агрегирования данных непосредственно в массиве данных в памяти, а не посредством вычислительной обработки.
Трансформация традиционных архитектур СУБД от монолитных к многозвенным заставила задуматься об эффективности хранения данных в облаках, однако вскоре оказалось, что наиболее значительные вычислительные ресурсы требуются уже на уровне сбора и предварительной обработки данных (рис. 1), где из многочисленных источников происходит формирование базы, пригодной для анализа на уровне приложения. При этом ресурсоемкие задачи сбора и предобработки не представляют собой привычный непрерывный транзакционный процесс, а могут быть распараллелены и распределены.
Кроме того, с ростом объемов данных увеличивается расстояние между точками их хранения и анализа — ведь до сих пор актуальна задача уменьшения стоимости хранения. Кстати, именно поэтому уже который раз переносится дата кончины ленточных носителей, которые по-прежнему остаются самой дешевой платформой для долгосрочного хранения. Однако для эффективного анализа данные должны быть максимально приближены к процессору. И, как следствие, сегодня возник целый парад архитектурных решений, соревнующихся в эффективности организации иерархии и доставки данных для анализа. В основном это референсные архитектуры, рекомендованные под SAP HANA, Vertica, Greenplum и др. непосредственно производителями оборудования, либо ускорители работы с массивами данных, такие, например, как решения от Violin Memory для флэш-памяти.
Перечисленные факторы не позволяют сегодня хотя бы приблизительно зафиксировать стек технологий для Больших Данных, который находится в состоянии постоянных изменений. Мало того, одной из особенностей использования Больших Данных является отсутствие уверенности в качестве сырых данных — применяемые сегодня специальные процедуры синхронизации и поддержания консистентности образуют чрезвычайно сложный конгломерат, в зависимость от которого нельзя ставить сроки и результаты анализа, но тем не менее необходимо учитывать определенный процент несогласованной информации.
Очень серьезно ситуацию со стеком технологий Больших Данных подогревает направление Smart City, Smarter Plane, которое будет предъявлять совсем иные требования к работе с данными. Так, например, уже сейчас корпорация Coca-Cola зарезервировала 16 млн MAC-адресов для сетевых устройств, отслеживающих движение продукции компании, установив в качестве пилотного проекта более 3500 таких устройств в сети ресторанов Burger King. Это означает, что следующим шагом в развитии аналитических систем, работающих с Большими Данными, будет аналитика реального времени; то есть, не успев стабилизироваться, стек опять будет пересматриваться — к слоям сбора и индексации, предварительного агрегирования информации, а также к средствам визуализации будут предъявляться уже совсем другие требования.
В России одним из основных сдерживающих факторов для развития аналитических систем, базирующихся на технологиях Больших Данных, является неготовность топ-менеджеров привлекать средства аналитики к процессу принятия решений. Тем не менее, согласно опросу KPMG, 85% руководителей задумываются об этом, но испытывают сложности при выборе средств анализа и интерпретации данных и сомневаются в возможностях быстродействия инструментов анализа. Однако и эффективного традиционного инструмента аналитики, даже работающего в режиме реального времени, недостаточно — краеугольным камнем эффективности аналитических систем для Больших Данных становятся методы анализа. Сегодня имеется много специализированных наработок на базе статистических и численных методов анализа финансовой информации, применимых и для задач Больших Данных, но для проблем, связанных с социальными, маркетинговыми и исследовательскими задачами, нужно учитывать еще множество факторов, например региональные особенности экономики и социальных отношений. Для получения качественной и достоверной информации необходимо организовать процедуры ее сбора с учетом лингвистики, геораспределенности, индустриальной специфики и множества других особенностей, ранее либо не попадавших в поле зрения аналитиков, либо скрытых толстым слоем накопленных, но никем не обработанных наблюдений. В этих условиях значимым конкурентным преимуществом становится простота настройки аналитики на предметную область, а также возможность адаптации инструментария к предметной области. Как следствие, преднастроенные экспертами схемы сами по себе будут пользоваться спросом — независимо от инструментария из стека технологий Больших Данных. Они сами будут инструментом, позволяющим применить экспертные знания к существенно большему количеству типовых задач.
***
Современный стек технологий Больших Данных — это пока еще некий инкубатор, из которого впоследствии образуются универсальные или специализированные решения по работе с данными на четырех основных направлениях: работа с большими базами, аналитика реального времени, обработка разнородной информации (структурированной, слабо связанной, неструктурированной), обеспечение непротиворечивости используемых данных.
Дмитрий Семынин (dsemynin@amt.ru) — директор департамента инфраструктуры информационных систем, компания AMT Group (Москва).
