Архитектура Doris: FE и BE, хранение данных и выполнение запросов
Apache Doris представляет собой мощную аналитическую СУБД для больших объемов данных в формате OLAP. Она построена по принципу мепп-архитектуры: фронтенд (FE) отвечает за метаданные, планирование запросов и контроль доступа, а бэкенд (BE) выполняет хранение данных и вычисления. В Doris данные разделены на планшеты (таблетки), которые распределяются по узлам BE и обрабатываются параллельно несколькими процессорами, что обеспечивает масштабируемость и высокую скорость агрегаций и фильтраций на больших датасетах. В данной главе мы познакомимся с архитектурой Doris, разберем отличие FE и BE, механизм хранения данных и выполнение запросов, дадим практические примеры использования как для открытого ПО, так и в рамках российского контекста экосистемы обработки данных, обсудим риски внедрения и ограничения, а также приведем подробный FAQ.
Архитектура Doris: FE и BE
Frontend (FE)
- Роль: FE служит каталогом метаданных, координатором планирования и контроллером безопасности. Он хранит схему базы, определения таблиц, информации о разделах и распределении данных, а также координирует выполнение запросов между BE.
- Характеристики: FE не предназначен для длительного хранения больших объемов пользовательских данных. Основная функция FE — держать «каркас» базы, версионирование схем, доступ к метаданным и создание/изменение объектов.
Backend (BE)
- Роль: BE выполняет физическое хранение данных и вычисления над ними. Разделенной логикой: данные в Doris разбиты на планшеты (tablet), которые размещаются на разных BE-узлах. Каждый BE отвечает за хранение конкретной части данных и выполнение соответствующих ей подзапросов.
- Характеристики: BE реализует вычислительный движок, чтение и запись данных, применения фильтров и агрегаций, а также репликацию и отказоустойчивость на уровне планшетов.
Как работает взаимодействие FE и BE
- Запрос пользователя сначала попадает на FE, где он парсится, валидируется и формируется план выполнения. FE может выполнить лексическую и синтаксическую проверку, применить привязку к метаданным и определить распределение работы по BE.
- План выполнения передается в BE, где вычислительная часть параллелится по планшетам и узлам. BE обрабатывает фильтры, объединение данных и агрегации, возвращая результат FE.
- FE формирует итоговый ответ и возвращает его пользователю или клиентскому приложению.
- Весь процесс максимально распараллелен и ориентирован на минимизацию задержек за счет распределения по узлам и эффективного использования памяти и кэширования.
Хранение данных и структура хранения
Таблицы и распределение
- Таблицы в Doris создаются с распределением по хешу и количеством_BUCKETS (bucket count). Это обеспечивает равномерное распределение данных по BE-узлам и эффективную параллельную обработку.
- Подразделение по Partition By может быть реализовано по диапазонам дат или по другим ключам, что позволяет эффективнее удалять старые данные, выполнять агрегации по временным интервалам и минимизировать сканируемый объем.
Tablet-структура и репликация
- Данные хранятся в виде планшетов (tablet), которые являются единицами физического хранения и вычисления. Планшеты реплицируются между BE-узлами для обеспечения отказоустойчивости и высокой доступности.
- Репликации позволяют выдержать отказы отдельных узлов без потери данных и без остановки сервиса.
Форматы хранения и сжатие
- Doris использует колоночное хранение внутри планшетов. Это позволяет эффективно выполнять сканирование только нужных столбцов и улучшает компрессию, что сокращает объем передаваемых данных и ускоряет агрегации.
- Данные хранятся на устойчивых носителях — локально на узлах BE или в распределенном хранилище (например, S3/OSS/ HDFS). Doris поддерживает конфигурацию хранения так, чтобы catering под нужды компаний с визией локального и облачного хранения.
Механизмы оптимизации и индексация
- Принцип снижения объема данных — даунскейлинг через отбор по фильтрам (predicate pushdown), исключение неинтересующих столбцов (column pruning) и применение Bloom фильтров для раннего отсечения планшетов.
- Doris поддерживает материализованные представления и предопределенные вычисления для ускорения повторяющихся запросов.
Манипуляции схемой, миграции и безопасность
- FE хранит схему и метаданные, а также обеспечивает контроль доступа. Когда структура таблиц меняется, FE управляет изменениями в каталоге, а BE адаптирует физические данные к новой схеме.
- Безопасность реализуется через механизмы аутентификации и авторизации FE, а также контроль доступа к данным на уровне пользователей и ролей.
Выполнение запросов: планирование, оптимизация и выполнение
Этапы выполнения запроса
- Парсинг и валидация на FE: синтаксис, типы данных, разрешения.
- Логический план: FE строит план выполнения и определяет, какие операции будут выполняться на BE.
- Физический план и оптимизация: FE применяет правила оптимизации (например, выбор присоединения, распределение по планшетам, порядок операций) и формирует физический план для распределения задач между BE.
- Распределение задач: BE получает фрагменты плана, раскладывает их по узлам и параллельно выполняет сканы, соединения, агрегации.
- Сбор результатов: BE возвращает частичные результаты в FE, который затем формирует итоговый набор данных и отправляет клиенту.
Технические особенности
- В Doris применяется векторизованный движок выполнения, который эффективно обрабатывает столбцовые данные и ускоряет агрегации.
- Фильтры и предикаты pushdown работают на уровне строк и столбцов, что позволяет существенно сократить объем сканируемых данных.
- Распределение по HASH и PARTITION BY позволяют локализовать обработку и снизить пересечения между узлами.
- Materialized views и агрегаты по умолчанию могут ускорять повторяющиеся запросы, особенно если они охватывают крупные временные рамки и сжатый набор измерений.
Практические примеры
Практическая постановка задач и реализации на базе Doris, примеры инфраструктуры и типовых сценариев
1) Простой аналитический кейс для открытого ПО
- Сценарий: онлайн-магазин собирает логи заказов и действий пользователей. Цель — быстрые агрегации по регионам и датам, а также детализированные фильтры по каналам продаж.
- Архитектура: FE-кластер из 3 узлов, BE-кластер из 6 узлов; данные хранятся в S3. Распределение по HASH на идентификаторе пользователя, partitions по дате заказа.
- Ингестия: данные сначала грузятся через брокер (Broker Load) из файлов Parquet в S3; периодическая загрузка через Routine Load обеспечивает непрерывный поток новых данных.
- Пример модели данных: таблица orders с колонками order_id, user_id, region, order_date, amount, channel.
- Пример запроса: выбрать суммарный объем продаж по региону за последние 30 дней и сравнить с предыдущим периодом; дополнительно группировать по каналу продаж.
- Результат: Doris обеспечивает быструю агрегацию за счет колоночного хранения и эффективной фильтрации по дате и региону.
- Вывод: легко масштабировать за счет добавления узлов BE и балансировки нагрузки; инфраструктура на открытом ПО хорошо подходит для стартапов и проектов с ограниченными бюджетами.
2) Интеграция с инфраструктурой на основе российских инструментов
- Сценарий: крупная аналитическая платформа в российском контексте, где требуется локальная обработка данных, совместимая с открытым ПО и русскоязычной документацией.
- Архитектура: Doris в связке с инструментами оркестрации (например, Apache Airflow), мониторингом через Prometheus и Grafana. База данных совместно с ClickHouse служит источником или альтернативой для разных задач анализа.
- Практическая особенность: в российских дата-экосистемах часто активно используются ClickHouse из-за зрелости и широкого коммьюнити. Doris может быть применен как альтернатива для сложных аналитических запросов, где требуется другой стиль планирования, возможность дельного распределения и особые сценарии хранения. В этом случае можно организовать гибридную архитектуру: Doris для крупных агрегаций и вторичных измерений, ClickHouse — для высокоскоростных точечных запросов.
- Пример сценария: загрузка данных из русского источника в Doris, обработка сложных временных и региональных агрегатов, затем экспорт агрегированных представлений в ClickHouse для оперативной визуализации.
- Вывод: сочетание Doris и российских инструментов (ClickHouse и локальные решения для визуализации и оркестрации) может дать гибкость и устойчивость архитектуры в условиях локальных требований к хранению данных, языковой поддержки и интеграций.
3) Примеры использования с открытым ПО и интеграциями
- Инструменты: Apache Airflow для оркестрации загрузок и обновления материализованных представлений, Grafana или Superset для дашбордов, Kafka и Stream Load для потоковой загрузки.
- Архитектура: FE 3 узла, BE 6 узлов; данные из Kafka поступают в Doris через Stream Load или Routine Load, регулярно обновляются временные серии и агрегаты.
- Взаимодействие с аналитикой: формируются отчеты по ключевым измерениям; Doris обеспечивает змейку по большим временным окнам и множество условий фильтрации.
- Вывод: открытое ПО упрощает внедрение, мониторинг и масштабирование, обеспечивая прозрачность в работе анализа.
4) Практическая рекомендация по проектированию схемы
- Разделение по времени:_partition_by_ по дате и годам упрощает архивирование и удаление устаревших данных.
- Хеш-распределение: выбор ключа hashed_distribution_col и величины bucket поддерживает балансировку нагрузки.
- Типы данных и конверсия: выбирать совместимые типы данных и минимизировать использование больших строковых полей в критичных путях запроса.
- Материальные представления: использовать их для ускорения частых запросов на сводные данные.
- Интеграции: строить конвейеры загрузки и обновления через однозначные шаги, документируя этапы и мониторинг.
Технические детали
Архитектурные компоненты и операционная практика
Архитектура кластера
- FE-кластер обеспечивает высокую доступность и устойчивость к сбоям. Часто FE размещается в режиме активного/пассивного или кластера из нескольких узлов.
- BE-кластер отвечает за хранение и вычисления. Он масштабируется горизонтально: добавление узлов BE увеличивает емкость и пропускную способность обработки запросов.
- Метаданные хранятся в каталоге FE, который поддерживает версионирование схем и объектов, а также управление правами доступа.
Хранение и данные
- Колонарное хранение внутри планшетов, эффективная компрессия и префетчинг данных.
- Таблицы создаются с параметрами DISTRIBUTED BY HASH и PARTITION BY, что позволяет оптимизировать сканы и ускорить агрегации.
- Репликация планшетов обеспечивает отказоустойчивость и устойчивость к сбоям отдельных узлов.
Ингестия данных
- Broker Load: загрузка данных через брокеры (HDFS/S3 и т. д.) из внешних хранилищ.
- Stream Load: потоковая загрузка данных в реальном времени через HTTP/торапровайдеры к BE-узлам.
- Routine Load: периодически-автоматическая загрузка из потоковых источников (например, Kafka) с поддержкой повторной отправки и обработки ошибок.
Выполнение запросов и оптимизации
- Параллельная обработка: запросы распараллеливаются по планшетам и узлам BE.
- Predicate pushdown: фильтры применяются как можно раньше, чтобы сузить сканируемый объем.
- Column pruning: выбираются только необходимые столбцы.
- Bloom-фильтры и статистика: используются для сокращения количества посещаемых планшетов.
- Материализованные представления: ускорение повторных запросов и сложных аггрегаций.
- Архитектура поддержки транзакций: Doris поддерживает транзакции на уровне таблиц, но в OLAP-предикате характер транзакций может быть ограничен. Важно планировать политику согласованности на уровне проекта.
Безопасность и администрирование
- Аутентификация и авторизация пользователей на FE, контроль доступа к данным на уровне таблиц и столбцов.
- Мониторинг и логирование: KPI производительности, задержки, использование CPU/памяти и доступ к данным.
- Обновления и обзоры схемы: миграции схемы проходят через FE с актуализацией метаданных и миграцией данных в BE.
Риски и ограничения
Архитектурные риски
- FE как узел, содержащий метаданные и планирование, может стать узким местом в сценариях с очень высокой частотой запросов. Необходимо обеспечить надлежащее резервирование FE и мониторинг.
- Репликация планшетов и консистентность в распределенных конфигурациях требуют внимательного управления и мониторинга. При большом объеме данных и высокой ingest-активности возможны задержки в консистентном представлении.
Ограничения функциональности
- Doris является мощной аналитической СУБД, но не всегда имеет полную функциональность как у некоторых конкурентных решений в области обработки данных (например, в части специфических RP-подзапросов, некоторых типов индексов, сложной репликации на уровне таблиц и транзакций). В зависимости от сценария возможно потребуются обходные решения или компромиссы в рамках архитектуры.
Инструменты и интеграции
- В экосистеме Doris активно развиваются интеграции, но уровни поддержки некоторых инструментов могут быть менее зрелыми по сравнению с самыми устоявшимися решениями. Необходимо планировать дорожную карту обновлений и тестирования совместимости.
Масштабирование и производительность
- Масштабирование требует правильного проектирования схеме и планирования ресурсоемких операций: выбор числа реплик, bucket-количества, паттернов агрегаций и индексов. Неправильные параметры могут привести к деградации производительности.
Стоимость владения и операционные риски
- Внедрение Doris требует поддержания кластера FE и BE, мониторинга и регулярного обслуживания. Это связано с затратами на администрирование, обновления, а также с требованиями к устойчивости к сбоям и резервному копированию.
Российские условия и локальные требования
- В контексте локальных требований к хранению данных, нормативов по обработке персональных данных и локализации сервисов, важно обеспечить соблюдение регламентов и доступность инфраструктуры в рамках российского законодательства. Возможна необходимость использования локальных дата-центров или réglementation по хранению данных в рамках государственной политики.
Выводы
- Doris — это мощная архитектура для аналитических задач с разделением ролей FE и BE, что обеспечивает гибкость, масштабируемость и высокую производительность. FE отвечает за метаданные и планирование, BE — за хранение и вычисления.
- Модель хранения данных в планшетах с колоночным форматом и продуманной стратегией распределения обеспечивает эффективное сканирование больших наборов данных и низкие задержки на агрегированном анализе.
- Практические сценарии показывают, что Doris хорошо подходит для крупных аналитических проектов, где нужно быстро наращивать мощность кластера, настраивать гибкие схемы разбиения данных и эффективно загружать данные из внешних источников.
- Важно учитывать риски: узкие места FE, требования к мониторингу, ограничения функциональности и операционные затраты. Эффективное внедрение требует продуманного дизайна архитектуры, тестирования и планирования изменений в схемах и конвейерах.
- В российских условиях Doris может быть частью смешанной архитектуры вместе с российскими решениями (например, ClickHouse) для достижения баланса между скоростью, функциональностью и локальными требованиями к инфраструктуре и поддержке.
Вопрос–Ответ (FAQ)
1) В чем основное отличие Doris между FE и BE?
FE отвечает за метаданные, каталог объектов, авторизацию и планирование запросов. BE хранит данные и выполняет вычисления. Взаимодействие между ними обеспечивает полноценную обработку запросов: FE планирует, BE исполняет и возвращает результаты.
2) Как Doris хранит данные и что такое планшеты?
Данные в Doris разбиваются на планшеты (tablet), которые хранятся на узлах BE. Планшеты реплицируются для отказоустойчивости и обеспечивают параллельную обработку запросов. Данные внутри планшета хранятся в колоночном формате, что улучшает компрессию и скорость сканирования.
3) Какие способы загрузки данных существуют в Doris?
Doris поддерживает несколько путей загрузки: Broker Load — загрузка через внешнее хранилище (HDFS, S3 и т. п.); Stream Load — потоковая загрузка через HTTP/потоки; Routine Load — автоматизированная периодическая загрузка из потоковых источников, например Kafka. Это позволяет строить конвейеры данных с разной задержкой и порядком обновления.
4) Какие механизмы оптимизации запросов имеются в Doris?
Прежде всего predicate pushdown и column pruning, что позволяет раннее отсечение планшетов и чтение только необходимых столбцов. Bloom-фильтры помогают дополнительно сузить число читаемых планшетов. Materialized views ускоряют повторяющиеся запросы. Векторизованный движок повышает производительность агрегаций и сканирования.
5) Какие ограничения стоит учитывать при внедрении Doris?
FE может стать узким местом при очень высоком уровне параллелизма запросов; требуется корректная настройка HA и мониторинга FE. Нельзя полагаться на полный функционал некоторых продвинутых функций, которые встречаются в других системах; синхронизация схем и миграции требуют продуманности. Интеграции с некоторыми инструментами могут требовать дополнительной доработки. В условиях локализации данных и нормативов важно обеспечить соответствие требованиям к хранению и обработке данных.
6) Как Doris сочетается с российскими аналитическими решениями?
Doris может быть частью гибридной архитектуры вместе с российскими инструментами обработки данных (например, ClickHouse). В таком случае Doris применяется для сложных аналитических задач и больших сводных таблиц, а ClickHouse — для высокоскоростного выполнения отдельных запросов или для конкретных рабочих нагрузок. Интеграция с Airflow, Grafana и системами мониторинга упрощает создание сложных конвейеров и дашбордов.
7) Какие критерии выбора схемы распределения данных?
Важно учитывать размер дата-сета, частоту обновления, тип запросов и требования к задержке результатов. Распределение по HASH на ключах обеспечивает равномерную загрузку между BE-узлами. PARTITION BY помогает управлять архивированием и быстро фильтровать данные по времени. Правильная настройка bucket-количества и partitioning существенно влияет на производительность.
8) Какие типичные сценарии лучше всего подходят для Doris?
Аналитика и агрегации по большим временным рядам, многомерный анализ по разным измерениям (регион, канал продаж, дата), регулярные отчеты и панели мониторинга с большими объемами данных, а также сценарии, где требуется параллельная обработка больших объемов данных и быстрые ответы на запросы.
9) Как происходит мониторинг и поддержка кластера Doris?
Мониторинг обычно включает метрики задержек выполнения запросов, загрузку CPU/RAM, пропускную способность сети и использование дискового пространства. Инструменты, которые часто применяются вместе с Doris, включают Prometheus и Grafana для визуализации, а также системы логирования для диагностики сбоев. HA и резервирование FE/BE узлов требуют карательной настройки.
10) Какие практические шаги стоит сделать на старте проекта с Doris?
Определить требования к нагрузке и скорости ответа, спроектировать схему с учетом разделения по HASH и partitioning, выбрать целевые хранилища (локальные диски или облачное) и настроить хранение данных. Спроектировать конвейер загрузки данных через Broker Load, Stream Load и Routine Load. Настроить оркестрацию с Airflow и мониторинг с Prometheus. Провести нагрузочные тесты, проверить устойчивость к сбоям, удостовериться в соблюдении регуляторных требований и локализации данных.
Эта глава дала обзор архитектуры Doris, объяснила роли FE и BE, разобрала механизмы хранения данных и выполнения запросов, привела практические примеры использования открытого ПО и российской экосистемы, обсудила риски внедрения и ограничения. В ходе работ над проектами важно учитывать баланс между производительностью, устойчивостью к отказам и требованиями к локализации данных. Doris можно рассматривать как мощный инструмент в арсенале аналитических технологий, который при грамотной архитектуре и аккуратном проектировании схемы может значительно ускорить аналитические конвейеры и повысить качество принятия решений.
