В настоящее время я использую AWS S3 + Athena для проекта.
Тем не менее, после использования его в течение 1-2 месяцев, я нахожу некоторые ограничения по этому поводу.
Я не уверен, если я не знаю, как его использовать, или это действительно ограничение.
Но, пожалуйста, не спрашивайте, почему я предпочитаю использовать его перед достаточным исследованием. Я думаю, что есть 2 балла:
- Требуется проектом
- Ресурсы Athena S3 и AWS не совсем централизованы, а их функциональные возможности постоянно меняются. Мне трудно найти то, что может или не может сделать Athena + S3, прежде чем использовать его некоторое время.
Увлекся слишком далеко, теперь вернемся к теме. > _ <</p>
В настоящее время я столкнулся с проблемой. С увеличением объема данных размер сканирования данных и количество запросов значительно увеличиваются и увеличиваются (иногда даже возникают исключения, например слишком много открытых файлов при выполнении запроса). Однако, похоже, что для AWS S3 + Athena есть только раздел, но нет индекса. Отсюда и проблемы.
Вопрос 1:
Могу ли я сделать что-то вроде индекса на AWS S3 + Athena?
Вопрос 2:
Если я использую раздел, кажется, что можно указать только один составной ключ (один или несколько столбцов в качестве меток в папке S3); в противном случае размер данных будет удвоен. Это правда?
Вопрос 3:
Даже я готов увеличить размер данных, это невозможно для таблицы с 2 составными ключами. Мне нужно иметь 2 таблицы Athena и 2 одинаковых набора данных, но на 2 типах разделов в S3, чтобы добиться этого. Это правда?
Вопрос 4:
Для ошибки «слишком много открытых файлов» после некоторого исследования кажется, что это проблема уровня ОС с предопределенным ограниченным числом дескрипторов файлов. Моя текущая ситуация такова, что SQL не имеет исключений большую часть времени, но в определенный период он легко имеет исключение. Насколько я понимаю, у Amazon будет кластер компьютеров (например, 32 узловых сервера) для обслуживания определенного количества клиентов, включая мою компанию и другие компании. Каждый сервер имеет ограниченное количество файловых дескрипторов, доступных для всех клиентов. Затем, в некоторые пиковые периоды (другие компании выполняют сложные запросы), доступное количество файловых дескрипторов будет уменьшаться, и это также объясняет, почему мой SQL с тем же набором данных иногда имеет исключение, но не всегда. Это правда?
Вопрос 5:
Из-за отсутствия индексной функции S3 + Athena не должна выполнять сложные запросы SQL. Это означает, что сложная логика объединения может быть выполнена только где-то на уровне преобразования перед загрузкой в S3. Это правда?
Вопрос 6:
Этот вопрос следует за предыдущим, Вопрос 5.
Позвольте мне использовать простой пример для иллюстрации:
Система отчетности разработана для отображения ордеров и торговли. Связь заключается в том, что после исполнения ордера будет сгенерирована сделка. Order_ID является ключом для связывания сделки и связанных с ней операций с ордерами. В разделе установлена дата.
Теперь поступают следующие данные:
Требование:
1. Для отчета в первый день отображается только запись заказа O001-Разместить заказ
2. Для отчета на 2-й день отображается только запись заказа O002-заказ на изменение заказа
3. Для отчета на 3-й день показываются все записи, включая 4 заявки и 1 сделку.
4. Для отчета на 4-й день отображается только запись заказа O004-Замечание Изменение
Для дней 1, 2 и 4 это легко, поскольку я просто отображаю, какие данные поступают в один и тот же день.
Однако для третьего дня мне нужно отобразить все данные, некоторые в прошлом, а некоторые в будущем (O001-Remark Change).
Чтобы избежать сложного SQL, я могу использовать только логику соединения на уровне преобразования.
Однако при выполнении преобразования в 3-й день, если сторона не отправляет мне данные в 1-й и 2-й дни, вы можете найти только исторические файлы, что нехорошо, поскольку вы никогда не знаете, сколько дней вам нужно для поиска.
Даже если мы выполняем поиск в Афине, так как Order_ID не находится в разделе, необходимо полное сканирование таблицы.
Вышеприведенное не является худшим, наихудшим случаем является то, что при преобразовании в День 3, O001-Remark Change в 4-й день - данные будущего и не должны быть известны в 3-й день.
Есть ли лучший способ сделать это?Или AWS S3 + Athena просто не подходит для такого сложного случая (приведенный выше случай - просто упрощенная версия моей текущей ситуации)?
Я знаю, что у меня слишком много и довольно много вопросов.Но все это то, что я действительно хочу уточнить, и я не могу найти четкого ответа.Любая помощь высоко ценится и большое спасибо.