SAP HANA Cloudのデータ階層とは？ホット・ウォーム・コールドの使い分け

01SAP HANA Cloudのデータ階層とは

SAP HANA Cloudのデータ階層とは、データの利用頻度、応答速度、保持期間、コストなどに応じて、データを適切なストレージへ配置する考え方です。すべてのデータを同じ場所に置くのではなく、日常的に参照するデータと、長期保存が中心のデータを分けて管理します。

SAP HANAは高速な分析処理を得意としますが、データ量が増え続けると、メモリ容量、ストレージ容量、バックアップ時間、運用コストに影響します。そこで、業務上すぐに必要なデータは高速な領域に保持し、参照頻度の低いデータはより経済的な領域へ移す設計が有効になります。

ここで重要なのは、データ階層化が単なる保存先の変更ではないことです。アプリケーションの検索条件、保持ポリシー、データのライフサイクル、障害時の復旧方法まで含めて設計する必要があります。

023つのデータ階層を理解する

一般的には、アクセス頻度と要求される応答速度に応じて、ホット、ウォーム、コールドという3つの層で考えます。SAP HANA Cloudでは、利用する機能や構成によって具体的な実装方法が異なるため、名称だけでなく役割を理解することが大切です。

ホットデータ

ホットデータは、現在の業務処理や頻繁な分析で利用するデータです。たとえば、当月の受注、在庫、請求、出荷状況などが該当します。短い応答時間が求められるため、SAP HANAのインメモリ処理を活用する設計と相性がよい領域です。

ホットデータは、単に新しいデータという意味ではありません。過去のデータであっても、月次締めや監査、顧客対応などで頻繁に参照されるなら、一定期間は高速な層に残す価値があります。

ウォームデータ

ウォームデータは、日常的な参照頻度はホットデータより低いものの、業務や分析でまだ利用されるデータです。直近数か月から数年の履歴データが代表例です。

この層では、メモリ使用量を抑えながら必要な検索を可能にすることが目標になります。アクセス速度、容量、管理のしやすさのバランスを取り、データの性質に応じて拡張ストレージや拡張テーブルなどの選択肢を検討します。

コールドデータ

コールドデータは、通常の業務処理ではほとんど参照しない長期保存データです。法令、社内規程、監査、将来の分析などのために保持されますが、常に高速アクセスできる必要はない場合があります。

SAP HANA Cloudでは、コールドデータの保管先としてSAP HANA Cloud Data Lakeを検討できます。Data Lakeは、大量データを比較的低コストで保持し、必要なときに分析できる構成を考えるための選択肢です。ただし、Data Lakeを追加すれば自動的にすべてのデータが最適化されるわけではありません。

03SAP HANA Cloud Data Lakeの役割

SAP HANA Cloud Data Lakeは、SAP HANA Cloudデータベースと組み合わせて、大量の履歴データや低頻度アクセスのデータを扱うためのサービスです。高速処理が必要なデータをSAP HANA側に置き、保持を優先するデータをData Lake側に配置することで、システム全体の構成を調整できます。

この構成は、データを完全に分離して別システムで管理するというより、用途に応じて処理基盤を組み合わせる考え方です。最新データのトランザクション処理と、長期間の履歴分析を同じ業務環境で扱いたい場合に検討しやすくなります。

Data Lakeを検討しやすいデータ

次のような特徴を持つデータは、Data Lakeへの配置候補になります。

• 参照頻度が低く、日常業務の応答時間に大きく影響しない
• 保存期間が長く、データ量が継続的に増加する
• 履歴分析や機械学習のために保持したい
• 形式や生成元が多様で、将来の利用方法がまだ確定していない
• 高速な更新よりも、容量と保持性を重視する

一方、頻繁に更新されるマスタデータ、リアルタイム連携の対象、厳しい応答時間が必要な処理は、Data Lakeだけで処理する設計に向かない場合があります。

Data Lakeとバックアップの違い

Data Lakeは、データの配置先や分析基盤として検討するものであり、バックアップそのものではありません。障害や誤操作から復旧するためのバックアップ、長期保存のためのアーカイブ、参照頻度を下げるためのデータ階層化は、それぞれ目的が異なります。

したがって、Data Lakeへデータを移したからバックアップが不要になるわけではありません。復旧目標、保持期間、削除要件、アクセス制御を整理し、SAP HANA Cloudのバックアップ設計とData Lakeの保存設計を分けて考える必要があります。

04データ階層を設計する手順

データ階層化は、いきなり保存先を決めるのではなく、データの利用実態を調べるところから始めます。次の順序で整理すると、技術選定と業務要件を結び付けやすくなります。

1. 対象データを分類する

まず、テーブル、パーティション、ファイル、ログなど、データの単位を一覧化します。そのうえで、データの作成日、更新頻度、参照頻度、サイズ、所有部門、保持期限を確認します。

「古いデータだからコールド」と決めつけるのは危険です。古い受注履歴が監査月に集中して参照されることもあれば、新しいログが一度しか使われないこともあります。日付だけでなく、実際の利用パターンを確認しましょう。

2. 業務要件を確認する

次に、各データに必要な応答時間、可用性、更新頻度、同時利用者数を整理します。業務担当者が数秒以内の画面応答を求めるのか、夜間バッチで数分待てるのかによって、適切な層は変わります。

また、個人情報、財務情報、契約情報などは、性能だけでなく権限管理や監査要件も確認します。データを別の層へ移すことで、アクセス経路や権限設定が変わる可能性があるためです。

3. 保持ポリシーを定義する

「直近12か月はホット」「1年から5年はウォーム」「5年を超えたらコールド」のように、移動の基準を定義します。ただし、期間だけで自動移動する場合でも、決算、監査、繁忙期などの例外を考慮しなければなりません。

保持ポリシーには、移動条件だけでなく、削除条件も含めます。保存期限を過ぎたデータを残し続けると、コストと管理対象が増えます。削除前の承認、法的保留、復元可能性もルール化しておくと安全です。

4. クエリと連携を検証する

データを別の階層に移すと、SQLの実行計画、結合処理、集計性能、データ転送量に影響することがあります。代表的な検索だけでなく、月次レポート、監査照会、障害調査、外部連携などの実際の処理を検証します。

特に、ホットデータとコールドデータを頻繁に結合する設計では、期待したコスト削減が得られない可能性があります。利用頻度の低いデータを分けた結果、毎回大量のデータを読み込むことにならないか確認しましょう。

5. 運用手順を作成する

移動処理の実行時間、監視項目、失敗時の再実行、権限申請、変更管理を明文化します。初回移行では大量のデータ転送が発生する可能性があるため、業務時間外に実施するか、段階的に処理する計画が必要です。

運用開始後は、データ量だけでなく、クエリ性能、メモリ使用量、ストレージ使用量、転送量、エラー件数を継続的に確認します。構成変更後の効果を測定できるよう、導入前の基準値を記録しておきましょう。

05データ階層化のメリット

最も大きなメリットは、データの価値と利用頻度に応じて、性能とコストのバランスを調整できることです。すべての履歴を高速なメモリ領域に保持する必要がなくなれば、現在の業務に必要なデータへリソースを集中しやすくなります。

また、データ量の増加に対して、単純にデータベース全体を拡張する以外の選択肢を持てます。業務データのライフサイクルを明確にすることで、容量計画や将来の移行計画も立てやすくなります。

分析面では、最新データと履歴データを組み合わせたレポートを作成しやすくなる可能性があります。たとえば、現在の在庫と過去の需要推移を比較する場合、現行データと履歴データを適切な場所に配置することで、分析の選択肢を広げられます。

06データ階層化の注意点

性能を単純比較しない

ホット、ウォーム、コールドの違いは、保存場所の速度だけで決まりません。データ量、圧縮、パーティション、インデックス、クエリ条件、ネットワーク、同時実行数などが結果に影響します。小さな検証データだけで本番性能を判断しないようにします。

移動コストを考える

データを移す処理には、CPU、ストレージI/O、ネットワーク、処理時間が必要です。移動の頻度が高すぎると、保存コストを削減するはずが、移動処理や監視の負荷が増える場合があります。毎日移動するのか、週次や月次でまとめるのかを、データの発生量と業務影響から決めます。

セキュリティと権限を確認する

Data Lakeなど別のサービスを利用する場合は、認証、認可、暗号化、監査ログ、ネットワーク接続を確認します。SAP HANA Cloud側で許可されていた利用者が、別のデータ層でも同じ範囲を参照できるとは限りません。

特に、データを広く保存できる仕組みほど、誰が何を読み取れるかを明確にする必要があります。機密情報を含むデータは、マスキング、アクセス制限、保管期間を含めた統制を設計します。

復旧と整合性を確認する

データ階層をまたぐ処理では、ある時点のデータ整合性をどのように保証するかが重要です。移動中に更新が発生した場合、二重登録、欠落、古いコピーの参照が起きないよう、製品機能と運用手順を確認します。

障害時には、SAP HANA Cloudデータベースだけを復旧すればよいのか、Data Lake側のデータも同じ時点へ戻す必要があるのかを判断します。復旧テストでは、接続、権限、ジョブ、レポートまで含めて確認すると実運用に近い検証になります。

07監視で確認すべき項目

データ階層化の運用では、容量だけを見てはいけません。次の項目を定期的に確認します。

• 階層ごとのデータ量と増加率
• ホットデータのメモリ使用量
• 移動ジョブの成功率と所要時間
• 各階層を利用するクエリの応答時間
• ホット層とコールド層をまたぐ読み取り量
• バックアップ、復旧、削除処理の結果
• 権限変更やアクセス異常の記録
• 保持期限を超過したデータの有無

性能が悪化したときは、単純に上位の層へ戻すのではなく、どのクエリがどのデータをどれだけ読み込んでいるかを調べます。必要に応じて、パーティション設計、集計テーブル、データ抽出方法、保持期間を見直します。

08SAP HANA Cloudの設定を学ぶ方法

実際の構成では、SAP HANA Cloudのデータベース、Data Lake、接続、権限、監視を一体として確認します。機能の有無や制約はサービスのエディション、リージョン、契約、リリースによって異なる場合があるため、導入時点の公式ドキュメントで確認してください。

SAP HANA Cloudの全体像を確認したい場合は、SAP HANA Cloudのプロビジョニングを参照すると、インスタンス作成や初期設定の流れを整理できます。オンプレミス環境との役割分担を比較したい場合は、SAP HANA Cloudとの比較ガイドも役立ちます。

運用設計では、データ量とメモリの関係を把握することが重要です。SAP HANAのメモリ使用量では、容量を確認するときの基本的な観点を整理しています。バックアップと復旧の観点は、SAP HANA Cloudのバックアップとリカバリと合わせて確認してください。

認定資格の学習では、製品名や機能名の暗記だけでなく、要件から構成を選ぶ力が求められます。どのデータをどの層に置くか、性能とコストをどう比較するか、障害時にどう復旧するかを説明できるようにすると、実務にもつながる理解になります。

09まとめ

SAP HANA Cloudのデータ階層は、データの利用頻度と業務上の重要性に応じて、ホット、ウォーム、コールドの配置を考える方法です。高速処理が必要なデータをSAP HANA側に残し、長期保持や低頻度参照のデータをData Lakeなどへ配置することで、性能、容量、コストのバランスを調整できます。

ただし、データ階層化は保存先を変えるだけの作業ではありません。保持ポリシー、SQL性能、データ移動、権限、バックアップ、復旧、監視をまとめて設計する必要があります。まずはデータの利用実態を計測し、小さな範囲で検証してから本番へ広げるのが安全です。

FAQ

実務では：SAP HANA Cloudのデータ階層とは何ですか

データの利用頻度や応答時間の要件に応じて、適切なストレージや処理基盤へデータを配置する考え方です。

Data Lakeに移すと処理は必ず遅くなりますか

必ず遅くなるとは限りません。クエリの種類、データ量、読み取り範囲、接続方法などによって結果が変わるため、本番に近いデータで検証が必要です。

実務では：古いデータはすべてコールドデータにできますか

できません。古いデータでも監査や決算で頻繁に参照する場合があります。日付だけで判断せず、実際の利用頻度と業務要件を確認してください。

Data Lakeはバックアップの代わりになりますか

なりません。Data Lakeはデータの保存や分析に使う選択肢であり、障害や誤操作から復旧するバックアップとは目的が異なります。

実務では：データ階層化を始める前に何を確認すべきですか

対象データのサイズ、更新頻度、参照頻度、保持期限、応答時間、権限、復旧要件を確認し、代表的なクエリで性能を検証します。