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

Catalyst揭秘 Day8 Final

外部数据源和缓存系统

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

外部数据源处理

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

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

首先，会以反射方式获取provider。

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

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

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

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

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

简单来说，处理流程是：

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

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

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

缓存

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

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

让我们看一下代码：首先进入cacheTable方法。

最重要的是对InMemoryRelation的生成。

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

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

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

最后还是会调用rdd的persist。

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

其他

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

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

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

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

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