Delta Live Tables best practices | Databricks on AWS [2022/11/24時点]の翻訳です。
本書は抄訳であり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
本書では、Delta Live Tablesパイプラインを開発、デプロイ、管理する際のベストプラクティスを説明します。
テーブルとビューの選択基準
パイプラインが効率的かつメンテナンスしやすくなる様に、パイプラインのクエリーを実装する際に、テーブルかビューかベストなデータセットタイプを選択する様にしましょう。
以下のケースではビューの使用を検討してください:
- 管理しやすいクエリーに分割したいと考える大規模かつ複雑なクエリーである場合。
- エクスペクテーションを用いて中間結果を検証したい場合。
- ストレージコスト、計算コストを削減したいと考えており、クエリー結果のマテリアライゼーションが不要な場合。テーブルはマテリアライゼーションされるので、計算コストとストレージリソースを必要とします。
以下のケースではテーブルの使用を検討してください:
- 複数の後段のクエリーがテーブルを使用する場合。ビューはオンデマンドで計算されるので、クエリーされるたびにビューは再計算されます。
- 開発中にクエリーの結果を参照したい場合。テーブルはマテリアライズされるので、パイプラインの外で参照、クエリーすることができ、開発中にテーブルを用いることは、計算処理の適切性の検証の役に立ちます。検証後に、マテリアライゼーションが不要なクエリーをビューに変換します。
パイプライン設定でSparkバージョンを上書きしないでください
Delta Live TablesのクラスターではカスタムバージョンのDatabricksランタイムを実行しているので、クラスター設定で手動でSparkバージョンを設定することはできません。手動でバージョンを設定するとパイプラインは失敗します。
注意深くパイプラインの境界を選びましょう
パイプラインをどの様に分割するのかを決定する際、以下の点を検討してください。
以下のケースでは大規模パイプラインにしてください:
- クラスターリソースをより効率的に活用したい。
- ワークスペースのパイプライン数を削減したい。
- ワークフローのオーケストレーションの複雑性を削減したい。
以下のケースでは複数のパイプラインにしてください。
- チーム境界で機能を分割したい場合。例えば、あなたのデータチームではデータを変換するためのパイプラインを維持管理し、データアナリストは変換データを分析するパイプラインを維持管理する場合。
- 結合度を削減し、共通機能の再利用を促進するために、アプリケーション固有の境界で機能を分割する場合。
効率を高め、リソース使用量を削減するためにオートスケーリングを活用しましょう
パイプラインにおけるクラスターの使用率を最適化するために、強化オートスケーリングを使いましょう。強化オートスケーリングは、リソースの追加によってパイプラインの処理スピードを改善するとシステムが判断した時のみリソースを追加します。不要になるとすぐにこれらのリソースは解放され、すべてのパイプラインのアップデートが完了するとクラスターはシャットダウンします。
プロダクションパイプラインで強化オートスケーリングを設定する際には、以下のガイドラインを使用してください。
-
Min workersの設定はデフォルトのままにしてください。 - 予算とパイプラインの優先度に基づいて、
Max workersを設定してください。 - Delta Live Tablesランタイムが、ワークロードにベストなインスタンスタイプを選択できる様に、インスタンスタイプは未設定の状態にしてください。