Лучшие практики для настройки конвейера данных на AWS? (Lambda / EMR / Redshift / Athena)

Question

* Отказ от ответственности: * Это моя первая публикация на stackoverflow, поэтому извините, если это не место для такого высокого уровня вопроса.

Я только начал работать в качестве ученого данных, и я Вас попросили настроить AWS среду для «внешних» данных. Эти данные поступают из разных источников, в разных форматах (хотя в основном это csv / xlsx). Они хотят хранить его в AWS и иметь возможность запрашивать / визуализировать его с помощью Tableau.

Несмотря на отсутствие опыта AWS, мне удалось найти решение, более или менее работающее. Это мой подход:

1. Необработанные csv / xlsx извлекаются с помощью лямбды
2. Данные очищаются и преобразуются с использованием pandas / numpy в той же лямбде, что и 1.
3. Обработанные данные записываются в папки S3 как CSV (все еще в той же лямбде)
4. Athena используется для индексации данных
5. Дополнительные таблицы создаются с использованием Athena (некоторые из которых являются взгляды, другие нет)
6. Соединитель Athena настроен для Tableau

Он работает, но кажется грязным решением: запросы медленные, а лямбды огромные. Данные часто не так нормализованы, как могли бы, так как это увеличивает время запроса еще больше. Хранение как CSV также кажется глупым

Я пытался прочитать лучшие практики, но это немного ошеломляет. У меня много вопросов, но все сводится к следующему: какие услуги мне следует использовать в подобной ситуации? Как выглядит архитектура высокого уровня?

Answer 1

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

В качестве первой итерации то, что вы описали выше, похоже, работает и является разумным подходом, но, как вы отметили, довольно основательно и неуклюже. Если внешние данные - это то, что вы будете постоянно поглощать и можете предвидеть их рост, я настоятельно рекомендовал бы сначала спроектировать систему передачи данных, я бы рекомендовал либо использовать службу формирования озера AWS, либо, если вам нужен больший контроль, и создать основу, используйте что-то вроде 3x3x3 подхода.

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

Поскольку архитектура высокого уровня будет выглядеть примерно так:

1. Lambda получает запрос от источника и вставляет в s3
2. Система обработки данных обрабатывает файловые и автоматические разделы + теги

тогда

В зависимости от того, как быстро вам нужно визуализировать ваши данные, и, если это большие объемы данных, потенциально используйте AWS клей pyshell или pyspark вместо lambda. Который будет обрабатывать ваши панды / numpy намного чище.

Я бы также порекомендовал конвертировать ваши файлы в паркет, если вы используете Athena или его эквивалент для повышения скорости запросов. Помните, что разбиение файлов важно для производительности!

Обратите внимание, что приведенное выше предназначено для довольно надежной системы приема и может быть излишним, если у вас есть базовый сценарий использования c с нечастым использованием данных.

Если ваши данные находятся в небольших пакетах, но очень часто, вы можете даже использовать слой кинезиса перед лямбда-шагом s3 для более организованной передачи данных. Вы также можете использовать redshift для размещения ваших файлов вместо S3, если вы хотите более современное складское решение. Однако, если у вас есть x источников, я бы предложил для простоты использовать s3.