今さら聞けない HANAのハナシの基本のほ

© 2017 SAP SE or an SAP affiliate company. All rights reserved. 1
今さら聞けない
HANAのハナシの基本のほ (その1)
(その2以降があるかは未定というか不明というか無いですが...)
SAP ジャパン (Digital Enterprise Platform)
新久保浩⼆ (しんくぼこうじ)

免責事項
このプレゼンテーションは、弊社の⼀般的な製品の⽅向性を説明するものであり、購⼊の意思決
定を⾏う際の判断基準にはなりません。このプレゼンテーションは、SAPとのライセンス契約ま
たはその他の契約を前提とするものではありません。
SAPは、このプレゼンテーションに概説された事業の実現、またはこのプレゼンテーションに記
載されたいかなる機能の開発またはリリースに対する義務も負いません。このプレゼンテーショ
ンおよびSAPの戦略および予定されている将来の開発は変更される可能性があり、SAPは随時、
理由の如何を問わずに事前の予告なく変更できるものとします。
本書は、商業性、特定⽬的への適合性または⾮侵害性等の黙⽰的保証を含めて、明⽰または黙⽰
を問わず、いかなる保証をも伴うものではありません。SAPによる意図的または重⼤な過失に起
因する損害を除き、本書の誤記、脱落等の過失について SAPは責任を負わないものとします。

本⽇のハナシ
⽇頃、HANAにまつわる(ちょっとニッチなものを含む)質問や都市伝説的
な噂に答える形で、HANAの基本的な話をします。
ところどころ、HANAのアーキテクチャーや歴史的な話に派⽣する場合
もあります。
そんなこんなで、まだ、HANAを触ったことがない、そもそも知らない
といった⽅でも、今⽇の話を知っておけば、なんとなくHANAは⼤丈夫
な感じになると思います。
ただ、実践も⼤事なので、ハナシだけではなく実際にHANAを触っても
らえると⾮常に嬉しいです。

SAP HANAとは?
だいたい、これくらい知っておけば⼤丈夫
SAP HANA（エスエイピーハナ）は、ドイツのソフトウェア企業
SAP SEが提供するカラムストア指向リレーショナルインメモリー
データ処理プラットフォームである。狭義には中核コンポーネントで
あるインメモリデータベース機能のみを指すが、広義にはHANA⽤
アプリケーションの実⾏環境や開発環境などのを含む
プラットフォーム全体を指す。
“
“
https://ja.wikipedia.org/wiki/SAP_HANA
周辺機能
SQLだけではなくテキスト分析やグラフエンジンなどのNoSQLや
Hadoopや他のデータソースとのデータ統合などの
“ “
周辺機能

HANAにまつわる質問1
HANAって、OLAP専⽤の
データベースなんですよね？

そう。。。じゃないんです。
HANAって、OLAP専⽤の
データベースなんですよね？

Database Workload
OLTP vs. OLAP
OLTP OLAP
データソース⽇々のビジネスデータ: OLTPのデータは
オリジナルのデータ (ビジネスデータの発
⽣源)
統合されたデータ: OLAPのデータは多く
のOLTPデータベースのデータから構成さ
れる
データの⽬的ビジネスの実⾏とコントロール計画、意思決定のサポート
求められる処理スピード低レイテンシー⾼スループット
データベース設計多くのテーブルによる⾼度な正規化⼀般的に⾮正規化された少ないテーブル
(star/snowflake schema)
クエリー⼀般的に定型的で、シンプル⼀般的に集約を含む⾮定型で、複雑
オペレーション追加、変更、削除、読み取り読み取り
データセット 6-18ヶ⽉数年-⼗数年

Column Store
• OLAP向き
• ⼤量データのバルクロード、スキャン
• 集計、最⼤/最⼩、平均、演算
• ⾼スループットな参照性能
⼀
般
的
な
認
識
• OLTP向き
• 少量データのRead/Write
• 更新、ショートトランザクション
• 低レイテンシーなトランクション性能
• リアルタイムプラットホームとしての位置付け
• OLAP処理⾼速化テクノロジーの実装
• OLTP性能向上テクノロジーの実装
• OLTPとOLAPの性能両⽴
SAPHANA
• 超⾼速OLTPデータベース
Row Store
＊SAP HANAのテーブルは、カラム/ローのいずれかを選択。カラム⇄ロー変換も可能
HANAはColumn Store、Row Storeの両⽅をサポート
Database Workload
Row Store & Column Store

HANAはRow Store TableとColumn Store Tableの両⽅をサポートします。
⼀般的には全てのワークロードに対してColumn Store Tableを使⽤することを推奨します。
Country Product Sales
US Alpha 3,000
US Beta 1,250
JP Alpha 700
US
Alpha
3,000
US
Beta
1,250
JP
Alpha
700
Row #1
Row #2
Row #3
US
US
JP
Alpha
Beta
Alpha
3,000
1,250
700
Country
Product
Sales
Table
Row Store Table
Column Store Table
アプリケーションからはRow Store Table
もColumn Store Tableも同⼀のTableのよ
うに透過的に扱えます
Row Store & Column Store

Nameカラム
無圧縮
Miller
John
Millman
Zsuwalski
Baker
Miller
Jones
Miller
Johnson
John
Millman
Nameカラム
ディクショナリーエンコーディング
4
1
5
N
0
4
3
4
2
1
5
Value ID配列
0 Baker
1 John
2 Johnson
3 Jones
4 Miller
5 Millman
N Zsuwalski
…
ディクショナリー配列
実データとしてはディクショナリー配列を参照するValue IDを格納
カラム単位でDictionary/Value ID配列を作成
• Dictionary：ユニークなカラム値を格納 (位置がValue IDを⽰す)
• Value ID配列：全てのエントリーのValue IDを格納 (位置がRecord IDを⽰す)
• Inverted Index：値が同じ⾏のリスト (値はRecord IDの配列、位置はValue ID）
Column Store
Dictionary Compression

Value ID CITY
0 Atlanta
1 Berlin
… …
772 New York
Record ID Value ID
0 93
1 772
2 654
… …
25382 772
25462 100
Value ID配列
Full
Table
Scan
Binary
Search
Column Store
Inverted index Search
Value ID CITY
0 Atlanta
1 Berlin
… …
772 New York
Record ID Value ID
0 93
1 772
2 654
… …
25382 772
25462 100
Value ID配列
Value ID Record IDs
0 67
1 345, 3334
… …
772 1, 25382
Invertedインデックス
Binary
Search

プレフィックスエンコーディング
4 4 4 4 4 4 4 4 3 5 3 1 1 0Uncompressed
8 4 3 5 3 1 1 0Prefixed Encoded
値
出現回数
ランレングスエンコーディング
5 5 5 4 4 4 4 3 3 2 2 2 2 2Uncompressed
5 4 3 2Run-Length Encoded 値
開始位置0 3 7 9
Advanced compression
• Prefix Encoding
連続する値を値+繰り返し回数にエンコード
• Run Length Encoding (RLE)
連続する値に対して反復を削除して配列の開始位置を保持
• Cluster Encoding
配列を分割、全数同じであれば1⽂字置換
• Sparse Encoding
最も頻出する値を削除
• Indirect encoding
配列を分割、低カーディナリティであれば再度辞書圧縮
Column Store
Advanced Compression

4 4 4 4 4 4 4 3 3 0 0 0Uncompressed
4 4 4 3 3 0Cluster Encoded
Bit Vector 1 1 0 1
クラスターが単⼀数値に
置き換えられた場合は1
4 4 4 3 3 1 0 0 0 4 4 4 4 0Uncompressed
4 3 3 1 0 0 0 0Sparse Encoded
Bit Vector
頻出の値が削除された場合は1
1 1 1 0 0 0 0 0 0 1 1 1 1 0
2 1 576 9 1 2 2 9 88 21 3 19 46 79 45 13 9 6 9 6 3 6 9 3Uncompressed
Compressed 1 0 3 2 0 1 1 2 88 21 3 19 46 79 45 13 2 1 2 1 0 1 2 0
0 1
1 2
2 9
3 576
0 3
1 6
2 9
Dictionary for block#1 Dictionary for block#3
block#2はカーディナリティが⾼いため
追加のディクショナリ圧縮は⾏わない
クラスターエンコーディングスパースエンコーディング
インダイレクトエンコーディング
Column Store
Advanced Compression

インメモリデータベース
デルタストレージメインストレージ
Insert Only Consistent View マネージャー
書き込みに最適化された領域（デルタストレージ）に対し
て、Insert/Update/Deleteを全てInsertで実⾏する(追記
のみのシンプルなオペレーション)
Readオペレーションから、メイン/デルタストレー
ジを隠蔽し、仮想的に１テーブルの外観を提供。
Deleteオペレーションによるローの無効化も実⾏。
トランザクションのIsolation Level(MVCC)も管理。
トランザクション処理とは⾮同期でデルタストレージを
メインストレージにマージする
書き込みに最適化された領域(ディクショナリー圧縮のみ) 読み取りに最適化された領域(圧縮)
Mixed Workload on One Database
デルタマージ
デルタストレージは純粋なカラムストアでは
なく書き込みにも最適された形式

IntelとかPOWERチップに最適化さ
れていると聞くんですけど、具体的
に何ですか？

IntelとかPOWERチップに最適化さ
れていると聞くんですけど、具体的
に何ですか？
そう。それ、すごい⼤事
なんですよ。

1978 1980 1982 1984 1986 1988 1990 1992 1994 1996 1998 2000 2002 2004 2006
10
100
1,000
10,000
1.5, VAX-11/785
VAX-11/780
VAX8700
Sun-4/260
MIPS M/120
MIPS M2000
IBM RS6000/540
HP PA-RISC, 0.05GHz
Alpha 21064, 0.2GHz
PowerPC 604, 0.1GHz
Alpha 21064A, 0.3GHz
Alpha 21164, 0.5GHz
Alpha 21164, 0.6GHz
Alpha 21264, 0.6GHz
Intel Pentium Ⅲ, 1.0GHz
AMD Athlon, 1.6GHz
Intel Pentium 4, 3.0GHz
AMD Opteron, 2.2GHz
Intel Xeon, 3.6GHz
64bit Intel Xeon, 3.6GHz
5
9
13
18
24
51
80
117
183
280
481
649
993
1267
1779
2584
4195
5367
5764
6505
Performance(vs.VAX-11/780)
25%/Year
52%/Year
20%/Year
History of CPU Performance
1980 1985 1990 1995 2000 2005 2010
Performance
10
100
1,000
10,000
100,000
Processor
CPU/Memory Performance GAP
CPU/Memory Performance Trend
CPU⾃体の純粋なスピード(クロックスピード)
の向上は⾒込めないので、CPU内、CPUコア間
での効率の良い並列処理が必要になる。
In-Memoryの世界だと、メインメモリーはCPUに⽐較して圧倒的
に低速なので、メインメモリーに対して何も考えずにアクセスす
ると、皆さんが思うほどのパフォーマンスアップは望めない。
Processor-Memory
Performance GAP
Memory

Latency is the enemy.
メインメモリー
Disk
ディスクは信じられないくらい遅いので、
アーカイブとトランザクションの永続化くら
いの⽤途で、それ以上は、もう考えない。
- CPUのクロックスピードは頭打ちなので、
もっと賢くCPUを使わないとね
- 同じコードを書いていても、CPUの
進化に合わせて勝⼿にスピードアッ
プする時代は終わり
- 効率の良いコードに書き換えないと
(SIMDとかTSXとかを使うように)
- さらにはメインメモリーへのアクセ
スを削減しないとね
CPU1 CPU2
CPU3 CPU4
メインメモリーメインメモリーメインメモリー
- メインメモリーは速くないよ
- 帯域は広くなっているけど、レイテンシー
が全然ダメ
- 特に(CPU)キャッシュミスした時のメイン
メモリーアクセスは本当に悪夢
- あと、NUMAアーキテクチャーに即した
データローカリティを考えないとね
- CPUのクロックスピードは頭打ちなので、
もっと賢くCPUを使わないとね
- 同じコードを書いていても、CPUの
進化に合わせて勝⼿にスピードアッ
プする時代は終わり
- 効率の良いコードに書き換えないと
(SIMDとかTSXとかを使うように)
- さらにはメインメモリーへのアクセ
スを削減しないとね
CPU core
CPU cache
CPU core
CPU cache
CPU core
CPU cache
CPU core
CPU cache

SIMD (Single Instruction Multiple Data)
Pentium ⅢよりSSE(Streaming SIMD Extensions)として搭載され、SIMDレジスタのサイズは128bit、Sandy BridgeよりIntel AVX
(Advanced Vector eXtensions)となりSIMDレジスタのサイズは256bit。Intel SkylakeはSIMDレジスタサイズは512bitとなっており、
今後SIMDレジスタサイズは増加していくと考えられる。(* ここではIntel版のみ⾔及)
SIMD (Vector-Processing)
1 2 3 4 4個のデータの集合A(配列A)
1 2 3 4 4個のデータの集合B(配列B)
を順番に⾜し算したい
1 2 3 4
1 2 3 4
2 4 6 8
+ + + +
=
=
=
=
1 2 3 4
1 2 3 4
+ (SIMD_Plus)
2 4 6 8
=
+演算は 4回
従来の処理では、4個のデータ
を処理するのに+演算
(⾜し算)が4回必要
+演算は 1回
SIMD演算では、4個のデータ
を1回の+演算(⾜し算)で
実⾏ => CPU演算の削減
SIMDレジスタサイズ(この場合は128bit ← ココのサイズが⼤きるなる傾向)
A:
B:

Transactional Memory(Intel TSX)
OLTPの課題
OLTPでの同時実⾏性の制御
- ロックやラッチ(semaphore、mutex)
古典的な⼿法で、あまり細かい粒度でリソースを管理するとパフォーマンスが良くないので、適度な粒度でまとめてリソースを管理します。
まとめて管理されるため、影響を受ける範囲が広がり、同時実効性が悪くなる場合があります。また、 OSのスケジューラーのオーバーヘッド
を回避するために各種にスピンロック(いわゆる無限ループ)も使⽤されるためCPU使⽤率が(無駄に)⾼まる場合があります。
さらに、容易にデッドロックが発⽣する。(よくある内部デッドロックのバグ)

Transactional Memory(Intel TSX)
OLTPの課題
OLTPでの同時実⾏性の制御
- トランザクショナル・メモリー
H/W(CPU)で古典的なロック処理を実装。ユーザー(データベース)はH/Wがロック違反
を検知した場合のみを実装すれば良い。
多くの場合は、スピンロックが不要になり、基本的にデッドロックも発⽣しない。
同時実⾏時の競合がない場合は、OSのスケジューラーのオーバーヘッドもない。
ただし、パフォーマンスの最適化はコンパイラー次第
なので、チップベンダー(≒コンパイラーベンダー)との協業が⼤事
START
XACQUIRE
投機的実⾏
競合判定
Write-set反映、破棄
XRELEASE
END
Write-set破棄
XACQUIREまで戻
り通常の処理
XRELEASE
* TSXのHLE(Hardware Lock Elision)の場合
基
本
的
に
ハ
ド
ウ
ェ
ア
実
装
で
の
処
理
競
合
発
⽣
時
は
ソ
フ
ト
ウ
ェ
ア
実
装
で
の
処
理
TSX使⽤時のイメージ
(* ここではIntel版のみ⾔及)

インメモリーデータベースの
HANAって揮発性なんですよね。

インメモリーデータベースの
HANAって揮発性なんですよね。
そうそう。シャットダウンすると全部消えて
無くなります。
とかありませんから！

普通のデータベースってどういう仕組み?
HANAの話をする前に
キャッシュ(バッファー)
データ
LRU
Tx Tx Tx
ログ
ログ
ログ
ユーザーの要求により
ディスク上のデータブ
ロック or ページをキャッ
シュに載せる
1
各トラザクションの更新
はキャッシュを直接更新
する
3
有限のキャッシュ領域を
LRUで管理
2
更新の確定の前には必ずログ
に更新履歴を同期書き込みで
書く
(Write Ahead Log=WAL)
3
更新されたキャッシュは
遅延書き込みによりディ
スク上に永続化される
(Checkpoint)
4
基本的にディスク上
のブロックイメージ
がキャッシュ上に存
在する

永続化は普通のデータベースに似ているSAP HANA?
インメモリーデータベースといえども永続化はディスク
インメモリーデータベース
データ
LRU
Tx Tx Tx
ログ
ログ
ログ
起動時にディスク上のカ
ラム全体 or ユーザー要求
によりデータページをメ
モリーに載せる
1
各トラザクションの更新
はメモリーを直接更新す
る
3
有限のメモリー領域を
LRUで管理(カラム or
ページ単位)
2
更新の確定の前には必ずログ
に更新履歴を同期書き込みで
書く
(Write Ahead Log=WAL)
3
更新されたデータは遅延
書き込みによりディスク
上に永続化される
(Savepoint)
4
ディスク上のブロッ
クイメージとインメ
モリーデータベース
のページイメージは
異なる
テ
ブ
ル
インメモリー
データベース

In-Memory & Persistence Layer
パーシスタンスレイヤー(永続化レイヤー)
HANAデータベースのストレージ管理、トランザクションログ
管理、システムリスタート時のリカバリー管理などを⾏う
• データボリューム
ü データとUndoを保持するストレージ領域
• ログボリューム
ü トランザクションログ(REDO)を保持するストレージ領域
ü データベースの変更(トランザクション)ログを保存するエリア
同期、⾮同期によるディスクへの書き込み
• セーブポイント(⾮同期)
ü メモリー上の変更データをデータボリュームに書き込む(デフォルトで
300秒ごとの遅延書き込み)
• コミット(同期)
ü トランザクション確定のログエントリーを含むログバッファー上のデー
タをログボリュームに書き込む
メモリー
ストレージ
データベース
ログボリューム
データボリューム
トランザクションログ
(WAL)の書き出し
- Log Buffer FULL
- Commit/Rollback
定期的な⾃動
セーブポイント
(Shadow Paging)
SAP HANA
UNDO DATAREDO
Log Buffer Row Store Column Store
ログセグメント

(余談) HANA Restart
お気づきかも知れませんが、
HANAというIn-Memory
Databaseはデータは消えない
ですが、再起動にはそれなりに
時間がかかる(ことが)あるんで
すよ。。。

(余談) HANA Restart (LOAD or PRELOAD)
SAP HANA
永続化
パターン1) PRELOADなし
クライアントからのリクエストに応じて、永続化レイヤー
からメモリーにロード
パターン2) PRELOADあり
データベース起動時(サービスのオープン前)に永続化レイヤー
からメモリーに事前にロード。(ALTER TABLE)
パターン3) 再起動前のLOAD状態のオブジェクトに依存
定期的にメモリー上にロード中のオブジェクトリストを取得して、
データベースの(再)起動時に⾮同期でメモリーに再ロード
①
② ①
②
①
② (⾮同期)
③
パターン1 パターン2 パターン3

(余談) SAPPHIRE NOW 2017@Orland
http://www.publickey1.jp/m/blog/17/intel_persistent_memory2018xeoncascade_lake.html
http://events.sap.com/sapandasug/en/session/32180?offsettime=0
Optimize Innovation with SAP HANA 2, Our Next-Generation In-Memory Platform
インテル、ついに不揮発性のメインメモリ「Intel persistent memory」発表、実稼働デモ公開。
2018年に新型Xeon「Cascade Lake」とともに登場予定
ハードウェアとしてプレリリース版のXeonプロセッサを搭載したサーバに、192GBのDRAMと1.5TBのIntel persistent memoryのどちら
もメインメモリとして装着。そのうえで、SAPのインメモリデータベースであるHANAの開発版を実⾏しています。
…
データベースのリード／ライトのような、できるだけ⼩さなレイテンシが要求される処理はDRAMを⽤いて処理し、(詳細な説明はなかった
ものの、おそらくログのような)ある程度の⼤きさのデータの読み書きに最適化された処理にはIntel persistent memoryを⽤いているとの
ことです。
Intel persistent memoryは2018年に登場予定の新型Xeonプロセッサ、コード名「Cascade Lake」にあわせて登場する予定。
…

(余談) http://www.vldb.org/pvldb/vol10/p1754-andrei.pdf
https://www.snia.org/sites/default/files/NVM/2016/presentation
s/RickCoulson_All_the_Ways_3D_XPoint_Impacts.pdf

Persistence Storage I/O Pattern
シナリオ Data Volume Log Volume Backup Storage
書き込みトランザクション - WRITE
OLTP – 概ね4KBのシーケンシャルI/O
OLAP – より⼤きなI/Oサイズ (1 MBを
上限に可変)
-
セーブポイント、スナップショット、
デルタマージ
WRITE
4 KB – 64 MB ⾮同期、並列I/O (デー
タ量はシステム負荷に依存)
- -
DB再起動、フェイルオーバー、テ
イクオーバー
READ
4 KB – 64 MB ⾮同期、並列I/O (デー
タ量はRow Storeのサイズに依存)
READ
256 KB ⾮同期I/O
-
Column Storeのテーブルロード READ
4 KB – 16 MB ⾮同期、並列I/O
- -
データボリューム・バックアップ READ
4 KB – 64 MB ⾮同期I/O (バッファー
サイズは512 MB)
- WRITE
512 MB シーケンシャルI/O (設定可能)
ログ・バックアップ - READ
4 KB – 128 MB ⾮同期I/O (バッファー
サイズは128 MB)
WRITE
4 KB – 128 MB シーケンシャルI/O
リカバリー WRITE
4 KB – 64 MB ⾮同期、並列I/O
READ
256 KB ⾮同期I/O
READ
Data backup: 512 MBのバッファーI/O
Log backup: 128 MBのバッファーI/O

できたてホヤホヤなので
エンタープライズ系の機能
(バックアップ、⾼可⽤性とか)
ないんでしょ。

できたてホヤホヤなので
エンタープライズ系の機能
(バックアップ、⾼可⽤性とか)
ないんでしょ。
できたてホヤホヤでも驚く
スピードで進化してますYO!

ミッションクリティカルシステム
のための強固な基盤
SPS12
デジタル改⾰⽀援機能の強化と
オープン化の促進
SPS112015
IoTやビッグデータとの接続性と信頼性を強化
プラットフォーム機能の進化とシンプル化の促進
エコシステムの拡張
プラットフォームとしての柔軟性の強化
プラットフォーム化 (Smart Data Access)
OLAP / OLTP 統合 (SAP Business Suite on SAP HANA)
ビッグデータアプリ対応 (PAL/R⾔語対応)
アジャイルデータマート対応 (SAP BW on HANA)
アナリティクス対応 (SAP BusinessObjects 4.0 対応)
インメモリーデータベースマーケットの開拓SPS1
SPS2
SPS3
SPS4
SPS5
SPS6
SPS7
SPS8
SPS9
SPS10
SAP HANA
アプリケーション
拡充
機能拡張
リアルタイムビジネス
プラットフォーム
として進化
2010
2011
2012
2013
2014
2016
2016/11⽉
SAP次世代
デジタルプラットフォームへ躍進
• データベース管理の進化
• データ管理の進化
• 分析インテリジェンスの進化
• アプリケーション開発の進化
• BW/4HANAのサポート
• S/4HANAのサポート
• SoH / BWoHのサポート
(NetWeaver 7.49以降)
現在はHANA2.0 SPS02
HANA Release History

HANA Backup & Recovery
共通
§ 圧縮データのため短時間で完了
§ 3rdパーティー製バックアップツール利⽤可能
バックアップ
§ メモリー上のDBの永続化は通常運⽤中に⾏われる
(セーブポイント)
§ フル、差分、増分バックアップ
§ データボリュームのコピー(オンライン)
§ ログバックアップ (⾃動)
§ ログボリュームのコピー (*1)
(*1) バックアップは⾃動ですが、外部ストレージへの退避等は⼿動で実⾏する必要が
あります。
リカバリー
§ ポイントインタイムリカバリー可能
バックアップ
管理上のメリット
n バックアップカタログによる世代管理、整合性チェック
n ストレージ・スナップショットの利⽤も可能(HANAのスナップショットを利⽤して)
リカバリー
メモリー
ストレージ
データベース
ログ
ボリューム
データ
ボリューム
Log
Volume
Data
Volume
Log
Volume
Data
Volume
ログ
ボリューム
データ
ボリューム
バックアップ
メモリー
ストレージ
ログ
ボリューム
データ
ボリューム
Log
Volume
Data
Volume
Log
Volume
Data
Volume
ログ
ボリューム
データ
ボリューム
バックアップ
メモリー上にロード
(+ UNDO)
REDO

HANA System Replication
Geo clusters
ビジネスの継続性
データセンター内の
⾼可⽤性
データセンター間の
ディザスタリカバリー
SAP HANA Host Auto-Failover
(Scale-Outのスタンバイ構成)
SAP HANA System Replication
SAP HANA Storage Replication
SAP HANA System Replication

Disaster Recovery
HANA Worker Server
HANA Worker Server
HANA Worker Server
HANA Standby Server
HANA Worker Server
HANA Worker Server
HANA Worker Server
Cluster ClusterLog shipping(*)
Delta data shipping
System Replication
Ÿ HANA組込みのデータベースレプリケーション機能
Ÿ ⾃動での切り替え(Takeover)機能はないので、クラスターマネージャーと連携が必要
(*1) 各種レプリケーションモードによりセカンダリーがACKを返すタイミングが異なります。

セカンダリーと接続が失われるとプライマリーとの整合性の維持はしない
セカンダリーと接続が失われても障害が回復されるまでプライマリも待ち状態
Synchronous(Fullオプション)
プライマリーセカンダリー
LogData Data Log
l ログはセカンダリーサイ
トに同期転送される
l ログ転送は、セカンダ
リーサイトのディスク保
存まで
LogData Data Log
Synchronous
l 正常時の動きは
Synchronous(Fullオプ
ション)と同様
Synchronous in memory
トに同期転送される
l ログ転送は、セカンダ
リーサイトでのメモリー
保存まで
LogData Data Log
メモリ
Asynchronous
LogData Data Log
バ
ッ
フ
ァ
トと接続されているネッ
トワーク経路にログ転送
が開始されると完了。
l ⾮同期転送される
Replication Mode
Transaction Transaction
Transaction Transaction
Bye

OS: DNS, hostname, Virtual IP
HASolutionPartner
HASolutionPartner
Primary
Name Server
Index Server
ログ
ボリュー
ム
データ
ボリュー
ム
Secondary
Name Server
Index Server
ログ
ボリュー
ム
データ
ボリュー
ム
② Log Shipping
① Initial Data Copy
③
HANA 2 SPS 00 〜
mode=logreplay_readaccess
④ 継続的に(プライマリーとは⾮同期)ログボリュームをリカバリー(リプレイ)
SAP HANA Client Library
I : Primaryに接続
Ⅱ : Secondaryに接続
I : Primaryに接続 Ⅱ : Secondaryに接続
認証
リソース及び処理内容から
Primary/Secondaryでの実⾏
をdispatch (Hint⽂で
Secondaryでの実⾏を強制可
能)
認証をPrimaryに依頼
必要に応じてSecondaryで
クエリーを実⾏
HANA2 Read Enabled

メモリーだけだと、そんなに多くの
データが格納できないんじゃない？

メモリーだけだと、そんなに多くの
データが格納できないんじゃない？
⼤丈夫、安⼼してください。
現実的(コスト⾯)な⼿段を提供しています。

Dynamic Tiering
SAP HANA + Extended Table + SAP IQ + Hadoop
各ドメインの強みを⽣かしたデータ処理
• In-Memory Platform
• リアルタイムでのOLTP/OLAP処理
• テキスト、地理情報などのへのネイ
ティブな分析関数
• Diskベースのカラムストア
• ⾼速かつ効率の⾼い圧縮
• データ定義、バックアップなどが
HANAから透過的に実⾏可能
• TB〜PBまでの構造化データに対して
クエリーが可能
• データの重複保持はしない
• ネイティブなHANAの機能ではない
• システムのデータの配置場所をIQに変更
• NLSとして読み込み専⽤ストレージとして
使⽤
• データにより異なるSLA要求に柔軟に対応
HANA
Hot
Dynamic Tiering
Warm
SAP IQ
Cold
• SDAによるHive/Sparkでの接続
• vUDFによる既存のMarReduceジョブの
活⽤
• vUDFはSQLとして実⾏も可能
Raw
Hadoop

Dynamic Tiering
概念と問題点
SAP HANA Database System
SAP HANA Hot store Table
(Classical HANA Table)
SAP HANA Warm store Table
(Extended Table)
参照更新参照更新
Hot storeから
Warm storeに
データを移動
Dynamic Tiering単体としては、HANAに統合された(とはいえ、単純な)ディスクベースのテーブル
の提供のみ(<= SPS12)。データの参照、更新、移動はアプケーション側の実装に依存。
データの場所(hot/warm)がアプリケーションから透過的ではない!

Data Warehousing Foundation(DWF)
Data Lifecycle Manager(DLM)
SAP HANA Hot store Table
(Classical HANA Table)
SAP HANA Warm store Table
(Extended Table)
参照更新更新
Hot storeから
Warm storeに
データを移動
Data Warehousing Foundation
Data Lifecycle Manager(DLM)
Union View (HANA Calc View)
DLMにより⾃動化が可能
DLMにより参照はアプリケーショ
ンから透過的にすることが可能
データの参照に関しては、DLMによりアプリケーションから透過的。
データの更新に関しては、DLMを使⽤してもデータの場所(hot/warm)がアプリケーションから
透過的ではない!
参照参照

Multistore Table (>= HANA 2.0)
SAP HANA Hot store Partition
(Classical HANA Table/Partition)
SAP HANA Warm store Partition
(Extended Table/Partition)
参照更新
Hot storeから
Warm storeに
データを移動
(逆も)
Partitioned Table (Multistore Table)
データの参照/更新に関して、Multistore Tableによりアプリケーションから完全に透過的。
Part#1 Part#2
Part#3 Part#4
Partition単位でデータ移動 Part#5 Part#6
Part#7 Part#8

このへんで、HANAのデータ
ベースサービスをざっと
まとめておきますね。

Row and Column Store
Memory
Logging and Backup –
Solid State / Flash / HDD
Storage
CPU
+
SAP HANA
SAP HANA
Database
In-Memory
Column Store
OLTP + OLAP
Single data copy
SIMD TSX
Real-time
CPU cycle
0.3 ns : 1 s
Main Memory
120 ns : 6 min
SSD:50-150 μs : 2-6 days
HDD:1-10 ms : 1-12 months
CPU
L1
L2
L3
Parallel Processing
CPU
CPU
CPU
CPU
Partitioning
Compression
Data Tiering Virtual Data Model
(No data movement)
Data Federation
High Availability
+
+
++
+
Write + Read Read
Delta Merge
SAP HANA Platform
Database Service
Cache Hierarchy NUMA Awareness

既存のデータベースがたくさん
あって、HANAへのデータ移⾏が
⼤変そう。

既存のデータベースがたくさん
あって、HANAへのデータ移⾏が
⼤変そう。
そのためにデータ統合機能も
あります。
そもそも、全てをHANAに置く必要はないかもしれま
せんよ。

SAP HANA
Virtual Physical
ETL
Virtual Model
Real-Time
No-Data movement
Flexible data model
Integration Service
OData
SAP IQ, SAP ASE,
Oracle, SQL Server,
Teradata …
Data federation
Real time/Batch ETL
Streaming Service
Remote Data Sync
Streaming Lite
(IoT Gateway)
Device/Sensor
SAL SQL Anywhere Ultra Lite
既存データ資産の保護とシステム構成のシンプル化
データ仮想化による仮想DWHの構築
Real-Time/BatchによるETLのサポート
ストリームデータからリアルタイムをアクション
IoTをエンタープライズスケールで実現
Enterprise Architecture Designer:
- ビジネス/ITプロセスで⼀貫性のあるモデリング
Agile Data Preparation:
- セルフサービスによるデータの準備、加⼯、品質
Smart Data Access:
- 既存のデータベース、HadoopへのData
Virtualization
- 双⽅向の参照、更新のサポート
Smart Data Integration/Quality:
- 各アダプターにより既存データベース/APIからReal-
Time/BatchによるETL/Replicationをサポート
Smart Data Streaming:
- 断続的にデバイスから送信されるストリーミングデー
タをSAP HANAに蓄積される前に効率的に処理
- SAP HANAの前にゲートウェイとしてStreaming Lite
を配置可能
Remote Data Sync:
- SAP HANAとSAP SQL Anywhereとの双⽅向同期
- 断続接続環境、低帯域ネットワーク環境のサポート
SAP HANA Platform
Integration Service

§ ローカルテーブルのようにリモートデータへアクセスが可能
§ 述語のプッシュダウン、JOINの再配置、他のデータベース上の
各機能の補完などのクエリの分析を含むスマートなクエリ処理
§ データのある場所によらず開発が可能
§ 異なるデータソースのアクセスに特別な構⽂は不要
§ リモートデータ(Virtual Table)もHANAのモデリングに使⽤可能
Netezza ESP
DB2
SQL Server
Oracle
SAP HANA
SAP ASE/IQ
Teradata
Hadoop/Spark/Vora
Virtual Enterprise Data Warehouse
HANA HANA Virtual Data Model
Data Virtualization
Smart Data Access
Virtual

HANAでアクセスできる
データってSQLでアクセス
できる構造化データだけ？

HANAでアクセスできる
データってSQLでアクセス
できる構造化データだけ？
そう。でもそれだけじゃ
ないんですよ。

Processing Service
Hadoop(Text, Historical Data…), SAP Vora /
SAP IQ, SAP ASE,
Oracle, SQL Server, Teradata …
R-Scripts
PAL
APL
In-Database Analytics
R-Engine
C4.5
decision tree
Weighted score
tables
Regression
ABC
classification
KNN classification
K-means
Associate
analysis:
market basket
SAP HANA
Spatial, IoT, Stream
Database Service
Virtual Physical
ETL
Virtual Model
Real-Time
No-Data movement
Flexible data model
Graph Engine
Spatial Engine
Text Analysis Engine
SQL Engine
Series Engine
構造化データに縛られない様々なデータ処理
各エンジン間でシームレスな連携
Spatial Engine:
- OGC準拠
- 地理空間の情報をデータベースの中で直接
保存、処理、⽣成、共有、取得
Graph Engine:
- ACID準拠のスキーマフレキシブルなグラフ
エンジン
- Pattern Matching/Graph Algorithms
Text Analysis Engine:
- ファイルフィルタリング/エンティティの抽
出、分類/ドメインファクトの認識
Time Series Engine:
- 効率的なシリーズデータの蓄積
- 等距離、⾮等距離のシリーズのサポート
Document Store:
- Schema on ReadのJSONドキュメント・ス
トア
SAP HANA Platform
Processing Service
{JSON}
Document Store
EML Tensor Flow

このへんで、HANAの
Platform全体をざっと
まとめておきますね。

データベースサービス
Web サーバ JavaScript
グラフィック
モデラー
データ仮想化 ELT &
レプリケーション
カラム型
OLTP+OLAP
マルチコア &
並列処理
⾼度な
圧縮
マルチテナントマルチティア
ストレージ
グラフ予測検索
データ
品質
系列
データ
ビジネス
関数
Hadoop &
Spark 統合
ストリーム
分析
ライフサイクル管理
HA & DRオープン
スタンダード
データ
モデリング
管理 &
セキュリティ
データ
同期
空間情報
テキスト
分析
Fiori UX
ALM
</>
アプリケーションサービスインテグレーションサービスプロセッシングサービス
S A P H A N A P l a t f o r m
SAP HANA Platform

そうそう、最近なんか新しいの出た
よね。Hadoop関連の何か？
なんなのあれ?

そうそう、最近なんか新しいの出た
よね。Hadoop関連の何か？
なんなのあれ?
はい、はい、はい、はい。

ALL IN-MEMORY
Enterprise Compute Distributed Compute
CONSUME|COMPUTE|STORE
Massive Scale Out
• Hadoop-HANAの双⽅向での接続
• エンタープライズデータをデータレイクと統合 (SQLに限らず、Sparkでサポートされるプログラミング⾔語でアクセス可能)
• エンタープライズでの分析(hierarchy) & Hadoop上のデータへのクエリー
• HANAでのクエリー最適化(⾼速化)技術をVoraでも使⽤可能(LLVM, SIMD etc)
• DLMを使⽤したOLAPシナリオでHANAからHadoop(Spark/Vora)へのData Tiering
• Vora上でデータ(ベース)技術者によるデータモデリング
Federated Queries &
Data Lifecycle
Manager(Tiering) &
Programming Model
HANA
OLTP + OLAP
Scale Up
Scale Out
Tiering
Vora Vora Vora
Vora Vora Vora
Vora Vora Vora
Vora
Vora
Vora
Vora
Vora
VoraVora
Vora
Vora
Certified Hardware on Any Hardware
Graph Time Series JSON SQLDocumentIn-Memory Disk
SAP Vora
In-Memory Data Fabric & Beyond
JSON

Hadoop Ecosystem
YARN
(Cluster Resource Management)
1 ° ° ° ° ° ° °
° ° ° ° ° ° ° °
° °
° °
° ° °
° ° °
HDFS (Text, ORC, Parquet, Avro)
(Hadoop Distributed File System)
Apache Spark
+ Vora plugin
MapReduce
ApacheHive
SparkSQL
SparkSQL
+VoraExtension
既存の開発環境が利⽤可能
SAP Lumira
Spark
Controller
Other Apps
BW4
HANA
SAP HANA
Platform
In-
Memory
Database
cv
cv
Data Processing Engine
Smart Data
Access
Virtual Table
In-Memory
Table
SQL
AWS
Analytics
HANAのSmart Data Access
でVoraにアクセスする場合は、
従来からサポートされるSpark
Controller経由もしくは、
Vora 1.3から提供されるVora
remote source
adapter(voraodbc)経由での
アクセスとなります。
voraodbcはVora 1.4で以下の
制限事項があります。
- Vora Disk Engine及び
Relational Engine(*)として
作成されたテーブルのみがサ
ポートされています
(*) Relational Engine:
Vora 1.4でリリースされた(置き
換えられた)In-Memory
Relational Engine
HANA – Vora間のデータの送受信はVoraの
各ワーカーノードが独⽴して通信を⾏います
voraodbcでは、spark controllerと
異なり、nativeのHANA wire
protocolを使⽤し、よりHANAへの最
適化が⾏われています。また、
voraodbcは、1.4でkerberos認証が
追加されています。
VoraRelational,Disk,Graph,
TimeSeriesEngine
&DocumentStore
voraodbc
BATCH, INTERACTIVE & REAL-TIME DATA ACCESS
SAP HANA Hadoop & Vora Integration
Bridge the digital divide with SAP Vora
S3 Swift

でも、結局、HANAとかVoraと
かって簡単に触れないんだよね。

Express Editionや
Developer Editionが⽤意
されていますので、無料で
お試し可能ですよ。
でも、結局、HANAとかVoraと
かって簡単に触れないんだよね。

インストールオプション
Ÿ Windows, Mac OS X向け
仮想マシンパッケージ
Ÿ Linux (SUSE and Red Hat)向け
バイナリーパッケージ
Ÿ パブリッククラウド向け
Cloud appliance library (CAL) cal.sap.com
SAP HANA, express editionは無償で利⽤可能なSAP HANAのスリムバージョン。
メモリ32GBまでクラウド、ラップトップやサーバーにインストール可能。
アプリケーション開発をクイックスタート。
SAP HANA無償版
今すぐダウンロード!!!
SAP HANA Express Edition
Ÿ 32GBまで無償。128GBまでの有償版への
アップグレードオプション
Ÿ SAP HANAコア機能を利⽤可能
Ÿ 認定ハードウェア不要 RAM 16GB以上
Ÿ コミュニティサポート
SAP HANAへの無償アクセス | 迅速なアプリケーション開発 | 有償版アッグレードへの柔軟性
開発者へのメリット
SAP HANAに触れてみよう! SAP HANA, express editionクイックインストールガイド
http://www.sapjp.com/blog/archives/15000
https://www.sap.com/japan/developer/topics/sap-hana-express.html
SAP HANA, Express Edition(XE)

インストールオプション
Ÿ Windows, Mac OS X向け
仮想マシンパッケージ
Ÿ パブリッククラウド向け
Cloud appliance library (CAL)
Ÿ AWS向け
AMIとしての提供
SAP Vora, Developer Editionは無償で利⽤可能なSAP Voraの開発⽤バージョン。
クラウド、ラップトップやサーバーにインストール可能。アプリケーション開発を
クイックスタート。
SAP Vora開発⽤
今すぐダウンロード!!!
SAP Vora Developer Edition
Ÿ SAP Voraの全機能を利⽤可能
– 主要なHadoopディストリビューション
(Cloudera,MapR,Hortonworks)をサポート
– In-Memory リレーショナルエンジンの他に
時系列、グラフ、ドキュメント、ディスクな
どの各種エンジンをサポート
– グラフィカルなモデリングツールをサポート
Ÿ コミュニティサポート
SAP Voraへの無償アクセス | 開発者に機能制限なしの利⽤ | 迅速なアプリケーション開発
開発者へのメリットhttps://www.sap.com/developer/topics/vora.html
SAP Vora, Developer Edition

書籍「SAP HANA ⼊⾨」出版のお知らせ

Q & A
Any Question?

THANK YOU!

今さら聞けない HANAのハナシの基本のほ

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie 今さら聞けない HANAのハナシの基本のほ

Ähnlich wie 今さら聞けない HANAのハナシの基本のほ (20)

Mehr von Koji Shinkubo

Mehr von Koji Shinkubo (12)

今さら聞けない HANAのハナシの基本のほ