I AM A ABAPER！
科技的进步，一定会使一些东西变得越来越精简!
大道至简！！！
文章很好！！！！！！！！！！！
--------------------------------------------------------------------------------------------------------------------------
转自：http://blog.sina.com.cn/s/blog_9154db5301019udr.html%20
说到HANA，SAP之神技也！呵呵，你要说我很疯癫，我就说你很2B，HANA除了作为一个高性能的实时数据平台之外，还有很多种用途（典型的手指图，5大类的应用），最近也有很多人听说HANA作为应用加速器的这个话题，这个东西是SAP AGS最初为那些Max Attention合同类型的大客户（比如两桶油公司，一头电公司这种大家伙）做SAP HANA项目快速原型法衍生（不需要修改ABAP代码，快速提升ABAP程序的性能）出来的方式，大家的问题如下：
这个东西是不是ERP on HANA的原型呢？不是!
这个东西是不是和CO-PA on HANA一个原理呢？原理相同，但是，但是，但是CO-PA on HANA的里面还包含了一些其他的增强和优化过的代码
将来是否ERP ON HANA是否仅仅的只是替换掉数据库这么简单呢？其实仅仅替换掉数据库也可以运行，SAP ERP抽象底层数据库的，MaxDB作为ERP的DB不也是跑的好好的吗？但是为了让ERP ON HANA跑的更好，更快，原先的ABAP系统代码和内核肯定会在将来做一些更新和优化，将ABAP-HANA做深度的集成和优化！
HANA作为SAP 应用的加速器的理解
关于HANA的应用，有很多种不同的应用，本文中介绍的HANA的其中一种应用，从名称来看，HANA作为SAP应用加速器，意味着原有SAP的系统的用户访问方式都不发生变化，但是在速度上可以有所提升，一句话，我还是用过去的ABAP代码写的SAP GUI的方式来做交易，但是速度比以前快了很多。
还是SAP NetWeaver Basis模块牛逼啊！
SAP 的ABAP的Kernel版本是一直在升级中的，而且ABAP一直也是从来都支持Second DataBase的，很早很早的Kernel版本开始就支持Second DB了，例如客户上了一个ERP，底层数据库是Sybase ASE/Oracle/DB2/SQL-Server/MaxDB，比如，我们可以说ERP on Oracle的方式，因为中间有一个抽象层，所以SAP的ERP系统根本就不在乎你底层是什么数据库，对上层的ABAP Stack来说，没什么太大区别。此时如果用户希望ABAP代码取得数据的来源是外部的Database系统，那么可以给ERP定义个一个第二数据库（Second Database），这就是所谓Second DB的说法和意思，之前的SAP ABAP Kernel大概可以支持4+种以上的数据库。
但是从NW 7.21 Kernel 的版本，SAP HANA就可以作为ERP的Second DB了，意味着从ERP中的ABAP代码中，不仅仅是访问ERP本地数据库，还可以访问HANA，利用HANA高性能的计算能力。
但是从NW 7.30 Kernel开始，SAP HANA将可以作为SAP ERP（Business Suite/ECC）的主要数据库，就是ERP on HANA的意思，这个全新的Kernel当前在BW 7.3 on HANA上面已经发布了，目前国内的一些客户早已用起来了（例如：农夫山泉，联想，大众车车公司），所以从不远的地方我们就可以很清楚的看到ERP ON HANA，太他妈正常了，当然年底很快很快发布第一个ERP on HANA的版本，这里我们就不多说，我们也不吹嘘，我们看SAP的实际行动啦！（SAP奥兰多蓝宝石大会-5月份宣布将在下面几个月发布ERP ON HANA的全球客户的Ramp-up项目）
这对于Oracle的震撼不是一点点啊！绝对是震精四野的消息，各位ABAPer又要活血了，估计ERP将来的代码又得大改了。
”加速器“原理和限制点
既然是加速器，就是说这个加速器是提供速度上的性能提升，比如某个SAP事务代码运行效率较低，使用ABAP Program Tracing和分析之后，看看ABAP和DB的访问时间的所占比列，是否正常，如果ABAP程序没有太多提升的空间，可能会调整数据库表的索引等，但是这些毕竟是有限的，HANA来了，所以自然而然鬼点子就来了。
从下面这张图中，我们可以看到ERP的原有数据库表基本是-完整的复制到HANA的，然后原有的ABAP程序 仅仅只是在使用HANA去加速原有程序的READ部分（SELECT xxx FROM TABLE abc）,原有的数据更新到ERP自己的数据库均不发生改变。就是说只加速读的部份，DEL/UPD/INS都不涉及。这种方式能够将HANA的对于数据的分析和计算应用到极致，在原有的基础提升10~20倍的速度，而且不用修改ABAP代码，喜欢用SAP GUI的客户们就继续使用吧，反正给你花里胡哨的BO你也不会喜欢的。
当然最好的是使用SLT的方式来同步两个DB之间的部分数据库的数据，可以保证准实时，属于不中断现有IT架构提升和保护系统投资的一种方式，让传统的ABAP也能利用到SAP HANA内存计算所带来的效能。
当然这种方式也是有局限性的，比如ERP-HANA之间的数据复制是有一定的实时间隔的，虽然SLT能够做到非常非常的准实时，所以如果一个业务关联的几个数据表之间的数据如果不一致（复制延时造成的），那么使用加速器的方式必须能够“处理“这种不一致所带来的问题，或者说即使有一定延时也没有任何关系，毕竟世界上不存在真真的实时，比如万分之一微秒等，运维性或者日常的报表应该会比较适合这种方式。
”加速器“不改代码和优化过的代码的区别
这个加速器有2中实现方式的
- 不改代码，仅仅HANA作为ABAP的READ数据的数据库，提升一些性能，工作量极其小，因为代码一行不改，只是换个数据库访问，所以性能的提升是有限的，当然如果提升到秒级，也不错，也就够了。（懒人方式）
- 优化代码，修改原有的ABAP代码，将原来的SELECT 出来的东西，内标LOOP套LOOP中的计算逻辑在HANA中实现，极大提升性能，这种方式相当于要对原有的程序代码做修改，要迁移部分计算逻辑和取数逻辑到HANA中，然后ABAP再去访问，这个工作量大一些，要改代码，但是回报也是相当不错的。（勤快人方式）
上图中，就是第二种方式，也就是所谓的优化代码的方式，我们现在所看到的BW 7.3这个版本，就是优化过的ABAP代码来访问ABAP的方式，将很多的计算逻辑下沉到HANA数据库层来做，主要是为了发挥IMDB的高性能，否则如果还是ABAP APP层来做，没啥意思。
什么什么on HANA，所隐含的东西？
我们现在看到很多XXX on HANA，例如SAP HANA官网上所列出的CO-PA on HANA Accelerator，还有BPC on HANA，XXX on HANA，Finiance on HANA，这种RDS(快速部署的解决方案)应用现在SAP发布了越来越多，什么意思！这其实是很大一盘棋啊！兄弟姐妹们，SAP ERP的代码和模块有多少，如果一行代码不改就ERP ON HANA，行吗？行，绝对没问题！
但是这样也就太没创意了，SAP要做的是一个全新的，能够真正利用到HANA高性能内存计算能力的ERP on HANA版本，而不是简单的把底层数据库换掉就OK了，SAP要做的是一步一步的不断提升ABAP，以及打造以HANA为基础平台的ABAP应用，怎么做呢？假设我们不知道SAP的战略方向吧！那我们就开始揣想吧！
- ABAP现在可以访问HANA了，READ没问题对吧
- BW 7.3 on HANA了，而且HANA作为数据库的存在，其实这里就是ABAP on HANA，我们可以这里理解对吧
- 即将推出的SAP ERP on HANA第一版，但是这里的ERP on HANA应该不是所有模块的代码全都是针对HANA优化过的，但是应该很多目前应用的有问题或者有待提升的模块都会on HANA.
举个例子，我们现在又CO-PA on HANA对吧！我百分之百的相信ERP ON HANA的这个版本自动默认就包含了CO-PA on HANA的全部代码和功能，当然还有Finiance on HANA的部份！那么你会觉得这些RDS有什么作用和目的吗？
XXX on HANA的意思，就是在ERP on HANA未发布之前，将所有新开发的应用或者原有的一些应用基于HANA平台来做，如果此时用户买了HANA，那好，直接买！如果用户没有买HANA，没关系，后面的ERP ON HANA中，会直接把这些所有的XXX on HANA全部包进去，这样第一个ERP on HANA的版本中就会有很多模块的应用都是重新优化过的了，当然还有一些原有的代码，当然我相信这是SAP ERP on HANA的一个必经之路！
结尾和供参考资料
关于怎么ABAP read data from HANA，本文中没有提及，因为很方便，Google随便一查，文章到处都是，我就不费口舌了，只是从这个加速器的方式来揣测SAP是如何将整个庞大的ERP的全部或者一步一步的搬移到HANA上去的。
SAP会不断持续的加大投资和更加加大力度的发展ABAP的技术的研究，会将ABAP-HANA的融合提升到一个全新的高度（例如：自动生成HANA中一些数据接口，读写这个接口，就等于是更新HANA DB等），那些认为ABAP没用的人可以去金科路的豆腐摊买块豆腐撞死了，哈哈