Мы всегда стремимся идти по пути снижения затрат на ИТ-инфраструктуру, это один из важных критериев выбора технологии наряду с производительностью и функциональными возможностями. Не секрет, что для хранения данных в рамках концепции Big Data используется кластерная организация серверов. Наш банк в этом плане не был исключением, мы также строили кластер с небольшим дополнением.
Основная идея заключалась в применении для построения кластера доступных и широко распространенных серверных технологий, чтобы в случае поломки одного компонента его можно было бы легко заменить другим. Мы воспользовались стандартными серверами компании HP семейства Proliant восьмого поколения. Каждый такой сервер (всего их пять) содержит 16 ядер, что позволяет получить на выходе при сравнительно небольших затратах до 80 ядер. При параллельной обработке этого более чем достаточно для высокоэффективной обработки до 50 Tб данных. Самое главное – при необходимости такая схема легко масштабируется до шести-семи узлов в кластере.
Дополнительно была организована виртуальная ферма для кластера резервирования и кластера тестовых данных. В результате были получены наиболее мощные кластеры в России при сравнительно невысоких затратах. Сама архитектура кластера типовая: мастер-узел, который управляет нагрузкой, дочерние узлы, выполняющие задачи, и т. д.
Конечно, при построении кластера мы столкнулись со спецификой работы с большими данными, и нам пришлось пересмотреть подход к организации данных. Построить кластер на «железе» – это еще не все, важно заставить его быть высокопроизводительным, а здесь все немного сложнее.
Идея технологии MPP (Massive Parallel Processing), которую мы использовали, состоит в том, что каждый узел кластера (Node) имеет свою базу для хранения данных. Все эти базы виртуально собираются в один кластер данных, который физически распределен по многим машинам. Конечно, изначально хотелось пойти по пути типичных реляционных СУБД и создать одну большую базу, а распределительные мощности рассредоточить между серверами, но это было бы неправильно исходя из самой парадигмы MPP, суть которой заключается не только в физическом построении кластера, но и в виртуальной сегментации данных. В теории MPP это означает корректное и взвешенное распределение данных между узлами кластера, что практически является искусством. Например, в банке есть база кредитных заявок из нескольких миллионов, необходимо посчитать в режиме онлайн уровень одобрения (Approval Rate). Как ее правильно распределить по кластеру, чтобы производительность его была максимальной, т. е. каждый узел кластер был загружен в равной степени? Для распределения используются аналитические разрезы наших фактических данных. Можно задействовать любой разрез, но не каждый из них обеспечит эффективное распределение нагрузки. Скажем, если делить данные заявок по признаку «мужчина»/«женщина», то данные можно разделить только на два узла кластера, остальные будут простаивать при вычислениях, если узлов у вас пять.
В банках основными данными, о которых можно говорить, что они относятся к Big Data, являются проводки, платежные документы, заявки на банковские продукты, истории обращений клиентов и карточные транзакции. Анализ последних – наверное, одна из сложнейших процедур, поскольку требует аудита безопасности и соблюдения норм PCI DSS. Следует отметить, что здесь нет какой-то однозначной «золотой формулы», говорящей вам «используйте всегда этот атрибут для сегментации данных», ведь заявки распределяются эффективно по одному признаку, а карточные транзакции – по другому. Для каждого набора данных условия распределения разные. В конечном итоге все это превращается в некую алхимию цифр и переменных, которая решается подбором компонентов.
Архитектура типичного кластера больших данных – это фактически обычный вычислительный кластер, содержащий следующие компоненты:
- узлы кластера, которые хранят данные и выполняют вычисления;
- Downstream сервера – хосты, необходимые для организации загрузки потоков данных в онлайн через различные механизмы захвата изменений (Change Data Capture – CDC), например, какой-нибудь log miner, который изучает логии транзакций реляционных СУБД;
- узлы резервной копии на случай падения одного из боевых узлов;
- средства репликации узлов и автоматической балансировки между боевой версией и резервной.
Строим с нуля инфраструктуру под большие данные
При построении Big Data-инфраструктуры с нуля следует помнить, что четкой и прямой связи между дорогим «железом» и высокопроизводительной средой нет. Во Всемирной сети можно найти примеры построения вычислительных кластеров до 40 узлов на базе простейших вычислительных машин Raspberry PI. Многие кампусы для анализа погодных данных и других больших массивов информации строят самодельные мейнфреймы из узлов, стоимость каждого из которых не превышает 40 долл. Поэтому при создании инфраструктуры важно переключиться с «железа» на анализ самих данных, которые вы планируете изучать. Каждые данные имеют свою специфику: банковские проводки имеют структурированный формат, заявки на кредит – во многом неструктурированный формат и большое количество текстовых полей.
Особо стоит отметить принятие решения по оптимальному выбору системы хранения данных (СХД), ведь от скорости обращения к данным зависит очень многое. В нашем банке были довольно бурные дискуссии по этому вопросу, тем более что мы сотрудничаем с несколькими вендорами, и каждый из них имеет свою специфику.
Мой совет: после первых набросков концептуальной архитектуры и инфраструктурной диаграммы не торопитесь внедрять ее, попробуйте оптимизировать – исключить дублирующие элементы, где-то упростить. Как говорится, семь раз отмерь, один раз отрежь.
Модернизация того, что есть
При таком подходе к организации инфраструктуры для больших данных важно соблюдать следующий принцип: все узлы кластера должны быть идентичными в части «железа» и компонентов. Если каждый узел уникален, то достаточно сложно организовывать распределенные вычисления и строить резервный контур (Disaster Recovery). Некоторые опции, имеющие отношение к «горячему» резерву и времени восстановления, связаны с идентичным «железом». Например, при создании резерва автоматизированной банковской системы (АБС) важно строить его на аналогичной основной АБС аппаратной части, как следствие, цена инфраструктуры возрастает в два раза. С технологиями больших данных ситуация такая же, поэтому начинать нужно с определения того, насколько однородное «железо» используется для организации кластера, и, если аппаратная часть неоднородна, оценить, во что обойдется закупка однородной.
Второй принцип, который следует соблюдать: нет смысла строить кластер на Nod’ах, если стоимость каждого превышает 100 тыс. долл., а цена самого кластера достигает миллиона долларов. С учетом того, что предстоит строить резервный кластер и кластер для тестирования, все это может вылиться в достаточно ощутимую сумму.
Третий принцип: «золотого правила» для выбора атомарного кластера по мощности не существует. У многих интернет-гигантов вычислительные кластеры достигают десятков тысяч Nod, но при этом каждая Nod может быть не более двух ядер и восьми гигабайт оперативной памяти.
Четвертый принцип: не ориентируйтесь на какой-то один конкретный опыт. Создание инфраструктуры больших данных – само по себе эксперимент, поэтому не нужно бояться собирать обратную связь и при необходимости оперативно перестраивать архитектуру.
Наконец, пятый принцип: рассчитывайте на размер данных, который минимум в пять раз превышает имеющийся у вас. Скорость прироста данных такова, что спроектированной архитектуры хватает максимум на полгода, поэтому нужно с самого начала учитывать возможности ее масштабирования.
