オンプレミス データ ゲートウェイ: セットアップおよび構成ガイド

オンプレミス データ ゲートウェイは、Power BI サービス (クラウド) とオンプレミス データ ソースの間のブリッジです。これがないと、企業ファイアウォールの背後にあるデータ (SQL Server データベース、PostgreSQL インスタンス、Oracle システム、ファイル共有、ODBC ソースなど) は Power BI サービスで更新できません。ゲートウェイは、クラウドからオンプレミス データベースへのライブ/DirectQuery 接続にも必要です。

ゲートウェイは重要な役割を果たしているにもかかわらず、後回しにされることがよくあります。組織は開発者のラップトップにこれをインストールし、高可用性構成をスキップし、スケジュールされた更新がなぜ毎週末失敗するのか疑問に思っています。このガイドでは、アーキテクチャの決定、インストール、クラスタリング、データ ソースの構成、監視、パフォーマンスの調整、最も一般的なエラーのトラブルシューティングなど、ライフサイクル全体をカバーしています。

---

重要なポイント

• オンプレミス データ ゲートウェイには、パーソナル (シングル ユーザー、共有なし) と標準/エンタープライズ (組織全体で共有、クラスタリングをサポート) の 2 つのモードがあります。
• エンタープライズ ゲートウェイは、信頼性の高い電力、ネットワーク、稼働時間を備えた専用サーバー (決して開発者ワークステーションではない) に常にインストールする必要があります。
• 2 つ以上のノードによるゲートウェイ クラスタリングにより高可用性が実現 --- 1 つのノードがダウンしても、もう 1 つのノードは更新リクエストの処理を継続します。
• すべての通信はゲートウェイから Azure Service Bus への送信です --- 受信ファイアウォール ポートを開く必要はありません
• データ ソースの資格情報は、回復キーを使用してゲートウェイ マシン上でローカルに暗号化されます --- このキーを失うと、すべてのデータ ソースを再構成することになります
• ゲートウェイ ログは、ユーザーのローカル アプリ データの下の GatewayComponents フォルダーにある、最も有用な単一のトラブルシューティング リソースです。
• リレーショナル ソースの接続プーリングを有効にし、適切なタイムアウト値を設定し、ゲートウェイ マシンに十分な RAM と CPU があることを確認することで、パフォーマンスを向上させることができます。

---

ゲートウェイのアーキテクチャ

ゲートウェイの仕組み

ゲートウェイは、TCP ポート 443 (HTTPS) を使用して Azure Service Bus への送信接続を確立します。ファイアウォールで受信ポートを開く必要はありません。通信の流れは次のとおりです。

1. ユーザーがサービスで Power BI レポートを開くか、スケジュールされた更新がトリガーされる
2. Power BI サービスが Azure Service Bus にクエリ要求を送信します。
3. ゲートウェイ (Azure Service Bus をポーリング) が要求を取得します。
4. ゲートウェイはオンプレミス データ ソースに対してクエリを実行します。
5. ゲートウェイは結果を暗号化し、Azure Service Bus 経由で送り返します。
6. Power BI サービスは結果を受信し、レポートを表示するか、更新を完了します。

このアーキテクチャは、ゲートウェイがインターネットからの受信接続を決して受信しないことを意味します。すべての送信通信が開始されるため、ファイアウォールの構成が大幅に簡素化されます。

パーソナル ゲートウェイと標準 (エンタープライズ) ゲートウェイ

運用環境の展開には、標準 (エンタープライズ) ゲートウェイを使用します。パーソナル ゲートウェイは、独自のデータ ソースを使用してプロトタイプを作成する個々のユーザーにのみ適しています。

---

インストール

前提条件

ゲートウェイをインストールする前に、ターゲット マシンが次の要件を満たしていることを確認してください。

重要: データベースと同じサーバーにゲートウェイをインストールしないでください。ゲートウェイはリフレッシュ操作中に CPU と RAM をめぐって競合するため、ゲートウェイをデータベースと同じ場所に配置すると、ゲートウェイとデータベースの両方のパフォーマンスが低下する可能性があります。

インストール手順

1. Microsoft の公式ダウンロード ページから最新のゲートウェイ インストーラーをダウンロードします。
2. インストーラーを実行し、エンタープライズ モードの場合は「オンプレミス データ ゲートウェイ (推奨)」を選択します。
3. ライセンス条項に同意し、インストール ディレクトリを選択します。
4. 組織アカウントでサインインします (アカウントは Power BI サービスと同じ Azure AD テナントに存在する必要があります) 5.「このコンピュータに新しいゲートウェイを登録する」を選択します。
5. ゲートウェイに名前を付けます (例: 実稼働ゲートウェイ、ニューヨーク、ノード 1 の場合は「PROD-GW-NY-01」など、わかりやすい名前を使用します)。
6. 回復キーを設定します --- これをパスワード マネージャーまたはキー コンテナーに安全に保存します。クラスターノードを追加するか、ゲートウェイを回復するために必要になります。
7. インストールを完了します

ゲートウェイ サービスは自動的に開始され、デフォルトでは「NT SERVICE\PBIEgwService」アカウントで実行されます。

サービスアカウントの変更

デフォルトでは、ゲートウェイはローカル サービス アカウントとして実行されます。ネットワーク リソース (ファイル共有、Windows 認証を使用したドメイン参加データベース) にアクセスするには、サービス アカウントをドメイン アカウントに変更する必要がある場合があります。

1. Windows サービス (services.msc) を開きます。 2.「オンプレミス データ ゲートウェイ サービス」を検索します。
2. 右クリックして「プロパティ」を選択し、「ログオン」タブを選択します。
3. 「このアカウント」を選択し、ドメイン認証情報を入力します。
4. サービスを再起動します

サービス アカウントに次の権限を付与します。

• 「サービスとしてログオン」ローカル ポリシー
• クエリに必要なデータ ソースへの読み取りアクセス
• データソースサーバーへのネットワークアクセス

---

高可用性のためのゲートウェイ クラスタリング

単一のゲートウェイは単一障害点になります。マシンがダウンすると、スケジュールされたすべての更新と DirectQuery 接続が失敗します。ゲートウェイ クラスタリングは、リクエストを複数のノードに分散することでこの問題を解決します。

クラスターの作成

1. 同じインストール手順に従って、2 台目のマシンにゲートウェイをインストールします
2. 「新しいゲートウェイを登録する」ステップで、「既存のゲートウェイ クラスターに追加する」を選択します。
3. ドロップダウンから既存のゲートウェイ名を選択します。
4. 回復キーを入力します (最初のノードに使用したのと同じキー)
5. インストールを完了します

現在、クラスターには 2 つのノードがあります。リクエストは正常なノード全体に分散されます。

負荷分散構成

デフォルトでは、ゲートウェイ クラスターはリクエストをランダムに分散します。負荷分散を構成できます。

ラウンドロビン: リクエストをすべてのノードに均等に分散します。同一のハードウェアを備えたクラスターに最適です。

重み付けルーティング: より多くのリクエストをより強力なノードに送信します。 Power BI 管理ポータルのゲートウェイ設定で構成します。

フェイルオーバーのみ: すべてのリクエストはプライマリ ノードに送られます。セカンダリ ノードは、プライマリが使用できない場合にのみアクティブになります。スタンバイ サーバーを使用したコスト重視の導入に最適です。

推奨されるクラスター トポロジ

運用環境の場合、ECOSIRE は少なくとも 2 つのゲートウェイ ノードを推奨:

両方のノードが同時にダウンしないように、メンテナンス時間をずらしてください。 Windows 更新プログラム、.NET パッチ、ゲートウェイ バージョンのアップグレードは、一度に 1 つのノードに適用する必要があります。

---

データソース構成

データソースの追加

ゲートウェイをインストールした後、Power BI サービスでデータ ソースを構成します。

1. [設定] (歯車アイコン) に移動し、[ゲートウェイの管理] に移動します。
2. ゲートウェイクラスターを選択します 3.「データソースの追加」をクリックします。
3. データ ソースの種類を選択します (SQL Server、PostgreSQL、Oracle、ODBC など)。
4. 接続の詳細 (サーバー名、データベース名) を入力します。
5. 認証方法を選択します (Windows、Basic、OAuth2)
6. 認証情報を入力します
7. 接続をテストする

サポートされるデータ ソースの種類

標準ゲートウェイは、80 を超えるデータ ソース タイプをサポートします。 Power BI で最も一般的なもの:

資格情報の暗号化

データ ソースの資格情報は回復キーを使用して暗号化され、ゲートウェイ マシンにローカルに保存されます。これらは平文でクラウドに送信されることはありません。クラスター ノードを追加すると、共有回復キーを使用して資格情報が同期されます。

重要: 回復キーを紛失し、すべてのゲートウェイ ノードに障害が発生した場合は、次のことを行う必要があります。

1. 新しい回復キーを使用して新しいゲートウェイをインストールします
2. すべてのデータソースと資格情報を再構成します。
3. Power BI サービスのすべてのデータセットを新しいゲートウェイに再マップします

回復キーを Azure Key Vault または組織のパスワード マネージャーに保存します。

接続プーリング

リレーショナル データベース (SQL Server、PostgreSQL、Oracle) の場合、接続プーリングを有効にして、更新操作全体でデータベース接続を再利用します。

ゲートウェイ構成ファイル (Microsoft.PowerBI.EnterpriseGateway.exe.config) 内:

<setting name="PoolConnections" serializeAs="String">
    <value>True</value>
</setting>
<setting name="MinPoolSize" serializeAs="String">
    <value>2</value>
</setting>
<setting name="MaxPoolSize" serializeAs="String">
    <value>20</value>
</setting>

接続プーリングにより、特に多数の同時ユーザーによる DirectQuery ワークロード中に、クエリごとに新しいデータベース接続を確立するオーバーヘッドが軽減されます。

---

スケジュールされた更新構成

スケジュールされた更新の設定

データセットを Power BI サービスに公開した後:

1. データセット設定に移動します
2. [ゲートウェイ接続] で、ゲートウェイと構成されたデータ ソースを選択します。
3. [スケジュールされた更新] で、トグルを有効にします。
4. 更新頻度を設定します (毎日、毎週、または特定の時間)
5. タイムゾーンを設定する
6. オプションで失敗通知を設定する

リフレッシュ頻度の制限

Windows のリフレッシュとスタガリング

すべてのデータセットの更新を同時にスケジュールしないでください。ゲートウェイの CPU とメモリは有限であり、同時更新によりリソースが競合します。

ベスト プラクティス: 利用可能なウィンドウ全体でデータセットをずらす更新スケジュールを作成します。

重要なデータセットは最初に更新され、後の更新で問題が発生した場合でも確実に完了します。

増分リフレッシュとゲートウェイ

増分リフレッシュにより、ゲートウェイ経由で処理されるデータ量が大幅に削減されます。データセット全体を更新するのではなく、新しい行と変更された行のみがフェッチされます。これは、完全な更新に数時間かかり、ゲートウェイ リソースを過剰に消費する大規模なデータセットの場合に特に重要です。

Power BI Desktop で増分更新を構成し (RangeStart/RangeEnd パラメーターのアプローチを参照)、サービスに公開します。ゲートウェイはパラメータ化されたクエリを自動的に処理します。

---

ファイアウォールとプロキシの構成

必要なアウトバウンド接続

ゲートウェイには、以下への送信 HTTPS (TCP 443) アクセスが必要です。

ファイアウォールでワイルドカード ドメインではなく明示的な IP 許可リストが必要な場合は、Microsoft の Azure IP Ranges JSON ファイル (毎週更新) を使用して、リージョン内の Azure Service Bus の IP 範囲を見つけます。

プロキシサーバーの構成

ゲートウェイが企業プロキシを介してルーティングする必要がある場合:

1. Microsoft.PowerBI.EnterpriseGateway.exe.config を編集します
2. <system.net> セクションにプロキシ構成を追加します。

<system.net>
  <defaultProxy useDefaultCredentials="true">
    <proxy proxyaddress="http://proxy.company.com:8080"
           bypassonlocal="true" />
  </defaultProxy>
</system.net>

3. ゲートウェイサービスを再起動します

プロキシが特定の資格情報 (パススルー Windows 認証ではない) を必要とする場合は、プロキシ PAC ファイルを使用するか、追加の認証なしでゲートウェイのサービス アカウントを許可するようにプロキシを構成する必要がある場合があります。

TLS 構成

ゲートウェイには TLS 1.2 が必要です。環境でまだ TLS 1.0 または 1.1 が有効になっている場合、ゲートウェイはデフォルトで TLS 1.2 を使用します。ただし、データ ソース サーバーが TLS 1.0 のみをサポートしている場合、接続は失敗します。

Windows レジストリで TLS 1.2 が有効になっていることを確認します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client
  Enabled = 1 (DWORD)
  DisabledByDefault = 0 (DWORD)

---

監視とロギング

ゲートウェイログ

ゲートウェイは詳細なログを以下に書き込みます。

C:\Users\<ServiceAccount>\AppData\Local\Microsoft\On-premises data gateway\

主要なログ ファイル:

追加のログを有効にする

トラブルシューティングのために、詳細ログを有効にします。

1. ゲートウェイ構成アプリケーションを開きます 2.「診断」に移動します。 3.「追加のログ記録」を有効にする
2. 問題を再現する
3. [ログのエクスポート] ボタンを使用してログをエクスポートします (すべてのログ ファイルの ZIP が作成されます)。
4. トラブルシューティング後に追加のログを無効にします (大量のログが生成されます)。

パフォーマンスカウンター

ゲートウェイは、「オンプレミス データ ゲートウェイ」カテゴリの下で Windows パフォーマンス カウンターを公開します。

Windows パフォーマンス モニターまたは監視ツール (Prometheus、Datadog、Azure Monitor) をセットアップして、これらのカウンターを追跡し、しきい値について警告します。

Power BI 管理ポータルの監視

Power BI 管理ポータルで:

1. 管理ポータルに移動し、次にゲートウェイ管理に移動します。
2. すべてのゲートウェイ、そのステータス (オンライン/オフライン)、およびバージョンを表示します。
3. データソースの使用状況統計を参照する
4. リフレッシュの成功/失敗率を監視する

ゲートウェイのオフライン イベントと更新の失敗に関する電子メール通知を構成します。

---

パフォーマンスのチューニング

ハードウェアの適切なサイジング

ゲートウェイのパフォーマンスは主に次の制約を受けます。

1. CPU — クエリ解析、データ圧縮、暗号化用
2. RAM — 中間クエリ結果を保持するため
3. ネットワーク — Azure Service Bus へのデータ転送用

サイズのガイドライン:

マッシュアップ エンジンの設定

ゲートウェイは、データ変換に Power Query (マッシュアップ) エンジンを使用します。ゲートウェイ アプリで設定します。

最大同時クエリ数: デフォルトは、CPU コアの数に 2 を乗じた値です。I/O バウンドのワークロード (遅いデータ ソースを待機している場合) の場合は増加します。 CPU に依存するワークロード (重い変換) が減少します。

クエリごとのメモリ制限: デフォルトは制限なしです。単一の暴走クエリが利用可能な RAM をすべて消費するのを防ぐために、制限 (2 GB など) を設定します。

ネットワークの最適化

データ ソースの近くにゲートウェイを配置します。 ゲートウェイとデータ ソース間のネットワーク待機時間は、更新ごとのクエリ数で乗算されます。データベースと同じデータセンターにゲートウェイを配置すると、遅延が最小限に抑えられます。

Azure への近さに基づいてゲートウェイを見つけないでください。 Azure Service Bus 接続は、単一の永続的な TCP 接続です。 Azure への待ち時間は初期接続セットアップに影響しますが、クエリ スループットには影響しません。

有線接続を使用してください。 運用ゲートウェイを Wi-Fi 上で実行しないでください。断続的な接続により、更新エラーが発生します。

ソースでのクエリの最適化

ゲートウェイのパフォーマンスを向上させる最も簡単な方法は、ゲートウェイが実行するクエリを最適化することです。

• テーブル全体をインポートする代わりにカスタム SQL クエリを使用します (データ量を削減します)。
• WHERE 句と JOIN で使用される列にデータベース インデックスを作成します。
• 複雑なデータ モデルの事前結合と事前集計を備えたビューを使用する
• Power Query でクエリの折りたたみを有効にして、変換をデータベースにプッシュします
• 増分リフレッシュを実装して、リフレッシュ サイクルあたりのデータ量を削減します。

---

一般的なエラーのトラブルシューティング

「ゲートウェイに到達できません」

原因: ゲートウェイ サービスが停止しているか、マシンがダウンしているか、Azure へのネットワーク接続がブロックされています。

解決策:

1. ゲートウェイ Windows サービス (services.msc) が実行されているかどうかを確認します。
2. *.servicebus.windows.net へのアウトバウンド HTTPS が許可されていることを確認します
3. 企業プロキシの背後にある場合はプロキシ設定を確認します。
4. ゲートウェイ マシンがインターネットに接続されていることを確認します。
5. ゲートウェイのバージョンが古いかどうかを確認します (自動更新はサイレントに失敗する可能性があります)。

「データソースに接続できません」

原因: 不正な資格情報、データ ソースへのネットワーク接続、またはドライバーの問題。

解決策:

1. ゲートウェイ構成アプリで接続をテストします (「診断」、「接続のテスト」)。
2. データ ソース サーバーがゲートウェイ マシンから到達可能であることを確認します (ポートへの ping、telnet)。
3. 認証情報が正しいこと、アカウントがロックされたり期限切れになっていないことを確認します。
4. Oracle および SAP の場合、必要なクライアント ライブラリがゲートウェイ マシンにインストールされていることを確認します。
5. データ ソースのファイアウォールがゲートウェイの IP からの接続を許可していることを確認します。

「オンプレミス データ ゲートウェイの更新に時間がかかりすぎます」

原因: 大規模なデータセット、遅いクエリ、不十分なゲートウェイ リソース、またはネットワークのボトルネック。

解決策:

1.増分更新を有効にしてデータ量を削減します 2. SQL クエリの最適化 (インデックスの追加、列の削減、行のフィルター) 3. リフレッシュ中にゲートウェイ マシンの CPU と RAM の使用状況を確認する 4. 同時負荷を軽減するために更新スケジュールをずらす 5. 負荷分散のために 2 番目のゲートウェイ ノードの追加を検討する

「データ ソースの資格情報が無効です」

原因: パスワードが変更されたか、アカウントがロックされているか、Kerberos 委任が正しく構成されていません。

解決策:

1. Power BI サービスに資格情報を再入力します (データセット設定、ゲートウェイ接続)。
2. Kerberos による Windows 認証を使用している場合は、以下を確認してください。

• ゲートウェイ サービス アカウントには、Active Directory での委任権限があります。
• SPN がデータ ソースに対して正しく構成されている
• KDC (ドメイン コントローラー) はゲートウェイから到達可能です

「ゲートウェイのバージョンが古いです」

原因: 自動更新が失敗したか、無効になっていました。

解決策:

1. Microsoft から最新のゲートウェイ インストーラーをダウンロードします。
2. 既存のゲートウェイ マシンでインストーラーを実行します (インプレースでアップグレードされます)。
3. クラスターの場合は、アップグレードの間に間隔をあけて、一度に 1 つのノードをアップグレードします。
4. アップグレード後に Power BI 管理ポータルでゲートウェイのバージョンを確認します。

---

セキュリティのベストプラクティス

最小特権の原則

• ゲートウェイ サービス アカウントにはデータ ソースへの読み取り専用アクセスが必要です
• ドメイン管理者アカウントまたはデータベース管理者アカウントを使用しないでください。
• セキュリティ ポリシーで必要な場合は、データ ソースの種類ごとに専用のサービス アカウントを作成します
• サービス アカウントのパスワードを定期的にローテーションし、ゲートウェイ データ ソース構成を更新します。

回復キーの管理

回復キーは、ローカルに保存されているすべての認証情報を暗号化します。データベースのマスター キーと同じように慎重に扱ってください。

• Azure Key Vault またはエンタープライズ パスワード マネージャーに保存する
• 回復キーにアクセスできるユーザーを文書化する
• キー管理ポリシーに回復キーのローテーションを含めます。
• 回復キーを使用してバックアップからゲートウェイを復元して回復をテストします。

ネットワークのセグメンテーション

以下に到達できるネットワーク セグメントにゲートウェイを配置します。

• データソースサーバー (SQL Server、PostgreSQL、Oracle など)
• Azure Service Bus (アウトバウンド HTTPS)
• Azure AD (アウトバウンド HTTPS)

他のすべての受信トラフィックと送信トラフィックをブロックします。ゲートウェイはソースからの受信接続を必要としません。

監査証跡

ゲートウェイ マシンで Windows セキュリティ監査を有効にして、以下を追跡します。

• サービス アカウントのログオン イベント
• ゲートウェイ構成の変更
• データソースのアクセスパターン

これらのイベントを SIEM (Splunk、Sentinel、Datadog) に転送して集中監視します。

---

移行とアップグレードのシナリオ

新しいゲートウェイ マシンへの移行

1. 新しいマシンにゲートウェイをインストールします
2. 登録中に、「既存のゲートウェイを移行、復元、または引き継ぐ」を選択します。
3. 元のゲートウェイからの回復キーを入力します。
4. 新しいマシンはすべてのデータ ソース構成と資格情報を継承します。
5. すべてのデータ ソースが Power BI 管理ポータルに接続されているように表示されていることを確認します。
6. IP ベースのファイアウォール ルールを更新して、新しいマシンの IP を含めます。
7. 古いゲートウェイ マシンを廃止する

ゲートウェイのバージョンのアップグレード

Microsoft はゲートウェイのアップデートを毎月リリースします。ベストプラクティス:

• 変更の事前通知については、ゲートウェイのリリース ノートを購読してください。
• 最初に非運用ゲートウェイ クラスターで新しいバージョンをテストします
• 実稼働クラスターの場合は、24 時間の間隔をあけて一度に 1 つのノードをアップグレードします。
• 各ノードのアップグレード後に更新の成功率を確認する
• 新しいバージョンが検証されるまで、前のバージョンに少なくとも 1 つのノードを保持します。

ゲートウェイはクラスター内で N-1 バージョンの互換性をサポートします --- ノードはまったく同じバージョンを実行する必要はありません。

---

よくある質問

仮想マシンにゲートウェイをインストールできますか?

はい。ゲートウェイは、Azure VM、AWS EC2、オンプレミスの Hyper-V または VMware を含む物理マシンおよび仮想マシン上で実行されます。 Azure VM の場合は、自己管理型ゲートウェイの必要性を完全に排除する VNet データ ゲートウェイ (Premium 容量のプレビュー段階) の使用を検討してください。オンプレミス VM の場合は、VM に専用の (共有ではない) CPU および RAM リソースがあること、およびハイパーバイザーがリソースを積極的にオーバーコミットしないことを確認してください。

1 つのゲートウェイでサポートできるデータ ソースの数は何ですか?

ゲートウェイごとのデータ ソースの数に厳密な制限はありません。実際には、ゲートウェイは通常 50 ～ 100 のデータ ソースを問題なくサポートします。制限要因は、構成されたデータ ソースの数ではなく、更新ウィンドウ中の同時クエリの負荷です。更新時間が低下している場合は、追加のゲートウェイ インストールを作成するのではなく、クラスター ノードを追加してください。

ゲートウェイは Linux をサポートしていますか?

いいえ。オンプレミス データ ゲートウェイには Windows (Server 2016 以降) が必要です。データ ソースが Linux で実行されている場合は、Linux データ ソース サーバーにネットワーク アクセスできる Windows マシンにゲートウェイをインストールします。ゲートウェイはネットワーク経由でデータ ソースに接続します。ゲートウェイはデータ ソースと同じオペレーティング システム上で実行する必要はありません。

クラスタ内の両方のゲートウェイ ノードが同時にオフラインになった場合はどうなりますか?

スケジュールされた更新はすべて失敗し、すべての DirectQuery 接続でエラーが返されます。 Power BI サービスはオフライン状態を検出し、ゲートウェイ管理者 (構成されている場合) に通知を送信します。キャッシュされたデータを使用するレポート (インポート モード) では、最後に正常に更新されたデータが引き続き表示されます。少なくとも 1 つのノードがオンラインに戻ると、保留中のリフレッシュ要求が自動的に処理されます。このシナリオを防ぐには、メンテナンス期間をずらして、クラスター ノードを別の物理インフラストラクチャに配置します。

ゲートウェイはリアルタイム ストリーミング データを処理できますか?

ゲートウェイは、ストリーミングではなく、クエリと応答のパターン向けに設計されています。リアルタイム データの場合は、Power BI ストリーミング データセット (ゲートウェイを完全にバイパスする)、Azure Stream Analytics、または Power BI リアルタイム ダッシュボードを備えた Azure Event Hubs を検討してください。ゲートウェイは、オンプレミス データベースにほぼリアルタイムでアクセスするための DirectQuery をサポートしていますが、レポートの対話ごとに、継続的なデータ ストリームを受信するのではなく、新しいクエリがトリガーされます。