20170518_今さら聞けないHANAのハナシの基本のき by SAPジャパン株式会社新久保浩二

© 2017 SAP SE or an SAP affiliate company. All rights reserved. 1
今さら聞けない
HANAのハナシの基本のき
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
そもそも、SAPさんってERPとかの
アプリケーションベンダーでしょ？

そもそも、SAPさんってERPとかの
アプリケーションベンダーでしょ？
そうですけど、
プラットフォーム
はじめました。
ぷ
ら
っ
と
ふ
ぉ
む

ERP
Non ERP
€100億
ERP
Non ERP
€208億 - Platformの⼤幅な伸び
- HANA/ASE/IQ/SQLA
- Business Objects/PA(aka KXEN)
- SAP Cloud Platform/HEC
- …
- クラウドカンパニーへ
- 2012 SuccessFactors
- 2012 Ariba
- 2013 Hybris
- 2014 Concur
- 2015 Altiscale
- …
FY2010 FY2015
SAPはERPの会社?
Non ERPの売り上げが60%以上へ

SAPはERPの会社?
HANA Platformの技術的バックグランド
TREX
(Text Retrieval and information EXtraction)
ʻ97
ADABAS D SAP DB
ʻ03 ʻ07
ʻ98
P*TIME
ʻ10
HANA
Sybase
OLAP Column based in-memory data
storage & processing & distributed
infra(no SQL, no transaction support) And
some processing engines are supported.
(graph, search, classification, mining…)
Row based on disk SQL access data storage
& processing
BI Suite. and
Data Integration (Data
Services)
HANA 1.0 SPS00
TREXMaxDB P*TIME
Sybase ASE(Row/Disk), Sybase IQ(Column/Disk),
Sybase SQL Anywhere(Light weight/Distributed
Remote Sync), Sybase Replication Server …
OLTP Row based in-memory SQL access
data storage & processing
Row based on disk SQL
access data storage &
processing. Very mature
storage architecture &
database
connectivity(client library).
BW
Accelerator
ʻ05
SAP Business Warehouse(BW)
Accelerator which is based on TREX
technology. This is provided as appliance
model & supports scale out/MPP.

で、カラムストアって何？

⼀般的にOLAP(分析処理な
ど)に最適化されたデータの
格納⽅式です。
で、カラムストアって何？

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

US
US
JP
Alpha
Beta
Alpha
3,000
1,250
700
Country
Product
Sales
Table
Row Store Table
Column Store Table Page#1
Page#2
Page#3
US Alpha 3,000
US Beta 1,250
JP Alpha 700
Sum 4,950
US
Alpha
3,000
US
Beta
1,250
JP
Alpha
700
Row #1
Row #2
Row #3
Page#1
Page#2
3,000
1,250
700
Sales
Page#3
全てのデータページ(ブロック)へのアクセスが必要
該当のカラムのページ(ブロック)への
アクセスのみでよい
Data Aggregation
US
Alpha
3,000
US
Beta
1,250
JP
Alpha
700
Row #1
Row #2
Row #3
Page#1
Page#2

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
Page#1
Page#2
Page#1
Page#2
Page#3
US Alpha 3,000
US Beta 1,250
JP Alpha 700
圧縮の基本的な考えは重複排除ですが、
Row Storeの場合は、様々な属性値が混
在するため、効率的な重複排除が困難
Column Storeの場合は、同⼀ページに
は同⼀属性のみが格納されるため効率的
は重複排除(圧縮)が可能
Data Compression
Row Store Table
Column Store Table

カラム単位でDictionary/Value ID配列を作成
• Dictionary：ユニークなカラム値を格納 (位置がValue IDを⽰す)
• Value ID配列：全てのエントリーのValue IDを格納 (位置がRecord IDを⽰す)
• Inverted Index：値が同じ⾏のリスト (値はRecord IDの配列、位置はValue ID）
1 Belgium
2 Denmark
3 France
4 Italy
5 Spain
1 3
2 4
3 5
4 4
5 2
6 2
7 1
8 4
… …
1 7
2 5,6
3 1
4 2,4,8
5 3
Logical Table
Dictionaryには5件のデータ。
従って、3bitで符号化可能
Value ID配列
(bit fields)
Inverted
indexDictionaryOrder Country Product Sales
456 France corn 1000
457 Italy wheat 900
458 Spain rice 600
459 Italy rice 800
460 Denmark corn 500
461 Denmark rice 600
462 Belgium rice 600
463 Italy rice 1100
… … … …
Dictionary Compression

カラム内の繰り返し値を圧縮
§ ソート済カラムで有効に動作
Advanced compression
• Prefix Encoding
連続する値を値+繰り返し回数にエンコード
• Run Length Encoding (RLE)
連続する値に対して反復を削除して配列の開始位置を保持
• Linear Run Length Encoding (LRLE)
Seriesデータに特化したディクショナリー圧縮
• Cluster Encoding
配列を分割、全数同じであれば1⽂字置換
• Sparse Encoding
最も頻出する値を削除
• Indirect encoding
配列を分割、低カーディナリティであれば再度辞書圧縮
Order Country Product Sales
456 France corn 1000
457 Italy wheat 900
458 Spain rice 600
459 Italy rice 800
460 Denmark corn 500
461 Denmark rice 600
462 Belgium rice 600
463 Italy rice 1100
… … … …
Logical Table
1 corn
2 rice
3 wheat
1
3
2x2
1
3x2
…
Product
Dictionary
Advanced Compression

US
US
JP
Alpha
Beta
Alpha
3,000
1,250
700
Country
Product
Sales
Table
Page#1
Page#2
Page#3
JP
Alpha
700
JP
Alpha
1,000
Row #3
Page#2
Row #4
US
US
JP
JP
Alpha
Beta
Alpha
Alpha
3,000
1,250
700
1,000
Country
Product
Sales
Page#1
Page#2
Page#3
US Alpha 3,000
US Beta 1,250
JP Alpha 700
JP Alpha 1,000
Data Modification
Row Storeの場合は、1⾏の更新は、
1ページのアクセスでよい
Column Storeの場合は、1⾏の更新は、
カラム数ぶんのアクセスが必要。かつ、
圧縮も考慮する必要がある。
Row Store Table
Column Store Table
US
Alpha
3,000
US
Beta
1,250
JP
Alpha
700
Row #1
Row #2
Row #3
Page#1
Page#2

あー、だからDWH専⽤の
アプライアンスなのね。

そう。。。じゃないんです。
あー、だからDWH専⽤の
アプライアンスなのね。

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

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

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

スケール
認定H/W
設置場所
クラウドはインスタン
スタイプでの認定制度
スケールアップ
スケールアウト
オンプレミス
クラウド
提供形態
アプライアンス
TDI
ハードウェア
認定制度
物理サーバー
仮想化環境
SAP HANA デリバリーモデル
クラウド認定
プライベート(IaaS)
パブリック(IaaS)
パブリック(PaaS)

SAP HANA Certified H/W
インプリの⾼速性
SAPによる完全なサポート
• SAPとHWパートナー
によるバリデーション
• ハードウェアの事前
セットアップ
• ソフトウェアに事前
インストール
• 基本的にはHWのみの提供
• ユーザーにより各コンポー
ネント(OSを含む)のインス
トール作業が必要
• ユーザーは各コンポーネン
トのサポートモデルについ
て各パートナーと調整
さらなる柔軟性
既存IT資産とエコシステムの活⽤
アプライアンス TDI
HANA Server
Bundled
Storage
DRAM
Application
Database
OS
Virtualization
Network
Storage
HANA Server
Enterprise
Storage
DRAM
Application
Database
OS
Virtualization
Network
Storage

Scale Up/Scale Out Cluster
Scale Up Server
l 2CPU 64GB 〜 20CPU以上 20TB
l SoH、S/4HANA、BWoH、データマート
⽤途としてのSAP HANA
l HA/DRのサポート
Scale Out Cluster
l S/4HANA 1610 FPS01からScale-Outをサポート
l クラスターあたり２台以上のサーバー構成
l メモリーは256GB, 512GB, 1TB, 1.5TB, 2TB,
3TB及び4TB (S/4HANAのScale-Out構成は除く)
l 認定済みの最⼤構成: 94ノード@4TB/Server
(376TB)
l HA/DRのサポート

SAP HANA Certified Cloud
x 11 インスタンスタイプ
Public IaaS
Public PaaS
Private PaaS + IaaS
* SAPPHIRE NOW 2017でSCPもHECもAWS、GCP、Azure上での稼働を発表

Certified HANA Hardware Directory
http://global.sap.com/community/ebook/2014-09-02-hana-hardware/enEN/appliances.html

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で克服すべき課題
データベースは、同時に多数の更新処理を処理します。
(⼀般的にTPSやTPMというベンチマーク指標で表されます)
ただ、同時に同じリソース(レコードよりもっと⼩さな粒度の
内部リソース)に対して更新してしまうとデータの⼀貫性が
保たれません。
なので、同⼀リソースに対する同時実⾏性の制御が
データの⼀貫性とパフォーマンスにおいて重要な課題になります。
ここの制御や実装が課題

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

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
ログ
ログ
ログ
ユーザーの要求により
ディスク上のデータを
キャッシュに載せる
1
各トラザクションの更新
はキャッシュを直接更新
する
3
有限のキャッシュ領域を
LRUで管理
2
更新の確定の前には必ずログ
に更新履歴を同期書き込みで
書く
(Write Ahead Log=WAL)
3
更新されたキャッシュは
遅延書き込みによりディ
スク上に永続化される
(Checkpoint)
4
Atomicity Consistency Isolation Durability

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
ログセグメント

論理ページ
P100
P101
P102 P103
物理ページ
(Disk)
論理P 物理P Flag
L1 P100 0
L2 P101 0
L3 P102 0
L4 P103 0
L1 L2
L3 L4
変換テーブル
(Memory)
初期状態
L1 L2
L3 L4
L１が更新されるセーブポイント中
L1 L2
L3 L4
P100
P101
P102 P103
P104
L1 P104 0
L2 P101 0
L3 P102 0
L4 P103 0
P100
P101
P102 P103
L1 P100 1
L2 P101 0
L3 P102 0
L4 P103 0
(シャドウページ)
(差分ページ)
セーブポイント
Shadow Paging
C001
(変換テーブル)
C001
(変換テーブル)
C001C001
(変換テーブルの
シャドウページ)
(新しい変換
テーブル)
* シャドウページはセーブポイントが正常終了後に再利⽤可能になる(free)

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のサポート
(1511 / 1610)
• SoH / BWoHのサポート
(NetWeaver 7.49以降)
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

Shadow Paging
HANA Snapshot/差分、増分バックアップ/System Replicationなど
L1 L2
L3 L4
P100
P101
P102 P103
P104
L1 P104 0
L2 P101 0
L3 P102 0
L4 P103 0
(シャドウページ)
(差分ページ)
C001C001
(シャドウページ
の変換テーブル)
(新しい変換
テーブル)
変換テーブルからどの論理ページ、
物理ページが差分(or 増分)なの
か⾼速に追跡可能
変換テーブルを含めて、セーブポイント完
了までは前回のスナップショットが維持さ
れているので、安全にリカバリー可能
ちなみにリカバリーのためのUNDOは、通
常のページと同じ仕組みで永続化される
さらに任意のタイミングで(セーブポイントと
は別に)スナップショットを取得可能。その場
合は、明⽰的(コマンド)で削除しない限り、ス
ナップショット(シャドーページ)は削除されな
い。
バックアップは内部的にスナップショットを
取得し、断⾯を揃えて、該当ページをバック
アップメディアとして出⼒
System ReplicationのInitial Data Copyなど
は内部的にバックアップと同等の動作

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

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

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

Data Compression
Traditional DB
Application
HANA
Application
HANA4x(*1)
up to
2.5x(*1)
up to
Simplified
Application
SAP HANA DB の
カラム型ストア
による⾼い圧縮率
アプリケーションコード
とデータモデルの
Simple化による
冗⻑データの削減
1/10(*1)
データフットプリントの縮⼩
1/10(*1)
データモデルの Simple化
集計・インデックステーブルの削減によるデータ
フットプリントの縮⼩
HANAの⾼圧縮率
カラムストアの⾼い圧縮率による
データフットプリントの縮⼩
(*1) 圧縮効果は当社⽐

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

Multistore Table
パターン1 (結合(UNION)をHANA側で実施)

Multistore Table
パターン2 (結合(UNION)をDynamic Tiering側で実施)

Multistore Table
パターン3 (Partition Pruningによる効率的なアクセス)

ピーク時でサイジングすると
HANAのCPUがスパコンレベル
で必要になるんですけど、何
かよい考えないですか?

ピーク時でサイジングすると
HANAのCPUがスパコンレベル
で必要になるんですけど、何
かよい考えないですか?
HANAにはコンテナーという
ナイスなサーバーコンソリ
デーションのソリューション
があるんですよ。

Schema X
SAP HANA Instance
App X
Schema Y
App Y
HW
OS
Database
Schema
SAP HANA Instance
App
HW
OS
Database
Schema X
Database
SAP HANA Instance
App X
Schema X
App Y
Database
SAP HANA Instance
Hypervisor
HW
OS OS
Schema X
Tenant DB
SAP HANA Instance
App X
Schema X
App Y
Tenant DB
HW
OS
SPS08以前 SPS09 マルチテナント
データベース機能
System DB
Multi Database Containers (MDC)
- Backup & Recoveryなどの
運⽤(SLA)とアプリケーション
の分割が困難
- スキーマ単位でのリソースの
制御が困難
- 仮想OSを含めたHANAを個別に
運⽤する必要がある
- 仮想OS単位でのリソース制御の
ため、ピーク時でのゲストOS間
でのリソースの融通等はできない
- 運⽤(SLA)とアプリケーションの分離
- テナントごとのリソースの制御
- ピーク時にはテナント間でリソースの
融通が可能
- 既存の運⽤が変わる可能性があるので
注意が必要

夜間バッチが終わらなくて、
システム部⾨の⼈が徹夜して、
とかよく聞くんですけど、
HANAにしたら、ちゃんと寝れる?

夜間バッチが終わらなくて、
システム部⾨の⼈が徹夜して、
とかよく聞くんですけど、
HANAにしたら、ちゃんと寝れる?
夜間バッチとか前時代的なこと
は、やめましょう。きっとHANA
なら毎⽇熟睡できますよ。

Virtual Data Modeling
1. Extract
2. Transform
3. Load
ETL
物理データ HANA
view
Qube
物理データ物理データ
仮想Qube
HANA
view
HANA
view
HANA
view
OLTPとOLAPをサポート
圧倒的なHANAの⾼速性
リアルタイムでのデータ
アクセスと柔軟な
モデリングを両⽴
Report Report
物理データ
キューブが⽣成されるまで、
多段での、物理データの移動
(バッチ処理)が発⽣
• HANA標準のモデリング
ツールによるデータモデ
ル構築
• 物理データの移動が伴わ
ないためリアルタイム性
を確保できる
• 構築されたデータモデル
に最適なHANAの実⾏エ
ンジン

このへんで、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

データベースがたくさんあって、
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

このへんで、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

SAP HANA
Database Service
Virtual Physical
ETL
Virtual Model
Real-Time
No-Data movement
Flexible data model
Application Service
機能
- データベースと独⽴してアプリケーションのスケールが
可能
- 開発⾔語の選択が可能 – JavaScript(node.js)、
Java(TomEE)、C++の実⾏環境
- SQLなしでもCore Data Services(CDS)によりデータ
ベースオブジェクトやリレーションを定義可能
- プログラミング⾔語サポートによる既存スキルの活⽤
- オープンソースコード管理ツール(Git/GitHub)によるア
プリケーション開発の迅速化
- アプリケーション、データベース間でSingle Sign-
On(SSO)を使ってシンプルな認証と認可
- JavaScriptやSQLScriptプログラムのスケジュール実⾏
が可能
メリット
- SAP HANAキャパシティの拡張を低TCOで実現
- デジタルインテリジェンスの再創造
- デジタルエコノミーへの橋渡し
Application Router
Authentication & Authorization
Web Application Server
JavaScript Node.JS Java TomEE C++ FastCGI
Repository
OData
SAP HANA Platform
Application Service

そうそう、最近なんか新しいの出た
よね。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

Hadoop Ecosystem
YARN
(Cluster Resource Management)
1 ° ° ° ° ° ° °
° ° ° ° ° ° ° °
° °
° °
° ° °
° ° °
HDFS (Text, ORC, Parquet, Avro)
(Hadoop Distributed File System)
Apache Spark
+ Vora plugin
ApacheMahout
SparkMLlib
SparkStreaming
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は現時点
(2017/04/28)で以下の制限事
項があります。
- Vora Disk Engine及び
Relational Engine(*)として
作成されたテーブルのみがサ
ポートされています
(*) Relational Engine:
Vora 1.4でリリースされた(置き
換えられた)In-Memory
Relational Engine
VoraのコンポーネントはYARNのリソース
管理外で実⾏されます
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 Vora
Vora Architecture Overview
S3 Swift

データの確認とデータのCSV
Export
REGISTER ALL TABLES
USING com.sap.spark.vora;
REGISTER TABLE <table>
USING com.sap.spark.vora;
右クリック
右クリック
SAP Vora Tools
Data Browser

チャートの描画設定
SAP Vora Tools
Data Browser – Draw Charts

グラフデータの表⽰
SAP Vora Tools
Data Browser – Graph Viewer

Time Seriesデータの表⽰
スライダーバーの表⽰
Time Seriesの描画設定
SAP Vora Tools
Data Browser – Time Series Viewer

SQLの経過時間の確認
コード補完を備えたSQLの実⾏環境
SQLの結果のCSV Export
トークンツールチップ
SAP Vora Tools
SQL Editor

各種ビューをGUIで作成
GUIからビューの作成
- ジョインキーのマップ
- 出⼒カラムの選択
- Calculated Column
- Assign Semantics
データのプレビュー
SAP Vora Tools
Modeler

でも、結局、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 リレーショナルエンジンの他に
Time Series、グラフ、ドキュメント、
ディスクなどの各種エンジンをサポート
– グラフィカルなモデリングツールをサポート
Ÿ コミュニティサポート
SAP Voraへの無償アクセス | 開発者に機能制限なしの利⽤ | 迅速なアプリケーション開発
開発者へのメリットhttps://www.sap.com/developer/topics/vora.html
SAP Vora, Developer Edition

Q & A
Any Question?

THANK YOU!

20170518_今さら聞けないHANAのハナシの基本のき by SAPジャパン株式会社新久保浩二

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to 20170518_今さら聞けないHANAのハナシの基本のき by SAPジャパン株式会社新久保浩二

Similar to 20170518_今さら聞けないHANAのハナシの基本のき by SAPジャパン株式会社新久保浩二 (20)

More from Insight Technology, Inc.

More from Insight Technology, Inc. (20)

Recently uploaded

Recently uploaded (11)