关于hive:线上数据问题排查案例分享因为-HMS-和底层-orc-文件中某字段的数据精度不一致造成的数据丢失问题

12次阅读

共计 3280 个字符，预计需要花费 9 分钟才能阅读完成。

大家好，我是明哥，本篇文章跟大家分享一次线上数据问题的排查案例，并总结下背地的技术背景和最佳实际，心愿对大家有所帮忙。

先说下通过本案例总结的避坑指南和最佳实际。

hive 的元数据服务 hms 和表底层的 orc 文件中都存储了表的元数据信息，两者人造是割裂的，当两者信息不统一时，容易呈现各种奇怪的数据问题；
为防止潜在的数据问题，开发人员须要确保 hms 和 orc 文件中元数据信息的统一，为此应尽量避免更改 hive orc 表字段的数据类型（尤其须要防止对已存储了数据的 orc 表字段做数据类型不兼容的批改）;
为防止潜在的数据问题，应用同步工具如 datax 等间接同步数据到 orc 文件时，orc 文件也应该尽量应用对应表在 HMS 中定义的数据类型和数据精度来进行数据同步；
为防止潜在的数据问题，应用 SQL 语句进行数据查问操作时，在数据类型不统一时，应尽量应用 CAST 进行显示转换而不依赖 HIVE SQL 的隐式转换机制；

某客户现场局部 HIVE ORC 表在各层的数据条数不统一，存在数据失落问题。

比方对于 hive orc 表 hs_sr.sr_xxx/hs_ods.ods_xxx/hs_tmp.tmp_pxxx，应用 count(1) 查问，发现 hs_sr 和 hs_ods 记录条数统一，但 hs_tmp 层则短少了 400 条左右数据。

进一步查问发现，指定条件如 prod_code 查问某条数据时，在 hs_sr 层能够查到该条数据但在 hs_tmp 层查不到该条数据，而在 hs_ods 层查问该条数据时，只有查问字段列表中蕴含 prod_scale 字段就会查不到该条数据，而查问字段列表不蕴含 prod_scale 字段就能够查问到该条数据。

备注：
*本案例中，数据链路为应用 datax 从上游交易系统 oracle 采集到 hive 中的 hs_sr 层，而后应用 hive sql 对 hs_sr 层进行加工解决后写入到 hs_ods 层，再通过 hive sql 进一步加工解决后写到 hs_tmp 层。

简略来讲，问题起因是 prod_scale 字段在 hive 表中的数据类型和数据精度跟 hive 表底层 orc 文件中的数据类型和数据精度不统一，当 orc 文件中局部记录 prod_scale 字段理论存储的值大于 hive 中定义的该字段的精度时，hive 查问该字段并写入到上游 ORC 表时会隐式转换为 NULL 值，而局部版本的 HIVE 在将 NULL 值写入 ORC 文件时有 BUG，会造成底层 ORC 文件中局部记录该字段不可读，所以后续 hive 再次在有问题的 ORC 文件中查问问题字段并插入最上游的 ORC 表时，上游表中就缺失了局部记录。。

解决方案依照思路不同分为两种，一种是业务侧的调整，一种是平台侧 / 工具侧的调整。

业务侧调整，能够调整 hive 中相干表相干字段在 DDL 定义中的数据类型和数据精度，使之与上游交易系统 ORALCE 中相干字段的数据类型和数据精度统一，比方这里发现的 prod_scale 字段应从 decimal(15,4) 调整为 decimal(18,4)；（查问上游交易系统 oracle 中的数据，发现的确有局部记录的 prod_scale 字段值比 decimal(15,4)精度更大，且业务确认这部分数据是失常数据，故应该调整 HIVE 中字段的数据类型和数据精度与上游统一）；

本案例中应用了 datax 从上游 oralce 同步数据到 hive orc 表，故能够对 datax 同步作业进行调整：datax 同步数据时，数据类型和数据精度应该以指标 HIVE 表中定义的数据类型和数据精度为准，对于 decimal 字段也应该以指标 hive 表中的定义为准，而不是全副应用默认的最大精度 decimal(38,18)，从而防止 orc 文件和 hms 中相干元数据信息的不统一，缩小后续数据类型隐式转换等操作带来的潜在问题。（datax 同步作业调整后，在数据同步过程中，如果遇到上游 ORACLE 数据精度大于 HIVE 指标表的数据精度，同步作业会报错退出，从而能第一工夫裸露数据问题确保数据品质，而不会将数据品质问题带到上游）。

备注：
** 因为开源的 datax 并不反对 hive 的 decimal 数据类型，而
金融行业对数据准确性广泛要求较高，故我司外部对 datax 做了加强，反对 hive 的 decimal 数据类型。**

本案例中数据链路如下：应用 datax 从上游交易系统 oracle 采集到 hive 中的 hs_sr 层，而后应用 hive sql 对 hs_sr 层进行加工解决后写入到 hs_ods 层，再通过 hive sql 进一步加工解决后写到 hs_tmp 层;
本案例中，hive 中 hs_sr/hs-ods/hs_tmp 层相干表中关键字段 prod_scale 都被定义为了 decimal(15,4), 而上游 ORACLE 中该字段类型为 decimal(18,4);
orc 文件：采集上游 oracle 表数据并写入 hive orc 表时，对于 decimal 类型的字段，以后 datax 作业应用的都是 hive 默认的最大精度即 decimal(38,18)，所以所有记录所有字段无论精度大小都能被同步到 ORC 文件中；
hs_sr 层表：但 HIVE 的 hs_sr 层表中该字段被定义为了更小精度 decimal(15,4)，跟底层 orc 文件中的 decimal(38,18) 并不统一，所以 hive 查问该字段时就会隐式转换为指标类型 decimal(15,4)，此时更大精度的值会被转换为 NULL 值进行解决，所以 hs_sr 层的表查问时不会短少记录，但大精度的字段值会被显示为 NULL;
hs_ods 层表：在查问 hs_sr 层表数据再写入 hs_ods 层表时，因为上述隐式转换的起因，局部大精度字段值会被转换为 NULL 值进行解决，而局部版本的 HIVE 在将 NULL 值写入 ORC 文件时有 BUG，会造成底层 ORC 文件中局部记录该字段不可读，具体哪些记录该字段受到影响跟底层 orc 文件中对应的 stripe 中存储了哪些记录的该字段无关，所以 hs_ods 层表只有查问字段列表中蕴含 prod_scale 字段就会查不到该条数据，而查问字段列表不蕴含 prod_scale 字段就能够查问到该条数据，同时应用 count(1) 也会发现数据条数没有缺失;
hs_tmp 层表：后续查问 hs_ods 层表数据并写入 hs_tmp 层表时，因为 hs_ods 层表底层的 orc 文件中局部 stripe 有问题，所以当查问字段列表蕴含 prod_scale 字段时，对应 stripe 中的记录都会受到影响查问不到，最终插入 hs_tmp 层的数据也就缺失了这部分记录，应用 count(1) 也会发现数据条数有缺失，即最终呈现了数据失落问题;

ORC 文件是自描述格局，orc 和 hms 中都存储了表的元数据信息，所以二者人造是割裂的;
当 hive 查问 ORC 表数据时，如果 orc 文件和 hms 中字段类型元数据信息不统一就会波及到隐式转换；
HIVE 并不是 ANSI dialect compliant 的，即 HIVE 并不合乎 ANSI SQL 规范，在解决有效数据时会返回 NULL 值而作业不会报错；
hive 中 decimal 类型的默认精度也即最大精度是 decimal(38,18), 当 decimal 类型的字段值在转换为更小精度比方 decimal(15,4) 时，较大精度的值会被转换为 NULL 值（隐式和显示转换都是如此）；
局部老版本的 hive 写 ORC 文件时在解决隐式转换的 NULL 值时有 BUG，会造成底层写入的 ORC 文件中的局部记录该字段不可读，但作业不会报错，具体哪些记录受到影响跟底层 orc 文件中对应 stripe 存储了哪些记录该字段无关；
能够应用工具如 hive –orcfiledump xx 来验证表底层 orc 文件的完整性；
相干 JIRA

[https://issues.apache.org/jir…
](https://issues.apache.org/jir…)

正文完