Архитектура хранения данных: таблицы, партиционирование, репликация и управление хранением

Данные в Doris формируют основу аналитических сценариев так, чтобы запросы на бизнес-данные выполнялись предсказуемо быстро даже в условиях больших объемов и сложной архитектуры кластеров. Глава посвящена архитектуре хранения данных в Doris: как формируются таблицы, какие подходы применяются к партиционированию и распределению данных, как реализована репликация и обеспечение отказоустойчивости, а также какие механизмы управления хранением применяются на практике. Понимание этих аспектов критично для проектирования кластеров, настройки параметров производительности и устойчивости, а также для эффективной эксплуатации OLAP-аналитической платформы.

В рамках главы будут рассмотрены принципы организации хранения на физическом уровне, концепции, лежащие в основе таблиц и их разделения на партиции, механизмы репликации и консистентности данных, а также практические подходы к управлению хранением - от компрессии и кодирования до tiered storage и интеграций с внешними системами хранения. Особое внимание уделяется тому, как эти элементы влияют на выбор архитектурных решений, какие trade-offs сопоставлять при настройке кластера и как организовать мониторинг и управление хранением в реальном производстве.

Что будет рассмотрено в этой главе
Какие принципы лежат в основе хранения в Doris и как они реализованы в кластерной среде
Как проектировать таблицы и партиционирование под нагрузки OLAP
Как организована репликация, консистентность и отказоустойчивость
Какие методы управления хранением применяются на уровне файловой системы и объектного хранилища

Таблицы и физическое хранение в Doris

Данные в Doris представлены не только структурой таблиц, но и физическим образом организованы в виде единиц хранения, которые управляются на уровне каждого BE-узла кластера. Основные концепции включают хранение в колонночном формате, сегментирование данных на временные или годичные, а также коллекцию версий и элементов чтения - rowset, segments и части таблиц, которые позволяют эффективно сжимать, индексировать и фильтровать данные при выполнении запросов.

Колонночная организация обеспечивает высокую сжимаемость и ускорение сканирования столбцов, что особенно ценно для аналитических запросов. В Doris данные разделяются на физические единицы, которые могут быть распределены по узлам кластера, реплицированы и обслуживаться независимо. Это даёт возможность параллельной обработки и высокой пропускной способности, но требует аккуратного проектирования схем таблиц и параметров хранения.

Table-level metadata содержит не только схемы и типы столбцов, но и правила распределения данных, политики выделения мест хранения и версии для восстановления после сбоев. Физическое размещение данных на дисках и в объектном хранилище определяется стратегиями хранения и конфигурациями уровня сервиса - от локальных дисков до tiered storage с доступом к внешним системам хранения.

Пример условной схематической конфигурации таблицы (для иллюстрации концепций):
CREATE TABLE sales (
  id INT,
  sale_date DATE,
  amount DECIMAL(18,2),
  region STRING
)
PRIMARY KEY (id)
DISTRIBUTED BY HASH(id) BUCKETS 16;

Это демонстрационная запись, иллюстрирующая базовую идею распределения по хэш-ключу. В реальных конфигурациях Doris версия и конкретный синтаксис могут отличаться, поэтому следует опираться на официальную документацию вашей версии кластера при реализации.

Важно помнить, что выбор ключей, типов столбцов и параметров компрессии напрямую влияет на размер занимаемого места, скорость сканирования и эффективность последующих операций очистки и обновления данных. Например, выбор ключевых столбцов для добычи агрегаций и фильтров определяет, как эффективно Doris сможет prune partitions и skip scan во время выполнения запроса. В разделе далее будут рассмотрены принципы проектирования таблиц и их влияние на хранение.

Партиционирование и шардирование: стратегия организации данных

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

Партиционирование по диапазонам времени: позволяет эффективно фильтровать данные по датам, что особенно полезно для временных рядов, логов и исторических отчетов. При правильном распределении по диапазонам удаётся минимизировать сканируемые данные и ускорить агрегацию по периоду.
Партиционирование по списку и по диапазону значений: обеспечивает гибкость в случаях, когда данные разнородны по категориям и требуют группировки по конкретным условиям. Способы применения зависят от бизнес-логики и объема данных.
Hash-партиционирование и распределение по ключам: обеспечивает равномерное распределение сегментов таблицы по узлам кластера, предотвращая концентрирование нагрузки и перегрузку отдельных нод. Это особенно важно на пиковых периодах, когда запросы наиболее интенсивны.
Динамическое управление партициями: позволяет автоматически добавлять, удалять или объединять партиции в зависимости от объема данных и срока их полезности. В сочетании с TTL-политиками это обеспечивает эффективное управление данными на протяжении жизни хранилища.

Эти подходы должны применяться с учётом реальных сценариев запросов. Например, частые по времени запросы на последние месяцы требуют хорошо продуманного диапазонного партиционирования и эффективной pruning. В то же время для исторических архивов возможно применение денежных стратегий хранения и отделение их от hot-пути.

Чтобы рассмотреть влияние партиционирования на производительность, полезно помнить о нескольких принципах:

Пропуск scan и фильтрация: правильное партиционирование позволяет Doris пропускать целые partition’ы, если фильтры по ним не применяются. Это снижает время отклика и нагрузку на сеть.
Балансировка данных: равномерное распределение партиций по узлам предотвращает перегрузку отдельных сегментов кластерa.
Управление метаданными: избыточное количество мелких партиций может увеличить накладные расходы на метаданные. Оптимальная гранулярность - баланс между точностью фильтрации и стоимостью управления.
```
## Иллюстративный пример (условная схема):
- **Таблица**: events
- **Партиции**: по месяцу (PARTITION p202401 VALUES LESS THAN ('2024-02-01'), p202402 VALUES LESS THAN ('2024-03-01'), ...)
- **Разделение по хеше**: DISTRIBUTED BY HASH(event_id) BUCKETS 64
```
Данные в Doris могут храниться на локальных носителях и/или в объектном хранилище. В зависимости от выбранной стратегии хранения и политики TTL, партиционирование может напрямую влиять на стоимость операций удаления, архивирования и восстановления. В разделе ниже рассмотрим, как репликация обеспечивает устойчивость к сбоям и как она взаимодействует с хранением.

Репликация и устойчивость к сбоям: консистентность и доступность

Репликация служит опорой доступности и отказоустойчивости аналитической платформы. В Doris реплики таблиц создаются в рамках определённых политик хранения, что обеспечивает устойчивость к сбоям отдельных узлов и сетевых сегментов. Основные аспекты включают:

Реплики и согласованность: каждая секция данных имеет копии на нескольких узлах. В зависимости от конфигурации репликации и политики commit’ов, Doris может обеспечивать как сильную, так и близкую к конечной консистентность для чтения данных после записи.
Лидерство и координация: для каждого планшета выбирается лидер, который отвечает за последовательную запись изменений и координацию между репликами. В случае сбоя лидер переназначается, чтобы поддержать непрерывность сервиса.
Механизмы отказоустойчивости: репликация позволяет продолжить обработку запросов, даже если часть кластера выходит из строя. Восстановление после сбоев происходит за счёт синхронизации реплик и повторного применения изменений.
Влияние на производительность: более высокий уровень репликации повышает стабильность, но требует дополнительных ресурсов для синхронной или асинхронной репликации. Настройки должны соответствовать целям SLA по задержкам и доступности.
Метаданные и хранение конфигурации: репликация часто дополняется механизмами консистентности метаданных, которые позволяют быстро восстанавливать состояние кластера после сбоев, минимизируя риск расхождения между физическим размещением и отображением в каталоге таблиц.

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

Управление хранением: компрессия, политики хранения и tiered storage

В современных аналитических системах управление хранением опирается на компрессию данных, кодирование столбцов, стратегию удаления устаревших данных и размещение «горячих» данных на быстрых носителях, а «холодных» - на объектном хранилище. Doris поддерживает эти подходы на уровне конфигураций и политики, что позволяет адаптировать систему под требования конкретной предметной области и инфраструктуры.

Компрессия и кодирование: выбор алгоритмов с учётом частоты доступа и типа нагрузки. Более агрессивные схемы компрессии уменьшают занимаемое место, но могут увеличить задержку при чтении в случае сложной декомпрессии. Важно подбирать компрессию под характер данных и частоту обновления.
Политики TTL и устаревших данных: TTL-политики позволяют автоматически удалять или архивировать данные по истечении заданного срока. Это особенно полезно для временных рядов и журналов событий, где ценность данных падает со временем.
Tiered storage: распределение данных между «горячими» локальными носителями и «холодным» объектным хранилищем. Это снижает себестоимость хранения при сохранении необходимой скорости доступа к наиболее «горячим» данным.
Управление удалением и архивированием: по мере устаревания данных может потребоваться перенос в архив или полное удаление. Применение последовательной политики обеспечивает единообразие и предсказуемость процессов хранения.
Интеграции с внешними хранениями: Doris может работать с HDFS, S3 и аналогичными системами для реализации tiered storage. Важно учитывать задержки доступа к внешним источникам при выборе политики кэширования и консистентности.

Эти механизмы хранения напрямую влияют на характеристики кластерной производительности: скорость сканирования, время отклика запросов, стоимость хранения и доступность данных. В производственных условиях комбинация партиционирования, репликации и tiered storage требует грамотной настройки и мониторинга.

Интеграции и эксплуатационные практики: мониторинг, конфигурация и сценарии внедрения

Эффективность хранения в Doris во многом определяется тем, как система интегрируется с остальными слоями инфраструктуры и как осуществляется мониторинг. Практические решения включают:

Интеграции с объектными хранилищами и файловыми системами: настройка доступа к S3, HDFS или аналогичным системам, выбор политики доступа, обработка ошибок сети и задержек, обеспечение надежных копий.
Мониторинг и трассировка: набор метрик для наблюдения за объемом данных на носителях, скоростью операций ввода-вывода, задержками сканирования и степенью пропускной способности сети. Важны proactive alerting и dashboards, показывающие тенденции при выполнении OLAP-запросов.
Оптимизация ввода-вывода: настройка параллелизма сканов, ограничение конкуренции по IO, настройка параллельности строительства секций таблиц и распределения по BUCKETS.
Конфигурации кластера: размер кластера, параметры репликации, настройки TTL и политики хранения, механизмы восстановления после сбоев и очередности операций реорганизации хранения. Эти параметры должны соответствовать целям производства и требованиям к SLA.
Безопасность и соответствие: обеспечение корректного доступа к данным, шифрование на уровне хранения, журналирование изменений и управление доступом к данным в рамках политики компании.

Таблица сравнения подходов к хранению

Аспект	Локальное хранение	Объектное хранение	Компрессия	TTL и удаление	Tiered storage
Основная цель	Быстрый доступ к актуальным данным	Экономия и масштабируемость хранения	Снижение объема данных	Управление сроком хранения	Разделение данных по «горячим/холодным» слоям
Преимущества	Низкие задержки, простота доступа	Масштабируемость, стоимость	Снижение занимаемого места	Соответствие требованиям регуляторов	Эффективное использование капитала
Ограничения	Большие затраты на ресурсы при росте	Зависимость от сетевых задержек к внешним хранилищам	Возможны вычислительные накладные	Необходимо точное определение TTL	Сложнее управлять кэшированием и консистентностью

Данная таблица иллюстрирует базовые trade-off и дает ориентиры для проектирования политики хранения. В реальном кластере следует учитывать конкретные требования к latency, throughput и бюджету на хранение.

Key takeaways

Архитектура хранения Doris строится вокруг таблиц, партиционирования и репликации, что обеспечивает масштабируемость и отказоустойчивость на уровне аналитических нагрузок.
Эффективное партиционирование и распределение по узлам повышают производительность запросов за счет prune и параллелизма, но требуют баланса между количеством партиций и метаданными.
Репликация и консистентность данных - фундамент устойчивости к сбоям; выбор политики репликации влияет на задержки записи и доступность чтения.
Управление хранением через компрессию, TTL и tiered storage позволяет снизить затраты на хранение без ущерба для скорости доступа к критически важным данным.
Интеграции с внешними хранилищами и грамотная конфигурация мониторинга существенно упрощают эксплуатацию и поддерживают SLA.
Практика проектирования таблиц и партиционирования должна опираться на характер запросов, частоту обновления данных и требования к времени задержки.
При выборе конфигураций следует учитывать реальную нагрузку и сценарии использования: от «горячего» пути к «холодному» архиву, от локального к объектному хранению и обратно.

FAQ

Что такое Tablet и Rowset в Doris и зачем они нужны?

Tablet представляет собой единицу хранения данных внутри таблицы, которая может быть реплицирована и обслуживаться на нескольких нодах. Rowset - это набор версий строк внутри Tablet, отражающий изменения во времени, что позволяет Doris эффективно поддерживать версионность и упрощает операции восстановления и оптимизации хранения. Эти концепции позволяют параллелить работу, ускорять сканирование и упростить механизмы обновления данных.

Как выбрать стратегию партиционирования для аналитических нагрузок?

Выбор стратегии зависит от паттернов запросов и характера данных. Для временных рядов стоит рассмотреть диапазонное партиционирование по дате, что обеспечивает эффективную pruning и быстрый доступ к последним данным. Для категориальных данных полезно сочетать hash-партиционирование для равномерного распределения нагрузки и диапазонное - для фильтров по ключам. Важно избегать избыточного мелкого партиционирования, чтобы не нагружать метаданные и не увеличивать задержки на управление партициями.

Как репликация влияет на задержку записи и чтение?

Увеличение числа реплик повышает устойчивость и доступность, но может увеличить задержку записи из-за синхронной репликации. В практике выбирают баланс: достаточное количество реплик для SLA по доступности и возможность чтения из локально реплицированных копий, с использованием кэширования и оптимизированных политик commit для снижения влияния на latency.

Что такое tiered storage и когда его использовать?

Tiered storage разделяет данные по горячим и холодным слоям: горячие данные размещаются на локальных быстрых носителях, холодные - на объектном хранении. Это позволяет снизить совокупную стоимость владения, сохранив при этом скорость доступа к наиболее востребованным данным. При этом важно правильно оценить задержки доступа к внешним хранилищам и настроить кэширование.

Какие параметры влияют на эффективность компрессии и кодирования в Doris?

Эффективность компрессии зависит от свойств данных: однородность типов, частота повторений значений, распределение нулевых значений и т. д. В Doris выбираются алгоритмы компрессии и кодирования для столбцов с учётом типа данных и частоты доступа. Разумный выбор снижает размер памяти и I/O, но может повлиять на время декодирования при сканировании.

Какие практики мониторинга наиболее критичны для хранения?

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

Как интеграции с внешними системами хранения влияют на архитектуру?

Интеграции с HDFS, S3 и аналогичными системами позволяют реализовать tiered storage и обеспечить долговременное архивирование. Это требует продуманной политики кэширования, согласованности и обработки ошибок сети. Важно обеспечить надёжный доступ к внешним копиям и корректную обработку задержек сети.

Как проектировать таблицы под OLAP-аналитику?

Во время проектирования следует учитывать требования к скользящим окнам времени, агрегациям и фильтрациям. Рекомендуется минимизировать количество мелких партиций, выбирать разумные ключи и комбинацию разделения по диапазону и хэшу, чтобы обеспечить как можно более эффективный prune и параллелизм.

Что делать при сбоях узлов в кластере Doris?

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

Каковы общие принципы уменьшения задержек чтения в хранилище Doris?

Уменьшение задержек чтения достигается за счёт эффективного партиционирования, prune’инга, балансировки нагрузки между репликами и узлами, оптимизации IO и кэширования. Важна настройка параметров параллелизма и разумной компрессии, чтобы избежать затрат на декодирование. Мониторинг является неотъемлемой частью обеспечения постоянной производительности.

Эта глава охватывает фундаментальные аспекты архитектуры хранения Doris и их влияние на практические задачи администрирования и эксплуатации OLAP-платформы.

← Предыдущая статья

Источники данных и интеграции: HDFS, S3, Kafka, MySQL, Hive, Iceberg

Следующая статья →

Разделение и горизонтальное масштабирование: шардирование и балансировка нагрузки