使用上の注意
概要
非同期マテリアライズドビューは、クエリ結果を事前に計算して保存することでクエリパフォーマンスを向上させますが、各リフレッシュには大きなオーバーヘッドが発生する可能性があります。本ドキュメントでは、非同期マテリアライズドビューの使用に関する推奨事項を提供します。
マテリアライズドビューのリフレッシュ原理については、Refresh Principlesを参照してください。
推奨使用シナリオ
推奨シナリオ
複雑な集計クエリ
- シナリオ: 複数テーブル結合、複雑な集計関数（例：SUM、AVG、COUNT）、またはウィンドウ関数を含むクエリ
- 利点: 実行の度に複雑なロジックを再計算することを回避
レポート
- シナリオ: 固定時点（例：毎日深夜）での一貫したスナップショットが必要なレポート
- 利点: すべてのユーザーが同じ時点のデータを参照することを保証
計算集約的な分析
- シナリオ: 複雑な数学的計算やデータ変換を伴う分析クエリ（顧客生涯価値計算や予測モデリングなど）
- 利点: 結果を事前に計算することで実行時のリソース消費を削減
データウェアハウスのスター/スノーフレークスキーマ
- シナリオ: ファクトテーブルと複数のディメンションテーブルの結合（例：製品、時間、地域ディメンションテーブルと結合した売上ファクトテーブル）
- 利点: 結合結果を事前に物理化して分析クエリを高速化
データレイク高速化
- シナリオ: データレイクのクエリは、ネットワーク遅延とオブジェクトストレージのスループット制限により遅くなる可能性がある
- 利点: Dorisのローカルストレージの利点を活用してデータレイク分析を高速化
データウェアハウス階層化
- シナリオ: ベーステーブルに大量の生データが含まれ、クエリには複雑なETL操作が必要
- 利点: 多層の非同期マテリアライズドビューを構築することでデータウェアハウス階層化を実装
非推奨シナリオ
頻繁に更新されるベーステーブル
- シナリオ: ソーステーブルデータが非常に頻繁に変更される（例：1分間に複数回の更新）
- 問題: 非同期マテリアライズドビューは同期を維持することが困難で、リフレッシュコストが高すぎる。代わりに定期的なリフレッシュを検討。
単純なクエリ
- シナリオ: 単一テーブルスキャンや単純なフィルタリングのみを含むクエリ
- 問題: 非同期マテリアライズドビューの利点がリフレッシュコストを相殺できない
リアルタイム（1-5分の新しさ）データが必要なシナリオ
- シナリオ: ビジネス要件で最新データが必要
- 問題: 非同期マテリアライズドビューはデータ遅延を引き起こす
小さなソーステーブル
- シナリオ: ベーステーブルに少数のレコードのみが含まれる（例：数百行）
- 問題: 非同期マテリアライズドビューの最適化効果が無視できる程度
リフレッシュ戦略の推奨事項
非同期マテリアライズドビューは3つの主要なリフレッシュ戦略を提供し、それぞれ異なるビジネスシナリオとデータ特性に適しています。適切な戦略を選択することは、データの新しさとシステムパフォーマンスのバランスを取るために重要です。
詳細なリフレッシュ戦略
手動リフレッシュ
仕組み:
- ユーザーコマンドまたは外部システムスケジューリングによって明示的にトリガー
適用可能なシナリオ:
- リアルタイムデータ要件が低いレポートシステム
- データウェアハウスの履歴データ分析
- 特定のビジネスプロセスとの同期が必要なシナリオ
- 協調的なシステムリソースが必要な大規模データリフレッシュ
メリット・デメリット:
- メリット: リフレッシュタイミングを完全制御、ビジネスピーク時間を回避
- デメリット: 追加のスケジューリング管理と、外部ループが継続的にリフレッシュをトリガーすることを防ぐフォルトトレラント性が必要
スケジュールリフレッシュ
仕組み:
- 固定間隔で自動的にリフレッシュ
- 最小時間単位：分
- 最初のタスク実行開始時間を指定可能
適用可能なシナリオ:
- 定期的なビジネスメトリクス監視
- 階層化データパイプライン
- 時間に敏感なレポートシステム
- 定期的な変動があるソースデータ
メリット・デメリット:
- メリット: スケジュールされたデータ処理で予測可能なデータ遅延
- デメリット: データの新しさが制限される；関連ビューのリフレッシュシーケンスは手動編成が必要
設定上の制約:
すべてのマテリアライズドビューを高頻度スケジュールリフレッシュに設定してほぼリアルタイム結果を実現することは避ける。以下のような問題が発生する可能性がある：
- システムリソースを継続的に占有
- リフレッシュジョブがリソースを競合
- 頻繁なpartition/tablet操作がBEに大きな負荷をかける可能性
トリガーベースリフレッシュ
仕組み:
- ベーステーブルデータが変更されたときに自動的にリフレッシュをトリガー
適用可能なシナリオ:
- 多層マテリアライズドビューアーキテクチャの上位層ビュー
- ベーステーブルが稀に変更されるシナリオ
メリット・デメリット:
- メリット: 高いデータ新しさと自動化
- デメリット: リフレッシュストームと予測不可能なシステム負荷を引き起こす可能性
設定上の制約:
以下の場合を除き、基盤マテリアライズドビューにトリガーベースリフレッシュを使用することは避ける：
- ベーステーブルのリフレッシュ頻度が低いことが分かっている（例：数十分ごとに変更）
組み合わせリフレッシュ戦略の推奨事項
階層化戦略
- 基盤層: スケジュールリフレッシュ（例：毎時）
- 中間層: スケジュールまたはトリガーベースリフレッシュ
- 表示層: トリガーベースまたは手動リフレッシュ
ビジネス重要度階層化
- 重要なリアルタイムビジネスデータ: 非同期マテリアライズドビューは非推奨
- 通常の分析データ: スケジュールリフレッシュ（日次/時間次）
- 履歴/アーカイブデータ: 手動リフレッシュ
データ変更頻度への適応
- 高頻度変更: スケジュールリフレッシュ（長い間隔）または手動リフレッシュ
- 低頻度変更: トリガーベースリフレッシュまたは短間隔スケジュールリフレッシュ
- 一括変更: 変更後の手動リフレッシュ
リフレッシュ頻度の推奨事項
これらは一般的なガイドラインです；実際の設定はシステムリソース、マテリアライズドビュー数、その他のビジネスリソース使用状況を考慮する必要があります。
| 実際のリフレッシュ時間 | 推奨リフレッシュ頻度 |
|---|---|
| < 15秒 | ≥ 5分 |
| < 10分 | ≥ 1時間 |
| < 1時間 | ≥ 1日 |
非同期マテリアライズドビューの重要な考慮事項
- 監視: マテリアライズドビュー導入後は、metricsを通じてシステムパフォーマンスを監視してください。非同期マテリアライズドビューの追加メトリクスは今後公開される予定です。現在はtasksを使用してタスク数、実行状態、継続時間を確認してください。
- 計画: マテリアライズドビュー数、リフレッシュ頻度、クラスターの最大計算能力を計画してください。「マテリアライズドビューを作成して維持しない」ことは避けてください—これらは本質的に拡張されたETL計算であり、従来のETLのような保守が必要です。
- リソース分離: マテリアライズドビューはデータ計算タスクです。必要に応じてリソース分離を実装してください。
