как вы проектируете OLAP-систему для поддержки панели мониторинга ежечасной (или даже более детальной) статистики использования API

Question

Для фона я собираю журналы использования API (запрос, ответ, задержка, userId и т. Д. c) для приложения. Типичный день накапливает 200-300 миллионов записей. Эти данные в настоящее время хранятся на s3 в формате parquet, и я использую AWS Athena для специальных запросов c. Я хотел бы перейти к созданию веб-панели инструментов, которая отображала бы показатели для каждого клиента; пример запроса - это объем запросов по клиентам по часам за последние 6 часов. Мне нужны такие подробные данные об использовании только за предыдущие 30 дней.

В идеале я продолжаю использовать экосистему AWS для этого решения. Я пытаюсь определить общее направление. Может ли Redshift эффективно вычислять эти типы запросов к необработанным данным журнала на лету, в течение 1 секунды или около того, чтобы их можно было использовать в Интернете? Есть лучший инструмент? Или мне следует посмотреть на запуск ETL и операций типа объединения для генерации этих показателей, заполнения другой таблицы (возможно, с красным смещением), а затем использовать ее для обслуживания панели мониторинга?

добро пожаловать - спасибо.

Answer 1

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

• Предварительно обработайте все, что вы можете а не рассчитывать на лету. Обобщите свои почасовые метрики, например, в хранилище ключевых значений, а не в вычислениях по большому количеству метрик. Вы можете эффективно хранить эти метрики в DynamoDB и извлекать.
• Redshift может быстро возвращать данные в зависимости от определений вашей схемы (ключей распределения, ключей сортировки), однако если вы запись отдельных транзакций не будет столь же эффективной с записью. Вы захотите делать эту массу на периоды. Его необходимо будет решить как решение, работающее почти в реальном времени.
• Общие информационные панели, которые требуют больших вычислений, но не должны быть активными (т.е. ежечасная или ежедневная статистика), могут быть сгенерированы и сохранены в S3 , поэтому он будет быстрым, но не требует чтения из БД каждый раз, когда пользователь.
• Athena предназначен для запроса озера данных, если вы используете его для больших порций данных, близких к реальному времени, это будет не так эффективно для получения результатов данных. Говоря это, если вы используете Redshift, вы можете присоединяться к запросам из своего озера данных, используя Redshift Spectrum .