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

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

SQL Server マスター インスタンス内のユーザー データベースのログ バックアップのみを行う必要があります (復旧モデルまたは HA 構成によって異なります)。 データ プール データベースには単純復旧モデルのみを使用します。 PolyBase 用に作成された DW* データベースに対しても同じことが当てはまります。

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

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

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

現時点ではありません。 1 つの方法として、Always On 可用性グループに SQL Server を展開します。 次に、読み取り可能なセカンダリ レプリカを使用して、いくつかのプロセスを実行できます (例: ML のトレーニングまたはスコアリング、メンテナンス作業など)。

これは、現時点ではサポートされていないシナリオです。

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

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

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

これは、現時点ではサポートされていないシナリオです。

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

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

HDFS 階層化を使用すると、S3 ベースのプロトコルとの透過的な統合が可能です。 詳細については、「ビッグ データ クラスターに HDFS 階層制御のための S3 をマウントする方法」を参照してください。

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

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

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

AKS コントロール プレーンでは、アップタイム SLA によって 99.95% の可用性が保証されます。 AKS クラスター ノード (ワーカー ノード) には可用性ゾーンが使用されます。詳細については、AKS 可用性ゾーンに関するページを参照してください。 可用性ゾーン (AZ) は、高可用性を提供する Azure のサービスで、アプリケーションとデータをデータセンターの障害から保護します。 AKS によって、可用性ゾーンを使用しないクラスターに対して 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 設定を使用して割合を構成できます。 この設定により、指定されたストアからのデータのキャッシュに使用できる、クラスターの合計容量の割合を管理します。 変更するには、「配置後に BDC の設定を構成する方法」を参照してください。 詳細については、「SQL Server ビッグ データ クラスターで HDFS の階層化を構成する」を参照してください。

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

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

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

ビッグ データ クラスターには、HA 構成によって containedag という可用性グループが作成されます。これには、レプリカ間でレプリケートされるシステム データベースも含まれます。 CREATE DATABASE または RESTORE ワークフローの結果として作成されたデータベースは、含まれている AG に自動的に追加され、シード処理されます。 SQL Server 2019 (15.0) CU2 より前は、ビッグ データ クラスター内の物理インスタンスに接続し、データベースを復元して、それを containedag に追加する必要があります。 「高可用性を使用して 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 には、テイント プロセスを使用してこれを調整するメカニズムがあり、これは通常、アップグレードまたはノードのメンテナンスのために実行されます。 詳細については、テイントおよび容認に関する Kubernetes のドキュメントを参照してください。

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

それはユース ケースと要件によって異なります。 ビッグ データ クラスターによって、Microsoft がサポートする Spark と HDFS に加えて、SQL Server への外部からの完全なアクセスがオンプレミスで提供されます。 ビッグ データ クラスターを使用すると、SQL Server ユーザーは分析とビッグ データへの統合が可能になります。 Azure Synapse はあくまでも、クラウド上のマネージド サービスとしてお客様にファースト クラスのエクスペリエンスを提供する、スケールアウト分析に重点を置いた分析プラットフォームです。 Azure Synapse の場合、その一部として運用ワークロードはターゲットとされていません。 ビッグ データ クラスターは、運用ストアにもっと近いデータベース分析シナリオに対応することを目標としています。

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

ROUND_ROBIN と REPLICATED です。 ROUND_ROBIN が既定値です。 HASH は使用できません。

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

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

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

INSERT..SELECT のアプローチを使用すると、毎回新しいテーブルを必要としなくて済みます。

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

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

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

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

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

現時点では、この操作を実行するための azdata インターフェイスはありません。 必要な PVC のサイズを手動で変更するオプションがあります。 サイズ変更は複雑な操作です。Kubernetes のドキュメントで「Persistent Volumes」 (永続ボリューム) を参照してください。

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

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

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

一般に、external キーワードは、データが 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 ビッグ データ クラスターでも使用できます。 詳細については、「SQL Server Machine Learning Services (Python と R) とは」を参照してください。

詳細を説明しているライセンス ガイドを参照してください。PDF のダウンロードはこちらです。
概要については、「SQL Server Licensing: Big Data Clusters | Data Exposed」(SQL Server ライセンス: ビッグ データ クラスター |Data Exposed) のビデオをご覧ください。

現時点ではありません。

はい。統合認証 (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 コンテナー レジストリを設定し、そこからプルするようにビッグ データ クラスターを構成することです。 その場合、、AzureContainerRegistry セクションで指定した IP アドレスを公開する必要があります。 これを行う方法とスクリプトは、「SQL Server ビッグ データ クラスターのオフライン展開を実行する」に記載されています。

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

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

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

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

はい。ビッグ データ クラスター内に付属するすべてのコンポーネントが Microsoft によってサポートされます。

SQL Server ML サービスのサポート ポリシーは、すべてのメジャー リリースに新しいランタイム バージョンが付属していることを除き、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 ビッグ データ クラスター