Catalyst揭秘 Day8 Final 外部数据源和缓存系统

Catalyst揭秘 Day8 Final

外部数据源和缓存系统

今天是Catalyst部分的收官,主要讲一些杂项内容。

外部数据源处理

什么叫外部数据源,是SparkSql自己支持的一些文件格式,以及一些自己自定义格式的文件开发。

让我们从文件的读取api开始,可以看到最终会创建一个DataFrame,当中比较关键的是relation方法。
Snip20160729_21

首先,会以反射方式获取provider。
Snip20160729_22
Snip20160729_23

我们以json文件为例,其provider为json.DefaultSource。可以看到继承自HadoopFsRelationProvider。
Snip20160729_26

进入其处理,可以看到,首先是获取文件路径,其后是调用了createRelation方法。
Snip20160729_27

让我们进入json.DefaultSource的createRelation,创建了JSONRelation。
Snip20160729_29

JSONRelation继承自HadoopFsRelation,来自interfaces.scala,定义了对各类文件的处理接口。
Snip20160729_30

最终JSONRelation组合入LogicalRelation中,提供后续解析器处理。
Snip20160729_31

简单来说,处理流程是:

  1. 目标是调用ResolvedDataSource生成Relation(比如JSONRelation)。
  2. 首先通过反射方式获得RelationProvider(比如json.DefaultDataSource)。
  3. 根据RelationProvider的类型(比如HadoopFsRelationProvider),准备参数,并生成Relation。
  4. Relation中除了文件具体信息外,还会继承一个intereface(比如HadoopFsRelation),根据文件类型,封装对文件的具体操作。

在optimizer中,对于文件的操作,在执行过程中还支持过滤下推,根据算子生成下推条件。
Snip20160729_32

filters中定义了一系列算子,可以在服务器上直接过滤数据,而不是集中到客户端过滤。
Snip20160729_33

缓存

我们看下缓存,很多算法都是缓存+并行来做的,是一个开发者逃不掉的魔咒,在Catalyst中直接cacheTable就可以缓存。

缓存在内存中,是以什么方式存储的?肯定是列式存储的方式,因为列式存储检索数据特别快,不是RDD一行一行object存放的方式,缓存的时候,对象会进入jvm的老年代,很容易产生full GC,进行交互查询容易悲剧。基于列的话,就可以采用类似byteBuffer这样的方式,由于是同样的数据类型,可以进行压缩,内存占用会极大的减少。查询的时候,只使用部分列也是一个自然的思路。

让我们看一下代码:首先进入cacheTable方法。
Snip20160729_34
最重要的是对InMemoryRelation的生成。
Snip20160729_35

InMemoryRelation继承自LogicalPlan,其方法都是一些简单的基于字节的编程

Snip20160729_36

内部做cache的时候,根据构建的树,会采用mapPartitions的方式。
Snip20160729_37

具体在partition里面,会迭代数据生成新的iterator,是ByteBuffer构成的array,对于每个列都会变成array的一部分,在遍历没一行数据的时候,都会变成列,每一列数据都会存入byteBuffer,

最后还是会调用rdd的persist。
Snip20160729_38

这个看起来有点像高性能的内存数据库,在进行表的查询时,把内存数据结构的分区进行具体的扫描操作,根据查询表达式建立索引,通过扫描器accessor获得具体的数据。
Snip20160729_39

其他

Catalyst支持让我们自己采用udf、udaf的方式去扩展功能,catalyst在分析的时候,会支持这方面的功能,由functionRegistry来进行管理。

可以看到FunctionRegistry中主要是一些管理类方法。
Snip20160729_40

到此,Catalyst中比较重要的功能都已解析完毕。

欲知后事如何,且听下回分解!

DT大数据每天晚上20:00YY频道现场授课频道68917580

posted @ 2016-07-29 20:56  哎哟慰  阅读(298)  评论(0编辑  收藏  举报