对于压缩算法的选择，我们倾向于对不同场景选择不同的压缩算法。
数仓一般被分为三层:
ODS层: 源数据层 , 主要和数据源打交道
原始日志一般采用 textFile存储 ，我们可以创建临时外部表，location指定原始日志位置，可以查询导入到ODS层,存储格式, 一般采用：ORC + ZLIB (从文件 到表的导入操作, 也可以使用 load data 操作，而load data 只能适用于 普通文本类型)
DW层: 数据仓库层, 主要使用进行数据分析工作
对于DW层, 表数据的格式, 一般采用的 : ORC + snappy的压缩.
APP(dm ADS)层: 数据应用层 数据展示层 , 主要是用于存储分析的结果数据
后期如果要对接BI, 可以将结果数据, 从APP层将数据导出到 交互式的数据库(mysql)中,从而提升BI查询数据的效率,对于APP层, 表数据的格式, 一般采用的 textFile.
----------------------------------
测试, 不同的文件存储格式, 对应压缩比如何: 压缩后文件大小 和 解压的效率
请问压缩方案, 是不是压得越小, 越好呢? 并不是, 在选择压缩方案的时候, 要选择一个压的效率和 解压效率都相对而言比较高
textFile存储文件大小为: 18.1M
ORC存储文件大小为 :2.8M 列式存储, 而且内置了一种ZLIB压缩算法
orc将压缩算法去掉, 不压缩: 7.7 M
PARQUET存储文件大小为: 13.1 M
不同格式存储同一份数据, 最终文件大小比较:
ORC > PARQUET > textFile
不同类型的查询时间比较:
textFile查询的时间为: 14.307 秒
ORC查询的时间为: 10.815
parquet查询的时间为: 12.217
ORC > parquet > textFile
由此可见, 一般采用文件存储格式为 ORC格式
提供在DW层, 构件表的标准建表方案:
create table log_orc_snappy(
track_time string,
url string,
session_id string,
referer string,
ip string,
end_user_id string,
city_id string
)
ROW FORMAT DELIMITED FIELDS TERMINATED BY ‘ ‘
STORED AS orc tblproperties ("orc.compress"="SNAPPY");
注意: 虽然使用snappy, 没有使用ORC默认的压缩算法形成文件更小, 但是带来好处, 大大提升压缩效率 和 解压效率
以后工作中:
1) dw层采用 ORC + snappy
2) 在查询分析数据的时候, 开启 map 和 reduce端的压缩方案 ;
参考：
https://www.yht7.com/news/111585
https://ericsahit.github.io/2017/09/10/Hive%E5%8D%87%E7%BA%A7%E5%85%A8%E5%A7%BF%E5%8A%BF/