记得上学的时候就看过说做数据的普遍时间分布是这样的80%为前期数据清理，20%为最后的分析计算。前不久做了一个4数据源药品数据归一合并的工作让我充分体会到了这其中的艰辛。
客户买了四个不同机构统计的各药品市场销售数据，侧重点不同有的可能是从医院角度有的呢是从零售角度。他们想把这四个不同来源中的其实是同一个厂家生产的同一个规格的药品都统一成一个，这样以后就可以在不同的维度看同一个药品的表现，当然是大利好了。但是理想很丰富现实却很骨感，这个工作就落在了我的头上。没看数据之前按照逻辑推测这个工作应该不难，结果看到数据后惊了个呆。各个数据源都是手工报表数据，而且都没有主键，表的属性也不一样。有的用中文，有的用英文还有的用拼音。关于一个药的定义又分为药品名称、药品品牌、药品化学式。药品的规格又分为片剂、针剂，干粉等等。而且不同的数据源之前对于同一个药品的描述方式有可能是完全不同的，因为他们不是同一批人做的。我见到一个奇葩的例子就是同一个药，一个来源写它的剂型是小瓶装，另一个的记录是干粉。好嘛，这样一看应该是2个药了对吧，可是仔细百度一下再结合结合生活经验，你可能才会发现，其实这个药是装在小瓶子里的干粉，类似于小时候打的青霉素那种，所以其实应该把它们合并为一种药……
大量这种医药专业化信息让我们痛不欲生，所以匹配工作根本无法靠代码来完成。只能人工去筛选，上百万的数据这要耗到什么时候啊。而且让人伤心的是感觉甲方很不配合，基本上就当个甩手掌柜，自已原本的人工梳理流程一点也不说，专业相关知识也一点不指导。我们本想的是原本这个工作是他们内部人工做的，那么可以参考你们的历史工作流程和数据这样会节省很多时间。当时对方就好像举个例子哈，让你造一个原子弹，和你说你看原料给你了铀和环，然后原理你懂的吧，在一个极限高温高压下产生链式反应就会爆炸了，一个月后我们看你们的demo。没了！作为一个程序员我此时表示鸭梨山大啊。不过抱怨归抱怨工作还是要做，我们只能从源头出手自己想办法这出其中的规律，看看有没有隐含信息便于关联的。最后还真的发现了一个数据中的字段叫做ATC编码，这个编码是医药领域统一的规范，大概就是描述一个药品的有效成本的化学分子式是什么，它治疗的是哪个领域的疾病。因为一开始的没有人告诉我们这个字段的意义，作为程序员看到一串字母乱码又不规范很容易就忽略掉了，没有想到这个编码在不同源之间是有着统一性的。然后再从甲方的最终需求去思考，他们把所有产品统一起来的目的是什么？很难相信几千个产品每个产品都会去看它的细节信息，一个十八流小药厂生产的双黄连也想知道它究竟市场占有率多少？一般看起来也会是按照某个类别比如ATC编码去汇总了看，所以其实我们最终并不一定要把每个药归一，只要保证甲方希望看到的分类在结果中是归一的那么就可以满足他们的实际需求了。最后把我们的想法和甲方沟通了一下，完美匹配！
所以对于做数据处理这次有了三点感悟：第一，元数据的每一个字段都需要参透，遇事不决回到源头往往可以找到答案；第二，客户有时候也不一定能准确描述自己的需求，他要的可能是A说的却是B，如果你再理解的是C那就全完了。需求还是要带领着客户慢慢梳理出来才是最精确的；第三，学无止境，跨界知识现在真的是越来越重要。我之所以能发现ATC这个字段的重要性还要感谢很早以前因为好奇学过的一门法医学慕课，那里面就提到了过了个东东。当时学了也就学了很多也许都忘了，没想到时隔多年之后居然在这里又救了我一次，真是无心插柳啊。
