Введение

Первоначально Presto был создан в Facebook, чтобы заполнить пробел между запросами в реальном времени и обработкой ETL в Facebook в то время. Основная цель Presto — предоставление интерактивных запросов, которые мы часто называем специальными запросами. Многие компании используют его в качестве механизма вычислений OLAP. Однако, поскольку в последние годы бизнес-сценарии становятся все более и более сложными, в дополнение к сценариям интерактивных запросов многим компаниям также требуется пакетная обработка, однако Presto, как вычислительный механизм MPP, использует базу данных архитектуры MPP для обработки больших объемов данных; наборы данных. Это очень сложная проблема, поэтому общий подход заключается в написании адаптера во внешнем интерфейсе для предварительной обработки SQL. Если это мгновенный запрос, используйте Presto, в противном случае используйте Spark. Эта обработка может в определенной степени решить нашу проблему, но два вычислительных механизма и предыдущая предварительная обработка SQL значительно увеличивают сложность нашей системы.

Чтобы решить эту проблему, PrestoDB запустила такие проекты, как Presto Unlimited и Presto on Spark. О них можно узнать в статьях Presto on Spark: поддержка мгновенных запросов и пакетной обработки и Presto on Spark: расширение Presto. Детали Искры. Сегодня мы поговорим о дороге ETL Trino (PrestoSQL), еще одной ветки Presto. В течение последних шести месяцев сообщество Trino разрабатывало поддержку ETL под кодовым названием Tardigrade, модифицируя код Trino для поддержки ETL.

Что такое проект Тихоходка

Что людям нравится в использовании Trino, так это то, что он быстро выполняет запросы и может решать бизнес-задачи с помощью интуитивно понятных сообщений об ошибках, интерактивного взаимодействия и объединенных запросов. Большой давней проблемой является то, что Trino очень сложно настраивать, настраивать и управлять им для длительных рабочих нагрузок ETL. Вот некоторые проблемы, с которыми вам придется столкнуться:

• Надежное время выполнения. Запросы, которые выполняются часами, могут завершиться неудачей, а их перезапуск с нуля приводит к потере ресурсов и усложняет соблюдение требований ко времени выполнения.
• Экономичный изкластер: для выполнения запроса нам нужен кластер распределенной памяти уровня TB Trino;
• Параллелизм: несколько независимых клиентов могут отправлять запросы одновременно. Некоторые из этих запросов, возможно, придется прекратить и перезапустить через определенный период времени из-за нехватки доступных ресурсов в какой-то момент, что делает время завершения задания более непредсказуемым.

Чтобы решить вышеуказанные проблемы, нам может потребоваться помощь команды экспертов, но для большинства пользователей это невозможно. Цель проекта Tardigrade — предоставить «нестандартное» решение вышеуказанных проблем. Сообщество разработало новую отказоустойчивую архитектуру выполнения, которая позволяет нам реализовать расширенное планирование с учетом ресурсов и детализированные повторные попытки. Вот результаты проекта Tardigrade:

• Когда при длительно выполняющихся запросах возникают сбои, нам не нужно запускать их заново.
• Когда запросам требуется больше памяти, чем доступно в данный момент в кластере, они все равно могут успешно выполняться;
• Когда одновременно отправляется несколько запросов, они могут справедливо распределять ресурсы и работать стабильно.

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

Tardigrade проектпринцип Введение

Trino — это вычислительная машина без сохранения состояния, поэтому для реализации ETL требуется множество модификаций Trino. С точки зрения реализации между Trino и PrestoDB есть некоторые различия. Чтобы поддерживать как ETL, так и запросы в реальном времени, PrestoDB на ранней стадии разработал проект под кодовым названием Presto Unlimited. Он в основном делил таблицу на сегменты. данные в каждом сегменте были независимыми, поэтому их можно вычислить независимо, если вычисление данных одного сегмента не удалось, просто повторите вычисление, связанное с данными сегмента. Эту часть принципа можно найти в разделе Presto в Spark: Поддержка. мгновенный запрос и пакетная обработка, а также Presto в Spark: пройти Spark для расширения Presto и других статей. Хотя Presto Unlimited решает некоторые проблемы, он не решает полностью проблему отказоустойчивости и не улучшает изоляцию и управление ресурсами. Для реализации этих функций, несомненно, потребуется множество модификаций Presto, и эти задачи на самом деле реализованы аналогичным образом в других движках (таких как Spark, Flink и другие вычислительные движки), а затем реализовать их в Presto — это немного заново изобрести велосипед; PrestoDB Сообщество представило Presto в Spark, который представляет собой интеграцию Presto и Spark. Он использует компилятор/оценку Presto в качестве библиотеки классов и использует RDD API Spark для управления встроенной оценкой Presto. реализация аналогична тому, как Google решил встроить запрос F1 в свою структуру MapReduce.

Но, глядя на Trino, идея его реализации отличается от описанной выше. Tardigrade Trino, похоже, реализует основные функции, такие как отказоустойчивость, повтор запроса/задачи и перемешивание непосредственно в Trino. Trino записывает данные восходящего этапа в случайном порядке на диск. Это поддерживает запись данных в AWS A3, Google Cloud Storage, Azure Blob Storage и локальное хранилище файлов (это для тестирования). .