Skip to Content

从SAP HANA作为SAP应用加速器(SAP Application Accelerator)的方式,看ERP on HANA的春天

原文地址:www.hanapost.com

说到HANA,SAP之神技也!呵呵,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你也不会喜欢的。 image

当然最好的是使用SLT的方式来同步两个DB之间的部分数据库的数据,可以保证准实时,属于不中断现有IT架构提升和保护系统投资的一种方式,让传统的ABAP也能利用到SAP HANA内存计算所带来的效能。 当然这种方式也是有局限性的,比如ERP-HANA之间的数据复制是有一定的实时间隔的,虽然SLT能够做到非常非常的准实时,所以如果一个业务关联的几个数据表之间的数据如果不一致(复制延时造成的),那么使用加速器的方式必须能够“处理“这种不一致所带来的问题,或者说即使有一定延时也没有任何关系,毕竟世界上不存在真真的实时,比如万分之一微秒等,运维性或者日常的报表应该会比较适合这种方式。

”加速器“不改代码和优化过的代码的区别

这个加速器有2中实现方式的

  • 不改代码,仅仅HANA作为ABAP的READ数据的数据库,提升一些性能,工作量极其小,因为代码一行不改,只是换个数据库访问,所以性能的提升是有限的,当然如果提升到秒级,也不错,也就够了。(懒人方式)
  • 优化代码,修改原有的ABAP代码,将原来的SELECT 出来的东西,内标LOOP套LOOP中的计算逻辑在HANA中实现,极大提升性能,这种方式相当于要对原有的程序代码做修改,要迁移部分计算逻辑和取数逻辑到HANA中,然后ABAP再去访问,这个工作量大一些,要改代码,但是回报也是相当不错的。(勤快人方式)
    image

上图中,就是第二种方式,也就是所谓的优化代码的方式,我们现在所看到的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没用的人可以去金科路的豆腐摊买块豆腐撞死了,哈哈

下面是一个ABAP访问HANA数据的附件

下载-ABAP访问HANA的PDF文件 ABAP读取HANA里面的数据
5 Comments
You must be Logged on to comment or reply to a post.