0


【数据库-Hive-01】hive为什么不支持更新和删除,一起找找根源


Hive支持更新和删除吗?这是一道典型的大数据面试题,绝大部分人回答不支持。其实也没错,但是更准确的回答是可以支持,主要是看怎么建表的,如果想要支持Update功能要按以下方式建表:

Hive对使用Update功能的表有特定的语法要求, 语法要求如下:

  • 要执行Update的表中, 建表时必须带有buckets(分桶)属性
  • 要执行Update的表中, 需要指定格式,其余格式目前赞不支持, 如:parquet格式, 目前只支持ORCFileformat和AcidOutputFormat
  • 要执行Update的表中, 建表时必须指定参数(‘transactional’ = true);

经过实验,你会发现Hive的更新机制速度非常的慢,在很小的数据集上更新,也要分钟级别,基本上处于不可用的状态,那么为什么Hive设计成不支持增删改查呢,我们一起聊聊根源。

都是HDFS惹的祸

我们知道,Hive的文件存储是基于HDFS,计算是基于MapReduce。HDFS的设计遵循“一次写入,多次读取”思想,什么意思呢,就是说一旦写完一个文件,这个文件就不能再修改了。我们这时候就不难想象,hive要支持update功能要费多少周折,例如,我们要对100G的表修改一条记录,步骤大致如下:1. 找到该记录对应文件块。2. 读取该块,创建新的文件块写入并顺带修改记录。3.删除原有块。4.修改nameNode信息并将新块复制多份。挺复杂的吧,要知道这是最简单的场景,如果修改的数据量大,导致数据块发生变化就更难了,想想就头大。

因此,Hive不支持update、delete单条记录,所以遇有update、delete的场景,也不要选Hive,反正Hive的应用场景已经够多了。

HDFS为什么不搞成“多次写、多次读”

在回答这个问题时,我们要想如果支持“多次写、多次读”,HDFS要怎么设计,典型的场景就是对一个文件,有多个线程更改,这时候就要考虑事务了,要想HDFS一个文件块就128M,甚至更大,他是放弃了细粒度的管控,换来了海量数据的管理。

ACID多麻烦,对于一个开源项目来说何必呢,没这么大的精力,定位也是海量的低价值密度的不修改的数据,干脆就是不支持修改算了。

湖仓一体登场

伴随着业务的发展,这种需要修改的场景越来越多,权宜之计就是把这些数据放入支持修改的数据库,比如MPP类型的数据仓库,事实上,我们很多项目案例都是这样的架构。但是这样造成了维护成本的升高,数据的冗余,也感觉不太优雅,可不可以一套存储,到这,湖仓一体登场了,等到湖仓一体文章中再聊。

参考文献

Why HDFS is write once and read multiple times?

标签: hive hadoop 数据库

本文转载自: https://blog.csdn.net/zhulangfly/article/details/128904982
版权归原作者 zhulangfly 所有, 如有侵权,请联系我们删除。

“【数据库-Hive-01】hive为什么不支持更新和删除,一起找找根源”的评论:

还没有评论