为什么不能使用 datax 直接读写 hive acid 事务表？
1. 前言
从技术发展趋势的角度来看，ACID事务表提供了多种新特性新功能，是 HIVE社区推荐的HIVE表格式，且在 CDH/CDP/TDH 等大数据平台的主流版本中均已经提供了支持。 在次背景下，目前我司大数据相关产品和项目，已经在部分场景下开始了探索使用 HIVE ACID事务表。 在此跟大家分享一个 HIVE ACID 事务表的相关问题，希望对大家有所帮助。
2. 从一个 HIVE SQL 报错聊起
某线上 HIVE SQL 应用，关联查询多个事务表时报错，报错信息如下:
ERROR : FAILED: Execution Error, return code 3 from org.apache.hadoop.hive.ql.exec.spark.SparkTask. Spark job failed due to task failures: [Error 30022]: Must use HiveInputFormat to read ACID tables (set hive.input.format=org.apache.hadoop.hive.ql.io.HiveInputFormat)INFO : Completed executing command(queryId=hive_20220606152200_54458918-d42c-445e-8e87-96f75eaeb22f); Time taken: 27.143 secondsError: Error while processing statement: FAILED: Execution Error, return code 3 from org.apache.hadoop.hive.ql.exec.spark.SparkTask. Spark job failed due to task failures: [Error 30022]: Must use HiveInputFormat to read ACID tables (set hive.input.format=org.apache.hadoop.hive.ql.io.HiveInputFormat) (state=42000,code=3)
3. “Must use HiveInputFormat to read ACID tables” 报错的底层原因
经排查发现，上述事务表底层的ORC 文件是使用 datax 直接同步过来的，而事务表对表底层在存储系统中的文件目录层次结构，文件名，以及文件格式，都有一套自己的规范，使用datax直接同步文件一般肯定会违反该规范，在后续查询使用时就会出现各种奇怪的问题，所以不能使用 datax 直接同步数据到事务表对应的hdfs目录下。
4. HIVE ACID 事务表的技术细节
为了在 HDFS 文件系统特性的基础上提供事务表的 ACID 语义（HDFS不支持对文件的原地更新，在APPEND追加写入文件时也不支持对该文件并发读取时的数据一致性），HIVE 对 ACID 事务表（或表分区）底层的文件，做了类似 deltalake/hudi/iceberg 一样的精细化管理，对底层文件的目录结构，文件名，和文件格式，都有一套自己的规范。
4.1 首先是文件目录层次结构规范
每个表或表分区对应一个 HDFS 目录；
表或表分区目录底层又包含两类子目录，一类是 base 子目录，一类是 delta 子目录；
表或表分区的大部分数据，都以文件形式存储在 base 子目录下；
每次对表或表分区的增删改操作，都对应一个事务，都会创建一个对应的 delta 子目录，并将这些增量操作产生的数据，以文件形式存储在该 delta 子目录下；
读取表或表分区数据时，会合并 base 子目录和 delta子目录下的所有文件，以呈现完整的数据；
4.2 其次是文件名规范
表底层BASE子目录名称类似 base_0000003_v0011148，其中中间部分对应创建该子目录的事务操作的TransactionId;
表底层DELTA 子目录名称类似（对应 insert/update操作）： delta_00000010000003 v0011147，其中中间两部分对应创建该子目录的事务操作的最小和最大TransactionId;（insert/update操作生成的delta文件的最小和最大TransactionId是一致的，compaction操作生成的 delta文件的最小和最大TransactionId分别对应 compaction的一系列 delta文件的最小和最大TransactionId）；
表底层DELTA 子目录名称类似（对应 delete操作）：delete_delta_00000010000003 v0011147，其中中间两部分对应创建该子目录的事务操作的最小和最大TransactionId;（delete操作生成的delete_delta文件的最小和最大TransactionId是一致的，compaction操作生成的 delta文件的最小和最大TransactionId分别对应 compaction的一系列 delete_delta文件的最小和最大TransactionId）；
子目录底层的文件名，类似bucket_00000或bucket_00000_0;(不管表是否分桶，文件名都是该格式；hive2.x和hive3.x新旧版本文件名格式略有不同)
4.3 最后是文件格式规范
ACID事务表底层的文件，都是以 orc 格式存储的；
ORC 文件包含的字段，除了ACID事务表中正常的业务字段，还包含5个元数据字段：operation:int,originalTransaction:bigint,bucket:int,rowId:bigint,currentTransaction:bigint
5 总结
正是因为 HIVE 对 ACID 事务表（或表分区）底层文件的目录结构，文件名，和文件格式的上述规范，所以我们不能直接读写操作 ACID 事务表底层的文件,正如我们不能绕过 MYSQL/ORACLE服务，直接读写 MYSQL/ORACLE表在底层本地文件系统中的文件一样。
所以周边生态工具，如 spark, datax 等，都不能像以往操作普通 ORC表一样，直接读取 HIVE ACID事务表了。
目前spark 访问 acid 事务表，社区推荐的方案是通过 hwc (hive warehouse connector) 这一插件来实现对 hive acid表的读写操作，而 datax 目前还没有成熟的方案。
原文：https://juejin.cn/post/7106403708199501831