【转贴】SAPHANA内存数据库详解
SAP HANA内存数据库详解
1. 从废话开始
2. SAP HANA快熟介绍
3. 关于内存数据库
4. 不⼀样的架构，深⼊了解⼀下吧
5. 基于HANA的应⽤，HANA Store？
6. 期待的HANA全路线图
7. 有待提⾼之处
8. 附录
1. 从“废话”开始
在介绍SAP HANA这个产品之前，我们来谈点别的, 好吗？⾏的话，请继续看，否则⼤家直接跳过这节吧！
现在的企业需要什么？时间就是⾦钱？效率就是⽣命，⼤家都是喊这样的⼝号，让ERP和企业的信息系统跑的更健壮，更稳定，不断的扩⼤硬件投资，但是这仅仅是让企业的信息系统以稳健的⽅式来提供企业管理者所需要的信息⽽已，⽽企业决策者其实想要的更多: Anywhere, Anytime, 说的简单，做到就难了，随时随地，想看就看，还要看的痛“快”对吧！
⼀般的企业实施了ERP信息系统之后，这是企业核⼼的管理应⽤，会应⽤⼀些商务智能分析软件（⽐如SAP BW）进⾏业务数据的抽取（从ERP, CRM, SCM, HCM，⾃开发系统作为数据源），筛选，建模，重新创建出适⽤于企业管理的运营报表，展⽰给最终的⽤户看的时候可能是使⽤（SAP Business Object）来展⽰，因为⽐较美观，直观，简单，还吸引眼球。
宁静致远图片“⽩天跑业务，晚上抽数据，隔天看报表”，您那就凑合着⽤吧！现状如此，如果能有所改变，您是否愿意？
⼀般来说，⽬前企业信息化现在⼀般来说，基本这个状态，并不是这样不好，只是，如果企业能做到Anywhere, Anytime, Superfast… 为什么不呢？下⾯这个是⽐较理想的⼀种状态，⼏乎实时，决策时刻，⽆须等待。
安吉旅游必去的景点我们卖软件，卖服务，买升级，买各种新应⽤，说到底⽆⾮是2个字“价值”，到底给企业，给决策者带来什么好处，这是我们最关注的，到底我实施HANA能给我受益什么东西吧？有话直说。
简化企业应⽤平台，⽽不必中断现有的应⽤系统
向“迅捷性”迈进⼀步，实时⼯⼚，实时管理，实时监控，实时分析，Anywhere, Anytime.
将企业的业务数据彻底的从系统中解放出来，发挥最⼤的价值
全新的基于内存计算的平台（我是⼀个平台，不是⼀个空盒⼦）
总之，最重要的⼀点，就是让数据飞快，应⽤飞快，这应该够了吧！当然，这是当前HANA的版本可以实现的，其实HANA还有更加宏⼤的远景和计划图（正在完成中，每⼀步都让企业和未来更近！）
什么是迅捷企业，迅捷= 迅速+敏捷？
现在的移动应⽤⾮常发达，平板电脑/⼿机对于企业的信息化处理不能像过去⼀样了，瞬息万变的商业机会很快就会溜⾛，如果企业能在任何时间段都能对企业的信息资源可以⽴即了解，这对于商业决策的快速决策是有⾮常⼤的影响的。
怎么样才能迅速的抓住这些商业机会呢？⾸先是企业⾃⾝对信息系统中的数据，加⼯整理的功夫要⾮常厉害，这点在很多成熟的企业中都做的很好，但是仅仅是这样还不够，还需要什么呢？还需要⼀个超快的内存数据库和⼀个超级引擎来完成结果的计算，HANA正式为此⽽⽣的。
2. SAP HANA 快“熟”介绍
根据SAP的字⾯意思理解，SAP HANA是硬件和和软件组合起来⼀个解决⽅案（Appliance, 装置），使得客户分析海量数据，⽽且是以接近实时的⽅式来同步数据，不需要花费太多时间在数据传输上，⽬前HANA的版本是1.0.
他集成了⼀些SAP的组件，⽐如IMDB(In-Memory Databa), Syba的Replication 技术，以及SAP STR(Landscape Transformation Replicator)等等。
SAP HANA作为⼀种第3⽅硬件合作伙伴共同合作⽽优化打造的应⽤，⽬前⽀持和认证的硬件⼚商，包含HP, IBM, 思科, 富⼠通，戴尔5家合作伙伴，据说给联想LENOVO做的HANA⽅案，是使⽤的联想⾃⼰的服务器，应该也可以。但是⽬前不在SAP通⽤实施的合作伙伴范围之内。
在官⽅的⽂档，HP的硬件在⽂档中排名第⼀的，列表中根本没有提SUN 的系统什么的，你也知道，甲⾻⽂是SAP的竞争对⼿！噢耶！我就是SAP粉丝，肿么了.
3. 关于内存数据库(In-Memory Databa)
市场上基于内存计算的数据库产品有⼀些，这⾥就不多介绍，为什么呢？可否让企业的信息化的架构简单⼀点？怎么样简单呢？我希望基因相同，⾎统纯正，不要让⼀个“简单”的信息化架构变成异常复杂和异构的那种⼤架构。一什么操场
因为，把复杂的东西变“简单”，那才是真的不简单，IPhone/IPad为什么这么受追捧，是有道理的，HANA也是⼀样，通俗⼀点说，就是“空间换时间”，以前数据放磁盘保存读取，现在放内存，你说能不快吗？
SAP IMDB(In-Memory Databa)是⼀个内存数据库的混⾎⼉，不仅包含⾏存储，也包含列存储，⽽且还有基于对象存储的数据数据库技术，这么设计的主要⽬的是⽤来充分挖掘和使⽤现代多核CPU架构设计所带来的并发处理能⼒，毫⽆疑问，SAP的这种应⽤能从中受益颇多。
IMDB是SAP HANA的核⼼，⽤来帮助客户提升运营效率，敏捷⽽且灵活，下图来⾃SAP HANA的Technology of Manual中图⽚。
IMDB⽀持多种数据源，⽬前⽀持3中数据replication⽅法，并且提供了⼀个管理界⾯，这边叫admin studio，⼀般的监控和新modeling 都可以在这⾥实现。
然后⽀持2种客户端，⽤来⽣成基于内存存储⽽产⽣的报表等，当然这些外围的⼯具是不断的扩充的。
3.1 SAP HANA Replication Technologies-数据复制技术
SAP IMDB所产⽣报告和分析所需要的业务数据是需要从源系统复制到SAP 的IMDB. 具体怎么复制这⾥现在提供了3中⽅法，在看具体有那3中⽅式之前，先看这个IMDB的核⼼中有哪些会参与到数据Replication的场景：
SAP HANA由IMDB和IMDB Admin Studio组成，UI主要⽤来管理HANA的应⽤装置，有点类似BO的仪表盘界⾯
Source System，例如ERP ,BW, CRM等
当然还有⽤于⽀持数据复制的软件组件
1. Trigger-Bad Replication
这⾥暂且称呼为实时模式，虽然也需要⼀个Landscape Transformation Replicator，实时扑捉SAP ERP的数据库系统的修改变化，然后⼏乎是是实时的就同步到HANA中，这个Replicator可以直接安装在ERP上，⽐较⽅便，也可以独⽴的安装在⼀个服务器中，也⽤于扑捉实时ERP的数据库修改变化。
2. ETL Bad Replication
这⾥暂时称呼为BO模式，需要⽤到BO的Data Service组件，意味着需要有BO，优点是可以对抽取的数据做合并和加⼯处理，⽀持多数据源和多⽬标系统, ETL也就是⼀个数据抽取然后传输（可以再加⼯）的组件
3. Log Bad Replication
这⾥暂时称呼DB LOG模式，因为这种模式对于数据的要求是有依赖的，⽽前2种都是独⽴于任何任何数据库的，我⼀般不推荐使⽤，除⾮客户制定使⽤这种⽅式。
所以⼀看数据复制技术的排序⽅式，就知道了，肯定是重要和好的放在前⾯，这就像在⽀持硬件中,HP惠普排名第⼀⼀样，总不能以上来就直接吧LOG BASED 复制技术，放在第⼀，然后跟着说这种⽅式不推荐吧！所以拍⼤腿也知道，前⾯两种是重点对象。
详细对⽐，SAP HANA TOM上有详细描述，3中⽅式各有千秋，看你的的业务需要什么样的模式了，这⾥不谈好坏，只谈差异！
4. SAP HANA, 不⼀样的架构
不想了解⼤致架构和组件的同学，请直接忽略本章
也是刚刚开始学习HANA的⼀些知识，⼀边看书⼀遍做笔记，说到底⽆⾮是⽤⾃⼰的语⾔来理解标准帮组⽂档所讲解的意思，肯定有理解失误的地⽅，毕竟没有参加过标准培训，即使有培训，从⽼师那边来的知识也不可能是完整的传授过来，中间多少的知识遗漏是正常的，所以多看看HELP的⽂档，应该可以原汁原味的理解作者的意思。
这张图⽚是从SAP HANA的PPT上剪辑下来的，主要包含了SAP HANA的应⽤架构和在应⽤中会涉及到⼀些周边软件环境。
4.1 HANA架构下的亲戚关系
SAP HANA的实施需要远亲，近亲，朋友，兄弟等等帮忙
IMCE Studio
⽤于HANA的系统管理，以及信息建模（各种维度，KPI等），是⼀个客户端的⼯具，基于Eclip平台开发
ERP
这⾥指的是⼀般的数据源，会从ERP过来过来的业务数据，好吧，我们就是SAP ERP
BO BI4
BO的BI 4.0平台，主要提供ETL的核⼼功能，源系统数据导⼊，删选/合并/格式化数据，再导⼊⽬标系统
Other Source System
其他的数据源, Syba, DB2, Oracle, SQL-Server等主流的数据库都⽀持，当然，还可以⽂本XML, CSV,EXCEL都可以。
In-Memory Computing Engine
IMCE的核⼼组件部分，⽤于计算数据和纬度
Clients
客户端的⼯具，⽤什么⽅式浏览⼯具（查看报表或者查询），或者⽤什么⼯具来展现数据（报表设计⼯具，是⽤Explorer还是⽤Web Intelligence, 或者⽤Crystal Report也是可以的，这⾥不多加描述）
以上这些都是在实施SAP HANA的时候，所涉及到到⼀些组件和设备等，然后下⾯就这些不同的⼯具来做⼀个详细的解释和分类。
4.2 和数据导⼊相关的
Modeling ⼯具中可以创建数据库表
Replication Agent（这⾥可能是使⽤SLT实时同步的情况下），可以安装在ERP中作为⼀个但单独的组件，监控应⽤层的数据库修改，然后可以同步到HANA的数据库
Data Service Designer⽤来创建数据的source，以及target， 可以做mapping，作为ETL的⼯具，⽐如创建定时的作业，这样可以定期的从source system抽数据，然后导⼊到HANA的数据库中
Data Service是服务器端（虽然使⽤DS作为ETL的⼯具，然后DS依然需要⼀个数据库来⽀持，注意！不是⽤来存储从ERP来的数据，然后传输到HANA中，是⽤来保存⼀些mapping关系的资源库）
4.3 和数据建模相关的
同样，Modeling⼯具（就是HANA的Admin Studio），⽤来创建数据模型，Attribute View，Analytical View，Calculation View，在Modeling⼯具中可以直接查看HANA中数据库表，也可以创建表等。
Meta Data Manager
SBO Information Design Tool, ⽐如创建⼀些Business Layer，然后发布成Univer，这样其他的BO的报表设计⼯具就可以使⽤这个基于Univer的数据模型了，然后开发出查询报表，等等。
Data Service Designer，除了帮助load 数据之外，它提供了Job导⼊，筛选数据等，重新合并数据源等等。
4.4 和报表计算相关的
MS Excel – BI Analysis for MS-Office Edition, 是个插件⽤来浏览报表⽤的
BI4 – Web Intelligence 可以⽤来做基于Univer发布的报表，稍微⽐Explorer灵活点
4.5 和HANA管理相关的
例如备份和恢复都是在IMCE Studio⾥⾯做的，和Information Modeling同⼀个界⾯，只是切换到管理视图的话，就可以看到⽤户，⾓⾊，schema等，以及HANA的服务的⼀些系统状态。
Persistence Layer持久层
HANA的服务器中⽤于储存数据的⾮闪存空间, HANA中的数据都是保存在内存中的，⼀拉闸停电，数
狮子座和白羊座配吗
据就没有了，虽然服务器掉电的情况发⽣很少，但是这⾥还是解决了这个问题，当然不是专门为停电⽽解决的，⽐如数据库休克了或者HANA服务器死机了，必须重启的情况。它有以下的功能 记录Log信息，包含last save point和因为停电⽽没有写⼊数据库中的那些log信息。
这⾥可以看到从HANA的内存写到Persistence Layer的数据，包含了2个部分：Data和Log，这个过程是持续不断的过程，当然中间有⼀定的时间间隔，其实Persistence Layer就是HANA的内存数据库的某个时点的⼀个完整的镜像拷贝，以及这个拷贝之后所所有发⽣的数据库更新的Log信息（在停电前成功执⾏完毕的）
为什么不直接写⼊磁盘保存呢？
因为HANA基于内存数据库(new DB)，这种实时数据同步操作或者实时数据的更新是很快的，但是磁盘的读写速度往往和内存的速度有差异，为了解决这个问题，在硬件层⾯提供了⼀个闪存（即使断电，还有数据，有点像快速缓存，这个闪存有2~4 TB左右）⽤来同步保存内存数据库中的log信息，并且⽣成Save Point，然后写⼊真正的持久的磁盘存储。
硬盘/固态存储, 闪存硬盘？
Disk Storage⽤于保存和备份HANA的数据库，因为Persistence Layer的容积是有限的，所以HANA的
备份都是放在外部的物理存储的，⽐如⾼速率的硬盘或者其他的设备。在备份数据和恢复数据的时候会⽤到，⽐如重启服务器。
备份是从Persistence Layer到Disk，原因上⾯已经解释了，为了不影响HANA的运⾏，以及读写速率差异的问题。备份可以设定时间，⽐如每天⼀次，还是⼀周⼀次等。
注意：
⽂中特别之处，当前的版本1.0（SP12）不⽀持Log的备份以及Configuration⽂件的备份，这些必须⼿动的拷贝出来备份，下个⼀个版本应该会解决这些问题。17英文
4.6 和备份恢复相关的
数据备份，从Persistence Layer备份到外部的存储系统，⾃动化处理
⼯具：IM Computing Studio 中有备份和恢复的功能可以使⽤
log备份, 暂时没有⾃动化，需要⼿⼯，不是体⼒活哦
Configuration 备份，没有⾃动化，需要⼿⼯
系统恢复的话，需要：
最后⼀个SAVE POINT
以及发⽣在这个save point之后成功被写⼊持久层的关于DB更新的log（不可以是损坏的⽂件）
恢复到什么地⽅到，看上⾯图⽚，红线之前的数据库的状态能全部还原。
5. 基于SAP HANA的应⽤，HANA App Store？
基于SAP HANA的第⼀个应⽤是SAP Business Objects – Strategic Workforce Planning, ⽬前基于HANA的应⽤还不是很丰富，当然这也是SAP⽬前正在全⼒以赴在做的事情，我理想中的状态是，SAP可以发布基于HANA的应⽤然后，客户可以下载，然后在HANA中直接应⽤，这不是很好吗？
HANA的发布很突然，像个秘密武器⼀样，横空出世，保密⼯作做的好啊！但是⾄少我们现在知道，HANA的后续应⽤开发会越来越多，当然企业可以⾃⼰基于HANA开发⾃⼰的应⽤，也可以使⽤SAP标准发布的HANA应⽤。
5.1 SAP官⽅HANA应⽤
什么是民谣
SAP官⽅⽬前加⼤了HANA Bad的业务应⽤开发，企业财务，销售预测，库存管理等等⽅⾯都会有新的应⽤出来，应该是⽴即部署，就可以⽴即使⽤的，如果做的像Apple Store的那样，或者直接就延续现在的SAP Service Marketplace⽅式，在上⾯发布HANA的应⽤，也挺好。
5.2 SAP相关的ISV的参与
SAP 的⽣态圈是做的⽐较好的，⽆论是在Portal上应⽤开发，还是围绕SAP核⼼的ERP的上的⼀些开发，都有很多很多的第三⽅的公司参与，⽽且很多都是⾮常优秀的产品。
同样，基于HANA的应⽤，ISV也可以参与开发，发布到SAP的HANA App Store.
5.3 客户⾃定义开发
之前有幸参与了HANA的⼀个项⽬实施，也是很受启发，也蛮震撼的，速度之快，以及开发部署的⽅便性，都⾮常让客户满意。
相⽐之下，BW的流程，创建创建Data Source, Cube, Key Figure, Characteristics, Transformation Structure, Load / Delta Load，然后创建Query还是蛮漫长的。
HANA基本上就是3步骤：
导⼊表，需要⼏个就导⼊⼏个，可以不
基于表，拖拽关联关系，建模型，这个过程⾮常短，因为所有的数据都有了，没有BW中的Information Structure这么⼀层
BO出最终⽤户的报表，效果还是⾮常不错的.
6. 期待的HANA全路线图
HANA是基于内存数据库（In-Memory Databa）的⼀种应⽤，⽽这个内存数据库（newDB）是可以在任何的业务平台上使⽤的，这是毫⽆疑问的，也是SAP正在努⼒做的事情，到今年的年底，SAP的BW的数据库(不管⽬前是DB2, Oracle，还是SQL-Server)就能切换能到内存数据库（newDB），当然以前BW的上的业务模型该怎么弄还是怎么弄，应该没变化。
类似以前的BW Accelerator（BW加速器）⼀样，它也是基于内存数据库的⼀种应⽤，也是最早的基于内存计算的⼀种SAP应⽤。
如果ERP的数据库也能基于HANA的，那是⽐较爽的，数据的读写，以及整个SAP ERP系统的执⾏效率都应该会有很⼤的飞跃，BW系统的数据库据说年内会替换成内存数据库。
HANA没有直接从SAP ERP开始，不是因为现在技术做不到，⽽是让客户接受和推⼴市场的时候需要⼀个循序渐进的过程，选择从BW-加速器作为HANA应⽤的第⼀块砖，是因为BW只是基于数据做分析，基本上没有业务数据的修改等问题，对客户来说⽐较保险和安全。
然后是替换BW的数据库，然后将ERP的底层数据库替换成HANA，这样⼀步⼀步的⾛，是个不错的路线图！
7. 有待提⾼之处
HANA⽬前的版本是1.0 SP3的版本，貌似，不过版本好像更新的很快，升级⾮常容易，⽐ERP容易多了，呵呵！但是我还是有些意见要说：
跳绳记录
HANA的管理⼯具中有⼀些⼩Bug，需要修复
HANA的权限说明配置⽂档，需要再详细⼀点
Calculation View（图形模式时候）中的Script步骤好像不work，没有找到相关的⽂档说明，头疼
Analytical View的时候如果能⽀持更加⾼级的过滤就好了，⽐如可以设定只显⽰某列的最⼤值的那⼀⾏记录.
当然，对于新的产品我们要有耐⼼和信⼼，毕竟SAP出品，品质还是有保障的。
色成
