spark 愿景

代码量和可读性

mapreduce 非常多

rdd 精简很多 但不太容易看懂

sql dataframe 更易懂、更简洁

读写：

可以使用自定义数据源实现ETL

案例：将网站数据查询后保存到hive中

写更少代码

select

join

aggregation

filter

schmea推导抽取：可将json文件对应一个表格

关系型数据库创建名称、类型

半结构化数据：可以推断出字段类型

大数据比较脏的，作一定的清理

能够合并不同的schema信息，但是必须兼容的

建议json转成orc或parquet文件，更快

schema合并自动化

可以对schema比较混杂的json,parquet自动推断合并（字段并，类型合并）

表现为一张表

自动分区探测：

表分区通用的优化方式

查询的时候只需要跟上今天的分区（）分区的条件（分区的列标识在分区目录上的）

gender=male作为目录名

parquet能够自动推断分区

好处是查某一性别某一国家

1000万数据聚合dataframe大概2s,RDD python 10s,rdd scala 4s

dataframe执行计划，计算在jvm提升

rdd python vm 与jvm需要大量跨进程交换

rdd scala

总体上，dataframe更快

dataframe 封装逻辑计划

为什么rdd比dataframe慢？函数式编程，创建很多对象

dataframe 尽可能使用已有对象

可以从分利用spark sql内部的特性，不但代码写得好，而且可读，优化

读更少数据

最快：忽略它

并非对所有数据熟视无睹，根据适当条件进行过滤；

能帮我们自动读更少数据：

列式存储，仅仅扫描需要的列（pqrquet,orc）

分区剪枝，日志表（who when what 记录操作日志，按照时间分区）

对于一些存储格式（如列式）：存储每块数据统计信息，最大值，最小值

支持条件（predicate）下压到数据源，从数据源段进行筛选

优化：（列式存储，分支裁剪，条件下压）

列式存储到底是什么样的呢？

row a1,b1,c2 a2,b2,c2 ...

col

a1,a2,a3..==>encoding chunk 

b1,b2,b3 ==>encoding chunk

底层优化

如何进行优化的呢？