Skip to Content

     HANA从11年的1.0 到目前最新的SP5,已经经历了不停的完善,虽然或多、或少的因为版本升级而造成的模型需要重新的麻烦,但让人高兴的是,HANA从单一的后台数据库发展到了一个支持中间应用的扩展解决方案(当然从目前的这个方案依然有很大的限制,服务器的开发语言是JS,对前端的支撑仅为O-Data与XMLA的两种方式,详细请参考SAP Note,1779803)。这种很小的变化使得原来核心得到了有效的扩展,从原来的SQL/MDX两种方式,扩展到了工业标准。

      这种很小的变化,让未来几年的企业级架构发生了很大程度变革打下了一个很好的基础。最初的HANA作为一个数据库技术的时候,所提的技术点是基于内存的计算,通过内存技术,有效避免硬盘读写时候的瓶颈。

     但这不是唯一的技术变革,HANA将原来的行式存储变为列式存储(这是去年的技术点,很多人会好奇,为什么行与列的存储会让性能有很高的提升呢?本质上行与列存储都不是新技术,关系型数据库技术的变革与创新比几十年前的创新少了很多很多。列存储有效解决了数据压缩的问题的同时,相当与每个列都变成了一个独立的表,这种方式对于数据的读取得到了有效地加速。当然HANA是支持行与列式存储的数据库,只是默认的存储方式为列)SAP的手册中明确指出,行的存储是一些数据字典,列式存储是交易数据,如果列式存储与行式存储的两个表进行相互关联的时候,数据库的读取性格会得不到良好的优化。所以针对常用的数据字典,也建议将这个数据表设置为列式存储。

     变革还不仅仅是数据存储方式,为了减低对于网络的依赖,HANA建议将数据放在内存中,而不是数据在不同的服务器之间搬来搬去。这种方式在改变了系统架构,从原来的独立系统从而转变为集中数据存储方式。开发方式也悄然得到改变,从原来的逻辑基于应用系统的开发方式,转变到了数据逻辑下沉的方式,将不同的逻辑与分析库、商业功能库、自己定义的脚本逻辑都下沉到HANA中,并通过基于C++ 的L优化,进一步提升计算的并行性。

      HANA将视图分为属性、分析与计算不同的模式,同时增加了基于时间类型的处理方法,这有效优化了,在关系型数据库中,针对时间序列的数据分析(HANA增加了分析视图与时间的相互关联性)。并将这些模型提供了一个指导性的建模过程:1.导入数据源系统的数据;2.装载并提供数据;3.创建数据模型;4.消费数据(基于多种模式)。基于SAP这种基本的方法论,还为BO与BW做了更多的优化,为引入BO的对象与BW对象更新了分析视图导入角色的权限。这让SAP BO与BW on HANA得到了非常好的集成性。当然另外一方面SP5以后通过分析特权的修正让数据得到进一步加速。

PS.jpg

  当然HANA的解决方案从一个单一的数据库,转变为一个解决方案的时候,将用户界面与底层数据库良好的集成性,成为SP4之后的重大任务之一。无论你看到的是基于UI5的案例,还是基于PHP的案例,还是基于移动手机的案例,本质上都是基于HANA对外提供工业化标准的支持。当然SAP也有自己的判断她放弃了目前常用的SOAP技术而转而提供的是REST技术(这种工业标准在跨网域与性格上得到了更好的标准,可以提供适当的缓存支撑,有效提升中间服务层的性能)。这种技术方式使得HANA可以有效提供任何对于REST技术标准软件的支持(甚至包括我们常用的微软office)。 巧妙利用UI5在不同平台的支撑特性(基于开源技术的应用)可以在不同的环境下,提供统一UI风格的实现。这使得新的开发有非常好的用户体验。

   这种小小的变革,让开发方式产生了非常大的变化,HANA由原来单一的代码下沉,转而变成了基于MVC这种架构模式,并在这种模式下利用JS开发出基于原生的应用成为一种全新的HANA开发方式。在这种思想的推动下,利用基于Eclipse的HANA IDE开发环境有效完成了基于团队开发的模式(利用这种技术可以轻松实现开发者与HANA之间代码的同步与从服务器获取新版本的功能)。并巧妙将HANA的应用转化为一种为基于原生的应用模式,另外一种基于云服务的应用模式。如果把基于HANA脚本的接口比喻成是ISB的话,那么XS则为ESB。这种分工,将有效提升各种性能及其逻辑的实现。

SAP HANA Extended Application Services.jpg

这中变革是一个质的飞跃,从开发平台的整合到多种开发方式的转变,从多人开发到MVC架构的有效利用,从单一的代码下沉到新用户界面整合,从有效增加并行计算到基于HANA内置代码的在线更正调试,标志HANA已经从单一的数据发展到了一个解决方案,一个新开发平台,新开发模式的转变。这种转变将会给目前烟囱方式的系统架构带来非常巨大的冲击。

  在几年前建立的系统中多采用的是独立的数据库,独立的应用解析服务器,独立的权限管理,单独应用不支持虚拟化技术,而这种方式,很显然已经过时。在HANA与移动技术的推动下,我们可以很快看到,后台将有基于HANA的统一存储,这种存储模式是基于内存计算、基于L的并行计算、基于列式存储的高效数据压缩、基于HANA内置分析优化、基于软硬一体机的高效硬件加速为基础的存储与技术。在前端将以门户、大屏幕及移动为基础的随时、随地、随需的供应模式。在新式的数据中心下,数据将有效减少数据的迁移成本与时间,集中部署的模式将为各层用户提供快速且优质的服务。这种服务模式,将有效减少数据安全成本、数据中心的合规检查、数据维护成本与更叫有效提升开发的效率。同样,这种开发模式,将进一步提升对于数据模型、数据规范、开发规则的要求。新的技术革命会带来新的开发模式,新模式将会提供更好的信息消费模式。让我们一同更随HANA的变革。

By @独角兽老头 kingbo ding

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. JianGang Zhou

    “HANA将视图分为属性、分析与计算不同的模式,同时增加了基于时间类型的处理方法,这有效优化了,在关系型数据库中,针对时间序列的数据分析(HANA增加了分析视图与时间的相互关联性)。”

    请问这句话怎么理解?是说的可以通过time hierarchy吗?我是金融行业的,所以对时间序列特别感兴趣,希望能得到您的指点。calfen#gmail.com. 谢谢

    (0) 
    1. kingbo ding Post author

      周兄,您提的这个问题是非常好的问题,HANA是一个基于存储与分析的数据库为核心的一体化解决方案。我之所以说是方案,而不是在说产品,是因为它是一个组合体,在HANA建模的时候,有独立的属性是针对时间的(且这样的视图头中具有一定的阶层,年,月,日,可见不同的视图应该是有不同的优化)。在实际数据表上会用另外一个视图,去过滤原来的表,为计算提供了静态数据链。以上两种都是属性视图去完成的工作,但这些数据准备好后,最后利用计算视图可以将一个或多个视图进行有效的关联与运算。这种运算还不仅仅基于这种简单的数据与数据的关联性,HANA还另外提供了两组函数( Business Function Library BFL与Predictive Analysis Library PAL)。提供了一些常用的功能与数据分析功能。

        在实际基于时间序列中分析场景中我们一般长用的指数回归、多元回归、多项回归、逻辑回归与单指数平滑、 二次指数平滑即霍尔特 – 温特斯双指数平滑与三重指数平滑法(基于季节与趋势)都提供了内置的函数。在计算视图中,可以将数据与时间关联后的结果交给这些内置的函数去计算,并将结果,返回到特定的表中。 当然HANA目前提供的分析函数还是有限的,不过可喜的是开放了R的接口,复杂的数据模型可以利用R的内置模型进行外部计算,且这种计算方式与内部提供的方式,都是基于脚本的方式进行编写。且无论是基于SQL脚本,还是基于R扩展脚本,都可以把它们封装为一个黑箱子,提供给其他脚本调用。

      目前我也还在研究针对HANA内部与外面R相同功能,不同的运行方式所带来的计算时间差异有多少。无论如何,有一定需要值得注意,基于热数据的处理对应时间的要求非常高的情况下,算法本身并不一定是关键,提升复杂度,并不一定能提升数据预测的准确性。我也处在摸索中,以上只是我的个人看法,欢迎讨论与指点。

      (0) 

Leave a Reply