【技术干货】Hive实践分享之存储和压缩的坑

    在学习大数据技术的过程中，HIVE是非常重要的技术之一，但我们在项目上经常会遇到一些存储和压缩的坑，本文通过科多大数据的武老师整理，分享给大家。
    大家都知道，由于集群资源有限，我们一般都会针对数据文件的「存储结构」和「压缩形式」进行配置优化。在我实际查看以后，发现集群的文件存储格式为Parquet，一种列式存储引擎，类似的还有ORC。而文件的压缩形式为Snappy。具体的操作形式如下：
    ① 创建Parquet结构的表（Hive 0．13 and later）：
    CREATE TABLE CRM．DEMO（A INT） STORED AS PARQUET ；
    ② 确认表的文件存储格式：
    desc formatted crm．demo；
    结果输出如下
    ＃ Storage Information
    SerDe Library：          org．apache．hadoop．hive．ql．io．parquet．serde．ParquetHiveSerDe
    InputFormat：                 org．apache．hadoop．hive．ql．io．parquet．MapredParquetInputFormat
    OutputFormat：               org．apache．hadoop．hive．ql．io．parquet．MapredParquetOutputFormat
    ③ 创建Snappy压缩格式的Parquet结构的表（待考察）：
    ALTER TABLE crm．demo SET TBLPROPERTIES （＇parquet．compression＇＝＇SNAPPY＇） ；
    或，写入时
    SET parquet．compression＝SNAPPY ；
    回到最初的问题，如果是按Snappy压缩的格式，这份用户行为数据没办法分析了，因此有两种办法去解决：
    ① 安装Snappy的解压工具
    可自行百度，由于没有权限，所以这条路行不通；
    ② 更改数据的压缩格式可以
    最初我试了一下更改Parquet格式表的压缩格式，但是没有用！因为我最后是需要将查询数据导出到本地文件系统，如下语句所示：
    insert  overwrite  local  directory  ＇／home／etl／tmp／data＇
    select ＊
    from crm．demo
    所以，通过这样的形式得到的数据，压缩格式依然是． Snappy。因此，这里就需要配置Hive执行过程中的中间数据和最终数据的压缩格式。
    如MapReduce的shuffle阶段对mapper产生的中间结果数据压缩：
    hive＞ set mapred．map．output．compression．codec；
    mapred．map．output．compression．codec＝org．apache．hadoop．io．compress．SnappyCodec
    如对最终生成的Hive表的数据压缩：
    hive＞ set mapred．output．compression．codec；
    mapred．output．compression．codec＝org．apache．hadoop．io．compress．SnappyCodec
    这里，我们要设置结果表数据的压缩格式，语句如下：
    set mapred．output．compression．codec＝org．apache．hadoop．io．compress．GzipCodec；
    最终的结果就是 ．gz 的压缩格式
    －rw－r－－r－－ 1 etl etl 342094 May 10 11：13 000000＿0．gz
    最后，我们直接下载到电脑本地，直接解压就可以通过Excel分析用户行为路径数据了。
    总结：从Hive应用层的角度来说，关于数据文件的「存储结构」和「压缩形式」，这两个点我们不需要关心，只是在导出数据的时候需要结合文件大小，以及数据类型去设置合适的压缩格式。不过从Hive底层维护的角度来说，涉及到各种各样的「存储结构」和「压缩形式」，都需要开发者去研究和调整，这样才能保证集群上的文件在「时间」和「空间」上相对平衡。