所以，你会看到，洗数据的大量的工作就是在把杂乱无章的数据归并聚合，这就是在建立数据标准。这里面绝对少不了人肉的工作。无非就是：
聪明的人在数据产生之前就定义好标准，并在数据产生之时就在干数据清洗的工作。
一般的人是在数据产生并大量堆积之后，才来干这个事。
另外，说一下Amazon的ASIN，这个事从十多年前就开始了，我在Amazon的内网里看到的资料并没有说为什么搞了个这样一个ID，我倒觉得这并不是因为Amazon因为玩数据发现必需建议个商品ID，也许因为Amazon的业务模型就是设计成以“商品为中心”的。今天，这个ASIN依然有很多很多的问题，ASIN一样不能完全保证商品就是一样的，ASIN不一样也不代表商品不一样，不过90%以上的商品是保证的。Amazon有专门的团队Category Team，里面有很多业务人员天天都在拼命地在对ASIN的数据进行更正。
案例二：数据的准确
用户地址是我从事过数据分析的另一个事情。我还记得当时看到那数以亿计的用户地址的数据的那种兴奋。但是随后我就兴奋不起来了。因为地址是用户自己填写的，这里面有很多的坑，都不是很容易做的。
第一个是假/错地址，因为有的商家作弊或是用户做测试。所以地址是错的，
比如，直接就输入“该地址不存在”，“13243234asdfasdi”之类的。这类的地址是可以被我的程序识别出来的。
还有很难被我的程序所识别出来的。比如：“宇宙路地球小区”之类的。但这类地址可以被人识别出来。
还有连人都识别不出来的，比如：“北京市东四环中路23号南航大厦5楼540室”，这个地址根本不存在。
第二个是真地址，但是因为用户写的不标准，所以很难处理，比如：
- 缩写：“建国门外大街” 和 “建外大街”，“中国工商银行”和“工行”……
- 错别字：“潮阳门”，“通慧河”……
- 颠倒：“东四环中路朝阳公园” 和 “朝阳公园 （靠东四环）” ……
- 别名：有的人写的是开发商的小区名“东恒国际”，有的则是写行政的地名“八里庄东里”……
这样的例子多得不能再多了。可见数据如果不准确，会增加你处理的难度。有个比喻非常好，玩数据的就像是在挖金矿一样，如果含金量高，那么，挖掘的难度就小，也就容易出效果，如果含金量低，那么挖掘的难度就大，效果就差。
上面，我给了两个案例，旨在说明——
1）数据没有大小之分，只有含金量大的数据和垃圾量大的数据之分。
2）数据清洗是一件多么重要的工作，这也是一件人肉工作量很大的工作。
所以，这个工作最好是在数据产生的时候就一点一滴的完成。
有一个观点：如果数据准确度在60%的时候，你干出来的事，一定会被用户骂！如果数据准确度在80%左右，那么用户会说，还不错！只有数据准确度到了90%的时候，用户才会觉得真牛B。但是从数据准确度从80%到90%要付出的成本要比60% 到 80%的付出大得多得多。大多数据的数据挖掘团队都会止步于70%这个地方。因为，再往后，这就是一件相当累的活。
数据的业务场景
我不知道有多少数据挖掘团队真正意识到了业务场景和数据挖掘的重要关系？我们需要知道，根本不可能做出能够满足所有业务的数据挖掘和分析模型。
推荐音乐视频，和电子商务中的推荐商品的场景完全不一样。电商中，只要你买了一个东西没有退货，那么，有很大的概率我可以相信你是喜欢这个东西的，然后，对于音乐和视频，你完全不能通过用户听了这首歌或是看了这个视频就武断地觉得用户是喜欢这首歌和这个视频的，所以，我们可以看到，推荐算法在不同的业务场景下的实现难度也完全不一样。
说到推荐算法，你是不是和我一样，有时候会对推荐有一种感觉——推荐就是一种按不同维度的排序的算法。我个人以为，就提一下推荐这个东西在某些业务场景下是比较Tricky的，比如，推荐有两种（不是按用户关系和按物品关系这两种），
更多详细信息，请您微信关注“计算网”公众号：
