Как создать серверную часть для отображения больших наборов данных в веб-интерфейсе

Похоже на разумный план. Я полагаю, вам нужны указания, как этого добиться?

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

Вы можете настроить таблицу с расположением, которое является префиксом всех файлов Parquet (например, s3://example/dir/, если файлы хранятся с такими ключами, как s3://example/dir/2020/03/13/12/file.parquet). Если ваш общий набор данных не превышает пары гигабайт, я бы порекомендовал это. Если ваш набор данных больше и он организован в префиксы, содержащие каждый день или час, вы можете создать секционированную таблицу и добавить секции с местоположениями, которые используют структуру префиксов (например, s3://example/dir/2020/03/13, s3://example/dir/2020/03/12 для ежедневных секций или s3://example/dir/2020/03/13/11 и s3: / / example / dir / 2020/03/13 / 12` для почасовых разделов). Если у вас нет сотен гигабайт данных в день или запросы, которые вы будете запускать с помощью Athena, почти всегда обращаются только к нескольким часам данных, я бы рекомендовал разбивать на разделы по дате, а не по часам, чтобы уменьшить количество разделов.

Если ваши существующие файлы Parquet очень малы, менее ста мегабайт и производительность запросов Athena очень важна, вы можете попытаться преобразовать файлы ETL в файлы большего размера, чтобы увидеть, поможет ли это. Это может или не может, это будет зависеть. Я рекомендую вам использовать саму Афину для ETL. Для создания новые разделы в таблице на основе данных из другой таблицы. Я предлагаю автоматизировать это, создав правило Event Bridge с schedule, который либо запускает функцию Lambda, которая запускает запрос преобразования в Athena, либо конечный автомат Step Functions, если вы не хотите платить за Lambda, простаивающую в ожидании завершения запроса (или нужно ждать более 15 минут). У AWS есть сервис под названием Glue ETL, который был создан для такого рода вещей, но, по моему опыту, это того не стоит. Использование Athena, Lambda и Step Functions превосходит его с точки зрения удобства использования и гибкости.

Вы можете использовать тот же механизм для загрузки предварительно рассчитанных временных рядов в DynamoDB - используйте Event Bridge для планирования функции Lambda, которая запускает запросы в Athena, и преобразования результатов для сохранения в DynamoDB. Используйте пошаговые функции, чтобы не платить за простой при ожидании завершения запросов.

Если Amazon Timestream когда-либо будет выпущен, он может стать лучшей целью для хранения временных рядов, чем DynamoDB. Также рассмотрите возможность сохранения предварительно рассчитанных временных рядов как JSON, CSV или Apache Arrow на S3 вместо DynamoDB, что может быть дешевле и в некотором смысле проще в зависимости от вашего варианта использования.

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