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

在自学大数据技术的过程中，HIVE是十分最重要的技术之一，但我们在项目上常常不会遇上一些存储和传输的坑，本文通过科多大数据的武老师整理，共享给大家。大家都告诉，由于集群资源受限，我们一般都会针对数据文件的「存储结构」和「传输形式」展开配备优化。

在我实际查阅以后，找到集群的文件存储格式为Parquet，一种列式存储引擎，类似于的还有ORC。而文件的传输形式为Snappy。明确的操作者形式如下：①创立Parquet结构的表格（Hive0．13andlater）：CREATETABLECRM．DEMO（AINT）STOREDASPARQUET；②证实表的文件存储格式：descformattedcrm．demo；结果输入如下＃StorageInformationSerDeLibrary：org．apache．hadoop．hive．ql．io．parquet．serde．ParquetHiveSerDeInputFormat：org．apache．hadoop．hive．ql．io．parquet．MapredParquetInputFormatOutputFormat：org．apache．hadoop．hive．ql．io．parquet．MapredParquetOutputFormat③创立Snappy传输格式的Parquet结构的表格（待实地考察）：ALTERTABLEcrm．demoSETTBLPROPERTIES（＇parquet．compression＇＝＇SNAPPY＇）；或，载入时SETparquet．compression＝SNAPPY；返回最初的问题，如果是按Snappy传输的格式，这份用户不道德数据没有办法分析了，因此有两种办法去解决问题：①加装Snappy的可执行文件工具可自行百度，由于没权限，所以这条路权宜之计；②变更数据的传输格式可以最初我中举了一下变更Parquet格式表的传输格式，但是没用！因为我最后是必须将查找数据给定到本地文件系统，如下语句右图：insertoverwritelocaldirectory＇／home／etl／tmp／data＇select＊fromcrm．demo所以，通过这样的形式获得的数据，传输格式仍然是．Snappy。

因此，这里就必须配备Hive继续执行过程中的中间数据和最后数据的传输格式。如MapReduce的shuffle阶段对mapper产生的中间结果数据压缩：hive＞setmapred．map．output．compression．codec；mapred．map．output．compression．codec＝org．apache．hadoop．io．compress．SnappyCodec如对最后分解的Hive表的数据压缩：hive＞setmapred．output．compression．codec；mapred．output．compression．codec＝org．apache．hadoop．io．compress．SnappyCodec这里，我们要设置结果表格数据的传输格式，语句如下：setmapred．output．compression．codec＝org．apache．hadoop．io．compress．GzipCodec；最后的结果就是．gz的传输格式－rw－r－－r－－1etletl342094May1011：13000000＿0．gz最后，我们必要iTunes到电脑本地，必要可执行文件就可以通过Excel分析用户不道德路径数据了。

总结：从Hive应用层的角度来说，关于数据文件的「存储结构」和「传输形式」，这两个点我们不必须关心，只是在给定数据的时候必须融合文件大小，以及数据类型去设置适合的传输格式。不过从Hive底层确保的角度来说，牵涉到到各种各样的「存储结构」和「传输形式」，都必须开发者去研究和调整，这样才能确保集群上的文件在「时间」和「空间」上比较均衡。

本文来源：银河galaxy娱乐游戏-www.painreliefbasics.com