zoukankan      html  css  js  c++  java
  • Hive表设计压缩问题

    对于压缩算法的选择,我们倾向于对不同场景选择不同的压缩算法。

    数仓一般被分为三层:
    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端的压缩方案 ;

    参考:

    Hive官网

    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/

  • 相关阅读:
    【队列】队列的分类和实现
    【JSP】EL表达式语言
    【JSP】JSP的介绍和基本原理
    【JSP】JSP Action动作标签
    【Servlet】关于RequestDispatcher的原理
    【JSP】JSP指令
    【JSP】JSP中的Java脚本
    【算法】表达式求值--逆波兰算法介绍
    C语言指针详解
    移动架构-MVVM框架
  • 原文地址:https://www.cnblogs.com/-courage/p/14201730.html
Copyright © 2011-2022 走看看