Объемы данных увеличиваются в геометрической прогрессии, перевалив в 2010 году за отметку один зеттабайт, причем в основном благодаря неструктурированным данным, образующим основную массу Больших Данных [1]. Неудивительно, что рынок технологий Больших Данных к 2015 году только в Европе вырос до 12,7 млрд евро, увеличившись в пять раз по сравнению с 2010 годом. На начало 2014 года 17 из 30 крупнейших российских банков либо уже использовали, либо планировали внедрить технологии работы с Большими Данными (в том числе Сбербанк, «Газпромбанк», ВТБ24 и др.). Кроме того, аналитики отмечают, что сегодня наметилась тенденция к «бессознательному накоплению данных» — многие компании чувствуют потенциал анализа собранных данных, но еще не знают, как именно и когда они будут его применять, собирая пока неструктурированные сведения «про запас».

Развитие средств обработки Больших Данных в крупных компаниях сдерживается и-за сложности самих данных — ИТ-системы крупных компаний зачастую представляют собой конгломерат разных решений, работающих каждое в своей логике и использующих высоконагруженные базы данных, значительная часть объемов которых приходится на так называемые журналы. Основу журналов составляют однажды записанные данные, которые в дальнейшем используются только для чтения (например, журналы транзакций и др.), не подвергаясь изменениям. Это усложняет администрирование оперативных баз данных и требует все больше времени для резервного копирования, отвлекая на него те же мощности, что и для оперативных баз. Экономически нецелесообразно применять дорогие хранилища для операций с практически необрабатываемыми данными. К тому же информацию из журналов, хранящихся в оперативных базах, невозможно использовать для анализа — базы обычно перегружены оперативными задачами, а держать ресурсы «про запас» слишком затратно.

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

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

В оперативных базах все данные на всех этапах жизненного цикла хранятся вместе, однако информацию из аналитического и архивного контуров можно перенести в отдельное хранилище. Но как определить, какую информацию можно безболезненно переместить? В дополнение к требованию отдельного хранения журналов добавляются требования масштабируемости (объемы журналов постоянно растут, а если их регулярно удалять, то нельзя будет воспользоваться ими для дальнейшего анализа) и необходимости предусмотреть оптимизацию для чтения, поиска и аналитики.

Для отдельного размещения журналов можно использовать разделы в рамках одного экземпляра базы, создавать отдельный экземпляр базы или применить распределенное хранилище, например распределенную открытую систему поиска ElasticSearch (github.com/elasticsearch/elasticsearch). Первые два варианта проигрывают по стоимости хранения и масштабируемости, а распределенное хранилище имеет ограниченные возможности по дальнейшему анализу данных. Оптимальным вариантом может стать хранилище, построенное на системах из экосистемы Hadoop, которые изначально создавались для масштабируемых отказоустойчивых решений на дешевом массовом оборудовании и обладают богатыми возможностями анализа данных.

Обычно такие системы, как ERP или CRM, хранят журналы либо в своих базах, либо в файлах на дисках и предоставляют интерфейсы чтения журналов. Если сразу помещать журналы в Hadoop-хранилище, то нарушится логика работы автоматизированных систем и потребуется вносить изменения в код, что нежелательно, поэтому предлагается добавить отдельное хранилище журналов для их архивирования в операционной базе данных (рис. 1).

 

Рис. 1. Общая схема решения
Рис. 1. Общая схема решения

 

Для сохранения привычной логики данные журналов на оперативном и отчетном контурах следует размещать в исходных местах хранения, а когда данные переходят в аналитический и архивный контуры, то помещать их в хранилище журналов. После выхода из оперативного и отчетного контура данные журналов (с проверкой, что они уже перенесены в хранилище) удаляются в исходном месте своего размещения.

Помимо продуктов Hadoop, в архитектуре решения имеются сервисы доступа к журналам хранилища и очистки журналов (рис. 2). Первый позволяет изменять логику работы хранилища и незаметно для пользователей менять его компоненты (например, Hive может быть заменен на Impala [2], что позволяет также не зависеть от версии Hadoop). Второй удаляет из операционных баз журналы после того, как они помещены в хранилище.

 

Рис. 2. Архитектура хранилища журналов
Рис. 2. Архитектура хранилища журналов

 

Для импорта данных из файловых журналов предназначен распределенный сервис Hadoop Flume. Он осуществляет сбор и передачу больших объемов данных, отслеживает появление новых файлов журналов и помещает их в распределенную файловую систему HDFS. Для переноса журналов из реляционных СУБД (в первую очередь из Oracle) используется сервис Sqoop, который инкрементально переносит данные в NoSQL-базу данных HBase, в SQL-базы данных Hive/Impala и в сервис индексации Apache Solr (lucene.apache.org/solr). Все эти сервисы хранят данные в HDFS.

HBase используется для хранения XML-сообщений, которые размещались в реляционной таблице в текстовой колонке, и для них требуется только доступ по ключу. Если нужно выполнять более сложные запросы (например, выборку инцидентов по критериям за указанный промежуток времени), то лучше использовать базу данных Impala или Hive. Последняя работает через MapReduce-задачи и хранит промежуточные результаты в HDFS. Лучшие результаты по быстродействию демонстрирует Impala, использующая свой механизм и хранящая промежуточные данные в оперативной памяти. Для данных, требующих быстрого поиска (например, по всем колонкам таблицы), больше подходит сервис индексации для Hadoop Apache Solr.

Для управления компонентами решения используются сервис запуска задач Oozie, сервис конфигурирования кластера ZooKeeper и сервис администрирования кластера ClouderaManager (www.cloudera.com/content/cloudera/en/products-and-services/cdh/impala.html).

При таком сценарии выбора записи из журнала по идентификатору автоматизированная система сначала пытается найти запись из операционной базы данных, а затем из хранилища, что полностью прозрачно для пользователя. Для сценария поиска такой подход неэффективен, и в интерфейсе пользователю предлагается вести поиск отдельно в хранилище или в операционной базе.

***

Практически все средние и крупные компании, в которых ведется учет и установлено несколько учетных систем (банки, ретейлеры или интернет-компании), сталкиваются с проблемой хранения и обработки файлов логов, журналов учета. Их объем может достигать 1 Тбайт в день. Однако такие данные требуется хранить в соответствии с нормативными документами, и при этом они являются кладезем с точки зрения анализа. Решение по переносу журналов в Hadoop-хранилище значительно сокращает стоимость хранения, а благодаря уменьшению объемов оперативных баз упрощаются задачи администрирования и создания резервных копий. Кроме того, стоимость Hadoop-хранилища, построенного на недорогом массовом оборудовании, в среднем втрое меньше стомости хранилища для операционной базы данных, а для пользователей ничего не меняется — существующие интерфейс и функционал автоматизированных систем сохраняются. Мало того — информация, которая раньше считалась обузой, теперь сможет применяться для анализа данных в интересах бизнеса.

Литература

  1. Наталья Дубова. Большие Данные крупным планом // Открытые системы.СУБД. — 2011. — № 10. — С. 30–33. URL: http://www.osp.ru/os/2011/10/13012225 (дата обращения 20.3.2015).
  2. Андрей Николаенко. Год облачных СУБД // Открытые системы.СУБД. — 2013. — № 9. — С. 42–47. URL: http://www.osp.ru/os/2013/09/13038286 (дата обращения 20.3.2015).

Дмитрий Морозов (morozov@custis.ru) — ведущий специалист по проектированию ИТ-инфраструктурных решений, группа компаний CUSTIS (Москва). Статья подготовлена на основе материалов доклада, представленного на семинаре «Hadoop на практике. Новые инструменты и проекты».