Hadoop数据库支持哪些文件格式

Hadoop数据库支持的文件格式
Hadoop生态（包括Hive、Pig、Sqoop等组件）支持多种文件格式，主要分为面向行、面向列和文本格式三大类，不同格式适用于不同场景（如日志存储、批量查询、数据交换等）。

1. 面向行格式

面向行格式以行为单位存储数据，适合需要整行读取的场景（如实时数据摄入、小批量查询）。

• TextFile（文本文件）：Hadoop默认的文件格式，数据以纯文本形式存储（如CSV、TSV），每行代表一条记录，字段间用分隔符（如逗号、制表符）分隔。优点是通用性强（几乎所有工具都支持）、易于调试；缺点是磁盘占用大（未压缩时）、解析开销高（尤其是XML/JSON等复杂格式），不推荐用于生产环境的大规模数据存储。
• SequenceFile：Hadoop API提供的二进制键值对文件格式，内部使用Writable接口实现序列化。Hive中的SequenceFile通常将key设为空，仅用value存储实际数据，目的是避免Map阶段排序。优点是压缩率高（支持Block-level压缩）、可分割（适合MapReduce并行处理）；缺点是不支持直接跳过无关列。
• MapFile：Sorted SequenceFile的扩展，在SequenceFile基础上生成索引文件（记录key的偏移量），支持按键快速查找。缺点是不可追加数据（写入后无法修改）、读取时需先加载索引，适合需要频繁随机访问的场景。
• Avro：面向数据密集型的二进制文件格式，天生带Schema定义（Schema存储在文件头部），无需开发者实现Writable对象。优点是文件紧凑（压缩率高）、序列化/反序列化性能好、支持多语言（Java、Python、C++等）；缺点是不支持嵌套结构（需扁平化处理），适合数据交换、日志存储等场景。

2. 面向列格式

面向列格式以列为单位存储数据，适合需要读取部分列（如聚合查询、分析型查询）的场景，能有效减少IO开销。

• RCFile（Record Columnar File）：Hive推出的行列混合存储格式，遵循“先按列划分、再垂直划分”的设计（将数据分成多个Row Group，每个Row Group内按列存储）。优点是能跳过无关列（减少IO）、高压缩率（列内数据类型一致，压缩效果更好）；缺点是读取所有列时性能不如SequenceFile（需扫描Row Group头部信息）。
• ORC（Optimized Record Columnar File）：Hive优化的列式存储格式，针对RCFile的不足进行了改进。将数据划分为固定大小的Stripe（默认250MB），每个Stripe包含索引（列的最大/最小值、行位置）、数据（列块）和Footer（元数据）。优点是查询性能高（索引支持快速定位数据）、压缩率高（支持Zlib、Snappy等压缩）、支持ACID事务；缺点是不支持随机写入（仅支持追加），适合大规模分析型查询。
• Parquet：面向列的二进制存储格式，支持嵌套结构（如JSON中的对象、数组），采用“行组（Row Group）+ 列块（Column Chunk）+ 页（Page）”的三层结构（行组是水平划分的单位，列块是列存储的单位，页是最小编码单位）。优点是压缩率高（支持Snappy、Gzip等压缩）、查询性能好（支持列投影和谓词下推）、支持嵌套数据；缺点是对嵌套结构的处理较复杂，适合需要处理复杂数据的应用（如电商订单、日志分析）。

3. 文本格式

文本格式以纯文本形式存储数据，通用性强但性能差，通常用于原始数据存储或数据交换（如日志收集、数据库导入）。

• 常见文本格式：TextFile（默认格式，无Schema）、XML（结构化文本，解析开销大）、JSON（半结构化文本，解析开销比XML小但仍高于二进制格式）。这些格式不适合生产环境的大规模数据存储，建议转换为二进制格式（如ORC、Parquet）以提高性能。

注：Hadoop生态支持任意实现了RecordWriter（写入数据）和RecordReader（读取数据）接口的文件格式，包括数据库格式（如HBase、MySQL导出的文件），但这些格式的序列化/反序列化由客户端完成，Hadoop不直接控制其数据布局。