watsonx.data 2.0.0 で File list cache を構成してみた (キャッシュ編 その1)

はじめに

watsonx.data はキャッシュを構成する事により Presto (Java) エンジンを使用した照会のパフォーマンスを向上する事ができます。
本投稿内の Presto は全て Presto (Java) を意味しています。

参考文献
RaptorX: Building a 10X Faster Presto

この文書によると Presto のキャッシュは階層構造になっており、5種類の異なるキャッシュを構成する事により、リモートのストレージからメタデータやデータの取得に要する時間を大幅に短縮する事ができます。
watsonx.data 2.0.0 に含まれる Presto でも この5種類のキャッシュはサポートされており構成する事が可能です。参考文献の内容とwatsonx.dataで キャッシュの名前や指定できるプロパティーが一部異なりますが目的や特徴は同じで、下記の5種類のキャッシュを構成する事ができます。

キャッシュの種類	キャッシュの場所	キャッシュの場所	特徴
Metastore versioned cache	コーディネーター	メモリー	メタデータのキャッシュ
File list cache	コーディネーター	メモリー	ファイルのリストのキャッシュ
File and stripe footer cache	ワーカー	メモリー	ファイルの記述子、Stripe、フッターのキャッシュ
File list cache	ワーカー	ディスク	読み取ったデータのキャッシュ
File list cache	ワーカー	ディスク	分割して処理されたデータのキャッシュ

キャッシュのアーキテクチャーを図にすると以下のようになります。
詳しくは参考文献をご覧ください。
5種類のキャッシュの内、Metastore versioned cache と File and stripe footer cache については watsonx.data 2.0.0 ではデフォルトで使用可能となっています。

今回は、5種類のキャッシュの中から File list cache について構成方法をご紹介します。
File list cache はデフォルトでは使用可能になっていないため構成手順に従って構成する必要があります。

Data cache については以下の記事をご参照ください。
watsonx.data 2.0.0 で Data cache を構成してみた (キャッシュ編 その2)

Fragment result cache については以下の記事をご参照ください。
watsonx.data 2.0.0 で Fragment result cache を構成してみた (キャッシュ編 その3)

File list cache について

ここで File list cache について、もう少し詳しく説明します。
Presto コーディネーターは、リモート・ストレージへの listFile 呼び出しによる遅延を回避するために、ファイルのリストをメモリーにキャッシュします。内容が変わらないディレクトリーがキャッシュの対象となり、頻繁にデータが取り込まれて保存されるようなディレクトリーはディレクトリーのリアルタイム性を担保するためにキャッシュの対象となりません。

以下に File list cache を構成する手順を記述します。

File list cache の構成手順

参考文献 (watsonx.data 2.0.x のマニュアル)
Enhancing the query performance through caching

File list cache は wxdengine カスタム・リソースに File list cacheのプロパティーを追加する事により構成します。以下が File list cache を構成するプロパティーとなります。

プロパティー	意味
file_status_cache_expire_time	キャッシュの期限が切れるまでの時間。デフォルトは 24h
file_status_cache_tables	キャッシュする表のタイプ。 デフォルトは * (全てのスキーマの全ての表をキャッシュ)
file_status_cache_size	キャッシュのサイズ。デフォルトは 100000000

1.OCPクラスターにログイン

"oc login" コマンドでOCPクラスターにログインします。

2.watsonx.data のプロジェクトに変更

作業中のプロジェクトをwatsonx.data がインストールされているプロジェクトに変更します。今回の環境では watsonx.data は 名前スペース zen にインストールされています。

$ export PROJECT_CPD_INST_OPERANDS=zen
$ oc project ${PROJECT_CPD_INST_OPERANDS}

3.File list cache を設定する Presto のエンジンIDを確認

$ oc get wxdengine -o custom-columns='DISPLAY NAME:spec.engineDisplayName,ENGINE ID:metadata.labels.engineName'
DISPLAY NAME   ENGINE ID
presto-01      presto-01

4.File list cache を設定する Prestoエンジンのステートフルセットを全て削除

$ oc delete statefulset -l engineName=presto-01
statefulset.apps "ibm-lh-lakehouse-presto-01-coordinator-blue" deleted
statefulset.apps "ibm-lh-lakehouse-presto-01-presto-worker" deleted
statefulset.apps "ibm-lh-lakehouse-presto-01-single-ble" deleted

5.wxdengine カスタム・リソース に patch を適用して File list cache を構成

"oc patch" コマンドは statefulset を削除した直後に実行する必要があるため、コピー＆ペーストできるように用意しておく事をお勧めします。

今回は下記のプロパティーの設定で File list cache を作成します。

プロパティー	値
file_status_cache_expire_time	24h
file_status_cache_tables	*
file_status_cache_size	100000000

"oc patch"コマンドで File list cache を設定

$ oc patch wxdengine/lakehouse-presto-01 --type=merge -p '{ "spec": { "file_status_cache_expire_time": "24h","file_status_cache_tables": "*","file_status_cache_size": 100000000 } }'
wxdengine.watsonxdata.ibm.com/lakehouse-presto-01 patched

しばらくすると Presto のステートフルセットとポッドが再起動しますので確認します。

$ oc get statefulset | grep presto
ibm-lh-lakehouse-presto-01-coordinator-blue   1/1     8m51s
ibm-lh-lakehouse-presto-01-presto-worker      5/5     8m51s
ibm-lh-lakehouse-presto-01-single-blue        0/0     8m55s

$ oc get pod | grep presto
ibm-lh-lakehouse-presto-01-coordinator-blue-0    1/1     Running     0    9m23s
ibm-lh-lakehouse-presto-01-presto-worker-0       1/1     Running     0    9m23s
ibm-lh-lakehouse-presto-01-presto-worker-1       1/1     Running     0    9m23s
ibm-lh-lakehouse-presto-01-presto-worker-2       1/1     Running     0    9m23s
ibm-lh-lakehouse-presto-01-presto-worker-3       1/1     Running     0    9m23s
ibm-lh-lakehouse-presto-01-presto-worker-4       1/1     Running     0    9m23s

6.File list cache が作成された事の確認

File list cache が作成された事を watsonx.data のオペレーターのポッドのログで確認します。File list cache はメモリー上のキャッシュなので、Data cache や Fragment result cache のようにコーディネーターやワーカーのポッドの中に専用のディレクトリー構造は作成されません。
オペレーターのポッドは watsonx.data インストール時に指定したオペレーターの名前スペースで稼働している "ibm-lakehouse-controller-manager" で始まる名前のポッドです。ポッドのログをファイルにリダイレクトして、ログの中を確認すると良いでしょう。

例)

export PROJECT_CPD_INST_OPERATORS=cpd-operator
$ oc get pod -n ${PROJECT_CPD_INST_OPERATORS} | grep ibm-lakehouse-controller-manager
ibm-lakehouse-controller-manager-7df78d599c-c7mm9  1/1   Running  0  9d

$ oc logs -n ${PROJECT_CPD_INST_OPERATORS} ibm-lakehouse-controller-manager-7df78d599c-c7mm9 > ibm-lakehouse-controller-manager.log

オペレーターのポッドのログの中に下記のような "oc patch"コマンドで指定したプロパティーが設定されるエントリーが記録されていれば File list cache は構成されています。

--------------------------- Ansible Task StdOut ------------------------------- 
  TASK [set file_status_cache_size] ********************************  
  [0;32mok: [localhost] =>   changed=false  [0m
  [0;32m  ansible_facts  [0m
  [0;32m    temp_file_status_cache_size: [0m
  [0;32m      presto: [0m
  [0;32m        file_list_cache: [0m
  [0;32m          file_status_cache_size: 100000000 [0m


--------------------------- Ansible Task StdOut -------------------------------
 TASK [set file_status_cache_expire_time] ******************************** 
 [0;32mok: [localhost] => changed=false  [0m
 [0;32m  ansible_facts: [0m
 [0;32m    temp_file_status_cache_expire_time: [0m
 [0;32m      presto: [0m
 [0;32m        file_list_cache: [0m
 [0;32m          file_status_cache_expire_time: 24h [0m

おわりに

今回は watsonx.data 2.0.0 の Presto の照会のパフォーマンスを向上するためのキャッシュの1つである File list cache の構成について紹介しました。
watsonx.data 1.1.x でも全く同じ手順で構成する事ができます。

キャッシュを削除する手順については、以下の記事をご参照ください。
watsonx.data 2.0.0 で 構成したキャッシュを削除する (キャッシュ編 その4)