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

<blockquote>''Журнал [http://www.osp.ru/os/#/home «Открытые системы»] опубликовал статью [[:Категория:Дмитрий Морозов (Статьи)|Дмитрия Морозова]], нашего ведущего специалиста по&nbsp;проектированию ИТ-инфраструктурных решений, посвященную проблеме обработки больших данных и&nbsp;ее&nbsp;решению. Каковы предпосылки возникновения данной проблемы? Каким образом можно разгрузить оперативные&nbsp;БД, не&nbsp;нарушая работу уже&nbsp;существующих учетных систем? В&nbsp;чем заключаются основные преимущества Hadoop-хранилищ по&nbsp;сравнению с&nbsp;операционными&nbsp;БД? Ответы на&nbsp;эти вопросы&nbsp;— в&nbsp;материале [http://www.osp.ru/os/2015/01/13045320/ «Опыт разработки масштабируемого хранилища журналов на&nbsp;технологиях Hadoop»] на&nbsp;сайте и&nbsp;в&nbsp;бумажной версии издания.''</blockquote>

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

В&nbsp;этих условиях все&nbsp;большее распространение постепенно получают технологии хранения и&nbsp;обработки неструктурированных данных Big&nbsp;Data, которые в&nbsp;программе Европейского союза по&nbsp;исследованиям и&nbsp;инновациям «Горизонт&nbsp;2020» (Horizon&nbsp;2020<ref name="footnote_1">[http://ec.europa.eu/programmes/horizon2020/en/home HORIZON 2020: The EU Framework Programme for Research and Innovation]</ref>) названы «топливом для&nbsp;новой цифровой экономики». В&nbsp;той же&nbsp;программе Еврокомиссии прогнозируется, что&nbsp;объем технологий и&nbsp;услуг Big&nbsp;Data во&nbsp;всем&nbsp;мире вырастет в&nbsp;2015&nbsp;году до&nbsp;12,7&nbsp;млрд&nbsp;евро<ref name="footnote_2">[http://ec.europa.eu/programmes/horizon2020/en/h2020-section/content-technologies-and-information-management-0 HORIZON 2020: Content Technologies and Information Management]</ref> (для сравнения: в&nbsp;2010&nbsp;году эта&nbsp;цифра составляла 2,4&nbsp;млрд&nbsp;евро).

Безусловно, работа с&nbsp;такими данными с&nbsp;каждым годом открывает все&nbsp;больше возможностей для&nbsp;бизнеса. Основными потребителями, заинтересованными во&nbsp;внедрении и&nbsp;развитии инструментов обработки больших данных, являются телеком-операторы, различные интернет-компании, представители сферы ритейла и&nbsp;банковского сектора. Эти&nbsp;компании получают огромные возможности собирать и&nbsp;анализировать данные о&nbsp;своих текущих и&nbsp;потенциальных клиентах, следить за&nbsp;их&nbsp;предпочтениями и&nbsp;адаптироваться к&nbsp;их&nbsp;новым потребностям. Лидеры рынков уже&nbsp;проявляют активный интерес к&nbsp;этим возможностям. Так, на&nbsp;начало 2014&nbsp;года 17&nbsp;из&nbsp;30&nbsp;крупнейших по&nbsp;чистым активам банков либо уже&nbsp;использовали, либо&nbsp;планировали внедрить технологии Big&nbsp;Data<ref name="footnote_3">[http://www.cnews.ru/top/2014/01/30/10_rossiyskih_bankov_iz_top30_ispolzuyut_tehnologii_big_data_558490 CNews Analytics: 10 российских банков из топ-30 используют технологии Big Data]</ref> (в&nbsp;том&nbsp;числе Сбербанк, Газпромбанк, ВТБ24, Райффайзенбанк и&nbsp;другие). В&nbsp;ближайшее время использование этих технологий станет определяющим фактором конкурентного преимущества и&nbsp;в&nbsp;ритейле.

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

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

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

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

=== Когда и&nbsp;какие данные переносить ===

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


[[Image:Рис. 1. Модель жизненного цикла данных.jpg|thumb|450px|center|<center>'''Рис. 1.''' Модель жизненного цикла данных</center>]]


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

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

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

=== Технологии и&nbsp;архитектура решения ===

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

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


[[Image:Рис. 2. Общая схема решения.jpg|thumb|450px|center|<center>'''Рис. 2.''' Общая схема решения</center>]] 


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

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


[[Image:Рис. 3. Внутренняя архитектура хранилища журналов.jpg|thumb|800px|center|<center>'''Рис. 3.''' Внутренняя архитектура хранилища журналов</center>]]


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

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

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

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

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

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

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

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

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

=== Результаты ===

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

[[Категория:Дмитрий Морозов (Статьи)]]
[[Категория:Открытые системы (Публикации)]]
[[Категория:2015 год (Статьи)]]

{{replicate-from-custiswiki-to-lib}}