Hologres (китайское название интерактивного анализа) — это универсальное хранилище данных в режиме реального времени, разработанное Alibaba Cloud. Эта облачная система объединяет сервисы в реальном времени и сценарии анализа больших данных. Она полностью совместима с протоколом PostgreSQL и легко подключается. с экосистемой больших данных.Одна и та же архитектура данных поддерживает одновременную запись в режиме реального времени, запросы в режиме реального времени и автономный федеративный анализ в реальном времени. Его появление упрощает структуру бизнеса и в то же время предоставляет бизнесу возможность принимать решения в режиме реального времени, позволяя большим данным проявлять большую ценность для бизнеса. С момента создания Alibaba Group до коммерциализации облака, с развитием бизнеса и развитием технологий Hologres также постоянно оптимизирует конкурентоспособность своих основных технологий.От высокопроизводительного механизма хранения до высокоэффективного механизма запросов, высокопроизводительной записи к запросу с высоким QPS и т. д., всесторонняя интерпретация голографов, пожалуйста, продолжайте обращать внимание!Прошлые основные моменты:
- _ Газета ВЛДБ 2020 г.»Alibaba Hologres: A cloud-Native Service for Hybrid Serving/Analytical Processing"_
- Гологр раскрывает:Публично впервые! Представлена базовая технология облачного хранилища данных в реальном времени Alibaba
- Гологр раскрывает:Демистификация облачного механизма хранения Hologres впервые
В этом выпуске мы представим анализ технических принципов высокоэффективного механизма распределенных запросов Hologers.
Являясь передовой практикой интеграции анализа услуг HSAP, механизм запросов Hologres является полностью самостоятельно разработанным механизмом выполнения, основной задачей которого является поддержка всех типов распределенного анализа и сервисных запросов, а также достижение максимальной производительности запросов. Для этого мы используем различные распределенные системы запросов, включая аналитические базы данных, хранилища данных в реальном времени и т. д., и используем преимущества различных аспектов для создания нового механизма выполнения с нуля. Зачем создавать новый механизм запросов с нуля? Существует две основные категории систем распределенного анализа и запросов с открытым исходным кодом:
- Одной из них является традиционная система массовой параллельной обработки, которая может поддерживать общие SQL-запросы, но недостаточно хорошо поддерживает сценарии реального времени, а ее производительность не идеальна.
- Одним из них являются хранилища данных в реальном времени, такие как Apache Druid и ClickHouse, которые специально разработаны и оптимизированы для сценариев реального времени.Они могут лучше поддерживать некоторые распространенные запросы к одной таблице в реальном времени, но производительность сложных запросов относительно низкая.
- Кроме того, основанный на MapReduce движок экосистемы больших данных больше подходит для пакетного ETL, вообще не подходит для онлайн-сервисов и сценариев многомерного анализа, да и производительность у него тоже довольно низкая.
Механизм выполнения Hologres основан на общей архитектуре, которая может поддерживать сложные запросы и вышеупомянутые высокопроизводительные сервисные запросы в реальном времени.Во-первых, реализованы часто используемые сценарии хранилища данных в реальном времени, а внутренний тест используется для убедитесь, что производительность и стабильность превышают производительность и стабильность выделенных хранилищ данных в реальном времени.После других конкурирующих продуктов он будет расширен для поддержки других сложных запросов. В процессе масштабирования, поскольку система неизбежно становится все более и более сложной, Benchmark также используется для поддержания производительности простых запросов в реальном времени без регрессии. Если в существующий механизм запросов внесены улучшения, добиться такого эффекта будет сложно, поскольку многие архитектурные и проектные решения были доработаны, и это затрагивает все тело.
Механизм выполнения Hologres сталкивается со многими проблемами от разработки до внедрения, но он также дает нам возможность комбинировать различные новые разработки в этой области и превосходить существующие системы для достижения высокой производительности для различных типов запросов. Обработка, стоящая за ним, в основном основана на следующих характеристиках. :
- Модель распределенного исполнения: Модель распределенного выполнения, которая взаимодействует с архитектурой разделения хранения и вычислений. План выполнения представлен графом выполнения DAG (направленный ациклический граф), состоящим из асинхронных операторов, которые могут выражать различные сложные запросы и отлично адаптируются к модели хранения данных Hologres, удобной для стыковки с оптимизатором запросов и использования различных запросов. оптимизационные технологии в промышленности.
- Полностью асинхронное выполнение: Сквозная полностью асинхронная структура обработки, которая может избежать узких мест систем с высокой степенью параллелизма, полностью использовать ресурсы и в максимальной степени избежать влияния задержки чтения данных, вызванной разделением систем хранения и вычислений. возможный.
- Векторизация и обработка столбцов: оператор максимально использует векторизованное выполнение при внутренней обработке данных и глубоко интегрирован с механизмом хранения.Благодаря гибкой модели выполнения в полной мере используются различные индексы, а материализация векторов и отложенные вычисления максимальны, чтобы избежать ненужных операций чтения. данные и расчеты.
- Адаптивная инкрементальная обработка: адаптивная пошаговая обработка, которая применяет шаблоны запросов к общим данным в реальном времени.
- Глубокая оптимизация под конкретные запросы: Уникальная оптимизация для некоторых шаблонов запросов.
Каждый модуль будет представлен один за другим ниже.
Модель распределенного исполнения
Hologres — это система, которая может эластично и бесконечно масштабировать объем данных и вычислительную мощность по горизонтали и должна поддерживать эффективные распределенные запросы. Механизм запросов Hologres выполняет распределенный план выполнения, созданный оптимизатором. План выполнения состоит из операторов. Поскольку данные таблицы в Hologres будут распределены по нескольким сегментам в соответствии с ключом распределения, а каждый сегмент может содержать множество сегментов, план выполнения также будет отражать эту структуру и будет распределяться на узел, где находятся данные для выполнения. . Каждый осколок таблицы будет загружен в вычислительный узел, а данные будут кэшированы в памяти узла и локальном хранилище. Поскольку это архитектура, которая разделяет хранилище и вычисления, в случае сбоя узла сегмент его службы может быть перезагружен на любой вычислительный узел, что эквивалентно очистке кеша. Например, относительно простой запрос.
select key, count(value) as total from table1 group by key order by total desc limit 100。
Если это автономная база данных, можно использовать такой план выполнения. Если данные и вычисления распределены по нескольким узлам, требуются более сложные планы выполнения.
В распределенной таблице для более эффективного выполнения и минимизации передачи данных план выполнения может быть разделен на разные фрагменты (фрагменты) и распределен по соответствующим узлам для выполнения, а некоторые операции проталкиваются вниз, чтобы уменьшить вывод данных фрагментами, который может измениться на такой план выполнения:
В зависимости от характеристик данных оптимизатор может генерировать разные планы. Например, если локальная агрегация не приводит к значительному уменьшению объема данных, этот оператор можно опустить. В другом примере, когда ключ является ключом распространения, его можно оптимизировать следующим образом:
Из этих примеров видно, что план выполнения Hologres делится на разные части в соответствии с характеристиками данных, а затем распределяется и выполняется одновременно. Обмен данными между фрагментами осуществляется через оператора Exchange. Более сложные запросы, такие как запросы объединения нескольких таблиц (Join), будут иметь больше фрагментов и более сложные шаблоны обмена данными. Например, следующий SQL
select user_name, sum(value) as total from t1 join t2 on t1.user_id = t2.user_id where … group by user_name order by total limit 100
В Hologres может быть такой план выполнения
Если ключ соединения и ключ распространения совпадают, следующий план выполнения можно оптимизировать, чтобы уменьшить удаленную передачу данных. Правильная установка ключа распределения в соответствии с желаемым запросом может значительно повысить производительность запросов.
В соответствии с условиями фильтрации, статистической информацией и т. д. оптимизатор также может генерировать различные планы выполнения оптимизации, например, включающие динамическую фильтрацию, локальное агрегирование и т. д.
Такой распределенный план выполнения является достаточно общим, чтобы выразить все запросы SQL и некоторые другие запросы. План выполнения также аналогичен большинству систем массовой параллельной обработки (MPP), что упрощает изучение и интеграцию некоторых применимых в отрасли оптимизаций. Немного уникальным является то, что многие экземпляры фрагментов плана запроса выровнены со структурой хранения Hologres, что позволяет эффективно очищать разделы и файлы.
В то же время Hologres реализует ряд инструкций PostgreSQL «Объяснение и Объяснение Анализа», которые могут отображать план выполнения и соответствующую информацию о выполнении в текстовом формате, чтобы пользователи могли сами понять план выполнения и внести целевые корректировки оптимизации SQL.
Полностью асинхронное выполнение
В системах с высокой степенью параллелизма, особенно с большим количеством операций ввода-вывода, частое ожидание или переключение задач являются обычными узкими местами системы. Асинхронная обработка — это проверенный метод, позволяющий избежать этих узких мест и максимально повысить производительность параллельной системы. Вся серверная часть Hologres, включая механизм выполнения, механизм хранения и другие компоненты, единообразно использует асинхронную безблокировочную среду программирования, предоставляемую компонентом HOS (Hologres Operation System), который может максимизировать эффект асинхронного выполнения. Каждый экземпляр фрагмента использует EC (логический блок планирования) HOS, поэтому все операторы и механизмы хранения во фрагменте могут выполняться асинхронно и безопасно получать доступ к большинству ресурсов без блокировок.
Операторы и фрагменты — это такие интерфейсы:
future<> Open(const SeekParameters& parameters, ...)
future<RecordBatchPtr, bool> GetNext(...)
future<> Close(...)
В дополнение к преимуществам общей асинхронной обработки, асинхронный интерфейс оператора лучше позволяет избежать влияния относительно высокой задержки чтения данных на производительность запросов в архитектуре разделения хранения и вычислений и имеет уникальные преимущества для модели выполнения распределенных запросов.
Механизм выполнения DAG в целом можно разделить на модель извлечения данных (например, модель вулкана) и модель передачи (например, модель поэтапного выполнения многих больших данных), каждая из которых имеет свои преимущества и недостатки. Модель асинхронного вытягивания, принятая Hologres, может получить преимущества обеих моделей и избежать их недостатков (на это были поданы заявки на патенты). Возьмите обычное хэш-соединение, чтобы проиллюстрировать:
Модель вулкана может просто извлечь данные b для построения хеш-таблицы, а затем передать данные a без помещения их в память. Однако, когда a или b необходимо прочитать данные, простая реализация должна ждать и не может заполнить ЦП, и необходимо полностью использовать ресурсы, увеличивая параллелизм фрагмента или вводя сложный механизм предварительной выборки, который будет ввести другие производительность.проблема.
Модель передачи данных упрощает одновременное чтение запросов данных и инициирование последующей обработки по завершении, но реализация описанного выше оператора соединения более сложна. Например, после того, как a обработал пакет данных и передал его оператору соединения, но хэш-таблица b не была построена, этот пакет данных необходимо временно сохранить в памяти или на диске, или использовать механизм обратного давления. вводится. Аналогичная проблема возникает на границе Fragment, вызывая некоторое кэширование данных, которое не требуется в модели данных по запросу.
Операторы Hologres и модель асинхронного извлечения данных Fragment могут быть такими же простыми, как модель вулкана, для получения данных из восходящего потока по запросу, и в то же время они могут быть такими же простыми, как модель push-данных для одновременного чтения данных, пока несколько асинхронных данных отправляются в восходящий поток. GetNext, последующая обработка будет запускаться естественным образом, когда обработка восходящего потока будет завершена. Количество и время асинхронного GetNext можно рассматривать как естественный механизм управления потоком, который может эффективно повысить загрузку ЦП и избежать ненужного временного хранения данных.
Hologres реализовал полный механизм запросов с этой асинхронной моделью, которая поддерживает все запросы PostgreSQL.
Обработка столбцов и векторизация
Постолбцовая обработка и векторизованное выполнение являются широко используемыми механизмами оптимизации для аналитических механизмов запросов, которые могут значительно повысить эффективность обработки данных. Hologres не является исключением, попробуйте использовать его, когда вы можете использовать векторную обработку. Hologres также использует колоночное хранилище в памяти. Хранение данных в памяти в столбцах позволяет выполнять больше векторной обработки. Еще одним преимуществом столбчатой организации данных является то, что она более удобна для отложенных вычислений. Например, выберите ..., где a = 1 и b = 2 ..., для пакета данных (обычно соответствующего сохраненной группе строк) a и b, выводимые оператором сканирования Hologres, могут быть информацией a и b читаются лениво. Эта партия a читается при обработке a = 1. Если a=1 не выполняется для всех строк пакета, столбец b пакета вообще не будет прочитан. Однако для некоторых операторов на основе строк, таких как Join, данные, хранящиеся в столбцах, могут привести к большему количеству промахов в кэше ЦП и вызвать большие проблемы с производительностью. Многие механизмы запросов будут вводить преобразование памяти по столбцу и памяти по строке в разных точках, но частое преобразование само по себе принесет много накладных расходов, а переключение столбцов приведет к ненужному чтению вышеупомянутого столбца отложенного чтения, а также некоторые другие проблемы с производительностью.
Адаптивная инкрементальная обработка
Многие приложения для работы с данными в реальном времени часто выполняют запрос повторно в течение разных периодов времени. Например, после открытия страницы индикатора мониторинга она будет выполняться регулярно.select avg(v1) from metrics where d1 = x and d2 = y and ts >= '2020-11-11 00:00:00' and ts < '2020-11-11 03:01:05' and … group by d3 … Такой запрос будет изменен в следующий раз наts < '2020-11-11 00:03:10', опять в следующий разts < '2020-11-11 00:03:15'.
Потоковые или инкрементные вычисления могут очень эффективно обрабатывать такие запросы. Но для таких интерактивных запросов, которые пользователи могут генерировать по своему желанию, обычно невозможно настроить потоковые вычисления или задачи инкрементных вычислений для всех комбинаций. Если запрос просто выполняется каждый раз, может быть большое количество повторяющихся вычислений, что приводит к трате ресурсов и неудовлетворительной производительности.
Hologres в полной мере использует глубокую интеграцию механизмов хранения и вычислительных механизмов, а также функцию, заключающуюся в том, что столбцовое хранение большинства данных в файлах только для чтения может предоставить результаты запроса, содержащие последние записанные данные, при этом максимально избегая повторных вычислений. query Может значительно повысить производительность и сократить использование ресурсов.
Глубокая оптимизация для конкретных шаблонов запросов
Hologres имеет уникальную оптимизацию для некоторых конкретных шаблонов запросов. Вот пример оптимизации Filter Aggregate. Многие приложения для работы с данными требуют открывать столбцы, что эквивалентно динамическому добавлению логических столбцов без изменения схемы таблицы. Например, один столбец представляет собой теги столбца с несколькими значениями (Postgres может использовать тип Array), в котором хранятся значения нескольких логических столбцов, таких как «{c1:v1, c2:u1}». При запросе, если вы используете обычные столбцы, общий тип запроса
-- Q1:
select c1, sum(x) from t1 where c1 in (v1, v2, v3) and name = 'abc' group by c1
При открытых столбцах такой запрос превращается в
-- Q2:
select unnest(tags), sum(x) from t1 where name = 'abc' and tags && ARRAY['c1:v1', 'c1:v2', c1:v3']
group by unnest(tags)
having unnest(tags) in ('c1:v1', 'c1:v2', c1:v3')
Для такого рода запросов Hologres может использовать битовый индекс для быстрого расчета условий фильтрации для получения соответствующих строк, но тогда операция извлечения соответствующих данных из многозначного столбца не может использовать векторную обработку, и производительность не может быть оптимизирована. . После исследования выполнение запроса может быть преобразовано в
Q3:
select 'c1:v1', sum(x) from t1 where tags && ARRAY['c1:v1']
UNION ALL
select 'c1:v2', sum(x) from t1 where tags && ARRAY['c1:v2']
UNION ALL
…
Таким образом, каждая ветвь UNION ALL может только считывать битовый индекс имени и тегов для вычисления условия фильтра, а затем использовать данные столбца x и условия фильтра для выполнения векторного вычисления SUM_IF для получения желаемого результата. Проблема в том, что каждая ветвь должна проходить через t1 и считывать битовый индекс столбца x и столбца name, что приводит к повторяющимся вычислениям. Наконец, введен специальный оператор агрегата фильтра для оптимизации таких общих запросов до максимальной производительности.Вы можете пройти t1 только один раз и удалить повторяющиеся операции.Результат можно получить только векторным вычислением, и нет необходимости читать данные столбца тегов. Измеренная производительность улучшена более чем в 3 раза на столе с десятками ТБ.
Подобная оптимизация, исполнительный механизм Hologres попытается абстрагироваться как более общий оператор, который можно применять к большему количеству сценариев. Оператор Filter Aggregate также является одним из патентов, поданных Hologres.
Суммировать
Механизм выполнения Hologres объединяет почти все наиболее эффективные оптимизации (включая различные типы индексов) родственной распределенной системы запросов в одной архитектуре и вносит уникальные улучшения. Благодаря глубокой интеграции с механизмом хранения можно в полной мере использовать преимущества асинхронной модели и эффективно использовать различные типы индексов для ускорения запросов. Все это в совокупности повысило производительность по сравнению с существующей системой и прошло фактическое испытание по шкале данных Alibaba Double 11. Данные на уровне миллиардов обеспечивают многомерный анализ и внешние услуги, 99,99% запросов могут возвращать результаты в течение 80 мс). и предоставляет распределенные службы запросов HSAP с высоким параллелизмом и высокой производительностью.
В будущем мы запустим серию раскрытий основных принципов технологии Hologres Конкретные планы таковы, пожалуйста, продолжайте обращать внимание!
- Гологр раскрывает:Публично впервые! Представлена базовая технология облачного хранилища данных в реальном времени Alibaba
- Гологр раскрывает:Демистификация облачного механизма хранения Hologres впервые
- Секрет Hologres: углубленный анализ высокоэффективного механизма распределенных запросов (эта статья)
- Hologres раскрывает: основные принципы прозрачного ускорения запросов MaxCompute
- Секрет Hologres: как добиться в сто раз большей скорости синхронизации данных между MaxCompute и Hologres
- Представлены Hologres: как поддерживать высокопроизводительные Upserts
- Hologres раскрывает: как поддерживать сверхвысокий QPS в сценариях онлайн-сервисов
- Демистификация Hologres: как поддерживать запросы с высоким параллелизмом
- Демистификация Hologres: как поддерживать архитектуры высокой доступности
- Демистификация Hologres: как обеспечить изоляцию ресурсов и поддержку множественных нагрузок
- Секрет гологров: принцип и практика использования векторного поисковика Proxima
- Секрет Hologres: Чтение плана выполнения, в десять раз выше производительность запроса
- Демистификация Hologres: как распределенные системы проектируют Shard и Table Group
- Открытие Hologres: как поддерживать больше расширений экосистемы Postgres
- Hologres Reveal: N позирует для высокопроизводительной записи в Hologres
- ......