水曜のSAP SAPPHIRE 2011カンファレンスでSAPはHigh-Performance Analytic Appliance (HANA)がDellとIntelとのパートナーシップの下、クラウドで利用できるようになったと発表した。このパートナーシップによって、SAPの顧客はSAPアプリケーションをDellのVirtual Integrated System(VIS)プラットフォームで利用できるようになった。SAPのCTOであるVishal Sakka氏は近々リリースされるHANA AppCloudの簡単に紹介した。HANA AppCloudを利用すると顧客はSAPのBusiness Intelligence OnDemandやCarbon Impact、Sales & Operations Planningにアクセスできる。SAPのアプリケーションとは別にHANAにはサードパーティのアプリケーションを認めるつもりだ。
HANAはSAP Sapphire 2010で初めて発表された時から、front and center position in SAPの戦略の最前線の中心に位置づけられた。この製品はSAPのインメモリコンピューティングへの挑戦であり、OracleのExadata製品に対する返答であると考えられている。というのは、SAPの顧客はOracleデータベースのユーザであり、OracleのExadataが次世代のデータ処理プラットフォームだと考えるだろうからだ。OracleのスタックしかExadataとは違い、a wide range of vendors have signed on to sell HANA appliances, including IBM、富士通、Dell、CiscoそしてHewlett-Packard等多くのベンダがHANAアプライアンスを販売する。
ZDNetのDennis Howlett氏が伝えるようにSAPがクラウド上のHANAに投資するのはやむを得ない理由がある。
収益だけの問題ではない。SAPすでに同社のシステムの運用の中でストレージが最も高コストだという統計データを持っている。このコストはSAPのアプリケーションサーバの運用コストを遥かに上回る。そして、テスト用のシステムは実運用するシステムよりも高コストだ。したがって、クラウド上で運用することで劇的にTCOが減る。
IBMのSAPコンサルタントでありSAP関連情報のブロガーとして有名なVijay VijayaShankar氏は技術的な観点からいくつかの疑問を呈している。
クラウド上のHANAの大きな問題は“どうやってETLをするか。リアルタイムでできるのか”ということです。これは現時点ではまだわかりませんが、私が特に心配しているのはクラウド上でSales & Operations Planningを実行したときです。このアプリケーションは常にETLを実施するシステムであり、インメモリでもスピードが課題だと言われています。さらにクラウドになることで帯域の問題やセキュリティやプライバシーにも関心を払う必要があります。私はいつもS&OPはオンデマンドではなくオンプレミスの方がいい感じています。データが少ないのでオンデマンドでも利用できる顧客もいるかもしれませんが、SAPを利用する巨大組織にまで広まるとは思いません。もうひとつ懸念しているのは、SAPのインフラ構成能力です。製造過程では、HANAのサイジングのための有用な情報を得るための時間が十分にありませんでした。したがって、HANAのホストに必要なサイズを多く見積もりすぎているか少なく見積もってしまっている可能性があります。どちらにしろ、これは悪いことです。
HANAはインメモリを採用してデータソースにとらわれない処理を実現する。処理対象のデーアtは二次的なストレージデバイスではなく、RAM上に保持されるので高性能だ。また、このプラットフォームにはビジネスユーザが簡単に使えるモデリングツールが付属している。IBMとのパートナーシップの下、WinterCorpが実施した初めての正式なベンチマークによれば、はHANA1.3テラバイトに対する1時間に10,000回のクエリ簡単にさばいて数秒で結果を返した。このテストはIBM x3850 X5サーバで実施された。このサーバの性能は32コア、メモリ0.5テラバイト、RAID 5だ。この構成でHANAが1.3テラバイトを扱えるのは、HANAがデータを圧縮して列で保持するからだ。また、HANAは直線的に拡張できる。つまり、コア数やメモリの追加が必要ならば単に追加すればいいだけだ。
Vijay VijayaShankar氏はHANAが謳っているリアルタイム性能について発言している。
HANAをリアルタイムと呼ぶには深刻な問題があります。Ray Wang氏がツイッターで指摘したように、少なくとも現時点では“ライトタイム”と呼ぶ方がいいかもしれません。HANAがECCや他の製品の土台になるまではそう呼んだほうがいいと思います。問題は“ユーザがリアルタイム性を感じられるか”どうかです。サーバルームのHANAの横で作業するユーザはほとんどいません。WANやVPNから接続して使うのです。SAPがはるばる研究所からお披露目の場にHANAを持ってきて systems all the way from their labs to the show floor, and not just connected to them remotely tells me that HANA will not give a real time feeling to users.
また、圧縮能力についても、
私はHassoの本をPDFバージョンで隅から隅まで読みました。そして、以前にもこの点についてツイッターでHassoとは異なる意見を表明しました。キーノートで彼は10分の1までデータを圧縮できると言いましたが、私には信じられません。DB2やORACLEはデータ圧縮の分野で既に素晴らしい仕事をしています。もしDB2が5分の1に圧縮していたら、HANAは本当にそれを上回る10分の1を実現できるのでしょうか。Hassoは私に生のデータが平均して10分の1に圧縮されると説明しましたが、顧客は既に圧縮されたデータを知っていてそれをHANAの圧縮結果と比べるます。またキーノートで言ったような圧縮率に基づいてデータベースの大きさを決められません。いくつかの技術的な理由からもっと領域が必要です。
Vishal Sikka氏はPCWorldのインタビューに答えてHANAのアーキテクチャを説明している。
HANAはSAPのこれまでの技術のすべての上に構築されたシステムです。MaxDBデータベースやTREXインメモリエンジンの技術も利用されています。HANAがメモリ上で持つデータはトランザクションを記録する永続化レイヤに補完されます。ドキュメントによればこのレイヤにはデータベースのイメージを作成するセーブポイントがあります。この機能によって停電やその他の障害が発生した場合に状態の復元ができます。また、HANAはSQLやMDXのような一般的な問い合わせ言語が利用できるBI(ビジネスインテリジェンス)アプリケーションと互換性があります。