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