Создайте управляемую событиями архитектуру для подключения потока DynamoDB к Amazon Comprehend для анализа настроений
В рамках своей серии статей о бессерверных технологиях я рассказывал, как построить хорошо спроектированный бэкэнд с сервисами AWS - используя многорегиональный подход и подходы «активно-активный» для обеспечения высокой доступности.
В этом блоге мы будем использовать потоки DynamoDB и Amazon Comprehend, чтобы применить анализ настроений к элементам, хранящимся в вашей глобальной таблице DynamoDB, которую мы разработали и создали в предыдущих публикациях.
Быстрое обновление API
Для начала нам нужно быстро обновить лямбда-функцию, которая обрабатывает POST-запрос.
Единственное отличие от функции предыдущий пост - это дополнительный session_comment, который принимает строку, содержащую комментарий пользователя.
После развертывания вы можете выполнить POST новый элемент с элементом session_comment следующим образом:
Функция GET не изменяется, поскольку изначально она возвращала полный объект, запрошенный item_id.
Тестирование функции GET должно вернуть только что добавленный session_comment следующим образом:
Как я уже упоминал - просто :)
Давайте поговорим о потоках DynamoDB и архитектурах, управляемых событиями
Проще говоря, поток DynamoDB - это упорядоченный по времени поток информации, отражающий изменения элементов в таблице DynamoDB. Изменения могут отражать любое из следующего: Создание, Обновление и Удаление элементов в таблице.
Важно понимать, что DynamoDB Streams гарантирует следующее:
- Каждая запись потока появляется в потоке ровно один раз.
- Для каждого элемента, измененного в таблице DynamoDB, записи потока отображаются в той же последовательности, что и фактические изменения элемента.
Мне нравятся потоки DynamoDB, потому что они идеально вписываются в мою любимую парадигму архитектурного проектирования: архитектура, управляемая событиями. Вместо ожидания или опроса изменений, действия происходят, когда происходят изменения в системе. Конечно, мы много лет говорили об этом архитектурном паттерне, но до недавнего времени его было очень сложно реализовать в масштабе.
Итак, что изменилось? Произошла AWS Lambda. AWS Lambda предоставила каждому возможность вычислений, управляемых событиями, и вывела парадигму, управляемую событиями, на совершенно новый уровень. Сегодня такие компании, как Netflix (Bless) и Capital One (Cloud Custodian), используют управляемые событиями архитектуры на базе AWS Lambda для обеспечения безопасности, соответствия требованиям и управления политиками в реальном времени.
Возвращаясь к потокам DynamoDB - подключение вашего потока к AWS Lambda позволяет выполнять архитектуру, управляемую событиями, с использованием изменений в базе данных в качестве источника событий. Это довольно удивительно, если вы спросите меня - не нужно тянуть, не нужно запрашивать базу данных. Действия могут происходить при создании, обновлении или удалении элементов в базе данных.
Другими словами, вы можете интегрировать Amazon DynamoDB с AWS Lambda, чтобы создавать триггеры - фрагменты кода, которые автоматически реагируют на события в DynamoDB Streams. С помощью триггеров вы можете создавать приложения, которые реагируют на изменения данных в таблицах DynamoDB.
Теперь вам, наверное, интересно, что я хочу с этим делать ...
Хороший вопрос, Винсент! Ответ прост - я хочу провести анализ настроений в поле session_comment ; Я хочу знать, является ли комментарий ПОЛОЖИТЕЛЬНЫМ, ОТРИЦАТЕЛЬНЫМ или НЕЙТРАЛЬНЫМ. И на AWS есть простой способ сделать это - поздороваться с Amazon Comprehend.
Голос покупателей: О чем ты ???
Amazon Comprehend - это сервис обработки естественного языка (NLP), который использует машинное обучение для поиска идей и взаимосвязей в тексте. Он может определять язык текста, извлекать ключевые фразы, места, людей, бренды или события. Сервис также может понять, насколько текст положительный или отрицательный. Другими словами - много крутого!
Один из аспектов Comprehend, который мне очень интересно изучить, - это API обнаружения настроений.
Да, это ЭТО просто! Одна строка кода - и вы получите ультрасовременный анализ тональности вашего приложения.
Интересный факт: служба Comprehend постоянно учится и совершенствуется на основе различных источников информации, включая описания продуктов Amazon.com и отзывы потребителей - один из крупнейших естественных языков. наборы данных в мире - чтобы идти в ногу с эволюцией языка.
Собери все вместе
Теперь давайте объединим все вместе и интегрируем потоки DynamoDB с AWS Lambda и Amazon Comprehend.
Во-первых, давайте посмотрим на поток DynamoDB и объекты, которые в нем отправляются. Ниже приведен объект потока, отправляемый после запроса POST.
Вот транслируемый объект полностью. По сути, это список записей.
Самая интересная часть - это поле под названием eventName, используемое здесь как INSERT в DynamoDB. Есть несколько типов модификации данных, которые могут быть выполнены в таблице DynamoDB:
INSERT- в таблицу добавлен новый элемент.MODIFY- один или несколько атрибутов существующего элемента были изменены.REMOVE- элемент удален из таблицы
Ниже показано, как функция Lambda подключается к потоку DynamoDB и вызывает Amazon Comprehend для анализа поля session_comment и сохранения его обратно в DynamoDB. Вы заметите, почему важно eventName.
Примечание. Не бойтесь функций remove_key () или replace_decimals (). Они используются, чтобы немного очистить объект и в дальнейшем облегчить мне жизнь :)
Примечание 2. Забавный синтаксис функции table.update_item () объясняется здесь.
Шаблон для развертывания Lambda, запускаемого из DynamoDB с использованием бессерверной среды, следующий:
Обратите внимание на тип functions: streamFunction, который используется в шаблоне, чтобы отличать его от других типов, и на поле events: stream. который содержит имя ресурса Amazon (ARN) потока DynamoDB.
Чтобы получить ARN, используйте следующую команду:
Чтобы развернуть, то же самое, что и раньше:
Пришло время протестировать недавно расширенный API.
Вуаля !! Вы просто, с минимальными усилиями, интегрировали в свое приложение анализ тональности. Браво :-)
но .. почему .. ты .. делаешь .. это ???
Вам может быть интересно, почему я решил использовать этот управляемый событиями шаблон преобразования потока в лямбда для дополнения данных вместо того, чтобы вызывать Amazon Comprehend непосредственно из клиента перед сохранением данных в DynamoDB. Один звонок вместо двух?
Я называю это эффективностью :-)
Но это не все! Используя этот подход, нам не нужно предоставлять клиенту дополнительные разрешения для прямого вызова Comprehend - ограничивая нашу политику безопасности и доступа до минимума.
На этом пока все, ребята! Надеюсь, это было информативным. В следующей статье этой серии мы перейдем к вопросам отказоустойчивости и хаос-инженерии - следите за обновлениями!
-"Адриан"
