サーバー設定¶
[サーバー設定] ダイアログからは Data Catalog サーバーのすべての設定を構成できます。このダイアログの機能は以下のタブごとにまとめられています。
VDP サーバー: ログインページから利用できる Virtual DataPort サーバー と、すべてのクエリが使用する 接続設定 を構成できます。
認証: Data Catalog で Kerberos を使用したシングルサインオン を有効化できます。
データベース: Data Catalog のメタデータを保管する 外部データベース を構成できます。
権限: 追加タスクを実行する権限を パワーユーザーに付与 できます。
AI Integration: ビュー詳細タブで使用できる アシスト付きクエリ 機能を構成します。
Virtual DataPort サーバーの構成¶
[VDP サーバー] タブの [サーバー] セクションから、ログインダイアログに表示される Virtual DataPort サーバーを構成できます。
ログインページに列挙される Virtual DataPort サーバーを構成するダイアログ¶
Virtual DataPort サーバーを新規追加するには、[サーバーの追加] ボタンをクリックし、以下の値を入力します。
名前: ログインページに表示する、このサーバーの名前。
URL: サーバーの接続 URL。
//<host>:<port>/<database>というパターンに従って指定します。入力の際は以下の点を考慮してください。Data Catalog に接続できるのは、データベースへの
CONNECT権限を持つユーザーのみです。特定のデータベースに対する LDAP 認証をサーバーで構成している場合、URL でこのデータベースを使用します。
説明: サーバーの説明。
Virtual DataPort サーバーの新規追加ダイアログ¶
注釈
保存されたクエリ は、ユーザーおよび Virtual DataPort サーバーごとに保存されます。Virtual DataPort サーバーは内部 ID によって識別されるため、サーバーを編集しても、そのサーバーに関連付けられたクエリはそのまま維持されますが、サーバーを削除するとクエリも削除されます。
注釈
自動クラウドモード の場合、$DENODO_HOME/conf/data-catalog/DataCatalogBackend.properties ファイルで次のプロパティを編集することで、デフォルトのサーバーを構成できます。
com.denodo.dc.vdp.port=<port>
com.denodo.dc.vdp.host=<hostname>
com.denodo.dc.vdp.servername=<servername>
Virtual DataPort サーバーへの接続設定の構成¶
[VDP サーバー] タブの [接続設定] セクションでは、Virtual DataPort サーバーに対してクエリを実行するために作成されるグローバル接続パラメータを構成できます。
Virtual DataPort サーバーへの接続設定の構成ダイアログ¶
パラメータの内容は以下のとおりです。
クエリアイムアウト: クエリがステートメントの完了を待つ最大時間 (ミリ秒単位)。指定されていない場合 (または値に 0 を指定した場合)、クエリは実行が完了するまで待機します。デフォルトは 900,000 ミリ秒です。
チャンクタイムアウト: クエリが新しい結果のチャンクの到着を待つ最大時間 (ミリ秒単位)。この時間を超過すると、Virtual DataPort はその時点までに抽出された結果を返します。この値が指定されていない場合 (または値に 0 を指定した場合)、Virtual DataPort はステートメントの実行終了時にすべての結果をまとめて返します。デフォルトは 90,000 ミリ秒です。
チャンクサイズ: 結果のチャンクを構成する結果の数。Virtual DataPort ツールは結果をこの数だけ取得すると、[Chunk timeout] の値に達していなくても Data Catalog に結果を返します。デフォルトは 1,000 行です。
Kerberos を使用したシングルサインオンの有効化¶
[認証] タブから、Data Catalog での Kerberos を使用したシングルサインオン を有効化できます。
Data Catalog での Kerberos 認証の構成ダイアログ¶
以下の手順に従って実施してください。
[Kerberos の使用] オプションを有効化します。
[サーバープリンシパル] フィールドに Data Catalog のサービスプリンシパル名を入力します。keytab ファイルの生成に使用したものと同じ値を入力してください。
keytab ファイルを [keytab ファイル] フィールドにドラッグ & ドロップします。または、フィールドをクリックしてファイルブラウザから選択することも可能です。
以下のいずれかの条件を満たしており、システムのデフォルトロケーションに krb5 ファイルが存在しない場合、[構成ファイル] フィールドに krb5 ファイルを追加することを検討してください。
Data Catalog を実行しているホストが Kerberos レルム (Windows Active Directory ドメインなど) に属していない場合。
Data Catalog を実行しているホストが Linux/Unix の場合。
Data Catalog 用に構成された Active Directory のサービスアカウントで、 制約付き委任 (constrained delegation) のオプションが有効になっている場合。
クロスドメインシナリオを使用している場合。つまり、組織が複数のドメインを使用している場合。
該当しない場合、フィールドは空のままで構いません。
参考
krb5 ファイルの詳細については、「 Kerberos 認証用の krb5 ファイルの提供 」を参照してください。
何らかの問題が生じた場合は、[Kerberos デバッグモードの有効化] オプションを選択してください。問題が生じていない場合は、このオプションを無効にしてください。
参考
Kerberos に関する問題のデバッグについては、「 Web アプリケーションで Kerberos をデバッグする方法 」を参照してください。
[保存] ボタンをクリックして Kerberos 構成を確定します。この構成は即座に有効になります。Data Catalog の再起動は不要です。
重要
Kerberos 認証の構成に失敗し、Data Catalog に誰もログインできなくなった場合でも、 ローカル認証 または ログインとパスワードによる認証 による接続が可能です。接続後、Kerberos 設定を変更するか、デバッグモードを有効化してください。
Data Catalog での外部データベースの使用¶
ここでは、設定を外部データベースに保存するように Data Catalog を構成する方法について説明します。Data Catalog サーバーのクラスタをセットアップして、すべてのサーバーに同じ設定とメタデータを共有させる場合には、これが必須です。
デフォルトでは、Data Catalog は、グローバル設定と各ユーザーの特定の設定を組み込みデータベース (Apache Derby) に保存します。たとえば、ユーザーの保存されたクエリや、ビューの検索画面にデフォルトで表示する、管理者が選択したフィールドの設定などです。これらをすべて外部データベースに保存するように Data Catalog を構成できます。
Data Catalog は以下のデータベースをサポートします。
MySQL
注釈
MySQL (または、使用する MySQL 内のデータベース) で
Default Charset = utf8オプションとCollation = utf8_unicode_ciオプションを構成してください。Oracle
PostgreSQL
SQL Server
MySQL 用および PostgreSQL 用の Amazon Aurora
Azure SQL Server
注釈
各データベースのバージョンの最小要件は、
MySQL 5.6
Oracle 12c
PostgreSQL 9.5
SQL Server 2014
MySQL 5.7 用の Amazon Aurora および PostgreSQL 9.5 用の Amazon Aurora
Data Catalog のメタデータを外部データベースに保存するには、以下の手順に従って実施してください。
外部データベースで、Data Catalog のメタデータ用のカタログかスキーマを作成します。
既存のスキーマを使用することも可能ですが、他のアプリケーションとはテーブルを分離するため、新規作成することをお勧めします。このスキーマには 5 GB の容量を確保することをお勧めします。ほとんどの場合、これほどの容量は不要ですが、データベースで容量不足の問題が発生しないように、大きな値を設定することをお勧めします。
このデータベースで、そのデータベースに対する作成、読み取り、および書き込みの権限を持つサービスアカウントを作成します。
稼働時間の厳しい要件を満たすために、このデータベースの高可用性機能を有効にすることを検討してください。
このデータベースの JDBC ドライバーをディレクトリ
<DENODO_HOME>/lib/data-catalog-extensionsにコピーします。以下の点を考慮してください。
Oracle 12 を使用する場合、
<DENODO_HOME>/lib/extensions/jdbc-drivers/oracle-12c-v12.2.0.1にあるojdbc6.jarファイルとorai18n.jarファイルのみをコピーしてください。Oracle 18 を使用する場合、
<DENODO_HOME>/lib/extensions/jdbc-drivers/oracle-18cにあるojdbc8.jarファイルとorai18n.jarファイルのみをコピーしてください。Oracle 19 を使用する場合、
<DENODO_HOME>/lib/extensions/jdbc-drivers/oracle-19cにあるojdbc8.jarファイルとorai18n.jarファイルのみをコピーしてください。Oracle 21 を使用する場合、
<DENODO_HOME>/lib/extensions/jdbc-drivers/oracle-21cにあるojdbc8.jarファイルとorai18n.jarファイルのみをコピーしてください。SQL Server を使用する場合、2 つの異なるドライバーを利用できます。
任意のバージョンで Microsoft ドライバーを使用します。これがお勧めのオプションです。このドライバーを使用する場合、
<DENODO_HOME>/lib/extensions/jdbc-drivers/mssql-jdbc-10.xにあるmssql-jdbc-10.2.0.jre8.jarファイルのみをコピーしてください。バージョン 2014 と 2016 の場合、jTDS ドライバーも使用できます。このドライバーを使用する場合、
<DENODO_HOME>/lib/extensions/jdbc-drivers/denodo-jtds-1.3.1にあるdenodo-jtds-1.3.1.jarファイルをコピーしてください。
MySQL 5.7 用の Amazon Aurora を使用する場合、
<DENODO_HOME>/lib/extensions/jdbc-drivers/mariadb-2.7にあるmariadb-java-client-2.7.1.jarファイルのみをコピーしてください。PostgreSQL 9.5 用の Amazon Aurora を使用する場合、
<DENODO_HOME>/lib/extensions/jdbc-drivers/postgresql-12にあるpostgresql-42.2.5ファイルのみをコピーしてください。Azure SQL Server を使用する場合、
<DENODO_HOME>/lib/extensions/jdbc-drivers/mssql-jdbc-7.xにあるmssql-jdbc-7.2.2.jre8.jarファイルのみをコピーしてください。Active Directory 経由で Azure SQL Server を使用する場合、
<DENODO_HOME>/lib/extensions/jdbc-drivers/mssql-jdbc-7.xにあるファイルmssql-jdbc-7.2.2.jre8.jar、adal4j-1.6.3.jar、gson-2.8.0.jar、oauth2-oidc-sdk-5.64.4.jarと、<DENODO_HOME>/lib/contribにあるファイルaccessors-smart.jar、json-smart.jar、javax.mail.jarとnimbus-jose-jwt.jarをコピーしてください。注釈
更新プログラム 8.0u20220815 以降、ActiveDirectoryPassword 認証方法を使用して Azure SQL Server を外部メタデータデータベースとして使用するには、すでに指定しているファイルに加えて、
<DENODO_HOME>/lib/contribからファイルcontent-type.jarを<DENODO_HOME>/lib/data-catalog-extensionsディレクトリにコピーします。他のデータベースの JDBC については、
<DENODO_HOME>/lib/extensions/jdbc-driversに存在する場合もあります。
Data Catalog に管理者アカウントでログインし、メタデータを エクスポート します。
この操作が必要なのは、Data Catalog のメタデータが現在のデータベースから新しいデータベースに自動的に転送されないためです。新規インストールであり、この Data Catalog に他の変更を加えていない場合には、この手順を省略できます。
Denodo Platform のすべてのコンポーネントを停止します。次に、
<DENODO_HOME>/bin/webcontainer_shutdownを実行して Web コンテナーが停止していることを確認します。Data Catalog と Denodo Platform の他のコンポーネントを開始します。
管理者アカウントで Data Catalog にログインし、[管理] > [設定と管理] > [サーバー] に移動します。[データベース] タブのダイアログから、外部データベースの構成が可能です。
Data Catalog がメタデータを保管するデータベースを構成するダイアログ¶
以下の情報を入力します。
データベース: 使用するデータベースを選びます。
ドライバークラス: 使用する JDBC ドライバーの Java クラスの名前です。通常はデフォルト値のままで問題ありません。
URL: データベースへの接続 URL です。
重要
SQL Server で Microsoft ドライバー 10.x 以降を使用している場合、encrypt プロパティを false に設定する必要があります。それには、データベース URL の末尾に encrypt=false を追加します。以下に例を示します。
jdbc:sqlserver://host:port;databaseName=database;encrypt=false認証: 外部データベースにアクセスするための認証方法です。Oracle と SQL Server 2014 のデータベースでのみ利用可能です。以下のいずれかの方法を選択します。
ログインとパスワード: デフォルトの認証方法です。データベースへの接続に使用するアカウントの資格情報を使用します。[ユーザー名] (オプション) と [パスワード] (オプション) があります。
パスワードを用いた Kerberos 認証: (Active Directory アカウントで) 指定された [ユーザー名] と [パスワード] を用いて Kerberos 認証を行います。
Keytab を用いた Kerberos: 指定された [ユーザー名] (この場合は、サービスプリンシパル名 - SPN -) と [Keytab ファイル] (パスワードは不要) を用いて、Kerberos 認証を行います。keytab ファイルを [Keytab ファイル] フィールドにドラッグアンドドロップするか、フィールドをクリックしてファイルブラウザーから選択することもできます。
Windows ユーザーを用いた Kerberos 認証: Kerberos によるシングルサインオン (SSO) を用いて、サーバーを起動したユーザーのパススルー認証を行います (ユーザー名とパスワードは不要)。
注釈
選択したデータベースが
Derby Embeddedの場合、[ドライバークラス]、[URL]、[ユーザー名]、[パスワード] のフィールドは編集できません。注釈
SQL Server 2014 で jTDS ドライバーを使用するよう構成するには、[ドライバークラス] で値
net.sourceforge.jtds.jdbc.Driverを使用し、パターンjdbc:jtds:sqlserver://<host>:<port>/<database>に従った URL を入力します。クエリ高速化のため、Data Catalog はデータベース接続を保持するプールを作成します。以下のオプション設定によって、プールの構成が可能です。
最大プールサイズ: データベースとの間に存在できる接続の最大数です。この値には、アイドル状態の接続と使用中の接続の両方が含まれます。
最小アイドル接続数: Data Catalog がプールに維持しようとするアイドル接続の最小数です。アイドル接続の数がこの値を下回り、なおかつ、プール内の接続の総数が [最大プールサイズ] より少ない場合、Data Catalog は新規の接続の追加を試みます。
接続タイムアウト: Data Catalog がプールからの接続を待つ最大時間 (ミリ秒単位) です。この時間を超えても接続を利用できない場合、エラーをスローします。
ping クエリ: プールから接続を使用する直前に、接続が有効であることを確認する目的で実行されるクエリです。このクエリが必要なのは、JDBC 4.0
Connection.isValid()API をサポートしていないレガシードライバーだけです。使用するドライバーが JDBC 4.0 をサポートしている場合、このプロパティを設定しないことを強くお勧めします。注釈
Microsoft SQL Server 用の jTDS ドライバーは JDBC 3.0 しかサポートしないため、レガシーだと見なされます。Data Catalog でこのドライバーを使用するには [ping クエリ] フィールドに値を指定する必要があります。
[保存] ボタンをクリックします。
データベースに到達できること、および必要なテーブルが存在することを Data Catalog がチェックします。
選択したデータベース用の JDBC ドライバーを読み込めなかった場合、以下の警告が表示されます。
JDBC ドライバーを読み込めなかった場合の警告¶
この場合でも構成を保存できますが、JDBC ドライバーを利用できるようにしてから Data Catalog を再起動する必要があります。
何らかの理由でデータベースに到達できなかった場合、以下の警告が表示されます。
データベースに接続できなかった場合の警告¶
この場合でも構成を保存できますが、エラーを修正してから Data Catalog を再起動する必要があります。エラーを修正できない場合、構成の保存はお勧めしません。
データベースに必要なテーブルが存在しない場合、以下の警告が表示されます。
データベースでテーブルを作成するダイアログ¶
Data Catalog にテーブルを作成させるかどうかを決定してください。作成にはデータベース用に構成されたユーザーアカウントを使用するため、データベースでの DDL 権限がアカウントに必要です。あるいは、適切な権限を持つ別のユーザーアカウントを指定しても構いません。
スクリプトを手動で実行する場合は、[キャンセル] ボタンをクリックします。このスクリプトは {<DENODO_HOME>}/scripts/data-catalog/sql/db_scripts` フォルダにあります。
重要
テーブルを作成するスクリプトを手動で実行する場合、プラットフォームの今後の更新のたびに、Data Catalog を再び起動する前に、データベーススキーマを更新する可能性がある新しいスクリプトを手動で実行する必要があります。なぜなら、このケースでは、Data Catalog が自動で新しいスクリプトを実行することはできないからです。
それでもスクリプトを手動で実行する場合は、フォルダ
<DENODO_HOME>/scripts/data-catalog/sql/db_scripts/<DATABASE_TYPE>に移動して、テーブルを作成するスクリプトを、そのために作成され、Data Catalog で構成されているスキーマで実行します。- 空のスキーマから始める場合、指定されたフォルダに存在する すべて のスクリプトを、バージョンの昇順に実行する必要があります。
プラットフォーム更新の場合、指定されたフォルダに存在し、それまでの更新で実行されていなかったすべてのスクリプトを、最後に実行されたスクリプトからバージョンの昇順に実行する必要があります。
Data Catalog サーバーのクラスタをセットアップする場合、すべてのサーバーが同じデータベースを共有します。そのため、データベースでのテーブルの作成は 1 回行えば十分です。
Data Catalog を再起動して変更を適用します。
データベース構成のエラーが原因で Data Catalog が起動しない場合、データベース構成を手動でデフォルトに戻すことができます。ファイル
<DENODO_HOME>/conf/data-catalog/datasource.propertiesを編集して、その内容を以下に示すように (<DENODO_HOME>を Denodo インストール環境へのパスで置換) 変更します。datasource.url.defaultプロパティにデータベースへのパスが含まれているので、その内容をspring.datasource.urlプロパティにコピーできます。datasource.type=derby datasource.url.default=jdbc:derby:<DENODO_HOME>/metadata/data-catalog-database;create=true spring.datasource.driver-class-name=org.apache.derby.jdbc.EmbeddedDriver spring.datasource.url=jdbc:derby:<DENODO_HOME>/metadata/data-catalog-database;create=true spring.datasource.username= spring.datasource.password= datasource.password.encrypted=false
もう一度 Data Catalog を再起動して変更を適用します。
手順 3 でエクスポートしたメタデータを インポート します。
Data Catalog のクラスタを構築している場合、同じ Web セッションのすべてのリクエストをクラスタの同じノードにリダイレクトするように (つまり、スティッキーセッション) ロードバランサーを構成します。
権限の構成¶
[権限] タブでは、ロールに付与する 権限 を構成できます。権限は エレメント権限 、 管理 、 コラボレーション 、 ユーザー 、および リクエスト の 5 つのカテゴリに分類されます。カテゴリを選択してから、ロールに割り当てる権限をすべてチェックしてください。該当するロールを持つすべてのユーザーに対して、Data Catalog 上で、選択された権限を付与します。
ユーザーの権限を構成するダイアログ¶
Virtual DataPort からロールが削除されている場合、権限テーブルのロールが赤字で示されます。名前の横にある 
アイコンをクリックすると、Data Catalog からも削除されます。
注釈
[権限] ダイアログで権限を割り当てるには、ユーザーに次の権限が必要です。
Data Catalog での
PERMISSIONS権限。これは [権限] ダイアログへのアクセスに必要です。Virtual DataPort のデータベースに対する
ADMIN権限。これは、Virtual DataPort サーバーで利用可能なすべてのロールにアクセスするための最小要件です。
[ユーザー] タブには、[VQL Shell] 権限と [Assisted Query] 権限が表示されます。
[VQL Shell] 権限と [Assisted Query] 権限の両方を構成するダイアログ¶
ワークフローリクエスト には、権限を割り当てるための固有のカテゴリがあります。
注釈
[権限] ダイアログでリクエストの権限を割り当てるには、ユーザーに Data Catalog での Manage request 権限が必要です。
ワークフローの権限を構成するダイアログ¶
アシスト付きクエリの構成¶
[AI Integration] タブの [API Configuration] セクションで、 アシスト付きクエリ 機能を構成できます。
一般的な API 構成パラメータを以下に示します。
一般的な API 構成パラメータを示すダイアログ¶
Enable query generation: この機能を有効または無効にします。
警告
この機能を有効にすると、Data Catalog のユーザーは、Data Catalog を使用する際にメタデータ情報を OpenAI サービスまたは Azure OpenAI サービスに送信できます。組織がこのことを認識し、同意していることを確認してください。
この機能を有効にすると、外部 API へのリクエストに費用が発生します。このオプションを有効にする前に、組織がこの金銭的影響を完全に認識していることを確認してください。
Language options: このオプションを使用して、クエリの説明に多言語構成を使用できるようにします。
User locale: Data Catalog で構成されているユーザーロケールに対応する言語が使用されます。
Language: 言語リストで選択された言語が使用されます。
Browser language: Web ブラウザで構成されている言語が使用されます。
Execution mode: 生成が完了した後、生成されたクエリをユーザーが手動で実行する必要があるか、生成されたクエリが自動的に実行されるかを選択します。
注釈
自動実行モードを利用すると、アシスト付きクエリ生成プロセスの所要時間が長くなります。なぜなら、クエリ生成後にクエリが自動実行されるため、最終的に最終結果を提示するのが遅れるためです。実行する前にクエリの正しさを要件に基づいて確認するかどうかを評価する際は、このことを考慮することをお勧めします。そのような場合、手動モードを選択することを強くお勧めします。
API: Data Catalog が LLM サービスを利用するために外部 API 位置に対して使用する API。
OpenAI: 公式の公開 OpenAI API を構成できます。
Azure: 公式の公開 Azure OpenAI Service API を構成できます。
Custom: カスタム API を構成できます。
重要
Denodo からモデルに提供されるプロンプトの固定部分は 3,000 トークンを占めていますが、モデルの応答用として別途多くのトークンが予約されています。
使用されるモデルで、プロンプトの固定部分と応答の予約トークンだけでなく、相互に作用するビューのスキーマ (フィールド名とその型) に対しても十分な数のトークンをサポートしていることが極めて重要です。ビュースキーマの送信はシステムの機能上必須ですが、フィールドの説明、他のビューとのアソシエーション、値の例などの追加情報に対応するトークンの制限を設定することを強くお勧めします。
少なくとも 10,000 トークンに対応するモデルが推奨されます 。ただし、ビューのメタデータの長さ (説明文の長さなど) によっては、この制限では不十分な場合があります。必要な情報をすべて送信する際にトークンの数が不足している場合、Data Catalog ではトークン削減アルゴリズムを使用して自動的にトークンの数を減らし、ビュースキーマと必須機能の情報を優先します。
API¶
現在、API を構成する際、[OpenAI]、[Azure OpenAI Service]、または [Custom] の 3 つのオプションがあります。ここでは、これらのオプションについて説明します。
OpenAI API¶
ここでは、OpenAI API のパラメータについて説明します。
OpenAI API の構成パラメータを示すダイアログ¶
API key: OpenAI API キー。このパラメータは必須です。
Organization ID: 構成すると、API リクエストで使用する組織を指定するヘッダーが送信されます。複数の組織に属するユーザーの場合に便利です。このパラメータは必須ではありません。
Model: クエリを生成するために使用するモデル。ドロップダウンに表示される値は、Denodo によってテスト済みです。ただし、未テストの OpenAI モデルを試したい場合は、編集アイコンをクリックすると構成できます。
重要
組織の OpenAI アカウントによっては [Model] フィールドに表示されたモデルが動作せず、使おうとしてもアクセスできないことがあります。
未テストの OpenAI モデルを構成すると、機能が誤動作する可能性があります。
モデルのトークン数制限: 編集アイコンをクリックした場合、モデルのトークン数制限パラメータを構成できます。リストのデフォルトモデルを構成した場合、Data Catalog は公式モデルのトークン数制限値を使用します。カスタムモデルを選択してモデルのトークン数制限値を導入しない場合、モデルのトークン数制限のデフォルト値 16384 が割り当てられます。
参考
OpenAI API のパラメータの詳細については、OpenAI API リファレンス Web サイトを参照してください。
Azure OpenAI Service API¶
ここでは、Azure OpenAI Service API のパラメータを列挙し、それらについて説明します。
Azure OpenAI Service API の構成パラメータを示すダイアログ¶
Azure resource name: Azure リソースの名前。
Azure deployment name: モデルをデプロイする際に選択したデプロイ名。
API version: この操作に使用する API バージョン。これは、YYYY-MM-DD 形式に従います。
API key: API キー。
モデルのトークン数制限: デプロイしたモデルで許可されている最大トークン数。モデルのトークン数制限値を導入しない場合、モデルのトークン数制限のデフォルト値 16384 が割り当てられます。
参考
Azure OpenAI Service API のパラメータの詳細については、 Azure OpenAI Service REST API リファレンス を参照してください。
Custom API¶
Denodo Platform は、OpenAI と Azure OpenAI Service の両方によって提供される公式 API に統合できるほか、カスタム API オプションを使用することでカスタム API とも統合できます。その結果、この機能によってカスタムモデルのサポートが導入され、公式モデルによるデフォルト API 以外の API も選択できるようになります。ただし、アシスト付きクエリ機能には固有の要件があることから、すべての API に Data Catalog との互換性があるとは限りません。この固有の要件は、カスタム API が OpenAI チャット補完 API アプローチと Azure OpenAI Service チャット補完 API アプローチのどちらに従っているかに応じて異なります。このアプローチに応じて、[Custom compatibility mode] パラメータを適切に設定する必要があります。このパラメータについて以下で詳しく説明します。
Custom compatibility mode¶
[Custom compatibility mode] パラメータを使用すると、 OpenAI チャット補完 API アプローチまたは Azure OpenAI Service チャット補完 API アプローチに従ったカスタム API に応じて、Data Catalog がリクエストを送信および処理できるようになります。
OpenAI チャット補完 API アプローチ: カスタム API が公式の OpenAI チャット補完 API を実装している場合、カスタム API はこのアプローチに従っていると定義します (
https://platform.openai.com/docs/guides/text-generation/chat-completions-apiを参照)。この場合、[Custom compatibility mode] パラメータを [OpenAI] に設定する必要があります。カスタム API と Data Catalog の互換性のために、OpenAI チャット補完 API のすべてのパラメータが必要なわけではありません。リクエストの本文: Data Catalog は、リクエスト本文で model、messages、および temperature の各パラメータを指定してリクエストを行います。
応答の本文: Data Catalog は、応答の本文に id、object、created、choices、および usage の各パラメータを必要とします。
Azure OpenAI Service チャット補完 API: カスタム API が公式の Azure OpenAI Service チャット補完 API を実装している場合、カスタム API はこのアプローチに従っていると定義します (
https://learn.microsoft.com/en-us/azure/ai-services/openai/reference#chat-completionsを参照)。この場合、[Custom compatibility mode] パラメータを [Azure OpenAI Service] に設定する必要があります。カスタム API と Data Catalog の互換性のために、Azure OpenAI Service チャット補完 API のすべてのパラメータが必要なわけではありません。リクエストの本文: Data Catalog は、リクエスト本文で messages および temperature の各パラメータを指定してリクエストを行います。
応答の本文: Data Catalog は、応答の本文に id、object、created、choices、および usage の各パラメータを必要とします。
次に、それぞれのカスタム互換性モードのパラメータについて説明します。
OpenAI¶
カスタム OpenAI API の構成パラメータを示すダイアログ¶
Authentication: カスタム API が認証を必要とするかどうかに応じて、このオプションを構成します。
API key: API キー。認証が有効な場合、このパラメータが必要です。
Organization ID: 構成すると、API リクエストで使用する組織を指定するヘッダーが送信されます。複数の組織に属するユーザーの場合に便利です。認証が有効な場合のみ使用できます。このパラメータは必須ではありません。
Custom API URI: カスタム API の URI。このパラメータは必須です。
Model: クエリを生成するために使用するモデル。このパラメータは必須です。
Model token limit: カスタムモデルで許可されている最大トークン数。このパラメータは必須です。
HTTP プロキシの構成¶
このセクションでは、HTTP プロキシ構成を指定できます。
プロキシ構成パラメータを示すダイアログ¶
Enable proxy: このトグルは、 アシスト付きクエリ 機能のプロシキ経由のコネクションを有効にします。これが有効な場合、リクエストはプロキシに送信されます。
Host: プロキシのホスト名 (IP または DNS 名)。プロキシを使用するには、このパラメータが必須です。
Port: ポート番号。プロキシを使用するには、このパラメータが必須です。
Proxy name: ユーザー名。
Proxy password: パスワード。
重要
プロキシを構成した後、Data Catalog を再起動する必要があります。