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. andData 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 TREXtechnology. This is provided as appliancemodel & 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

SalesPage#3

全てのデータページ(ブロック)へのアクセスが必要

該当のカラムのページ(ブロック)へのアクセスのみでよい

Row Store & Column StoreData 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の場合は、同⼀ページには同⼀属性のみが格納されるため効率的

は重複排除(圧縮)が可能

Row Store & Column StoreData 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 Belgium2 Denmark3 France4 Italy5 Spain

1 32 43 54 45 26 27 18 4… …

1 72 5,63 14 2,4,85 3

Logical Table

Dictionaryには5件のデータ。従って、3bitで符号化可能

Value ID配列(bit fields)

InvertedindexDictionaryOrder Country Product Sales

456 France corn 1000457 Italy wheat 900458 Spain rice 600459 Italy rice 800460 Denmark corn 500461 Denmark rice 600462 Belgium rice 600463 Italy rice 1100

… … … …

Row Store & Column StoreDictionary 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 Sales456 France corn 1000457 Italy wheat 900458 Spain rice 600459 Italy rice 800460 Denmark corn 500461 Denmark rice 600462 Belgium rice 600463 Italy rice 1100

… … … …

Logical Table

1 corn2 rice3 wheat

13

2x21

3x2…

ProductDictionary

Row Store & Column StoreAdvanced 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 #3Page#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

Row Store & Column StoreData 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 WorkloadRow Store & Column Store


インメモリデータベース

デルタストレージメインストレージ

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 Serverl 2CPU 64GB 〜 20CPU以上 20TB l SoH、S/4HANA、BWoH、データマート

⽤途としてのSAP HANAl HA/DRのサポート

Scale Out Clusterl 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 21164A, 0.3GHz

Alpha 21164, 0.5GHz

Alpha 21164, 0.6GHz

Alpha 21264, 0.6GHzAlpha 21264A, 0.7GHz

Intel Pentium Ⅲ, 1.0GHz

AMD Athlon, 1.6GHz

Intel Pentium 4, 3.0GHzAMD Opteron, 2.2GHz

Intel Xeon, 3.6GHz64bit Intel Xeon, 3.6GHz

5

9

1318

24

51

80

117

183

280

481

649

9931267

1779

2584

41955367

57646505

Perf

orm

ance

(vs.

VAX

-11/

780)

25%/Year

52%/Year

20%/Year

History of CPU Performance

1980 1985 1990 1995 2000 2005 2010Pe

rfor

man

ce

10

100

1,000

10,000

100,000

Processor

CPU/Memory Performance GAP

CPU/Memory Performance Trend

CPU⾃体の純粋なスピード(クロックスピード)の向上は⾒込めないので、CPU内、CPUコア間での効率の良い並列処理が必要になる。

In-Memoryの世界だと、メインメモリーはCPUに⽐較して圧倒的に低速なので、メインメモリーに対して何も考えずにアクセスすると、皆さんが思うほどのパフォーマンスアップは望めない。

Processor-MemoryPerformance 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での同時実⾏性の制御- ロックやラッチ(semaphore、mutex)

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



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

物理

ペー

ジ(D

isk)

論理P 物理P FlagL1 P100 0L2 P101 0L3 P102 0L4 P103 0

L1 L2

L3 L4

変換

テー

ブル (M

emor

y)

初期状態

L1 L2

L3 L4

L１が更新されるセーブポイント中

L1 L2

L3 L4

P100 P101

P102 P103

P104


P100 P101

P102 P103


(シャドウページ)

(差分ページ)

セーブポイント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/OLog 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のスナップショットを利⽤して)

リカバリー

メモリー

ストレージ

データベース

ログボリューム

データボリューム

LogVolume Data

VolumeLog

Volume DataVolume

ログボリュームデータ

ボリューム

バックアップ

メモリー

ストレージ

ログボリューム

データボリューム

LogVolume Data

VolumeLog

Volume DataVolume

ログボリュームデータ

ボリューム

バックアップ

メモリー上にロード(+ UNDO)

REDO


Shadow PagingHANA Snapshot/差分、増分バックアップ/System Replicationなど

L1 L2

L3 L4

P100 P101

P102 P103

P104


(シャドウページ)

(差分ページ)

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


HANA System ReplicationDisaster 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 ログはセカンダリーサイトに同期転送される

l ログ転送は、セカンダリーサイトでのメモリー保存まで


LogData Data Log

メモリ

Asynchronous


LogData Data Log

バッファ

l ログはセカンダリーサイトと接続されているネットワーク経路にログ転送が開始されると完了。

l ⾮同期転送される

HANA System ReplicationReplication Mode

Transaction Transaction

Transaction Transaction

Bye


OS: DNS, hostname, Virtual IP

HA S

olut

ion

Part

ner

HA S

olut

ion

Part

nerPrimary

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でクエリーを実⾏

HANA System ReplicationHANA2 Read Enabled



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



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

⼤丈夫、安⼼してください。現実的(コスト⾯)な⼿段を提供しています。


Data Compression

Traditional DB

Application

HANA

Application

HANA4x(*1)

up to

2.5x(*1)

up to

SimplifiedApplication

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 FoundationData 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

HWOS

Database

Schema

SAP HANA Instance

App

HWOS

Database

Schema X

DatabaseSAP HANA Instance

App X

Schema X

App Y

DatabaseSAP HANA Instance

HypervisorHW

OS OS

Schema X

Tenant DB

SAP HANA Instance

App X

Schema X

App Y

Tenant DB

HWOS

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 HANADatabaseIn-Memory

Column StoreOLTP + OLAP

Single data copy

SIMD TSX

Real-time

CPU cycle0.3 ns : 1 s

Main Memory120 ns : 6 min

SSD:50-150 μs : 2-6 daysHDD:1-10 ms : 1-12 months

CPU

L1L2

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 PlatformDatabase Service



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



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

そのためにデータ統合機能もあります。

そもそも、全てをHANAに置く必要はないかもしれませんよ。


SAP HANA

Virtual Physical ETL

Virtual ModelReal-Time

No-Data movement

Flexible data model

Integration Service

ODataSAP IQ, SAP ASE,

Oracle, SQL Server, Teradata …

Data federationReal time/Batch ETL

Streaming Service

Remote Data Sync

Streaming Lite(IoT Gateway)

Devi

ce/S

enso

r

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 PlatformIntegration 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 VirtualizationSmart 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.5decision tree

Weighted score tables

Regression

ABC classification

KNN classification

K-means

Associate analysis:

market basket

SAP HANA

Spatial, IoT, Stream

Database Service



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 AlgorithmsText Analysis Engine:- ファイルフィルタリング/エンティティの抽

出、分類/ドメインファクトの認識Time Series Engine:- 効率的なシリーズデータの蓄積- 等距離、⾮等距離のシリーズのサポートDocument Store:- Schema on ReadのJSONドキュメント・ス

トア

SAP HANA PlatformProcessing Service

{JSON}

Document Store


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


データベースサービス

Web サーバ JavaScript

グラフィックモデラー

データ仮想化 ELT & レプリケーション

カラム型OLTP+OLAP

マルチコア & 並列処理

⾼度な圧縮

マルチテナントマルチティアストレージ

グラフ予測検索

データ品質

系列データ

ビジネス関数

Hadoop & Spark 統合

ストリーム分析

アプリケーションライフサイクル管理

HA & DRオープンスタンダード

データモデリング

管理 &セキュリティ

データ同期

空間情報

テキスト分析

Fiori UXALM

</>

アプリケーションサービスインテグレーションサービスプロセッシングサービス

S A P H A N A P l a t f o r m

SAP HANA Platform


SAP HANA

Database Service



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 RouterAuthentication & Authorization

Web Application Server

JavaScript Node.JS Java TomEE C++ FastCGI

Repository

OData

SAP HANA PlatformApplication Service



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



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

はい、はい、はい、はい。


ALL IN-MEMORY

Enterprise Compute Distributed Compute

CONSUM

E | COM

PUTE | 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

HANAOLTP + 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 VoraIn-Memory Data Fabric & Beyond


Hadoop Ecosystem

YARN(Cluster Resource Management)

1 ° ° ° ° ° ° °

° ° ° ° ° ° ° °

° °

° °

° ° °

° ° °

HDFS (Text, ORC, Parquet, Avro) (Hadoop Distributed File System)

Apache Spark+ Vora plugin

Apac

he M

ahou

t

Spar

k M

Llib

Spar

k St

ream

ing

Spar

k SQ

L+

Vor

a Ex

tens

ion

既存の開発環境が利⽤可能

SAP Lumira

Spark Controller

Other Apps

BW4HANA

SAP HANA Platform

In-MemoryDatabase

cv cv

Data Processing Engine

Smart Data Access

Virtual TableIn-Memory

Table

SQL

AWS

Analytics

HANAのSmart Data AccessでVoraにアクセスする場合は、従来からサポートされるSparkController経由もしくは、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認証が追加されています。

Vora

Rel

atio

nal,

Dis

k, G

raph

,Ti

me

Seri

es E

ngin

e&

Doc

umen

t St

ore

voraodbc

BATCH, INTERACTIVE & REAL-TIME DATA ACCESS

SAP VoraVora Architecture Overview

S3 Swift


データの確認とデータのCSV Export

REGISTER ALL TABLES

USING com.sap.spark.vora;

REGISTER TABLE <table>

USING com.sap.spark.vora;

右クリック

右クリック

SAP Vora ToolsData Browser


チャートの描画設定

SAP Vora ToolsData Browser – Draw Charts


グラフデータの表⽰

SAP Vora ToolsData Browser – Graph Viewer


Time Seriesデータの表⽰

スライダーバーの表⽰

Time Seriesの描画設定

SAP Vora ToolsData Browser – Time Series Viewer


SQLの経過時間の確認

コード補完を備えたSQLの実⾏環境

SQLの結果のCSV Export

トークンツールチップ

SAP Vora ToolsSQL Editor


各種ビューをGUIで作成

GUIからビューの作成- ジョインキーのマップ- 出⼒カラムの選択- Calculated Column- Assign Semantics

データのプレビュー

SAP Vora ToolsModeler



でも、結局、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ジャパン株式会社...

Technology