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