由一个数据增量处理问题看到技术人员的意识差距

这是我们一位技术人员在做商业智能BI项目的时候问到的一个的问题，我们在内部也做了下复盘，觉得有些价值和启发，跟大家也分享一下。

数据增量处理问题

比如像历史订单数据量比较大，所以按道理应该每天做增量抽取，按时间日期戳抽取最新一天的数据。但问题就在于这个订单信息业务部门昨天提交了，数据也被加载到数据仓库了，但这个订单隔了几天之后业务部门可能重新修改了，这样就造成已经进入到商业智能BI数据仓库的历史订单数据就不准确了。

那我就问，你在这个商业智能BI项目上是如何处理的。技术人员回答说我们是全删全查，每天ETL抽取的时候将数据仓库的数据先删除掉，然后再重新查询进来。但是历史订单数据量很大，可能还存了好几年的，每次全删全查，这种效率就很低。

数据可视化 - 派可数据商业智能BI可视化分析平台

那我就问，为什么不换种方式呢？比如在这个商业智能BI项目数据仓库中删除最近30天的历史订单数据，每次重新加载最近30天的订单数据进来不就可以解决问题了吗？这也是一种增量处理方式。增量并不是每次就处理一天的数据，30天也算是增量处理。

技术人员就说不行，因为业务部门说了订单的数据不保证什么时候会修改，有可能是30天，有可能更长。所以，没有办法，只能做全量数据删除和加载处理。所以就按照这种方式一直处理到现在，效率就很慢，从ODS层开始到DW到DM层层都要重新算，周期就拉得很长。

当然这位技术人员在这个商业智能BI项目里面也尝试其他的方式比如做分区、做索引优化去改善等等，事情就到这里就结束了。

数据增量问题处理方案

感觉整个过程有没有问题？从技术角度来讲没有问题，商业智能BI项目里通常情况下都是这么做的。

但实际上呢？还是有问题的，技术人员思考的方向需要再打开一些。凭什么业务人员说订单任何时候都会修改，三个月以前的会修改吗？一年前的会修改吗？很显然，这些业务场景的真实性是存在问题的。

数据可视化 - 派可数据商业智能BI可视化分析平台

一个销售订单下来了，审核没有问题就到工厂那边去了，工厂排计划排产东西都生产出来了，最后发到客户那边，整个订单的流程就执行完成了，这个周期算下来30天、45天还是90天，这个很容易去验证，怎么会出现一年前的订单数据再去修改的问题呢？这个概率有多大，显然很小。所以这种场景从业务的角度是不存在的，至于为什么会那么长时间还会修改订单信息，这个就只有业务人员自己知道了。

所以，最后带着这种疑问去跟业务部门的领导一碰，根本就不存在这个问题，偶尔会有订单信息在近几天内调整修改，再长也不会超过30天。下单的时候审核一次，到生产那边再审核一次，没有问题就执行了。特殊情况因为各种各样的原因订单没有执行，也是以一种状态来结束的，这些订单数据在收入统计的时候会被剔除掉的。

数据增量问题处理思路

那我讲这件事情的目的在哪里？就是虽然我们在商业智能BI项目里从事的是技术，但是也要有业务的敏感度。像上面提到的技术人员，技术没有问题想的方式挺全考虑听周到的，但是对业务不太敏感。就造成了一个原本相对简单的处理方式，最后弄得非常得复杂，并且还没有很好的方式去优化。

我们做信息化的目的不仅仅是为了把业务流程捋顺、效率提升，很多时候也是要推动业务管理的进步和改善的。假设刚才提到的场景就真实存在，一年前的订单信息还会被修改，那这种情况是不是业务管理上的一个漏洞，经不经得起解释，这种业务管理流程是否合理。

数据可视化 - 派可数据商业智能BI可视化分析平台

在这个例子中就能看出来我们一些技术人员会存在的一个问题，就是技术思维领先，缺乏一种业务视角，也缺乏一种意识去质疑一些事情。比如有没有这种意识先去质疑这种一眼看上去就不合理的业务要求，去弄明白为什么会出现这种违背常理的处理方式，去跟业务较下劲，至于结果怎么样不说，个人有没有这种意识去突破，去做出这种动作，这一点很重要。

别人想到的你能想到，别人没有想到的你也能想到，想到了并且还能去主动验证下并提出更优的解决方式，这就是普通技术人员跟优秀技术人员的差距。