Афина действительно не хранилище данных с низкой задержкой. Вы будете очень редко видеть время отклика ниже одной секунды, и часто они будут значительно дольше. В общем случае Athena не подходит в качестве бэкенда для API, но, конечно, это зависит от того, какой это API. Если это какая-то аналитическая служба, возможно, пользователи не ожидают времени ответа менее секунды? Я создал API, которые используют Athena, которые работают очень хорошо, но это были сервисы, где ожидаемое время отклика в секундах (и даже считается быстрым), и я получил помощь от команды Athena, чтобы настроить наш аккаунт для нашей рабочей нагрузки.
Чтобы понять, почему Афина «медленная», мы можем проанализировать, что происходит, когда вы отправляете запрос в Афину:
- Ваш код начинает запрос с помощью
StartQueryExecution API-вызова - Служба Athena получает запрос и помещает его в очередь. Если вам не повезло, ваш запрос некоторое время будет находиться в очереди
- Когда есть доступная емкость, служба Athena берет ваш запрос из очереди и создает план запроса
- План запроса требует загрузка метаданных таблицы из каталога Glue, включая список разделов, для всех таблиц, включенных в запрос
- Athena также перечисляет все местоположения на S3, полученные из таблиц и разделов, для создания полного списка файлов, которые будет обработан
- Затем план выполняется параллельно и, в зависимости от его сложности, в несколько этапов
- Результаты параллельных выполнений объединяются, а результат сериализуется как CSV и записывается в S3
- Между тем, ваш код проверяет, завершился ли запрос с использованием вызова API
GetQueryExecution, пока не получит ответ, в котором говорится, что выполнение завершилось успешно, не удалось или было отменено - Если выполнение завершено успешно ваш код использует вызов API
GetQueryResults для получения первой страницы результатов - Чтобы ответить на этот вызов API, Афина считывает результат CSV из S3, десериализует его и сериализует его как JSON для ответа API
- Если в последних шагах более 1000 строк будет повторяться
Эксперт Presto, вероятно, мог бы дать более подробную информацию о шагах 4-6, хотя они, вероятно, немного изменены в версии Presto Афины. Подробности не очень важны для этого обсуждения.
Если вы выполняете запрос для большого количества данных, десятков гигабайт или более, общее время выполнения будет зависеть от шага 6. Если результат также большое значение будет иметь значение 7.
Если ваш набор данных небольшой и / или содержит тысячи файлов на S3, вместо этого будет доминировать 4-5.
Вот несколько причин почему запросы Athena никогда не могут быть быстрыми, даже если они не будут касаться S3 (например, SELECT NOW()):
- Прежде чем вы получите ответ, будет как минимум три вызова API, a
StartQueryExecution, GetQueryExecution и GetQueryResults, только их время прохождения в оба конца (RTT) может составить более 100 мс. - Скорее всего, вам придется звонить
GetQueryExecution несколько раз, и задержка между вызовами накладывает ограничение на то, насколько быстро вы сможете обнаружить, что запрос выполнен успешно, например, если вы будете вызывать его каждые 100 мс, вы в среднем добавите половину 100 мс + RTT к общему времени, потому что в среднем вы пропустите фактическое завершение время к этому много. - Афина запишет результаты в S3, прежде чем пометит выполнение как успешное, и, поскольку она создает один CSV-файл, это не делается параллельно. Для написания большого ответа требуется время.
GetQueryResults должен прочитать CSV из S3, проанализировать его и сериализовать как JSON. Последующие страницы должны пропускаться вперед в CSV и могут быть еще медленнее. - Афина - это мультитенантная служба, все клиенты конкурируют за ресурсы, и ваши запросы будут поставлены в очередь, когда не будет достаточно ресурсов.
Если вы хотите узнать, что влияет на производительность ваших запросов, вы можете использовать API-вызов ListQueryExecutions, чтобы вывести список последних идентификаторов выполнения запросов (я думаю, вы можете go вернуть максимум на 90 дней), а затем использовать GetQueryExecution для получения статистики запросов (см. документацию для QueryExecution.Statistics, чтобы узнать, что означает каждое свойство). С помощью этой информации вы можете выяснить, связаны ли ваши медленные запросы с очередями, выполнением или накладными расходами на выполнение вызовов API (если это не первые два, скорее всего, последний).
Есть некоторые вещи Вы можете уменьшить некоторые задержки, но эти советы вряд ли приведут вас к задержке менее секунды:
- Если вы запрашиваете много данных, используйте форматы файлов, оптимизированные для такого рода. Дело в том, что Parquet - это почти всегда ответ, а также убедитесь, что размеры ваших файлов оптимальны, около 100 МБ.
- Избегайте большого количества файлов и избегайте глубоких иерархий. В идеале иметь только один или несколько файлов на раздел и не организовывать файлы в «подкаталогах» (префиксы S3 с косой чертой), за исключением тех, которые соответствуют разделам.
- Избегайте выполнения запросов в начале часа, Это происходит, когда запускаются все остальные запланированные задания, в первые минуты каждого часа возникают значительные конфликты за ресурсы.
- Пропуск
GetQueryExecution, загрузите CSV напрямую из S3. Вызов GetQueryExecution удобен, если вы хотите знать типы данных столбцов, но если вы уже знаете, или вам все равно, чтение данных напрямую может сэкономить вам драгоценные десятки миллисекунд. Если вам нужны типы данных столбца, вы можете получить файл ….csv.metadata, который записывается вместе с CSV-результатом, это недокументированные данные Protobuf, см. здесь и здесь для получения дополнительной информации. - Попросите службу технической поддержки Athena настроить вашу учетную запись. Это может быть не то, что вы можете получить без поддержки более высокого уровня, я не знаю политики этого, и вам нужно начать с разговора с вашим менеджером аккаунта.