Data Cache

Начиная с версий v3.1.7 и v3.2.3, Selena представила Data Cache для ускорения запросов в кластерах с разделяемыми данными, заменив File Cache из более ранних версий. Data Cache загружает данные из удаленного хранилища блоками (порядка МБ) по мере необходимости, в то время как File Cache каждый раз загружает целые файлы данных в фоновом режиме, независимо от того, сколько строк данных фактически требуется.

По сравнению с File Cache, Data Cache имеет следующие преимущества:

• Меньше операций чтения из объектного хранилища, что означает меньшие затраты на доступ к объектному хранилищу (если ваше объектное хранилище взимает плату на основе частоты доступа).
• Меньшая нагрузка на запись на локальные диски и использование CPU, таким образом меньшее влияние на другие задачи загрузки или запросов (поскольку потоки фоновой загрузки больше не нужны).
• Оптимизированная эффективность кэша (поскольку File Cache может загружать менее часто используемые данные в файле).
• Оптимизированный контроль над кэшированными данными, таким образом избегая перегрузки локальных дисков, вызванной избыточными данными, которые не удалось вытеснить File Cache.

Включение Data Cache

Начиная с версии 1.5.0, Data Cache включен по умолчанию. Если вы хотите использовать Data Cache в кластере v3.1, или вы ранее вручную отключили эту функцию, вам необходимо выполнить следующие процедуры для ее включения.

Чтобы динамически включить Data Cache во время выполнения, выполните следующий оператор:

UPDATE information_schema.be_configs SET VALUE = 1 
WHERE name = "starlet_use_star_cache";

Динамические конфигурации станут недействительными после перезапуска узлов CN.

Чтобы постоянно включить Data Cache, вам необходимо добавить следующую конфигурацию в файл конфигурации CN cn.conf и перезапустить узлы CN:

starlet_use_star_cache = true

Настройка Data Cache

Вы можете настроить Data Cache, используя следующие элементы конфигурации CN(BE):

• storage_root_path (В кластерах с разделяемыми данными этот элемент используется для указания корневого пути, где хранятся кэшированные данные.)
• starlet_use_star_cache
• starlet_star_cache_disk_size_percent

примечание

Если вы включили File Cache перед обновлением вашего кластера Selena до версий v3.1.7, v3.2.3 или более поздних, пожалуйста, проверьте, изменяли ли вы элемент конфигурации starlet_cache_evict_high_water. Значение по умолчанию этого элемента равно 0.2, что указывает на то, что File Cache будет использовать 80% пространства хранения для хранения кэшированных файлов данных. Если вы изменили этот элемент, вы должны соответственно настроить starlet_star_cache_disk_size_percent во время обновления. Предположим, вы ранее установили starlet_cache_evict_high_water в 0.3. При обновлении вашего кластера Selena вам необходимо установить starlet_star_cache_disk_size_percent в 70, чтобы обеспечить, что Data Cache будет использовать тот же процент дисковой емкости, который вы установили для File Cache.

Просмотр статуса Data Cache

• Выполните следующий оператор, чтобы проверить, включен ли Data Cache:

  SELECT * FROM information_schema.be_configs 
  WHERE NAME LIKE "%starlet_use_star_cache%";

• Выполните следующий оператор, чтобы просмотреть корневой путь, который хранит кэшированные данные:

  SELECT * FROM information_schema.be_configs 
  WHERE NAME LIKE "%storage_root_path%";

  Кэшированные данные хранятся в подпути starlet_cache/star_cache вашего storage_root_path.

• Выполните следующий оператор, чтобы просмотреть максимальный процент хранилища, который может использовать Data Cache:

  SELECT * FROM information_schema.be_configs 
  WHERE NAME LIKE "%starlet_star_cache_disk_size_percent%";

Мониторинг Data Cache

Selena предоставляет различные метрики для мониторинга Data Cache.

Шаблоны панелей мониторинга

Вы можете загрузить следующие шаблоны панелей мониторинга Grafana в зависимости от вашей среды Selena:

• Шаблон панели мониторинга для кластера Selena с разделяемыми данными на виртуальных машинах
• Шаблон панели мониторинга для кластера Selena с разделяемыми данными на Kubernetes

Важные метрики

fslib read io_latency

Записывает задержку чтения Data Cache.

fslib write io_latency

Записывает задержку записи Data Cache.

fslib star cache meta memory size

Записывает оценочное использование памяти Data Cache.

fslib star cache data disk size

Записывает фактическое использование диска Data Cache.

Отключение Data Cache

Чтобы динамически отключить Data Cache во время выполнения, выполните следующий оператор:

UPDATE information_schema.be_configs SET VALUE = 0 
WHERE name = "starlet_use_star_cache";

Динамические конфигурации станут недействительными после перезапуска узлов CN.

Чтобы постоянно отключить Data Cache, вам необходимо добавить следующую конфигурацию в файл конфигурации CN cn.conf и перезапустить узлы CN:

starlet_use_star_cache = false

Очистка кэшированных данных

Вы можете очистить кэшированные данные в случае чрезвычайных ситуаций. Это не повлияет на исходные данные в вашем удаленном хранилище.

Выполните следующие шаги для очистки кэшированных данных на узле CN:

1. Удалите подкаталог, который хранит данные, то есть ${storage_root_path}/starlet_cache.

   Пример:

   # Предположим, что `storage_root_path = /data/disk1;/data/disk2`
   rm -rf /data/disk1/starlet_cache/
   rm -rf /data/disk2/starlet_cache/

2. Перезапустите узел CN.

Примечания по использованию

• Если свойство datacache.enable установлено в false для облачной таблицы, Data Cache не будет включен для таблицы.
• Если свойство datacache.partition_duration установлено в определенный временной диапазон, данные за пределами временного диапазона не будут кэшироваться.
• После понижения версии кластера с разделяемыми данными с v3.3 до v3.2.8 и более ранних версий, если вы хотите повторно использовать кэшированные данные в Data Cache, вам необходимо вручную переименовать Blockfile в каталоге starlet_cache, изменив формат имени файла с blockfile_{n}.{version} на blockfile_{n}, то есть удалить суффикс информации о версии. Версии v3.2.9 и более поздние совместимы с форматом имени файла в v3.3, поэтому вам не нужно выполнять эту операцию вручную. Вы можете изменить имя, запустив следующий shell-скрипт:

#!/bin/bash

# Замените <starlet_cache_path> на каталог Data Cache вашего кластера, например, /usr/be/storage/starlet_cache.
starlet_cache_path="<starlet_cache_path>"

for blockfile in ${starlet_cache_path}/blockfile_*; do
    if [ -f "$blockfile" ]; then
        new_blockfile=$(echo "$blockfile" | cut -d'.' -f1)
        mv "$blockfile" "$new_blockfile"
    fi
done

Известные проблемы

Высокое использование памяти

• Описание: Пока кластер работает в условиях низкой нагрузки, общее использование памяти узла CN значительно превышает сумму использования памяти каждого модуля.
• Идентификация: Если сумма fslib star cache meta memory size и fslib star cache data memory size составляет значительную долю от общего использования памяти узла CN, это может указывать на данную проблему.
• Затронутые версии: v3.1.8 и более ранние патч-версии, и v3.2.3 и более ранние патч-версии
• Исправленные версии: v3.1.9, v3.2.4
• Решения:
  • Обновите кластер до исправленных версий.
  • Если вы не хотите обновлять кластер, вы можете очистить каталог ${storage_root_path}/starlet_cache/star_cache/meta узлов CN и перезапустить узлы.

Вопросы и ответы

В1: Почему каталог Data Cache занимает гораздо больше места в хранилище (наблюдаемое через команды du и ls), чем фактический размер кэшированных данных?

Дисковое пространство, занимаемое Data Cache, представляет историческое пиковое использование и не связано с текущим фактическим размером кэшированных данных. Например, если кэшируется 100 ГБ данных, размер данных станет 200 ГБ после уплотнения. Затем, после сборки мусора (GC), размер данных был уменьшен до 100 ГБ. Однако дисковое пространство, занимаемое Data Cache, останется на своем пике в 200 ГБ, даже если фактические кэшированные данные внутри составляют 100 ГБ.

В2: Автоматически ли Data Cache вытесняет данные?

Нет. Data Cache вытесняет данные только когда достигает лимита использования диска (80% дискового пространства по умолчанию). Процесс вытеснения не удаляет данные; он просто помечает дисковое пространство, которое хранит старый кэш, как пустое. Новый кэш затем перезаписывает старый кэш. Поэтому, даже если происходит вытеснение, использование диска не уменьшится и не повлияет на фактическое использование.

В3: Почему использование диска остается на настроенном максимальном уровне и не уменьшается?

Обратитесь к В2. Механизм вытеснения Data Cache не удаляет кэшированные данные, а помечает старые данные как перезаписываемые. Следовательно, использование диска не уменьшится.

В4: Почему использование диска Data Cache остается на том же уровне после того, как я удалил таблицу и файлы таблицы удалены из удаленного хранилища?

Удаление таблицы не запускает удаление данных в Data Cache. Кэш удаленной таблицы будет постепенно вытесняться со временем на основе логики LRU (Least Recently Used) Data Cache, и это не влияет на фактическое использование.

В5: Почему фактическое использование диска достигает 90% или более, даже если настроено 80% дисковой емкости?

Использование диска Data Cache точное и не превысит настроенный лимит. Избыточное использование диска может быть вызвано:

• Файлами журналов, генерируемыми во время выполнения.
• Core-файлами, генерируемыми сбоями CN.
• Постоянными индексами таблиц Primary Key (хранятся в ${storage_root_path}/persist/).
• Смешанными развертываниями экземпляров BE/CN/FE, использующими один и тот же диск.
• Кэшами внешних таблиц (хранятся в ${STARROCKS_HOME}/block_cache/).
• Проблемами диска, например, используется файловая система ext3.

Вы можете выполнить du -h . -d 1 в корневом каталоге диска или подкаталогах, чтобы проверить конкретные каталоги, занимающие место, а затем удалить неожиданные части. Вы также можете уменьшить лимит дисковой емкости Data Cache, настроив starlet_star_cache_disk_size_percent.

В6: Почему существует значительная разница в использовании диска Data Cache между узлами?

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

• Различными моментами времени, когда узлы были добавлены в кластер.
• Различиями в количестве tablet, принадлежащих разным узлам.
• Различиями в размере данных, принадлежащих разным tablet.
• Различиями в ситуациях уплотнения и GC между узлами.
• Узлами, испытывающими сбои или проблемы нехватки памяти (OOM).

В заключение, различия в использовании кэша зависят от множества факторов.