orc对hive复杂结构支持问题

L13763338360

于 2023-02-20 11:57:47 发布

阅读量565

点赞数

分类专栏： hive 文章标签：大数据

本文链接：https://blog.youkuaiyun.com/L13763338360/article/details/129121341

版权

hive 专栏收录该内容

2 篇文章

订阅专栏

文章讨论了ORC格式在处理复杂嵌套结构时的不足，相比之下，Parquet由于其设计动机——存储嵌套数据并提供高效压缩和编码，对于此类数据表现更好。在一项测试中，将数据从ORC转换为Parquet后，相同操作的时间从4.8小时减少到1.8小时。因此，对于包含复杂嵌套类型的Hive表，推荐使用Parquet而不是ORC。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

orc格式

在实际实用中，发现orc对复杂嵌套结构支持不友好。

CREATE TABLE `xxx` (
  `user_id` BIGINT COMMENT '客户唯一id，从user_list中获取',
  `device_id` STRING COMMENT '设备id',
  `version_num` INT COMMENT 'Version版本号,格式为：Version number ，首字母大写，number根据创建时间自增+1',
  `task_id` BIGINT COMMENT 'task唯一值，系统自动生存，可区分是一个version的第几个task',
  `msg_create_time` BIGINT COMMENT '数据产生时间',
  `msg_insert_time` BIGINT COMMENT 'Flink写入Hive时间',
  `error_type` BIGINT COMMENT '异常类型',
  `error_msg` STRING COMMENT '异常详情',
  `elements` ARRAY<STRUCT<`element_id`: BIGINT, `identifier`: STRING, `entry_time`: BIGINT, `finish_time`: BIGINT, `sequence_number`: BIGINT, `label_groups`: STRING, `is_target`: STRING, `element_type`: INT, `element_name`: STRING, `trigger_time`: BIGINT, `trigger_status`: INT, `parameters`: STRING, `execute_res`: STRING, `trace_info`: STRING, `error_message`: STRING, `recipient_id`: STRING, `touchpoint_key`: STRING, `trigger_detail`: STRING, `error_reason`: STRING, `variate`: STRING, `signature`: STRING, `path_id`: INT, `extend_json`: STRING, `extend_info`: STRING>>,
   ...
  `region` STRING,
  `dt` STRING)
stored as orc
PARTITIONED BY (region, dt)
;

500亿左右的数据、1TB左右的存储，用insert overwrite table xxx1 select * from xxx2的方式，400个vcores，大概花了4.8h。

怀疑是用了表字段复杂的嵌套类型，orc支持不友好。参考：https://developer.aliyun.com/article/226990

parquet格式

尝试改用parquet存储格式

CREATE TABLE `xxx` (
  `user_id` BIGINT COMMENT '客户唯一id，从user_list中获取',
  `device_id` STRING COMMENT '设备id',
  `version_num` INT COMMENT 'Version版本号,格式为：Version number ，首字母大写，number根据创建时间自增+1',
  `task_id` BIGINT COMMENT 'task唯一值，系统自动生存，可区分是一个version的第几个task',
  `msg_create_time` BIGINT COMMENT '数据产生时间',
  `msg_insert_time` BIGINT COMMENT 'Flink写入Hive时间',
  `error_type` BIGINT COMMENT '异常类型',
  `error_msg` STRING COMMENT '异常详情',
  `elements` ARRAY<STRUCT<`element_id`: BIGINT, `identifier`: STRING, `entry_time`: BIGINT, `finish_time`: BIGINT, `sequence_number`: BIGINT, `label_groups`: STRING, `is_target`: STRING, `element_type`: INT, `element_name`: STRING, `trigger_time`: BIGINT, `trigger_status`: INT, `parameters`: STRING, `execute_res`: STRING, `trace_info`: STRING, `error_message`: STRING, `recipient_id`: STRING, `touchpoint_key`: STRING, `trigger_detail`: STRING, `error_reason`: STRING, `variate`: STRING, `signature`: STRING, `path_id`: INT, `extend_json`: STRING, `extend_info`: STRING>>,
   ...
  `region` STRING,
  `dt` STRING)
stored as parquet
PARTITIONED BY (region, dt)
;

同样用insert overwrite table xxx1 select * from xxx2的方式，400个vcores，大概花了1.8h。

总结

Apache Parquet 最初的设计动机是存储嵌套式数据，比如 protobuf、thrift、json等，将这类数据存储成列式格式以方便对其高效压缩和编码，且使用更少的IO操作取出需要的数据，也是paruqet 相比于orc的优势，它能透明的将 protobuf 和 thrift 被广泛的使用的今天，于 parquet 进行集成,是一件非常容易和自然地事情。除了上述优势外，相比于 orc，parquet 没有太多其他可圈可点的地方，比如不支持update操作(数据写成后不可修改)、不支持ACID等。

总结结论，如果hive表字段采用了复杂嵌套类型，建议用 parquet ，不建议用 orc 。