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类型的数据仓库，事实上，我们很多项目案例都是这样的架构。但是这样造成了维护成本的升高，数据的冗余，也感觉不太优雅，可不可以一套存储，到这，湖仓一体登场了，等到湖仓一体文章中再聊。
参考文献