【IT168 专稿】本文根据【2016 第七届中国数据库技术大会】现场演讲嘉宾刘伟老师分享内容整理而成。录音整理及文字编辑IT168@杨璐 【微信搜索DTCC2014，关注中国数据库技术大会公众号】

　　嘉宾简介

　　SAP大中华区副总裁 大数据与平台事业部总经理

　　刘伟 毕业于北京大学光华管理学院，并拥有美国Thunderbird国际管理商学院的硕士学位，他在硅谷开始其IT职业生涯，拥有丰富的行业及管理经验。

　　正文

　　在过去几年，大家经常会听到，中国的经济进入新常态。如今IT行业，也在进入新常态。传统行业对互联经济颠覆、再造，IT技术同样也被新技术影响甚至取代。

　　几年前，可能还有争议，但现在没有人怀疑数据与生俱来的价值。但如何把数据价值变现，还有很多需要探讨的地方。数据价值变现需要两个条件：第一个是必要的条件，我们需要有非常高超的数据处理技术;第二需要对业务有比较深刻的理解。只有对业务有理解才能找到合适业务的场景去解决客户业务的问题，创造新的业务价值。

　　基于内存计算的数据平台 实现实时深度数据挖掘

　　今天重点介绍在数据处理能力下，基于内存计算下一代的数据平台，怎么样能够帮助大家实现实时深度数据挖掘，怎么样帮助大家把我们企业内部和外部的数据能够打通，帮助大家把我们OT和IT技术打通，真正实现数据的联动。

　　首先问大家两个相关的问题，第一个在今天DT的时代，现在收入最高的IT技能是什么?大家想一想，看跟我们接下来讲的是不是一致的。

　　这是美国一个专注于技术类职位2015年的数据， 2015年十大高薪IT职能，第一位的是SAP HANA，之后是Cassandra、Cloudera。一半是大数据，另外一半是云计算。第二个问题，与我们职业还是有关系。二十一世纪最性感的职业是什么?

　　在IT和DT的时代，最性感的职业是什么?其实有一个说法是二十一世纪最性感的职位是数据科学家。数据科学家需要懂IT技术、需要懂开发、需要懂数理统计、需要懂客户业务。这样的人是万千宠爱于一身。真的很不容易找到。

　　数据科学家具体工作内容是什么?举例：我们看看有两份税务申报单。在西方成熟市场每年几亿计的税务申报单，但是怎么样分别真假?这是数据科学家所需要做的工作。把刚才提到的各项技能整合起来，建立模型，在数以亿计的税务申报单里找出来哪份是真的哪份是假的。那这两份哪份是真的呢?

　　带着这个小问题回顾IT系统的演进。企业IT建设刚刚开始的时候，我们可能首先有一个基础的，比如ERP，对我们企业业务流程的运算，处理数据交易。那么在这些时候我们的数据可能是以关系型为主，我们对一致性、持续性要求非常高。所以我们说基于磁盘的关系型数据库。

　　一个企业要发展，我们需要比竞争对手做得更好，怎样有更多的对业务的洞察帮助做预测性分析等，就要用差异化的系统。这时数据源不一样，要把多个数据源整合。开源技术便大放异彩。因为开源技术还是有些缺陷，在性能方面开始尝试内存计算。

　　随着技术的发展，近年来企业受到互联网巨大的冲击。这时传统企业开始重塑再造业务。尝试借助IOT改善供应链，也可能借助一些消费者的大数据做对客户的精准营销，对客户画像等。数据在这时代变成大量的、实时的。我们既要处理事务性的交易，还要处理多维分析、数据挖掘。这时，无论商业技术还是开源技术方向不约而同，也就是内存计算。

　　SAP大概六年前推出基于内存计算的系统。随着业内关注而越来越多，SAP也与时俱进，这种开源技术会被更多用户所采用。SAP推出了一个叫SAP Vora，在spark节点上实现SQL 分析。Hadoop有一些技术架构的限制。在这些方面它们弱一些，SAP Vora可以实现两者之间的整合。

　　无论是开源还是商用，内存技术是共同的选择。就这点来说，内存技术已经成为新时代大数据分析技术的主流。十年前，数据库的奠基人Jim Gray，在2006年曾经预言，他说磁盘已死，磁盘已经落伍，内存才是王道。

　　回顾过去，正好是这样。所以，过去我们是在磁盘IO读写，但有了内存计算之后，再处理时CPU首先会就近用高速缓存来处理每个现存任务，之后才会在主内存里对数据进行查询和修改。实际上，现在新的瓶颈变成怎样能把数据更快从主内存里加载到高速缓存，让我们的CPU能持续的进行运算，然后提供更快速的反应。

　　在这点上，因特尔与SAP一直有紧密合作。比如在一期的志强芯片V3版本里专门针对HANA做了内存指令优化。即使我们不在其他软件里面做任何修改，性能至少也可提升两倍，这样可以更好的支持运行。

　　有了内存计算，但大数据时代开源架构还是有缺陷的。我们是不是可以利用内存计算对它进行一些修改、优化呢?讲到开源，要说 CAP原理，基本上就是一致性、可用性、和分区容错性。因为分布式的计算，必须要保证我们的分区容错性。这样就导致我们在C和A之间要做出取舍，我们不可能鱼与熊掌兼得，要么就是CP、要么就是AP，很难做到均衡。

　　有了内存计算，我们有了新的架构可以帮助，就有技术大拿推出实时大数据架构。这里应用了实时内存计算。简单讲，基本上静态数据就用Batch Layer的技术。这个计算，其中有新的数据进来，然后对其中的数据进行批次计算。这里重要的是不可变性。数据是不会修改的。就是不管是删除还是修改，所有的都会被保存。所以有很好的容错性。

　　另外在对新增的数据，所谓的C，对新增的增量做的增量视图。最后在服务层，把实时视图和批量视图进行合并，给用户提供服务。所以，在这里面其实每一个点上都可以用到我们开源的来实现。HDFS， Spark等等都可以在里面对应上。

　　但是我们知道，并不一定全部要用开源，我们选择的时候希望选最优的方案。分享我们和开源技术做一个深度无缝的融合。在Batch Layer的时候基本上还是用Hadoop。然后在速度层建议用HANA。利用内存计算技术来对实时的大量技术来生成增量视图。在服务层用HANA Vora，是在Hadoop上实现多维分析。通过一些计算，我们通过Vora把数据曝露出来，然后提供给客户。

　　疑问来了：这两套框架怎么在一块，会不会有什么问题，会不会让应用架构非常复杂。

　　首先有一个概念，数据的温度，我们有热的数据、温的和冷的。按数据的存在的时间长短等等来定义我们数据的温度。在这个里面我们的管理是由我们HANA自带数据周期管理来实现的。我们可以先看黄颜色的一组箭头，我们应用里的数据，首先是在内存里在存储，如果过了一段时间，按照事先定义的热数据当变成一个温数据之后会放在扩展存储。在我们扩展层之间的流动对应用来说是透明的，它感知不到，完全是机制自动维护的。当数据温度进一步降低的，变成冷数据的时候，会放在Hadoop系统里存放。

　　我们可以换一个方向来看，我们肯定有很多大数据，来自社交媒体等等，进入Hadoop之后我们透过Vora把它提交到HANA里来，供应用使用。所以无论哪个方向，在这里面有非常关键的观点，大家要注意的就是说最终对我们应用来说都感知不到数据在里面流动，所有的都是在我们后面来实现，对应用来说它面对接口非常简单，这样让应用在开发的时候架构也简单。我们不用特别关注数据在不同体系之间的流动。

　　案例分析

　　芯片制造非常类似于流程制造，过程不可逆，但是一旦发生问题对厂家的成本非常大。但是怎么去控制这个?所以我们客户就提出来有没有可能基于它们的海量生产的数据、工厂的数据，HANA内存计算、机器学习，由我们预测分析，这些技术能不能帮助他来满足以下几个需求：

　　第一，在生产制造的过程当中能不能帮他找到产品良率的根因追溯、质量率。我们基于大量数据做出模型以后应用到生产系统，然后基于生产实时数据进行预警、分析，然后去优化这个数据，持续来改进我们所出的预测模型。

　　第二，怎么样把海量的数据处理缩短到秒，这样质控人员、分析师就可以把大量时间放在其他方面，而不是每天在这里看，而且还不见得精准。

　　第三，他希望借助这个项目帮助他们搭建数据平台，帮助他们实现实时的动态和产品的分析。而且这个平台要好用，在未来还有新的产品、新的生产线可以复用，而不用再做个新的项目。

　　还是同样我们的数据，首先在生产工厂的大量数据，热数据，我们首先是在HANA内存里做计算。然后当温度降下来，通过动态分层，就会存储在磁盘、闪存里。冷数据就会存在Hadoop里面，然后透过Vora来实现HANA和Hadoop之间的交互。我们看一下基础的架构，我们对HANA内存节点，用了14个T的内存，然后在动态分层我们一个节点、2T内存，Hadoop是10个节点。这是当时的技术架构。就用到了因特尔E至强V3版本，本身因为它对内存指令优化，性能就非常高。

　　实现的结果就是：速度很快，五亿条记录38秒。但这并不是这个方案的根本出发点，根本出发点还是我们提供了非常好的业务洞察，在这里实际上当客户把他的需求明确之后，我们双方的数据科学家在一块讨论，怎么样把数据输入，选择什么样的模型、用什么样的测算工具。对于他们选择了HANA里的PAL我们的预测分析库。借助这个库里的，分类回归树来建立这个模型。如下图，是一个可视化结果。

　　在根节点上实际上我们这里面不良品的数量和比率，我们再度分解，把其中一个影响因素按不同的区间，我们又可以看到它的不良品数量和概率。这期间又进一步分析，一层层分解下来。最终到不可分解为止。这个都可以在算法的配置参数里控制。

　　通过这个我们建立了一个模型，把它用在生产里，实时数据进来，我们会用这个模型做计算、去做预警，在某个节点上有问题了，只要匹配的话就可以。随着更多数据可以进一步优化模型，可以预测更精准。大家可以看到这是非常典型的Lambda架构，HANA加上Hadoop这么一个架构整合，可以帮助客户且回报巨大。