Spark+ignite实现海量数据高性能OLAP

        海量数据多维分析我这里指的是通过数据库，然后通过某种专业olap工具（例如cognos等）进行灵活查询的行为，这种查询具有以下特定：

1、行为不可控，在模型范围内随意查询，大表与大表关联，多表关联等等，各种查询行为都有。

2、数据量巨大，大表都有1个T以上的数据。

按我们这么多年的工作实践，海量数据的olap要想达到快速查询其实是非常难的事情，主要难在：

1、查询行为不固定，即使你再努力调优，发现你只能解决一个场景，不能解决所有场景。例如机构，你按照某个字段“机构”进行分区了，命中后提升了查询效率，但是我们有好几个机构，开户机构、管理机构、交易机构，导致了你根本无法对这个模型全面优化

2、专业olap工具我们使用并不是很理想，我们曾经尝试过cube或者麒麟等产品，但是因为需求不会一成不变，一旦需求变更整个模型就要从新加载数据；维度多，多到产品都无法支持，即使能够支持cube也会膨胀非常厉害，所以我们最终还是放弃了。

    现在，我们主要基于数据库+BI工具的方式，因为这样数据加载、修数、模型变更等非常灵活，但是这样一来就会把所有压力传导给数据库，也就是你的bi效率快慢完全取决于数据库的快慢。下面我说一下几个产品的比较：

1、oracle数据库，它的性能调优主要通过主键、分区、索引等解决，所以对于千万级别数据量简单查询还可以，但是对于动辄大几千万、亿以上的多表关联，一旦没有命中索引，cpu马上就会告警。前面已经说过，灵活查询根本无法预知查询行为。所以不命中是大概率事件。

2、mpp数据库（例如GP），由于实现了分布式，会自动重分布，不用建索引也能实现高效查询，所以对于海量数据查询我们目前使用的方案基本都是采用gp。但是同时也带来一些问题，查询性能不高，分钟级以上是经常发生，并发不大。

3、hadoop+spark的方式，底层可以提供HIVE、hbase等数据库，大宽表查询我们可以直接指向hbase，我感觉灵活性比gp数据库好。虽然有索引，但是经测试基本没有任何效率的提升。使用这种方式，最好能够强制命中分区键（例如日期），命中的情况下效率非常好。

4、Spark+ignite，这是我目前认为最好解决海量数据高性能计算、查询的最好方案：

Ignite是一个分布式的内存数据库、缓存和处理平台，为事务型、分析型和流式负载而设计，在保证扩展性的前提下提供了内存级的性能。

Spark是一个流式数据和计算引擎，通常从HDFS或者其他存储中获取数据，一直以来，他都倾向于OLAP型业务，并且聚焦于MapReduce类型负载。

整合这两种技术会为Spark用户带来若干明显的好处：

通过避免大量的数据移动，获得真正可扩展的内存级性能；

提高RDD、DataFrame和SQL的性能；

在Spark作业之间更方便地共享状态和数据。

下图中显示了如何整合这两种技术，并且标注了显著的优势：

经测试，我们对某个场景进行查询1天数据只用3秒、明显高于hadoop好几倍。查询一个月数据，只要4秒，说明在大数据量情况下依然能够保持良好的查询效率。

Ignite有索引，经测试，加索引以后效率快很多

Ignite既可以用内存，也可以用ssd盘，所以在一定数据量情况下是能够保证效率。他本身就是一个数据库，也可以把一些内容持久化到硬盘。并且是多备份的，保证数据不丢失。但是我并不建议把它完全当硬盘数据库使用，取其优势就可以了。

但是他的弊端也是非常明显的，就是完全依赖内存或SSD盘的大小，我们发现其实只有20%的应用承载了80%的访问量，所以我们大不不必把所有应用采用这种方案，只把访问量大放到ignite就可以了。其他低频的依然在hadoop或者mpp数据库，采用传统数据库和这个方案相结合。

新技术层出不穷，特别是现在基于hadoop也有很多实现方案，如果我发现好东西再告诉大家