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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

©2024 Databricks Inc. — All rights reserved 一般的なパフォーマンスのボトルネック 4 ボトルネック詳細小さなファイル問題 ● 大量の小規模ファイルの一覧やメタデータオペレーションは高コストになる場合があります。 ● クラウドストレージの I/O制限によるスロットリングにつながる場合があります。データの偏り ● 大規模データの偏りは、単一のエグゼキューターで大量処理につながる場合があります。 ● 読み込むデータに偏りがなくても、特定の変換処理がメモリー内のデータの偏りにつながる場合があります。過度の処理 ● 従来のデータレイクプラットフォームは、多くの場合データセットやパーティション全体の再書き込みを必要とします。リソース競合 ● アドホックやBIクエリーとして、大規模な取り込み処理と ETLジョブを同時に実行すると、クラスターの分離なしにはクエリーパフォーマンスの低下につながります。ビッグデータやMPPシステムで遭遇集約前都市で集約

Slide 5

Slide 5 text

©2024 Databricks Inc. — All rights reserved 小さなファイル問題の回避 5 Data Lakeではこの一般的なパフォーマンスの問題を自動で対応します ▪ 大量の小さなファイルは読み込みのオーバーヘッドを大きく引き上げます ▪ 少量の大規模ファイルは読み込みの並列性を低下させます ▪ 過度のパーティショニングは一般的な問題です ▪ DatabricksではDelta Lakeテーブルのサイズを自動でチューニングします ▪ Databricksでは、auto-optimizeによって自動で小規模ファイルをコンパクトにします

Slide 6

Slide 6 text

©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)

Slide 7

Slide 7 text

©2023 Databricks Inc. — All rights reserved そこで… リキッドクラスタリング - パーティションよさらば ● 高速 ○ 適切にチューニングされパーティショニングされたテーブルよりも高速な書き込みと同等の読み込み性能 ● 自己チューニング ○ 過度のパーティショニングやパーティショニング不足を回避 ● インクリメンタル ○ 新規データに対して自動の部分的なクラスタリング ● 偏りへの耐性 ○ 一貫性のあるファイルサイズを生成し、書き込み量の増幅を抑制 ● 柔軟 ○ クラスタリング列を変更したい？問題ありません！

Slide 8

Slide 8 text

©2023 Databricks Inc. — All rights reserved リキッドクラスタリングより高速に、より安価に取り込みとクラスタリング読み込み性能ポイントクエリーでスキャンされたバイト数少ないほど優れています Hiveスタイルのパーティショニング ZORDER リキッドクラスタリングより簡単にクラスタリングは簡単になります: ● カーディナリティの心配は不要です ● リキッドクラスタリングの進化書き込みの増加(バイト) 時間 ZORDER Liquid 時間

Slide 9

Slide 9 text

©2023 Databricks Inc. — All rights reserved リキッドクラスタリングのメリットが出るシナリオ ● 頻繁に高いカーディナリティでフィルタリングされるテーブル ● データ分布に大きな偏りのあるテーブル ● 急速に成長し、メンテナンスやチューニングの工数を要するテーブル ● 同時書き込み要件のあるテーブル ● 時間とともにアクセスパターンが変化するテーブル ● 典型的なパーティションキーが多すぎる/少なすぎるパーティションを生成してしまうテーブル

Slide 10

Slide 10 text

©2023 Databricks Inc. — Conﬁdential & 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

Slide 11

Slide 11 text

©2024 Databricks Inc. — All rights reserved テーブルの統計情報コストベースのオプティマイザーがベストな結果を出せるようにテーブルの統計情報を最新に維持します • テーブルのすべてのカラムの統計情報を収集 • Adaptive Query Executionをサポート • 適切なjoinタイプの選択 • hash-joinにおける適切なビルドサイドの選択 • マルチウェイjoinにおけるjoin順序の調整 ANALYZE TABLE mytable COMPUTE STATISTICS FOR ALL COLUMNS 16

Slide 12

Slide 12 text

©2024 Databricks Inc. — All rights reserved インクリメンタル処理 17 ACIDトランザクションとCDCでデータセット全体の再処理を回避 ▪ 従来のデータレイクシステムでファイルを操作する際、追記、ファイル全体の上書きや削除しかできません。 ▪ ACIDトランザクションによって、Delta LakeではDWシステムと同じようにレコードレベルでのINSERT、UPDATE、DELETE、UPSERT を可能にします。 ▪ 変更点のみを処理するCDCアーキテクチャパターンに移行することで、全体的な処理時間を劇的に削減します。

Slide 13

Slide 13 text

©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ウェアハウスを活用しましょう。

Slide 14

Slide 14 text

Slide 15

Slide 15 text

©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ではコストベースのオプティマイザーを活用できません。

Slide 16

Slide 16 text

Slide 17

Slide 17 text

©2024 Databricks Inc. — All rights reserved クラスターのタイプ ▪ 分析やアドホックなDE & DSの開発 ▪ 共有クラスターがおすすめですが、チームやワークロードでの分離がベストプラクティスとなります。 ▪ 稼働済みのクラスターを常に利用 (APIやスケジュール処理を含む ) ▪ より高価です ALL PURPOSE COMPUTE ▪ ジョブのために作成され、処理が完了すると停止する揮発性のクラスター ▪ 事前のスケジュールあるいは API 経由での作成 ▪ シングルユーザー ▪ 処理の分離やデバッグに最適 ▪ プロダクションあるいは定期的なワークロード ▪ 低コスト JOBS COMPUTE ▪ アドホックなSQL分析やBIにおける高い同時実行性を提供 ▪ Photon有効化 ▪ アドホックのSQL分析では、ワークロード固有の別個のウェアハウスではなく、共有ウェアハウスが推奨です。 ▪ 即座に起動するサーバレスを利用できます。 SQL WAREHOUSE

Slide 18

Slide 18 text

©2024 Databricks Inc. — All rights reserved オートスケーリング ▪ ワークロードに基づきクラスターのサイズを動的に変更します ▪ 固定サイズやプロビジョン不足のクラスターよりも高速な処理 ▪ 固定サイズのクラスターよりも全体的なコストを削減 ▪ ワーカー数の範囲設定にはいくつかの実験が必要ですユースケースオートスケーリングの範囲アドホックの利用やビジネス分析広い範囲プロダクションのバッチジョブ不要あるいは上限値のバッファストリーミング Delta Live Tablesで利用可能

Slide 19

Slide 19 text

©2024 Databricks Inc. — All rights reserved スポットインスタンス ▪ スペアのVMインスタンスを安いマーケット価格で利用するためにスポットインスタンスを活用しましょう ▪ アドホック/共有クラスターに最適 ▪ ミッションクリティカルなSLAを持つジョブでは非推奨 ▪ ドライバーでは決して使わないでください！ ▪ 様々なユースケースにクラスターを仕立てるためにオンデマンドと (カスタムスポット価格の)スポットインスタンスを組み合わせましょう SLA スポットかオンデマンドかミッションクリティカルではないジョブドライバーはオンデマンドワーカーはスポット厳しいSLAのあるワークフローオンデマンドにフォールバックするスポットインスタンスを使用

Slide 20

Slide 20 text

©2022 Databricks Inc. — All rights reserved フリートクラスター ▪ 可用性の改善: ▪ インスタンス取得エラーの最小化 ▪ スポット削除の最小化 ▪ Spot Placement Scoreを用いた自動AZ選択の改善 ▪ コスト削減 ▪ スポットへのアクセス改善はTCOを削減します ▪ クラスター作成をシンプルに: ▪ コンピュートタイプとサイズを選択するだけでよく、インスタンスタイプの選択が不要になります

Slide 21

Slide 21 text

©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ランタイムをサポート

Slide 22

Slide 22 text

©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から始めて他のオプションをテストしましょう

Slide 23

Slide 23 text

©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キャッシュが有効化されるものを使いましょう

Slide 24

Slide 24 text

©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キャッシュが有効化されるものを使いましょう

Slide 25

Slide 25 text

©2022 Databricks Inc. — All rights reserved コンピュートコストの削減 ▪ ETL利用者はコンピュートコストを最大40%削減高速なクエリーパフォーマンス ▪ 他のクラウドデータウェアハウスと比較して、最大12倍のコストパフォーマンスを持つモダンなハードウェア向けに開発コード変更が不要 ▪ 探索、ETL、大規模データ、小規模データ、低レーテンシー、高い同時実行性、バッチ、ストリーミングを行うSpark API 様々な言語をサポート ▪ SQL、Python、Scala、R、Javaをサポートチューニングやセットアップなしの世界記録のクエリーエンジンを活用 Photon Databricksがデータウェアハウスのパフォーマンスにおける公式世界記録を達成

Slide 26

Slide 26 text

©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/Shufﬂe ✅ 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)

Slide 27

Slide 27 text

©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

Slide 28

Slide 28 text

Slide 29

Slide 29 text

©2022 Databricks Inc. — All rights reserved Databricks SQLのサーバレスコンピュート即時起動、柔軟 & 管理不要のコンピュート • クイックにセットアップ、即時起動で柔軟な SQLウェアハウス - ストレージからの分離 - Photon有効化 • ベストなコストパフォーマンス(最大12倍)のためにインスタンスタイプと設定を自動で決定 • 高い同時実行性ビルトインの自動ロードバランス • インテリジェントなワークロード管理、クラウドストレージからの高速な読み込み • 即座に起動、優れた可用性、サーバレスで全体のコストを平均で40%削減 GA GA Coming Soon

Slide 30

Slide 30 text

©2022 Databricks Inc. — All rights reserved AIが提供するシンプルさインテリジェントなワークロード管理新たなクエリーを即座に実行するために優先度を上げるか、実行中のクエリーを阻害することなしに実行できるようにするためにスケールアップするかを判断するために、ワークロードの履歴を継続的に学習します。混合ワークロードのクエリーレーテンシー (秒) 低いほど優れています

Slide 31

Slide 31 text

©2022 Databricks Inc. — All rights reserved Predictive I/O インデックスなしに選択的なクエリーを SELECT * from events where user_id = 123 経済的高速容易データのコピーを作成する必要が無かったり、高コストなインデックスを作る必要が無かったとしたら？システムがあなたのクエリーでどのデータが必要で、次に何を必要とするのかを学習するとしたら？あなたのクエリーが調整なしに高速だとしたら？

Slide 32

Slide 32 text

©2022 Databricks Inc. — All rights reserved New: Predictive I/O for Reads パフォーマンスの手動のチューニングを排除するためにMLを活用 $$$ 高価なインデックス選択的クエリーのパフォーマンス (秒) 低いほど優れています • 手動チューニングの必要なしにデータの場所を三角法で計測 (PARTITION BY, CLUSTER BY) • Predictive I/Oでは、レイクハウスをデータウェアハウスにするために、大規模AI/MLシステムを構築してきた Databricksの数年に渡る経験を活用しています

Slide 33

Slide 33 text

©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 プレビュー

Slide 34

Slide 34 text

©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ウェアハウスを使いましょう

Slide 35

Slide 35 text

Slide 36

Slide 36 text

©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"

Slide 37

Slide 37 text

©2023 Databricks Inc. — Conﬁdential & Subject to Change Fleet (vCPU) Clusters • Abstracting away instance type selection • Simpliﬁes 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

Slide 38

Slide 38 text

©2023 Databricks Inc. — Conﬁdential & 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

Slide 39

Slide 39 text

©2023 Databricks Inc. — Conﬁdential & 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 ﬁles 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

Slide 40

Slide 40 text

Slide 41

Slide 41 text

©2024 Databricks Inc. — All rights reserved ▪ それぞれのワークロードにおけるSLA要件に基づいて選択します ▪ 最初はタスク(ファイル)の数に基づいてサイズを決め、あとで調整します ▪ タスクの数の見当をつけるために小規模なクラスターでジョブを実行します ▪ ベースのサイジングではコア数の2-3倍のタスクを使用します ▪ 1タスク = 1ファイル。 Databricksはauto-optimizeによって最適なサイズでファイルを書き出します。クラスターサイジングのスタート地点経験則 53

Slide 42

Slide 42 text

©2024 Databricks Inc. — All rights reserved ▪ 予想したよりもジョブに時間を要する、あるいは、全く完了しない場合、それはディスク溢れによるものである場合があります。 ▪ Spark UIでディスク溢れを特定できます (下をご覧ください) ▪ インメモリでオペレーションを実行するのに十分なメモリがない場合、ディスクの読み書きが必要となります。これは非常に高コストなオペレーションです。 ▪ メモリー量を増加することでディスク溢れを解決します。 ▪ 他のプラットフォームでは、データの偏りによってディスク溢れが起きることがあります。 AQE(デフォルトで有効化)によってDatabricksではデータの偏りに自動で対応します。 ▪ インメモリのシャッフルパーティションを調整することで、ディスク溢れを回避できる場合があります。Databricksでは適切なシャッフルパーティション数を自動で特定することができます: spark.sql.shuffle.partitions = Auto ディスク溢れの回避 55

Slide 43

Slide 43 text

©2024 Databricks Inc. — All rights reserved クラスターのサイジング - ETL、分析ワークロード ▪ 計算資源に制限を受けていますか？ ▪ CPU使用量をチェック (クラスターのメトリクス) ▪ 高速にする唯一の方法はコアの追加です ▪ ネットワークに制限を受けていますか？ ▪ 重い計算ステップのまえの高いスパイクをチェック ▪ シャッフルを削減するためにより大きく/少ないマシンを使用 ▪ 高速なリモート読み込みのためにSSD搭載インスタンスを使用 ▪ 大量に溢れていますか？ ▪ Spark SQLタブで溢れをチェック (シャッフル前の集計は一般的な溢れの原因です) ▪ メモリー最適化インスタンスを使用

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

©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.

Slide 47

Slide 47 text

©2024 Databricks Inc. — All rights reserved SQLウェアハウスのオートスケール ▪ 同時実行処理に対応するために、それぞれのDatabricks SQLウェアハウスの同時実行クエリー数は10に制限されています。 ▪ Databricks SQLウェアハウスでオートスケールを有効化すると、ウェアハウスは同時実行数に応じて自動でクラスターを追加し、不要になったらクラスターを削減します。

Slide 48

Slide 48 text

©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

Slide 49

Slide 49 text

Slide 50

Slide 50 text

©2024 Databricks Inc. — All rights reserved ウェアハウスのサイジング 3. ユーザー / 同時実行リクエストの数でスケールします • 大きなクラスターは大規模なクエリーを高速に処理し、スループットを改善します • クエリーの処理時間が約5秒以下の場合、大きなクラスターはより多くの同時実行クエリーを捌くための助けにはなりません • 10-15の同時実行クエリーに対して1台のクラスターでうまく動作すると考えましょう 63