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