一种基于Spark大数据处理平台的查询方法
【技术领域】
[0001] 本发明涉及一种数据处理的查询方法，尤其涉及一种基于Spark大数据处理平台 的查询方法。
【背景技术】
[0002] 随着互联网的发展，数以万计的网页不断涌现，而要搜索这些网页首先要抓取存 储，然后进行分析计算，google就是这么做的，但是日益庞大的数据使得存储面临着单台机 器容量不够的问题，查询面临着耗时太多的问题;针对这两个问题，google提出了分布式存 储和分布式并行计算的解决方案，而后来的hadoop产品是这种解决方案的源码实现； hadoop提供了分布式文件系统HDFS和分布式并行计算框架MapReduce，随着hadoop的发展， 其生态系统又不断涌现新的项目产品，如Hbase、hive、pig等，但它们都是基于HDFS存储层 和MapReduce计算框架，MapReduce通过在集群的多个节点上并行执行计算，因此大大加快 了查询的速度，但随着数据量的日益增大，MapReduce渐渐显得力不从心，于是基于内存计 算的Spark计算框架应运而生，Spark的查询速度相比hadoop提升了100倍，因此是目前最先 进的分布式并行计算框架；随着Spark生态系统的发展，在其上又涌现出Spark SQL、Spark Streaming、ML1 ib、GraphX等，其中Spark SQL是针对SQL用户开发的可以用SQL语言对结构 化数据进行分析查询的工具。
[0003] 如图1所示，现有技术中，以使用Spark SQL应用程序为例，基于Spark大数据处理 平台的查询方法可以分为五个步骤：
[0004] 步骤I、Spark SQL应用程序接收用户的SQL语句后，进行语法解析、执行策略优化、 job (查询作业)生成，最后通过调用Spark平台中的SparkContext接口进行job的提交；
[0005] 步骤2、SparkContext收到job后，定义Task (计算任务)执行成功后如何存储计算 结果，然后提交job给eventProcessActor，接着等待eventProcessActor告知job执行结束， 结束后将计算结果返回给Spark SQL;
[0006] 步骤3、eventProcessActor收到提交job的事件后，在各个节点分配多个Task开始 并行计算；
[0007] 步骤4、每个Task执行完毕后向eventProcessActor报告状态和结果， eventProcessActor统计job的所有Task是否全部完成，若完成，则通知SparkContext提交 的job已结束，SparkContext返回计算结果给Spark SQL;
[0008] 步骤5、Spark SQL得到计算结果后，先进行格式转化，然后拷贝一份给输出模块， 最后由输出模块输出结果。
[0009] 如图2所示，步骤1主要是解析SQL语句的语法并生成一组代表一个Job的RDD，RDD 是一种分布式数据结构，它描述了要处理的分布式存储的数据以及怎样处理的算法，因此 一个RDD就代表对数据的一个操作，一组RDD就是一个操作序列，按序完成了这一系列操作 后即代表完成了一次查询计算；Spark采用了延迟执行策略，即每个操作不先执行，而是先 生成操作的序列，然后把这个序列发送给执行器执行;这一组RDD所代表的操作因为有序且 不循环，因此其组成的逻辑依赖图又称有向无环图（DAG);在DAG中，下游的RDD是上游的RDD 执行某个操作后生成的。
[0010]如图3所示，步骤2主要是将D A G提交给处于另一个线程环境的 eventProcessActor，提交前，分配一块内存，并告知eventProcessActor当Task执行成功后 往这块内存中存储结果，提交后，当前线程挂起，等待eventProcessActor在job完成后唤醒 它，被唤醒后，此时所有Task已经执行结束，并且计算结果全部已经存储到事先分配的内存 中；因此直接将这块存储了结果的内存地址返回给Spark SQL模块。由于要等到所有Task执 行结束才能返回结果，因此客户响应时间过长，事实上，每个Task的结果都是最终结果的一 个子集，没有必要一起输出所有的结果子集;另外，由于输出前要存储整个查询结果，结果 的大小将直接受限于程序的堆栈大小。
[0011] 如图4所示，步骤3主要是实现DAG阶段的划分以及每个阶段Task集合的生成。每个 阶段的所有Task执行的都是相同的操作，只不过它们作用的数据不同罢了，因此它们可以 完全并行执行;但是不同阶段的Task就不一定能并行了。每个深灰色填充矩形代表一个数 据块，并且每个数据块都对应一个Task对其进行计算，由于RDD2的数据块是根据RDD1的多 个数据块计算得来的，因此就需要等待执行RDDl的所有Task结束才能开始计算RDD2,所以 RDDl和RDD2需要分属两个不同的阶段，而RDD2计算出RDD5时，每个数据块都是独立进行的， 互不依赖，RDD2中计算其中一个数据块的Task不需要等待其它数据块的Task结束即可开始 向RDD5生成的计算（此处是join操作），因此RDD2和RDD5可以同属一个阶段；同理，RDD3和 RDD4可以同属一个阶段，但RDD4不能和RDD5同属一个阶段；图4中，stagel和stage2互不依 赖，可以并行执行，stage3同时依赖stagel和stage2，因此必须等待stagel和stage2均完成 后才能执行。
[0012] 如图5所示，步骤4主要是最后一个阶段的Task执行成功后，将计算结果存储到 SparkContext指定的内存中；在图5中，stagel和stage2的Task执行结束后只生成中间结 果，stage3的每个Task才是最终结果，而最终输出的结果是由stage3的每个Task的结果拼 接而成，在拼接的过程中可能会有排序。如图6所示，如果查询语句要求对结果进行排序，则 Task的结果按序存放，如果不对结果排序，则结果按照Task完成的先后顺序排序，每次查询 的结果排列顺序将是随机的。对于结果排序的情况，既然每个Task知道它的结果应该排在 什么位置，那么应该排在首位的Task就已经计算出了最终结果的头部，可以立即通知客户 了；对于结果不排序的情况，由于客户不关心结果的排列顺序，因此不管哪个Task先计算完 成，其结果就可以告知客户了，没有必要去等到其它Task，而且即使等待，最终的结果也是 按照它们执彳丁完成的先后顺序排序的。
[0013] 步骤5主要是对记录行数组形式的结果格式化为字符串序列，每一行记录转换成 字符串格式，并且将列分隔符替换为制表符，最后输出模块在提取格式化后的结果时，复制 一份到输出模块，然后输出。事实上，对结果的格式化不是必须的，格式化可能看起来更美 观，但是却消耗了大量内存和性能，在某些情况下，数据本身已经很工整了，此时就没必要 去格式化。
[0014] 综上所述，现有技术中基于Spark大数据处理平台的查询方法存在以下技术问题：
[0015] 1、目前Spark大数据处理平台执行查询时，用户响应时间过长，尤其是分析较大规 模数据时，其响应时间更是超出了用户所能忍受的程度，并且随着分析数据量的增大，这种 响应延迟也将同步增加。
[0016] 2、目前Spark大数据处理平台不支持大规模查询结果的输出，默认配置只允许输 出IG的查询结果数据量，配置的过少，将不能充分利用内存资源，配置的过多，若结果超出 实际剩余的内存空间将导致内存溢出异常;再者，对于内存配置较低的机器环境，允许输出 的数据量将进一步大大缩减。
[0017] 3、Spark SQL在获取Spark大数据处理平台的计算结果后，要进行一些格式转化和 数据拷贝后才正式输出，将造成内存中相同或近似相同的数据有多个拷贝，浪费了内存资 源，也降低了性能，也直接影响了用户响应和结果存储容量，并且这种影响会随着输出结果 的增大而增大。
【发明内容】
[0018] 本发明要解决的技术问题是提供一种基于Spark大数据处理平台的查询方法，该 查询方法在执行常规的简单查询时(DAG阶段比