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中，提供后续解析器处理。
简单来说，处理流程是：
- 目标是调用ResolvedDataSource生成Relation(比如JSONRelation)。
- 首先通过反射方式获得RelationProvider(比如json.DefaultDataSource)。
- 根据RelationProvider的类型(比如HadoopFsRelationProvider)，准备参数，并生成Relation。
- 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
