次の方法で共有


シャード化された SQL コネクタ

大事な

AKS 上の Azure HDInsight は、2025 年 1 月 31 日に廃止されました。 の詳細についてはこのお知らせで詳しく知ることができます。

ワークロードの突然の終了を回避するには、ワークロードを Microsoft Fabric または同等の Azure 製品 に移行する必要があります。

大事な

この機能は現在プレビュー段階です。 Microsoft Azure プレビューの 追加使用条件 には、ベータ版、プレビュー版、または一般公開されていない Azure 機能に適用される、より多くの法的条件が含まれています。 この特定のプレビューの詳細については、AKS プレビュー情報 Azure HDInsightを参照してください。 ご質問や機能提案がある場合は、詳細を記載して AskHDInsight にリクエストを送信してください。また、Azure HDInsight Communityをフォローして、さらなる更新情報を入手してください。

シャード化された SQL コネクタを使用すると、任意の数の SQL サーバーに分散されたデータに対してクエリを実行できます。

前提 条件

シャード化された SQL サーバーに接続するには、次のものが必要です。

  • SQL Server 2012 以降、または Azure SQL Database。
  • Trino コーディネーターとワーカーから SQL Server へのネットワーク アクセス。 ポート 1433 が既定のポートです。

一般的な構成

コネクタは、1 つのデータ ソースとして複数の SQL サーバーに対してクエリを実行できます。 カタログ プロパティ ファイルを作成し、connector.name=sharded-sql を使用してシャード化された SQL コネクタを使用します。

構成例:

connector.name=sharded_sqlserver
connection-user=<user-name>
connection-password=<user-password>
sharded-cluster=true
shard-config-location=<path-to-sharding-schema>
財産 説明
コネクタ名 シャード化された SQL のためのコネクタの名前は sharded_sqlserver である必要があります。
接続ユーザー SQL Server のユーザー名
接続パスワード SQL Server のユーザーのパスワード
シャード化クラスター sharded-sql コネクタの TRUE に設定する必要がある
シャード構成の場所 シャーディング スキーマを定義する構成の場所

データ ソース認証

コネクタは、ユーザー パスワード認証を使用して SQL サーバーにクエリを実行します。 構成で指定したのと同じユーザーが、すべての SQL サーバーに対して認証を行う必要があります。

スキーマ定義

コネクタは、SQL サーバー間の物理データの 2D パーティション/バケットレイアウトを前提としています。 スキーマ定義では、このレイアウトについて説明します。 現時点では、ファイル ベースのシャーディング スキーマ定義のみがサポートされています。

シャーディング スキーマ json の場所は、shard-config-location=etc/shard-schema.jsonなどのカタログ プロパティで指定できます。 必要なプロパティを使用してシャーディング スキーマ json を構成し、レイアウトを指定します。

次の JSON ファイルでは、Trino シャード化された SQL コネクタの構成について説明します。 その構造の内訳を次に示します。

  • テーブル: データベース内のテーブルを表すオブジェクトの配列。 各テーブル オブジェクトには次のものが含まれます。

    • スキーマ: SQL Server のデータベースに対応するテーブルのスキーマ名。
    • 名前: テーブルの名前。
    • sharding_schema: テーブルに関連付けられているシャーディング スキーマの名前。これは、次の手順で説明する sharding_schema への参照として機能します。
  • sharding_schema: オブジェクトの配列。それぞれがシャーディング スキーマを表します。 各シャーディング スキーマ オブジェクトには、次のものが含まれます。

    • 名前: シャーディング スキーマの名前。
    • partitioned_by: シャーディングスキーマのパーティション分割に使用される1つ以上の列を含む配列。
    • bucket_count(省略可能): テーブルが分散されるバケットの合計数を表す整数。既定値は 1 です。
    • bucketed_by(省略可能): データがバケット化される 1 つ以上の列を含む配列。パーティション分割とバケット化は階層的であり、各パーティションがバケット化されていることを意味します。
    • partition_map: オブジェクトの配列。それぞれがシャーディング スキーマ内のパーティションを表します。 各パーティション オブジェクトには次のものが含まれます。
      • パーティション: partition-key=partitionvalue 形式で指定されたパーティション値
      • シャード: オブジェクトの配列。それぞれがパーティション内のシャードを表し、配列の各要素はレプリカを表し、trino はパーティション/バケットのデータをフェッチするためにランダムにそれらのいずれかを照会します。 各シャード オブジェクトには次のものが含まれます。
        • connectionUrl: シャードのデータベースへの JDBC 接続 URL。

たとえば、このコネクタを使用してクエリを実行する2つのテーブル lineitempart を次のように指定できます。

	"tables": [
		{
			"schema": "dbo",
			"name": "lineitem",
			"sharding_schema": "schema1"
		},
		{
			"schema": "dbo",
			"name": "part",
			"sharding_schema": "schema2"
		}
    ]

手記

コネクタは、テーブルのスキーマで定義されている SQL サーバーにすべてのテーブルが存在することを想定しています。そうでない場合、そのテーブルのクエリは失敗します。

前の例では、テーブル lineitem のレイアウトを次のように指定できます。

	"sharding_schema": [
		{
			"name": "schema1",
			"partitioned_by": [
				"shipmode"
			],
          		  "bucketed_by": [
              		  "partkey"
           		],
			"bucket_count": 10,
			"partition_map": [
				{
					"partition": "shipmode='AIR'",
                    			"buckets": 1-7,
					"shards": [
						{
							"connectionUrl": "jdbc:sqlserver://sampleserver.database.windows.net:1433;database=test1"
						}
					]
				},
				{
					"partition": "shipmode='AIR'",
                   			"buckets": 8-10,
					"shards": [
						{
							"connectionUrl": "jdbc:sqlserver://sampleserver.database.windows.net:1433;database=test2"
						}
					]
				}                
			]
        }
    ]

この例では、次の内容について説明します。

  • shipmodeでパーティション分割されたテーブル行項目のデータ。
  • 各パーティションには 10 個のバケットがあります。
  • 各パーティションは列partkeyによってバケット化されています。
  • パーティション値 AIR のバケット 1-7 は、test1 データベースにあります。
  • パーティション値 AIR のバケット 8-10 は、test2 データベースにあります。
  • シャードは、connectionUrlの配列です。 配列の各メンバーは replicaSet を表します。 クエリの実行中に、Trino は配列からシャードをランダムに選択してデータをクエリします。

パーティションとバケットの剪定

コネクタは、計画中にクエリ制約を評価し、指定されたクエリ述語に基づいて実行します。 これにより、クエリのパフォーマンスが高速化され、コネクタが大量のデータに対してクエリを実行できるようになります。

ここで に説明されているMurmurHash関数の実装を使用して、割り当てを決定するためのハッシュ分割法

型マッピング

シャードSQLコネクタは、SQLサーバーコネクタと同じ型マッピングをサポートします。型マッピング

プッシュダウン

次のプッシュダウン最適化がサポートされています。

  • プッシュダウンの制限
  • 分配集計
  • プッシュダウンに参加する

JOIN 操作をサーバーにプッシュダウンできるのは、コネクタがビルド テーブルとプローブ テーブルのデータが併置されていると判断した場合のみです。 コネクタは、left テーブルと right テーブルの両方のsharding_schemaが同じである場合に、データが併置されると判断します。 - 結合条件はパーティションキーとバケットキーの上位集合です。

プッシュダウンの最適化 JOIN 使用するには、カタログ プロパティ join-pushdown.strategyEAGER に設定する必要があります

このコネクタのAGGREGATEプッシュダウンは、分配集合体に対してのみ実行できます。 この最適化を有効にするには、オプティマイザー構成 optimizer.partial-aggregate-pushdown-enabledtrue に設定する必要があります。