シャード化された SQL コネクタ
Note
Azure HDInsight on AKS は 2025 年 1 月 31 日に廃止されます。 2025 年 1 月 31 日より前に、ワークロードを Microsoft Fabric または同等の Azure 製品に移行することで、ワークロードの突然の終了を回避する必要があります。 サブスクリプション上に残っているクラスターは停止され、ホストから削除されることになります。
提供終了日までは基本サポートのみが利用できます。
重要
現在、この機能はプレビュー段階にあります。 ベータ版、プレビュー版、または一般提供としてまだリリースされていない Azure の機能に適用されるその他の法律条項については、「Microsoft Azure プレビューの追加の使用条件」に記載されています。 この特定のプレビューについては、「Microsoft HDInsight on AKS のプレビュー情報」を参照してください。 質問や機能の提案については、詳細を記載した要求を AskHDInsight で送信してください。また、その他の更新については、Azure HDInsight コミュニティのフォローをお願いいたします。
シャード化された SQL コネクタにより、任意の数の SQL サーバーに分散されたデータに対してクエリを実行できるようになります。
前提条件
シャード化された SQL サーバーに接続するには、次が必要です。
- SQL Server 2012 以降 または Azure SQL Database。
- Trino コーディネーターとワーカーからの SQL Server へのネットワーク アクセス。 既定のポートは、ポート 1433 です。
全般構成
コネクタは、複数の SQL サーバーを 1 つのデータ ソースとしてクエリを実行できます。 カタログ プロパティ ファイルを作成し、シャード化された SQL コネクタを使用するために、connector.name=sharded-sql
を使用 します。
構成の例:
connector.name=sharded_sqlserver
connection-user=<user-name>
connection-password=<user-password>
sharded-cluster=true
shard-config-location=<path-to-sharding-schema>
プロパティ | 説明 |
---|---|
connector.name | シャード化された SQL 用のコネクタの名前で、これには sharded_sqlserver を指定する必要があります |
connection-user | SQL Server 内のユーザー名 |
connection-password | SQL Server 内のユーザーのパスワード |
sharded-cluster | sharded-sql コネクタに対しては、TRUE に設定する必要があります |
shard-config-location | シャーディング スキーマを定義する構成の保存先 |
データ ソースの認証
コネクタは、 SQL サーバーに対しクエリを実行するために、ユーザー パスワード認証を使用します。 すべての SQL サーバーに対する認証を、構成で指定したのと同じユーザーが行うことを想定します。
スキーマ定義
コネクタは、SQL サーバー間の物理データについて、 2D パーティション/バケットレイアウトを前提としています。 スキーマ定義が、このレイアウトについて記述します。 現時点では、ファイル ベースのシャーディング スキーマ定義のみがサポートされています。
shard-config-location=etc/shard-schema.json
のようなカタログ プロパティで、シャーディング スキーマの json の保存先を指定できます。
レイアウトを指定するのに必要なプロパティを使用して、シャーディング スキーマ json を構成します。
次の JSON ファイルでは、Trino のシャード化 SQL コネクタのための構成を記述しています。 その構造の内訳を次に示します。
tables: オブジェクトの配列。各オブジェクトはデータベース内のテーブルを表します。 各テーブル オブジェクトには次が含まれます。
- schema: SQL Server 内のデータベースに対応するテーブルのスキーマ名。
- name: テーブルの名前。
- sharding_schema: テーブルに関連付けられているシャーディング スキーマの名前。これは、次の手順で説明する
sharding_schema
に対する参照として機能します。
sharding_schema: それぞれがシャーディング スキーマを表すオブジェクトの配列。 各シャーディング スキーマ オブジェクトには、次が含まれます。
- name: シャーディング スキーマの名前。
- partitioned_by: シャーディング スキーマをパーティション分割する 1 つ以上の列を含む配列。
- bucket_count (オプション): テーブルが分散されるバケットの合計数を表す整数。既定値は 1。
- bucketed_by (オプション): データをバケット化する 1 つ以上の列を含む配列。パーティション分割とバケット化は階層的であることに注意してください、つまり各パーティションはバケット化されています。
- partition_map: オブジェクトの配列。それぞれがシャーディング スキーマ内のパーティションを表します。 各パーティション オブジェクトには次が含まれます。
- partition:
partition-key=partitionvalue
の形式で指定されたパーティション値 - shards: それぞれがパーティション内のシャードを表すオブジェクトの配列で、配列の各要素はレプリカを表します。Trino はそのいずれかをランダムにクエリして、パーティション/バケットのデータをフェッチします。 各シャード オブジェクトには次が含まれます。
- connectionUrl: シャードのデータベースへの JDBC 接続 URL。
- partition:
たとえば、2 つのテーブル lineitem
および part
に、このコネクタを使用してクエリを実行したい場合には、次のように指定します。
"tables": [
{
"schema": "dbo",
"name": "lineitem",
"sharding_schema": "schema1"
},
{
"schema": "dbo",
"name": "part",
"sharding_schema": "schema2"
}
]
Note
コネクタは、テーブルのスキーマで定義されている 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 個のバケットがあります。
- 各パーティションは bucketed_by の
partkey
列です。 - パーティション値
AIR
のバケット1-7
は、test1
データベース内に置かれています。 - パーティション値
AIR
のバケット8-10
は、test2
データベース内に置かれています。 - 各シャードは
connectionUrl
の配列です。 配列の各メンバーは replicaSet を表します。 クエリの実行中、Trino はデータをクエリするシャードを配列からランダムに選択します。
パーティションとバケットの除去
コネクタは、プランニング中にクエリの制約を評価し、指定されたクエリ述語に基づいてそれを実行します。 これにより、クエリのパフォーマンスが高速化され、コネクタが大量のデータに対してクエリを実行できるようになります。
こちらで説明されている murmur hash 関数の実装を使用して、割り当てを決定するバケット式。
型マッピング
シャード化された SQL コネクタでは、SQL Server コネクタの型マッピングと同じ型マッピングがサポートされます。
プッシュダウン
次のプッシュダウン最適化がサポートされています。
- 制限プッシュダウン
- 分散的集計
- 結合のプッシュダウン
JOIN
操作をサーバーにプッシュダウンできるのは、ビルド テーブルとプローブ テーブルに、データが併置されているとコネクタが判定した場合のみです。 コネクタは、left
と right
、両方のテーブルで sharding_schema が同じである場合に、データが併置されていると判断します。
- 結合条件は、パーティション分割キーとバケット キーのスーパーセットです。
JOIN
プッシュダウンの最適化を使用するには、カタログ プロパティ join-pushdown.strategy
を EAGER
に設定する必要があります
このコネクタの AGGREGATE
プッシュダウンは、分散的集計に対してのみ実行できます。 この最適化を有効にするには、オプティマイザー構成 optimizer.partial-aggregate-pushdown-enabled
を true
に設定する必要があります。