转自：https://zhuanlan.zhihu.com/p/348698298

前言

在进行大数据开发过程中，避免不了遇到数据错位的情况。出现数据错位的情况通常处于大数据开发的上游环节，为了保证数据质量需要对Hive表数据进行修复处理，本文由一次真实的Hive数据错位修复经历所启发，在这个基础上总结和扩展数据错位发生场景、数据错位修复思路和修复案例演示demo。

01 发生数据错位的场景

首先需要清楚以下2个概念：

上游数据来源表为不同渠道的数据，如关系型数据库MySQL的数据、网站或应用的埋点数据日志和第三方提供的数据等

下游Hive表在这边主要指的是ODS层的表，即从各个渠道来的数据所抽取到Hive的表

在将原始数据导入到Hive表的时候可能会发生数据错位，发生错位的场景有以下3种（请首先排除第3种情况）：

（1）数据来源表的结构发生变化

因为不可避免的原因如业务调整或别的不可控因素，上游数据来源表的结构发生了变化，这种表结构的变化包含了数据来源表字段的增加、删除、修改这3种变化，复杂度依次增加，这些情况都会导致数据错位。

（2）数据的分隔符发生变化

还有因为分隔符导致的数据错位， 第1种情况是切换数据来源之后数据的分隔符和以前的不一致， 第2种情况是某些字段中包含了分隔符，这2种情况都会导致数据错位。

（3）insert 语句select 后面列顺序与建表时顺序不一致

insert overwrite table my.test_table partition(pt=1) select 2 as col2, 1 as col1 from my.online_table;

按常规逻辑来说，查询的时候应该是col1字段都为1，col2字段都为2。但是事实上执行

select col1, col2 from my.test_table;

结果是

2    1
2    1
2    1
2    1
....

事实上，hive并不关心你执行insert语句所用的别名，别名代表的字段可以不存在，甚至别名都可以相同。它只关心顺序。这一点很容易忽略：请严格保证insert语句中的字段和建表语句中的字段的顺序一致！！！

02 数据修复的思路

我们在上一节已经描述了问题产生的场景，接下来是确定解决问题的思路：

（1）数据来源表结构发生变化情况下的修复思路

在数据来源表结构发生变化的场景中，不管是增删改中的哪一种情况，核心解决思路是通过建立临时表对最新数据进行处理再回填到Hive表完成修复。

• 数据来源表字段增加，如果Hive表的下游加工需要用到新增的字段，则根据新增字段的位置重新建表，并将历史数据回填到新表，一般情况下新增字段的表结构为在旧表的后面追加新增字段，如果新增字段不在旧表的后面则按照来源表结构新建；如果下游加工用不到新增字段，则建立Hive临时中间表，表结构与数据来源表一致，把需要的数据从Hive临时中间表回填到Hive表

• 数据来源表字段删除，如果Hive表的下游加工需要用到删除的字段，则需要提前通知下游评估影响并反馈解决方案；如果下游未使用删除的字段，则新建Hive临时中间表并将数据回填到Hive表中，Hive表结构不变，被删除字段做置空处理

• 数据来源表字段修改（字段名称或类型发生变化、数据错位且字段不一致），数据来源表的字段名称或类型发生变化，如果Hive表的下游加工需要用到修改的字段，则需要提前通知下游评估影响并反馈解决方案；数据来源表的字段发生数据错位且字段不一致这种情况比较复杂，需要先将旧数据与新数据的字段名和几条数据放到同一张Excel表进行比对，再参考完整数据按照旧表字段名来确定新表字段名，尽量保证2种表共有字段的字段名一致，如果旧表中的字段没有完全体现在新表中，则需要提前通知下游评估影响并反馈解决方案，如果没有使用的话在将Hive临时中间表回填到Hive表的时候将没用到的字段做置空处理

（2）数据分割符发生变化情况下的修复思路

切换数据来源之后数据的分隔符前后不一致的情况，在允许的情况下可以先对分隔符进行转换，然后上传数据，和上游沟通格式要求。

某些字段中包含了分隔符，CSV格式文件的部分字段中出现了’,’ ，这种情况是比较复杂且不合理的，如果还是用英文的逗号的话必然会导致数据错位，这个需要和上游数据提供方共同约定将分隔符改为其他不常用的字符如 ‘\t’ 或其他不会出现在字段内容中的特殊符号

总 结 在进行大数据开发过程中，难免会遇到Hive数据错位问题，出现问题的原因包含了数据调研不充分和上下游沟通不到位，问题发生之后先让自己静下来整理思路，然后再进行修复，最终的目标是为了保证数据质量而不影响下游的加工。