キャッシュデータベース固有の情報¶
ここでは、キャッシュデータの保存に使用するデータベースに応じて考慮する必要がある情報について説明します。
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 サーバーは、Hadoop プロパティで指定された JSON ファイルから取得した資格情報を用いて、Google Cloud Storage に接続します。
このデータベースはフルキャッシュモードのみをサポートします。部分キャッシュを使用するビューを無視して、キャッシュを持たないかのように動作します。
キャッシュにデフォルトとは異なるカタログ/スキーマを使用する必要が生じると、[Read & Write] タブのドロップダウンリストに表示されるカタログが 1 つだけであることがわかります。これは、データソース作成時のコネクション URI にプロジェクト名 (プロジェクトは bigquery におけるカタログ) を含める必要があるためです。そのため、このカタログのみが許可されます。
Kudu¶
Impala 3.x Kudu を使用してキャッシュデータを保存する場合、以下の点を考慮してください。
Kudu をキャッシュとして使用するビューはプライマリキーを保持している必要があります。
Kudu をキャッシュとして使用するビューでは、[Time to Live] を ['Never expire'] に設定してください。[Time to Live] が ['Never expire'] 以外になっているビューでは、Kudu をキャッシュデータソースとして使用できません。
PrestoDB/Trino¶
PrestoDB/Trino を使用してキャッシュデータを保存する場合、以下の点を考慮してください。
一括読み込みのみがサポートされているため、[Read & Write] タブで [Use bulk data load APIs] を選択し、一時ファイルのシステムストレージ、資格情報、ルートを指定する必要があります。「 分散オブジェクトストレージを使用するデータベース 」のセクションを参照してください。
PrestoDB/Trino を使用してキャッシュデータを保存する場合、ビューのキャッシュモードとして [Partial] を選択しないでください。これを選択した場合、データはキャッシュされません。
Virtual DataPort は、管理されていない (外部) Hive テーブルを使用して PrestoDB/Trino にデータを転送します。外部テーブルを使用する場合、データファイルのアップロード用に構成された URI が、キャッシュまたはデータ移動に使用されるスキーマの場所とは異なる可能性があります。PrestoDB/Trino の
hive.non-managed-table-writes-enabled
構成プロパティがtrue
であることを確認してください。それ以外の値の場合、PrestoDB/Trino へのデータ保存プロセスは失敗します。旧バージョンの Denodo の動作 (つまり外部テーブルを使用しない動作) に戻すには、以下を実行します。SET 'com.denodo.vdb.util.tablemanagement.sql.PrestoTableManager.useExternalTables'='false';
この変更を適用するために再起動は不要です。
組み込み Denodo MPP¶
フルキャッシュモードのみがサポートされるため、データ一括読み込みを構成する必要があります。
「 分散オブジェクトストレージを使用するデータベース 」のセクションを参照してください。
Spark¶
キャッシュの無効化プロセスの実行中には、Parquet ファイルの変更中に実行された一部のクエリは失敗する可能性があります。
Yellowbrick¶
Yellowbrick は、そのデータベースのエンコードタイプとして LATIN9 (デフォルト) と UTF-8 の 2 つをサポートしています。Virtual DataPort で完全にサポートできるのは、 UTF-8 エンコードを使用するデータベースのみ であることに注意してください。データベースを作成する際に encoding = UTF-8
を指定することによって、データベースのエンコードを選択できます。
LATIN9 でエンコードされたデータベースをキャッシュデータベースとして使用する場合、他のデータソースからデータをキャッシュする際に、無効な文字を使用するデータが失われる可能性があります。
分散オブジェクトストレージを使用するデータベース¶
分散オブジェクトストレージを使用するデータベースでサポートされているシステムは S3 や ADLS、HDFS、および Azure ストレージなどの Hadoop API と互換性のあるストレージです。
Hadoop 互換のオブジェクトストレージ (Hive、Impala、Presto、Spark、および Databricks) を使用するデータベースでは、フルキャッシュモードのみをサポートします。部分キャッシュを使用するビューは無視され、キャッシュが存在しないかのように動作します。
一時ファイルは、デフォルトで Parquet 形式と snappy
圧縮を使用して生成されます。これらの構成の詳細については、「 HDFS、S3、または ADLS などの分散オブジェクトストレージへのデータ一括読み込み 」のセクションを参照してください。
さらに、これらのデータベースでは Full キャッシュ の無効化のみがサポートされます。