Время ожидания AWS Athena истекло / недостаточно ресурсов при таком коэффициенте масштабирования

#mysql #sql #amazon-web-services #amazon-athena #presto

Вопрос:

Я столкнулся с проблемой с Афиной, когда пытался присоединиться и заказать два стола вместе. Мое заявление о запросе выглядит очень похоже на это:

 SELECT *  from Table_1  LEFT JOIN Table_2 ON Table_1  where Table_1.id = Table_2.id AND Table_1.date = Table_2.date  ORDER BY Table_1.id, Table_1.date  

Мои таблицы потенциально велики в зависимости от набора данных, с которым я работаю, примерно с миллионом строк или более. Проведя некоторое исследование, я понимаю, что ЗАКАЗ ПО потенциально может замедлить мой запрос, но даже когда я его удаляю, время ожидания все равно истекает. В то же время мне нужен ПОРЯДОК, чтобы структурировать мои данные, потому что я буду превращать их в csv-файл. Я также читал, что мог бы разделить свой запрос, чтобы использовать разных работников и воспользоваться способностью Афины выполнять параллельную работу, но я точно не знаю, как это сделать в Афине, поэтому, если бы кто-нибудь мог подробно и объяснить, как это можно сделать, это было бы идеально. Еще одна вещь, о которой я думал, — это разбиение моих данных на столбцы, но мне бы хотелось, чтобы кто-нибудь объяснил мне преимущества этого, так как я буду выбирать не только часть своей таблицы, но и всю таблицу каждый раз.

Я не знаю, актуально ли это, но мои размеры файлов обычно составляют около ~100 МБ или меньше. Однако, судя по различным публикациям здесь, которые я вижу с одной и той же проблемой, они имеют дело с более чем 10 ГБ, поэтому я не уверен, что в моем использовании Athena что-то принципиально не так.

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

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

1. Есть ли TEXT столбцы в любой из таблиц? Можете ли вы обеспечить SHOW CREATE TABLE каждого из них? Мы должны знать, какие у вас показатели.

2. Это id PRIMARY KEY для каждого стола? Если да, то почему вы также включаете фильтр date ?

3. «выглядит очень похоже» — если не достаточно похоже, то любой совет, который мы дадим, будет подозрительным.

4. OFFSET это ужасно неэффективный способ разбиения на страницы. Вместо этого «вспомните, на чем вы остановились».

5. PARTITIONing редко обеспечивает производительность.

Ответ №1:

Проведя еще несколько тестов над моим кодом, чтобы увидеть, в какой момент он нарушается с точки зрения размера полезной нагрузки, я понял, что мое общее количество строк было намного больше, чем должно быть. Я обнаружил, что мое утверждение select-это не то, чем оно является на самом деле, как я описал его в своем посте. в нем отсутствовала AND Table_1.date = Table_2.date часть из-за ошибки в построении запроса (потому что я его условно создаю). Это привело к тому, что количество строк было умножено до 10 раз, как я заметил, что испортило мой запрос и съело все ресурсы афины. Так что теперь все работает нормально. Тем не менее, я оставлю этот пост в основном в учебных целях, чтобы узнать, есть ли ответы на какие-либо вопросы, связанные с этой потенциальной проблемой.