Перейти к основному содержимому

Прогрев Data Cache

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

Selena v3.3 представляет функцию Data Cache Warmup, которая является улучшением Data Cache. Data Cache — это процесс пассивного заполнения кэша, при котором данные записываются в кэш во время выполнения запросов. Data Cache Warmup, однако, является активным процессом заполнения кэша. Он проактивно извлекает желаемые данные из удаленного хранилища заранее.

Сценарии​

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

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

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

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

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

Параметры:

  • column_name: Столбцы для извлечения. Вы можете использовать * для извлечения всех столбцов во внешней таблице.
  • catalog_name: Имя external catalog, требуется только при запросе внешних таблиц в озерах данных. Если вы переключились на external 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: Общий размер данных, прочитанных из Data Cache всеми узлами.
  • WRITE_CACHE_SIZE: Общий размер данных, записанных в Data Cache всеми узлами.
  • AVG_WRITE_CACHE_TIME: Среднее время, затраченное каждым узлом на запись данных в Data Cache.
  • TOTAL_CACHE_USAGE: Использование пространства Data Cache всего кластера после завершения этой задачи прогрева. Эта метрика может использоваться для оценки того, имеет ли Data 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 в кластере с общими данными:

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: среднее время для каждого узла на чтение данных при попадании в Data 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 для предварительной загрузки данных тестируемой таблицы в Data 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 вы должны сначала включить функцию Data Cache и иметь привилегию SELECT на целевой таблице.
  • CACHE SELECT поддерживает прогрев только одной таблицы и не поддерживает операторы типа ORDER BY, LIMIT или GROUP BY.
  • CACHE SELECT может использоваться как в кластерах shared-nothing, так и в кластерах shared-data.
  • CACHE SELECT может прогревать удаленные файлы TEXT, ORC, Parquet.
  • Данные, прогретые CACHE SELECT, могут не сохраняться в кэше навсегда. Кэшированные данные все еще могут быть вытеснены на основе правила LRU функции Data Cache.
    • Если вы пользователь озера данных, вы можете проверить оставшуюся емкость Data Cache, используя SHOW BACKENDS\G или SHOW COMPUTE NODES\G, чтобы оценить, может ли произойти вытеснение LRU.
    • Если вы пользователь кластера shared-data, вы можете проверить использование Data Cache, просматривая метрики кластера shared-data.
  • В настоящее время реализация CACHE SELECT использует подход INSERT INTO BLACKHOLE(), который прогревает таблицу, следуя обычному процессу запросов. Поэтому накладные расходы производительности CACHE SELECT аналогичны накладным расходам обычных запросов. В будущем будут внесены улучшения для повышения производительности.

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

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