パフォーマンス最適化のベストプラクティス

Databricksのパフォーマンス最適化について説明します。

Transcript

1. ©2024 Databricks Inc. — All rights reserved パフォーマンス最適化の ベストプラクティス 1 Databricks
2. ©2024 Databricks Inc. — All rights reserved 高性能な分析環境の構築 ファイルのレ イアウト コードの 最適化 クラスターの サイジング 微調整 最適化 基礎
3. ©2024 Databricks Inc. — All rights reserved 基礎のデザイン 3
4. ©2024 Databricks Inc. — All rights reserved 一般的なパフォーマンスのボトルネック 4 ボトルネック 詳細 小さなファイル問題 • 大量の小規模ファイルの一覧やメタデータオペレーションは高コストになる場合があります。 • クラウドストレージの I/O制限によるスロットリングにつながる場合があります。 データの偏り • 大規模データの偏りは、単一のエグゼキューターで大量処理につながる場合があります。 • 読み込むデータに偏りがなくても、特定の変換処理がメモリー内のデータの偏りにつながる場合がありま す。 過度の処理 • 従来のデータレイクプラットフォームは、多くの場合データセットやパーティション全体の 再書き込みを必要とします。 リソース競合 • アドホックやBIクエリーとして、大規模な取り込み処理と ETLジョブを同時に実行すると、クラスターの分離な しにはクエリーパフォーマンスの低下につながります。 ビッグデータやMPPシステムで遭遇 集約前 都市で集約
5. ©2024 Databricks Inc. — All rights reserved 小さなファイル問題の回避 5 Data Lakeではこの一般的なパフォーマンスの問題を自動で対応します ▪ 大量の小さなファイルは読み込みの オーバーヘッドを大きく引き上げます ▪ 少量の大規模ファイルは読み込みの並列性を低下さ せます ▪ 過度のパーティショニングは一般的な問題です ▪ DatabricksではDelta Lakeテーブルのサイズを 自動でチューニングします ▪ Databricksでは、auto-optimizeによって自動で小 規模ファイルをコンパクトにします
6. ©2024 Databricks Inc. — All rights reserved データ偏りへの対応 6 データの偏りは不可避ですが、Databricksでは自動でこれに対応します ▪ MPPシステムでは、一部のワーカーで大量の処 理を行うことになるので、パフォーマンスに大き なインパクトをもたらします ▪ 多くのクラウドDWでは、データの偏りを 解決するために手動、オフラインの再分配を必 要とします ▪ Adaptive Query Executionによって、Sparkは 大規模なパーティションを小規模でサイズの 揃ったパーティションに自動でブレーク ダウンします Partition 6 (150 MB) Partition 1 (50 MB) Partition 2 (50 MB) Partition 3 (50 MB) Partition 4 (50 MB) Partition 5 (90 MB) Partition 6 (150 MB) Partition 1 (50 MB) Partition 2 (50 MB) Partition 3 (50 MB) Partition 4 (50 MB) Partition 6-A (50 MB) Partition 6-B (50 MB) Partition 6-C (50 MB) Partition 5 (90 MB) Partition 5-A (45 MB) Partition 5-B (45 MB) Partition 1 (50 MB) Partition 2 (50 MB) Partition 3 (50 MB) Partition 4 (50 MB)
7. ©2023 Databricks Inc. — All rights reserved そこで… リキッドクラスタリング - パーティションよさらば • 高速 ◦ 適切にチューニングされパーティショニングされたテーブルよりも 高速な書き込みと同等の読み込み性能 • 自己チューニング ◦ 過度のパーティショニングやパーティショニング不足を回避 • インクリメンタル ◦ 新規データに対して自動の部分的なクラスタリング • 偏りへの耐性 ◦ 一貫性のあるファイルサイズを生成し、書き込み量の増幅を抑制 • 柔軟 ◦ クラスタリング列を変更したい？問題ありません！
8. ©2023 Databricks Inc. — All rights reserved リキッドクラスタリング より高速に、より安価に 取り込みとクラスタリング 読み込み性能 ポイントクエリーでスキャンされたバイト数 少ないほど優れています Hiveスタイルの パーティショニング ZORDER リキッド クラスタリング より簡単に クラスタリングは簡単に なります: • カーディナリティの 心配は不要です • リキッド クラスタリングの進化 書き込みの増加(バイト) 時間 ZORDER Liquid 時間
9. ©2023 Databricks Inc. — All rights reserved リキッドクラスタリングのメリットが 出るシナリオ • 頻繁に高いカーディナリティでフィルタリングされるテーブル • データ分布に大きな偏りのあるテーブル • 急速に成長し、メンテナンスやチューニングの工数を要するテーブル • 同時書き込み要件のあるテーブル • 時間とともにアクセスパターンが変化するテーブル • 典型的なパーティションキーが多すぎる/少なすぎるパーティションを生成し てしまうテーブル
10. ©2023 Databricks Inc. — Confidential & Subject to Change 取り込み時間によるクラスタリング パーティショニングやZ-Orderなしにすぐに利用可能なデータスキッピング 000.csv T + 5 T + 3 T + 1 T + 0 001.csv 997.csv 998.csv 999.csv すべてのDeltaオペレーション(DML 取り込み、メンテナンス)における 自然なクラスタリングを保持 19倍 優れたクエリー性能をすぐに 利用可能 環境: 日付で自然に並べられたデータを持つセールステーブルを格納 高いほど優れている 15 AWS GCP ステータス GA GA
11. ©2024 Databricks Inc. — All rights reserved テーブルの統計情報 コストベースのオプティマイザーがベストな結果を出せるようにテーブルの 統計情報を最新に維持します • テーブルのすべてのカラムの統計情報を収集 • Adaptive Query Executionをサポート • 適切なjoinタイプの選択 • hash-joinにおける適切なビルドサイドの選択 • マルチウェイjoinにおけるjoin順序の調整 ANALYZE TABLE mytable COMPUTE STATISTICS FOR ALL COLUMNS 16
12. ©2024 Databricks Inc. — All rights reserved インクリメンタル処理 17 ACIDトランザクションとCDCでデータセット全体の再処理を回避 ▪ 従来のデータレイクシステムでファイルを操作する際、追記、ファイル全体の上 書きや削除しかできません。 ▪ ACIDトランザクションによって、Delta LakeではDWシステムと同じようにレコー ドレベルでのINSERT、UPDATE、DELETE、UPSERT を可能に します。 ▪ 変更点のみを処理するCDCアーキテクチャパターンに移行することで、全体的 な処理時間を劇的に削減します。
13. ©2024 Databricks Inc. — All rights reserved 基本的な推奨事項 18 1. 自動チューニングのメリットを享受するためにDatabricksとDelta Lakeを活用しましょう: a. 小さなファイル問題を回避するためのファイルサイズの自動チューニングとauto-optimize b. AQEによる自動での偏りへの対応 c. 自然なソートオーダーの保持によって、1TBより小さいパーティニングテーブルが不要に 2. リキッドクラスタリングとクエリーのフィルターでよく使われるカラムに対するクラスターによるデータス キッピングを活用しましょう(週次のOPTIMIZEジョブ)。 3. 特にjoinで使用されるカラムのテーブル統計情報を収集しましょう(週次のANALYZEジョブ)。 4. CDCアーキテクチャに移行し、変更データのみを処理するようにするために、Delta LakeのSQL DML機能を活用しましょう。 5. リソース競合を回避するために、分離されたジョブクラスターとSQLウェアハウスを活用 しましょう。
14. ©2024 Databricks Inc. — All rights reserved コードの最適化 20
15. ©2024 Databricks Inc. — All rights reserved コード最適化の推奨事項 21 1. プロダクションのジョブでは、ファイルの読み書きを伴うアクションを 起動するオペレーションは避けましょう。これには、count()、display() collect()が含まれます。 2. シングルスレッドのpython/pandas/Scalaを用いるなど、ドライバーノードにす べての計算処理を強制するオペレーションを避けましょう。pandas関数を分散 処理するためにPandas API on Sparkを使いましょう。 3. 行ごとに処理を行うPythonのUDFは避けましょう。代わりに、ネイティブの PySpark関数かベクトル化UDFであるPandas UDFを使いましょう。 4. RDDではなくデータフレームかデータセットを使いましょう。RDDでは コストベースのオプティマイザーを活用できません。
16. ©2024 Databricks Inc. — All rights reserved ファインチューニング: 適切なクラスターの選択 24
17. ©2024 Databricks Inc. — All rights reserved クラスターのタイプ ▪ 分析やアドホックなDE & DSの開発 ▪ 共有クラスターがおすすめですが、 チームやワークロードでの分離が ベストプラクティスとなります。 ▪ 稼働済みのクラスターを常に利用 (APIやスケジュール処理を含む ) ▪ より高価です ALL PURPOSE COMPUTE ▪ ジョブのために作成され、処理が 完了すると停止する揮発性の クラスター ▪ 事前のスケジュールあるいは API 経由での作成 ▪ シングルユーザー ▪ 処理の分離やデバッグに最適 ▪ プロダクションあるいは定期的なワー クロード ▪ 低コスト JOBS COMPUTE ▪ アドホックなSQL分析やBIにおける高 い同時実行性を提供 ▪ Photon有効化 ▪ アドホックのSQL分析では、ワーク ロード固有の別個のウェアハウス ではなく、共有ウェアハウスが推奨で す。 ▪ 即座に起動するサーバレスを利用 できます。 SQL WAREHOUSE
18. ©2024 Databricks Inc. — All rights reserved オートスケーリング ▪ ワークロードに基づきクラスターのサイズを動的に変更します ▪ 固定サイズやプロビジョン不足のクラスターよりも高速な処理 ▪ 固定サイズのクラスターよりも全体的なコストを削減 ▪ ワーカー数の範囲設定にはいくつかの実験が必要です ユースケース オートスケーリングの範囲 アドホックの利用やビジネス分析 広い範囲 プロダクションのバッチジョブ 不要あるいは上限値のバッファ ストリーミング Delta Live Tablesで利用可能
19. ©2024 Databricks Inc. — All rights reserved スポットインスタンス ▪ スペアのVMインスタンスを安いマーケット価格で利用するために スポットインスタンスを活用しましょう ▪ アドホック/共有クラスターに最適 ▪ ミッションクリティカルなSLAを持つジョブでは非推奨 ▪ ドライバーでは決して使わないでください！ ▪ 様々なユースケースにクラスターを仕立てるためにオンデマンドと (カスタムスポット価格の)スポットインスタンスを組み合わせましょう SLA スポットかオンデマンドか ミッションクリティカル ではないジョブ ドライバーはオンデマンド ワーカーはスポット 厳しいSLAのあるワークフロー オンデマンドにフォールバックする スポットインスタンスを使用
20. ©2022 Databricks Inc. — All rights reserved フリートクラスター ▪ 可用性の改善: ▪ インスタンス取得エラーの最小化 ▪ スポット削除の最小化 ▪ Spot Placement Scoreを用いた自動AZ選択の改善 ▪ コスト削減 ▪ スポットへのアクセス改善はTCOを削減します ▪ クラスター作成をシンプルに: ▪ コンピュートタイプとサイズを選択するだけでよく、インスタンス タイプの選択が不要になります
21. ©2024 Databricks Inc. — All rights reserved AWS Gravitonインスタンスのサポート (ARM) お客様のワークロードのコストパフォーマンスを最適化 インスタンスファミリー例 m6g.xlarge m6g.2xlarge m6g.4xlarge m6g.8xlarge インスタンスファミリー例 i3.xlarge i3.2xlarge i3.4xlarge i3.8xlarge Non-Graviton AFTER Graviton 20-30%のパフォーマンス の改善 40-50%のコストパフォーマンス の改善 • Databricksのコストパフォーマンスを改善し、お客様のTCOを削減 • ARM上のPhotonランタイムをサポート
22. ©2024 Databricks Inc. — All rights reserved 31 ワークロードごとのクラスターのお勧め - AWS VM/インスタンス Deltaキャッシュ ワークロードタイプ チップ SSDタイプ 推奨ユースケース メモ m6gd No General Purpose ARM (Graviton) NVMe * (利用できる場合)ほとんどの ユースケース * シングルスレッドのML、hyperopt i3/r5dと同じ性能で多く の場合で70%の コスト削減 c6g No Compute Optimized ARM (Graviton) EBS * joinや集計がない c6gd No Compute Optimized ARM (Graviton) NVMe * joinや集計を伴う小規模/列が少ない データ r6gd Yes Memory Optimized ARM (Graviton) NVMe * 列の多いテーブルやjoin/集計 * Spark ML * ステートフルなストリーミング * Pandas UDF m5gdから切り替え --> ディスクに溢れたらr5gd ▪ 使えるならGravitonを使いましょう ▪ 使えるなら最新世代のVMを使いましょう ▪ General purposeから始めて他のオプションをテストしましょう
23. ©2024 Databricks Inc. — All rights reserved 32 ワークロードごとのクラスターのお勧め - Azure VM/インスタンス Delta キャッシュ ワークロードタイプ チップ SSDタイプ クラウド 推奨ユースケース メモ Dadsv5 Yes General Purpose AMD Premium SSD Azure * (利用できる場合)ほとんどの ユースケース * シングルスレッドのML、hyperopt Fsv2 No Compute Optimized Intel Premium SSD Azure * joinや集計がない * joinや集計を伴う小規模/列が少な いデータ Eadsv5 Yes Memory Optimized AMD Premium SSD Azure * 列の多いテーブルやjoin/集計 * Spark ML * ステートフルなストリーミング * Pandas UDF Dadsv5から切り替え --> ディスクが溢れた らEadsv5 ▪ 使えるならAMD on Azureを使いましょう ▪ 使えるなら最新世代のVMを使いましょう ▪ General purposeから始めて他のオプションをテストしましょう ▪ Deltaキャッシュが有効化されるものを使いましょう
24. ©2024 Databricks Inc. — All rights reserved 33 ワークロードごとのクラスターのお勧め - GCP VM/インスタンス Deltaキャッシュ ワークロードタイプ チップ SSDタイプ クラウド 推奨ユースケース メモ n2d-standard Yes General Purpose AMD SSD GCP * ほとんどのユースケース * シングルスレッドのML、hyperopt n2-high-cpu No Compute Optimized AMD SSD GCP * joinや集計がない n2d-high-cpu No Compute Optimized AMD SSD GCP * joinや集計を伴う小規模/列が少な いデータ n2d-high-mem Yes Memory Optimized AMD SSD GCP * 列の多いテーブルやjoin/集計 * Spark ML * ステートフルなストリーミング * Pandas UDF n2d-standardから切 り替え --> ディスクが 溢れたら n2-highmem ▪ 使えるならAMDを使いましょう ▪ 使えるなら最新世代のVMを使いましょう ▪ General purposeから始めて他のオプションをテストしましょう ▪ Deltaキャッシュが有効化されるものを使いましょう
25. ©2022 Databricks Inc. — All rights reserved コンピュートコストの削減 ▪ ETL利用者はコンピュートコストを最大40%削減 高速なクエリーパフォーマンス ▪ 他のクラウドデータウェアハウスと比較して、 最大12倍のコストパフォーマンスを持つモダンな ハードウェア向けに開発 コード変更が不要 ▪ 探索、ETL、大規模データ、小規模データ、 低レーテンシー、高い同時実行性、バッチ、 ストリーミングを行うSpark API 様々な言語をサポート ▪ SQL、Python、Scala、R、Javaをサポート チューニングやセットアップなしの世界記録のクエリーエンジンを活用 Photon Databricksがデータウェアハウスの パフォーマンスにおける 公式世界記録を達成
26. ©2022 Databricks Inc. — All rights reserved データ型 オペレーター ✅ Byte/Short/Int/Long ✅ Boolean ✅ String/Binary ✅ Decimal ✅ Float/Double ✅ Date/Timestamp ✅ Struct ✅ Array ✅ Map ✅ Scan, Filter, Project ✅ Hash Aggregate/Join/Shuffle ✅ Nested-Loop Join ✅ Null-Aware Anti Join ✅ Union, Expand, ScalarSubquery ✅ Delta/Parquet Write Sink ✅ Sort ✅ Window Function RDD Scan エクスプレッション ✅ Comparison / Logic ✅ Arithmetic / Math (大部分) ✅ Conditional (IF, CASE, etc.) ✅ String (共通的なもの) ✅ Casts ✅ Aggregates(最も共通なもの) ✅ Date/Timestamp Scala UDFs Photonのカバレッジ (DBR 11.3)
27. ©2024 Databricks Inc. — All rights reserved アーキテクチャの検討事項 36 リソース競合を避けるためのクラスター & ウェアハウスの分離 1. 揮発性のジョブクラスター ◦ Jobs - 取り込み + ETLオブのために分離されたコンピュートは当該ワークロードに 対してサイジング/最適化することができ、スケジュールで実行 されます ◦ ジョブ実行中のみ課金が発生します 2. 共有の開発クラスター ◦ All-purpose - チームが活発に開発している際にのみ利用し、必要なリソースが追 加されるようにするための自動停止とオートスケーリング ◦ 完全なデータセットのサブセットで開発、テストすることを推奨します 3. アドホック分析のための共有SQLウェアハウス ◦ SQL warehouse - チームが活発にクエリーを実行している際に利用し、必要なリ ソーが追加されるようにするための自動停止とオートスケーリング ◦ 即座に起動し、アイドル時間でシャットダウンするサーバレスを利用可能 4. BIレポートのための別個のSQLウェアハウス ◦ BI要件に合わせてサイジングし、他のプロセスとの競合を回避 注意: 多くの他のビッグデータ、データウェアハウスプラットフォームは モノリシックであり、面倒な手動のワークロード管理を必要とします Databricks AWS Reference Architecture
28. ©2024 Databricks Inc. — All rights reserved ファインチューニング: 適切なウェアハウスの選 択 37
29. ©2022 Databricks Inc. — All rights reserved Databricks SQLのサーバレスコンピュート 即時起動、柔軟 & 管理不要のコンピュート • クイックにセットアップ、即時起動で柔軟な SQLウェアハウス - ストレージからの分離 - Photon有効化 • ベストなコストパフォーマンス(最大12倍)のために インスタンスタイプと設定を自動で決定 • 高い同時実行性 ビルトインの自動ロードバランス • インテリジェントなワークロード管理、クラウド ストレージからの高速な読み込み • 即座に起動、優れた可用性、サーバレスで全体の コストを平均で40%削減 GA GA Coming Soon
30. ©2022 Databricks Inc. — All rights reserved AIが提供するシンプルさ インテリジェントなワークロード管理 新たなクエリーを即座に実行するために優先度を 上げるか、実行中のクエリーを阻害することなしに 実行できるようにするために スケールアップするかを判断するために、ワーク ロードの履歴を継続的に学習します。 混合ワークロードのクエリーレーテンシー (秒) 低いほど優れています
31. ©2022 Databricks Inc. — All rights reserved Predictive I/O インデックスなしに選択的なクエリーを SELECT * from events where user_id = 123 経済的 高速 容易 データのコピーを作成する必要が 無かったり、高コストなインデックスを作る必 要が無かったとしたら？ システムがあなたのクエリーで どのデータが必要で、次に何を必要とす るのかを学習するとしたら？ あなたのクエリーが調整なしに高速 だとしたら？
32. ©2022 Databricks Inc. — All rights reserved New: Predictive I/O for Reads パフォーマンスの手動のチューニングを排除するためにMLを活用 $$$ 高価な インデックス 選択的クエリーのパフォーマンス (秒) 低いほど優れています • 手動チューニングの必要なしに データの場所を三角法で計測 (PARTITION BY, CLUSTER BY) • Predictive I/Oでは、レイクハウスを データウェアハウスにするために、大規 模AI/MLシステムを構築してきた Databricksの数年に渡る経験を 活用しています
33. ©2022 Databricks Inc. — All rights reserved MERGE 2-6x 高速 現実のワークロード DELETE 2-10x 高速 現実のワークロード 最大10倍高速なMERGE、UPDATE、DELETE New: Predictive I/O for Updates • 通常、CDWはデータの大部分に対して再 書き込みを繰り返し行います。 • Predictive I/Oは書き込みを劇的に削減 しつつも、読み込み性能を劣化しないよう にするために、インテリジェントDeletion Vectorを適用します。 42 プ レ ビ ュ ー
34. ©2024 Databricks Inc. — All rights reserved クラスター/ウェアハウス最適化の推奨事項 43 1. DS & DEの開発: オートスケールと自動停止を有効化した all-purposeコンピュート、データのサブセットで 開発 & テスト 2. 取り込み & ETLジョブ: オートスケールが有効化され、ジョブの SLAに適したサイズのjobsコンピュート 3. アドホックのSQL分析: (サーバレス) SQLウェアハウス、オートスケールと自動停止を有効化 4. BIレポート: BIのSLAに適したサイズの別個のSQLウェアハウス 5. ベストプラクティス: a. ワーカーノードでスポットインスタンスを活用しましょう b. スポットの可用性を高めるためにフリートクラスターや auto-AZを活用しましょう c. 可能な場合にはGravitonインスタンスを使いましょう d. 可能な場合には最新のLTSのDatabricksランタイムを使いましょう e. 適用できる際にはベストなTCOのためのPhotonを使いましょう f. 最新世代のVMのgeneral purposeからスタートし、memory/compute optimizedをテストしましょう g. アイドル時間の削減とAIで強化された最適化のためにサーバレス SQLウェアハウスを使いましょう
35. ©2024 Databricks Inc. — All rights reserved Roadmap 44
36. ©2022 Databricks Inc. — Confidential & Subject to Change Confidential & Subject to Change 45 The following is intended to outline our general product direction. We constantly innovate with our customers, and the specifics may change. Do not share this information without explicit permission from Databricks. "This information is provided to outline Databricks’ general product direction and is for informational purposes only. Customers who purchase Databricks services should make their purchase decisions relying solely upon services, features, and functions that are currently available. Unreleased features or functionality described in forward-looking statements are subject to change at Databricks discretion and may not be delivered as planned or at all"
37. ©2023 Databricks Inc. — Confidential & Subject to Change Fleet (vCPU) Clusters • Abstracting away instance type selection • Simplifies cluster creation: users describe resource needs rather than pick instances • Optimized selection of spot instances to reduce interruptions • Instance capacity aware for improved availability AWS Azure GCP Current Status Private Preview Public Preview by end of Q4 TBD TBD
38. ©2023 Databricks Inc. — Confidential & Subject to Change Auto Tune for UC Managed Tables Complete table management for best performance out of the box Problem For optimal performance tables require periodic tuning operations. Solution Unity Catalog will auto tune tables. • For tables under 1TB, no tuning required (4x faster) • Auto Tune takes care of the data layout HOW? • Optimized Writes for Unpartitioned Tables • Asynchronous Auto Compaction • Ingestion Time Clustering AWS GCP Status GA In Q4 GA In Q4 BEFORE AUTO TUNE AFTER AUTO TUNE
39. ©2023 Databricks Inc. — Confidential & Subject to Change Faster Updates with Photon + Deletion Vectors Up to 10x speed-up in MERGE, UPDATE & DELETE queries w/ Photon Solution • Using Deletion Vectors, Photon avoids the need to rewrite files during MERGE, UPDATE & DELETE, speeding up updates by up to 10x. Problem • Updates to tables are expensive because of rewrites AWS GCP Q1 - Gated Public Preview Q1 - Gated Public Preview
40. ©2024 Databricks Inc. — All rights reserved DS&DEクラスターの サイジング 52
41. ©2024 Databricks Inc. — All rights reserved ▪ それぞれのワークロードにおけるSLA要件に基づいて選択します ▪ 最初はタスク(ファイル)の数に基づいてサイズを決め、あとで調整します ▪ タスクの数の見当をつけるために小規模なクラスターでジョブを実行 します ▪ ベースのサイジングではコア数の2-3倍のタスクを使用します ▪ 1タスク = 1ファイル。 Databricksはauto-optimizeによって最適なサイズでファイルを書き出しま す。 クラスターサイジングのスタート地点 経験則 53
42. ©2024 Databricks Inc. — All rights reserved ▪ 予想したよりもジョブに時間を要する、あるいは、全く完了しない場合、それはディスク溢れに よるものである場合があります。 ▪ Spark UIでディスク溢れを特定できます (下をご覧ください) ▪ インメモリでオペレーションを実行するのに十分なメモリがない場合、ディスクの読み書きが必要とな ります。これは非常に高コストなオペレーションです。 ▪ メモリー量を増加することでディスク溢れを解決します。 ▪ 他のプラットフォームでは、データの偏りによってディスク溢れが起きることがあります。 AQE(デフォルトで有効化)によってDatabricksではデータの偏りに自動で対応します。 ▪ インメモリのシャッフルパーティションを調整することで、ディスク溢れを回避できる場合が あります。Databricksでは適切なシャッフルパーティション数を自動で特定することができます: spark.sql.shuffle.partitions = Auto ディスク溢れの回避 55
43. ©2024 Databricks Inc. — All rights reserved クラスターのサイジング - ETL、分析ワークロード ▪ 計算資源に制限を受けていますか？ ▪ CPU使用量をチェック (クラスターのメトリクス) ▪ 高速にする唯一の方法はコアの追加です ▪ ネットワークに制限を受けていますか？ ▪ 重い計算ステップのまえの高いスパイクをチェック ▪ シャッフルを削減するためにより大きく/少ないマシンを使用 ▪ 高速なリモート読み込みのためにSSD搭載インスタンスを使用 ▪ 大量に溢れていますか？ ▪ Spark SQLタブで溢れをチェック (シャッフル前の集計は一般的な溢れ の原因です) ▪ メモリー最適化インスタンスを使用
44. ©2024 Databricks Inc. — All rights reserved SQLウェアハウスの サイジング 57
45. ©2024 Databricks Inc. — All rights reserved SQLウェアハウスのサイジング
46. ©2022 Databricks Inc. — All rights reserved ウェアハウスのサイズの説明 Only use when SLA is not important Good starting point for BI style workloads Step up as you need lower latency or intensive workloads Cluster size 2X-Small X-Small Small Medium Large X-Large 2X-Large 3X-Large 4X-Large Azure Driver size E8ds_v4 E8ds_v4 E16ds_v4 E32ds_v4 E32ds_v4 E64ds_v4 E64ds_v4 E64ds_v4 E64ds_v4 AWS Driver size i3.2xlarge i3.2xlarge i3.4xlarge i3.8xlarge i3.8xlarge i3.16xlarge i3.16xlarge i3.16xlarge i3.16xlarge Worker count 1 2 4 8 16 32 64 128 256 vCPU 8 8 16 32 32 64 64 64 64 Memory (GiB) 61 61 122 244 244 488 488 488 488 Instance Storage (GB) 1 x 1900 NVMe 1 x 1900 NVMe 2 x 1900 NVMe 4 x 1900 NVMe 4 x 1900 NVMe 8 x 1900 NVMe 8 x 1900 NVMe 8 x 1900 NVMe 8 x 1900 NVMe Networking Bandwidth (Gbps) Up to 10 Up to 10 Up to 10 10 10 25 25 25 25 vCPU 8 8 16 32 32 64 64 64 64 Memory: GiB 64 64 128 256 256 504 504 504 504 Max NICs 4 4 8 8 8 8 8 8 8 Networking Bandwidth (Gbps) 4 4 8 16 16 30 30 30 30 The instance size of all workers is i3.2xlarge on AWS The instance size of all workers is Standard_E8ds_v4 on Azure On Azure each driver and worker has 2 128 GB Standard LRS managed disks attached. Attached disks are charged hourly.
47. ©2024 Databricks Inc. — All rights reserved SQLウェアハウスのオートスケール ▪ 同時実行処理に対応するために、それぞれのDatabricks SQLウェアハウスの同時 実行クエリー数は10に制限されています。 ▪ Databricks SQLウェアハウスでオートスケールを有効化すると、ウェアハウスは同 時実行数に応じて自動でクラスターを追加し、不要になったら クラスターを削減します。
48. ©2024 Databricks Inc. — All rights reserved 1TB / 10B+ rows X-Large+ 500GB / 1B rows X-Large 250GB / 100M+ rows Large 100GB / 10M+ rows Medium 10GB / ~M rows Small ウェアハウスのサイジング 1. どのくらいのコストと時間のクエリーなのかの見当をつけます 標準のクラスターのサイジングと同じように通常のランタイムを使います。 以下に助けとなるメトリクスを示します: • 500GB, 3.6B行、小規模テーブルのjoin + 大量のフィルター => Lクラスターで50秒 • 100GB, すべての700M行が600Mとjoin + group by + order => Lクラスターで60秒 • 50GB, 60M行が1Mとjoin => Lクラスターで8秒 • 10GB => 72M行で多数のbroadcast joinとフィルター => Sクラスターで2秒 “場合によります”がここからスタートできます… 61
49. ©2024 Databricks Inc. — All rights reserved ウェアハウスのサイジング 2. あなたのSLAに応じた個々のクラスターサイズを考えます • レーテンシーはクラスターあたりのクエリー数とほぼ線形関係にあります • 例: うまく分散された1つのクエリーが10秒かかる場合、10クエリーの 実行に100秒要します 62
50. ©2024 Databricks Inc. — All rights reserved ウェアハウスのサイジング 3. ユーザー / 同時実行リクエストの数でスケールします • 大きなクラスターは大規模なクエリーを高速に処理し、スループットを 改善します • クエリーの処理時間が約5秒以下の場合、大きなクラスターはより多くの同時実 行クエリーを捌くための助けにはなりません • 10-15の同時実行クエリーに対して1台のクラスターでうまく動作すると 考えましょう 63
51. ©2024 Databricks Inc. — All rights reserved 現時点では、“scheduled requests”はクラスター起動を待っている唯一のリクエストに見え、 あるクラスターは並列で約10のリクエストだけを処理することができますが、現時点はすべて“running”と 表示されています - キューはありません ウェアハウスの監視