Хранение данных и аналитика на AWS

#amazon-web-services #data-analysis #data-lake

Вопрос:

У меня есть одно требование к анализу данных в AWS. У меня ограниченные знания в области обработки больших данных, но, основываясь на своем анализе, я придумал несколько вариантов.
Требование состоит в том, чтобы собирать данные, вызывая API поставщика каждые 30 минут. (прием данных) Данные в основном структурированы. Эти данные должны храниться в хранилище (озеро данных S3 или Красное смещение.. не уверен)и различные агрегации/измерения из этих данных должны предоставляться через API REST. В будущем потребуется запускать алгоритмы ML на исходных данных, и, следовательно, необходимо соответствующим образом решить вопрос о хранении. Итак, основываясь на этом, можете ли вы предложить:

  1. Как принимать данные (Лямбда для запуска с запланированным интервалом и извлечения данных, хранения в хранилище ИЛИ любого лучшего способа извлечения данных в AWS)
  2. Как хранить (хранить в S3 или RedShift)
  3. Анализ данных (в настоящее время некоторые ежемесячные, еженедельные агрегации), какие инструменты можно использовать? Какие инструменты использовать, если я храню данные в S3.
  4. Предоставьте результаты аналитики через API. (Надеюсь, я смогу использовать Лямбда-код для запроса аналитического движка на предыдущем шаге)

Ответ №1:

Прием внутрь прост. Если извлечение происходит относительно быстро, то планирование функции AWS Lambda является хорошей идеей.

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

Для хранения Amazon S3 имеет смысл, по крайней мере, для первоначального хранения полученных данных, но может (или не может) подходить для API и аналитики.

Если вы собираетесь предоставить API, вам нужно будет подумать о том, как код API (например, с помощью AWS API Gateway) потребуется для извлечения данных. Например, идентичен ли он большому двоичному объекту исходных извлеченных данных, или требуются сложные преобразования или, возможно, объединение данных из других местоположений и временных интервалов. Это поможет определить, как следует хранить данные, чтобы их было легко извлечь.

Потребности в анализе данных также будут определять способ хранения ваших данных. Подумайте, достаточно ли базы данных SQL. Если есть миллионы и миллиарды строк, вы можете рассмотреть возможность использования Amazon Redshift. Если данные хранятся в Amazon S3, вы можете использовать Amazon Athena. Правильный ответ полностью зависит от того, как вы собираетесь получить доступ к данным и обработать их.

Итог: Сначала подумайте, как вы будете использовать данные, а затем определите наиболее подходящее место для их хранения. Общего ответа, который мы могли бы дать, нет.

Комментарии:

1. Спасибо Джону за проверку идеи и предложения по собственному решению AWS. Я также рассматриваю другие варианты, такие как Databricks для аналитики, которые также могут обслуживать API. В будущем мы обновим информацию о том, как это происходит…

2. Даже базы данных не предоставляют хороших возможностей для предоставления таблиц данных через REST API. Я нашел несколько хороших собственных решений с использованием (Каталог клея Афина), (Паркет спектр красного смещения), даже если они не являются быстрыми масштабируемыми решениями. Я предполагаю, что придется использовать решения OLTP (MySQL и т. Д.), А для ML нужно вернуть их в S3 или около того.. Если кто-нибудь знает о каких-либо БЫСТРЫХ, МАСШТАБИРУЕМЫХ решениях API для передачи данных, пожалуйста, просветите.