キャッシュデータベース固有の情報¶
ここでは、キャッシュデータの保存に使用するデータベースに応じて考慮する必要がある情報について説明します。
Amazon Athena¶
Athena を使用してキャッシュデータを保存する場合、以下の点を考慮してください。
Amazon Athena をキャッシュデータベースとして使用するには、 データ一括読み込み を有効にしてデータを S3 にアップロードする必要があります。
[Read & Write] タブで [Use bulk data load APIs] をチェックして、[Authentication type]、[AWS access key id]、[AWS secret access key]、[AWS IAM role ARN] (オプション)、および [S3 Location] の各フィールドに値を入力します。これを行わないと、Virtual DataPort はデータをキャッシュできません。
[AWS IAM role ARN] は、ユーザーが引き受ける IAM ロールの Amazon リソースネームであり、オプションのフィールドです。このロールは、AWS S3 バケットの管理に必要な権限を付与します。この値の形式は
arn:aws:iam::<awsAccountId>:role/<roleName>
です。Athena をキャッシュデータベースとして使用する場合、ビューでは Full キャッシュモードのみを有効にすることができます。 Partial キャッシュ を有効にした場合、データはキャッシュされません。
Azure SQL Data Warehouse¶
Azure SQL Data Warehouse データソースをキャッシュとして使用する場合、制限事項がいくつかあります。
Azure SQL Data Warehouse はテーブルの一意のインデックスをサポートしません。
データ移動とマテリアライズドテーブルの作成をトランザクション内で行うことはできません。
バイナリおよび複合型の列 (配列およびレジスター) は、8,000 バイトに制限されます。キャッシュロードプロセスの実行中にこのサイズを超えた場合、プロセスは「String または binary データは切り詰められました。」というエラーで終了します。
「読み取りのコミット解除」が使用可能な唯一の分離レベルです。
キャッシュの構成の [Driver class path] ボックスで [mssql-jdbc-7.x] が選択されていることを確認してください。選択されていない場合、いくつかの機能が正常に動作しない可能性があります。
Google BigQuery¶
Google BigQuery を使用してキャッシュデータを保存する場合、以下の点を考慮してください。
[Read & Write] タブから選択できる File System は HDFS のみです。
[Read & Write] タブから [Use bulk data load APIs] をチェックし、[HDFS URI] フィールドを入力します。
また、以下の Hadoop プロパティを確立する必要があります。
google.cloud.auth.service.account.enable = true google.cloud.auth.service.account.json.keyfile = < path of the JSON file that contains your service account key>
Virtual Dataport が BigQuery にデータを転送する際は、まずデータを Google Cloud Storage (GCS) にアップロードし、その後 GCS から BigQuery テーブルにデータを読み込みます。そのため、VDP サーバーは、Hardoop プロパティで指定された JSON ファイルから取得した資格情報を用いて、Google Cloud Storage に接続します。
このデータベースはフルキャッシュモードのみをサポートします。部分キャッシュを使用するビューを無視して、キャッシュを持たないかのように動作します。
キャッシュにデフォルトとは異なるカタログ/スキーマを使用する必要が生じると、[Read & Write] タブのドロップダウンリストに表示されるカタログが 1 つだけであることがわかります。これは、データソース作成時のコネクション URI にプロジェクト名 (プロジェクトは bigquery におけるカタログ) を含める必要があるためです。そのため、このカタログのみが許可されます。
PrestoDB/PrestoSQL¶
PrestoDB/PrestoSQL を使用してキャッシュデータを保存する場合、以下の点を考慮してください。
PrestoDB/PrestoSQL を使用できるのは、データが Hadoop Distributed File System (HDFS) に保存されている場合のみです。
[Read & Write] タブで [Use bulk data load APIs] をチェックして、[HDFS URI] および [Hadoop executable location] の各フィールドに値を入力します。これを行わないと、Virtual DataPort はデータをキャッシュできません。
PrestoDB/PrestoSQL を使用してキャッシュデータを保存する場合、ビューのキャッシュモードとして [Partial] を選択しないでください。これを選択した場合、データはキャッシュされません。
Virtual DataPort は、管理されていない (外部) Hive テーブルを使用して PrestoDB/PrestoSQL にデータを転送します。外部テーブルを使用する場合、データファイルのアップロード用に構成された URI が、キャッシュまたはデータ移動に使用されるスキーマの場所とは異なる可能性があります。PrestoDB/PrestoSQL の
hive.non-managed-table-writes-enabled
構成プロパティがtrue
であることを確認してください。それ以外の値の場合、PrestoDB/PrestoSQL へのデータ保存プロセスは失敗します。旧バージョンの Denodo の動作 (つまり外部テーブルを使用しない動作) に戻すには、以下を実行します。SET 'com.denodo.vdb.util.tablemanagement.sql.PrestoTableManager.useExternalTables'='false';
この変更を適用するために再起動は不要です。
Spark¶
キャッシュの無効化プロセスの実行中には、Parquet ファイルの変更中に実行された一部のクエリは失敗する可能性があります。
Yellowbrick¶
Yellowbrick は、そのデータベースのエンコードタイプとして LATIN9 (デフォルト) と UTF-8 の 2 つをサポートしています。Virtual DataPort で完全にサポートできるのは、 UTF-8 エンコードを使用するデータベースのみ であることに注意してください。データベースを作成する際に encoding = UTF-8
を指定することによって、データベースのエンコードを選択できます。
LATIN9 でエンコードされたデータベースをキャッシュデータベースとして使用する場合、他のデータソースからデータをキャッシュする際に、無効な文字を使用するデータが失われる可能性があります。
HDFS ストレージを使用するデータベース¶
HDFS ストレージを使用するデータベース (Hive、Impala、Presto、Spark、および Databricks) は、Full キャッシュモードのみをサポートします。Partial キャッシュを使用するビューは無視され、キャッシュが存在しないかのように動作します。
一時ファイルは、 snappy
圧縮方式で生成されます。Parquet ファイルの圧縮方式を変更する場合、VQL シェルから次のコマンドを実行します。
SET 'com.denodo.vdb.util.tablemanagement.sql.insertion.HdfsInsertWorker.parquet.compression'
= '<compression mechanism>';
「<compression mechanism>」の値として、 off
(圧縮なし)、 snappy
、 gzip
、または lzo
を指定できます。
このプロパティを変更した後で再起動は不要です。
選択した圧縮アルゴリズムがデータベースでサポートされている必要があります。
これらのファイルを圧縮して生成することにより、ビューのキャッシュロードプロセスまたはデータ移動が高速化される可能性があります。ただし、データベースが Denodo サーバーと同じローカルエリアネットワーク内にある場合は、転送速度が高速であるため、高速化されない可能性があります。高速化されないにもかかわらず Denodo サーバーは圧縮ファイルを生成しなければならないため、CPU 使用率が増加する可能性があります。
さらに、これらのデータベースでは Full キャッシュ の無効化のみがサポートされます。