SAP 新产品内存数据库 HANA 的前景如何？
-
应该说Hana的最大实施方向可能就是SAPCloud，但即便是更新极快的cloud业务，已有的传统DB也不太可能短期就全部migrate到Hana上，这个成本比想象的要高，并且在没有特别优化的前提下，提升并不大。这也就意味着将来的一段时间内Hana和传统数据库即便是在Cloud事业上也是并存的，换句话说开发测试要继续苦逼的兼顾两套DB（已兼顾了一年=_=），直到Hana生态圈真正建立并成熟。目前一定程度上虽说可以兼容，但只有真正做的人才知道由于专利壁垒的存在，兼容并不那么简单，再加上Hana如果是作为新一代DB的话，时日尚短（Oracle成熟用了很多年），但未来可期。至于说作为新一代Platform怎么展开，这个以后再说……
-
这个新产品，对于某些行业的应用来说，是有提升的。比如海量数据级别的零售业，或者快消行业。所以HANA的样板客户就是养生堂。但是对于SAP的大本营制造业来说，部署起来成本偏高，收益也不是那么明显。个人的看法，这会在SAP的力推下在几年后成为市场的主流，但是很难100%的淘汰之前的产品。形成类似ECCS/BCS/BPC并存的市场格局。
-
HANA也在致力于和Hadoop这样的分布式系统对接。通过Hadoop和HANA两个系统的对接，SAP能够高效读取Hadoop里的各种数据，实现了HANA数据库的延伸，从而能够去处理真正的海量数据的实时处理。“Hadoop和HANA是互补关系，HANA的内存计算主要是针对活跃数据进行处理，非活跃数据的历史数据则放在Hadoop上。
-
HANA产生的技术背景在于内存足够便宜。传统架构由于内存太贵，才区分出快速运行内存，和便宜外存。运行时将需要的数据从外存读取到内存。现在内存的价格对于企业应用来讲，已经足够便宜了，所以可以实现内外存的部分统一。在应用方面，对于企业用户来说，有两个应用点。一个应用点是BI，传统的BI架构，是以BW/DW服务器（即数据仓库）为核心。需要一台BW服务器将原始交易数据从各个业务系统中抽取转换，映射到BW模型，再由报表服务器呈现给最终用户。可以看出传统架构有以下不足：架构比较复杂，需要多台服务器，需要考虑各种服务器连接，可用性，灾备等；费用较高，至少多出一个BW的数据库软件授权；最重要的是从抽数到出具报表，中间有多个步骤和相当大的时间差。而HANA方案，可以让业务系统和BW共用一套服务器，架构简单，软件授权少，维护也相对简单了。对于最终用户来讲，就是BI报表出具速度加快。有案例说从几天加快到几秒。重点讲下这个报表出具速度其实对于这个报表出具时间，对于一般企业的一般应用，几天时间是可以接受的，或者说不值得让用户掏钱去更新到HANA架构的。但对于某些特定应用，对时间相当敏感。比如基于BI的财务报表合并系统，在BI中，会进行一系统各个报表、各个公司间的数据核对。在传统的BI架构，IT抽数-->用户出具报表－－》用户发现错误－－》调整原始数据－－》通知IT再次抽数－－》IT通知用户抽数完成－－》用户重新出具报表。这样多个循环下来，是需要耗费相当多时间和精力的。用户是不能忍受的，只能采用次级解决办法，比如直接在BW更改原始数据。这样会带来相当多的其他问题。对于这类应用，HANA可以由用户直接调整数据，然后快速出具报表。对于用户来讲，就有相当大的吸引力了。另外关于这个传言：HANA将报表出具时间由几天缩短至几秒。映象中这是农夫山泉的BW项目案例，讲的是SQL查询时间而不是报表出具时间，这两个是有一点区别的。另外留个尾巴：对于多级BI系统架构，比如大区公司有自己的BW服务器从业务系统抽数，总公司再从大区BW服务器抽数。这种架构下，HANA是否有优势呢。另一个应用点，就是业务交易系统了。以ERP应用来讲，我们的客户在使用SAP月底结账时，运行物料分类账计算差异，可能需要24小时以上。这期间物料不能收发，还需要禁止运行其他报表。而在HANA上，可以缩短运行时间至1小时以内。这是个相当强的效果，并且是传统架构无法通过一般优化到效果。
-
HANA很不错，这是SAP的基石，也是SAP未来的救命药，更是SAP的壮阳药。有了它，SAP再也无需恐惧Oracle了；有了它，企业可以秒秒钟把一年才跑一次的报表跑出来；有了它，你又有机会把你遗忘多年的SQL再学一遍；有了它，企业又有机会花钱搞新项目了，顺便搞钱。
-
HANA是个sharenothing架构的分布式数据库，并且原生支持并行优化。这样的架构使得HANA能够充分利用多核、分布式集群处理大数据问题。这是HANA跟现有主流商业数据库架构上的不同之处，像Oracle、MicrosoftSQLServer都不是这样的架构。长远来讲，这将是HANA击败竞争对手的核心能力之一。大数据是行业发展的必然方向，数据本地化和数据级并行是大数据处理技术上的必然选择，而sharenothing的分布式架构恰恰就是数据本地化和数据级并行的设计。不过，目前这个阶段，这还不足以成为HANA的杀器，因为shareeverything架构的数据库也可以处理现在企业面临的数据量。HANA是个内存数据库。HANA的数据基本上都放在内存里，数据操作都不需要访问磁盘。内存的访问速度跟磁盘完全不是一个数量级的，这使得HANA可以更快的处理数据。当然HANA也有优化，一些不热的数据也会扔到磁盘上去。现在HANA宣传的时候内存数据库这点着墨比较多，但在我看来这不是最大的特色和能力。HANA同时具有行式数据库和列式数据库引擎。列式数据库本身并没有太多新颖之处，在业内也存在多年。但HANA却颠覆了列式数据库的用途，因为HANA想用列式数据库来处理OLTP的问题。在我看来，这是现阶段HANA的最大杀器，也是HANA在很多场合体现出的高性能的基础。HANA内置了一些数据建模和数据分析的功能，甚至于把R深度集成了。SAP推荐在HANA上同时处理OLTP和OLAP的问题，并且也把HANA这么设计。这一点是颠覆过去几十年企业级管理软件领域的思维的。SAP推荐在HANA上直接处理商业逻辑。这一点是完全反R/3的架构的，因为R/3架构里数据库只处理数据。但是，在大数据时代，要想数据处理的快，商业逻辑就得跟数据在一起。所以这个想法长远来看是对的。以上这些点看下来，从技术上来讲HANA并没有哪一点是完全独创的。但HANA的独特之处在于把这些东西揉合在一起，并定义一套新的企业级管理软件和数据库的架构模式。这使得HANA目前在行业内是相当独特的。Oracle最近发布的12cIn-MemoryDatabase多少也有向HANA看齐的意思，这其实是Oracle的被动选择。好了，终于可以回到问题本身了。从上面的分析可以看出，HANA是一个新颖的东西，对SAP而言是个下一代的产品。我们可以从下面几点分析看看HANA的发展前景：通用的关系型数据库。这是个发展了三十多年的市场，比较稳定，现在是寡头竞争，基本是Oracle、DB2、MicrosoftSQLServer的天下。我不觉得HANA短期内在这个领域有多么强的竞争力，首先HANA的软硬件价格不菲，而且HANA的生态圈还没有建设起来。长期的话就要看HANA的持续发展了。数据仓库和数据分析。HANA其实具有一部分数据仓库的功能和数据分析的功能，HANA的优势在于比较快，而且跟SAPERP的集成又好，可以实实在在的帮企业解决一些问题，所以在这个市场我认为会发展的还不错。SAP商务套件的基础数据库和基础平台。现在SAP商务套件已经完全支持HANA了，而SAP也力推这个组合并且在这个组合上推出一些特色的功能。这自然会带动HANA的销售。但短期内我不觉得会有大批的SAP客户会把ERP这样的关键业务系统迁移到HANA上来。SAP下一代发展的基础平台。事实上HANA现在应该也是SAP发展的最高战略。SAP的云平台和下一代的企业级应用显然都将以HANA为基础展开。在这一点上单独谈HANA的销售或者前景也没有太大必要，HANA已经跟SAP的未来发展绑在一起。综上所述，单独讲HANA的发展前景意义不大，HANA已经和SAP的命运绑定在一起。HANA并不只是SAP的一款数据库产品，而是SAP将来发展的战略平台。所以只要SAP还在而且SAP的战略没有大的变化，那么HANA肯定就会持续发展。而这种持续的发展到一个临界点的时候，可能会帮助HANA在通用的关系型数据库领域开疆拓土，进而成为一个新的寡头。
-
要回答这个问题，首先得弄清楚HANA是怎么产生的，它又具体是个什么东西。HANA的产生背景有下面几点：硬件发展趋势。CPU多核成为趋势，并且核越来越多，内存容量越来越大也越来越便宜。行业趋势。列式数据库、分布式数据库、数据仓库、数据挖据等等都已经发展的越来越成熟，大数据也正在蓬勃发展。SAP对于企业级管理软件和数据库软件的反思。SAP无疑是企业级管理软件这个领域的执牛耳者，从R/3时代开始SAP所开发的基于C/S结构和关系型数据库的企业管理软件获得了极大的成功。即使SAP近些年更多的在开发基于浏览器的应用，但R/3时代开始的后端架构并没有发生根本的变化。但这种架构现在显然碰到了不少问题，企业的数据越来越多，企业希望更及时更智能的分析数据，这些需求在老的架构上都碰到挑战。
回答请先登录