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