行型、列型の3つのデータ領域を使って、OLTPとOLAPの壁を解消するSAP HANA


SAPジャパンの松舘です。前回OLTPとOLAPの融合するSAP HANAの革新性についてお話ししましたが、2回目の今回は少し深掘して、この従来の概念を覆すOLTPとOLAPの融合について、技術的な側面から解説してみたいと思います。

OLTP/OLAP共存の難しさを解消するSAP HANAのアプローチ

Office building stairwell seen through windows

従来、OLTPの仕組みとOLAPの仕組みは、それぞれの特性もあり別のデータベースで実現する形態が取られてきました。OLTP、つまりトランザクション系の仕組みは、通常のRDBMSで実現する形が一般的です。1件の売上伝票を入力すると、1件のレコード更新が行われるような「行(ロー)指向」の考え方です。一方、OLAP、つまり分析系の仕組みの場合は、売上金額の集計のように、“売上”という列を対象に「列(カラム)指向」で対応を行う処理になります。これまでは、行指向と列指向の機能を1つのデータベースで対応することは困難だったため、この技術的な制約から別データベースで運用が行われてきた経緯については、前回お話した通りです。

しかし、行指向と列指向の機能を1つのデータベース上で実現できるハイブリッド型の仕組みで設計されているSAP HANAでは、OLTPとOLAPの融合が図られています。SAP HANAの内部では、最終的にはすべて列(カラム)型で格納・処理されますが、データの受け口、つまり1件ごとのトランザクションが発生する段階では、行(ロー)型のテーブルがバッファーに格納されます。大きく分けると、この2段階(内部のステップでは3段階)で処理が行われ、これらすべての処理がインメモリーで行われます。

行型、列型をミックスした3つのデータ格納領域を活用

この点について、もう少し詳しく見ていくことにしましょう。以下の図に示すように、SAP HANAの内部には3つのデータ格納領域(L1-delta、L2-delta、Main Store)があります。売上が立って伝票が発生し、データがインサートされた際には、まずL1-deltaと呼ばれる書き込み最適化領域に格納されます。実行系のトランザクション処理には、やはり行型の仕組みの方が適しているため、最初のステップではこのような形態が取られるのです。次に、横型(行型)で格納されたデータを、縦型(列型)に変換し、L2-deltaと呼ばれる領域に格納します。そして、最終的に本来のカラムストアであるMain Storeにデータを格納します。

Picture2

これらの動きは自動化されており、L1-deltaの領域は利用可能なメモリーサイズに依存しますが、1ノードあたり1万〜10万件を目安とするレコードを格納し、これを超えると自動的にL2-deltaへの移行が行われます。また、L2-deltaの領域は1,000万件を目安とするレコードを格納し、同じくこれを超えた場合は自動的にMain Storeへの移行が行われます。

自動化された移行処理は、厳密にはデータ件数やCPU利用率などのしきい値によって判断が行われ、オンラインユーザーが少なくCPU負荷の低い時間帯を使って処理が実施されます。

L2-deltaとMain Storeは両方ともカラムストアになりますが、辞書の効率性という点で違いがあります。カラム形式の場合、1つの項目に対し、同一のデータが数多く存在するため、これらを辞書化し、データ上は単純な数値などに置き換えることで圧縮を図ります。簡単に言えば、商品A、商品B、商品Cというデータが発生した場合、それぞれの辞書を作成し、データ上はそれぞれ、1、2、3という形で格納することでデータを圧縮します。このような圧縮対応にはいくつかのレベルがあり、L2-deltaでは、Main Storeと比べて辞書がソートされておらず、ピンポイントアクセスには2次インデックスを必要とします。最終的にMain Storeの段階でデータの特性に応じて、インメモリー処理に最適化された複数ある圧縮方式のうち最適な方式を利用して辞書が生成されます。

ユーザーは格納領域を意識せずデータを抽出

ここまでの説明を読むと、読者の皆様の中には「データをセレクトする際に、この3つの領域を意識しなければならないのか?」という疑問を持たれる方もいらっしゃるかもしれません。しかし、その心配はありません。ユーザーがこの領域を意識することなく、データを操作できる点もSAP HANAのメリットです。

これを支えているのが「Consistent View Manager」と呼ばれる機能で、対象データが現在どのステージ(領域)に存在するのかを判断し、結果を返します。このため、ユーザーは抽出したいデータが現在どの段階にあるのかを意識することなく、容易に検索を行うことができます。

ビジネスユーザーにとってのメリット:SAP HANA Live

最後にビジネスユーザーにとってのメリットについても、少しだけ触れることにします。OLTPとOLAP、言い換えればトランザクションの仕組みとレポーティングの仕組みが1つのデータベース上で一体化されることで、どんなメリットが生まれるのかという点について、「SAP HANA Live」と呼ばれる機能で説明します。

従来のSAP ERPは、アプリケーションサーバーに該当するSAP ERPと、データが格納されるDBMSの2つからシステムが構成されています。DB内のテーブルは固有の名前を持ち、また固有の項目名を含んでいます。また、ここから抽出したデータを分析するBI機能であるSAP NetWeaver Business Warehouseでは、OLAPを実現する手順として、ERP側のDBからデータをコピーし、「顧客単位」「商品単位」などの切り口でサマリーしたキューブを作成します。しかし、ここではコピーというプロセスが入るため、データの鮮度を常に最新の状態に保つことには限界があり、またキューブを構成するためのデータ領域の確保や、OLAPを構成するハードウェアなどの確保も別途必要になります。また、ERPのデータ構造を熟知したコンサルタントも必要です。

一方、SAP HANA Liveでは、SAP HANAに存在する、ERPが参照するテーブル上に直接仮想的なキューブを構成しており、SAPがユーザーによる再利用可能な形でデータモデルを提供しています。ERPのデータを明細レベルで確保しつつ、その集計値もリアルタイムで計算するため、常に最新の情報を明細データ、集計データというカットで抽出することができます。先ほどの既存OLTP、OLAPの仕組みにおける課題と対比する形で、SAP HANA Live導入によるメリットを記載すると、以下のようになります。

  • データは常に最新(トランザクション発生と同時にデータが更新され集計値はオンザフライで計算される)
  • データのコピーやキューブ作成の必要がない
  • SAP HANAのデータを直接参照して仮想的にビューを構成するためデータ容量も増えない
  • OLAP側の仕組みを稼動されるためのハードウェアやその運用も不要

今回は、OLTPおよびOLAPを実現するSAP HANAの技術的な仕組み、そしてその応用形とも言えるSAP HANA Liveも機能についてご紹介しましたが、いかがだったでしょうか?次回は、既存のデータベースからSAP HANAへ移行する際に有効となる「SAP HANA最適化」について、詳細に説明させていただきたいと思います。引き続きご覧いただければ幸いです。

(免責事項)
SAP は、この記事に概説された事業の実現、または記事に記載されたいかなる機能の開発またはリリースに対する義務も負いません。この記事および SAP の戦略および予定されている将来の開発は変更される可能性があり、SAP は随時、理由の如何を問わずに事前の予告なく変更できるものとします。

ご質問はチャットWebからも受け付けております。お気軽にお問い合わせください。

●お問い合わせ先
チャットで質問する
Web問い合わせフォーム
電話: 0120-554-881(受付時間:平日 9:00~18:00)