В предыдущей статье я поделился нашим опытом создания аналитического хранилища полного цикла на базе экосистемы Hadoop. Одним из тезисов той статьи стало утверждение о том, что аналитическую систему можно спроектировать, не прибегая к федерализации разных технологических платформ, предназначенных для решения локальных задач.
В этом материале я попробую подробнее раскрыть, как в нашей системе реализован подход обработки и загрузки данных в реальном времени с использованием технологии Kudu, при котором эти данные сразу доступны для анализа.
Решаемая задача
Для начала давайте немного поговорим о задаче, для которой потребовалось такое решение. Любая современная организация, оказывающая клиентские услуги, имеет собственную программу лояльности. Как правило клиент получает всевозможные скидки, бонусы или бесплатное обслуживание по определенному продукту или категории продуктов при выполнении ряда условий. Примерами таких условий могут быть:
Оборот по карте;
Траты в определенных категориях товаров;
Средний размер остатка на счетах;
Участие в зарплатном проекте;
Участие в корпоративной программе;
Основным технологическим вызовом было то, что условие предоставлении скидки должно было рассчитаться буквально сразу по завершению календарного месяца и клиент должен быть оповещен через канал коммуникации о том, что он выполнил все условия по карточному обороту и на следующий расчетный период он получает льготное обслуживание.
За все операции с платежными картами отвечает карточный процессинг. Но фактически средства списываются либо начисляются в валюте счета на карточном счете тогда, когда в учетной бэк-системе будет сформирован и проведен платежный документ. Вы наверняка обращали внимание, что в случае проведения вами операции по карте, в мобильном приложении любого банка напротив операции первое время стоит пиктограмма в виде часов. Это и есть тот случай, когда операция прошла в процессинге, но не прошла еще в учетной бэк-системе.
Именно в этой особенности и заключается сложность получения оборота за период в режиме реального времени. Ведь данные сперва должны быть обработаны в учетной системе, затем, в рамках регламента они должны быть загружены в слой первичных данных в хранилище, потом они должны быть учтены в аналитическом слое и наконец попасть в систему принятия решения. При таком маршруте даже и о t-1 день мечтать не приходится.
Задачу необходимо решать в подходе лямбда-архитектуры. Очевидно, что запись данных в аналитические форматы вроде Parquet в режиме реального времени и наличие операций обновления (а карточная транзакция может проходить множества стадий обработки на стадии процессинга) вызовет проблемы. Использование HBase не решит задачу бесшовного доступа к offline и online данным без федерализации. И вот тут и проявляются сильные стороны дистрибутива, который мы используем. В сборке присутствует технология, закрывающая наши требования:
Интенсивная real-time загрузка данных и stream обработка;
Поддержка согласованных операций изменения Upsert / Delete;
Быстрый отклик;
Поддержка того же аналитического движка запросов что и для offline данных - Impala
Эта технология - Kudu. Этот вид антилоп родился в недрах сообщества и выпущен на поля Apache License 2.0. Kudu представляет собой отдельный storage формат и набор API для работы с этим форматом. Как правило данные в on-premise bare metal инсталляции располагаются на локальных дисках data узлов отдельно от HDFS (в нашем случае отдельные разделы в ext4).
Kudu имеет колоночный формат, но технически, как и многие другие аналитические движки, имеет онлайн Delta область, хранящую временно данные в строковом формате (аналог WOS в Vertica).
Архитектурный подход
В нашем решении Kudu служит буфером загрузки онлайн данных. Данные из процессингового центра попадают в корпоративную шину. Отдельное приложение “слушает” очередь сообщений ПЦ (процессингового центра), преобразует их в реляционный формат и записывает события в Kudu через API.
Но для расчета нашего предложения требуются не просто онлайн данные, а агрегат. Причем агрегат должен быть основан как на оффлайн данных бэк-системы, так и на онлайн данных ПЦ. И тут и проявляется сильная стороны Kudu - данные могут быть прочитаны через тот же движок, который используется и для всего остального SQL доступа и ETL трансформаций - Impala. Все что нам остается сделать - правильно соединить два множества одно из которых рассчитывается в ходе регламентного batch процесса, а другое в режиме онлайн при обращении.
Данные из ПЦ сами по себе представляют дополнительный интерес для дальнейшего анализа, поэтому раз в сутки операции загруженные в Kudu время изменения которых превышает 1 месяц, записываются в Parquet HDFS.
Помимо интеграции с процессинговым центром в нашем хранилище есть и другие источники, поставляющие данные в реальном времени в буферную область Kudu:
Запросы с фронт-систем;
Действия клиента в мобильном приложении;
Запросы с операционного CRM;
Информация от контактного центра
Интеграция с этими системами выполнена через брокер сообщений Kafka. В данный момент на кластере в рабочие часы в среднем фиксируется от 400 до 900 операций upsert в секунду. При этом в пиковые нагрузки, связанные с определенными регламентными работами систем, это значение вырастает до 25 тысяч.
Выводы
Использование технологии Kudu позволяет решить задачи онлайн интеграции и real-time аналитики, не прибегая к дополнительным интеграционным работам, связанным с имплементацией стороннего ПО в архитектурный ландшафт Hadoop. Обращение ко всем данным, как горячим так и холодным, через единый процессинговый движок Impala и общий интерфейс доступа предоставляет удобный сервис для бизнес-пользователей по анализу данных.
В настоящий момент после трех лет промышленной эксплуатации мы все еще не сталкивались с задачами, которые бы потребовали от нас дополнительных инсталляций стороннего ПО, связанных с тем что наши архитектурные подходы в Hadoop не способны их решить эффективно.