Чанки

В данном разделе собрана информация о чанках - частях таблицы или файла, которые хранят данные.

Общие сведения

Данные, хранящиеся в таблицах, файлах и журналах, разбиты на части, называемые чанками. Чанк хранит непрерывный диапазон данных.
В частности, в каждом чанке таблицы содержится некоторый диапазон ее строк.
Чанк — неизменяемая сущность: после создания чанка данные в нем нельзя изменить.

Физически данные чанков хранятся на узлах кластера. Мастер-сервера YTsaurus отслеживают расположение чанков, а также поддерживают их в реплицированном состоянии.

Мастер-сервера YTsaurus хранят только метаданные. Тем не менее, метаданные имеют существенный размер, поэтому, чтобы ограничить потребление памяти мастер-серверами, количество чанков, доступных аккаунту, квотируется.

Размер чанков

Чанки не монолитны, они состоят из блоков, чтобы можно было читать и записывать чанк частями.
Блоки статических таблиц по умолчанию имеют размер 16 мегабайт, а блоки динамических таблиц — 256 килобайт.

Размер блока можно изменить в настройках table_writer, атрибут block_size.

Как правило, чанк занимает на узле кластера сотни мегабайт или единицы гигабайт.
Размер создаваемых чанков можно настраивать через секцию table_writer, атрибут desired_chunk_size.

Не рекомендуется делать чанки слишком маленькими. Это приводит к увеличению их количества, что расходует память мастер-серверов. Также, мелкие чанки замедляют чтение: возрастает количество запросов к мастеру и к диску, которые необходимо сделать, чтобы прочитать все данные.

Чтение данных

Когда клиент вызывает процедуру чтения данных из статической таблицы, на прокси-сервере выполняются следующие шаги:

  1. Получение от мастер-сервера списка чанков, из которых состоит таблица.
  2. Получение от мастер-сервера списка узлов кластера, на которых находятся реплики чанка.
  3. Скачивание данных с узлов кластера и передача клиенту.

Запись данных

Запись осуществляется схожим образом:

  1. Разделение потока входных данных на части.
  2. Оформление каждой части в виде чанка.
  3. Передача данных на узлы кластера и привязка к таблице.

Формат чанка

В YTsaurus существуют два формата чанков: построчный и поколоночный.
Формат чанка задает параметр optimize_for. Для построчного формата optimize_for имеет значение lookup, для поколоночного — scan.

Построчный формат: optimize_for=lookup

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

Поколоночный формат: optimize_for=scan

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

Если требуется прочитать одну строку или небольшой диапазон строк по ключу, потребуется совершить столько обращений к диску, сколько в таблице колонок. Для минимизации обращений к диску можно использовать атрибут group в описании колонок в схеме, который позволит хранить связанные данные в одном блоке. Подробнее можно прочитать в разделе Схема данных.

Примечание

Использование поколоночного формата без схемы бессмысленно.

Пример указания формата

CLI

yt set //tmp/table/@optimize_for scan

Установка атрибута влияет только на будущие чанки и не конвертирует таблицы (аналогично установка атрибутов @erasure_codec и @compression_codec).

Чтобы конвертировать уже записанные данные в новый формат, выполните операцию Merge:

CLI

yt merge --mode ordered --src //tmp/table --dst //tmp/table --spec '{force_transform = %true}'

Для динамической таблицы аналогичную задачу решает forced compaction. Перед его использованием обязательно изучите статью Фоновая компактификация.

Пример запуска операции через CLI:

yt set //tmp/table/@forced_compaction_revision 1

Также в случае поколоночного формата у динамической таблицы стоит обратить внимание на атрибут group на схеме колонки. Если из таблицы часто лукапятся строчки без фильтрации колонок, то имеет смысл выставить на все колонки одну и ту же группу. Про группы подробнее в документации про схему таблицы.

Владельцы чанков

Узлы Кипариса, состоящие из чанков, — таблицы, файлы и журналы, называются владельцами чанков.
Множество чанков, принадлежащих владельцам чанков, организовано в виде древовидной структуры данных. Листьями структуры являются чанки, а промежуточными вершинами — чанк-листы (chunk_list).

Помимо атрибутов, присущих всем узлам Кипариса, владельцы чанков имеют следующие дополнительные атрибуты:

Имя Тип Описание Обязательный
chunk_list_id Guid Идентификатор корневого списка чанков. Да
chunk_ids array<Guid> Список идентификаторов всех чанков.
chunk_count int Количество чанков.
compression_statistics CompressionStatistics Статистика по типам использованных кодеков сжатия и размерам данных. Да
erasure_statistics ErasureStatistics Статистика по типам использованных erasure-кодеков и размерам данных. Да
optimize_for_statistics OptimizeForStatistics Статистика по типам использованных типов чанков (optimize_for). Да
multicell_statistics MulticellStatistics Статистика распределения чанков по мастер-серверам. Да
uncompressed_data_size int Общий несжатый объем данных всех чанков (без учета репликации и erasure-кодирования). Да
compressed_data_size int Общий сжатый объем данных всех чанков (без учета репликации и erasure-кодирования). Да
compression_ratio double Коэффициент сжатия, отношение сжатого объема к несжатому. Да
update_mode string Способ изменения данных под транзакцией: none, append или overwrite; для узлов вне транзакции это none. Да
replication_factor integer Коэффициент репликации (для erasure-кодирования равен 1). Да
compression_codec string Имя кодека сжатия. Да
erasure_codec string Имя erasure-кодека. Да
vital bool Являются ли чанки этого узла витальными Нет
media Media Коэффициенты репликации и другие настройки медиумов. Да
primary_medium string Первичный медиум. Да

Витальность данных

Система YTsaurus разделяет чанки на два вида: витальные и невитальные. По умолчанию данные в системе витальные (атрибут vital равен true) и их потеря — серьезный инцидент. Потеря данных может произойти из-за выпадения узлов кластера.

Невитальные данные - это те данные, потеря которых не является критичной. Настройки кластеров YTsaurus таковы, что недоступность невитальных чанков не вызывает срабатывания мониторингов и вмешательства эксплуатации. Типичными примерами невитальных данных являются промежуточные результаты операций: планировщик сам заметит потери и выполнит пересчет. Для невитальных данных атрибут vital равен false.

Примечание

Система не считает витальными чанки, записанные без erasure-кодирования и имеющие единичный коэффициент репликации.

Данные могут быть утрачены при выпадении узлов кластера. Чтобы этого избежать, по умолчанию данные в YTsaurus хранятся в трёх копиях.
Однако, при выпадении нескольких хостов система может потерять доступ ко всем копиям. Если при утрате витальных данных были прерваны вычисления, перезапустите их.

Предыдущая
Следующая