Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member

     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以后通过分析特权的修正让数据得到进一步加速。

  当然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。这种分工,将有效提升各种性能及其逻辑的实现。

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

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

By @独角兽老头 kingboding

2 Comments
Labels in this area