Hive的存储类型主要取决于底层文件格式（如ORC、Parquet）和压缩算法的选择，其中ORC和Parquet因支持列式存储和高效压缩，是当前大数据场景下的绝对主流，能显著提升查询性能并降低存储成本。
在大数据生态系统中,数据如何被“装进”Hive表里，直接决定了你跑SQL时的速度与钱包的厚度，很多刚入行的数据工程师容易陷入一个误区，认为只要数据能存进去就行，结果到了分析阶段，查询慢得像蜗牛，存储费用还高得离谱，选择合适的存储类型，就像给仓库选货架，选对了，取货快、占地小；选错了，不仅找数据费劲，还浪费大量空间，业内专家指出，随着数据量的爆炸式增长，传统的行式存储已难以满足实时分析的需求，列式存储凭借其独特的架构优势，成为了Hive优化中的必选项。
![26 [大数据] hive 4种文件存储格式](https://i1.hdslb.com/bfs/archive/9fa31f9196cb1edab8804923f3e091f02a1b5a8a.jpg)
行式存储与列式存储的本质区别
要理解为什么ORC和Parquet是主流,首先得搞清楚它们和传统格式（如TextFile）的根本差异，这不仅仅是文件格式的不同，更是数据存储逻辑的革命。
行式存储：适合写入，不适合查询
行式存储（Row-based Storage）是传统关系型数据库（如MySQL、Oracle）的标准做法，它把一行数据的所有字段连续存储在一起，想象一下，你有一张员工表，每一行包含姓名、年龄、工资、部门，在行式存储中，这三个字段是紧挨着存放的。
这种结构的优点是写入速度快,因为数据可以连续追加，非常适合事务处理（OLTP）场景，当你需要插入一条新记录时，数据库只需在末尾追加即可，效率极高，在大数据分析（OLAP）场景下，这种结构就显得力不从心，假设你只需要统计全公司的“平均工资”，如果使用行式存储，Hive必须读取每一行的所有字段（姓名、年龄、部门等），哪怕你根本不需要这些信息，这种“全表扫描”不仅浪费I/O资源，还极大地拖慢了查询速度。
列式存储：为分析而生
列式存储（Column-based Storage）则将同一列的数据连续存储在一起，还是那张员工表，在列式存储中，所有“姓名”字段存在一起，所有“年龄”字段存在一起，所有“工资”字段存在一起。
这种结构对分析型查询有着天然的优势,当你只查询“平均工资”时，Hive只需要读取“工资”这一列的数据，完全忽略其他无关列，这不仅大幅减少了I/O操作，还因为同一列的数据类型相同，更容易进行高效的压缩，据统计，列式存储通常能将查询性能提升数倍至数十倍，同时显著降低存储开销。
主流列式文件格式深度解析
在Hive中,常见的列式文件格式主要有ORC和Parquet两种，它们各有千秋，选择哪种往往取决于你的具体业务场景和技术栈。
ORC：Hive的原生最优解
ORC（Optimized Row Columnar）是Hive团队专门为Hive设计的存储格式，它结合了行式和列式的优点，旨在提供高效的存储和快速的查询速度。
ORC的核心优势在于其复杂的索引机制,它在文件内部建立了多种索引，包括行组索引、列索引和块索引，当你执行查询时，Hive可以利用这些索引快速定位到需要的数据块，跳过大量无关数据，ORC支持多种压缩算法，如ZLIB、Snappy和LZO，能够在压缩率和解压速度之间取得良好的平衡。
对于主要使用Hive进行数据仓库构建的团队来说,ORC往往是默认的首选，它在Hive生态中的兼容性最好，支持复杂的嵌套数据结构，如Map、List和Struct，且在进行谓词下推（Predicate Pushdown）时表现优异。
Parquet：跨生态的通用标准
Parquet是由Apache Avro和Apache Thrift团队联合开发的列式存储格式，它的最大特点是“跨生态”，不仅Hive支持，Spark、Presto、Impala、HBase等大数据组件都能完美读取Parquet文件。
Parquet采用了动态压缩策略,根据数据类型选择最合适的编码方式，对于字符串类型，它可以使用字典编码；对于数值类型，它可以使用RLE（游程编码）或Delta编码，这种细粒度的压缩使得Parquet在存储效率上往往优于ORC，尤其是在处理大量重复值或低基数列时。
如果你的团队不仅使用Hive,还广泛使用Spark进行ETL处理，或者需要与其他BI工具对接，那么Parquet可能是更灵活的选择，它在处理大规模数据时的稳定性也备受认可，是许多数据湖架构中的标准格式。
压缩算法的选择策略
无论选择ORC还是Parquet,压缩算法都是影响性能的关键因素，常见的压缩算法包括Snappy、GZIP、LZO和ZLIB。
Snappy：速度与空间的平衡
Snappy是Google开发的一种压缩算法,主打高速压缩和解压，它的压缩率不如GZIP，但解压速度极快，且支持切片（Slicing），这意味着MapReduce或Spark任务可以并行读取压缩文件的不同部分，而无需解压整个文件。
在大多数Hive查询场景中,Snappy是首选，它能在保持较高压缩率的同时，最大限度地减少CPU开销，提升查询响应时间，对于实时性要求较高的数据仓库，Snappy几乎是标配。
GZIP与ZLIB：极致压缩，牺牲速度
GZIP和ZLIB提供更高的压缩率,能显著减少存储空间，但它们的缺点是压缩和解压速度慢，且不支持切片，这意味着在读取数据时，必须串行解压，严重拖慢查询速度。
除非你的存储成本极高,且查询频率很低，否则不建议在Hive中使用GZIP，对于需要长期归档的历史数据，可以考虑使用GZIP以节省空间。
LZO：兼容性与性能的折中
LZO是一种古老的压缩算法,虽然压缩率一般，但解压速度非常快，且支持切片，由于LZO需要额外的索引文件（.lzo_index），管理起来较为复杂，且在现代硬件上，其优势已不如Snappy明显，除非你有遗留系统依赖LZO，否则新项目建议优先选择Snappy。
实操建议：如何优化Hive存储
在实际工作中,选择合适的存储类型只是第一步，正确的配置和使用习惯同样重要。
创建表时的格式选择
在创建Hive表时,务必明确指定存储格式和压缩算法，创建一个使用ORC格式和Snappy压缩的表：
CREATE TABLE employee_orc_snappy (
id INT,
name STRING,
age INT,
salary DOUBLE
)
STORED AS ORC
TBLPROPERTIES ("orc.compress"="SNAPPY");
数据导入与转换
如果已有TextFile格式的数据,可以通过INSERT OVERWRITE命令将其转换为ORC或Parquet格式，这个过程虽然会消耗一定的计算资源，但能显著提升后续查询的性能。
INSERT OVERWRITE TABLE employee_orc_snappy SELECT FROM employee_text;
分区与分桶的配合
存储格式的优化需要与分区（Partition）和分桶（Bucket）结合使用，对于经常按日期查询的数据，建议按天或按月分区；对于需要JOIN操作的大表，建议进行分桶，以减少Shuffle开销。
常见疑问解答
hive存储类型选择orc还是parquet
如果团队主要使用Hive,且数据仓库构建较为复杂，ORC是更稳妥的选择，因为它与Hive的优化器结合更紧密，如果团队使用多种计算引擎（如Spark、Presto），或者需要与其他系统共享数据，Parquet的兼容性更好，两者在性能上差异不大，主要取决于生态兼容性。
hive存储类型压缩算法怎么选
默认情况下,Snappy是最佳选择，因为它支持切片，解压速度快，适合大多数查询场景，如果存储成本是主要瓶颈，且查询频率低，可以考虑GZIP，避免使用未压缩的格式，除非数据量极小。
hive存储类型对查询性能影响多大
从行式存储切换到列式存储,查询性能通常能提升3-10倍，具体取决于查询的列选择率，如果查询只涉及少数几列，列式存储的优势将更加明显，合理的压缩算法能进一步减少I/O，提升整体效率。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/461801.html
