はじめに
watsonx.data はキャッシュを構成する事により Prestoエンジンを使用した照会のパフォーマンスを向上する事ができます。
参考文献
RaptorX: Building a 10X Faster Presto
この文書によると Presto のキャッシュは階層構造になっており、5種類の異なるキャッシュを構成する事により、リモートのストレージからメタデータやデータの取得に要する時間を大幅に短縮する事ができます。
watsonx.data 1.1.3 に含まれる 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 1.1.3 ではデフォルトで使用可能となっています。
今回は、5種類のキャッシュの中から Data cache について構成方法をご紹介します。
Data cache はデフォルトでは使用可能になっていないため構成手順に従って構成する必要があります。
Fragment result cache については以下の記事をご参照ください。
watsonx.data 1.1.3 で Fragment result cache を構成してみた (キャッシュ編 その2)
File list cache については以下の記事をご参照ください。
watsonx.data 1.1.3 で File list cache を構成してみた (キャッシュ編 その3)
Data cache について
ここで Data cache について、もう少し詳しく説明します。
Presto のワーカーは、リモートストレージから読み取ったデータを元のデータの形式 (圧縮や暗号化されている場合でも) で1MBの単位でキャッシュとしてワーカーのローカル・ディスクに保存します。
コーディネーターは、実行要求があったSQLの結果がキャッシュに含まれるワーカーに処理をスケジュールします。もしこのワーカーが忙しかったり使用可能でない場合は、SQLの結果がキャッシュに含まれていなくても 別のワーカーに処理をスケジュールします。この仕組みを Soft affinity scheduling と呼んでいます。
この仕組みにより、一度読み込まれて Data cache に保存されたデータを繰り返し リモート・ストレージから読む事を防いで照会のパフォーマンスを向上する事ができます。以下に Data cache を構成する手順を記述します。
Data cache の構成手順
参考文献 (watsonx.data 1.1.x のマニュアル)
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 1.1.3 の Presto の Data cache では、TTL (キャッシュの有効期間) を設定する事ができませんが、将来のバージョンで設定できるようになる事を期待しましょう。
今回は OpenShift の localstorageProvisioner を使用したPersistent Volume (PV)をData cache のストレージとして使用します。watsonx.data 1.1.x のマニュアル上ではオプションとなっていますが、localstorageProvisioner を使用したPVを作成する事により、ワーカー・ポッドが直接マウントしたローカル・ボリュームをキャッシュとして使用する事ができるため、キャッシュの読み書きのパフォーマンスの向上を期待する事ができます。
ODF等の既存のコンテナ・ストレージのストレージ・クラスを使用すると短い手順で Data cache を構成する事ができますが、キャッシュの読み書きがネットワーク経由となり遅延が発生する可能性があります。
1.OCPクラスターにログイン
"oc login" コマンドでOCPクラスターにログインします。
2.watsonx.data のプロジェクトに変更
作業中のプロジェクトをwatsonx.data がインストールされているプロジェクトに変更します。今回の環境では watsonx.data は 名前スペース wxd にインストールされています。
$ export PROJECT_WXD_INST_OPERANDS=wxd
$ oc project ${PROJECT_WXD_INST_OPERANDS}
3.ワーカー・ノードの中に必要なディレクトリーを作成
デバッグセッションで、OpenShiftの全ワーカー・ノードの中に必要なディレクトリーを作成します。
① ワーカーノードの確認
"oc get node"でOCPのノードの一覧を出力して、NAMEとROLESからワーカーノードを判断します。ストレージノードは対象外です。
$ oc get node
NAME STATUS ROLES AGE VERSION
master-1 Ready control-plane,master 38d v1.26.13+8f85140
master-2 Ready control-plane,master 38d v1.26.13+8f85140
master-3 Ready control-plane,master 38d v1.26.13+8f85140
storage-1 Ready worker 38d v1.26.13+8f85140
storage-2 Ready worker 38d v1.26.13+8f85140
storage-3 Ready worker 38d v1.26.13+8f85140
worker-1 Ready worker 38d v1.26.13+8f85140
worker-2 Ready worker 38d v1.26.13+8f85140
worker-3 Ready worker 38d v1.26.13+8f85140
worker-4 Ready worker 38d v1.26.13+8f85140
worker-5 Ready worker 38d v1.26.13+8f85140
② ワーカー・ノードの中に必要なディレクトリーを作成
全てのワーカーノードの中に、"/dev/<サブディレクトリー>" ディレクトリーを作成します。<サブディレクトリー> の部分は任意のサブディレクトリー名を指定します。今回は dataCache とします。
oc debug node/<ワーカーノード名> -- chroot /host mkdir -p /dev/dataCache
コマンドを実行するとWarningが表示されますが無視します。
ワーカー・ノードに /dev/dataCache ディレクトリーが作成されている事を確認します。
oc debug node/<ワーカーノード名> -- chroot /host ls /dev | grep dataCache
4.PVを作成するYAMLファイルを作成
PVを作成するYAMLファイルを作成します。
YAMLファイルの例)
・name と storageClassName にには任意の名前を指定します。
・path には 2 のステップでワーカーノードに作成したディレクトリーを指定します。
・nodeAffinity の values には、ワーカーノード名を列挙します。
$ cat dataCache-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: /dev/dataCache
nodeAffinity:
required:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- worker-1
- worker-2
- worker-3
- worker-4
- worker-5
5.PVを作成
Prestoのポッドが複数ある場合は、name の値が異なるYAMLファイルを Prestoのポッドの数 (コーディネーター + ワーカー) だけ作成して、PVを作成します。今回の環境では1個のコーディネーター・ポッドと5個のワーカー・ポッドが存在するため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-green" deleted
statefulset.apps "ibm-lh-lakehouse-presto-01-presto-worker" deleted
statefulset.apps "ibm-lh-lakehouse-presto-01-single-green" 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 -n wxd -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-green 1/1 8m9s
ibm-lh-lakehouse-presto-01-presto-worker 5/5 8m9s
ibm-lh-lakehouse-presto-01-single-green 0/0 8m11s
$ oc get pod | grep presto
ibm-lh-lakehouse-presto-01-coordinator-green-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 ディレクトリーはコーディネーターのポッドの中にも作成されています。念のため全てのポッドにディレクトリーが作成されている事を確認しましょう。
10.Persistent Volume Claim (PVC) を確認
マニュアルには記載がありませんが Data cache を作成すると PVC が作成され、4 と 5 のステップで作成したPVと接続 (Bound) されている事が確認できます。
$ oc get pvc | grep data-cache
ibm-lh-cache-mount-ibm-lh-lakehouse-presto-01-coordinator-green-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 1.1.3 の Presto の照会のパフォーマンスを向上するためのキャッシュの1つである Data cache の構成について紹介しました。