遇到这种反直觉的情况确实挺困惑的，结合你的表结构（含20万长度、仅0/1/2的整数数组）和分区特征（每个分区1万行），我梳理了几个最可能的原因，附对应的解决思路：

• ORC表未启用合适的压缩配置
  虽然ORC原生支持高压缩比，但不同Hive版本的默认压缩设置可能有差异——如果你的ORC表没有显式配置压缩参数，可能默认用了低压缩甚至未压缩，而Parquet通常默认启用了Snappy或ZLIB压缩，自然体积差距会很大。
  解决方法：创建表或修改分区时显式指定压缩算法，比如：

  -- 新建ORC表时直接指定压缩配置
  CREATE TABLE orc_table (
    field1 STRING,
    field2 INT,
    field3 STRING,
    field4 STRING,
    array_field ARRAY<INT>
  ) PARTITIONED BY (partition_name STRING)
  STORED AS ORC
  TBLPROPERTIES (
    'orc.compress'='ZLIB', -- ZLIB压缩率更高，也可选择Snappy兼顾速度
    'orc.compression.strategy'='COMPRESSION'
  );
  
  -- 针对已存在的分区修改压缩设置
  ALTER TABLE orc_table PARTITION (partition_name='<partition-name>') SET TBLPROPERTIES (
    'orc.compress'='ZLIB'
  );
  

• 数组列的编码策略未适配高重复场景
  你的数组元素只有0、1、2三种值，重复度极高。Parquet会自动对这种低基数列启用字典编码或行程编码（RLE），大幅压缩体积；但ORC的默认编码可能没针对这种场景做优化，导致数组列的存储效率极低。
  解决方法：强制ORC对数组元素使用字典编码，通过表属性配置：

  ALTER TABLE orc_table SET TBLPROPERTIES (
    'orc.column.encoding.array_field'='DICTIONARY',
    'orc.dictionary.key.threshold'='0.5' -- 降低阈值，确保高重复场景触发字典编码
  );
  

• ORC的Stripe大小导致元数据占比过高
  ORC默认的Stripe大小是64MB，而你的每个分区数据量可能远小于这个值。这种情况下，ORC的元数据（比如Stripe索引、文件脚注等）占整个文件的比例会比Parquet高很多，直接推高了整体体积。
  解决方法：针对小分区场景调整Stripe大小，比如设置为16MB：

  ALTER TABLE orc_table SET TBLPROPERTIES (
    'orc.stripe.size'='16777216' -- 单位为字节，对应16MB
  );
  

• ORC表的创建方式导致优化参数未生效
  你是先创建普通表，再通过ALTER PARTITION SET FILEFORMAT ORC指定格式，这种方式可能无法让ORC的默认优化参数（比如压缩、编码规则）完全生效。正确的做法是创建表时直接指定STORED AS ORC，确保所有ORC的原生优化被加载。
  解决方法：重新创建ORC表并指定存储格式，再插入数据，验证体积变化。

内容的提问来源于stack exchange，提问作者jrauhamaa