Кэширует ли Presto промежуточные результаты из коробки?

Presto имеет несколько коннекторов. Хотя соединители реализуют операции чтения и записи, из всех читаемых мной руководств кажется, что они обычно используются в качестве источников данных только для чтения. Например, netflix. имеет «10 петабайт» данных на Amazon S3, и они явно заявляют, что на рабочих узлах Presto не используется диск (и HDFS). Заявленный вариант использования - это «специальные интерактивные» запросы.

Кроме того, Amazon Athena по сути является S3 + Presto и имеет аналогичные варианты использования.

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

Пример использования 1. Я часто выполняю один и тот же запрос, например для отображения метрики на панели инструментов. Избегает ли Presto повторного сканирования уже «известных» точек данных?

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

Или, если это не так, можно ли мне посоветовать где-нибудь хранить промежуточные результаты (например, CREATE TABLE AS ...)?


person Jan    schedule 09.03.2017    source источник


Ответы (3)


Насколько мне известно, промежуточного уровня неявного кеширования нет. Когда вы используете HDFS в своем кластере, вы, несомненно, выиграете от дисковых кешей ОС, поэтому следующий запуск запроса будет быстрее, но вы не получите мгновенных кешированных результатов. Аналогичное кэширование на уровне блоков данных может применяться и к S3.

Как правило, никакая система разумного размера не может просеять 10 петабайт данных, поскольку чтение всех этих данных займет много времени. Однако данные можно разделить, чтобы Presto более или менее знала, какие фрагменты данных необходимо сканировать. Когда разбиение согласуется с условиями запроса (например, вы разделяете данные по данным и запрашиваете самые свежие данные), это может работать очень хорошо.

Если ваши данные не разбиты на разделы так же, как вы запрашиваете, и вы не хотите повторно разбивать их по-другому, сохранение временных результатов с помощью create table ... as select имеет большой смысл. Вы также можете хранить такие временные таблицы, используя некоторое хранилище в памяти, например raptor (в настоящее время не документировано) или коннекторы memory для еще более быстрого доступа.

Некоторые советы для начинающих по разделению, настройке хранилища и запросам вы можете найти на странице https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/.

person Piotr Findeisen    schedule 01.04.2017
comment
Спасибо, ссылка, которую вы предоставили, помогает: если разделение данных является частью конфигурации источника данных и запросы согласованы с этим разделением, то, конечно, Athena / Presto может ответить на запрос при чтении только подмножества данные. - person Jan; 04.04.2017

Для самого Presto нет уровня кэширования данных. Честно говоря, я не думаю, что предлагаемые вами функции должны быть предоставлены Presto в качестве механизма аналитики SQL. Для обоих упомянутых вами случаев использования я предлагаю развернуть Alluxio вместе с Presto в качестве слоя кеширования, чтобы помочь:

Пример использования 1. Я часто выполняю один и тот же запрос, например для отображения метрики на панели инструментов. Избегает ли Presto повторного сканирования уже «известных» точек данных?

В качестве уровня кэширования Alluxio может обнаруживать схему доступа к данным из Presto (или других приложений) и принимать решения о кэшировании / удалении для обслуживания наиболее часто используемых данных на уровне памяти (в зависимости от вашей конфигурации это может быть SSD или HDD). Это поможет, когда доступ к данным не согласован.

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

Имея больше знаний о ваших входных данных, вы можете применять политики данных в Alluxio для (1) предварительной загрузки данных (общих подзапросов) в пространство кэширования, (2) установки TTL для удаления данных из кэширующего пространства Alluxio, чтобы освободить место для других горячих данных, (3) установить политики кэширования для определенного входного пути (например, CACHE на определенных путях, NO CACHE на некоторых других путях).

Дополнительные советы по запуску стека Presto / Alluxio: https://www.alluxio.io/blog/top-5-performance-tuning-tips-for-running-presto-on-alluxio-1/

person apc999    schedule 27.08.2019

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

Файловая система Alluxio служит Presto Hive Connector в качестве независимой файловой системы с распределенным кешированием поверх HDFS или хранилищ объектов, таких как AWS S3, GCP, хранилище BLOB-объектов Azure. Пользователи могут понимать использование кеша и управлять кешем явно через интерфейс файловой системы. Например, можно предварительно загрузить все файлы в каталог Alluxio, чтобы подогреть кеш для запросов Presto, и установить TTL (время жизни) для кэшированных данных, чтобы освободить емкость кеша.

Служба структурированных данных Alluixo взаимодействует с Presto как с каталогом, так и с файловой системой кэширования на основе Option1. Этот вариант предоставляет дополнительные преимущества в дополнение к варианту 1 с точки зрения беспрепятственного доступа к существующим таблицам Hive без изменения расположения таблиц в Hive Metastore и дальнейшей оптимизации производительности за счет консолидации множества небольших файлов или преобразования форматов входных файлов.

Источник: Presto Alluxio Cache Service

person Sharhabeel Hamdan    schedule 19.10.2020