CloudComputing云计算SparkSQL：基于内存的大数据处理引擎文／高彦杰，陈冠诚作为Shark的下一代技术，SparkSQL的性能已完全超过Shark，且由于底层机制相同，用户可以做到无缝迁移，而受到用户的青睐。本文将深入分析SparkSQL架构思路和优化策略，并与同类产品进行比较。104在刚刚结束的SparkSummit2014上，Databricks宣布不再支持Shark的开发，全力以赴开发Shark的下一代技术SparkSQL，同时Hive社区也启动了HiveOilSpark项目，将Spark作为除MapReduce~Tez之外的新执行引擎。根据BigDataBenchmark测试对比数据，Shark的InMemory性能可达到Hive的100倍，即使是OnDisk也能达到1O倍的性能提升，是Hive的强有力的替代解决方案。而作为Shark进化版本的SparkSQL，在最新测试中的性能已超过Shark。本文中，统称SparkSQL、Shark和HiveonSpark为SQLonSpark。虽然Shark不再开发，但其架构和优化仍有借鉴意义，因此文章中也会有所涉及。为什么使用SparkSQL由于Shark底层依赖于Hive，所以这个架构的优势是传统Hive用户可以将Shark无缝集成进现有系统运行查询负载。但也有一些问题：随着版本升级，查询优化器依赖于Hive，不方便添加新的优化策略，需要进行另一套系统的学习和二次开发，学习成本很高。另一方面，MapReduce是进程级并行，~HHive在不同的进程空间会使用一些静态变量，当在同一进程空1司进行多线程并行执行时，多线程同时写同名称的静态变量会产生一致性问题，所以Shark需要使用另一套独立维护的Hive源码分支。为了解决这个问题，AMPLab和Databricks利用Catalyst开发了SparkSQL。在Spark1．0版本中已发布SparkSQL。机器学习、图计算、流计算如火如荼的发展和流行吸弓1了大批学习者，那为什么还要重视在大数据环境下使用SQL呢?主要有以下几点原因。-易用性与用户惯性。在过去很多年中，有大批程序员的工作是围绕着“DB+应用”的架构来做的，SQL的易用性提升了应用的开发效率。程序员已习惯业务逻辑代码调用SQL的模式去写程序。提供SQL和JDBC的支持会让传统用户像以前一样地编写程序，大大减少了迁移成本。一生态系统的力量。很多系统软件性能好，但未取得成功和没落，很大程度上因为生态系统问题。传统的SOL在JDBC、ODBC等标准下形成了一套成熟的生态系统，很多应用组件和工具可以迁移使用，如一些可视化工具、数据分析工具等，原有企业的ITEK具可以无缝过渡。一数据解耦，SparkSQL正在扩展支持多种持久化层，用户可使用原有的持久化层存储数据，也可体验和迁移~ljSparkSQL提供的数据分析环境。SparkSQL架构分析SparkSQL与传统“DBMS查询优化器+执行器”的架构较为类似，只不过其执行器是在分布式环境中实现的，并采用Spark作为执行引擎。SparkSQL的查询引擎是Catalyst，其基于Scala语言开发，能灵活利用Scala原生的语言特性方便地进行功能扩展，奠定了SparkSQL的发展空间。Catalyst~SQL语言翻译成最终的执行计划，并在这个过程中进行查询优化。与传统方法的区别在于，SQL经过查询优化器最终转换为可执行的查询计划是一个查询树，传统DB可以执行这个查询计划，而SparkSQL会在Spark内将这棵执行计划树转换为有向无环图(DAG)再进行执行。Catalyst架构及执行流程分析图1中是Catalyst的整体架构，可以看~rJCatalyst是SparkSQL的调度核心，它遵循传统数据库的查询解析步骤对SQL进行解析，转换为逻辑查询计划和物理查询计划，最终转换为荭行执行(图2)。SparkSQL优化策略除了查询优化，SparkSOL在存储上也是进行了优化，下面看看SparkSQL的优化策略。内存列式存储与内存缓存表SparkSQL可以通过cacheTable将数据存储转换为列式存储，同时将数据加载到内存进行缓存。cacheTable相当于分布式集群的内存物化视图，将数据进行缓存，这样迭代的或者交互式的查询不用再从HDFS读数据，直接从内存读取数据大大减少了I／O开销。列式存储的优势在于SparkSQL只需要读出用户需要的列，而不需要像行存储那样需要每次将所有列读出，从而大大减少内存缓存数据量，更高效地利用内存数据缓存，同时减少网络传输~uI／O开销。并且由于是数据类型相同的数据连续存储，能够利用序列化和压缩减少内存空间的占用。列存...
