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