PentahoでDB接続情報を共有する／DB接続情報をパラメータ化する

タイトルにあげた「DB接続情報を共有する」「DB接続情報をパラメータ化する」というのは、いずれもこちらのブログ記事に記載されていることなのですが、左記の記事では2つのことをいっぺんに述べようとしているせいかどうもそのメリットが伝わってきません。

まずやりたいことを整理しましょう：

共有・・・複数のジョブ（Job）や変換（Transformation）で同じデータベース接続情報を共有させたい
パラメータ化・・・DB接続情報の定義を外部化して、検証環境・本番環境など稼働フェーズにあわせて接続情報だけを切り替えられるようにしたい
共有とパラメータ化の組み合わせ・・・パラメータ化されたDB接続情報を、複数のジョブや変換で共有させたい

DB接続情報の共有

これはとても簡単です。

Spoonの左側ペインの［ビュー］タブ→［データベース接続］配下から、複数のジョブや変換の間で共有したい接続情報を右クリック→［共有］をクリックします。すると当該のDB接続情報のラベルが太字になります。

この状態で画面で表示中のジョブや変換を保存すると、Spoonを起動している個人ユーザのホーム・ディレクトリ配下.kettleディレクトリ内にあるshared.xmlというXMLファイルに、この接続情報が書き出されます。

こうして共有状態にしたデータベース接続情報は他のジョブや変換の［ビュー］タブ→［データベース接続］配下に表示されるようになります。

パラメータ化

こちらもそんなに難しい話ではありません。

Pentahoでは、すべてではないようですがジョブや変換の設定項目のなかで、${プロパティ名}という書式でパラメータを使用できるようになっています。

このパラメータのことをPentahoの公式マニュアルや解説記事ではしばしば「環境変数」と呼んでいます。それがPentahoのターミノロジーなのですから文句を言っても仕方ないのですが、実際にはこれはJavaのプロパティのことです。

.kettleディレクトリ内にはkettle.propertiesというプロパティ・ファイルも存在しており、こちらに記載しておいたプロパティはSpoon起動時にロードされます。デフォルトでは下記のようにコメントが記載されているだけです（技術系ドキュメントやサンプルコードでギリシャ神話の神々の名前を見たのは初めてです・・・）：

# This file was generated by Pentaho Data Integration version 5.3.0.0-213.
# 
# Here are a few examples of variables to set: 
#
# PRODUCTION_SERVER = hercules
# TEST_SERVER = zeus
# DEVELOPMENT_SERVER = thor
#
# Note: lines like these with a # in front of it are comments
#

ここに例えば下記のようにDB接続情報を記述しておけば、Spoonの画面側では${PG_SERVER_HOST}や${PG_SERVER_PORT}などの「環境変数」を利用できるようになります。

(中略)
# DEVELOPMENT_SERVER = thor
#
# Note: lines like these with a # in front of it are comments
#

PG_SERVER_HOST = peth1dbs01
PG_SERVER_PORT = 5433
PG_USER_ID = peth1usr01
PG_USER_PASSWORD = xxxxxxx

このパラメータ化についておもしろいのは［データベース接続］の設定のうちでもパスワードに関してです（原典）。［パスワード］欄は何しろパスワードを入力する欄なので、入力内容は伏字で表示されることになります。${PG_USER_PASSWORD}というパラメータ化された記述にしてもそれは代わりません。そうではあってもこの記述をしておけばその値はkettle.propertiesで定義した値に実行時に置き換えられます。

共有とパラメータ化の組み合わせ

以上の2つのテクニックを組み合わせると、DB接続情報を複数のジョブや変換の間で共有させつつ、検証環境・本番環境など稼働フェーズにあわせて切り替えを行うということが可能になります（もちろんこれが前述の記事で執筆者が述べたかったことです）。

ジョブや変換の定義ファイル、そしてshared.xmlはすべての環境（フェーズ）で同じものを使用します。一方、kettle.propertiesは環境（フェーズ）ごとにその環境固有の設定値を持たせて配備します。こうすることで共有とパラメータ化の組み合わせがなり、まともな構成管理ができるようになるわけです。

なおこちらのフォーラムの投稿では.kettleディレクトリの位置を任意の場所に変更する方法も紹介されています。

ただしこの投稿を読むとまるでKETTLE_HOMEには.kettleディレクトリのパスを設定するかのように書かれていますが、実際は.kettleディレクトリのあるディレクトリ（.kettleディレクトリの親ディレクトリ）のパスを設定するのが正しいようです。つまり仮に.kettleディレクトリの絶対パスが/Users/foo/Devel/Pentaho/.kettleの場合、export KETTLE_HOME=/Users/foo/Devel/Pentahoとするのです。

実行環境となるマシンが環境（フェーズ）間で別々になっていない場合はこの投稿で紹介されている方法（環境変数KETTLE_HOMEでパスを指定する）が役に立ちそうです。

おまけ：定義済み「内部変数」

公式リファレンスのこちらのページに、あらかじめ定義済みの「内部変数」（Internal Variables）の紹介があります。使用方法は「環境変数」と変わりありません。いずれも入力ファイルや出力先ファイルのパスを指定する際や、H2やDerbyなどの組み込みDBのJDBC接続文字列を指定する際には必須のものばかりです。

例としてあげると：

変数名	値の例
Internal.Transformation.Filename.Directory	D:\Kettle\samples
Internal.Transformation.Filename.Name	Denormaliser - 2 series of key-value pairs.ktr
Internal.Transformation.Name	Denormaliser - 2 series of key-value pairs sample
Internal.Job.Filename.Directory	file:///home/matt/jobs
Internal.Job.Filename.Name	Nested jobs.kjb
Internal.Job.Name	Nested job test case