バージョン: Stable-3.3

データキャッシュのウォームアップ

データレイク分析や共有データクラスタのシナリオでは、BIレポートや概念実証 (PoC) のパフォーマンステストなど、クエリに対して高いパフォーマンス要件があります。リモートデータをローカルデータキャッシュにロードすることで、同じデータを何度も取得する必要がなくなり、クエリの実行速度が大幅に向上し、リソース使用量を最小限に抑えることができます。

StarRocks v3.3では、Data Cache の強化機能としてデータキャッシュのウォームアップ機能を導入しました。Data Cacheは、データクエリ中にデータをキャッシュに書き込むことでキャッシュを受動的に充填するプロセスです。一方、データキャッシュのウォームアップは、キャッシュを能動的に充填するプロセスで、リモートストレージから必要なデータを事前に積極的に取得します。

シナリオ

データキャッシュに使用されるディスクのストレージ容量が、ウォームアップするデータ量よりもはるかに大きい場合。ディスク容量がウォームアップするデータよりも少ない場合、期待されるウォームアップ効果は得られません。例えば、100 GBのデータをウォームアップする必要があるが、ディスクには50 GBのスペースしかない場合、50 GBのデータしかキャッシュにロードできず、以前にロードされた50 GBのデータは後でロードされる50 GBのデータによって置き換えられます。
データキャッシュに使用されるディスクへのデータアクセスが比較的安定している場合。アクセス量が急増すると、期待されるウォームアップ効果は得られません。例えば、100 GBのデータをウォームアップする必要があり、ディスクに200 GBのスペースがある場合、最初の条件は満たされます。しかし、ウォームアッププロセス中に大量の新しいデータ (150 GB) がキャッシュに書き込まれたり、予期しない大規模なコールドクエリが150 GBのデータをキャッシュにロードする必要がある場合、ウォームアップされたデータが追い出される可能性があります。

動作の仕組み

StarRocksは、データキャッシュのウォームアップを実装するためにCACHE SELECT構文を提供します。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: 外部カタログの名前。データレイクの外部テーブルをクエリする場合にのみ必要です。SET CATALOGを使用して外部カタログに切り替えた場合は指定しなくても構いません。
db_name: データベースの名前。そのデータベースに切り替えた場合は指定しなくても構いません。
table_name: データを取得するテーブルの名前。
boolean_expression: フィルター条件。
PROPERTIES: 現在、verboseプロパティのみがサポートされています。詳細なウォームアップメトリクスを返すために使用されます。

CACHE SELECTは同期プロセスであり、一度に1つのテーブルのみをウォームアップできます。実行が成功すると、ウォームアップ関連のメトリクスが返されます。

外部テーブルのすべてのデータをウォームアップ

次の例では、外部テーブル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: すべてのノードによってデータキャッシュから読み取られたデータの総サイズ。
WRITE_CACHE_SIZE: すべてのノードによってデータキャッシュに書き込まれたデータの総サイズ。
AVG_WRITE_CACHE_TIME: 各ノードがデータキャッシュにデータを書き込むのにかかった平均時間。
TOTAL_CACHE_USAGE: このウォームアップタスクが完了した後のクラスタ全体のデータキャッシュの使用率。このメトリクスは、データキャッシュに十分なスペースがあるかどうかを評価するために使用できます。

フィルター条件を使用して指定された列をウォームアップ

列と述語を指定して、細かいウォームアップを実現できます。これにより、ウォームアップするデータ量を減らし、ディスク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によって返されるメトリクスは、複数のBEsで結合されたメトリクスです。CACHE SELECTの末尾にPROPERTIES("verbose"="true")を追加することで、各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: データキャッシュがヒットしたときに各ノードがデータを読み取るのにかかる平均時間。

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>

使用例

PoCパフォーマンステスト中に、外部ストレージシステムの干渉なしにStarRocksのパフォーマンスを評価したい場合、CACHE SELECTステートメントを使用してテストするテーブルのデータを事前にデータキャッシュにロードできます。

ビジネスチームが毎朝8時にBIレポートを確認する必要がある場合、比較的安定したクエリパフォーマンスを確保するために、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)

ウォームアップ中のシステムリソース消費を最小限に抑えるために、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は、共有なしクラスタと共有データクラスタの両方で使用できます。
CACHE SELECTは、リモートのTEXT、ORC、Parquetファイルをウォームアップできます。
CACHE SELECTによってウォームアップされたデータは、キャッシュに永遠に保持されるわけではありません。キャッシュされたデータは、Data Cache機能のLRUルールに基づいて追い出される可能性があります。
- データレイクユーザーの場合、SHOW BACKENDS\GまたはSHOW COMPUTE NODES\Gを使用してデータキャッシュの残り容量を確認し、LRU追い出しが発生するかどうかを評価できます。
- 共有データクラスタユーザーの場合、共有データクラスタのメトリクスを表示してデータキャッシュの使用状況を確認できます。
現在、CACHE SELECTの実装はINSERT INTO BLACKHOLE()アプローチを使用しており、通常のクエリプロセスに従ってテーブルをウォームアップします。したがって、CACHE SELECTのパフォーマンスオーバーヘッドは通常のクエリと同様です。将来的には、パフォーマンスを向上させるための改善が行われる予定です。

将来のバージョンでの期待

将来的には、StarRocksは適応型データキャッシュのウォームアップを導入し、キャッシュヒット率を向上させる予定です。

シナリオ​

動作の仕組み​

外部テーブルのすべてのデータをウォームアップ​

フィルター条件を使用して指定された列をウォームアップ​

詳細モードでのウォームアップ​

CACHE SELECTタスクの定期スケジューリング​

CACHE SELECTタスクの管理​

作成されたタスクの表示​

タスク実行履歴の表示​

タスクの削除​

使用例​

制限と使用上の注意​

将来のバージョンでの期待​

このドキュメントについてどう思いましたか？