このトピックでは、Hologres の計算資源を管理するためのベストプラクティスについて説明し、複雑で多様な読み取りおよび書き込みリクエストを効率的、インテリジェント、かつコスト効率よく処理するのに役立ちます。
背景
e コマース企業では、データはデータチームによって処理され、アナリストやレコメンデーションチームによって使用されます。データチームは、データ処理と、社内のさまざまなコンシューマーへのデータ提供を担当します。次の表に、各チームのビジネスタスクと特徴を示します。
チーム | 責務 | タスク | 特徴 |
データチーム | リアルタイム、ニアリアルタイム、バッチデータの ETL リンクを含む、すべてのビジネスチームのデータ書き込みと処理を担当します。 | リアルタイムおよびニアリアルタイム ETL:
バッチ ETL:
|
|
データアナリスト | 運用スタッフ、アウトレットスタッフ、営業スタッフなど、さまざまなロールの売上データ分析 |
|
|
レコメンデーションチーム | パーソナライズされた製品レコメンデーション | リアルタイムレコメンデーション: プライマリキーに基づいてユーザーの特徴を取得し、レコメンデーションアルゴリズムを使用してユーザーに合わせたレコメンデーションを行います。 | e コマースプラットフォームのユーザーからのトラフィックは、毎晩ピークに達します。 |
最適化の原則
安定したワークロードの場合、専用の計算資源を予約するだけで十分です。しかし、実際のユースケースでは、ワークロードは非常に同時実行性が高い、ピーク時間がある、または極端に高い場合があります。これにより、計算資源が枯渇し、インスタンスの安定性に影響を与える可能性があります。この場合、次のデシジョンツリーを使用して、リソース最適化ソリューションを選択します。
非常に大きなワークロードにはサーバーレスコンピューティングを使用します。たとえば、大規模なデータバックフィル、フィルターなしの全表スキャン、10 を超えるテーブルとの複雑な結合操作、複数のネストされたサブクエリなどです。これにより、インスタンスで実行されている他のクエリへの影響を回避できます。これらのタスクには、アダプティブサーバーレスコンピューティングを有効にすることをお勧めします。
Fixed Plan によって最適化されたリクエストは、サーバーレスコンピューティングまたはクエリキューを使用した実行をサポートしていません。したがって、これらのリクエストのピークワークロードは、仮想ウェアハウスをスケールアップすることで処理する必要がありますが、書き込みのピークは仮想ウェアハウスの自動弾力性では処理できないことに注意してください。
他のリクエストについては、 パフォーマンスのニーズ、ピーク時間、リクエストタイプに基づいてソリューションを選択します。
サーバーレスコンピューティングを使用する場合、適切なソリューションを選択するには、「課題とリソース管理ソリューション」をご参照ください。
課題とリソース管理ソリューション
このセクションでは、次のビジネス上の問題点に対する最適なソリューションを推奨します。
課題 1: 異なるチーム間のリソース競合と相互干渉
説明: データ ETL とクエリタスクは、計算資源をめぐって競合し、相互に干渉する可能性があります。
ソリューション: 複数の仮想ウェアハウスを持つ Hologres インスタンスを使用して、異なるチーム間のワークロードの隔離を実装します。詳細については、「仮想ウェアハウスインスタンスのアーキテクチャ」をご参照ください。例:
プライマリ仮想ウェアハウス (init_warehouse): データチームがデータの書き込みと ETL に使用します。
読み取り専用仮想ウェアハウス 1: 分析チームが使用します。
読み取り専用仮想ウェアハウス 2: レコメンデーションチームが使用します。
課題 2: 固定されたピーク時間
スケジュールされたスケーリング (ベータ) を使用して、スケジュールされた時間に仮想ウェアハウスをスケールアップまたはスケールダウンします。1 日あたり 16 時間未満のリソース拡張が必要な場合、スケジュールされたスケーリングは、専用 (予約済み) リソースのみを使用する場合と比較してコストを節約します。例:
リアルタイム ETL:
これらのタスクは Fixed Plan を介して最適化されるため、ピーク時間に対処するには仮想ウェアハウスをスケールアップするしかありません。
プライマリ仮想ウェアハウスのスケジュールされたスケーリングを有効にして、ピーク時間に対応します。
データ分析: トラフィックのピーク特性 (日中の勤務時間) に基づいて、読み取り専用仮想ウェアハウスのスケジュールされたスケーリングを構成します。
リアルタイムレコメンデーション:
これらのタスクは Fixed Plan によって最適化されたポイントクエリです。したがって、ワークロードの急増に対応するには、仮想ウェアハウスをスケールするしかありません。
ピークトラフィックは夕方に発生するため、読み取り専用仮想ウェアハウスのスケジュールされたスケーリングを構成して、夕方に計算資源をスケールアップします。
課題 3: 大きなタスクが頻繁に OOM エラーを引き起こし、リソースを長時間占有して他のタスクに影響を与える
次のシナリオには、大きなタスクが含まれる場合があります:
バッチ ETL: 単一のタスクは通常、大量のリソースを必要とします。タスク自体が OOM エラーを起こしやすく、計算資源を長時間占有して他のタスクをブロックする可能性があります。
ソリューション 1 (安定性優先): すべてのバッチ ETL タスクをサーバーレスコンピューティングリソースを使用して実行します。これは SQL またはユーザーレベルで構成できます。詳細については、「サーバーレスコンピューティングリソースを使用して読み取りおよび書き込みタスクを実行する」をご参照ください。
ソリューション 2 (安定性とコストのバランス): バッチ ETL タスクのサイズが異なる場合は、プライマリ仮想ウェアハウスを使用して小さなタスクを実行し、サーバーレスコンピューティングを使用して大きなタスクを実行します。
Dynamic Tables を使用したニアリアルタイム ETL: 各テーブルに対して毎分、増分更新タスクが実行されます。タスクに必要な計算量は増分データの量に関連しており、不安定になる可能性があります。
ソリューション 1 (安定性優先): これらの ETL タスクをすべてサーバーレスコンピューティングリソースを使用して実行します。詳細については、「CREATE DYNAMIC TABLE」をご参照ください。
ソリューション 2 (安定性とコストのバランス): 大きなテーブルまたはデータ量が大幅に変動するテーブルの更新タスクをサーバーレスコンピューティングを使用して実行します。他のタスクはプライマリ仮想ウェアハウスを使用して実行します。
データ分析用の BI ダッシュボード: 多くのデータダッシュボードがあり、タスクのサイズはさまざまです。大きなタスクは計算資源を長時間占有し、小さなタスクをブロックする可能性があります。
ソリューション 1 (安定性、コスト、開発工数のバランス): データベースまたはユーザーレベルで アダプティブサーバーレスコンピューティング を有効にします。これにより、大きなタスクは自動的にサーバーレスコンピューティングリソースを使用するように指示され、小さなタスクは読み取り専用仮想ウェアハウスに残ります。
ソリューション 2 (安定性とコストのバランス): データダッシュボードから大きなタスクの SQL 指紋を抽出し、クエリキューを作成し、このクエリキュー内のすべてのリクエストがサーバーレスコンピューティングリソースで実行されるように構成します。このソリューションを実装するには、次の手順を実行します:
データダッシュボードをテストして、Hologres がダッシュボードからのすべてのリクエストを実行することを確認します。
Hologres のスロークエリログで、
cpu_time_msフィールドを使用して大きなタスクをフィルターし、SQL 指紋であるdigestフィールドを抽出します。詳細については、「スロークエリログのクエリと分析」をご参照ください。SQL 指紋を使用して大きなタスク用のクエリキューを作成します。詳細については、「分類子照合ルールの構成」をご参照ください。
このクエリキュー内のすべてのリクエストがサーバーレスコンピューティングリソースで実行されるように構成します。詳細については、「サーバーレスコンピューティングリソースを使用してクエリキュー内のクエリを実行する」をご参照ください。
ソリューション 3 (コスト削減優先): 仮想ウェアハウスですべてのクエリを実行することを優先します。同時に、クエリキューに対して大きなクエリの自動再実行を有効にします。これにより、サーバーレスコンピューティングリソースを使用して、タイムアウトしたクエリと OOM クエリを再実行します。ユーザーはタイムアウトや OOM エラーに気付きません。詳細については、「大きなクエリの制御」をご参照ください。
課題 4: 突然の大きなタスクがリソースプールを完全に占有し、システムの安定性に影響を与える
散発的な分析タスクは、突然の高いオーバーヘッドを生み出し、インスタンスの安定性に影響を与える可能性があります。
ソリューション 1 (安定性優先): すべてのアドホック分析リクエストがユーザーレベルでサーバーレスコンピューティングで実行されるように構成します。詳細については、「ユーザーレベルでの構成」をご参照ください。
ソリューション 2 (安定性とコストのバランス): ユーザーレベルで アダプティブサーバーレスコンピューティング を有効にします。これにより、ユーザーによって開始された大きなタスクは自動的にサーバーレスリソースに送られ、小さなタスクは仮想ウェアハウスで実行され続けます。
ソリューション 3 (コスト削減優先): 仮想ウェアハウスですべてのリクエストを実行することを優先します。同時に、クエリキューに対して大きなクエリの自動再実行を有効にします。これにより、サーバーレスコンピューティングリソースを使用して、タイムアウトしたクエリと OOM クエリを再実行します。ユーザーはタイムアウトや OOM エラーに気付きません。詳細については、「大きなクエリの制御」をご参照ください。
課題 5: 異なるデータの鮮度と安定性の要件
BI ダッシュボードは、データ開発者、運用スタッフ、営業スタッフ、上級管理職など、社内のさまざまなロールによってクエリされます。顧客向けのデモンストレーションや内部閲覧など、アクセス目的もさまざまです。
高いパフォーマンスのニーズ:
ソリューション 1 (安定性優先): ワークロードが安定している場合は、リクエストを処理するために別の仮想ウェアハウスを作成します。
ソリューション 2 (安定性とコストのバランス): すべてのリクエストをサーバーレスコンピューティングを使用して実行するか、アダプティブサーバーレスコンピューティング機能を使用します。
待機時間が許容できる場合:
データダッシュボードのリクエストタイプが固定されている場合 (例: あるロールが特定のダッシュボードに一貫してアクセスする場合)、手動でスロットリングを構成します。まず、ストレステストを実行して仮想ウェアハウスの読み取り容量を決定します。次に、クエリキューに固定の同時実行制限を構成します。詳細については、「クエリキューの作成」をご参照ください。
リクエストタイプが固定されていない場合 (例: 複数のダッシュボードが異なるロールによってアクセスされる場合)、自動スロットリングを有効にします。Hologres はワークロードに基づいてクエリキューの同時実行制限を自動的に調整します。詳細については、「自動スロットリング (ベータ)」をご参照ください。
課題 6: 予期せぬリクエストの急増がインスタンスの安定性に影響を与える
夜間の予期せぬクエリの急増は課題となります。サーバーレスコンピューティングは、未知のユーザー、テーブル、SQL 文のため、これらを処理できません。スケジュールされたスケーリングは、予測不可能なスパイクに対しては効果がありません。
ソリューション: Auto Scaling を有効にします。これにより、仮想ウェアハウスはピーク負荷時に自動的にスケールアウトし、需要が減少したときにスケールインできます。詳細については、「マルチクラスターと Auto Scaling (ベータ)」をご参照ください。
高度な設定
サーバーレスコンピューティングのタスク優先度の構成
複数のサービスがサーバーレスコンピューティングを使用する場合、ユーザーレベルでリクエストの優先度を構成します。詳細については、「サーバーレスコンピューティングタスクの優先度を設定する」をご参照ください。例:
高いパフォーマンスニーズを持つロールからのクエリリクエスト: 優先度を 5 に設定します。これらのリクエストは、サーバーレスリソースが不足している場合に最初に実行されます。
バッチ ETL タスク: 優先度を 1 に設定します。これらのタスクは、サーバーレスリソースが不足している場合にキューで待機します。
その他のタスク: デフォルトの優先度 3 を使用します。
サーバーレスコンピューティングの日次割当クォータの構成
複数のサービスがサーバーレスコンピューティングを使用できる場合、コストが予期せず高くなる可能性があります。この場合、インスタンスのサーバーレスコンピューティングリソースの日次割当クォータを構成します。また、異なるユーザーに対してリソースクォータを構成することもできます。これにより、サーバーレスコンピューティングリソースを柔軟かつコスト効率よく使用できます。詳細については、「日次累積使用量制限」をご参照ください。
読み取り専用仮想ウェアハウスの高可用性を有効にする
読み取り専用仮想ウェアハウス、特にオンラインレコメンデーションサービスを処理するウェアハウスについては、複数のシャードレベルのレプリカを構成します。これにより、クエリノードに障害が発生した場合でも、損失のないクエリが保証されます。詳細については、「Hologres インスタンスのシャードレベルのレプリケーション」をご参照ください。