Анализ настроений с помощью AWS и Splunk: потому что все крутые ребята этим занимаются

Автор: Билл Мэтьюз

У меня есть несколько вещей в жизни, которые мне действительно нравятся, и AWS забирает их у меня. Мне нравится писать код для анализа настроений, но я НЕНАВИЖУ тренировать модели. Итак, введите Amazon Comprehend, который является (одной из) многих магических вещей AWS в области машинного обучения. Вы швыряете в него какой-то текст, он его ищет и выдает оценку, разбитую на нейтральные, положительные или отрицательные оценки.

Теперь мы хотели провести базовый анализ тональности последнего сообщения в заявке. Почему? Отличный вопрос. Мы хотели посмотреть, не будет ли клиент слишком негативно относиться к билету, и, честно говоря, Том Копчак сказал мне это сделать, и я это сделал. Я также хотел узнать больше об AWS Lambda и Сборщике HTTP-событий Splunk. Этот проект сочетал в себе все эти вещи, так что я был полностью на борту. Это не предназначено для того, чтобы быть учебным пособием по какой-либо из этих вещей, у каждого поставщика есть свои собственные (лучшие) учебные пособия, и вы можете ознакомиться с ними.

Вот так.

Наши заявки существуют в Zendesk, и у них есть довольно удобный API, поэтому мы могли легко получить то, что нам было нужно, и в AWS’ S3 для последующей обработки. Теперь я мог бы просто передать одно в другое, но я, вероятно, буду делать с этими данными некоторые другие вещи, которые потребуют S3, поэтому я выбрал этот маршрут.

S3 позволяет вам определить политику жизненного цикла, поэтому эти данные довольно скоротечны — они в значительной степени умрут после того, как будут созданы. Как только он достигает S3, мы получаем событие «созданный объект», которое вызывает нашу функцию AWS Lambda, это умно называется «триггером». Это сообщает нашей лямбда-функции, какое ведро S3 и «ключ» (на самом деле имя файла) использовать для этого вызова. Затем функция Lambda вызовет Comprehend AWS и извлечет результаты анализа (занимает несколько секунд), а затем передаст эти результаты нашему сборщику событий Splunk HTTP, где я построил действительно причудливую панель инструментов, чтобы показать общий анализ настроений.

Код доступен здесь, но давайте подробнее рассмотрим, что происходит.

После того, как мы сделали наш импорт, мы загружаем наши необходимые клиенты Boto 3. Boto 3 — одна из тех вещей, которые только что предоставляет Lambda, так что вам не нужно делать ничего особенного, чего бы вы в любом случае не сделали в Python.

s3 = boto3.client('s3')
comprehend = boto3.client('comprehend')

В следующем разделе анализируются данные из нашего триггера S3 и заполняются наше ведро и ключевые переменные.

def lambda_handler(event, context):
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = urllib.unquote_plus(event['Records'][0]['s3']['object']
   ['key'].encode('utf8'))

Здесь мы берем наши Переменные среды AWS Lambda, которые позволяют нам шифровать нашу конфиденциальную информацию о конфигурации. Здесь только информация о нашем сервере Splunk и наш токен HEC.

    splServer = os.environ['splServer']
    splToken = os.environ['splToken']

Эта строка захватывает для нас объект S3 и загружает его в объект ответа, чтобы мы могли работать с ним.

response = s3.get_object(Bucket=bucket, Key=key)

Когда у нас есть этот объект, нам нужно только захватить его тело, так как мы хотим проанализировать его целиком, а не анализировать его каким-либо образом.

#grab the ticket post from the S3 response
ticketBody = response['Body'].read()

Эта строка просто отправляет тело заявки, которую мы захватили выше, и загружает ответ в словарь настроений. Это словарь, потому что так говорит Python, не спорьте.

#run the ticket post through AWS Comprehend to get sentiment analysis
sentiments = comprehend.detect_sentiment(Text=ticketBody, LanguageCode='en')

Теперь, поскольку я не делал никакого синтаксического анализа, а мой «ключ» S3 — это просто номер тикета, было довольно тривиально, без какого-либо синтаксического анализа, добавить ключ (номер тикета) в словарь настроений, чтобы у меня было что-то уникальное для идентификации. анализ с.

#add the ticket number to the dict so we have a unique key in splunk
sentiments['ticketNum'] = key

На данный момент все, что нам нужно сделать, это отправить полные результаты анализа в наш сборщик событий Splunk HTTP, который позволяет нам провести некоторый анализ и построить причудливые информационные панели. Обратите внимание: я сделал «хост» «лямбда-», а затем имя функции. Это ни в коей мере не является обязательным требованием, но упрощает определение в Splunk источника данных. Я мог бы сделать это и в Source, но я этого не сделал, так что меня устраивает то, что вам удобнее — я не осуждаю.

#fling the data to Splunk HTTP Event Collector for further analysis
r = requests.post(splServer, headers={"Authorization": "Splunk " + splToken}, json={"host":"lambda-runSentimentAnalysis","event":sentiments})

Необработанные данные в Splunk выглядят примерно так, с измененными номерами заявок для защиты невиновных:

После того, как я построил уродливую приборную панель, Ян (наш повелитель приборной панели) сделал ее лучше и менее «похожей на Билла», так что теперь она выглядит довольно хорошо:

Имейте в виду, что это не данные, которые мы должны поддерживать «свежими», все они автоматизированы, и это довольно общая функция, поэтому ее можно использовать с любым типом данных, а не только с билетами. Самым сложным для меня было разобраться во всей номенклатуре Lambda, код очень простой и понятный. Это позволило мне совместить три моих любимых вещи: AWS что угодно, обработку естественного языка (хотя на самом деле мне не нужно было ничего из этого писать) и, что не менее важно, Splunk. Это также позволило мне узнать кое-что новое о моих любимых вещах, которые я смогу применить к другим более масштабным проектам. Вот это я называю стоящей парой часов работы.

Наслаждаться!