SQL Server ビッグ データ クラスターに関する FAQ

Windows または Linux 上のベア メタル マシンで SQL Server を構成する場合と比べて、この点に関する柔軟性は低くなります。 Kubernetes 環境では、これらの成果物は抽象化され、移植可能である必要があります。 現在、構成可能なポッドごとに提供される、データとログ用に 2 つの永続ボリューム (PV) があります。 詳細については、「 Kubernetes の SQL Server ビッグ データ クラスターでのデータ永続化」を参照してください。

ログ バックアップは、(復旧モデルまたは HA の構成に応じて) SQL Server マスター インスタンスのユーザー データベースに対してのみ実行する必要があります。 データ プール データベースでは、SIMPLE 復旧モデルのみが使用されます。 PolyBase 用に作成された DW* データベースにも同じことが当てはまります。

ビッグ データ クラスターシナリオ用に拡張された既存の PolyBase DMV を使用できます。 詳細については、「 PolyBase の監視とトラブルシューティング」を参照してください。

Kubernetes API または kubectl を使用して一部の設定を変更できますが、サポートも推奨もされていません。 azdata を使用して、すべてのビッグ データ クラスター管理操作を実行する必要があります。

WebHDFS を使用して、ハードウェア レベルのストレージ スナップショット作成またはコピー/同期を有効にする任意のソリューションを使用できます。 azdata bdc hdfs cpを使用することもできます。詳細については、azdata bdc hdfs を参照してください。

現時点ではできません。 1 つのオプションは、 Always On 可用性グループに SQL Server をデプロイすることです。 その後、 読み取り可能なセカンダリ レプリカを 使用して、いくつかのプロセス (ml のトレーニング/スコアリング、メンテナンス アクティビティなど) を実行できます。

現時点では、これはサポートされているシナリオではありません。

データ プール インスタンス内のデータベースには、外部テーブルに関するメタデータはありません。これは、任意のユーザー データベースに似ています。 バックアップ/復元を行うことができますが、一貫性のない結果を回避するには、 SQL Master インスタンス のメタデータ データベース内の外部テーブル メタデータが同期されていることを確認する必要があります。

データ プールは分散テーブルの概念です。 シャーディングは通常、OLTP の概念として参照されます。これは現在サポートされていません。

プールという用語は、同種のサービスまたはアプリケーションのコレクションを記述するために予約されています。 たとえば、データ プールはステートフルな SQL Server コンピューティングのセットであり、ストレージ プールは HDFS サービスと Spark サービスのセットです。 SQL Server マスターは、可用性グループで構成できる単一インスタンスまたは複数のインスタンスです。 SQL Server マスター インスタンスは、Linux 上の通常の SQL Server インスタンスであり、Linux で使用できる任意の機能を使用できます。 最初に、データ モデル、エンティティ、および主にエンティティで動作するサービス/アプリケーションから始める必要があります。 SQL Server や HDFS、データ プールなど、すべてのデータを 1 か所に格納する必要はありません。 データ分析に基づいて、ほとんどのデータを HDFS に格納し、データをより効率的な形式に処理し、他のサービスに公開することができます。 残りのデータは SQL Master インスタンスに格納されます。

現時点では、これはサポートされているシナリオではありません。

各ポッドに保持できる永続ボリューム (PV) は 2 つだけです。 OS レベルでボリュームを抽象化し、永続ストレージに使用できます。 たとえば、複数のディスクを使用して RAID 0 OS パーティションを作成し、ローカル ストレージ プロビジョンタを使用して永続ボリュームに使用できます。 現在、ポッドごとにさらに多くの PV を使用する方法はありません。 PV はコンテナー内のディレクトリにマップされ、これは固定されています。 永続ボリュームの詳細については、 Kubernetes ドキュメントの永続ボリュームを参照してください。

デプロイ時に特定のストレージ クラスを使用するように記憶域プールを構成できます。 Kubernetes の SQL Server ビッグ データ クラスターでのデータ永続化に関する説明を参照してください。

HDFS の階層化により、S3 ベースのプロトコルと透過的に統合できます。 詳細については、 ビッグ データ クラスターで HDFS 階層化用に S3 をマウントする方法に関する記事を参照してください。

はい。データは永続ボリュームによってバックアップされ、アップグレードによって新しいイメージを使用して既存のポッドがデプロイされるだけなので、データは保持されます。

HDFS 階層化を使用すると、ビッグ データ クラスターで実行されているローカル HDFS を使用してデータがキャッシュされるため、ユーザーはすべてのデータを取り込む必要なく、大規模なデータ レイクに接続できます。 キャッシュに割り当てられる構成可能な領域の量は、既定では現在 2% です。 データはキャッシュに保持されますが、そのしきい値を超えると削除されます。 セキュリティもレイクから維持され、すべての ACL が適用されます。 詳細については、「 ビッグ データ クラスターでの HDFS 階層化の構成」を参照してください。

はい。HDFS 階層化を使用して、ADLS Gen2 に格納されているデータを仮想化できます。 HDFS 階層化が ADLS Gen2 にマウントされると、ユーザーは HDFS データに対してクエリを実行し、それに対して Spark ジョブを実行できるようになります。 マウントされたストレージは、--mount-path で指定された場所のビッグ データ クラスターの HDFS に表示され、ユーザーはローカル ストレージを操作する場合と同様に、そのマウント パスを操作できます。 詳細については、ビッグ データ クラスターでの HDFS 階層化の構成に関するページを参照してください。 HDFS レベルのアクセス許可の詳細については、「 SQL Server ビッグ データ クラスターの HDFS アクセス許可を管理する」を参照してください。

AKS コントロール プレーンでは 、アップタイム SLA によって 99.95% 可用性が保証されます。 AKS クラスター ノード (ワーカー ノード) は可用性ゾーンを使用します。詳細については、 AKS 可用性ゾーンに関するページを参照してください。 可用性ゾーン (AZ) は、データセンターの障害からアプリケーションとデータを保護する Azure の高可用性オファリングです。 AKS では、Availability Zones を使用しないクラスターの 99.9% 可用性がサポートされています。 詳細については、 Azure Kubernetes Service (AKS) の SLA を参照してください。

sparkhead を再起動してもログが失われることはありません。これらのログは HDFS にあります。 /gateway/default/sparkhistory UI の Spark 履歴ログは引き続き表示されます。 Yarn コンテナー ログの場合、Yarn RM が再起動するため、Yarn UI にこれらのアプリは表示されませんが、これらの Yarn ログは引き続き HDFS にあり、Spark 履歴サーバーからそれらのアプリにリンクできます。 Spark アプリを診断するには、必ず Spark 履歴サーバーをエントリ ポイントとして使用する必要があります。

既定では、マウントされたデータのキャッシュのために、合計 HDFS ストレージの 1% が予約されます。 キャッシュは、マウント全体のグローバル設定です。 現時点では、オフにする方法は公開されていませんが、 割合は hdfs-site.dfs.provided.cache.capacity.fraction 設定を使用して構成できます。 この設定は、提供されたストアのデータをキャッシュするために使用できるクラスター内の合計容量の割合を制御します。 変更するには、「 デプロイ後にビッグ データ クラスターの設定を構成する方法」を参照してください。 詳細については、「 SQL Server ビッグ データ クラスターでの HDFS 階層化の構成」を参照してください。

ビッグ データ クラスターの SQL Server マスター インスタンスで SQL Server エージェント サービスを使用できます。

現時点では、ビッグ データ クラスター内の InfluxDB は、ビッグ データ クラスター内で収集された監視データの格納にのみ使用され、外部エンドポイントとして公開されることはありません。

現時点では、ビッグ データ クラスター内の InfluxDB は、ビッグ データ クラスター内で収集された監視データの格納にのみ使用され、外部エンドポイントとして公開されることはありません。

ビッグ データ クラスターでは、HA 構成によって包含タグと呼ばれる可用性グループが作成されます。これには、レプリカ間でレプリケートされるシステム データベースも含まれます。 CREATE DATABASE または RESTORE ワークフローの結果として作成されたデータベースは、含まれている AG に自動的に追加され、シード処理されます。 SQL Server 2019 (15.0) CU2 より前のバージョンでは、ビッグ データ クラスター内の物理インスタンスに接続し、データベースを復元して包含タグに追加する必要があります。 「高可用性を使用して SQL Server ビッグ データ クラスターを展開する」を参照してください。

現時点では、SQL Server と同様に、sp_configureを使用して SQL インスタンスのメモリを設定できます。 コアの場合は、 ALTER SERVER CONFIGURATION SET PROCESS AFFINITYを使用できます。 既定では、コンテナーにはホスト上のすべての CPU が表示され、現時点では Kubernetes を使用してリソース制限を指定する方法はありません。 コンピューティング プール/データ プール/記憶域プールの場合、構成は SQL Server マスター インスタンスの EXECUTE AT DATA_SOURCE ステートメントを使用して実行できます。

それぞれのワーカー ノードにアフィニティされていないポッドは、十分なリソースがあれば、Kubernetes クラスター内の別のノードに移動されます。 それ以外の場合、ポッドは使用できなくなり、障害が発生します。

このアクションは、Kubernetes にのみ依存します。 ノード ラベルを使用したポッドの配置とは別に、ビッグ データ クラスター内から Kubernetes リソースの再分散を制御する他のメカニズムはありません。

このアクションは、シャットダウン中のホスト ノードと同じです。 Kubernetes にはテイント プロセスを使用してこれを調整するメカニズムがあり、通常はアップグレードまたはノードのメンテナンスに従います。 詳細については、 Taints と Tolerations の Kubernetes ドキュメントを参照してください。

はい。レプリケーション係数は、HDFS で使用可能な構成の 1 つです。 詳細については、「 永続ボリュームの構成」を参照してください。

ユース ケースと要件によって異なります。 ビッグ データ クラスターには、Microsoft がサポートする Spark と HDFS に加えて、オンプレミスの SQL Server の完全なサーフェス領域が用意されています。 ビッグ データ クラスターを使用すると、SQL Server のお客様は分析/ビッグ データに統合できます。 Azure Synapse は純粋に分析プラットフォームであり、スケールアウト分析に重点を置き、クラウドのマネージド サービスとしてお客様にファーストクラスのエクスペリエンスを提供します。 Azure Synapse は、その一部として運用ワークロードをターゲットにしていません。 ビッグ データ クラスターは、運用ストアに近いデータベース分析シナリオで提供することを目指しています。

SQL Server インスタンスのデータベース ファイルは HDFS に格納されませんが、SQL Server は外部テーブル インターフェイスを使用して HDFS にクエリを実行できます。

ROUND_ROBINとレプリケート。 ROUND_ROBINが既定値です。 HASH は使用できません。

現在、Thrift プロトコルを使用して Hive Metastore (HMS) を公開しています。 プロトコルを文書化しますが、現時点では ODBC エンドポイントを開いっていません。  Hive メタストア HTTP プロトコルを使用してアクセスできます。詳細については、 Hive メタストア HTTP プロトコルに関する説明を参照してください。

SQL Server on Linux (ビッグ データ クラスターの SQL Server マスター インスタンスにも適用されます) では、汎用 ODBC データ ソースがサポートされていないため、サードパーティの ODBC ドライバー (SnowFlake、DB2、PostgreSQL など) をインストールしてクエリを実行できます。 この機能は現在、Windows 上の SQL Server 2019 (15.0) でのみ使用できます。 ビッグ データ クラスターでは、JDBC を使用して Spark 経由でデータを読み取り、MSSQL Spark コネクタを使用して SQL Server に取り込むことができます。

SQL Server on Linux (ビッグ データ クラスターの SQL Server マスター インスタンスにも適用されます) では、汎用 ODBC データ ソースがサポートされていないため、サードパーティの ODBC ドライバー (SnowFlake、DB2、PostgreSQL など) をインストールしてクエリを実行できます。

INSERT..SELECTアプローチを使用すると、毎回新しいテーブルが不要になります。

SQL Server マスター インスタンスに分析ワークロードを満たすのに十分なリソースがある場合は、常に最速のオプションです。 データ プールは、分散クエリの他の SQL インスタンスに実行をオフロードする場合に役立ちます。 データ プールを使用して、さまざまな SQL インスタンスに並列で Spark Executor からデータを取り込むこともできます。そのため、Hadoop 分散ファイル システム (HDFS) から生成される大規模なデータセットの読み込みパフォーマンスは、通常、単一の SQL Server インスタンスに入るよりも優れています。 ただし、SQL Server に複数のテーブルを含め、必要に合わせて並列に挿入できるため、これは言い難いです。 パフォーマンスは多くの要因に依存し、その点に関して単一のガイダンスや推奨事項はありません。

EXECUTE AT を使用すると、sys.dm_db_partition_statsなどの DMV にクエリを実行して、各ローカル テーブルのデータを取得できます。

いいえ。 azdata bdc hdfs cp を使用できます。 ルート ディレクトリを指定すると、コマンドはツリー全体を再帰的にコピーします。 ソース/ターゲット パスを変更するだけで、このコマンドを使用してイン/アウトをコピーできます。

MSSQL Spark コネクタ ライブラリを使用して、SQL とデータ プールの取り込みを支援できます。 ガイド付きチュートリアルについては、「 チュートリアル: Spark ジョブを使用して SQL Server データ プールにデータを取り込む」を参照してください。

azdata bdc hdfs cp a try を指定します。 ルート ディレクトリを指定すると、コマンドはツリー全体を再帰的にコピーします。 ソース/ターゲット パスを変更するだけで、このコマンドを使用してイン/アウトをコピーできます。

現時点では、この操作を実行する azdata インターフェイスはありません。 必要な PVC のサイズを手動で変更することもできます。 サイズ変更は複雑な操作です。 Kubernetes ドキュメントの永続ボリュームを参照してください。

主な相違点とユース ケースについては、 PolyBase に関する FAQ を参照してください。

ビッグ データ クラスターでは、SQL Server、Oracle、MongoDB、Teradata などの ODBC ソースからの データ仮想化 がサポートされています。また、 Azure Data Lake Store Gen2 や S3 互換ストレージなどのリモート ストアの階層化、AWS S3A、Azure Blob File System (ABFS) の階層化もサポートしています。

はい。ビッグ データ クラスターの PolyBase を使用して、Azure SQL Database のデータにアクセスできます。

一般に、外部キーワードは、データが SQL Server インスタンス内にないことを意味します。 たとえば、HDFS ディレクトリの上に記憶域プール テーブルを定義できます。 データはデータベース ファイルではなく HDFS ファイルに格納されますが、外部テーブルを使用すると、HDFS ファイルをデータベース内にあるかのようにリレーショナル テーブルとしてクエリするためのインターフェイスが提供されます。
外部データへのアクセスのこの概念はデータ仮想化と呼ばれ、詳細については、「 PolyBase を使用したデータ仮想化の概要」を参照してください。 HDFS の CSV ファイルからデータを仮想化するチュートリアルについては、「記憶域プール ビッグ データ クラスターから CSV データを仮想化する」を参照してください。

比較については、 ビッグ データ クラスターの PolyBase とスタンドアロン インスタンスの PolyBase を参照してください。

データ ソースの場所のプレフィックス (sqlserver://、oracle://、sqlhdfs://、sqldatapool:// など) を調べることで、外部テーブルの種類を確認できます。

Azure Data Studio ノートブックを使用した SQL Server ビッグ データ クラスターの管理に関するページを参照してください。 Kubernetes のトラブルシューティングに関するトピックも参照してください。

デプロイ時に実行できるすべてのカスタマイズについては、 クラスター リソースとサービスのデプロイ設定の構成に関するページを参照してください。 Spark については、「 ビッグ データ クラスターでの Apache Spark と Apache Hadoop の構成」を参照してください。

いいえ。 具体的には、SQL Server Analysis Services (SSAS) は SQL Server on Linux ではサポートされていないため、SSAS を実行するには Windows サーバーに SQL Server インスタンスをインストールする必要があります。

ビッグ データ クラスターは、バージョン 1.13 以降に基づいて任意の Kubernetes スタックで実行できます。 ただし、EKS または GKS でビッグ データ クラスターの特定の検証を実行していません。

Spark は 2.4、HDFS は 3.2.1 です。 ビッグ データ クラスターに含まれるオープンソース ソフトウェアの詳細については、 オープンソース ソフトウェア リファレンスを参照してください。

Spark にパッケージを インストールするためのサンプル ノートブックの手順を使用して、ジョブの送信時にパッケージを追加できます。

Machine Learning (ML) サービス (R および Python) は、SQL Server 2017 以降で使用できます。 ML サービスは、SQL Server ビッグ データ クラスターでも使用できます。 詳細については、「 Python と R を使用した SQL Server Machine Learning Services とは」を参照してください。

詳細については、ライセンス ガイドを参照し、 PDF をダウンロードしてください。
概要については、 SQL Server ライセンス: ビッグ データ クラスターのビデオをご覧ください。 |公開されているデータ。

現時点ではできません。

はい。統合認証 (Active Directory を使用) を使用して、さまざまなビッグ データ クラスター サービスに接続できます。 詳細については、「 Active Directory モードでの SQL Server ビッグ データ クラスターの展開」を参照してください。 ビッグ データ クラスターのセキュリティの概念も参照してください。

基本認証モード (ユーザー名/パスワード) では、コントローラーまたは Knox ゲートウェイ/HDFS エンドポイントに対して複数のユーザーを追加することはできません。 これらのエンドポイントでサポートされている唯一のユーザーは root です。 SQL Server の場合、他の SQL Server インスタンスの場合と同様に、Transact-SQL を使用してユーザーを追加できます。 エンドポイントの AD 認証を使用してビッグ データ クラスターをデプロイする場合は、複数のユーザーがサポートされます。 デプロイ時に AD グループを構成する方法の詳細については、こちらを参照してください。 詳細については、「 Active Directory モードでの SQL Server ビッグ データ クラスターの展開」を参照してください。

Azure IP 範囲とサービス タグ ( パブリック クラウド) のさまざまなサービスで使用される IP アドレスを確認できます。 これらの IP アドレスは定期的にローテーションされることに注意してください。
コントローラー サービスが Microsoft Container Registry (MCR) からコンテナー イメージをプルするには、 MicrosoftContainerRegistry セクションで指定された IP アドレスへのアクセス権を付与する必要があります。 もう 1 つのオプションは、プライベート Azure Container Registry を設定し、そこからプルするようにビッグ データ クラスターを構成することです。 その場合は、 AzureContainerRegistry セクションで指定された IP アドレスを公開する必要があります。 これを行う方法とスクリプトの手順については、「 SQL Server ビッグ データ クラスターのオフライン展開の実行」を参照してください。

はい。詳細については、「 SQL Server ビッグ データ クラスターのオフライン展開の実行」を参照してください。

これは、Azure Kubernetes Service (AKS) の動的ストレージ プロビジョニングツールの構成によって異なります。 詳細については、Azure Kubernetes Service (AKS) でのストレージとバックアップのベスト プラクティスに関するページを参照してください。

はい。 詳細については、「ビッグ データ クラスターのキー バージョン」を参照してください。

はい。SQL Server ビッグ データ クラスター CU13 で導入された新機能を使用して、 自動生成された Active Directory オブジェクト のパスワードを簡単にローテーションできます。 詳細については、「 AD パスワードのローテーション」を参照してください。

はい。Microsoft では、ビッグ データ クラスター内に出荷されるすべてのコンポーネントがサポートされています。

SQL Server ML Services のサポート ポリシーは、すべてのメジャー リリースに新しいランタイム バージョンが付属している点を除き、SQL Server のサポート ポリシーと同じです。 SparkML ライブラリ自体はオープン ソース ソフトウェア (OSS) です。 ビッグ データ クラスターには多数の OSS コンポーネントがパッケージ化されており、これは Microsoft によってサポートされています。

現時点ではできません。 テスト対象の構成については、こちらを参照してください。

はい。Azure Data Studio に表示されたのと同じ Jupyter カーネルです。

いいえ。現時点では、 azdata はオープン ソースではありません。

使用できるリソースを次に示します。
ワークショップ: Kubernetes - ベア メタルから SQL Server ビッグ データ クラスターへ
ワークショップ: SQL Server ビッグ データ クラスター - アーキテクチャ
チュートリアル: Azure Kubernetes Service (AKS) 用のアプリケーションの準備

(PDF)ケース スタディ: MS SQL Server 2019 ビッグ データ クラスターの Apache Spark で実行されている SQL ワークロード

こちらも参照ください

• SQL Server ビッグ データ クラスター