Details
-
New Feature
-
Status: Closed
-
Critical
-
Resolution: Fixed
-
None
Description
引入 ACID 后不支持加载数据。需要填补 ACID 表和常规配置单元表之间的差距。
- 加载数据对数据执行非常有限的验证，特别是它使用可能不在 00000_0 中的输入文件名，这可能会破坏某些读取逻辑。（当然会酸）。
- 它不检查文件的架构。这对于 Acid 来说可能不是问题，它需要自描述的 ORC，因此 Schema Evolution 可以无缝地处理这个问题。（假设架构没有太大不同）。
- 它会检查 _InputFormat_S 是否兼容。
- 分桶（并因此排序）表不支持加载数据（但仅当 hive.strict.checks.bucketing=true（默认））。将保留对 Acid 的限制。
- 加载数据支持 OVERWRITE 子句
- 文件权限/所有权会发生什么：重命名与复制差异
实施将遵循与中相同的想法HIVE-14988并为 OVERWRITE 子句使用 base_N/ 目录。
minor compaction 如何处理原始文件的 delta/base？
由于 delta_8_8/_meta_data 是在文件移动之前创建的，因此 delta_8_8 在填充之前变得可见。这是一个问题吗？
不是因为 txn 8 没有提交。
实施说明/限制（补丁 25）
- 不支持分桶/排序表
- 输入文件名必须采用 00000_0/00000_0_copy_1 形式 - 强制执行。(
HIVE-18125) - 加载数据创建一个包含新文件的 delta_x_x/
- Load Data w/Overwrite 创建一个包含新文件的 base_x/
- “_metadata_acid”文件放置在目标目录中以指示它需要在读取时进行特殊处理
- 输入文件必须是“普通”ORC 文件，即不包含 acid 元数据列，如果这些文件是从另一个 Acid 表复制的，就会出现这种情况。在后一种情况下，数据中嵌入的 ROW_ID 在目标表中可能没有意义（例如，如果它在不同的集群中）。此类文件也可能混合了已提交和已中止的数据。
- 稍后可以通过向 _metadata_acid 文件添加信息以在读取时忽略现有的 ROW_ID 来放松这一点。
- ROW_ID 在读取时动态附加，并通过压缩永久保存。这与处理在转换为 Acid 之前写入表的文件的方式相同。
- 支持矢量化
Attachments
Attachments
Issue Links
- incorporates
-
HIVE-17232 "No match found" Compactor finds a bucket file thinking it's a directory
-
- Resolved
-
- is related to
-
-
- Closed
-
-
-
- Closed
-
- relates to
-
HIVE-17970 MM LOAD DATA with OVERWRITE doesn't use base_n directory concept
-
- Closed
-
-
-
- Open
-
-
-
- Open
-
-
-
- Closed
-
- links to
