Отказоустойчивый кластер хранилища данных для аналитических запросов в банковской сфере

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

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

Эффективные процессы принятия решений в бизнесе зависят от качественной информации. В современной конкурентной бизнес-среде требуется гибкий доступ к хранилищу данных, организованному таким образом, чтобы повысить производительность бизнеса, обеспечить быстрое, точное и актуальное понимание данных. Архитектура хранилища данных разработана для удовлетворения подобных требований и является основой этих процессов [1–5].

Цель работы — определение приоритетной СУБД для выполнения аналитических запросов в банковской сфере и проектирование отказоустойчивого кластера хранилища данных. Данное решение существенно повысит скорость выполнения аналитических запросов, решит проблемы с масштабируемостью и надежностью хранилища данных.

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

Хранилище данных (Data warehouse) — это система, которая собирает данные из множества различных источников внутри организации для составления отчетов и анализа, используя оперативную аналитическую обработку (OLAP) для быстрого анализа больших объемов данных. Данная система сосредоточена на чтении, а не на изменении исторических данных из множества различных источников, поэтому соблюдение требований ACID (Atomic, Consistent, Isolated and Durable) менее строгое. Хранилища данных выполняют сложные функции агрегирования, анализа и сравнения данных для поддержки принятия управленческих решений в компаниях.

Хранилище в банковской сфере может содержать:

• учетную информацию о клиентах (персональные данные, адреса, телефоны);
• информацию о банковских продуктах и услугах (кредиты, депозиты, пластиковые карточки, мобильный банк и т. д.);
• данные об операциях (включая карточные) в минимальной детализации за последние 3 года;
• сведения о счетах, остатках на них и т.д.

Для удовлетворения потребностей в онлайн-аналитической обработке запросов (OLAP) существуют отдельные типы систем управления базами данных (СУБД) [3–6]. Каждая из систем имеет свои особенности в построении архитектуры.

Для проведения эффективного анализа соответствия указанным требованиям хранилища должны:

• обладать высокой вместимостью, способной вместить огромные объемы данных (миллиарды или триллионы строк);
• быть организованы в виде широких таблиц с множеством столбцов;
• выполнять запросы с небольшим количеством столбцов;
• иметь высокую скорость выполнения запросов (в миллисекундах или секундах);
• предусматривать большую часть запросов только на чтение;
• поддерживать быструю массовую загрузку данных при их обновлении (более 1000 строк за раз) и добавлении, но без их изменения;
• обладать высокой пропускной способностью для обработки одного запроса (до миллиардов строк);
• обладать высокой надежностью;
• обеспечивать безопасность и консистентность данных.

Для OLAP-сценария работы в банковской сфере предпочтительнее использовать колоночные аналитические СУБД, поскольку в них можно хранить много столбцов в таблице, что не будет сказываться на скорости чтения данных. Колоночные СУБД обеспечивают сильное сжатие данных в столбцах, так как в одной колонке таблицы данные, как правило, однотипные, чего не скажешь о строке. Они также позволяют на более маломощном оборудовании получить прирост скорости выполнения запросов в десятки раз. При этом, благодаря компрессии, данные будут занимать на диске в 5–10 раз меньше места, чем в случае с традиционными СУБД [7–11].

В ходе анализа требований выбраны следующие колоночные СУБД: ClickHouse, Vertica, Amazon Redshift. ClickHouse является предпочтительным решением из-за следующих преимуществ: открытый исходный код; есть возможность определять некоторые или все структуры, которые будут храниться только в памяти; высокая скорость работы; хорошая степень сжатия данных; http и интерфейс командной строки; кластер можно горизонтально масштабировать; высокая доступность; легкость установки и настройки. Установка осуществляется на серверах организации в изолированном сегменте, что отвечает требованиям безопасности для чувствительных данных в банковской сфере. Также СУБД включена в реестр отечественного программного обеспечения, поэтому позволяет внедрять данный программный продукт в государственные компании.

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

Vertica является альтернативным вариантом ClickHouse с платной лицензией для крупных кластеров и возможностью установки на локальные серверы компании.

Ниже представлена реализация архитектуры распределенного хранилища данных. Для повышения отказоустойчивости и производительности предлагается реализация распределенного отказоустойчивого кластера ClickHouse с 3 шардами и 2 репликами.

Шардинг (горизонтальное масштабирование) позволяет записывать и хранить части данных в распределенном кластере, обрабатывать и считывать их параллельно на всех нодах кластера, увеличивая пропускную способность данных.

Репликация — копирование данных на несколько серверов, поэтому каждый бит данных можно найти на нескольких нодах.

Масштабируемость определяется шардированием или сегментацией данных. Надежность хранилища данных определяется репликацией данных [12–16].

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

В зависимости от количества доступных ресурсов и серверов, предлагается реализовать эту конфигурацию на 3 или 6 нодах. Для производственной среды рекомендуется использовать кластер из 6 нод. Следует отметить, что репликация не зависит от механизмов шардирования и работает на уровне отдельных таблиц, а также, поскольку коэффициент репликации равен 2, то каждый шард представлен в 2 нодах [17–19]. Ниже описаны варианты конфигурации.

Схема логической топологии выглядит следующим образом:

3(Шард) × 2(Реплики) = Кластер Clickhouse из 6-ти нод.

Вероятность безотказной работы системы с 2 репликами и 3 шардами на 6 нодах равна:

𝑃с = [ 1 − (1 − 𝑝)² ]³.

Вероятность безотказной работы — это объективная возможность того, что система без восстановлений проработает время t [7][13].

Таким образом, таблица, содержащая 30 миллионов строк, будет распределена равномерно на 3 ноды кластера. Остальные 3 ноды будут хранить реплики данных. При выводе из строя одной из нод кластера, данные будут браться из другой доступной ноды, которая содержит ее реплику, тем самым достигается надежность [20]. Кластер из 6 нод изображен на рис. 1.

Для репликации данных и выполнения распределенных DDL запросов необходимо использовать +1 ноду с установленным ZooKeeper. Можно использовать также ClickHouse Keeper, совместимый с ZooKeeper, не требующий установки на отдельном сервере.

Пример фрагмента конфигурационного файла представлен на рис. 2, из которого видно, что шарде настроена репликация для 1-ой и 6-ой ноды.

Вариант конфигурации кластера из трех нод с цикличной репликацией изображен на рис. 3.

Для такой реализации требуется два разных сегмента, расположенных на каждой ноде. Основная проблема возникает из-за того, что каждый шард имеет одинаковое имя таблицы, ClickHouse не может отличить один шард/реплику от другого, когда они расположены на одном сервере.

Для решения данной проблемы необходимо:

• поместить каждый шард в отдельную базу данных (схему);
• установить default_database для каждого шарда;
• установить параметр internal_replication каждого шарда в true;
• использовать пустой параметр базы данных в сценарии DDL распределенной таблицы.

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

Автоматизация выполнена с помощью Ansible Playbooks и интегрирована с системой управления версиями Gitlab. Таким образом достигается быстрое развертывание конфигурации на всех нодах кластера. При изменении конфигурации ее можно применить на всех нодах с помощью одной команды или развернуть новый кластер СУБД за несколько минут [21].

Результаты исследования. Отказоустойчивый кластер аналитической СУБД обеспечивает резервирование для важных компонентов системы, что позволяет продолжительно функционировать даже в случае возникновения ошибок в отдельных узлах кластера. Это делается за счет распределения нагрузки, репликации данных между узлами кластера и высокой надежности компонентов, используемых в кластере. Результатом является увеличение доступности и надежности аналитической СУБД, что важно для бизнеса, в котором аналитические запросы играют ключевую роль. Отказоустойчивая кластерная конфигурация хранилища данных для аналитических запросов в банковской сфере с учетом автоматизации процесса разворачивания позволяет повысить надежность аналитического хранилища данных и удовлетворить требования к масштабируемости. Разработанная задача по автоматизации развертывания кластера с использованием механизма шаблонизации конфигурационных файлов в Ansible Playbooks позволяет настроить готовый кластер на новых серверах за несколько минут. В задачи шаблона входят операции по установке необходимых пакетов, созданию необходимой конфигурации и запуску кластера.

Пример конфигурационных файлов для автоматического развертывания кластера СУБД приведен на рис. 4. Расширение j2 говорит о том, что они созданы с помощью механизма шаблонов Jinja. Специальные заполнители в шаблоне позволяют писать код, аналогичный синтаксису Python. В шаблон передаются параметры для автоматической вставки в финальный документ, тем самым достигается автоматическая сборка в зоны разработки, тестирования и промышленной эксплуатации, которая не требует ручного изменения файлов конфигурации.

Описание конфигурационных файлов:

• clickhouse_config.xml.j2 — общая конфигурация кластера;
• clickhouse_keeper.xml.j2 — конфигурация zookeeper, которая отвечает за синхронизацию нод и репликацию;
• clickhouse_ldap_auth.xml.j2 — конфигурация подключения к LDAP для обеспечения безопасности данных;
• clickhouse_ldap_user_directory.xml.j2 — конфигурация с ролевой моделью по группам доступа для обеспечения безопасности данных;
• clickhouse_macro_n1(6).xml.j2 — файлы макросов (для каждой ноды свой);
• clickhouse_users.xml.j2 — конфигурационный файл создания локальных пользователей, необходимых для администрирования;
• cluster.xml.j2 — конфигурационный файл кластера.

Для проверки надежности данной конфигурации проведен эксперимент, в ходе которого были загружены данные в кластер СУБД с коэффициентом репликации, равным 2. Созданы схемы dwh и таблицы cluster_test_data на каждой из нод кластера СУБД, а также создана распределенная таблица на кластере dwh.cluster_test_ data_ distributed. Строки таблицы dwh.test_ data_ distributed, распределенной по кластеру, равны 27 547 855. Ниже перечислены строки таблицы dwh.cluster_test_ data с каждой из нод кластера:

• 9186544 строк — 1-ая нода;
• 9182959 строк — 2-ая нода;
• 9182959 строк — 3-я нода;
• 9178352 строк — 4-ая нода;
• 9178352 строк — 5-ая нода;
• 9186544 строк — 6-ая нода.

Как можно заметить, таблица распределилась на весь кластер. Согласно конфигурации, приведенной на рис. 1, коэффициент репликации равен 2, значит, каждый блок данных будет представлен на 2 нодах. Это можно увидеть из количества строк на нодах: шестая нода хранит копию первой, третья — копию второй, пятая — копию четвертой.

Отказоустойчивость данной конфигурации можно проверить попеременным выводом из строя нод в кластере. Для этого можно выключить ноду или остановить сервисы на одной из нод командой systemctl stop clickhouse-server. В ходе эксперимента была выполнена остановка сервисов СУБД на нодах кластера.

При одновременном отключении 3, 4, 6-ой или 1, 2, 5-ой нод, которые содержат реплики, пользователи продолжали получать данные из таблицы dwh.cluster_test_ data_ distributed, и количество строк было равным 27 547 855. При выводе из строя одной из нод, данные продолжали отображаться, а количество строк было равным 27 547 855. При одновременном отключении нод, которые содержат реплику и оригинальные данные, происходила потеря данных. Данную конфигурацию можно масштабировать на 12 нод, тогда коэффициент репликации будет равен 3, а коэффициент шардирования — 6.

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

Обозначен набор характеристик, которым должна соответствовать OLAP СУБД, выполнено сравнение СУБД, предложена отказоустойчивая кластерная конфигурация хранилища данных для аналитических запросов в банковской сфере, выполнена автоматизация процесса разворачивания конфигурации. Подобное решение применимо для развертывания на FreeBSD, Linux, macOS. Приведены схемы конфигурации кластера. Данная конфигурация решит проблему, связанную с надежностью и масштабируемостью, которая часто встречается в организациях.