Озеро данных нового поколения: увеличение производительности в 10 раз!
В этой статье мы поговорим о том, как быстро организовать данные, поступающие из разных источников, и добиться при этом высокой производительности запросов.
Около 30 лет назад Билл Инмон определил хранилище данных, как "предметно-ориентированный, интегрированный и энергонезависимый сбор данных, призванный облегчить процесс принятия управленческих решений". Однако, первоначальные хранилища данных не могли хранить необработанные и неструктурированные данные - это и стало первопричиной создания озер данных. В современном мире озеро данных представляет собой совершенно новую парадигму. Это открытая архитектура управления данными, отличающаяся мощными аналитическими возможностями, высокой гибкостью и открытым форматом.
Если бы меня попросили выбрать только одно слово для того, чтобы описать озеро данных нового поколения, я бы выбрал «унификацию»:
- Унифицированное хранилище данных, позволяющее избежать проблем и потенциальных рисков, связанных с избыточным хранилищем и ETL процессами;
- Унифицированное управление данными и метаданными с поддержкой ACID, Schema Evolution и Snapshot;
- Приложение для унифицированных данных, поддерживающее доступ к данным через единый интерфейс для нескольких рабочих нагрузок.
Давайте внимательно рассмотрим архитектуру озера данных. Очевидно, что речь идет не только о форматах таблиц, таких как Apache Iceberg, Apache Hudi и Delta Lake. Важнее то, что озеро данных оснащено высокопроизводительным механизмом запросов, позволяющим извлечь максимальную ценность из имеющихся данных.
Всех пользователей в первую очередь интересуют механизмы запросов, обеспечивающие быстрый и беспрепятственный доступ к наиболее популярным источникам данных. Чего они точно не хотят, так это того, чтобы их данные блокировались в определенной базе данных и были недоступными для других механизмов запросов. Кроме того, пользователям совсем не хочется тратить дополнительное время на передачу данных и преобразование их формата.
Поэтому механизм запросов должен отвечать на следующие вопросы:
- Как обеспечить доступ к наибольшему количеству источников данных и получить метаданные наиболее легким способом?
- Как повысить производительность запросов к данным, поступающим из различных источников?
- Как обеспечить более гибкое планирование ресурсов и управление рабочей нагрузкой?
У Apache Doris есть ответы на эти вопроса. Речь идет о базе данных OLAP, работающей в режиме реального времени, которая стремиться к тому, чтобы стать унифицированным шлюзом анализа данных, что подразумевает возможность легкого подключения к различным СУБД, хранилищам данных и механизмам озер данных (таким как Hive, Iceberg, Hudi, Delta Lake и Flink Table Store), а также обеспечение быстрой записи данных и запросов к этим разнородным источникам данных. Оставшаяся часть данной статьи посвящена подробному объяснению методов Apache Doris по трем вышеупомянутым направлениям: получение метаданных, оптимизация производительности запросов и планирование ресурсов.
Сбор метаданных и доступ к данным
Apache Doris 1.2.2 поддерживает широкий спектр форматов озер данных, а также доступ к данным из различных внешних источников данных. Кроме того, с помощью табличных функций пользователи могут напрямую анализировать файлы в объектном хранилище или HDFS.
Apache Doris делает все необходимое для сбора метаданных, а также для получению доступа к данным из самых разных источников.
Сбор метаданных
Метаданные состоят из информации о базах данных, таблицах, разделах, индексах и файлах из источника данных. Таким образом, метаданные из различных источников данных имеют разные форматы и шаблоны, что усложняет объединение метаданных. Идеальный сервис сбора метаданных должен включать в себя следующее:
- Структуру метаданных, которая может вмещать разнородные метаданные;
- Расширяемую структуру подключения к метаданным, обеспечивающую быстрое и недорогое подключение к данным;
- Надежный и эффективный доступ к метаданным, поддерживающий получение метаданных в режиме реального времени;
- Настраиваемые службы аутентификации для взаимодействия с внешними системами управления правами доступа.
Структура метаданных
Предыдущие версии Doris поддерживали двухуровневую структуру метаданных: база данных и таблица. В результате пользователи должны были осуществлять маппинг для внешних баз данных и таблиц один за другим, что весьма неудобно. В Apache Doris 1.2.0 появилась функция Multi-Catalog. Теперь Вы можете сопоставлять внешние данные на уровне каталога, что означает следующее:
- Вы можете делать сопоставления со всем внешним источником данных и получить из него все метаданные;
- Вы можете управлять свойствами указанного источника данных на уровне каталога (подключение, права доступа и сведения о приеме данных), а также с легкостью обрабатывать несколько источников данных.
В Doris данные попадают в два типа каталогов:
- Внутренний каталог: существующие базы данных Doris и таблицы принадлежат Внутреннему каталогу.
- Внешний каталог: используется для взаимодействия с внешними источниками данных. Например, Внешний каталог HMS можно подключить к кластеру, управляемому Hive Metastore, а Внешний каталог Iceberg можно подключить к кластеру Iceberg.
Для переключения каталогов можно использовать команду SWITCH
. Вы также можете выполнять федеративные запросы, используя полные имена. Например:
SELECT * FROM hive.db1.tbl1 a JOIN iceberg.db2.tbl2 b
ON a.k1 = b.k1;
Расширяемая структура подключения к метаданным
У пользователей также есть возможность добавлять новые источники данных при помощи команды CREATE
CATALOG
:
CREATE CATALOG hive PROPERTIES (
'type'='hms',
'hive.metastore.uris' = 'thrift://172.21.0.1:7004',
);
В данный момент Apache Doris поддерживает следующие сервисы метаданных:
- Hive Metastore
- Alibaba Cloud Data Lake Formation
- AWS Glue
Она позволяет разработчикам, которые хотят подключиться как можно к большему количеству источников данных, сделать это с помощью Внешнего каталога. Для этого им нужен только лишь интерфейс доступа.
Эффективный доступ к метаданным
Доступ к внешним источникам данных зачастую ограничен условиями сети и ресурсами данных. Поэтому для того, чтобы гарантировать надежность, стабильность и своевременность доступа к метаданным, механизм запросов данных должен приложить дополнительные усилия.
Эффективный доступ к метаданным в Doris осуществляется за счет мета кэша (Meta Cache), который включает в себя кэш схемы (Schema Cache), кэш раздела (Partition Cache), а также кэш файла (File Cache). Это означает, что Doris может отвечать на запросы метаданных по тысячам таблиц за миллисекунды. Кроме того, Doris поддерживает ручное обновление метаданных на уровне каталога/базы данных/таблицы. Между тем, она также обеспечивает и автоматическую синхронизацию метаданных в хранилище метаданных Hive, поэтому любые изменения могут быть обновлены в течение нескольких секунд.
Пользовательская авторизация
Как правило, внешние источники данных поставляются вместе со своим сервисом управления правами доступа. Многие компании (такие, как Apache Ranger) используют один единственный инструмент для предоставления авторизации для всех своих многочисленных систем управления данными. Doris использует плагин пользовательской авторизации. Как пользователь, вначале Вы должны указать плагин авторизации для вновь созданного каталога, только после этого Вы сможете легко осуществлять авторизацию, аудит и шифрование данных в Doris.
Доступ к данным
Doris поддерживает доступ к внешним системам хранения данных, включая HDFS и объектное хранилище S3:
Оптимизация обработки запросов
После того, как путь к внешним данным открыт, механизм запросов начинает ускорять запросы данных. В случае с Apache Doris усилия будут приложены для чтения данных, механизма выполнения и оптимизатора.
Чтение данных
Чтение данных в удаленных системах хранения часто ограничивается задержкой доступа, параллелизмом и пропускной способностью ввода-вывода, поэтому лучше уменьшить частоту считывания.
Считыватель форматов данных
Повышение эффективности считывания данных влечет за собой оптимизацию чтения файлов Parquet и файлов ORC, являющихся наиболее часто встречающимися файлами данных. Doris провела рефакторинг своего считывателя данных, который настраивается в зависимости от формата данных. Рассмотрим в качестве примера считыватель файлов Parquet:
- Уменьшает необходимость преобразования данных: может напрямую конвертировать файлы в формат хранения Doris или в другой необходимый формат;
- Интеллектуальное индексирование с большей степенью детализации: поддерживает индекс страниц для файлов Parquet, поэтому может использовать интеллектуальное индексирование для фильтрации страниц;
- Predicate pushdown и поздняя материализация: сначала считываются столбцы с фильтрами, а затем считываются другие столбцы отфильтрованных строк. Это значительно уменьшает объем чтения файлов, поскольку позволяет избежать чтения нерелевантных данных;
- Меньшая частота считывания: за счет высокой пропускной способности и низкого уровня параллелизма удаленного хранилища считыватель объединяет несколько считываний данных в одно, что значительно повышает общую эффективность считывания данных.
Кэш файлов (File Cache)
Doris кэширует файлы из удаленного хранилища на локальные высокопроизводительные диски, чтобы повысить производительность чтения данных. Кроме того, были разработаны и добавлены две новые функции, которые делают запросы к удаленным файлам такими же быстрыми, как и запросы к локальным файлам:
- Block cache: поддерживает block cache удаленных файлов и может автоматически регулировать размер блока от 4 КБ до 4 МБ в зависимости от запроса. Подобный метод уменьшает амплификацию чтения/записи и сокращает задержку чтения в холодных кэшах;
- Согласованное хэширование для кэширования: Doris применяет согласованное хеширование для управления расположением кеша и планирования сканирования данных. Таким образом, база данных предотвращает сбои кеша, а также увеличивает частоту попаданий в кэш и стабильность функционирования службы запросов.
Механизм выполнения
Конечно же, разработчикам совсем не хочется перестраивать все общие функции для каждого нового источника данных. Вместо этого им гораздо удобнее было бы повторно использовать векторизованный механизм выполнения и всех операторов Doris в сценарии Lakehouse. Поэтому Doris провела рефакторинг узлов сканирования:
- Разделите логику на уровни: Все запросы к данным в Doris, в том числе и к внутренним таблицам, используют одни и те же операторы, такие как Join, Sort и Agg. Единственная разница между запросами к внутренним и внешним данным заключается в доступе к данным. В Doris все, что выше узлов сканирования, следует той же логике запроса, в обратном случае о доступе к различным источникам данных позаботятся классы реализации;
- Используйте общую структуру для операторов сканирования: Разные источники данных имеют много общего, например, логику разделения задач, планирование подзадач и операций ввода-вывода и т.д. Поэтому Doris использует интерфейсы для их обработки. Затем она использует единую логику планирования для всех подзадач. Планировщик отвечает за все задачи сканирования в узле. Обладая всеобъемлющей информацией об узле, планировщик может осуществлять детальное управление. Такой подход позволяет легко подключить новый источник данных к Doris, на что у разработчика уйдет всего неделя работы.
Оптимизатор запросов
Doris поддерживает ряд статистических данных из различных источников данных, включая Hive Metastore, Iceberg Metafile и Hudi MetaTable. Она также усовершенствовала модель затрат на основе характеристик различных источников данных, чтобы расширить возможности планирования запросов.
Производительность
Мы протестировали Doris и Presto/Trino в ClickBench и в TPC-H. Получили следующие результаты:
Как видите, при тех же вычислительных ресурсах и том же наборе данных Apache Doris требуется гораздо меньше времени для ответа на SQL-запросы по сравнению с Presto/Trino (производительность выше в 3-10 раз).
Управление рабочей нагрузкой и эластичные вычисления
Запросы к внешним источникам данных не требуют внутренней памяти Doris, что открывает возможность для эластичных вычислений. Apache Doris 2.0 планирует реализовать Elastic Compute Node, предназначенный для поддержки запросов к внешним источникам данных.
Вычислительные узлы без сохранения состояния открыты для быстрого масштабирования, поэтому пользователи могут с легкостью справляться с рабочими нагрузками запросов во время пиков и спадов и находить баланс между производительностью и стоимостью. Кроме того, Doris оптимизирована для управления Kubernetes и планирования узлов. Теперь главные узлы могут автоматически управлять подключением и отключением эластичных вычислительных узлов, поэтому пользователи могут без труда управлять рабочими нагрузками своих кластеров в облачных и гибридных сценариях.
Use Case
Apache Doris была принята финансовым учреждением по управлению рисками. Витрина данных, построенная на Greenplum и CDH, которая использовалась учреждением ранее, больше не подходила ввиду возросших требований пользователей по скорости обработки запросов. В 2022 году они включили Apache Doris в свой конвейер обработки данных и приложений, что позволило им выполнять федеративные запросы в Elasticsearch, Greenplum и Hive. Вот несколько основных моментов из отзывов пользователей:
- Doris позволяет создать всего один каталог Hive, сопоставимый с десятками тысяч внешних таблиц Hive, и быстро обрабатывать запросы;
- Doris позволяет выполнять федеративные запросы в режиме реального времени с использованием каталога Elasticsearch, при этом время отклика исчисляется в миллисекундах;
- Doris позволяет разделить ежедневную пакетную обработку данных и статистический анализ, что значительно снижает потребление ресурсов и повышает стабильность работы системы в целом.