パフォーマンス効率のベストプラクティス

この記事では、 パフォーマンス効率のベストプラクティスを 、次のセクションに記載されているアーキテクチャの原則別にまとめています。

1.垂直スケーリング、水平スケーリング、および線形スケーラビリティ

ベスト プラクティスに入る前に、分散コンピューティングの概念 (水平スケーリング、垂直スケーリング、線形スケーラビリティ) をいくつか見てみましょう。

• 垂直スケーリング : 1 台のマシン (通常は CPU、メモリ、GPU) にリソースを追加または削除することで、垂直方向にスケーリングします。 これは通常、ワークロードを停止し、より大きなマシンに移動して再起動することを意味します。 垂直方向のスケーリングには限界があり、より大きなマシンがない場合や、次に大きなマシンの価格が法外な場合があります。
• 水平スケーリング : 分散システムにノードを追加または削除して、水平方向にスケーリングします。 垂直スケーリングの限界に達した場合、ソリューションは水平方向にスケーリングすることです: 分散コンピューティングは、複数のマシンを持つシステム ( クラスターと呼ばれます) を使用してワークロードを実行します。 これを可能にするには、Databricks Data Intelligence Platform、Apache Spark、Photon のエンジンでサポートされているように、ワークロードを並列実行用に準備する必要があることを理解することが重要です。 これにより、複数の安価なマシンをより大きなコンピューティングシステムにまとめることができます。 より多くのコンピュート リソースが必要な場合、水平スケーリングはクラスターにノードを追加し、不要になったノードを削除します。 技術的には制限はありませんが (Spark エンジンは負荷分散の複雑な部分を行います)、ノードの数が多いと管理の複雑さが増します。
• 線形スケーラビリティ 、つまり、システムにリソースを追加すると、スループットと使用されるリソースの関係は線形になります。 これは、並列タスクが独立している場合にのみ可能です。 そうでない場合は、1 つのノード セットの中間結果を、さらに計算するためにクラスター内の別のノード セットで必要になります。 このノード間のデータ交換には、ネットワークを介して結果を 1 つのノード セットから別のノード セットに転送することが含まれ、これにはかなりの時間がかかります。 一般に、分散コンピューティングには、データの配布と交換を管理するためのオーバーヘッドがあります。 その結果、1 つのノードで分析できる小さなデータ セットのワークロードは、分散システムで実行するとさらに遅くなる可能性があります。 Databricks Data Intelligence Platform は、ワークロードの固有のニーズを満たすための柔軟なコンピューティング (シングルノードおよび分散) を提供します。

2. サーバレスアーキテクチャを使用する

Use サーバレス コンピュート

Data Intelligence Platform 上の サーバレス コンピュート を使用すると、コンピュート レイヤーは顧客の DatabricksDatabricksアカウントで実行されます。このサービスはフルマネージドであり、 Databricksによって継続的に強化されています。 これにより、顧客は使用した分だけ支払うだけでなく、生産性が向上します。

• クラウド管理者は、クォータの調整、ネットワーク リソースの作成と保守、請求ソースへの接続など、複雑なクラウド環境を管理する必要がなくなりました。 低レベルのクラウドコンポーネントを管理する代わりに、価値の高いプロジェクトに時間を集中させることができます。
• ユーザーは、クラスター、起動待ち時間、クエリの同時実行性の向上というメリットを享受できます。

は、 ワークロード用のサーバレスSQLDatabricksウェアハウス を提供します: ワークスペース管理者は、インスタントSQLSQL コンピュートを有効にし、 によって管理されるサーバレス ウェアハウスを作成できます。Databricks元の Databricks SQL ウェアハウスで通常行うのと同じように、Databricks SQL クエリと共に使用します。 サーバレス コンピュートは、 SQLウェアハウスの起動時間が非常に速く、インフラストラクチャは Databricksによって管理および最適化されています。

エンタープライズ グレードのモデルサービング サービスを使用する

Mosaic AI Model Serving は、AI モデルをデプロイ、管理、クエリするための統一されたインターフェイスを提供します。 提供する各モデルは、Web アプリケーションまたはクライアント アプリケーションに統合できる REST API として使用できます。

モデルサービングは、モデルをデプロイするための高可用性と低遅延のサービスを提供します。 このサービスは、需要の変化に合わせて自動的にスケールアップまたはスケールダウンするため、インフラストラクチャのコストを節約しながら、レイテンシのパフォーマンスを最適化します。 この機能はサーバレス コンピュートを使用します。

3. パフォーマンスのためのワークロードの設計

データ取り込みとアクセスパターンを理解する

パフォーマンスの観点から見ると、データ アクセス パターン ("集計とポイント アクセス" や "スキャンと検索" など) は、データ サイズによって動作が異なります。 スキャンクエリには大きなファイルの方が効率的で、特定の行を見つけるために読み取るデータが少なくて済むため、検索には小さなファイルの方が適しています。

インジェストパターンでは、DML ステートメントを使用するのが一般的です。 DML ステートメントは、データがクラスタ化されている場合に最もパフォーマンスを発揮し、データのセクションを簡単に分離できます。 インジェスト中は、データをクラスター化して分離可能に保つことが重要です: 自然な時間の並べ替え順序を維持し、インジェスト ターゲット テーブルにできるだけ多くのフィルターを適用することを検討してください。 追加専用および上書きインジェスト ワークロードの場合、比較的安価な操作であるため、考慮すべきことはあまりありません。

インジェストとアクセスのパターンは、多くの場合、明らかなデータレイアウトとクラスタリングを指しています。 そうでない場合は、ビジネスにとって何がより重要であるかを決定し、その目標をよりよく達成する方法に焦点を当てます。

有益な場合は並列計算を使用してください

価値実現までの時間は、データを操作する際の重要なディメンションです。 多くのユースケースは 1 台のマシンに簡単に実装できますが (小さなデータ、少数の単純な計算ステップ)、大規模なデータセットを処理する必要がある、複雑なアルゴリズムのために実行時間が長い、または何百回も何千回も繰り返す必要があるユースケースもよくあります。

Databricksプラットフォームのクラスター環境は、これらのワークロードを効率的に分散するのに最適な環境です。クラスターのすべてのノード間で SQL クエリを自動的に並列化し、 Python と Scala が同じことを行うためのライブラリを提供します。 内部的には、Apache Spark エンジンと Photon エンジンがクエリを分析し、並列実行の最適な方法を決定し、回復力のある方法で分散実行を管理します。

バッチ タスクと同様に、 構造化ストリーミング はストリーミング ジョブをクラスター全体に分散して、最高のパフォーマンスを実現します。

並列計算を使用する最も簡単な方法の 1 つは 、DLT を使用することです。ジョブのタスクと依存関係を SQL または Pythonで宣言すると、DLT が実行計画、効率的なインフラストラクチャ設定、ジョブ実行、およびモニタリングを処理します。

data scientistsの場合、 Pandasは、Pythonプログラミング言語用の使いやすいデータ構造とデータ分析ツールを提供するPythonパッケージです。ただし、 Pandas は Big にスケールアウトしません。 PandasAPIon は、Spark Pandasで動作する同等の を提供することでAPIs Apache Sparkこのギャップを埋めます。

さらに、このプラットフォームには、標準の機械学習ライブラリ MLlibに並列化された機械学習アルゴリズムが付属しています。 すぐに使用できるマルチGPUの使用をサポートします。 ディープラーニングは、 DeepSpeed Distributor または TorchDistributorを使用して並列化することもできます。

実行のチェーン全体を分析

ほとんどのパイプラインまたは消費パターンには、システムのチェーンが含まれます。 たとえば、BI ツールでは、パフォーマンスはいくつかの要因の影響を受けます。

• BI ツール自体。
• BI ツールと SQL エンジンを接続するコネクタ。
• BI ツールがクエリを送信する SQL エンジン。

クラス最高のパフォーマンスを得るには、チェーン全体を考慮し、最高のパフォーマンスを得るために選択/調整する必要があります。

より大きなクラスターを優先する

大規模なクラスターを計画します (特にワークロードが線形にスケーリングされる場合)。 この場合、ワークロードに大規模なクラスターを使用することは、小規模なクラスターを使用することよりもコストがかかることはありません。 ただ、その方が速いだけです。 重要なのは、ワークロードの期間中、クラスターをレンタルすることです。 したがって、2 つのワーカー クラスターをスピンアップし、1 時間かかる場合、それらのワーカーに対して 1 時間分の料金を支払うことになります。 同様に、4 人のワーカー クラスターをスピンアップし、30 分しかかからない場合 (ここで線形スケーラビリティの出番です)、コストは同じです。 コストが非常に柔軟な SLAの主な推進力である場合、オートスケール クラスターは通常最も安価ですが、必ずしも最速であるとは限りません。

注記

サーバレス コンピュートでは、大規模なクラスターはクラスターを自動的に管理するため、推奨する必要はありません。

ネイティブの Spark 操作を使用する

ユーザー定義関数 (UDF) は、Spark SQL の機能を拡張する優れた方法です。 ただし、ネイティブ関数が存在する場合は、Python または Scala UDF を使用しないでください。

• Spark SQL
• PySpark

理由：

• Python と Spark の間でデータを転送するには、シリアル化が必要です。 これにより、クエリの速度が大幅に低下します。
• プラットフォームに既に存在する機能を実装してテストする作業の増加。

ネイティブ関数が見つからず、Python UDF として実装する必要がある場合は、 Pandas UDF を使用します。 Apache Arrow は、 Spark と Python の間でデータが効率的に行き来することを保証します。

ネイティブ プラットフォーム エンジンを使用する

PhotonDatabricksは、データ取り込み、ETL 、ストリーミング、データサイエンス、インタラクティブクエリなど、低コストで高速なクエリパフォーマンスをデータレイク上で直接提供する エンジンです。Photon は Apache Spark APIsと互換性があるため、コードの変更やロックインは不要で、電源を入れるのと同じくらい簡単に開始できます。

Photonは、既存のSQLおよびデータフレーム API呼び出しをより高速に実行し、ワークロードあたりの総コストを削減する高性能ランタイムの一部です。 Photon は、 Databricks SQL ウェアハウスの デフォルト によって使用されます。

ハードウェアとワークロードの種類を理解する

すべてのクラウドVMが同じように作成されているわけではありません。 クラウドプロバイダーが提供するさまざまなマシンファミリーは、すべて問題となるほど異なります。 RAMとコアという明らかな違いと、プロセッサの種類と世代、ネットワーク帯域幅の保証、ローカルの高速ストレージとローカルディスクとリモートディスクのどちらかという微妙な違いがあります。 「スポット」市場にも違いがあります。 ワークロードに最適な VM の種類を決定する前に、これらを理解する必要があります。

注記

サーバレス コンピュートでは、クラスターは自動的に管理されるため、これは必須ではありません。

キャッシングを使用する

キャッシングは、頻繁にアクセスされるデータをより高速なメディアに保存するため、元のデータソースにアクセスする場合と比較して、データの取得に必要な時間を短縮できます。 これにより、レイテンシーが短縮され、応答時間が短縮され、アプリケーションの全体的なパフォーマンスとユーザーエクスペリエンスが大幅に向上します。 キャッシングは、元のデータソースへのリクエスト数を最小限に抑えることで、ネットワークトラフィックとデータ転送のコストを削減します。 この効率の向上は、外部の APIs データベースや従量課金制のデータベースに依存するアプリケーションにとって特に有益です。 これにより、負荷をシステム全体に均等に分散し、ボトルネックや潜在的なダウンタイムを防ぐことができます。

Databricks で使用できるキャッシュには、いくつかの種類があります。 各タイプの特性は次のとおりです。

• ディスクキャッシュを使用する

  ディスク キャッシュ (旧称 "Delta キャッシュ") は、仮想マシンのローカル ディスク (SSDなど) にリモート データのコピーを格納します。さまざまなクエリのパフォーマンスを向上させることができますが、任意のサブクエリの結果を格納するために使用することはできません。 ディスクキャッシュは、データファイルが作成または削除されたことを自動的に検出し、それに応じてその内容を更新します。 ディスク キャッシュの使用に推奨される (そして最も簡単な) 方法は、クラスターを構成するときに、 SSD ボリュームを持つワーカーの種類を選択することです。 このようなワーカーは、ディスク キャッシュに対して有効化され、構成されています。

• Spark キャッシングの回避

  Spark キャッシュ (.persist() と .unpersist()を使用) には、任意のサブクエリ データの結果と、Parquet 以外の形式 (CSV、JSON、ORC など) で格納されたデータを格納できます。ただし、クエリの間違った場所で使用すると、すべてのメモリが消費され、クエリの速度が大幅に低下する可能性があります。 経験則として、影響がどのようなものになるかを正確に把握していない限り、 Spark キャッシングは避けてください 。

• クエリ結果キャッシュ

  ウェアハウスを介したすべてのクエリ のクエリ結果の クラスターごとのキャッシュ。SQLクエリ結果のキャッシュを活用するには、 = NOW()などの述語を使用しないなど、決定論的なクエリに焦点を当てます。 クエリが決定論的であり、基になるデータが Delta 形式で変更されていない場合、ウェアハウス SQLクエリ結果キャッシュから直接結果を返します。

• Databricks SQL UI キャッシュ

  すべてのクエリとレガシ ダッシュボードの結果のユーザーごとのキャッシュは、 Databricks SQL UI に出力されます。

コンパクションを使用する

Delta Lake on Databricks は、テーブルからクエリを読み取る速度を向上させることができます。 1 つの方法は、小さなファイルを大きなファイルにまとめることです。 コンパクションをトリガーするには、OPTIMIZE コマンドを実行します。 「データファイルレイアウトの最適化」を参照してください。

Delta Lake には、書き込みと OPTIMIZE 操作のターゲット ファイル サイズを自動的に構成するオプションが用意されています。 Databricks は、これらの設定の多くを自動的に調整し、ファイルを適切なサイズにすることでテーブルのパフォーマンスを自動的に向上させる機能を有効にします。

• 自動圧縮 では、Delta テーブル パーティション内の小さなファイルを結合して、小さなファイルの問題を自動的に減らします。 自動圧縮は、テーブルへの書き込みが成功し、書き込みを実行したクラスターで同期的に実行された後に発生します。 自動圧縮では、以前に最適化されていないファイルのみが最適化されます。
• 最適化された書き込みにより、 データが書き込まれるときにファイルサイズが改善され、テーブルに対する後続の読み取りにメリットがあります。 最適化された書き込みは、各パーティションに書き込まれる小さなファイルの数を減らすため、パーティション化されたテーブルに最も効果的です。

詳細については、「 データ ファイル サイズを制御するための Delta Lake の構成 」を参照してください。

データスキップを使用する

データのスキップは、クエリの条件を満たさないデータをスキップすることで、クエリのパフォーマンスを大幅に向上させることができます。 これにより、読み取って処理する必要のあるデータの量が減り、クエリの実行時間が短縮されます。

これを実現するために、 Delta テーブルにデータを書き込むときに、データ スキップ情報が自動的に収集されます (デフォルト Delta Lake on Databricks は、テーブル スキーマで定義された最初の 32 列の統計を収集します)。 Databricks 上の Delta Lake は、クエリ時にこの情報 (最小値と最大値) を使用して、クエリを高速化します。 「Delta Lake のデータのスキップ」を参照してください。

データスキップには、次の手法を適用できます。

• Z-Ordering、同じファイルセット内の関連情報を併置する手法。このコローカリティは、Delta Lake のデータ スキップ アルゴリズムによって Databricks で自動的に使用されます。 この動作により、Delta Lake が読み取る必要があるデータ量が大幅に減少します。

• リキッドクラスタリング は、データレイアウトの決定を簡素化し、クエリのパフォーマンスを最適化します。 パーティション分割と Z-Ordering は時間の経過とともに置き換えられます。 Databricks では、すべての新しいデルタ テーブルに対してリキッドクラスタリングをお勧めします。 リキッドクラスタリングは、既存のデータを書き換えることなくクラスタリングキーを再定義する柔軟性を提供し、時間の経過とともに分析ニーズに合わせてデータレイアウトを進化させることができます。 Databricks では、すべての新しいデルタ テーブルに対してリキッドクラスタリングをお勧めします。

  次の特性を持つテーブルは、リキッドクラスタリングの恩恵を受けます。

  • カーディナリティの高い列でフィルター処理されます。
  • データ分布が大幅に歪んでいる。
  • これは急速に成長し、メンテナンスとチューニングの作業が必要です。
  • 並列書き込み要求を使用します。
  • アクセスパターンは時間の経過とともに変化します。
  • 一般的なパーティション キーでは、パーティションが多すぎたり少なすぎたりしてテーブルを離れる可能性があります。

詳細と手法については 、「Databricks、Spark、Delta Lake のワークロードを最適化するための総合ガイド」を参照してください。

Enable forecast的最適化 for Delta Lake

予測的最適化 により、Delta Databricksテーブルのメンテナンス操作を手動で管理する必要がなくなります。予測的最適化を有効にすると、 Databricks はメンテナンス操作の恩恵を受けるテーブルを自動的に特定し、ユーザーに代わって実行します。 保守操作は必要な場合にのみ実行されるため、保守操作の不要な実行と、パフォーマンスの追跡とトラブルシューティングに関連する負担の両方が不要になります。

過剰なパーティション分割を避ける

以前は、 パーティション分割 がデータをスキップする最も一般的な方法でした。 ただし、パーティション分割は静的であり、ファイルシステム階層として現れます。 アクセスパターンは時間の経過とともに変化するため、パーティションを簡単に変更する方法はありません。 多くの場合、パーティション分割は過剰なパーティション分割、つまり、パーティションが多すぎてファイルが小さすぎるため、クエリのパフォーマンスが低下します。

Databricks では、サイズが 1 TB 未満のテーブルをパーティション分割しないこと、および各パーティションのデータが少なくとも 1 GB であると予想される場合にのみ列でパーティション分割することをお勧めします。

それまでの間、パーティション分割よりも優れた選択肢は、 Z-Ordering または新しい リキッドクラスタリング (上記を参照)です。

ジョインのパフォーマンスを最適化する

• 範囲結合の最適化 を検討します。

  範囲結合は、2 つのリレーションが間隔内のポイントまたは間隔のオーバーラップ条件を使用して結合されるときに発生します。 Databricks Runtime で の範囲結合の最適化 のサポートにより、クエリのパフォーマンスが大幅に向上しますが、慎重な手動チューニングが必要です。

• アダプティブ クエリ実行 を使用します。

  アダプティブ クエリ実行 (AQE) は、クエリの実行中に発生するクエリの再最適化です。 これには 4 つの主要な機能があります。

  • ソート・マージ結合をブロードキャスト・ハッシュ結合に動的に変更します。
  • シャッフル交換後にパーティションを動的に結合します。
  • ソート、マージ結合、シャッフルハッシュ結合でスキューを動的に処理します。
  • 空のリレーションを動的に検出して伝播します。

  AQE は有効のままにしておくことをお勧めします。 異なる機能を 別々に構成できます。

詳細については 、Databricks、Spark、Delta Lake のワークロードを最適化するための包括的なガイドを参照してください。

分析テーブルを実行してテーブル統計を収集

ANALYZE TABLE ステートメントは、指定したスキーマ内のテーブルに関する統計を収集します。これらの統計は、 クエリ オプティマイザー によって使用され、最適なクエリ プランを生成したり、正しい結合の種類を選択したり、ハッシュ結合で正しいビルド側を選択したり、多方向結合で結合順序を調整したりします。

予測的最適化 自動的に ANALYZE (Public Preview), a command for collecting statistics, on Unity Catalog マネージドテーブル. Databricks では、すべての Unity Catalog マネージドテーブルに対して予測的最適化を有効にして、データのメンテナンスを簡素化し、ストレージ コストを削減することをお勧めします。 Unity Catalog マネージドテーブルの予測的最適化を参照してください。

4. 開発の範囲内でパフォーマンステストを実行する

本番運用データを代表するデータでの検証

本番運用データ(読み取り専用)または類似データに対するパフォーマンステストの実行 類似のデータを使用する場合、ボリューム、ファイルレイアウト、データスキューなどの特性は、パフォーマンスに大きな影響を与えるため、本番運用データと類似させる必要があります。

リソースの温暖化を検討する

クエリとデータ形式に関係なく、クラスターの最初のクエリは、後続のクエリよりも常に遅くなります。 これは、すべての異なるサブシステムが起動し、必要なすべてのデータを読み取っているためです。 予温は、パフォーマンステスト結果に大きな影響を与えます。

• Prewarm クラスター : クラスター リソースは、複数のレイヤーで初期化する必要があります。 クラスターを事前にウォームすることができます: Databricksプールは、アイドル状態ですぐに使用できるインスタンスのセットです。これらのアイドル状態のインスタンスを使用してクラスターノードを作成すると、クラスターの起動時間とオートスケールの時間が短縮されます。
• プリウォームキャッシュ : キャッシュがセットアップの一部である場合、最初の実行でデータがキャッシュ内にあることが確認され、後続のジョブが高速化されます。 キャッシュは、 特定のクエリを実行して キャッシュを初期化することで事前ウォーム化できます (たとえば、クラスターの再起動後)。 これにより、最初のいくつかのクエリのパフォーマンスが大幅に向上します。

そのため、さまざまなシナリオの動作を理解するために、プレウォーミングを使用した場合と使用しない場合の最初の実行と、その後の実行のパフォーマンスをテストします。

ボトルネックの特定

ボトルネックとは、本番運用の負荷が増加するにつれて全体的なパフォーマンスが低下する可能性のあるワークロードの領域です。 設計時にこれらを特定し、より高いワークロードに対してテストすることで、本番運用でワークロードを安定させることができます。

5. パフォーマンスを監視する

クエリのパフォーマンスを監視する

モニタリング クエリのパフォーマンスは、リソースがさまざまなクエリによってどのように使用されているかを理解するのに役立ちます。 実行速度が遅いクエリを特定できるため、システムのパフォーマンスのボトルネックを特定できます。 また、システムリソースを大量に消費し、不安定性やダウンタイムにつながる可能性のあるクエリを特定することもできます。 この情報は、リソースの割り当てを最適化し、無駄を減らし、リソースを効率的に使用するのに役立ちます。

Databricks Data Intelligence Platform には、さまざまなモニタリング機能 (オペレーショナル エクセレンス - モニタリング、アラート、ログの設定を参照) があり、その一部はパフォーマンス モニタリングに使用できます。

• クエリ プロファイル : クエリ プロファイル 機能を使用して、クエリ実行中のパフォーマンスのボトルネックをトラブルシューティングします。 各クエリタスクと、費やした時間、処理された行数、使用メモリなどの関連メトリクスを視覚化します。
• SQLウェアハウス モニタリング : ライブ統計、ピーク クエリ数グラフ、稼働中のクラスター グラフ、クエリ履歴テーブルを表示して、SQLウェアハウスを監視します

ストリーミングワークロードの監視

ストリーミング モニタリングを使用すると、データを分析し、問題が発生したときに検出して、システムのパフォーマンスと動作に関するリアルタイム 知見を得ることができます。 ストリーミングデータを分析することで、トレンド、パターン、最適化の機会を特定できます。 これにより、システムの微調整、リソース使用率の向上、およびコストの削減が可能になります。

ストリーミング クエリの場合は、 で組み込み構造化ストリーミング モニタリング Spark UIApacheを使用するか、 Sparkストリーミング Query Listener インターフェイスを使用してメトリクスを外部サービスにプッシュします。

ジョブのパフォーマンスを監視する

ジョブ モニタリング は、 Databricks ジョブの問題 (失敗、遅延、パフォーマンスのボトルネックなど) を特定して対処するのに役立ちます。 ジョブ モニタリングは、ジョブのパフォーマンスに関する知見を提供し、リソース使用率の最適化、無駄の削減、全体的な効率の向上を可能にします。