7月26日和27日，我受邀参加了SAP在国家会议中心举办的“蕴韬略促转变共发展”为主题的中国商业同略会，下面就参会的一些感想和大家分享一下。
SAP中国商业同略会是第二次在北京举办，此次大会汇聚国内外知名商业领袖、企业高层、行业权威、专家学者，既有主题演讲又有分会场专题演讲和互动交流体验，可以说本次大会内容丰富，精彩纷呈！
本次大会我比较关注SAP HANA技术，在主题演讲和分会场专题演讲中众多嘉宾的发言中这个词的频率出现最高。从专业性角度上来说，谈SAP HANA最好的一场是26日下午在211室的“SAP旗下的数据库五虎将”，在这里我很高兴见到了SAP亚太区技术总监卢东明。在会议上，各位专家的讲解都比较好，场下还有人不断的围绕SAP HANA提问题,气氛非常积极热烈和活跃。
说到SAP HANA,我想大家和我一样都想知道它是怎样的一种数据平台以及对企业现有的业务和综合管理将产生什么样的影响。首先SAP HANA是一个软硬件结合体，提供高性能的数据查询功能，用户可以直接对大量实时业务数据进行查询和分析，而不需要对业务数据进行建模、聚合等。从硬件上来说，新的HANA计算平台拥有100 IBM X5节点、100TB 主内存、 4000个X86内核，应该说已经是很*的超一流配置了。从软件上来说，SAP HANAHANA的计算引擎（Computing Engine）是其核心，负责解析并处理对大量数据的各类CRUDQ操作，支持SQL和MDX语句、SAP和non-SAP数据。HANA的快就在于用大内存提供内存数据库，并在内存数据库里采用列式存储从而可以将更多的数据装进内存，从而快速处理用户复杂的查询请求，快速返回查询结果。
在这里，现场的来宾问了一个问题，行式和列式在内存数据库中是如何实现的？郭磊对这个问题是这样解答的。传统的行式数据库，是按照行存储的，维护大量的索引和物化视图，无论是在时间处理还是空间存储方面成本都很高。而列式数据库恰恰相反，列式数据库的数据是按照列存储，每一列单独存放，数据即是索引。只访问查询涉及的列，大大降低了系统I/O，每一列由于数据类型一致，数据特征相似，极大方便压缩。行式数据库擅长随机读操作，列式数据库则更擅长大批量数据量查询。就每张数据表而言，行式和列式在硬盘、阵列、存储设备上是两种不同的存储格式，需要转换的时候比较大的表比较耗时和费事。但是HANA技术是把要读取的表装载到内存中，然后根据算法进行行列转换，快速读取和返回查询结果。这里他说了一个细节，就是一张表在内存中并不能同时被指定为行式和列式两种存储格式，这是要根据需要在内存中进行转换的。
另外来宾们比较关注的就是宕机后，内存中的数据会不会丢及重新从硬盘写会内存需要多长时间？卢东明对这个问题进行了解答。大家都知道内存数据库一旦崩溃，数据不复存在。因此HANA内存数据包含了DATA和LOG两个部分，它在硬件层面提供了一个闪存（2-4TB）用来同步保存内存数据库中的LOG信息并生成SAVE POINT,然后写入真正的持久的硬盘存储。当然即使是突然断电宕机了，我们可以得到那个时间点的SAVE POINT，根据这个信息将未写入的信息进行恢复导入磁盘。除了这些，同时还要有健壮的容错和Failover机制，保证一个节点崩溃或宕机，同一组中的替补节点能立即顶替工作。一种解决方案是构筑分布式内存数据库还有一种方案就是内存数据库的实时复制功能。宕机后，重新写入磁盘是分步骤分批的，工作原理就是先加载需要的表再逐步加载其他需要的表，默认时间是5分钟，当然也要根据具体的情况来看（比如光纤盘、高速存储等好的硬件），时间也可以比5分钟更短。
最后有位EMC的工程师问到“多数据中心之间HANA的平衡能力”，这个郭磊简单的做了回答。比如HANA计算平台是10个节点，分布在各处，这10个节点就是一个分布式计算平台，其中有一个是MASTER服务器，其他是SLAVE。而且这些节点之间都是万兆交换机来互联，以保证节点之间的快速调度和平衡，一个节点宕了其他节点都能快速负载和分担其计算。
谈到企业为何使用HANA时，嘉宾总结了10点：1、处理海量数据;2、应对非常复杂的SQL查询;3、快速响应需求;4、解决结构化与非结构化数据挑战;5、即时响应新生成的查询;6、不构建Cube;7、需要实时的业务分析;8、目前平台无法支持一些应用程序;9、需要对系统环境进行简化，让新旧应用运行在同一架构下;10、能够提供处理器与刀片服务器的无限扩展能力。
短暂的两天大会结束了，可是有关SAP HANA的思考仍在我的心头萦绕，可以想见数据库的新发展和高性能计算正踏歌而来，路漫漫终其将至。
SAP HANA不是一个终点，它正是开启未来高性能计算的一个起点。不远的未来，让我们共同努力，套用会上的一句经典“未来不是历史的延长，未来可以由我们*创造”。
本文出自 “滴水穿石孙杰” 博客，谢绝转载！