农夫山泉：HANA应用在企业中层层展现

商务分析成为企业信息化应用的一大热点，它的出现，为企业提升洞察力和加强从战略到执行的管理提供了新的帮助。但在实际应用中，不难发现，传统的数据仓库和数据分析技术，在应对海量及实时数据的处理上都很难做好。在这种情况下，如何提供一个能够应对海量数据的挑战，实现高效的逻辑运算、实时的数据分析以及快速的数据展现的解决方案。

　　为此，胡健和他的IT团队经过研究把目标锁定在SAP推出不久的HAHA。作为一种海量数据实时分析工具，HANA能够在不改变现有IT信息系统架构的前提下，实时分析来自几乎任何数据源的海量数据，提高计算速度，从而降低总体拥有成本，大幅提升用户应对市场变化的能力。

　　农夫山泉作为HANA在全球第三个、亚太区第一个上线的企业实现了HANA数据库变成一个集解决方案和行业应用为一体的高性能交易型应用行业数据库解决方案。查询同样的数据，用原来的数据库与BI组合需要215.0秒，用HANA和升级后的BI组合一次查询只需2.1秒，二次查询则只需1.8秒；同样的报表展现原来需要358.1秒，而在HANA中只需要16.8秒！胡健非常镇静地描述了以上惊人的数据。作为ERP应用的资深专家，CIO，胡健作客微畅谈，与大家分享一下实现HANA在农夫山泉中应用过程中所获得的经验的感受。

　　HANA不仅是数据库也是平台

　　胡健表明，HANA不仅仅一个数据仓库，更是一个平台，在这个平台之上用户可以构建数据仓库或集市、报表和仪表盘等。HANA能做的，首先是作为内存数据库，提供数据插入、修改和高效的查询功能。其次，作为一个平台，在HANA之上，BO报表系统可以提供更好的用户体验，用户几乎不需要等待数据返回。用户可以使用HANA的建模工具直接访问ECC或其它数据源，他介绍HANA的软件架构：最下层是SAPECC、BW及其它非SAP数据源，通过DataServices把数据导入HANA，通过ReplicationServices写到磁盘，通过HANA计算引擎处理数据插入和查询等操作。HANA是一个平台，在这个平台之上可以是BO、BW，以及其它产品。

　　胡健进一步强调：“SAPHANA除了能够作为一个开放的平台给更多的客户和合作伙伴创造更多的价值之外，自身也做了很多研究以保证基于SAPHANA的企业级应用能够得以实现。提高业务运营效率还远远不能体现内存计算的全部价值。通过快速的分析使大规模数据产生价值，是内存计算更深层次的应用。

　　农夫山泉为SAP提供了超过1亿条的客户记录，将它们加载到SAPHANA中之后，仅仅数秒钟SAPHANA就可以完成对这些记录的梳理。而在此之前，将这些数据从农夫山泉的数据仓库和SAP商务套件中抽取并展现出来就要花费二十几分钟时间。这也是SAP官方确认农夫山泉应用SAPHANA之后平均速度提升2000倍客户的依据。”

　　HANA体现高速内存计算性能

　　农夫山泉在去年8月20日上线HANA（STANDALONE）创造了亚太第一，2012年2月15日上线的BWONHANA也是国内首家，胡健谈到HANA的高速内存计算性能，希望供大家参考。“比较的前提是，我们oracle的dbserver是HP的6600（8核cpu64G）小型机，HANA是HPDL980M+（32核512G），源数据量是3.5T（SAP和NONSAP），oracle是行存储，11G，HANA是列存储。

　　第一点，STANDALONEHANA，以运费逻辑计算场景为例，在oracle的PLSQL上写的procedure，需要跑24小时，而在HANA的studio上同样的逻辑实现只需要36秒，但是将数据进行分段计算，在内存中并行处理，这也是HANA的新特性，得到的速度结果是3秒多，这是一个怎样的速度，是万倍级的提升。再看一个场景，对数据量为1亿条记录的sms_tb_shortmsg进行简单的sql执行：selectcount(*)fromsms_tb_shortmsg，在ORACLE中速度是26秒，而在HANA中执行速度是12毫秒，两种相差2000多倍，这也是SAP官方确认我们平均速度提升2000倍客户的依据。当然，数据量越大，HANA的性能提升会越快。

　　第二点，BWONHANA，相对于STANDALONEHANA的质的飞跃，BWONHANA的提升效果虽然没有那么离奇，但也是不错的，以HR人事月报场景为例，数据量41万多条，数据源SAPR3，在BWONORACLE上激活DSO的时间是131秒，在BWONHANA的DSO激活速度是31秒，综合其他DSO的平均激活速度，BWONHANA提高5-10倍，而在展现上，BWONHANA只用了2秒就在BO4上展现出来，而BWONORACLE在BO3上的展现时间是97秒，相差50倍，这是一个我们认为提升最快的场景了。当然综合其他场景，平均提高5-20倍左右。”

　　胡健指出：因为oracle是行存储，HANA是列存储。总体上来说，给我映像最深的就是读的速度区别很大。SAPHANA充分发挥了内存数据处理的威力，能够实时地分析来自几乎任何数据源的大数据量。“

　　一个上亿条的关系表，当然是行存储的，在建立了INDEX后，全表扫描，并按组织groupby后，进行sum和count的时间在40秒左右，而ETL到HANA中，转换为列存储，不用建INDEX，也是按照以上规则，0.2秒就能出来，性能超过ORACLE10G的速度达200倍。以上的场景，在BO中，一边是连接ORACLE关系表，一边是连接HANA的表，展现速度更是超过350倍。

　　“写的速度，这个就是列存储不擅长的方面了，HANA的原理是，将表的每一列进行压缩，建立相互索引关系，在搜索时，进行简洁的关联，争取最小的数据量连接，找到结果。而写的操作，对于它来说，往往是针对某一行进行delete、update、insert，需要将列解压，再关联成行，修改完成后，再压缩，且在解压完成后，没法自动进行index创建，故速度很惨，我们的运费计算场景，最后在HANA列数据表中惨败给ORACLE，甚至无法完成调用。不过，SAP-HANA支持两种表存储类型，行存储和列存储，也可以用简单的SQL进行类型转换，解决了PROCEDURE写，和FUNCTION读的问题。在HANA行存储的测试中，也几乎与ORACLE速度奇虎相当。

　　HANA已经可以支持R3的全部数据库，原来只有DB2才能，进行实时的数据增量更新，也就是说，R3中有任何凭证更新，在HANA中可以第一时间进行增量复制，以后在BO中就可以看到即时数据了！”

　　HANA在OLAP中体现实时性企业应用

　　新一代的数据库应该既能够处理交易数据(TransactionalData)，又能够应对数据分析以及集群的搜索模式，而这一点正是HANA的特别之处。在SAPHANA中，对数据采取了混合存储，既保持了传统的行存储方式，又提供了基于列的数据存储方式，而OLTP、OLAP采用了相同的数据结构，放弃了星形模式和Cube的构建，这样太费时外部的数据可以通过复制和ETL来进入系统，操作采用大规模并行处理(MPP)，所有聚集是按需和实时的。而磁盘仅用于备份与恢复。因此HANA可以应对的四种操作：交易型数据、业务分析、复杂事务处理和非结构化数据。这在其他数据库产品中是无法完成的。

　　我认为企业选择HANA时，主要看中以下10点：1、处理海量数据；2、应对非常复杂的SQL查询；3、快速响应需求；4、解决结构化与非结构化数据挑战；5、即时响应新生成的查询；6、不构建Cube；7、需要实时的业务分析；8、目前平台无法支持一些应用程序；9、需要对系统环境进行简化，让新旧应用运行在同一架构下；10、能够提供处理器与刀片服务器的无限扩展能力。

　　SAP还发布了新的功能包，提供了在HANA上运行SAPNetWeaverBusinessWarehouse的能力。二者的结合将大大简化OLAP系统结构，并提升性能。

　　2004年农夫山泉就已经采用了SAP的ERP系统来构建企业内部信息化系统，并且采用了Abap直接在OLTP中提取数据生成报表。而这种方式随着数据规模的增长开始出现瓶颈--到目前为止，农夫山泉每天生成70~80GB数据，传统OLTP模式已经难以完成对数据的分析。而另一方面，更加实时性的分析--OLAP在传统架构下则面临着三点困难：1、数据展现速度越来越慢，2、数据运算难以忍受，3、数据更新只能是一天一次。

　　对于农夫山泉这样的快销行业来说，数据的实时分析和更新可以为企业带来有效的经营战略调整和业务决策。我们对比了SAPHANA和Oracle的性能。由于内存计算在I/O方面的强大优势，HANA的性能要远胜过当时一起评测的OracleExadata数据库系统，而且在性价比上也是HANA和HPDL980G7更具有优势。

　　从基础设施角度来看，DL980G7在HANA方面跑的非常好，在功耗和散热方面我认为DL980是一款成熟的产品，非常适合跑HANA架构的数据库产品

　　在应用方面，目前农夫山泉有1万多个代表在全国各地采集各种分析数据，包括市场调研、价格波动等，而基于HPDL980G7则在后台用HANA系统进行运算。

　　从实时性上来看，HANA的同步数据传输技术（SLT）已很好的实现将SAP和NO-SAP复制到HANA.。从部署的情况来看，农夫山泉从决定启用SAPHANA到最终上线至今，农夫山泉的业务系统在HANA上运行的很和谐，从部署到运行没有出现过业务中断的情况，并且对整个业务效率的提升起到了很大的促进作用。

　　如何评估HANA投资回报率

　　作为HANA的第一个“吃螃蟹”者，农夫山泉已经感受了HANA这只“螃蟹”的鲜美。

　　我们只是做了一件满足企业业务需求的事情。即使不用HANA，我们也要用替代的解决方案。作为一个快速消费品行业企业，数据的应用对于农夫山泉来说非常重要。企业高管需要实时、准确的数据作为依据来对变化万千的市场做出准确的判断，并据此进行科学的决策。

　　而当时农夫山泉的团队却面临着IT系统难以忍受的OLAP(联机分析处理)效率：数据展现速度越来越慢，数据运算速度难以忍受，数据更新周期太长。农夫山泉在2004年开始上线SAPERP系统R3。当时农夫山泉采用传统的数据仓库来进行数据展示。但是到了2008年，快速发展的农夫山泉的数据规模变得非常大，数据处理、展现效率不尽如人意。为此，农夫山泉做了一个OLAP系统。但三年后，这个解决方案又开始出现问题。而且，采用传统的ETL(数据抽取、转换、装载)，农夫山泉的分析系统数据基本上一天才能更新一次。而作为一个快速消费品企业，农夫山泉希望能够实时看到数据变化，并据此做出决策。

　　我们需要一个能够应对海量数据的挑战，实现高效的逻辑运算、实时的数据分析以及快速的数据展现的解决方案。为此，我和我的IT团队研究了很多产品，最后他们把目标锁定在SAP推出不久的HAHA。作为一种海量数据实时分析工具，HANA能够在不改变现有IT信息系统架构的前提下，实时分析来自几乎任何数据源的海量数据，提高计算速度，从而降低总体拥有成本，大幅提升用户应对市场变化的能力。

　　HANA具备成为下一代SAPDB条件

　　胡健认为：“收购Sybase的目的有两个，一个是看好Sybase的Mobility解决方案，这个是SAP一直都窥视的领域，另一个是数据库特别是基于列存储的IQ，很快，在去年，Sap推出了HANA和SMP，特别是SUP直接就标着sybaseunwareplatform的字样，HANA在OLAP数据库方面的卓越表现，已经在全世界的客户面前展示过，我个人认为，先专注做好OLAY的数据库市场，内存计算列存储的HANA一定能在OLAY数据库产品中领先成为第一品牌，但Oracle的基础是在OLTP数据库，是否成为第二，必须进入OLTP，而进入之前必须解决几个问题，第一、OLTP和OLAP最大的区别就是安全性要求，所以HA和RAC都是必须的，HANA进入OLTP首先要提出自己的HA和RAC方案，才能稳定的为交易提供保障；第二、列存储有很多优点，在OLTP中可能会变成劣势，比如列压缩技术，在交易频繁的写入工作，采用行存储更合适，一旦放弃自己的优势，怎样与久经考验的OSD（Oracle、Sqlserver、Db2）这些厂商进行PK，只能另辟蹊径，唯一的办法，其实还是SAP老路子，Solution-Appliction，将HANA数据库变成一个集解决方案和行业应用为一体的高性能交易型应用行业数据库解决方案。”

　　HANA是针对OLAP的加速技术，内存计算列存储数据库，HANA在OLAP数据库方面的卓越表现，已经在全世界的客户面前展示过，但HANA毕竟是新的产品，希望不久的将来，HANA1.5或者2.0的Release版本上，能够有所体现，也希望能得到改进的进展反馈。

　　主要是四个方面：1、JOB，HANA不支持JOB定义和监控，需调用应用脚本和系统任务。2、interface，HANA目前没有给出接口调用模式，外部系统如J2EE无法进行方便的调用，也无WEBSERVICE调用方案。3、FUNCTION，不支持变量定义，复杂甚至简单的计算都无法实现（无法忍受），返回类型只有TABLETYPE。4、DRIVER，HANA目前只能调用ODBC/JDBC管道，没有自己的SpecialInstantDRIVER，对ETL和BO的数据调用速度会有影响。

　　总体上，HANA具备成为下一代SAPDB的条件，如果HANA完善了以上几点的话，业务部门在实际应用过程中也会更顺手，相应地减轻IT部门负担