其他特性对比
Presto也是完全基于内存的并行计算,注意内存保护,根据数据量情况,为每个节点设置合适的内存大小,否则大数据量情况下,内存溢出就是家常便饭;Impala2.0之后支持内存不够情况,数据吐给磁盘,虽然有了可靠性保护,但是内存与磁盘的I/O交换会带来更慢的吞吐。
Presto由调度节点(Coordinator)和注册与发现节点(Discovery Service)实现SQL执行的集群调度管理,由于Coordinator和Discovery Service都是单节点部署,可能会因为Coordinator故障,产生多个Coordinator服务,导致集群的脑裂问题,因此一般建议都是Coordinator和Discovery Service放在一个节点上部署,形成Discovery对Coordinator的唯一性指定,然后再做成一主一备两个节点形成HA,这样主节点服务挂掉,备集群Work都连接到备节点上,实现主备节点的热替换。
Impala的后台服务因为是无共享的架构模式,非常适合集群节点的无限扩张,但往往需要在Impala集群之上安装一个客户端请求负载均衡器,实现对Impalad服务的负载调度。
最后就是Impala的架构更适合于计算与存储放在一起的就近读取原则,有效防止网络传输数据的损耗;但是Presto的架构更倾向于计算与存储分离,存储系统多样化的支持,虽然使自身变得灵活,适配性高,但是默认读数据源并不是采用就近读取原则,导致计算访问数据都是远程操作,例如:在复杂的大数据集Join操作,会导致严重的网络传输的性能损耗。
Spark SQL
Spark架构
作为大数据处理计算的大一统软件栈Spark,或将是大数据处理领域里面的Spring framework。我们从下图中可以看到Spark core之上具有了四种面向不同计算领域或方式的Spark模块,Spark streaming模块面向实时流计算,具体方式采用微批处理;MLlib模块面向Spark的机器学习库,尤其是Spark默认对Python的支持,成为Python开发者接入Hadoop生态平台的绝佳入口;GraphX面向图处理,有了GraphX,对于社交网络、知识库、超文本关联度分析、传染病传播预测等应用领域,都可以使用Spark来处理。
我们本次主要分析了解到是Spark SQL,一个将不同来源数据进行关系结构化再进行计算处理的模块。
DataFrame
示例
Spark SQL可以支持从很多种数据源的结构化抽象,Spark SQL从数据源中抽取数据集后抽象成一种具有schema结构的rdd对象:DataFrame,有点类似拿到了一个Hibernate的Session与实体对象的合体(类似,可能不太恰当),可以执行类似下面例子中DataFrame(df)的查询操作。
大家可以看到DataFrame实际上就是将数据源结构化为SQL表列。因为DataFreame也需要进行schema定义。类似下图:
支持的数据源
Spark SQL可以从哪些数据源建立DataFrame结构化模型呢?
json:Spark自动推断数据结构和类型
Parquet Spark的默认数据源,自动保存schema
Hive table Spark支持直接读取Hive数据
JDBC Spark通过Jdbc驱动拉取Rdbms数据表数据
CSV 可根据CSV行头定义列
等等......
架构
如下图所示:
1.客户端根据自己的目标语言,Java、Python、Scala进行Spark SQL操作。
2.Spark SQL访问上述的各种数据源,创建DataFrame对象。
3.通过对DataFrame API的调用,实现SQL方式操作数据(查询、聚合、分组等、连接等)。
4.Spark SQL将SQL操作语句调入Catalyst Optimizer引擎形成执行计划。
5.执行计划进入Spark处理引擎,由分布在不同节点的Spark集群任务并行处理SchemaRDD(DataFrame)。
Catalyst优化器
Spark SQL执行的SQL语句在Catalyst优化器中经历了逻辑计划、物理计划两个过程,逻辑计划过程主要依赖Antlr。首先SQL语句在unresolved logical plan阶段由antlr转换成抽象语法树,这时候会根据Catalog中(存储了所有的表信息、DataFrame信息)的元数据,对unresolved logical plan进行表达式解析,确定表、列都存在后,才会形成真正的resolved logical plan,最后交付Catalyst优化器进行优化逻辑计划(Optimized logical plan)。如下图所示:
转换成功的逻辑计划将进入物理计划阶段,Optimized logical plan会分解为多个物理计划(Physical Plans),最终进入代价模型(Cost Model),根据资源开销成本,去选择最佳的物理计划(Best Physical Plan),最终进入到集群中运行。如下图所示:
Dataset
在Dataframe之后Spark推出了一个新的数据抽象:DataSet,DataSet可以理解为DataFrame的扩展,对象类型更为显性,这种优势就是在开发起来具有更友好的API风格,更适合工程化管理。
例如:我们定义了一个叫Flight的Dataset实体类
我们可以将DataFrame转换成Flight class类型的Dataset,这时候的变量flights就是Dataset[Flight]强类型了,即具有类型安全检查,也具有Dataframe的查询优化特性。
Dataset在编译时就会检查类型是否符合规范。Dataset仅适合用于基于JVM的Scala、Java,通过case类或Javabeans指定类型。
当调用DataFrame的API时,返回的结果结构就是Row类型;当使用DatasetAPI时,就可以将将Row格式的每一行转换为指定的业务领域对象(case类或Java类)
Spark集群架构
我们可以将Hive、Impala、Presto理解为比较独立的数仓工具,在上一篇中Impala和Presto的对比,我们甚至可以看到它们俩具有独立的分布式架构。Hive则是Hadoop生态独立性很高SQL解析与执行工具,插接Mapreduce、Spark、Tez计算引擎,高度依赖HDFS存储系统。
反观Spark SQL,它并不独立,应是Spark平台上的一组模块,彻底与Spark糅合在一起,因此谈Spark SQL的分布式架构,其实就是在讲Spark架构。我们从下图可以看到Spark架构的特征,在集群计算资源调度方面与Spark无关,主要依赖Hadooop Yarn或者Mesos实现分布式集群计算资源的调度管理。
同理Spark SQL解析完成物理计划后就完成交由Spark集群进行并行任务处理,Spark集群中Driver提交作业、实现调度,Executor具体执行任务、返回结果。
Executor中通过多线程方式运行任务(Task),而且Executor通过堆内内存、堆外内存管理,实现高性能的内存计算,这点是Spark性能上优于Mapreduce将中间过程数据写入磁盘导致性能慢的关键原因之一。