введение
В ByteDance Presto в основном поддерживает такие сценарии, как специальные запросы, анализ визуализации BI и анализ запросов почти в реальном времени, с ежедневным объемом запросов почти 1 миллион.
- функциональные аспекты
Полностью совместимый с синтаксисом SparkSQL, пользователи могут переходить с SparkSQL на Presto, не чувствуя себя;
- представление
Реализованы оптимизации, такие как изменение порядка соединения и фильтр времени выполнения, а производительность набора данных TPCDS1T была улучшена на 80,5% по сравнению с версией сообщества;
- С точки зрения стабильности
Во-первых, реализована архитектура с несколькими координаторами, которая решает проблему отсутствия у одного координатора в кластере Presto возможности аварийной устойчивости.Время аварийного восстановления контролируется в пределах 3 с. Во-вторых, реализованы статические правила, основанные на гистограмме, и динамические правила, основанные на состоянии времени выполнения, которые могут эффективно выполнять кластерную маршрутизацию и ограничение тока;
- Аспекты работоспособности
Реализована функция History Server, которая может поддерживать отслеживание в реальном времени выполнения одного запроса и общее наблюдение за рабочим состоянием кластера.
Использование платформы движка данных ByteDance OLAP Presto для развертывания
За последние несколько лет механизм обработки данных OLAP компании ByteDance претерпел процесс постепенной конвергенции, а затем сегментации полей и уточненной оптимизации операций. Что касается хранилища, автономные данные в основном хранятся в HDFS, а бизнес-данные и данные онлайн-журналов хранятся в MQ и Kafka. В соответствии с различными типами бизнеса Presto поддерживает специальные запросы и некоторые запросы отчетов BI, SparkSQL отвечает за крупномасштабный комплексный анализ и автономный ETL, а Flink отвечает за очистку и импорт потоковых данных.
Чтобы справиться с растущим спросом на специальные запросы, в 2020 году платформа данных ByteDance представила Presto для поддержки таких сценариев. В настоящее время весь кластер Presto имеет масштаб в десятки тысяч ядер, поддерживая около 1 миллиона запросов запросов в день, покрывая большинство сценариев специальных запросов и некоторые сценарии анализа запросов BI.
Легенда: схема архитектуры развертывания внутреннего кластера Presto ByteDance
На приведенном выше рисунке показана архитектура внутреннего развертывания кластера Presto ByteDance.Он разделен на несколько изолированных кластеров для различных бизнес-потребностей.Каждый кластер развертывает несколько координаторов, которые отвечают за планирование рабочих процессов соответствующего кластера.
Уровень доступа предоставляет единый шлюз, отвечающий за маршрутизацию и текущее ограничение пользовательских запросов. В то же время он также предоставляет вспомогательные компоненты, такие как History Server и Monitor System, для повышения работоспособности и стабильности кластера.
Повышение стабильности и производительности кластера Presto
Для различных бизнес-сценариев и требований к производительности запросов мы разделяем вычислительные ресурсы на независимые кластеры Presto.
Шлюз отвечает за обработку маршрутизации пользовательских запросов.Эта часть функции в основном реализуется с помощью статических правил маршрутизации.Правила маршрутизации в основном включают кластеры, которые разрешены для отправки пользователями, и кластеры, которые понижены и устойчивы к стихийным бедствиям.
Чтобы лучше сбалансировать нагрузку между различными кластерами и полностью и эффективно использовать вычислительные ресурсы, позже была введена стратегия динамической маршрутизации и разгрузки. В процессе выбора маршрутизации эта стратегия будет вызывать Restful API каждого координатора кластера, чтобы получить статус загрузки каждого кластера и выбрать оптимальный кластер для планирования маршрутизации.
Благодаря сочетанию статических правил и динамических политик Gateway обеспечивает баланс рабочих нагрузок между кластерами, предоставляя пользователям единый интерфейс доступа.
Узел Coordinator является основным узлом отдельного кластера Presto и отвечает за доступ и распределение запросов по всему кластеру, поэтому его стабильность напрямую влияет на стабильность всего кластера.
При начальном развертывании в каждом кластере Presto может быть развернут только один координатор.При сбое узла весь кластер будет тратить несколько минут недоступного времени, ожидая автоматического подтягивания узла.
Для решения этой проблемы мы разработали функцию нескольких Координаторов. Эта функция поддерживает развертывание нескольких узлов координатора в одном и том же кластере Presto, и эти узлы находятся в активно-активном резервном состоянии по отношению друг к другу.
Основная идея реализации состоит в том, чтобы использовать Zookeeper для трансформации обнаружения сервисов Coordinator и Worker.
Рабочий получит существующего координатора от Zookeeper и случайным образом выберет его для создания отчетов о сердцебиении.В то же время каждый координатор также может воспринимать существование других координаторов из Zookeeper.
Каждый координатор отвечает за сохранение нагрузки задачи текущего подключенного работника и выполнение запланированного им запроса, а также за предоставление этой информации в виде Restful API; другие координаторы будут получать информацию через эти Restful API при планировании задач Ресурс использование всего кластера выполняет соответствующее планирование задач.
В настоящее время механизм мультикоординатора используется в кластере уже полгода, и время, когда кластер недоступенСокращено с минут до менее 3 с.
Еще одним важным фактором, влияющим на стабильность кластеров Presto, являются чрезвычайно масштабные запросы.
В нерегламентированных сценариях такого рода запросы неизбежны, а поскольку такие запросы будут сканировать большое количество данных или генерировать огромные промежуточные состояния, они будут занимать вычислительные ресурсы кластера в течение длительного времени, что приводит к снижению производительности. весь кластер деградирует.
Для решения этой проблемы мы сначала ввелиПрогнозирование времени запроса на основе правил и затрат.
Прогнозирование времени запроса на основе правил в основном подсчитывает объем входных данных, задействованных в запросе, и сложность запроса для прогнозирования.
Прогнозирование времени запроса на основе стоимости в основном прогнозирует стоимость запроса на основе данных гистограммы, собранных в Каталоге.
Вышеприведенный прогноз может решить некоторые проблемы, но все же есть некоторые неточные прогнозы.Чтобы в дальнейшем справиться с этими ситуациями, мыВведена адаптивная отменаФункции.
Эта функция в основном предназначена для прогнозирования общего времени выполнения запроса путем периодического подсчета объема данных, которые, как ожидается, будут прочитаны запросом, и времени выполнения завершенной задачи после того, как запрос начнет выполняться, и отмены запроса, для которого прогнозируется превысить порог заранее, чтобы избежать растраты вычислительных ресурсов и повысить стабильность кластера.
Кроме того, UI-интерфейс, предоставляемый самим Presto, может хорошо анализировать ситуацию выполнения запроса, но поскольку эта часть информации хранится в памяти координатора, она будет постепенно очищаться по мере накопления количества запросов, что приводит к невозможности получения историческая информация о запросе. .
Для решения этой проблемы мы разработали функцию History Server.
После того, как выполнение запроса будет завершено, координатор сохранит выполнение запроса в постоянном хранилище, а сервер истории загрузит историю выполнения запроса из постоянного хранилища и предоставит точно такие же возможности анализа, как и пользовательский интерфейс Presto. в этой части постоянства Вы также можете установить соответствующую плату мониторинга для наблюдения за состоянием службы кластера.
Оптимизация и практика в разных сценариях
1. Сценарии анализа специальных запросов
До 2020 года специальные запросы в сценариях с большими данными в основном поддерживались Hive/SparkSQL. Для дальнейшей оптимизации производительности запросов и повышения эффективности использования ресурсов, начиная с 2020 года, мы будем широко использовать Presto в производственной среде.
По сравнению со SparkSQL, Presto представляет собой резидентный механизм запросов SQL с архитектурой MPP, который позволяет избежать накладных расходов на запуск Spark Context и приложение ресурсов, а также имеет меньшую сквозную задержку.
По сравнению с Hive/Spark Thrift Server, Presto Coordinator является более зрелым, легким и стабильным, а модель Presto Shuffle с полной памятью может эффективно сократить задержку запросов. Чтобы перенести пользовательские запросы в Presto без ощущения, мы проделали большую работу, чтобы сделать Presto совместимым со SparkSQL на уровне синтаксиса и семантики.
С точки зрения уровня доступа: обеспечивает функцию перезаписи стандартизации SQL. Эта функция может переписать пользовательский SQL в синтаксис SQL, который Presto может поддерживать для выполнения, чтобы базовый механизм был прозрачен для пользователя.
С точки зрения поддержки функций: выполнение Hive UDF поддерживается в Presto, поэтому большое количество UDF, накопленных предыдущими аналитиками данных, может быть выполнено в Presto. Эта функция в основном поддерживает загрузку Hive UDF и UDAF на этапе синтаксического анализа, выполнение преобразования типов для их адаптации к системе типов Presto и, наконец, инкапсуляцию их во встроенные функции Presto для выполнения. Часть этой функции была передана сообществу Presto:
2. Сценарии визуального анализа BI
Еще одним важным сценарием применения Presto в ByteDance является анализ визуализации BI.
Визуальный анализ BI предоставляет функцию визуального взаимодействия для анализа данных.Анализ данных может интуитивно и быстро выполнять анализ данных и генерировать соответствующие диаграммы анализа, что выдвигает более высокие требования к механизму запросов.В этом сценарии значительно улучшается не только количество запросов в секунду, но и механизм запросов, обеспечивающий относительно низкую задержку запросов..
Для решения этих задач мы проделали относительно важную работу -Представлены материализованные представления в Presto.
В этом сценарии запрос SQL часто автоматически генерируется платформой визуализации BI в соответствии с фиксированным шаблоном, а операции визуализации пользователя часто ограничиваются изменениями условий фильтра запроса, измерений агрегации и индикаторов агрегации, которые подходят для приложения. материализованных взглядов.
В функции материализованного представления мы опираемся на опыт многих традиционных баз данных, и работа в основном включает три аспекта:
- Автоматический анализ материализованных представлений—— Он в основном анализирует исторические записи пользовательских запросов и подсчитывает частоту запросов различных данных для автоматической рекомендации и создания материализованных представлений.
- Управление жизненным циклом материализованных представлений—— В основном поддерживать автоматическое обновление и удаление материализованных представлений на уровне раздела.
- Переписать функцию материализованного представления- На основе существующего материализованного представления переписать запрос пользователя, чтобы уменьшить сложность выполнения запроса.
3. Анализ запросов сценариев, близких к реальному времени
Этот сценарий изучался в этом году, в основном для уменьшения задержки каналов передачи данных и повышения своевременности анализа запросов.
В традиционном канале передачи данных на основе ETL бизнес-данные и данные журналов регулярно выгружаются в HDFS через Kafka, а затем несколько задач ETL будут обрабатывать и очищать данные для формирования таблиц Hive на разных уровнях для анализа запросов.
В этой ссылке часто необходимо обновить полный объем данных таблицы.Задача относительно тяжелая, и есть задержка данных более чем на 1 день с онлайн-данными.
Чтобы уменьшить задержку данных, мыПредставлен Hudi для добавочного обновления данных.
В этой ссылке бизнес-данные и данные журналов постепенно записываются в таблицы Hudi с помощью задач потоковой передачи Spark/Flink, и аналитики данных могут напрямую запрашивать эту часть данных. В настоящее время эта ссылка может обеспечить задержку данных на уровне минут.
Наша работа по оптимизации в Presto в основном заключается в том, чтобы извлечь функцию чтения таблиц Hudi из Hive Connector в отдельный Hudi Connector.
во-первых, Hudi Connector лучше поддерживает структурные характеристики таблиц Hudi.Алгоритмы планирования фрагментов, основанные на различных стратегиях, чтобы обеспечить рациональность распределения задач.
в то же время, Hudi Connector оптимизирует управление памятью во время чтения таблицы Hudi MOR,Избегайте OOM рабочих узлов и повышайте стабильность кластера.
Наконец, введение Hudi ConnectorСнижена рабочая нагрузка, связанная с обновлением версии Hudi., который может лучше интегрировать последние функции сообщества Hudi. Мы будем постепенно возвращать эту часть функции сообществу:
Оптимизация внутренней функции Presto ByteDance, представленная в этой статье, теперь прошла через продукт данных Volcano Engine."Комплексная аналитическая служба озера и склада"В направленииВыход на внешний бизнес.Служба аналитики Lakehouse LAS (служба аналитики Lakehouse)Это бессерверная служба обработки и анализа данных, ориентированная на интегрированную архитектуру озер и складов, предоставляющая универсальные вычислительные возможности для хранения массивных данных и возможности интерактивного анализа, полностью совместимая с экосистемами Spark, Presto и Flink, помогающая предприятиям легко анализировать ценность данных. .
печатьпорталчтобы узнать больше о LAS.