Опыт разработки масштабируемого решения по хранению журналов в Hadoop

Журнал «Открытые системы» опубликовал статью Дмитрия Морозова, нашего ведущего специалиста по проектированию ИТ-инфраструктурных решений, посвященную проблеме обработки больших данных и ее решению. Каковы предпосылки возникновения данной проблемы? Каким образом можно разгрузить оперативные БД, не нарушая работу уже существующих учетных систем? В чем заключаются основные преимущества Hadoop-хранилищ по сравнению с операционными БД? Ответы на эти вопросы — в материале «Опыт разработки масштабируемого хранилища журналов на технологиях Hadoop» на сайте и в бумажной версии издания.

Проблематика и предпосылки

Сегодня информация накапливается в геометрической прогрессии — объемы данных десятикратно увеличиваются примерно каждые пять лет. Неким рубежом стал 2010 год, когда объем данных перевалил за отметку 1 зеттабайт (1 Зб примерно равен 1 млн Тб). А по данным IDC, до 2020 года эта цифра увеличится до 35 зеттабайт.

В этих условиях все большее распространение постепенно получают технологии хранения и обработки неструктурированных данных Big Data, которые в программе Европейского союза по исследованиям и инновациям «Горизонт 2020» (Horizon 2020) названы «топливом для новой цифровой экономики». В той же программе Еврокомиссии прогнозируется, что объем технологий и услуг Big Data во всем мире вырастет в 2015 году до 12,7 млрд евро (для сравнения: в 2010 году эта цифра составляла 2,4 млрд евро).

Безусловно, работа с такими данными с каждым годом открывает все больше возможностей для бизнеса. Основными потребителями, заинтересованными во внедрении и развитии инструментов обработки больших данных, являются телеком-операторы, различные интернет-компании, представители сферы ритейла и банковского сектора. Эти компании получают огромные возможности собирать и анализировать данные о своих текущих и потенциальных клиентах, следить за их предпочтениями и адаптироваться к их новым потребностям. Лидеры рынков уже проявляют активный интерес к этим возможностям. Так, на начало 2014 года 17 из 30 крупнейших по чистым активам банков либо уже использовали, либо планировали внедрить технологии Big Data (в том числе Сбербанк, Газпромбанк, ВТБ24, Райффайзенбанк и другие). В ближайшее время использование этих технологий станет определяющим фактором конкурентного преимущества и в ритейле.

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

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

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

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

Когда и какие данные переносить

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

Рис. 1. Модель жизненного цикла данных

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

Для этого формализуем понятие «журнал»: будем считать журналами информацию, вносящую существенный вклад в объем БД, создающую большой поток данных и доступную только для чтения. Для такой информации в дополнение к отдельному хранению добавляются требования по масштабируемости (объемы журналов постоянно растут, можно, конечно, их регулярно удалять — но тогда нельзя будет использовать их для дальнейшего анализа с помощью технологий Big Data) и необходимость предусмотреть оптимизацию на чтение, поиск и аналитику.

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

Технологии и архитектура решения

Вариантов для размещения журналов достаточно: можно использовать партиционирование в рамках того же экземпляра БД, отдельный экземпляр БД или применить распределенное хранилище, например, ElasticSearch. Первые варианты проигрывают по стоимости хранения и масштабируемости, а распределенное хранилище — по возможностям дальнейшего анализа данных. Оптимальным решением представляется хранилище, построенное на продуктах экосистемы Hadoop. Они изначально создавались для масштабируемых отказоустойчивых решений на дешевом массовом оборудовании и обладают богатыми возможностями ad hoc анализа данных собственными инструментами.

На начальный момент большинство автоматизированных систем (АС), которые планируется разгрузить нашим решением, сохраняют журналы либо в базах данных, либо в файлах на дисках и имеют интерфейсы чтения журналов. В проектируемом решении предлагается сохранить данную логику работы систем, добавив хранилище журналов. В него будет архивироваться информация из файлов и журналов в операционной БД (рис. 2). Если осуществлять сохранение журналов сразу в Hadoop-хранилище, то нарушится логика работы автоматизированных систем и потребуется вносить изменения в их код. Учитывая размер инфраструктуры компании (мы ориентируемся на крупные организации в банковской или торговой сфере), стоимость внесения изменений в логику работы бизнес-приложений может превзойти выгоды от внедрения хранилища. Кроме того, в этом случае изменилось бы поведение АС для пользователей и возникли бы риски нестабильной работы. Более того, для систем с истекшим сроком поддержки использование хранилища было бы вообще невозможным.

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

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

Рассмотрим, как описанную выше логику можно реализовать, используя продукты Hadoop (рис. 3). Как известно, экосистема Hadoop живет, меняется, развивается, продукты находятся на различных этапах жизненного цикла. Этот факт необходимо учитывать в решении, принимая во внимание, что компоненты хранилища могут с течением времени изменяться.

Рис. 3. Внутренняя архитектура хранилища журналов

Помимо продуктов Hadoop, в архитектуру решения включены два собственных сервиса. Для создания интерфейса чтения из АС предлагается использовать разработанный на Java сервис доступа к журналам хранилища. Он позволяет изменять логику работы хранилища и менять его компоненты (например, Hive может быть заменен на Impala) незаметно для пользователей, а также не зависеть от версии Hadoop.

Для импорта данных из файловых журналов используется Flume. Он настроен на отслеживание появления новых файлов журналов и помещение их в распределенную файловую систему HDFS. Для переноса журналов из реляционных СУБД (в первую очередь, из Oracle DB) используется сервис Sqoop, который инкрементально переносит данные через Keyvalue БД Hbase, Fullscan БД Impala, сервис индексации Solr в HDFS.

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

Для управления компонентами решения используются сервис запуска задач Oozie, сервис конфигурирования кластера ZooKeeper и сервис администрирования кластера ClouderaManager.

Что изменилось в автоматизированных системах? Теперь в сценарии выбора записи из журнала по идентификатору система сначала пытается найти запись из операционной БД, затем из хранилища, и это полностью прозрачно для пользователя. Для сценария поиска такой подход неэффективен, поэтому в интерфейсе пользователю предлагается выбор: или искать отдельно в хранилище, или в операционной БД (в виде нового флажка «Искать в архиве» на форме поиска данных в журнале). Это единственное изменение интерфейса для пользователя АС.

Сравнительный анализ стоимости

Попробуем сравнить стоимость хранения данных в операционной БД и в Hadoop-хранилище. Для примера рассмотрим хранение 10 Тб данных. Дисковая полка СХД среднего уровня (вместе с коммутаторами) стоит порядка 3 млн рублей. Это около 50 Тб SATA-дисков (то есть 600 тыс. рублей за 10 Тб) или 15 Тб SAS-дисков (то есть 2 млн рублей за 10 Тб). Более быстрые решения на SSD, FlashCache и тому подобных технологиях рассматривать не будем, поскольку они еще дороже.

Для создания хранилища на HDFS на 10 Тб потребуется как минимум 4 простых сервера с 10 Тб обычных дисков в каждом (по цене порядка 50 тыс. рублей). То есть хранение 10 Тб будет стоить порядка 200 тыс. рублей. Притом, как мы помним, это оборудование будет использоваться и для хранения, и вычислений и анализа данных.

Как видим, разница в стоимости — минимум в три раза. А с учетом того, что высоконагруженные операционные БД в большинстве случаев не создаются на SATA-дисках, то и в десять раз.

Результаты

Таким образом, решение по переносу журналов в хранилище на основе Hadoop значительно сокращает стоимость хранения данных. Благодаря уменьшению объемов оперативных БД упрощаются задачи администрирования, сокращается время создания резервных копий. В то же время для пользователей ничего не меняется — существующие интерфейс и функционал автоматизированных систем полностью сохраняются. Но самое главное, информация, которая раньше считалась обузой, теперь сможет применяться при анализе больших данных в интересах бизнеса.

---

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