Teradata QueryGridには、以下のコンポーネントが含まれています。
| コンポーネント | 説明 |
|---|---|
| Teradata QueryGridマネージャ | Teradata QueryGridの定義、管理、および監視を可能にする専用の物理マシン(TMSまたはサーバー)またはVMにインストールされたソフトウェア。 Teradata QueryGridマネージャをインストール後、Viewpoint上で構成します。次に、QueryGridポートレットを使用して残りのTeradata QueryGridコンポーネントをインストールし、構成します。 |
| データセンター | Teradata QueryGridのデータ ソース(システム)の物理的な場所を表わす論理名。 |
| データ ソース | Teradata Databaseノード、Hadoopクラスタ内のノード、またはPrestoクラスタ内のノードなど、同じソフトウェア プラットフォームを共有する1つ以上のデータ ソース ノードを含むシステム。 |
| ブリッジ | 圧縮や暗号化などのCPUを集中的に使用する操作を実行し、データを転送するために使用されるデータ ソース ノードまたは非データ ソース ノードのサブセットを含むシステム。 |
| ファブリック | 同じポート経由で互換性のあるバージョンのTeradata QueryGridソフトウェアを実行する、異なるシステム内の1つ以上のデータ ソース ノード。 Teradataコネクタに関係するリンクのみがサポートされています。例えば、イニシエータまたはターゲット コネクタがTeradataコネクタではないリンク(Hive-Oracle間など)はサポートされていません。 |
| コネクタ | データ型のマッピング、変換、および同じTeradata QueryGridファブリック内の他のコネクタとの通信を可能にするデータ ソース用のアダプタ ソフトウェア。 開始コネクタはクエリーを開始するコネクタで、ターゲットコネクタはクエリーを受信するコネクタです。次のコネクタがサポートされています。
|
| リンク | 相互に通信できるコネクタを指定し、データ転送のルールを定義する名前付き構成。 |
Teradata QueryGridマネージャ
- Teradata QueryGridの管理と監視
- Teradata QueryGridのインストール、構成、およびアップグレードの許可
- リンク、コネクタ、または帯域幅の診断チェックの開始。
- クエリー パフォーマンス測定基準の要約
- Teradata QueryGridへのセキュリティで保護されたアクセスのためのキーの管理
- Teradata QueryGridコンポーネントから生成されたログの取得
- QueryGridマネージャのハードウェア仕様
- ファブリック内のデータ ソース ノードの数
- QueryGridクエリーの量
- QueryGridクエリーの監視
- 問題の状態に対する警告を受ける
- 構成の変更を行う
- 失敗したクエリーのキャプチャ サポート バンドルを作成する
- 診断チェックを実行する
QueryGridマネージャ クラスタ
複数のTeradata QueryGridマネージャ インスタンスがインストールされている場合は、高可用性とスケーラビリティを実現するために、Teradata QueryGridマネージャ インスタンスをクラスタ化します。複数のTeradata QueryGridマネージャ インスタンスがインストールされている場合は、高可用性とスケーラビリティを実現するために、Teradata QueryGridマネージャ インスタンスをクラスタ化する必要があります。クラスタリングによって、すべてのTeradata QueryGridマネージャ インスタンスが同じ構成になるため、それぞれがTeradata QueryGridを管理および監視することができます。複数のQueryGridマネージャ クラスタを作成し、個別の実働環境およびテスト環境を維持できます。
クラスタが存在する場合、QueryGridマネージャ インスタンスのフェールオーバーおよび回復は自動的に行なわれます。1つのインスタンスがオフラインになると、クラスタ内の他のインスタンスが失敗したインスタンスのワークロードを引き継ぎます。失敗したQueryGridマネージャがオンラインに戻ると、オフライン中に作成された新しい構成が自動的に回復され、失敗する前と同じようにワークロードを再開します。
データセンター
データ センターは、QueryGrid接続済みシステムが存在する場所または領域です。QueryGridマネージャおよびQueryGrid接続済みシステムをデータ センターに関連付けることで、QueryGridにより、ノードとQueryGridマネージャ間のトラフィックを、データ センターまたは領域に対してローカルのままに保つことができます。
物理マシンにTeradata QueryGridマネージャ ソフトウェアをインストールすると、TMS、VM、またはサーバーのホスト名を使用してデフォルトのデータ センターが作成されます。デフォルトのデータ センター名がQueryGridポートレットに表示されます。
- QueryGridポートレットに新しいデータ センターを作成する
- 2つ以上のTeradata QueryGridマネージャ インスタンスがある場合は、クラスタリング時に新しいデータ センターを作成する
データ ソース
Teradata QueryGridの構成中に、Teradata QueryGridが監視対象システムとして追加されます。
- Teradata Database
- hive
- Spark SQL
- Oracle
- Presto
Teradata QueryGrid構成時に、ノードおよびファブリック ソフトウェアはシステム内のすべてのノードにインストールされます。ノード ソフトウェアは、ノード上のファブリックとコネクタを管理します。
ブリッジ
- 同じネットワーク上にないイニシエータとターゲットのデータ ソース ノード間の通信を可能にするブリッジ内のノードを通過するネットワーク トラフィック
- データ ソース システム内のすべてのノードを使用する代わりに、データの暗号化や圧縮などのCPUを集中的に使用する操作をブリッジ システムのノードにオフロードする
- QueryGridノード ソフトウェアを実行しているデータ ソース ノードのサブセット。データ ソース ノードは、イニシエータ システム、ターゲット システム、またはその両方に指定できます。
- QueryGridノード ソフトウェアを実行している非データ ソース ノードのセット。非データ ソース ノードには、処理するローカル データがないため、コネクタ ソフトウェアは必要ありません。非データ ソース ノードの例としては、Hadoopシステムのエッジ ノードがあります。
リンクは、データ転送パスを定義します。1つまたは2つのブリッジをデータ転送パスに含めることができます。リンクには、1つ以上のホップを含めることができます。ホップは、データ転送パスの接続ポイント間でのデータ移動に使用するネットワーク/通信ポリシーを定義します。ホップの数はブリッジの数に基づきます。
| ブリッジの数 | ホップの数 |
|---|---|
| ブリッジなし | 1つのホップ |
| 1つのブリッジ | 2つのホップ |
| 2つのブリッジ | 3つのホップ |
ファブリック
ファブリックは、Teradata QueryGridで以下の機能を実行します。
- Teradata DatabaseとTeradata Databaseなどの同じタイプ、またはTeradata DatabaseとPrestoなどの異なるタイプのペアのデータ ソース ノード間の通信を可能にする
- ユーザーがファブリック内の2つ以上のデータ ソースからデータを結合する単一のSQLクエリーを開始できるようにする
ファブリック内のデータ ソース ノード間で転送されるデータのサイズに制限はありません。
- Teradata QueryGridコネクタで次のことを可能にする
- 互いに並行して通信する
- データを効率的に実行、処理、および転送する
- クエリーごとのファブリック使用率を監視し、Teradata QueryGridマネージャに測定基準をレポートする
コネクタとリンクは、ファブリックに関連付けられています。
コネクタ
- データ ソース(システム)間のクエリー処理を提供する
- クエリー リクエストSQLを1つのソース クエリー形式から別のソース クエリー形式に変換する
- データの変換。データを別のデータ型または形式に変換して、異なるデータ ソース システム間で交換できるようにする。
- データ ソースがクエリーに参加することを許可する。 ファブリックを結合するコネクタならどれでも、クエリーに参加できる。
- データ ソースがクエリーを開始することを許可する。
- ファブリックとの間でのデータの送受信を可能にする
- ファブリック内の他のコネクタと通信する
- ターゲット システムでのクエリー実行の制御。すべてのコネクタがクエリーのターゲットとして機能でき、イニシエータ データ ソース システムに代わってターゲット データ ソース システムで実行されるクエリーの制御を可能にする。
- クエリー結果を開始システムに返す
コネクタは、システムの種類(Teradata Database、Hive、またはPrestoで構成されたHadoop)に固有であり、システムの種類ごとに1つのコネクタしか存在できません。例えば、TeradataシステムはTeradataコネクタをホストしますが、単一のHadoopシステムは複数のコネクタ(HiveとPresto)をホストすることができます。
オプションのコネクタ プロパティを使用すると、コネクタの種類の構成を調整したり、構成時に設定されたコネクタ プロパティを上書きしたりできます。
コネクタ ソフトウェアは、データ ソースをTeradata QueryGridファブリックに接続します。このソフトウェアは、システム内のすべてのデータ ソース ノードにインストールされます。ファブリック ソフトウェアも、システム内のすべてのデータ ソース ノードにインストールされます。ファブリック ソフトウェアにはドライバが含まれます。ドライバは、ドライバ ノードと呼ばれる1つ以上のデータ ソース ノードで実行されます。クエリー処理の一環として、ドライバ ノードはイニシエータ コネクタからリクエストを受け取り、そのリクエストをターゲット システムに送信します。 ドライバはコネクタを読み込み、メッセージを読み取り、メソッドを呼び出して、リクエストの処理と応答の送信を行ないます。
コネクタを構成する場合、データ ソース内のどのノードがドライバ ノードであるかを指定する必要があります。大規模なシステム上のノードのサブセットのみをドライバ ノードにする必要があります。 複数のドライバ ノードを使用して冗長性を確保し、クエリーの開始に必要なワークロードを共有します。
- 物理接続を再利用
- QueryGridクエリーのオーバーヘッドを削減
- セッションの作成と終了を最小化
接続プールは、単一クエリーのすべてのフェーズ、または同じセッションおよびユーザー信頼証明を持つ後続のクエリーに対して、同じJDBC接続を使用します。調整可能なコネクタプールのプロパティの構成の詳細については、関連するコネクタのトピックのコネクタとリンクプロパティの情報を参照してください。
リンク
| コネクタのタイプ | 説明 |
|---|---|
| 開始 | QueryGridクエリーの起点となるポイント。例えば、Teradata-Presto間クエリーでは、Teradataコネクタがクエリーを開始します。 |
| ターゲット | QueryGridクエリーの宛先ポイント。例えば、Teradata-Presto間クエリーでは、Prestoコネクタがデータのインポートまたはエクスポートのいずれかにコネクタ アクセスを開始するターゲット コネクタです。 |
| 定義されたコネクタ | 結果 |
|---|---|
| Teradata Databaseのみ | Teradataシステム間でのみリンクを作成できます。 |
| TeradataとPresto | TeradataシステムとPrestoシステム間でリンクを作成できます。 |
| Teradata、Presto、Hive、Oracle | これらのコネクタ タイプをともなうTeradataシステム間でリンクを作成できます。 |
リンクは、QueryGridクエリーの実行に備えて、外部サーバー定義の構成を簡略化します。
- クエリーに使用する開始コネクタとターゲット コネクタのリンクの組み合わせを指定する
- ブリッジを使用するかどうかを指定する:
ブリッジの数 定義されたホップ数 ブリッジなし 1つのホップ(イニシエータとターゲット間のホップ) 1つのブリッジ 2つのホップ(イニシエータとブリッジ間のホップおよびブリッジとターゲット間のホップ) 2つのブリッジ 3つのホップ(イニシエータと最初のブリッジ間のホップ、最初のブリッジと2番目のブリッジ間のホップおよび2番目のブリッジとターゲット間のホップ) - 開始コネクタおよびターゲット コネクタのプロパティを定義するリンクおよび関連付けられるプロパティの作成時に、名前と値のペア(NVP)の構成を作成します。NVPでは次を実行します。
- ターゲット コネクタ コンポーネントの動作の指定
- データの変換方法の構成
- 基本となるリンク データの転送レイヤーの構成
- イニシエータ コネクタの実行方法の決定
オプションのプロパティを使用すると、開始コネクタまたはターゲット コネクタの構成を精緻化することができます。 これらのリンク プロパティはコネクタ プロパティを上書きします。
- ホップの開始ネットワークおよびターゲット ネットワークを定義する
- Linksはネットワークを参照し、データ転送にどのインターフェースを使用するかを決定します。クエリーは特定のサーバーまたはネットワークで発生し、ターゲット サーバーまたはネットワークに送信されます。 ネットワークが指定されない場合は、リンクはいずれかの稼働ルートを使用します。
- Networksは、インターフェース名またはCIDR表記法のいずれかによって物理ネットワーク インターフェースを論理ネットワークの定義にマップするルールによって定義されます。各ルールは、それらがルール一致リストに表示される順序でチェックされます。
- ターゲット コネクタと開始コネクタとブリッジ(使用されている場合)の間でデータを転送するためのルールを定義する通信ポリシーを指定する
通信ポリシーは、システム同士が相互にどのように通信するかを定義し、ポリシーにより転送の同時実行数とセキュリティのオプションを構成したり、データ転送中に行データ ブロックのZStandardデータ圧縮を有効または無効にしたりできます。
Teradata QueryGridでは、LAN経由での使用に適したポリシー(LANポリシー)とWANでの使用に適したポリシー(WANポリシー)があらかじめ構成されています。
通信ポリシーは関連するシステムに必ずしも固有ではないので、再利用できます。
- ユーザー マッピングの指定(オプション)
ユーザー マッピングにより、開始システムにログオンしているユーザーがターゲット システム上の特定ユーザーとしてクエリーを実行できます。該当する場合には、開始システム上の複数のユーザーをターゲット システム上の単独ユーザーにマッピングできますが、ターゲット システム上の複数のユーザーを開始システム上の単独ユーザーにマッピングすることはできません。
QueryGridポートレットで、一方のデータ ソースのユーザー名を他方のデータ ソースのユーザー名にマッピングできます。
Hive、Presto、またはSparkターゲット コネクタをセキュリティなしで使用する場合は、通常、ユーザー マッピングが必要です。例えば、ユーザーJoeが、Teradata - Hadoop間のリンクを使用してクエリーを開始した場合、Teradataは自動的にユーザー名をすべて大文字に変更し、デフォルトでユーザーJOEとしてターゲット システムにクエリーを送信します。Hiveターゲット コネクタでセキュリティが使用されていない場合、このユースケースでは次のような結果が得られます。シナリオ 要件 ユーザーJOEがターゲット システム上に存在しない Hiveなどのターゲット システム上で既存のユーザーを使用してクエリーを実行する必要があります。このシナリオでは、Teradataシステム上のJOEがターゲットのHiveシステムでユーザーHiveにマップされている場合にユーザー マッピングが必要です。 ターゲット システムにjoeとして存在する TeradataシステムのJOEがターゲットHiveシステムのjoeにマップされている場合は、ユーザー マッピングが必要です。 ターゲットにJOEとして存在する このシナリオでは、ユーザー マッピングは必要ありません。 Kerberosなどのセキュリティ プラットフォームを使用する場合は、Hive、Presto、またはSparkターゲット コネクタを使用するときにユーザー マッピングは必要ありません。