蒋旭：大家好，我是神舟通用的，这里的HADOOP数据生态，HADOOP做了很多的分布式计算引擎，基于存储引擎相应开发了SOL开发引擎，针对于非SOL方式提供了非SOL算式，同时HADOOP生态有另外有一条路模仿现在的MGV路线，不依赖于原有的生态体系，实现了像Inpala，有Presto。同时还有配套的体系，在这样体系里面有很多的厂商基于这种体系开展大数据业务，这样的体系看起来非常完美，其实它还是有很多的问题。正由于这样的问题才有MPP自己的生存之道，也有我们后端针对MPP整个路线，后边究竟怎么在HADOOP体系、MPP体系以及大数据生态体系究竟往什么方向去发展？有我们的一些思考。大数据后续发展的趋势我觉得有这么几个部分，现在其实不管是用HADOOP体系还是什么体系，在做数据仓库以及整个建模分析时目前还是T+1的方式，也就是说大家建立这个数据中心，这个数据中心更多是离线端。在这种体系下，大家希望像T+0方式进行发展，能开展在线访问。基于原始数据集开展迭代式、探索式的分析。像刚才牟总说的百度的Palo，它也在开展在线即席的分析业务。牟总说到Palo里面建立了很多的运计算的模型，通过运计算模式提升客户的查询能力。

       我们的分析更多还是通过原始数据集，我们面向的分析场景不一样，原来是建立一个数据集市开展业务，现在原始数据来了，既有针对统计结果用户二次统计分析的业务，同时针对原始数据集会有一些查询和检索，在这一套产品里面最好能支持两项业务。同时，如何将一个性能提升到1000S到2S，大家有两种体系。我用HADOOP体系支持，当一台机器能够精细化手段达到非常高性能提升时，可能我只需要十台机器就能达到这种性能提升，这也是MPP体系跟HADOOP体系的优化不一样。HADOOP体系更多是粗放性、分布式计算理论，通过更多的廉价设备堆叠完成要求，但是投资成本也很高。MPP更多希望引入精细化计算的理论，来实现性能和转换，更多为用户节省相应的成本和开销，这是主要的点。

      最终，HADOOP到大数据整个的体系，最终会向统一的运营能力去发展。我们希望在T+0解决离线端检索与分析，通过T+0方式去解决，同时融合TP和AP业务实现更进一步的融合。

       在整个大数据发展里面，我觉得分久必合，合久必分的过程。在原来的大数据结构体系里面，最开始是由各种各样的数据模型存在，当时为什么出现这样形态呢？主要由于当时的机器包括配置非常有限，我们解决这样的问题性能是非常关键。要解决性能的问题必然要有特定的工作场景和精细化设计满足要求。随着机器性能不断提升，整个关系模型逻辑体系的推演，最终实现了关系数据库一统天下的局面。在这个局面到现在大数据时代，又出现了数据量太大，这种数据量在原有关系数据库模式下解决不了，HADOOP体系的提出也引用了分布式计算，让数据和计算尽可能就近去完成，同时要计算分布化这样理论。通过这样理论来提升整个的系统运算性能，这种运算性能提升是一种框架的提升，原有体系的支撑并没有在HADOOP体系框架内。HADOOP体系整个的运算和集成体系过于分化，这样的分化不便于大家开展后续业务，学习成本比较高，所以HADOOP体系这些年不断做思路化推进，在思路化推进过程中也遇到很多的问题，包括产品优化、模型理论等，以及存储等精细化设置，这样的设置在目前HADOOP体系里面都不具备。在关系式分布引入分布式计算理论，通过关系式分布提升整个的数据优化，运用分布计算理论把它带入适合大规模数据访问场景。

       MPP现在也遇到了问题，MPP整个的体系过于封闭化，我底下存储的数据用MPP自有引擎，这就引发了跟HADOOP对立的局面。这样的局面不适合MPP今后的发展，我们更多让MPP融入生态化，让MPP和HADOOP集成和整合，利用HADOOP体系原有的计算引擎和完善的生态体系，同时使用MPP目前精细化的索引、优化、固化以及上层的产品引擎特点，通过这样的方式。这两条路目前看是平行的一条路，但是将来大数据整个发展体系一定是合并在一起，需要合并的有哪些呢？我大概思考了一下也不一定对，第一是在扩展性层面上。HADOOP在扩展性层面在存储和计算模式下，它提出了非常好。它是一个逻辑分离、物理统一的原则，逻辑上上下层是独立的，但是物理层计算跟存储同时部署在一个机器上，这是它的计算原则。这种计算原则在MPP和HADOOP体系都需要吸收和引进，在后续统一之后形成这样的原则。

      第二，在扩展性层面上。HADOOP融入了更多的存储引擎和计算引擎，通过这种存储和计算引擎对接，使整个的扩展性达到更大的提升。这个时候，用户可以开展更多的业务，不仅是SOL支持的业务。

应用层面，它在应用器层面上进行了大量设计，通过产品计算和产品优化能力提升整个的效率。

再往后是检索层面它都有精细化设计，这种精细化设计才能满足未来需求。

在通用分析引擎基础上，未来一个是满足检索能力，把HADOOPT+1能做的事情，我们使用T+0引用进来实现聚合，内部基于流水运算模式，可以实现在在线业务的T+0分析，同时T+0分析可以满足秒级的响应，建立好T0（音）模型，可以满足在线的HADOOP分析。最终为用户提供的是一种高性能，同时应用的一种系统，这是整体发展思路。

       商业化产品能开源的产品实际上定位不一样，现在的开源产品大部分都孵化于互联网公司，互联网公司跟传统的商业公司包括现在面临的用户不一样。不一样的点在哪呢？在业务方向上。互联网公司每客户一个业务，业务方向定位非常精准，我这个业务就要解决这个问题。互联网公司面对的2C端，要明确的解决这个问题，满足业务专用化场景产品，也形成了互联网公司一个个集成的开源化产品。当时它设定业务开发人员，一定要针对我这个场景去设计。

       我们所面临的是商务化场景，商务化场景更多是传统行业。传统行业会有历史的遗留系统，这些遗留系统会面临整合，它的业务需求非常繁杂，这些繁杂的业务需求，用户初始时提不出来我需要更多的系统。它需要一套平台支撑多类型业务。同时，在传统行业里面会有非常多的应用开发厂商，这些应用开发厂商需要跟底层的平台进行集成，这些开发厂商实际上能力、水平参差不齐，每个应用开发厂商侧重点也不一样，原来的业务积累方向也不一样，就需要底层的基础人员产品给上层的应用软件集成商提供更多应用的要求产品；是这样的模式。

       针对传统行业在商业化产品设计时，必然要走向中庸的设计原则，通过中庸设计原则混合更多的场景。更多是平衡场景与性能矛盾，通过这样的平衡解决商业化问题。什么时候运用中庸化原则？什么时候解决性能问题呢？第一，需要涵盖更多产品时，我们涵盖更多产品之后性能的平均衰减小于40%，这个时候我们运用更多的场景解决商业化的问题。第二，特定场景下，要求极致性能，提升十倍百倍以上解决这个问题。商业化氛围更多偏向于中庸设计原则，在整个商业化产品设计时也是基于这样原则去做。

       神通MPP怎么解决这个问题？在存储模型设计时，我们实际面临的业务场景有高效的离线分析，多列间值的检索，时间范围的检索，针对这三个场景上面的任何引擎都解决不了，如何维护多系统一致性都是很多问题。尤其建设的数据中心达到一定规模时，包括在保安行业做的数据中心，一份数据就要单本达到TB，在用户的需求下你存成一份两份，这都面临存储的压力。当用户混合经济查询时，一行数据多列同时检索时，会发生多批次的RO操作，造成系统的ROPS（音）非常高。当精确查询混合查询时，系统的利用率非常高，系统访问带宽非常低下，我们抛弃了这样的设计原则。同时，使用了行列混合的设计原则，第一压缩，通过压缩降低成本，降低ROPS的操作。二是导入分析，我通过数据裁减减少范围需求。我们的索引设计也是满足中庸原则，在原来和现在引有的存储引擎，更多引入BC索引，BC索引在一行级非常快，现在我们面临的场景是一张单表一天的数据增量在两万亿行以上，一天增量在两万亿行时，用户的投入成本只能接受200台服务器。200台服务器，也就是说一天的一台服务器接受100亿行，（1：53：46），根本不可以接受。怎么解决这样的事情？我们就要引入怎么降低索引的开销，我们通过建包级索引把索引最小化。实际上线时可以做到一行索引（1：54：46），把它调整到最小，能够满足这样的业务场景一系列需求。

      我们在MPP里面，刚才说过MPP能把它更多融入到生态，怎么融入到生态，我们也对HADOOP整体生态做了分析。HADOOP整体生态不排除任何的存储引擎，它在存储引擎上是通用的。包括Spark RDD、MPI也好，希望跟…一定是底层访问结果非常大时，才会有这种需求，大家知道每秒20行的指标，在这种指标下完成满足不了。其实HADOOP生态对存储引擎访问是二级引擎访问，第一阶段先下一个引擎告诉你我要查询什么？通过这个查询出来每个查询子单元，每个查询子单元所在什么存储位置？商住引擎不管是…也好，基于这个存储位置获取拓扑结构，根据拓扑结构做最就近的访问。第二个阶段再跟每一个存储单元里面对接，通过这种集成可以跟…引擎进行对接，这种对接可以解决更高的性能。通过这种集成方式，原来的…只能解决数据流量和扫描问题，这个存储引擎相对来说更加优雅，这也是今后融合的方式，希望通过这种方式来解决。

      在存储层面的融合，刚才讲的那个层面MPP作为底层的存储，Spak作为上层计算。另外一种是MPP底层更多融合HADOOP的优秀存储引擎，可以把MPP底下数据存储的分布式引擎比如说NoSQL。（1：59：40）。

      这种集成的方式会有很多（2：00：00），引入到MPP内部，变为专业的存储结构。比如说文档性存储，多级结构怎么融入进来？直接在内部发起相关查询，我们能提供更好更优雅的访问方式来扩展集成。

      我们最终达到的是TP、AP融合，这一块目前在开展。目前也分析了相关的一系列存储结构，目前就我们看如何要实现AP和TP的融合，必须要计算计算和存储层。要建立统一的数据副本和异地容灾的策略。构建数据苦专用分布式存储系统，目前也对很多的分布式存储系统进行调研，比如说赛弗，等等一系列的存储系统，其实都不能完全满足这样的要求。TP要求低延迟高并发的访问，AP也需要分布式系统，但是赛弗所造成的数据每一次访问都会有大量的访问交换。AP要求就近访问，要求底层存储能够跟上层有一个位置感知协议，通过位置感知方式获取更多的访问，这样会对数据库有一个专业的分布式系统满足两个同时的要求，这个也有可行的方案，国内有一些产品还没有办法满足，国外有一些产品在走这条路线，可以满足性能的要求。

      第二，基于存储层构建多版本的访问机制，降低分布式事务锁冲突问题。这样在AP、TP做融合时，能够产生相关的好处，进一步让融合成为一种可能性。

       最后，优化器层面上。AP和TP优化器层面上完全不一样，AP里面所有数据是通过远程传递，所以优化器更倾斜于在一条语句发布到一个节点上。在AP分析上，要求数据的访问，要求优化器通过一条语句的多个节点访问，（2：03：49）这需要进行自适应的开发，这就是TP跟AP融合的主要技术指导，通过这样的解决方式满足要求。

      后面是目前上线的MPP案例，第一年也上线了中国联通的全国集中结算系统，当时布点了66个节点集群，这也是非常早的在MPP体系里面部署。后续我们国家网络安全行业做了一系列国家级的重点工程，现在整体在网安行业里面部署的节点数规模大概有300人员，承担着一系列国家级工程。比如说现在的A工程，现在上线的节点数是200个节点，它能够实现每秒3600行的数据接入能力，同时单表TB级。每天的数据量23万亿行，单表23万亿行目前还没有看到有达到这样结果的。

非常感谢大家！