Перейти к основному содержимому
Версия: 2.0.x

Прогрев Block cache

Некоторые сценарии аналитики озер данных и shared-data cluster предъявляют высокие требования к производительности запросов, такие как BI-отчеты и тестирование производительности в рамках proof of concept (PoC). Загрузка удаленных данных в локальный block cache позволяет избежать необходимости многократно извлекать одни и те же данные, значительно ускоряя выполнение запросов и минимизируя использование ресурсов.

Selena v1.5.2 представляет функцию Block Cache Warmup, которая является улучшением Block Cache. Block Cache — это процесс пассивного заполнения кеша, при котором данные записываются в кеш во время выполнения запросов. Block Cache Warmup, однако, представляет собой активный процесс заполнения кеша. Он заранее проактивно извлекает необходимые данные из удаленного хранилища.

Сценарии использования​

  • Диск, используемый для block cache, имеет емкость хранения значительно большую, чем объем данных для прогрева. Если емкость диска меньше объема данных для прогрева, ожидаемый эффект прогрева не может быть достигнут. Например, если необходимо прогреть 100 ГБ данных, но диск имеет только 50 ГБ пространства, то только 50 ГБ данных можно загрузить в кеш, и ранее загруженные 50 ГБ данных будут заменены 50 ГБ данных, которые загружаются позже.
  • Доступ к данным на диске, используемом для block cache, относительно стабилен. Если происходит всплеск объема доступа, ожидаемый эффект прогрева не может быть достигнут. Например, если необходимо прогреть 100 ГБ данных и диск имеет 200 ГБ пространства, то первое условие выполнено. Однако, если большой объем новых данных (150 ГБ) записывается в кеш во время процесса прогрева, или если неожиданный большой холодный запрос требует загрузки 150 ГБ данных в кеш, это может привести к вытеснению прогретых данных.

Как это работает​

Selena предоставляет синтаксис CACHE SELECT для реализации Block Cache Warmup. Перед использованием CACHE SELECT убедитесь, что функция Block Cache включена.

Синтаксис CACHE SELECT:

CACHE SELECT <column_name> [, ...]
FROM [<catalog_name>.][<db_name>.]<table_name> [WHERE <boolean_expression>]
[PROPERTIES("verbose"="true")]

Параметры:

  • column_name: Столбцы для извлечения. Вы можете использовать * для извлечения всех столбцов во внешней таблице.
  • catalog_name: Имя catalog, по умолчанию DEFAULT_CATALOG. Если вы переключились на catalog с помощью SET CATALOG, его можно не указывать.
  • db_name: Имя базы данных. Если вы переключились на эту базу данных, его можно не указывать.
  • table_name: Имя таблицы, из которой извлекаются данные.
  • boolean_expression: Условие фильтрации.
  • PROPERTIES: В настоящее время поддерживается только свойство verbose. Оно используется для возврата подробных метрик прогрева.

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

Прогрев всех данных во внешней таблице​

Следующий пример загружает все данные из внешней таблицы lineitem:

mysql> cache select * from hive_catalog.test_db.lineitem;
+-----------------+------------------+----------------------+-------------------+
| READ_CACHE_SIZE | WRITE_CACHE_SIZE | AVG_WRITE_CACHE_TIME | TOTAL_CACHE_USAGE |
+-----------------+------------------+----------------------+-------------------+
| 48.2MB          | 3.7GB            | 59ms                 | 96.83%            |
+-----------------+------------------+----------------------+-------------------+
1 row in set (19.56 sec)

Возвращаемые поля:

  • READ_CACHE_SIZE: Общий размер данных, прочитанных из block cache всеми узлами.
  • WRITE_CACHE_SIZE: Общий размер данных, записанных в block cache всеми узлами.
  • AVG_WRITE_CACHE_TIME: Среднее время, затраченное каждым узлом на запись данных в block cache.
  • TOTAL_CACHE_USAGE: Использование дискового пространства block cache всего cluster после завершения этой задачи прогрева. Эта метрика может использоваться для оценки того, имеет ли block cache достаточно места.

Прогрев указанных столбцов с условиями фильтрации​

Вы можете указать столбцы и предикаты для достижения детального прогрева, что помогает уменьшить объем данных для прогрева, снижая дисковый I/O и потребление CPU.

mysql> cache select l_orderkey from hive_catalog.test_db.lineitem where l_shipdate='1994-10-28';
+-----------------+------------------+----------------------+-------------------+
| READ_CACHE_SIZE | WRITE_CACHE_SIZE | AVG_WRITE_CACHE_TIME | TOTAL_CACHE_USAGE |
+-----------------+------------------+----------------------+-------------------+
| 957MB           | 713.5MB          | 3.6ms                | 97.33%            |
+-----------------+------------------+----------------------+-------------------+
1 row in set (9.07 sec)

Следующий пример предварительно извлекает определенный столбец из облачно-нативной таблицы lineorder в shared-data cluster:

mysql> cache select lo_orderkey from ssb.lineorder;
+-----------------+------------------+----------------------+-------------------+
| READ_CACHE_SIZE | WRITE_CACHE_SIZE | AVG_WRITE_CACHE_TIME | TOTAL_CACHE_USAGE |
+-----------------+------------------+----------------------+-------------------+
| 118MB           | 558.9MB          | 200.6ms              | 4.66%             |
+-----------------+------------------+----------------------+-------------------+
1 row in set (29.88 sec)

Прогрев в подробном режиме​

По умолчанию метрики, возвращаемые CACHE SELECT, являются метриками, объединенными на нескольких BE. Вы можете добавить PROPERTIES("verbose"="true") в конец CACHE SELECT, чтобы получить подробные метрики каждого BE.

mysql> cache select * from hive_catalog.test_db.lineitem properties("verbose"="true");
+---------------+-----------------+---------------------+------------------+----------------------+-------------------+
| IP            | READ_CACHE_SIZE | AVG_READ_CACHE_TIME | WRITE_CACHE_SIZE | AVG_WRITE_CACHE_TIME | TOTAL_CACHE_USAGE |
+---------------+-----------------+---------------------+------------------+----------------------+-------------------+
| 172.26.80.233 | 376MB           | 127.8micros         | 0B               | 0s                   | 3.85%             |
| 172.26.80.231 | 272.5MB         | 121.8micros         | 20.7MB           | 146.5micros          | 3.91%             |
| 172.26.80.232 | 355.5MB         | 147.7micros         | 0B               | 0s                   | 3.91%             |
+---------------+-----------------+---------------------+------------------+----------------------+-------------------+
3 rows in set (0.54 sec)

В подробном режиме возвращается дополнительная метрика:

  • AVG_READ_CACHE_TIME: среднее время для каждого узла на чтение данных при попадании в block cache.

Периодическое планирование задач CACHE SELECT​

Вы можете использовать CACHE SELECT вместе с SUBMIT TASK для достижения периодического прогрева. Например, следующий случай прогревает таблицу lineitem каждые 5 минут:

mysql> submit task always_cache schedule every(interval 5 minute) as cache select l_orderkey
from hive_catalog.test_db.lineitem
where l_shipdate='1994-10-28';
+--------------+-----------+
| TaskName     | Status    |
+--------------+-----------+
| always_cache | SUBMITTED |
+--------------+-----------+
1 row in set (0.03 sec)

Управление задачами CACHE SELECT​

Просмотр созданных задач​

mysql> select * from default_catalog.information_schema.tasks;
+--------------+---------------------+-----------------------------------------------------+---------------+------------------------------+---------------------------------------------------------------------+---------------------+------------+
| TASK_NAME    | CREATE_TIME         | SCHEDULE                                            | CATALOG       | DATABASE                     | DEFINITION                                                          | EXPIRE_TIME         | PROPERTIES |
+--------------+---------------------+-----------------------------------------------------+---------------+------------------------------+---------------------------------------------------------------------+---------------------+------------+
| always_cache | 2024-04-11 16:01:00 | PERIODICAL START(2024-04-11T16:01) EVERY(5 MINUTES) | emr_hive_test | zz_tpch_sf1000_hive_orc_zlib | cache select l_orderkey from lineitem where l_shipdate='1994-10-28' | NULL                |            |
+--------------+---------------------+-----------------------------------------------------+---------------+------------------------------+---------------------------------------------------------------------+---------------------+------------+
1 row in set (0.21 sec)

Просмотр истории выполнения задач​

mysql> select * from default_catalog.information_schema.task_runs;
+--------------------------------------+--------------+---------------------+---------------------+---------+---------------+------------------------------+---------------------------------------------------------------------+---------------------+------------+---------------+----------+------------------------------------------------------------------------------------------------------------------------+------------+
| QUERY_ID                             | TASK_NAME    | CREATE_TIME         | FINISH_TIME         | STATE   | CATALOG       | DATABASE                     | DEFINITION                                                          | EXPIRE_TIME         | ERROR_CODE | ERROR_MESSAGE | PROGRESS | EXTRA_MESSAGE                                                                                                          | PROPERTIES |
+--------------------------------------+--------------+---------------------+---------------------+---------+---------------+------------------------------+---------------------------------------------------------------------+---------------------+------------+---------------+----------+------------------------------------------------------------------------------------------------------------------------+------------+
| 55b30204-f7da-11ee-b03e-7ea526d0b618 | always_cache | 2024-04-11 16:06:00 | 2024-04-11 16:07:22 | SUCCESS | emr_hive_test | zz_tpch_sf1000_hive_orc_zlib | cache select l_orderkey from lineitem where l_shipdate='1994-10-28' | 2024-04-12 16:06:00 |          0 | NULL          | 100%     | AlreadyCachedSize: 15.7GB, AvgReadCacheTime: 1ms, WriteCacheSize: 0B, AvgWriteCacheTime: 0s, TotalCacheUsage: 75.94%   |            |
| a2e3dc7e-f7d9-11ee-b03e-7ea526d0b618 | always_cache | 2024-04-11 16:01:00 | 2024-04-11 16:02:39 | SUCCESS | emr_hive_test | zz_tpch_sf1000_hive_orc_zlib | cache select l_orderkey from lineitem where l_shipdate='1994-10-28' | 2024-04-12 16:01:00 |          0 | NULL          | 100%     | AlreadyCachedSize: 15.7GB, AvgReadCacheTime: 1.2ms, WriteCacheSize: 0B, AvgWriteCacheTime: 0s, TotalCacheUsage: 75.87% |            |
+--------------------------------------+--------------+---------------------+---------------------+---------+---------------+------------------------------+---------------------------------------------------------------------+---------------------+------------+---------------+----------+------------------------------------------------------------------------------------------------------------------------+------------+
2 rows in set (0.04 sec)

Поле EXTRA_MESSAGE записывает метрики CACHE SELECT.

Удаление задач​

DROP TASK <task_name>

Примеры использования​

  1. Во время тестирования производительности PoC, если вы хотите оценить производительность Selena без вмешательства внешних систем хранения, вы можете использовать оператор CACHE SELECT для предварительной загрузки данных тестируемой таблицы в block cache.

  2. Бизнес-команде необходимо просматривать BI-отчеты каждое утро в 8 часов. Чтобы обеспечить относительно стабильную производительность запросов, вы можете запланировать задачу CACHE SELECT, которая начнет выполняться в 7 часов утра каждый день.

    mysql> submit task BI schedule START('2024-02-03 07:00:00') EVERY(interval 1 day)
    AS cache select * from hive_catalog.test_db.lineitem
    where l_shipdate='1994-10-28';
    +--------------+-----------+
    | TaskName     | Status    |
    +--------------+-----------+
    | BI           | SUBMITTED |
    +--------------+-----------+
    1 row in set (0.03 sec)

  3. Чтобы минимизировать потребление системных ресурсов во время прогрева, вы можете указать переменные сессии в операторе SUBMIT TASK. Например, вы можете назначить группу ресурсов для задачи CACHE SELECT, настроить степень параллелизма (DOP) и указать условие фильтрации в WHERE, чтобы уменьшить влияние прогрева на регулярные запросы.

    mysql> submit task cache_select properties("pipeline_dop"="1", "resource_group"="warmup") schedule EVERY(interval 1 day)
    AS cache select * from hive_catalog.test_db.lineitem where l_shipdate>='1994-10-28';
    +--------------+-----------+
    | TaskName     | Status    |
    +--------------+-----------+
    | cache_select | SUBMITTED |
    +--------------+-----------+
    1 row in set (0.03 sec)

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

  • Чтобы использовать CACHE SELECT, вы должны сначала включить функцию Block Cache и иметь привилегию SELECT на целевой таблице.
  • CACHE SELECT поддерживает прогрев только одной таблицы и не поддерживает операторы типа ORDER BY, LIMIT или GROUP BY.
  • CACHE SELECT может использоваться как в shared-nothing, так и в shared-data cluster.
  • CACHE SELECT может прогревать удаленные файлы TEXT, ORC, Parquet.
  • Данные, прогретые с помощью CACHE SELECT, могут не храниться в кеше вечно. Кешированные данные по-прежнему могут быть вытеснены на основе правила SLRU функции Block Cache.
    • Если вы пользователь озера данных, вы можете проверить оставшуюся емкость block cache, используя SHOW BACKENDS\G или SHOW COMPUTE NODES\G, чтобы оценить, может ли произойти вытеснение SLRU.
    • Если вы пользователь shared-data cluster, вы можете проверить использование block cache, просмотрев метрики shared-data cluster.
  • В настоящее время реализация CACHE SELECT использует подход INSERT INTO BLACKHOLE(), который прогревает таблицу в соответствии с обычным процессом запроса. Следовательно, накладные расходы на производительность CACHE SELECT аналогичны расходам обычных запросов. Улучшения будут внесены в будущем для повышения производительности.

Что ожидать в будущих версиях​

В будущем Selena представит адаптивный Block Cache Warmup для обеспечения более высокого процента попаданий в кеш.