Big Data в Райффайзенбанке

Всем привет!

В этой статье мы расскажем про Big Data в Райффайзенбанке.
Но прежде чем перейти к сути, хотелось бы внести ясность по поводу самого определения Big Data. Действительно, в последние несколько лет этот термин употреблялся во множестве контекстов, что привело к размытию границ самого термина и потере содержательной части. Мы в Райффайзенбанке выделили три направления, которые мы относим к Big Data:

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

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

Для начала пару слов о предпосылках интереса к технологиям. К моменту начала работ по Big Data в банке имелось несколько решений по работе с данными:

• Data Warehouse (DWH, Корпоративное хранилище данных)
• Operational Data Store (ODS, Хранилище операционных данных)

Что заставило нас смотреть в сторону Big Data?

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

На тот момент у DWH и ODS имелись некоторые ограничения, которые не позволяли развивать эти решения в качестве универсальных инструментов для анализа всех данных:

1. Жесткие требования к качеству данных, предъявляемые к DWH, сильно влияют на актуальность данных в хранилище (данные доступны для анализа на следующий день).
2. Отсутствие исторических данных в ODS (по определению).
3. Использование реляционных СУБД в ODS и DWH позволяет работать только со структурированными данными. Необходимость определять модель данных еще при записи в DWH/ODS (Schema on write) влечет дополнительные расходы на разработку.
4. Отсутствие возможности горизонтального масштабирования решения, ограниченность вертикального масштабирования.

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

Мы выбрали второй вариант, т.к. он нам показался более консервативным.

Далее мы пришли к пониманию, что Big Data это всего лишь инструмент, а вариантов решения конкретной задачи с помощью этого инструмента может быть множество.
Решаемая задача предъявляла следующие требования:

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

Изучив литературу, почитав форумы и ознакомившись с доступной информацией, мы обнаружили, что решение, удовлетворяющее этим требованиям, уже существует в виде устоявшегося архитектурного шаблона и называется «Data Lake». Приняв решение о внедрении Data Lake, мы таким образом нацелились получить самодостаточную экосистему «DWH + ODS + Data Lake», способную решать любые задачи, связанные с данными, будь то управленческая отчетность, операционная интеграция или предиктивная аналитика.

Наш вариант Data Lake реализует типичную лямбда-архитектуру, в которой входные данные разделяются на два слоя:

— «быстрый» (speed) слой, в котором обрабатываются, в основном, потоковые данные, объемы данных небольшие, трансформации минимальные, но зато достигается минимальное время задержки (latency) между возникновением события и его отображением в аналитической системе. Для обработки данных мы используем Spark Streaming, а для хранения результата – Hbase.
— «пакетный» (batch) слой, в котором данные обрабатываются пакетами (батчами), которые могут включать несколько миллионов записей сразу (например, балансы по всем счетам по результатам закрытия операционного дня), это может занимать некоторое время, но зато мы можем обработать достаточно большие объемы данных (throughput). Данные в слое batch мы храним в HDFS, а для доступа к ним используем Hive или Spark, в зависимости от задачи.

Отдельно хочется отметить Spark. Мы широко его используем для обработки данных и для нас самые значимые преимущества – следующие:

• Можно использовать в качестве ETL средства.
• Более быстрый, чем стандартные джобы на MapReduce.
• Выше скорость написания кода по сравнению с Hive/ MapReduce, т.к. код получается менее многословный, в том числе за счет DataFrame’ов и библиотеки SparkSQL.
• Более гибкий, поддерживает более сложные пайплайны обработки, чем парадигма MapReduce.
• Поддерживается Python и JVM-языки.
• Встроенная библиотека машинного обучения.

Мы стараемся хранить данные в Data Lake в исходном, «сыром» виде, реализуя подход «schema on read». Для управления процессами в качестве планировщика задач мы используем Oozie.

Структурированные входные данные храним в формате AVRO. Это дает нам преимущества:

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

Для витрин данных, с которыми будут работать пользователи через BI-средства, планируем использовать форматы Parquet или ORC, т.к. это в большинстве случаев позволит ускорить выборку данных за счет колоночного хранения.

В качестве сборки Hadoop рассматривали Cloudera и Hortonworks. выбрали Hortonworks, потому что его дистрибутив не содерджит проприетарных компонентов. К тому же, у Hortonworks из коробки доступна 2-я версия Spark, а у Cloudera – только 1.6.

Среди аналитических приложений, которые используют данные Data Lake, отметим два.

Первое – Jupyter Hub с Python и установленным библиотеками машинного обучения, которое наши Data Scientist’ы используют для предиктивной аналитики и построения моделей.

На роль второго мы сейчас рассматриваем приложение класса Self-Service BI, с помощью которого пользователи самостоятельно смогут подготовить большинство стандартных ретроспективных отчетов – таблицы, графики, круговые диаграммы, гистограммы и т.д. При этом подразумевается, что роль ИТ будет заключаться в том, чтобы добавить данные в Data Lake, предоставить для приложения и пользователей доступ к данным, и … все. Остальное пользователи смогут делать сами, за счет чего, в частности, мы ожидаем уменьшения конечного времени поиска ответов на интересующие вопросы.

В заключение хотелось бы рассказать, чего мы достигли на данный момент:

• Вывели в Прод ветку Batch Layer, грузим данные, которые используются как для ретроспективного анализа (т.е. аналитики с помощью данных пытаются ответить на вопрос «как мы пришлю сюда»), так и предиктивного анализа: ежедневный прогноз на базе машинного обучения спроса на снятие наличных в банкоматах и оптимизация работы службы инкассации.
• Подняли Jupyter Hub, дали пользователям возможность анализировать данные самыми современными инструментами: scikit learn, XGBoost, Vowpal Wabbit.
• Активно разрабатываем и готовимся вывести в Прод ветку «Speed Layer», реализуя на Data Lake систему класса Real Time Decision Making.
• Составили продуктовый бэк-лог, реализация которого позволит наибыстрейшим темпом повысить зрелость решения. В числе запланированного:
  
  1. Катастрофоустойчивость. Сейчас решение развернуто в одном дата центре, и по сути мы не гарантируем непрерывность сервиса, а также можем необратимо потерять накопленные данные, случись что с дата-центром (такая вероятность мала, но все же существует). Мы столкнулись с проблемой: встроенными средствами HDFS нельзя добиться гарантированного хранения данных в разных дата-центрах. Есть доработка на этот счет (https://issues.apache.org/jira/browse/HDFS-5442), ее судьба пока непонятна, планируем реализовывать собственное решение.
  2. Обогащение метаданных (Atlas), Data Management / Governance на основе метаданных, ролевой доступ на основе метаданных.
  3. Исследовать альтернативы выбранным архитектурным компонентам. Первые кандидаты: Airflow как альтернатива Oozie, более продвинутые CDC как альтернатива Scoop для выгрузки данных из реляционных СУБД.
  4. Внедрение конвейера CI/CD. При всем разнообразии используемых технологий и инструментов мы хотим добиться, чтобы любое изменение кода можно было в автоматическом режиме максимально быстро выкатывать в продуктивную среду, и при этом гарантировать качество поставки.

Планов на использование Big Data в Райффайзенбанке еще очень много и мы обязательно расскажем об этом.
Спасибо за внимание!