はじめに

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、フッターのキャッシュ
Data cache	ワーカー	ディスク	読み取ったデータのキャッシュ
Fragment result cache	ワーカー	ディスク	分割して処理されたデータのキャッシュ

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

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

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

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

Data cache について

ここで Data cache について、もう少し詳しく説明します。
Presto のワーカーは、リモートストレージから読み取ったデータを元のデータの形式 (圧縮や暗号化されている場合でも) で1MBの単位でキャッシュとしてワーカーのローカル・ディスクに保存します。
コーディネーターは、実行要求があったSQLの結果がキャッシュに含まれるワーカーに処理をスケジュールします。もしこのワーカーが忙しかったり使用可能でない場合は、SQLの結果がキャッシュに含まれていなくても別のワーカーに処理をスケジュールします。この仕組みを Soft affinity scheduling と呼んでいます。
この仕組みにより、一度読み込まれて Data cache に保存されたデータを繰り返しリモート・ストレージから読む事を防いで照会のパフォーマンスを向上する事ができます。以下に Data cache を構成する手順を記述します。

Data cache の構成手順

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

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

プロパティー	意味
cacheStorageClass	Data cacheを作成するストレージ・クラス
cacheStorageSize	キャッシュとして使用するストレージのサイズ
cache_alluxio_max_cache_size	Data cacheとして使用する最大サイズ

watsonx.data 2.0.0 の Presto の Data cache では、TTL (キャッシュの有効期間) を設定する事ができませんが、将来のバージョンで設定できるようになる事を期待しましょう。

今回は新規に作成した Persistent Volume (PV)をData cache のストレージとして使用します。watsonx.data 2.0.x のマニュアル上ではオプションとなっていますが、PVを新規に作成作成する事により、ワーカー・ポッドがマウントしたローカル・ボリュームをキャッシュとして使用する事ができるため、キャッシュの読み書きのパフォーマンスの向上を期待する事ができます。
ODF等の既存のコンテナ・ストレージのストレージ・クラスを使用すると短い手順で Data cache を構成する事ができますが、キャッシュの読み書きがネットワーク経由となり遅延が発生する可能性があります。

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.ワーカー・ノードの中に必要なディレクトリーを作成

デバッグセッションで、OpenShiftの全ワーカー・ノードの中に必要なディレクトリーを作成します。

① ワーカーノードの確認

"oc get node"でOCPのノードの一覧を出力して、NAMEとROLESからワーカーノードを判断します。ストレージノードは対象外です。
今回の環境では worker-1～worker-5 がワーカーノードになります。

$ oc get node
NAME        STATUS   ROLES                  AGE   VERSION
NAME        STATUS   ROLES                  AGE   VERSION
master-1    Ready    control-plane,master   12d   v1.27.14+95b99ee
master-2    Ready    control-plane,master   12d   v1.27.14+95b99ee
master-3    Ready    control-plane,master   12d   v1.27.14+95b99ee
storage-1   Ready    worker                 12d   v1.27.14+95b99ee
storage-2   Ready    worker                 12d   v1.27.14+95b99ee
storage-3   Ready    worker                 12d   v1.27.14+95b99ee
worker-1    Ready    worker                 12d   v1.27.14+95b99ee
worker-2    Ready    worker                 12d   v1.27.14+95b99ee
worker-3    Ready    worker                 12d   v1.27.14+95b99ee
worker-4    Ready    worker                 12d   v1.27.14+95b99ee
worker-5    Ready    worker                 12d   v1.27.14+95b99ee

② ワーカー・ノードの中に必要なディレクトリーを作成

全てのワーカーノードの中に、Data cache が使用するディレクトリーを作成します。
このディレクトリーを作成するファイルシステムには、Data cache を作成するために十分な容量が必要となります。今回の環境では /var の下に十分な容量があるため /var の下にサブディレクトリーを作成します。
PV は Data cache が構成される Presto のPodの数だけ必要になります。コーディネーターとワーカー両方のポッドに Data cache が作成されます。今回の環境ではコーディネーターのポッドが1個、ワーカーのポッドが5個稼働していますので6個のPVが必要です。
少々複雑ですが、各PVはワーカーノードの中の特定のディレクトリー (path)を指定して作成します。ポッドが起動する時に Data cahe のためにどのPVを使用するかは制御できませんので、どのPVが使用されても良いように、全てのワーカーノードの中に予めPV用の6個のディレクトリーを作成しておきます。
以下にその手順を示します。
まず、"oc debug node/<ワーカーノード名>" を実行して、ワーカーノードの中に入ります。Warningが表示される場合がありますが無視します。少し待つとプロンプトが表示されますので "chroot /host" を実行します。
この後でPV用の6個のディレクトリーを作成します。ディレクトリーが作成された事を確認したら "exit" を 2回実行してノードのデバッグから抜けます。
この作業を全てのノードで実行します。

$ oc debug node/worker-1
Warning: would violate PodSecurity "baseline:v1.24": host namespaces (hostNetwork=true, hostPID=true), hostPath volumes (volume "host"), privileged (container "container-00" must not set securityContext.privileged=true)
Starting pod/worker-1-debug ...
To use host binaries, run `chroot /host`
Pod IP: 192.168.252.14
If you don't see a command prompt, try pressing enter.
sh-4.4# chroot /host
sh-5.1# mkdir -p /var/dataCache/pv1
sh-5.1# mkdir -p /var/dataCache/pv2
sh-5.1# mkdir -p /var/dataCache/pv3
sh-5.1# mkdir -p /var/dataCache/pv4
sh-5.1# mkdir -p /var/dataCache/pv5
sh-5.1# mkdir -p /var/dataCache/pv6
sh-5.1# ls /var/dataCache
pv1  pv2  pv3  pv4  pv5  pv6
sh-5.1# exit
exit
sh-4.4# exit
exit
Removing debug pod ...

4.PVを作成するYAMLファイルを作成

PVを作成するためのYAMLファイルを作成します。
・storageClassName には任意の名前を指定します。
・path には 2 のステップでワーカーノードに作成したディレクトリーを指定します。
・nodeAffinity の values には、ワーカーノード名を列挙します。
name と path が異なる6個のYAMLファイルを作成します。
data-cache-pv2.yaml では、"name: data-cache-storage-pv2","path: /dev/dataCache/pv2" のような指定をして6個のYAMLファイルを作成します。

例)

$ cat data-cache-pv1.yaml
apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: data-cache-storage-pv1
  spec:
    capacity:
      storage: 10Gi
    volumeMode: Filesystem
    accessModes:
    - ReadWriteOnce
    persistentVolumeReclaimPolicy: Delete
    storageClassName: data-cache-storage
      local:
        path: /var/dataCache/pv1
  nodeAffinity:
      required:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/hostname
            operator: In
            values:
            - worker-1
            - worker-2
            - worker-3
            - worker-4
            - worker-5

5.PVを作成

"oc apply -f " で6個のYAMLファイルを指定して、6個のPVを作成します。

$ oc apply -f data-cache-pv1.yaml
persistentvolume/data-cache-storage-pv1 created
..........
$ oc apply -f data-cache-pv6.yaml
persistentvolume/data-cache-storage-pv6 created

6.Data 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

7.Data 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-blue" deleted

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

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

今回は下記のプロパティーの設定で Data cache を作成します。
cacheStorageSize の単位が Gi ,cache_alluxio_max_cache_size の単位が GB である事に注意してください。

プロパティー	値
cacheStorageClass	data-cache-storage
cacheStorageSize	10Gi
cache_alluxio_max_cache_size	10GB

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

$ oc patch wxdengine/lakehouse-presto-01 --type=merge -p '{ "spec": { "cacheStorageClass":"data-cache-storage","cacheStorageSize":"10Gi","cache_alluxio_max_cache_size": "10GB" } }'
wxdengine.watsonxdata.ibm.com/lakehouse-presto-01 patched

しばらくすると Presto のステートフルセットとポッドが再起動しますので確認します。
数分以上かかる場合がありますので辛抱強く待ちます。

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

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

9.ポッドの中に /mnt/flash/data ディレクトリーが作成されている事を確認

$ oc exec -it ibm-lh-lakehouse-presto-01-presto-worker-0 -- bash
bash-4.4$ ls /mnt/flash
data

/mnt/flash/data ディレクトリーはコーディネーターのポッドの中にも作成されています。念のため全てのポッドの中に /mnt/flash/data ディレクトリーが作成されている事を確認しましょう。

10.Persistent Volume Claim (PVC) を確認

マニュアルには記載がありませんが Data cache を作成すると Persistent Volume Claim (PVC) が作成され、4 と 5 のステップで作成したPVと接続 (Bound) されている事が確認できます。

$ oc get pvc | grep data-cache
ibm-lh-cache-mount-ibm-lh-lakehouse-presto-01-coordinator-blue-0  Bound  data-cache-storage-pv4  10Gi  RWO  data-cache-storage  13m
ibm-lh-cache-mount-ibm-lh-lakehouse-presto-01-presto-worker-0      Bound  data-cache-storage-pv1  10Gi  RWO  data-cache-storage  13m
ibm-lh-cache-mount-ibm-lh-lakehouse-presto-01-presto-worker-1      Bound  data-cache-storage-pv2  10Gi  RWO  data-cache-storage  13m
ibm-lh-cache-mount-ibm-lh-lakehouse-presto-01-presto-worker-2      Bound  data-cache-storage-pv6  10Gi  RWO  data-cache-storage  13m
ibm-lh-cache-mount-ibm-lh-lakehouse-presto-01-presto-worker-3      Bound  data-cache-storage-pv3  10Gi  RWO  data-cache-storage  13m
ibm-lh-cache-mount-ibm-lh-lakehouse-presto-01-presto-worker-4      Bound  data-cache-storage-pv5  10Gi  RWO  data-cache-storage  13m

1番左の列が作成された PVCの名前、3番目の列がPVの名前です。2番目の列が全て Bound であれば、PVC と PV が接続されていて、作成した PV が Data cache として正常に使用可能である事が確認できます。Bound ではなく Available になっている場合は PV が Data cache として使用されませんので Data cache の作成手順に問題が無いか確認して作り直す必要があります。

おわりに

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

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