Spark官方给出的性能是内存模式比mapreduce快100倍，磁盘模式比mapreduce快10倍。有没有办法让Spark这个基础上在继续快百倍？答案必须是肯定的。让我们先分析下Spark为什么会比mapreduce快，然后分析下在这种模式依然存在的问题，最后给出我们的解决方案。

首先Spark为什么会比mapreduce快。
1.Spark减少了中间过程的磁盘读写，数据很多时候不需要落地，从而提升了效率。
2.Spark基于内存的读写，减少了磁盘IO、node数据交互的通信时间。
3.Spark并非mapreduce心跳的模式，任务调度性能比mapreduce快，适合迭代计算。

依然存在的问题以及改进思路。
1.依然是暴力扫描-需要索引。
如果数据总量几百亿，但很多时候我们只想对其中的含有某些关键词的数据进行分析，Spark依然要从头到尾扫描这几百亿的数据，太浪费资源，我们需要对每个维度的值创建一层索引，通过索引我们可以将不想关的记录直接跳跃过去，只对满足匹配条件的结果进行计算。这样即使总量有百亿，但经过匹配后的记录数可能仅仅是几千万，对这几千万的数据进行统计分析与对整体的100亿的数据进行统计分析，性能肯定要快上千倍万倍。
2.大部分的列均有重复值，Spark没有针对这种情况进行优化。
Spark目前的分组统计和排序计算直接读取数据的真实值，这样计算量以及磁盘IO都很大。
在真实的数据中，数据肯定是有重复的，我们可以对数据排重后按照数据大小进行编号，我们在这里称之为标签。
1）排序和分组仅仅使用标签进行计算。
2）用标签来代替原始值后，原始值仅仅存储一份，索引体积变小。
3）标签根据列的数据重复程度不同，标签的长度可以是1bits~32bits，内存中对应byte,short,int类型，因绝大部分数据都有重复，故short类型居多,占用存储空间也小。
4）使用原始数据的真实值（字符串），进行大小比较太耗费CPU资源，相比于完全数值型的标签，标签计算占用的cpu更少。
5）大多数的计算只需要使用标签，而不需要使用标签对应的原始值，仅仅在计算完毕后，将一少部分标签转换为真实值，给用户即可。
3.部分格式支持列存储，但尚有优化空间。
有相当一部分的场景我们只需要获取TOP N 条结果，以下面这条SQL为例
select a,b,c,d,e,f,g,h,i,j,k,l,m,x from testtable order by x desc limit 10
我们只需要获取前10个最大值的x列即可，目前Spark的处理方式是将a,b,c,d,e,f,g,h,i,j,k,l,m,x 这14个列的值全部都读取出来，然后在按照x排序取出TOP N，其实最简单的变换下思路即可，我们先只取出x列,其他的13个列的数据并不读取，按照x列排序得到TOP N结果后，在将剩余的N个结果的13个值附加进来即可，这种先排序，后附加其他列的方式，相对于Spark那种将14个列全部读取出来，IO一下降低了13倍。

解决方案
当然需要实现上述的3点需要在Spark的基础上做很多工作，但好在我们不需要自己来开发，已经有人帮我们做好了。我们可以试下
spark运行在ydb上，从而将spark的查询速度直接提高。
延云YDB,为大数据即席分析而生的数据库,核心是大索引，是延云自主研发的海量数据实时在线分析（OLAP）系统，只需一百台机器就可近实时的对每天千亿、总量万亿级数据进行秒级的全文检索以及多维分析。
本文不想过多的对YDB做过多的宣传，有兴趣的读者可以访问 http://ycloud.net.cn 去查看，这里仅仅介绍YDB如何与SPARK进行对接，从而提升查询速度。

基本思路是这样，Ydb实现了Spark的StorageHandler接口，spark可以访问YDB的数据，在SPARK读取YDB的数据之前，
1）YDB会先利用自己的索引将没必要的行给过滤掉
2)也会针对有大量重复值的列按照标签进行预汇总(类似mapreduce的combine)，但这个预汇总采用了标签技术，针对重复值的列只读取一次IO。
3)针对TOP N排序，也采用了先排序，后附加其他列的方式。