既存BWをHANAで高速化したサザン・カリフォルニア・エジソン
本日は、現在のHANA利用例の中でもっとも数が多く、もっともリスクが低く、もっともすばやくROIが得られる”鉄板”ユースケース、BW on HANAの事例を紹介する。
当ブログはどちらかというとSAPやHANAを知らない方、というよりそもそもIT系ではない方にもできるだけわかりやすいように、というコンセプトで書き続けているが、一方でやはりHANAに興味をお持ちの、SAPのお客様やパートナー企業の方、つまりIT畑の方にも多数お読みいただいている。ときどき「読んでますよ」とお声掛けをいただくと、そりゃあ嬉しいものである(笑)。
今日の事例紹介は、おもにそうした、SAPの既存ユーザーの方向けの内容である。つまりSAPの前提知識がないとちょっと理解しにくいと思われるのだが、これを全部解説していくとこの5倍くらいの量になってしまうのでｗ、ご容赦いただきたい。
サザン・カリフォルニア・エジソンは米国カリフォルニア州南部エリアに電力（および一部ガス、水道）を供給している。管内人口はおよそ1400万人（ちなみに東京電力はおよそ4200万人、関西電力およそ2100万人）。以前は発電・送電を含めて独占的に手掛けてきたが、1998年からの電力自由化と同時に発電・送電の切り離しが行われた。現在も発電所を一部保有しているが、主要部分は卸売市場から調達している。社員数は15,500人。
5月のSAPPHIRE Orlandoで行われた、サザン・カリフォルニア・エジソンのITディレクター、ロン・グラビアン氏の講演をもとに構成した。
オリジナル動画はこちら。
■Southern California Edison Unleashes the Power of SAP HANA （20分46秒、英語）
http://www.sapvirtualevents.com/sapphirenow/sessiondetails.aspx?sId=2266
同講演のPDF資料はこちら。
http://sapvod.edgesuite.net/SapphireNow/sapphirenow_orlando2012/pdfs/23398.pdf
-----
弊社では、BW on HANAとスタンドアローンHANAの両方のパイロットを行いましたので、本日はそのお話をしたいと思います。BW on HANAは10月に本稼働する予定です。
■BW：
正式名称はSAP NetWeaver Business Warehouse。
SAPが提供するエンタープライズDWH構築基盤。SAP ERPのデータに対応した業務テンプレート「ビジネスコンテンツ」があらかじめ用意されており、それを有効化するだけでERPのデータを分析することができるため、SAP ERPとセットで導入されるケースが非常に多い。ワールドワイドで現在約13,000社・約16,000インスタンスが稼働しており、さらに毎月200ほど増え続けている。（過去に当ブログで紹介したSAP既存ユーザー企業にはほぼ万遍なく導入されていると言っても過言ではない。）当事例で紹介されているとおり、DBにHANAを採用して「BW on HANA」となることでさらに優位性を増し、採用が加速している。
■BW on HANA：
正式名称はSAP NetWeaver Business Warehouse powered by SAP HANA。上記のBWは従来型のDB上で稼働していたが、これをHANAに置き換えたもの。現在、HANAのユースケースとしてはもっとも数が多く、すでに100社を超えており、さらに勢いを増している。■スタンドアロンHANA：
BW on HANAとの対語として使われる通称で、BWを乗せず、データベースとしてのHANAを素のまま使うアプローチ。BWがないため、データのモデリングなど一連の作業は導入の際にゼロからやらなくてはならないが、一方でBWというオーバーヘッドはないので、DB設計が適切に出来ていれば、パフォーマンス的にはBW on HANAをさらに上回る。
-----
HANAとは何か？論理的には、HANAはインメモリ・データベースです。データをモデリングし、ストアして、管理します。
データソースからリアルタイムにデータを複製（レプリケーション）したり、ETL（ローディング）する機能もあります。
分析はインメモリですので高速です。分析のためのモデリングは柔軟にできます。
また、新しいアプリケーションの稼働基盤にもなります。
物理的には、HANAアプライアンスとは、大きなメモリとマルチコアCPU（当社では512GBのメモリと、40コア）を積んだ強力なサーバーです。
メモリはディスクとくらべてざっと100万倍ちかく高速です。ディスクアクセスを1とすると、SSDは1,000倍くらい、メモリアクセスは700,000倍くらいの速さですので。
データベース全体がメモリで動くというのは画期的なことですが、一方でデータ保持のために640GBのSSDと、4.7TBのハードディスクを積んでいます。
行ストアと列ストアが使えます。とくに列ストアは分析業務に効きます。
データ圧縮が自動的にかかり、約5倍になります。実際にはBW on HANAではさらに圧縮効率が高い（7.5倍：後述）です。
非マテリアライズドビューなので、モデリングが柔軟にできますし、データの重複も発生しません。
マルチコアを使った並列データローディングおよびパーティショニングにより高速です。
-----
当社がHANAを導入したねらいは2つです。
まずOperational Improvement、つまり現在も行っている業務をさらに改善すること。レポーティングの高速化、データロードの高速化、TCOの引き下げ、とくにキューブやレポートのメンテナンスコスト・新規作成コストの削減です。こちらはBW on HANAの領域です。
もうひとつはNext-Generation Analysis、つまり次世代型の情報系・分析系システムへの道を拓くことです。HANAが持つ、分析の高速化、柔軟なモデリング、ほぼリアルタイムなデータ、計算エンジンや組み込み関数、ビッグデータ対応などの機能を活かした次世代型アプリケーション、たとえばスマートメーターアナリティクス、停電管理、電力の市場からの調達の最適化、それらのための予測分析（Predictive Analysis）などです。こちらはスタンドアロンHANAの領域です。
-----
この図は当社におけるBIの歴史と将来、です。
左端は2007年に導入した、従来型DBで動くBWです。このパフォーマンスを100とすると、
2番目のBWAでは、レポート（黄色のバー）が約2.5倍速くなりました。データローディング（緑色のバー）のほうは変わりません。
■BWA：
Business Warehouse Accelerator。
従来型BWのうち、分析・レポーティングに関わる部分だけを外付けインメモリに出して高速化する、という製品。ごく大雑把にいうと、HANAの前身。
左から4番目が、BW on HANAです。これはパイロット結果ですが、従来のBW（左端）と比べるとレポートは10倍強、直前の環境（左から3番目）と比べても5倍の改善になっています。
またデータローディングのほうですが、こちらもこれまで15時間かかっていたものが4.6時間へと、3倍強の改善です。別の言い方をすれば、従来は前日17時にローディングを開始しても、翌朝8時に終わるかどうかギリギリだったものが、10時間以上の余裕ができたということです。これは大きい。
-----
BW on HANAパイロットの結果です。
現行のBWAとの比較で見てみると、まずデータ圧縮については、圧縮比率7.5倍になりました。事前予測の5.7倍よりよい結果です。HANAはライセンス量課金なので、コストを抑える意味でも、圧縮比の高さは重要です。
次にデータロードですが、全量（Full）ロードでは数千万行をアップしますが、15時間から3時間弱へ、5.2倍の改善。差分（Delta）ロードでは5,000～10,000行くらいですが、3.2倍。
レポートのほうは、現行BWAでは35秒だったものが、BW on HANAに移行したキューブでは約7秒。DSO（インフォプロバイダ）でもやはり7秒で、約5倍の改善。
一方、スタンドアロンHANA上にスキーマを作り、Universe経由でBusinessObjectsからアクセスする形では、1秒未満になりました。もちろんこれはひとつのテストにすぎず、すべてのBW業務をスタンドアロンHANAに移すのにはコストがかかりすぎますが。
-----
これはデータ量の削減についてです。既存BWは19,934GB、ほとんど20テラバイトありました。これをどのように減らして行ったか？
- 左から2番目、まずはゴミ掃除（Housekeeping）の強化です。レガシーDBのオーバーヘッドや変更ログを落とすとともに、PSAを100に絞りました。
- 3番目、システムテーブルの掃除で、1,167GBあったものを300GBに。ここまではシステム部側のお掃除です。
- 4番目、もう使わなくなっていた古いDSOやキューブを削除し、またキューブのうちいくつかはDSOから直接見ることにして削減。
- 5番目、データとデータの結合などのために設けていたレイヤを減らして一段階で済ませることで、さらに削減。
- そして最後、右端では、キューブのうちいつも見るわけではない少し前のデータをニアライン・ストレージに逃がすことで、141GBにまで減らしました。
こうした掃除とスリム化の努力により、データ量は2,157GBまで減り、これにHANA化によるデータ圧縮を約6倍と見ると、データ量は359GBまで減らせます。（物理メモリ量は512GBなので十分に乗る量になりました。）
これはけっこう大変な作業ではありました。各データやレポートが使われているのか、をひとつひとつ精査していきましたから。しかし19TBもあるからHANAなんてとても買えない、と考える前に、やってみれば、できるものです。
-----
TCOについては、詳細は申し上げませんが、HANA化に伴う5年間のTCOはポジティブになる（HANA化しない状態よりも削減される）と見ています。
導入当初はもちろんHANAのライセンスやハードウェア、またニアライン・ストレージなどを買わなくてはなりませんが、BWAを解約して充当するのと、BWAで使っていたハードウェアやストレージは転用できるのでその分が節約になります。
一方ランニングコストとしては、そもそも我々のビジネスが伸びているためデータ量は必然的に増えるのですが、それに伴ってHANAの追加ライセンスも必要になるでしょう。一方でキューブ等の開発およびメンテナンスにかかる人的コストがなくなりますが、これはコスト全体の2割を占めていましたので、その分が大きく節約になります。
-----
最後に、スタンドアロンHANAの可能性です。
会社としてまだなんら意思決定をしたわけではありませんが、このスライドはどの電力会社にでもあてはまるものだと思います。
スマートメーター・アナリティクス、電力の市場からの調達、停電の管理、そして需要や停電の予測分析などは、まさにHANAの特長が生きるアプリケーションであり、今後検討していきます。
-----
※本稿は公開情報をもとに筆者が構成したものであり、サザン・カリフォルニア・エジソン社のレビューを受けたものではありません。