技術者必見。これさえ読めば疑問は解決。―インテルとの技術協業で開発されたSAP HANAの基礎の基礎と最新情報(1)


インテルとSAPのロゴ2010年にインテル® Xeon®プロセッサーがリファレンス・アーキテクチャーとなり、インメモリーデータベースとして登場したSAP HANA。ビッグデータの高速処理基盤であり、SAP S/4HANAの基盤にも採用され、SAPデータ管理プラットフォームとして定着しつつあります。しかし、従来のリレーショナルデータベースとは根本的に異なるSAP HANAの構造については誤解も多いのが現状です。そこで、今さら人には聞けないSAP HANAの基本事項について、2回に分けて解説します。

エンジニアが押さえておくべきSAP HANAのポイント

SAP HANAは、SAPの共同創業者の1人で、現在はドイツのポツダム大学で教授を務めるハッソ・プラットナー博士が、学生たちに与えた研究課題から生まれたものです。その後、SAPが研究を引き継ぎ、インテルとの協業を経て新たなデータベースアーキテクチャーとして2010年に製品化しました。リリースした当初は情報系の分析に特化した高速データ解析エンジンとしての位置付けでしたが、その後開発を急ピッチで進めてトランザクション系への対応を実現しました。そのSAP HANAをデータ管理基盤に採用したアプリケーションがSAP S/4HANAです。

疑問1 SAP HANAは分析系(OLAP)専用のデータベースなの?

答 いいえ。分析系(OLAP)と、基幹系(OLTP)の両方に対応しています。

SAP HANAが誕生した経緯もあり、SAP HANAは分析系(OLAP)専用のデータベースであり、ERPの更新系(OLTP)には使えないと誤解している人が多くいます。確かに、SAP HANAはデータ格納方式に列方向の処理に特化したカラム型データベースを採用しているため、大量のデータ集計や分析処理などを得意としていることは確かです。当初は主にレポーティングを高速化する用途などに利用されてきました。しかし現在は、カラムストアの中に更新系専用の領域「デルタストレージ」を設けることで、トランザクション処理を高速化しています。つまり、分析系(OLAP)と、基幹系(OLTP)の両方に対応した高速データベースということになります。

SAP HANAが採用しているカラムストア(列指向)は、分析処理などに用いるOLAP方式に対応したデータ格納方式で、高いスループットを持っているのが特長です。一方、基幹系システムはローストア(行指向)のデータ構造を持つデータベースを採用し、OLTP方式を前提に発達してきました。トランザクションデータを扱うOLTPではレイテンシー(通信遅延)を重視し、レイテンシーが低ければ低いほど高速に処理できることを意味します。データベースの世界では、スループット重視ならカラムストア、レイテンシー重視ならローストアと設計方法が決まっています。

カラムストアを前提に設計されているSAP HANAでトランザクション系の処理をする場合、OLTP方式に最適化されたデルタストレージで実行されます。一方、OLAP方式に最適化されたメインストレージではカラムごとにデータ圧縮を行い、定期的にデルタストレージのデータとマージすることでトランザクションを更新します。これをSAP HANAでは「デルタマージ」と呼んでいます。これらはすべてバックエンドで自動的に処理されるため、ユーザーは意識する必要はありません。

HANAはColumn Store、Row Storeの両方をサポートしています

疑問2 インテルの最新テクノロジーに最適化されているの?

答 はい。SAP HANAはメモリー上にデータがあるから速いわけではありません。

ディスクを使ったデータベースは、I/O性能がボトルネックとなっていました。SAP HANAはデータをメモリーから直接取得することでその問題を解消し、圧倒的な高速処理を実現します。レイテンシーは、従来のディスクと比べると理論上は100万倍以上となりますが、実際はそこまで速くなることはありません。そこでSAP HANAは、インテルと協業し、最新のテクノロジーを用いて最適化を図っています。

メモリーがどれだけ高速化しても、CPUと比べれば圧倒的に低速であることは変わりありません。そのため、メモリーに対してそのままアクセスしていても高速化は望めません。このような状況において、SAP HANAで大量のデータを処理するためには、CPUのみのスピードに頼らない効率的な並列処理が必要です。そこでSAP HANAでは「SIMD(Single Instruction Multiple Data)」や「インテル® TSX」といったテクノロジーによってコードを書き換え、より高速な処理を実現しています。SIMDとは1つの命令で複数の処理を実行する機能のことで、CPUの演算回数を削減することができます。インテル® TSX(インテル® トランザクショナル・シンクロナイゼーション・エクステンション)は、複数のスレッドを効率的に処理する機能です。このように、SAP HANAはメモリー上にデータがあるから高速というだけではなく、インテルのテクノロジーと共に進化を遂げているデータベースプラットフォームととらえることができます。

事例 自動車の部品展開プログラムの基盤にSAP HANAを採用し1日の処理件数を1300倍に拡大、パフォーマンスを10倍向上

ここで、SAP HANAの高速性を利用して自動車の高速部品展開処理を実現した自動車メーカーの事例を紹介します。このメーカーでは、車1台を完成させるために、ライン上に多くの工程があり、約数千点もの部品を組み付けています。これまで部品1個あたりの原価を積み上げて、車1台あたりの製造原価を算出するためには、ホストベースの原価管理用の部品表と部品展開プログラムを用いて計算していました。

しかしホストベースのシステムでは処理能力の拡張に限界があり、月次の日程の中で計算できる車種の数が一部の代表車種に限られていました。実は同じ車種でもグレードやオプションによって1台1台最終仕様が異なる自動車の場合、すべての最終仕様の原価積上げができなければ正確な車種別損益分析ができません。そこで同社はSAP HANAの高速性に着目し、実機を使った実証実験(PoC)を実施しました。その結果、狙い通りの処理性能(最終仕様ごとの車1台の製造原価の算出を1日で完了させる)が確保できる見通しがついたため、SAP HANAの本格採用を決定し、部品表と原価計算部品展開プログラムのSAP HANA上への移植を行いました。

移植のポイントは、COBOL言語で開発したホスト上の手続き型プログラムから、汎用的なSQLで記述した一括DB処理へのマイグレーションにあります。COBOLベースの部品展開プログラムでは、いくつかのテーブルから「SELECT」と「JOIN」をループさせて数珠つなぎでデータベースのテーブルを結合していく必要があり、膨大な時間を要します。それに対してSAP HANAはインメモリーデータベース上で想定できるすべての部品構成を高速に展開してから、ターゲットとなる車の部品構成を取得する正反対のアプローチを取ります。このように、SAP HANAの特性を生かすことで、大量データを段階的に処理するホストのプログラムも簡単に移植ができるようになりました。

SAP HANAへの移植により、今までシステムの処理性能により限定されていた月次での原価積上げが可能な原価計算の車種の数は、そのメーカーが製造する全車種(全最終仕様)に拡大され、処理件数としては現状に比べて約1,300倍の増加となりました。また全体の処理スピードも大幅に短縮され、想定された処理時間に対してもパフォーマンスは約10倍に高速化しています。その結果、車種、グレード、オプション、色別などの詳細な車種別損益分析が高精度かつタイムリーにできるようになりました。

次回も、SAP HANAの基礎について掘り下げます。

参考資料 >> インテルと SAP によるエンタープライズ・インフラストラクチャー・ソリューション