2.16 - Teradata QueryGridのコンポーネント - Teradata QueryGrid

Teradata® QueryGrid™ インストールとユーザー ガイド

Product
Teradata QueryGrid
Release Number
2.16
Release Date
2021年6月
Content Type
インストール
ユーザー ガイド
構成
管理
Publication ID
B035-5991-061K-JPN
Language
日本語 (日本)

Teradata QueryGridには、以下のコンポーネントが含まれます。

コンポーネント 説明
Teradata QueryGridマネージャ Teradata QueryGridの定義、管理、および監視を可能にする専用の物理マシン(TMSまたはサーバー)またはVMにインストールされたソフトウェア。

Teradata QueryGridマネージャをインストールしたら、Viewpointでそれを構成し、次にQueryGridポートレットを使用して残りのTeradata QueryGridコンポーネントをインストールして構成します。

データセンター データ ソース(システム)およびTeradata QueryGridマネージャインスタンスの物理的な場所またはリージョンを表わす論理名。利用可能な場合は、データ ソース ノードは、同じデータ センターを共有するQueryGridマネージャと通信します。
データ ソース Teradataシステム ノード、Hadoopクラスタ内のノード、またはPrestoクラスタ内のノードなど、同じソフトウェア プラットフォームを共有する1つ以上のデータ ソース ノードを含むシステム。
ブリッジ データ ソース ノードまたは非データ ソース ノードのサブセットを含むシステム。直接ネットワーク接続を持たないデータ ソース システム間の接続を可能にするために使用します。
ファブリック 同じポートでリスニングし、互換性のあるTeradata QueryGrid tdqg-fabricソフトウェア バージョンを実行している、複数システムにまたがる1つ以上のデータ ソース ノード。

Teradataコネクタに関係するリンクのみがサポートされています。例えば、イニシエータまたはターゲット コネクタがTeradataコネクタではないリンク(Hive-Oracle間など)はサポートされていません。

コネクタ データ型のマッピング、変換、および同じTeradata QueryGridファブリック内の他のコネクタとの通信を可能にするデータ ソース用のアダプタ ソフトウェア。
開始コネクタは、クエリーを開始するために対話するコネクタであり、ターゲットコネクタは、クエリー開始後にクエリー処理の大半を実行するためにリモート側でトリガーされるコネクタです。以下のコネクタがサポートされています。
  • Teradata
  • Hive
  • Spark SQLコネクタ
  • Oracle(ターゲット コネクタとしてのみ)
  • Presto
リンク 相互に通信できるコネクタを指定し、データ転送のルールを定義する名前付き構成。

QueryGridネットワーク図

Teradata QueryGridマネージャ

Teradata QueryGridマネージャを使用して、Teradata QueryGridで以下の機能を実行します。
  • Teradata QueryGridの管理と監視
  • Teradata QueryGridのインストール、構成、およびアップグレード
  • リンク、コネクタ、または帯域幅の診断チェックの開始
  • クエリー パフォーマンス測定基準の要約
  • Teradata QueryGridへのセキュアなアクセスに必要なキーの管理
  • Teradata QueryGridコンポーネントから生成されたログの取得
必要なTeradata QueryGridマネージャインスタンスの数は、次の条件によって異なります。
  • QueryGridマネージャのハードウェア仕様
  • ファブリック内のデータ ソース ノードの数
  • QueryGridクエリーの量
  • 高可用性(少なくとも2つのQueryGridマネージャ インスタンスが必要、QueryGridマネージャのサイジングを参照してください)
すべてのQueryGridマネージャがオフラインの場合、以下の機能を実行できません:
  • QueryGridクエリーを監視する
  • 問題状況のアラートの受信
  • 構成に変更を加える
  • 失敗したクエリーのサポート バンドルを作成する
  • 診断チェックを実行する
すべてのQueryGridマネージャがオフラインの場合、クエリー パス内のいずれかのQueryGridファブリック サービスが再起動されない限り、QueryGridクエリーは引き続き実行可能です。

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 Advanced SQL Engine Teradata
Hadoop Hive、Spark SQL、Presto
スタンドアロンPresto Presto
Oracleドライバ ノード Oracle

Teradata QueryGrid構成時に、ノードおよびファブリック ソフトウェアはシステム内のすべてのノードにインストールされます。ただし、ソフトウェアがOracleドライバ ノードのみにインストールされるOracleを除きます。ノード ソフトウェアは、ノード上のファブリックとコネクタを管理します。

ブリッジ

開始システムとターゲット システム間に直接的なネットワーク接続がない場合に、ブリッジ システムが必要になります。ブリッジ システムをリンク上に構成する場合、開始システムとターゲット システム間で転送されるすべてのデータは、ブリッジ システムのノードを経由します。イニシエータ システムとターゲット システムのデータ ソース ノード間のリンクに、ゼロ、1つ、または2つのブリッジ システムを追加できます。ブリッジ システムのノードは、次のいずれかを含みます。
  • QueryGridノード ソフトウェアを実行しているデータ ソース ノードのサブセット。データ ソース ノードは、イニシエータ システム、ターゲット システム、またはその両方に指定できます。
  • QueryGridノード ソフトウェアを実行している非データ ソース ノードのセット。非データ ソース ノードには、処理するローカル データがないため、コネクタ ソフトウェアは必要ありません。非データ ソース ノードの例としては、Hadoopシステムのエッジ ノードがあります。

リンクに追加されたブリッジ システムごとに、そのホップ用に転送されるデータに使用する開始側ネットワーク、ターゲット側ネットワーク、通信ポリシーを指定する、新しいホップ設定が必要です。ホップとは、2つの直接接続されたデータ ソース システムまたはブリッジ システム間でのデータ転送です。ホップ数は、ブリッジの数に基づきます。

ブリッジの数 定義されたホップ数
ブリッジなし 1つのホップ(イニシエータとターゲット間のホップ)
1つのブリッジ 2つのホップ(イニシエータとブリッジ間のホップおよびブリッジとターゲット間のホップ)
2つのブリッジ 3つのホップ(イニシエータと最初のブリッジ間のホップ、最初のブリッジと2番目のブリッジ間のホップおよび2番目のブリッジとターゲット間のホップ)

ソース システムとターゲット システム間のホップおよびブリッジの例。

ファブリック

ファブリックを使用して、Teradata QueryGridで以下の処理を実行します。
  • TeradataとTeradataなどの同じタイプ、またはTeradataとPrestoなどの異なるタイプのペアのデータ ソース ノード間の通信を可能にする
  • ユーザーがファブリック内の2つ以上のデータ ソースからデータを結合する単一のSQLクエリーを開始できるようにする

ファブリック内のデータ ソース ノード間で転送されるデータのサイズに制限はありません。

データ ソース ノードにファブリック ソフトウェアをインストールして、以下を実行します。
  • Teradata QueryGridコネクタに以下の処理を許可します。
    • 互いに並行して通信する
    • データを効率的に実行、処理、および転送する
  • クエリーごとのファブリック使用率を監視し、Teradata QueryGridマネージャに測定基準をレポートする

コネクタとリンクは、ファブリックに関連付けられています。

コネクタ

コネクタは、クエリーのイニシエータまたはターゲットの両方として機能します。コネクタを使用して、Teradata QueryGridで以下の処理を実行します。
  • データ ソース(システム)間のクエリー処理を提供する。
  • クエリー リクエストSQLを1つのソース クエリー形式から別のソース クエリー形式に変換する。
  • データの変換。データを別のデータ型または形式に変換して、異なるデータ ソース システム間で交換できるようにする。
  • データ ソースがクエリーに参加することを許可する。ファブリックを結合するコネクタならどれでも、クエリーに参加できる。
  • データ ソースがクエリーを開始することを許可する。
    • Oracleコネクタを除く。
  • ファブリックとの間でのデータの送受信を可能にする。
  • ファブリック内の他のコネクタと通信する。
  • ターゲット システムでのクエリー実行の制御。すべてのコネクタがクエリーのターゲットとして機能でき、イニシエータ データ ソース システムに代わってターゲット データ ソース システムで実行するクエリーの制御を可能にする。
  • クエリー結果を開始システムに返す。

コネクタは、システムの種類(例: Teradataシステム、Hive、またはPrestoで構成されたHadoop)に固有です。例えば、TeradataシステムはTeradataコネクタをホストしますが、単一のHadoopシステムは複数のコネクタ(例: Hive、Spark、Presto)をホストすることができます。

オプションのコネクタ プロパティを使用すると、コネクタの種類の構成を調整したり、構成時に設定されたコネクタ プロパティを上書きしたりできます。

コネクタ ソフトウェアは、データ ソースをTeradata QueryGridファブリックに接続します。このソフトウェアは、システム内のすべてのデータ ソース ノードにインストールされます。ファブリック ソフトウェアも、システム内のすべてのデータ ソース ノードにインストールされます。ファブリック ソフトウェアにはドライバが含まれます。ドライバは、ドライバ ノードと呼ばれる1つ以上のデータ ソース ノードで実行されます。クエリー処理の一環として、ドライバ ノードはイニシエータ コネクタからリクエストを受け取り、そのリクエストをターゲット システムに送信します。ドライバはコネクタを読み込み、メッセージを読み取り、メソッドを呼び出して、リクエストの処理と応答の送信を行ないます。

コネクタを構成する場合は、以下を実行します。
  • データ ソース内のドライバ ノードに該当するノードを指定します。

    大規模なシステムでは、ドライバ ノードにするのは一部のノードのみで十分です。

  • 冗長性を確保し、クエリーの開始に必要なワークロードを共有するため、複数のドライバ ノードを選択します。
  • セッションの再利用性を高めるため、ドライバ ノードの数を制限します。
ターゲット ドライバ ノードがクエリーを送信すると、接続キャッシュは次を実行する接続プールを形成します。
  • 物理接続を再利用
  • QueryGridクエリーのオーバーヘッドを削減
  • セッションの作成と終了を最小化

接続プールは、単一クエリーのすべてのフェーズ、または同じセッションおよびユーザー信頼証明を持つ後続のクエリーに対して、同じJDBC接続を使用します。調整可能なコネクタ プールのプロパティの構成の詳細については、関連するコネクタのコネクタとリンクのプロパティ情報を参照してください。

リンク

リンクは、イニシエータ コネクタとターゲット コネクタのペアを定義する名前付き構成です。
コネクタのタイプ 説明
開始 QueryGridクエリーの起点となるポイント。例えば、Teradata-Presto間クエリーでは、Teradataコネクタがクエリーを開始します。
ターゲット QueryGridクエリーの宛先ポイント。例えば、Teradata-Presto間クエリーでは、Prestoコネクタがデータのインポートまたはエクスポートのいずれかにコネクタ アクセスを開始するターゲット コネクタです。
開始とターゲット リンクの組み合わせは、定義したコネクタの種類に対してのみ作成できます。
定義されたコネクタ 結果
Teradataシステムのみ Teradataシステム間でのみリンクを作成できます。
Teradata、Presto、Hive、Spark、Oracle これらのコネクタ タイプをともなうTeradataシステム間でリンクを作成できます。

リンクは、QueryGridクエリーの実行に備えて、外部サーバー定義の構成を簡略化します。

Teradata QueryGridファブリックでは、以下を使用して各リンクを指定します。
  • クエリーに使用する開始コネクタとターゲット コネクタのリンクの組み合わせ
  • 使用するブリッジの数(ある場合):
    ブリッジの数 定義されたホップ数
    ブリッジなし 1つのホップ(イニシエータとターゲット間のホップ)
    1つのブリッジ 2つのホップ(イニシエータとブリッジ間のホップおよびブリッジとターゲット間のホップ)
    2つのブリッジ 3つのホップ(イニシエータと最初のブリッジ間のホップ、最初のブリッジと2番目のブリッジ間のホップおよび2番目のブリッジとターゲット間のホップ)
  • 開始コネクタのとターゲット コネクタのプロパティ
    リンクおよび関連付けられるプロパティの作成時に、名前と値のペア(NVP)の構成を作成します。NVPでは次を実行します。
    • ターゲット コネクタ コンポーネントの動作の指定
    • データの変換方法の構成
    • 基本となるリンク データの転送レイヤーの構成
    • イニシエータ コネクタの実行方法の決定

    オプションのプロパティを使用すると、開始コネクタまたはターゲット コネクタの構成を精緻化することができます。 これらのリンク プロパティはコネクタ プロパティを上書きします。

  • ホップの開始ネットワークおよびターゲット ネットワークを定義する
    • Linksはネットワークを参照し、データ転送にどのインターフェースを使用するかを決定します。クエリーは特定のサーバーまたはネットワークで発生し、ターゲット サーバーまたはネットワークに送信されます。ネットワークが指定されない場合、ファブリックは既知のターゲット ノード ネットワーク アドレスをすべて並行して試し、接続の確立に成功した最初のアドレスを使用します。
    • Networksは、インターフェース名またはクラスレス ドメイン間ルーティング(CIDR)表記法のいずれかによって物理ネットワーク インターフェースを論理ネットワークの定義にマップするルールによって定義されます。各ルールは、それらがルール一致リストに表示される順序でチェックされます。
  • ターゲット コネクタと開始コネクタとブリッジ(使用されている場合)の間でデータを転送するためのルールを定義する通信ポリシー

    通信ポリシーは、システム同士が相互にどのように通信するかを定義します。ポリシーにより転送の同時実行数を構成したり、データ転送中に行データ ブロックのZStandardデータ圧縮を有効または無効にしたりできます。

    Teradata QueryGridは、圧縮が有効(Compression)の通信ポリシーと、圧縮が有効でない(No Compression)の通信ポリシーで事前に構成されています。

    通信ポリシーは関連するシステムに必ずしも固有ではないので、再利用できます。

  • ユーザー マッピング(オプション)

    ユーザー マッピングにより、開始システムにログオンしているユーザーがターゲット システム上の特定ユーザーとしてクエリーを実行できます。該当する場合には、開始システム上の複数のユーザーをターゲット システム上の単独ユーザーにマッピングできますが、ターゲット システム上の複数のユーザーを開始システム上の単独ユーザーにマッピングすることはできません。

    QueryGridポートレットで、一方のデータ ソースのユーザー名を他方のデータ ソースのユーザー名にマッピングできます。

    Hive、Presto、またはSparkターゲット コネクタをセキュリティなしで使用する場合は、通常、ユーザー マッピングが必要です。例えば、ユーザーJoeが、Teradata-Hive間のリンクを使用してクエリーを開始した場合、Teradataは自動的にユーザー名をすべて大文字に変更し、デフォルトでユーザー「JOE」としてターゲット システムにクエリーを送信します。Hiveターゲット コネクタでセキュリティが使用されていない場合、このユースケースでは次のような結果が得られます。
    シナリオ 要件
    ユーザー「JOE」がターゲット システム上に存在しない 「Hive」などのターゲット システム上で既存のユーザーを使用してクエリーを実行する必要があります。このシナリオでは、Teradataシステム上の「JOE」がターゲットの「Hive」システムでユーザーHiveにマップされている場合にユーザー マッピングが必要です。
    ターゲット システムにjoeとして存在する Teradataシステムの「JOE」がターゲットHiveシステムの「joe」にマップされている場合は、ユーザー マッピングが必要です。
    ターゲットに「JOE」として存在する このシナリオでは、ユーザー マッピングは必要ありません。

    Kerberosなどのセキュリティ プラットフォームを使用する場合は、Hive、Presto、またはSparkターゲット コネクタを使用するときにユーザー マッピングは必要ありません。

  • 確認応答(acknowledgment)を有効または無効にします。確認応答により、QueryGridは一時的なネットワーク エラーのために切断された接続を再度確立できます。ネットワーク エラーが原因でクエリーが失敗する場合、このオプションを有効にできますが、その代わりメッセージのオーバーヘッドが多少増えます。