SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
Azure Machine Learning Studio で、機械学習モデルを作成する際のデータセットとして、次のようなデータストアを選択することができるのですが、この中には Synapse Analytics は含まれていません。
SQL Database の論理サーバー内に専用 SQL プール (Dedicated SQL Pool) を使用した場合は、論理サーバーの下に DB が作成されますので、接続のエンドポイントとしては「～.database.windows.net」を使用することができますので、データストアの種類として「Azure SQL Database」を選択しても戸惑うことなくデータストアを作成できるのではないでしょうか。
Synapse Analytics の Dedicated SQL Pool (専用 SQL プール) に対して、データローディングを行う際には、いくつかのポイントがあり、特性を意識したデータローディングを実施しないと、パフォーマンスが大幅に低下する恐れがあります。
本投稿ではどのようなアプローチを行えばよいのかについてまとめておきたいと思います。
Build 2021 の SQL Server ベースの環境の発表については、Build 2021 のタイミングで発表された SQL Server / SQL Database のアップデート に Synapse も含めて書いてみましたが、Synapse 単体でもいくつかのドキュメントの更新が行われていますので、Synapse Analytics のみで、一度アップデートの内容を把握しておきたいと思います。
Ignite 2021 で、発表された内容の中に Synapse Pathway がありました。
Synapse Pathway は Azure Synapse Analytics の専用 SQL プールに移行するための、SQL のコード変換を行うことができるツールとなっています。
2021/3/10 時点では、次の環境のオブジェクトの変換を行うことができるようになっています。
今後、Amazon Redshift / Google BigQuery / Teradata のサポートも予定されているようですね。
日本語化されたドキュメントも Azure Synapse Pathway プレビューの概要 で公開されましたので、SQL Server からの変換を使用して、機能を試してみたいと思います。
Synapse Pathway はクラウドサービスではなく、スタンドアロンのツールとして提供されており、実行環境にツールをインストールする必要があります。
モジュールのダウンロード / インストール方法は本投稿では触れていません。
ツールの導入方法については、、Azure Synapse Pathway プレビューのダウンロード を参照してください。
インストーラーをダウンロードしてセットアップをぽちぽちするとインストールされます。
Synapse Analytics のファイアウォール設定や、プライベートエンドポイント経由でのアクセスを、Synapse Studio で確認していて、一部の項目がうまく表示されない場合などの調査時のメモを。
ファイアウォールで「Azure サービスおよびリソースに、このワークスペースへのアクセスを許可する」をオフにして、アクセスを厳しくしている場合の調査に使っていました。 
Synapse Analytics は Azure Data Factory のようなパイプラインの実行機能を持っており、クラウドベースの ETL の実行を行うことができます。
Synapse Analytics と Data Factory のパイプラインの違いについては、Data integration in Azure Synapse Analytics versus Azure Data Factory に記載されており、いくつかの違いがあります。
Monitoring についても機能差があり、Synapse のパイプラインは Azure Monitor に統合が行われていません。
これにより、現時点では、パイプライン (またはトリガー) の実行状況の取得方法が、Data Factory とは異なります。
また、Azure Monitor と統合がされていないことにより、診断設定の利用可否も変わってくるかと思います。
しばやん先生が Hack Azure! #4 – Synapse と Cosmos で実現するサーバーレスデータ分析 フォローアップ で紹介していますが、Synapse Analytics の Serverless SQL pool の分散クエリ処理エンジン (Distributed Query Processing Engine : DQP) については、POLARIS として、Microsoft Research から、「POLARIS: The Distributed SQL Engine in Azure Synapse」として、論文が公開されています。
論文を読むのはしんどいのですが、VLDB 2020 では、動画の公開も行われていましたので、こちらも合わせながら、ざっくりと眺めてみました。
Synapse Analytics (Workspace) の SQL on-demand (Serverless SQL Pool) では、次の形態の DB を利用することができます。
従来の、Azure SQL Database では「論理サーバー」を使用した環境の場合、サーバーはエンドポイントとなっていました。
エンドポイント内に複数のデータベースを作成することはできるのですが、各データベースは独立したリソースで動作しているため、データベースを跨いだクエリの実行にはかなり制限がありました。
SQL on-demand の場合、Azure SQL Database の論理サーバーモデルとは異なり、データベースを跨いだクエリの実行ができるようです。
Azure Synapse SQL でサポートされる Transact-SQL 機能 で、サポートされる T-SQL の機能が記載されているのですが、SQL on-demand では、データベース間のクエリはサポートとなっています。
SQL on-demand (Serverless SQL Pool) では、共有メタデータテーブル という形で Spark Pool で作製した Parquet フォーマットを使用したテーブルを、SQL on-demand で参照することができます。
先日投稿した、Synapse Analytics の Serverless SQL Pool (SQL on-demand) でテキストを参照する際の文字コードの設定 (おまけで Synapse Link for Cosmos DB) でも Synapse Analytics の照合順序に触れましたが、共有メタデータテーブルでも照合順序はポイントとなる点がありますので、触れておきたいと思います。
ドキュメントについては、SQL オンデマンド (プレビュー) で Apache Spark for Azure Synapse の外部テーブル定義を同期する を参照すると良いかと。
