Машинное обучение меняет мир. Беспилотные автомобили, виртуальные помощники для общения и регистрация в авиакомпаниях с помощью распознавания лиц - вот лишь несколько примеров того, к чему мы стремимся. В каждом из этих примеров машинное обучение автоматизирует процессы, которые человеческий мозг выполнял в прошлом, например, как распознаются изображения и обрабатывается язык.
Это также распространяется на процессы, которые компании по всему миру используют для ведения своего бизнеса. Бизнес-процессы обычно представляют собой прекрасную возможность для автоматизации, в решении которой могут помочь продукты BPM с открытым исходным кодом. Сочетание BPM с открытым исходным кодом и машинного обучения может вывести автоматизацию на новый уровень.
Например, машинное обучение можно использовать для предоставления рекомендаций, которые могут улучшить процесс принятия решений в бизнес-процессе. Но как мы можем интегрировать машинное обучение и BPM с открытым исходным кодом в реактивную архитектуру микросервисов? Мы хотим, чтобы наши сервисы были небольшими и были сосредоточены на том, чтобы хорошо выполнять одну задачу, при этом они были отделены друг от друга и могли развертываться независимо. В этой статье мы обсудим шаблон интеграции для достижения этой цели с использованием машинного обучения, BPM с открытым исходным кодом и реактивных микросервисов.
Предпосылки машинного обучения
Сначала давайте кратко расскажем о машинном обучении. Это действительно разновидность искусственного интеллекта (ИИ). Ниже приведена хронология графика, иллюстрирующая различные этапы, которые мы пройдем.
ИИ начал свою деятельность в 1950-х годах с так называемых экспертных систем. Эти системы содержали логику если / тогда, запрограммированную человеком. Позже ранние формы программного обеспечения машинного обучения были сосредоточены на линейной регрессии, деревьях, регрессии временных рядов и обучении без учителя. В 1980-х годах начало появляться машинное обучение нейронных сетей. За последние 25 лет программное обеспечение для машинного обучения значительно продвинулось вперед, и большая часть его стала с открытым исходным кодом.
Вычислительная мощность также стала намного дешевле, и ее можно быстрее получить за счет облачных вычислений. H2O - один из таких примеров платформы машинного обучения в оперативной памяти с открытым исходным кодом. Он предоставляет ряд алгоритмов (например, Обобщенная линейная модель, Случайный лес, Машина повышения градиента, Анализ основных компонентов и т. Д.) Для обучения моделей машинного обучения, а также генерирует метрики, показывающие точность и производительность сгенерированная модель.
H2O также сгенерирует развертываемый артефакт, который вы можете включить в свой проект, например, артефакт POJO (обычный старый объект Java) или MOJO (объект модели, оптимизированный). MOJO обычно используется, когда POJO достигает предельного размера или требуется более высокая производительность.
Следующая ключевая концепция машинного обучения - это две категории высокого уровня - контролируемая и неконтролируемая.
Контролируемый - это место, где вы помечаете свои данные и включаете функции вместе с целевой переменной в набор данных. Эта целевая переменная представляет элемент данных, который вы хотите спрогнозировать, а функции - это элементы данных, которые можно использовать для предсказания цели. Целевая переменная предоставляется в наборе данных для прошлых записей, и алгоритмы используют эти функции, чтобы определить, как предсказать предоставленную целевую переменную. Неконтролируемый - это когда вы не маркируете свои данные (цель не указывается), а позволяете программе находить взаимосвязи. Обычно это делается путем группирования похожих данных вместе.
В обоих случаях всегда полезно предоставить как можно больше данных, чтобы программное обеспечение машинного обучения было максимально точным. Кроме того, важно убедиться, что данные в любом случае не являются смещенными, иначе модель будет смещена. С машинным обучением модель хороша ровно настолько, насколько хороши данные.
Интеграция машинного обучения в реактивные микросервисы
Теперь, когда у вас есть некоторый контекст по машинному обучению, давайте обсудим, как его можно интегрировать с микросервисами, реактивной архитектурой и BPM с открытым исходным кодом. К настоящему времени вы, наверное, все слышали о микросервисах и их преимуществах.
Прочтите мои предыдущие блоги, чтобы узнать больше о реактивной архитектуре и BPM с открытым исходным кодом.
Сначала поговорим о сценарии использования. Представьте себе сценарий, в котором у вас есть бизнес-процесс, который может включать некоторую степень человеческого рабочего процесса наряду с вызовами системного API. Машинное обучение можно использовать, чтобы уменьшить объем рабочего процесса для пользователя. Его также можно использовать, чтобы предоставить пользователю дополнительную информацию для принятия лучших решений.
С точки зрения дизайна, вы обычно хотите, чтобы ваши бизнес-процессы BPM с открытым исходным кодом были легкими и сосредоточились на тех вещах, в которых он хорош. В противном случае вы можете быстро получить монолитное приложение. Итак, сделайте так, чтобы BPM сосредоточилась на рабочем процессе, а внешние службы - на выполнении работы.
Чтобы добиться этого, вы можете использовать Kafka в качестве механизма интеграции. Http://kafka.apache.org/
Kafka - это распределенная потоковая платформа, которую можно использовать в качестве потока событий в архитектуре реактивных микросервисов. Микросервисы заранее запрограммированы на реакцию на определенные события, присутствующие в Kafka. Сам Kafka работает быстро и имеет высокую пропускную способность, подтвержденную LinkedIn, поскольку они используют его для обработки миллиардов транзакций в день. Он также часто используется для противодавления во многих архитектурах, выступая в качестве буфера между производителем и потребителем, который позволяет потребителю читать с желаемой скоростью. Он также имеет настраиваемое постоянство, которое можно использовать для воспроизведения событий в архитектуре микросервисов. Это позволяет микросервисам выполнять резервное копирование любых записей, которые они могут пропустить во время простоя.
Одно доказательство концепции, которое я недавно разработал (вместе с Дэвидом Мерфи из Red Hat), использует собственное расширение Kafka для инструмента BPM с открытым исходным кодом, Red Hat Process Automation Manager ™ (PAM). (Red Hat PAM - это новое название Red Hat BPM Suite, и оба они основаны на более старых ветвях проекта сообщества jBPM.) Расширение Red Hat PAM для интеграции с Kafka позволяет бизнес-процессу напрямую производить и потреблять события на темы Kafka. Для этого мы создали специальный обработчик рабочих элементов для Kafka в Red Hat PAM ™ вместе с Kie Server Extension (разработанным Дэвидом Мерфи из Red Hat). Обработчик рабочих элементов создает служебную задачу Kafka, которую можно использовать в бизнес-процессе для передачи в Kafka. Обновление Kie Server Extension потребляет события из Kafka, выполняет некоторый синтаксический анализ, а затем отправляет эти события в качестве сигнальных событий в бизнес-процесс. Ниже приведен пример схемы, иллюстрирующей расширение Kie Server Extension, которое основано на более старой версии BPM Suite 6.2 и использует конструкцию EJB.
В Red Hat PAM 7.0 архитектура выглядела бы так, в которой удаляется конструкция EJB и используется концепция генератора событий:
Вы можете найти исходный код более старой версии здесь:
После подключения Red Hat PAM к Kafka вы можете запрограммировать бизнес-процесс для создания событий в Kafka, которые будут запускать внешние микросервисы. Это позволяет Red Hat PAM управлять только рабочим процессом и позволяет внешним микросервисам выполнять работу.
Это следует шаблону Гибрид - Реагирование между и координатором для управления потоком. Ниже представлена архитектурная диаграмма общего доказательства концепции:
Давайте рассмотрим это доказательство концепции более подробно. Вы можете найти его исходный код ниже:
Важной концепцией, которую мы реализуем в этом примере, являются команды и события. Команды - это вещи, которые необходимо выполнить, тогда как события - это вещи, которые произошли в прошлом.
Выступая в качестве координатора, Red Hat PAM выдает команды Kafka, которые внешние микросервисы используют, выполняют некоторую обработку, а затем создают события, которые затем потребляются либо другим микросервисом, либо Red Hat PAM. В этом доказательстве концепции у нас есть два микросервиса. Один для расчета характеристик, а второй для выполнения модели H2O.
Мы намеренно выделили их, чтобы при необходимости их можно было масштабировать отдельно. Оба они развернуты как dockerized Java JAR, которые используют API Kafka для использования и создания в Kafka. Для модели H2O она была обучена с использованием алгоритма распределенного случайного леса на выборочном наборе данных обнаружения мошенничества с кредитными картами из Kaggle. Он включает 28 десятичных знаков, а также время, сумму транзакции и переменную класса, которая указывает, является ли транзакция мошеннической (1) или нет (0).
Мы интегрировали POJO, сгенерированный H2O, в наш микросервис Java, импортировав его в наш проект java:
import com.decisioning.drf_c79982d1_29c6_47bd_8950_897ba97ba737;
Затем мы написали код-оболочку для создания экземпляра модели:
hex.genmodel.GenModel rawModel = null; rawModel = (hex.genmodel.GenModel) new drf_c79982d1_29c6_47bd_8950_897ba97ba737(); EasyPredictModelWrapper model = new EasyPredictModelWrapper(rawModel); RowData row = new RowData();
Затем мы сопоставляем входные переменные с объектом строки, который является экземпляром класса RowData:
row.put("Time", time);
row.put("V1", v1);
row.put("V2", v2);
row.put("V3", v3);
row.put("V4", v4);
row.put("V5", v5);
row.put("V6", v6);
row.put("V7", v7);
row.put("V8", v8);
row.put("V9", v9);
row.put("V10", v10);
row.put("V11", v11);
row.put("V12", v12);
row.put("V13", v13);
row.put("V14", v14);
row.put("V15", v15);
row.put("V16", v16);
row.put("V17", v17);
row.put("V18", v18);
row.put("V19", v19);
row.put("V20", v20);
row.put("V21", v21);
row.put("V22", v22);
row.put("V23", v23);
row.put("V24", v24);
row.put("V25", v25);
row.put("V26", v26);
row.put("V27", v27);
row.put("V28", v28);
row.put("Amount", amount);
Затем выполняем модель:
BinomialModelPrediction p = null;
try {
p = model.predictBinomial(row);
} catch (PredictException e) {
e.printStackTrace();
}
затем запишите содержимое p.label (1 для мошенничества, 0 для отсутствия мошенничества) и p.classProbability, чтобы получить результаты: (JSON ниже жестко запрограммирован для примера)
//if the H2o model thinks its fraud, return Fraudulent Transaction
if (p.label.equalsIgnoreCase("1"))
line = "{\"id\":\"" + appid + "\",\"action\": \"Fraudulent Transaction\",\"data\": {\"timestamp\": \"" + ts + "\"},\"p.label\":\"" + p.label + "\",\"p.classProbability\":\"," + p.classProbabilities[0] + "\"}";
else //if h2o model does not think its fraud, return Transaction OK
line = "{\"id\":\"" + appid + "\",\"action\": \"Transaction OK\",\"data\": {\"timestamp\": \"" + ts + "\"},\"p.label\":\"" + p.label + "\",\"p.classProbability\":\"," + p.classProbabilities[0] + "\"}";
return line;
Давайте углубимся в коробку Red HAT PAM. В этом примере Red Hat PAM выполняет бизнес-процесс, который прослушивает сигнальные события (представленные в виде треугольников в замкнутых кругах), поступающие от Kafka, которые обрабатываются серверным расширением Kie.
Задача Calc Features - это созданная нами задача службы Kafka, которая позволяет вам создавать сообщения непосредственно в теме Kafka. Требуется три входа. KafkaKey, Value (данные, которые вы хотите записать в Kafka) и тему, для которой вы хотите создать. В этом случае он записывает в тему card.transaction и отправляет значение «Calc Features» (которое находится в переменной appInit) в качестве команды.
Это отображается в теме Kafka как:
{“id”: “b0e0193b-9c2c-46d0–8dfe-12d2ac88adf3”,”action”: “Calc Features”}
Затем микросервис Calc Features запрограммирован на реакцию при обнаружении события в Kafka действием «Calc Features». Он вычисляет 28 различных числовых характеристик и затем записывает их обратно в Kafka:
{“id”:”b0e0193b-9c2c-46d0–8dfe-12d2ac88adf3",”action”: “Features Calculated”,”data”: {“timestamp”: “2018–07–10 16:38:52.578”, “time”: “7891”, “v1”: “-1.585505367”, “v2”: “-3.261584548”,”v3": “-4.137421983”,”v4": “2.357096252”,”v5": “-1.405043314”,”v6": “-1.879437193”,”v7": “-3.513686871”,”v8": “1.515606746”,”v9": “-1.207166361”,”v10": “-6.234561332”,”v11": “5.450746067”,”v12": “-7.333714067”,”v13": “1.361193324”,”v14": “-6.608068252”,”v15": “-0.481069425”,”v16": “-2.60247787”,”v17": “-4.835112052”,”v18": “-0.553026089”,”v19": “0.351948943”,”v20": “0.315957259”,”v21": “0.501543149”,”v22": “-0.546868812”,”v23": “-0.076583636”,”v24": “-0.425550367”,”v25": “0.123644186”,”v26": “0.321984539”,”v27": “0.264028161”,”v28": “0.13281672”,”amount”: “1”}}}
Микросервис модели запуска запрограммирован так, чтобы реагировать, когда он видит вычисленные функции, а затем выполняет модель H2O и записывает выходные данные модели и указывает, в порядке ли транзакция:
{“id”:”703d2ff8–9a60–43f6–8d76–0065ec3528a0",”action”: “Transaction OK”,”data”: {“timestamp”: “2018–07–10 16:38:44.633”},”p.label”:”0",”p.classProbability”:”,0.40568148708343504"}
или если это мошенническая транзакция:
{“id”:”b0e0193b-9c2c-46d0–8dfe-12d2ac88adf3",”action”: “Fraudulent Transaction”,”data”: {“timestamp”: “2018–07–10 16:38:52.591”},”p.label”:”1",”p.classProbability”:”,0.022"}
Red Hat PAM имеет сигнальное событие, которое ищет значение OK или мошеннической транзакции и либо завершает процесс, либо записывает обратно в Kafka, указывая на необходимость дальнейшей оценки:
{“id”: “b0e0193b-9c2c-46d0–8dfe-12d2ac88adf3”,”action”: “Evaluate Fraud”}
Ниже приведена диаграмма последовательности, которая помогает проиллюстрировать процесс:
Мы можем увидеть общий путь, пройденный рабочим процессом в Red Hat PAM, используя службу REST:
Резюме
Таким образом, это доказательство концепции представляет собой рабочий пример того, как можно интегрировать машинное обучение в архитектуру реактивных микросервисов, а также включить BPM с открытым исходным кодом. Если вы реализуете BPM как гибридный шаблон координатора, обратите внимание на несколько важных моментов:
● Примените шаблон координатора, где:
1. Есть синхронные блоки асинхронной обработки.
2. Необходимо видеть общий бизнес-процесс на всех этапах разработки и выполнения.
3. Необходимо как можно больше отделить друг от друга, чтобы устранить зависимости.
● Координатор может быть единственной точкой отказа. Убедитесь, что это стоит компромисса и упрощает вашу архитектуру. Оцените множественное развертывание для активного / активного (уровни приложения и базы данных).
● Используйте идентификаторы корреляции в событиях, чтобы сопоставить различные события.
Надеюсь, этот блог окажется для вас полезным. Вы можете найти живую демонстрацию доказательства концепции здесь. Я хотел бы поблагодарить Дэвида Мерфи из RedHat за ваш вклад в этот блог. Спасибо!
РАСКРЫТИЕ ИНФОРМАЦИИ: это мнение автора. Если в этом посте не указано иное, Capital One не является аффилированным лицом и не поддерживается ни одной из упомянутых компаний. Все используемые или отображаемые товарные знаки и другая интеллектуальная собственность являются собственностью соответствующих владельцев. Эта статья © Capital One, 2018.
