您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 Code iProcess 课程 认证 咨询 工具 火云堂 讲座吧   成长之路  
会员   
 
   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
 
     
   
 订阅
  捐助
数据的游戏:冰与火
 

火龙果软件 发布于:2014-09-16

1107 次浏览     评价:      
 

新华社新媒体中心联合数托邦创意分析工作室抓取了新浪微博上提及“爸爸去哪儿”的45.5万条原创微博,并对36.7万独立原发作者用户(去除还要提的一个是“数据中的个人隐私问题”,这似乎就像那些有悖伦理的黑魔法一样,你要成功就得把自己变得黑暗。是的,数据就像一个王座一样,像征着一种权力和征服,但登上去的路途一样令人胆颤。

我对数据挖掘和机器学习是新手,从去年7月份在Amazon才开始接触,而且还是因为工作需要被动接触的,以前都没有接触过,做的是需求预测机器学习相关的。后来,到了淘宝后,自己凭兴趣主动地做了几个月的和用户地址相关数据挖掘上的工作,有一些浅薄的心得。下面这篇文章主要是我做为一个新人仅从事数据方面技术不到10个月的一些心得,也许对你有用,也许很傻,不管怎么样,欢迎指教和讨论。

另外,注明一下,这篇文章的标题模仿了一个美剧《权力的游戏:冰与火之歌》。在数据的世界里,我们看到了很多很牛,很强大也很有趣的案例。但是,数据就像一个王座一样,像征着一种权力和征服,但登上去的路途一样令人胆颤。

数据挖掘中的三种角色

在Amazon里从事机器学习的工作时,我注意到了Amazon玩数据的三种角色。

Data Analyzer:数据分析员。这类人的人主要是分析数据的,从数据中找到一些规则,并且为了数据模型的找不同场景的Training Data。另外,这些人也是把一些脏数据洗干净的的人。

Research Scientist:研究科学家。这种角色主要是根据不同的需求来建立数据模型的。他们把自己戏称为不近人间烟火的奇异性物种,就像《生活大爆炸》里的 那个Sheldon一样。这些人基本上玩的是数据上的科学

Software Developer :软件开发工程师。主要是把 Scientist 建立的数据模型给实现出来,交给Data Analyzer去玩。这些人通常更懂的各种机器学习的算法。

我相信其它公司的做数据挖掘或是机器学习的也就这三种工作,或者说这三种人,对于我来说,

最有技术含量的是 Scientist,因为数据建模和抽取最有意义的向量,以及选取不同的方法都是这类人来决定的。这类人,我觉得在国内是找不到的。

最苦逼,也最累,但也最重要的是Data Analyzer,他们的活也是这三个角色中最最最重要的(注意:我用了三个最)。因为,无论你的模型你的算法再怎么牛,在一堆烂数据上也只能干出一堆垃圾的活来。正所谓:Garbage In, Garbage Out !但是这个活是最脏最累的活,也是让人最容易退缩的活。

最没技术含量的是Software Developer。现在国内很多玩数据的都以为算法最重要,并且,很多技术人员都在研究机器学习的算法。错了,最重要的是上面两个人,一个是苦逼地洗数据的Data Analyzer,另一个是真正懂得数据建模的Scientist!而像什么K-Means,K Nearest Neighbor,或是别的什么贝叶斯、回归、决策树、随机森林等这些玩法,都很成熟了,而且又不是人工智能,说白了,这些算法在机器学习和数据挖掘中,就像Quick Sort之类的算法在软件设计中基本没什么技术含量。

数据的质量

目前所流行的Buzz Word——大数据是相当误导人的。在我眼中,数据不分大小,只分好坏。

在处理数据的过程中,我第一个感受最大的就是数据质量。下面我分几个案例来说明:

案例一:数据的标准

在Amazon里,所有的商品都有一个唯一的ID,叫ASIN——Amazon Single Identify Number,这个ID是用来标识商品的唯一性的(来自于条形码)。也就是说,无论是你把商品描述成什么样,只要ASIN一样,这就是完完全全一模一样的商品。

这样,就不像淘宝一样,当你搜索一个iPhone,你会出现一堆各种各样的iPhone,有的叫“超值iPhone”,有的叫“苹果iPhone”,有的叫“智能手机iPhone”,有的叫“iPhone 白色/黑色”……,这些同一个商品不同的描述是商家为了吸引用户。但是带来的问题有两点:

1)用户体验不好。以商品为中心的业务模型,对于消费者来说,体验明显好于以商家为中心的业务模型。

2)只要你不能正确读懂(识别)数据,你后面的什么算法,什么模型统统没用。

所以,只要你玩数据,你就会发现,如果数据的标准没有建立起来,干什么都没用。数据标准是数据质量的第一道关卡,没这个玩意,你就什么也别玩了。所谓数据的标准,为数据做唯一标识只是其中最最基础的一步,数据的标准还单单只是这个,更重要的是把数据的标准抽象成数学向量,没有数学向量,后面也无法挖掘。

所以,你会看到,洗数据的大量的工作就是在把杂乱无章的数据归并聚合,这就是在建立数据标准。这里面绝对少不了人肉的工作。无非就是:

聪明的人在数据产生之前就定义好标准,并在数据产生之时就在干数据清洗的工作。

一般的人是在数据产生并大量堆积之后,才来干这个事。

另外,说一下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的,比如,推荐有两种(不是按用户关系和按物品关系这两种),

一种是共性化推荐,结果就是推荐了流行的东西,这也许是好 的,但这也许会是用户已知的东西,比如,到了北京,我想找个饭馆,你总是给我推荐烤鸭,我想去个地方,你总是给我推荐天安门故宫天坛(因为大多数人来北京就是吃烤鸭,就是去天安门的),这些我不都知道了嘛,还要你来推荐?另外,共性化的东西通常是可以被水军刷的。

另一种是一种是个性化推荐,这个需要分析用户的个体喜好,好的就是总是给我我喜欢的,不好的就是也许我的口味会随我的年龄和环境所改变,而且,总是推荐符合用户口味的,不能帮用户发掘新鲜点。比如,我喜欢吃辣的,你总是给我推荐川菜和湘菜,时间长了我也会觉得烦的。

推荐有时并不是民主投票,而是专业用户或资深玩家的建议;推荐有时并不是推荐流行的,而是推荐新鲜而我不知道的。你可以看到,不同的业务场景,不同的产品形态下的玩法可能完全不一样,

另外,就算是对于同一个电子商务来说,书、手机 和服装的业务形态完全不一样。我之前在Amazon做Demand Forecasting(用户需求预测)——通过历史数据来预测用户未来的需求。

对于书、手机、家电这些东西,在Amazon里叫Hard Line的产品,你可以认为是“标品”(但也不一定),预测是比较准的,甚至可以预测到相关的产品属性的需求。

但是地于服装这样的叫Soft Line的产品,Amazon干了十多年都没有办法预测得很好,因为这类东西受到的干扰因素太多了,比如:用户的对颜色款式的喜好,穿上去合不合身,爱人朋友喜不喜欢…… 这类的东西太容易变了,买得人多了反而会卖不好,所以根本没法预测好,更别Stock/Vender Manager 提出来的“预测某品牌的某种颜色的衣服或鞋子”。

对于需求的预测,我发现,长期在这个行业中打拼的人的预测是最准的,什么机器学习都是浮云。机器学习只有在你要面对的是成千上万种不同商品和品类的时候才会有意义。

数据挖掘不是人工智能,而且差得还太远。不要觉得数据挖掘什么事都能干,找到一个合适的业务场景和产品形态,比什么都重要。

数据的分析结果

我看到很多的玩大数据的,基本上干的是数据统计的事,从多个不同的维度来统计数据的表现。最简单最常见的统计就是像网站统计这样的事。比如:PV是多少,UV是多少,来路是哪里,浏览器、操作系统、地理、搜索引擎的分布,等等,等等。

唠叨一句,千万不要以为,你一天有十几个T的日志就是数据了,也不要以为你会用Hadoop/MapReduce分析一下日志,这就是数据挖掘了,说得难听一点,你在做的只不过是一个统计的工作。那几个T的Raw Data,基本上来说没什么意义,只能叫日志,连数据都算不上,只有你统计出来的这些数据才是有点意义的,才能叫数据。

当一个用户在面对着自己网店的数据的时候,比如:每千人有5个人下单,有65%的访客是男的,18-24岁的人群有30%,等等。甚至你给出了,你打败了40%同类型商家的这样的数据。作为一个商户,面对这些数据时,大多数人的表现是完全不知道自己能干什么?是把网站改得更男性一点,还是让年轻人更喜欢一点?完全不知道所措。

只要你去看一看,你会发现,好些好些的数据分析出来的结果,看上去似乎不错,但是其实完全不知道下一步该干什么?

所以,我觉得,数据分析的结果并不仅仅只是把数据呈现出来,而更应该关注的是通过这些数据后面可以干什么?如果看了数据分析的结果后并不知道可以干什么,那么这个数据分析是失败的。

总结

综上所述,下面是我觉得数据挖掘或机器学习最重要的东西:

1)数据的质量。分为数据的标准和数据的准确。数据中的杂音要尽量地排除掉。为了数据的质量,大量人肉的工作少不了。

2)数据的业务场景。我们不可能做所有场景下的来,所以,业务场景和产品形态很重要,我个人感觉业务场景越窄越好。

3)数据的分析结果,要让人能看得懂,知道接下来要干什么,而不是为了数据而数据。

搞数据挖掘的人很多,但成功的案例却不多(相比起大量的尝试来说),就目前而言,我似乎觉得目前的数据挖掘的技术是一种过渡技术,还在摸索阶段。另外,好些数据挖掘的团队搞得业务不业务,技术不技术的,为其中的技术人员感到惋惜……

不好意思,我只给出了问题,没有建议,这也说明数据分析中有很多的机会……

最后,还要提的一个是“数据中的个人隐私问题”,这似乎就像那些有悖伦理的黑魔法一样,你要成功就得把自己变得黑暗。是的,数据就像一个王座一样,像征着一种权力和征服,但登上去的路途一样令人胆颤。

   
1108 次浏览  评价: 差  订阅 捐助
     
相关文章 相关文档 相关视频



我们该如何设计数据库
数据库设计经验谈
数据库设计过程
数据库编程总结
数据库性能调优技巧
数据库性能调整
数据库性能优化讲座
数据库系统性能调优系列
高性能数据库设计与优化
高级数据库架构师
数据仓库和数据挖掘技术
Hadoop原理、部署与性能调优
 

MySQL索引背后的数据结构
MySQL性能调优与架构设计
SQL Server数据库备份与恢复
让数据库飞起来 10大DB2优化
oracle的临时表空间写满磁盘
数据库的跨平台设计
更多...   


并发、大容量、高性能数据库
高级数据库架构设计师
Hadoop原理与实践
Oracle 数据仓库
数据仓库和数据挖掘
Oracle数据库开发与管理


领先IT公司 android开发平台最佳实践
北京 Android开发技术进阶
某新能源领域企业 Android开发技术
某航天公司 Android、IOS应用软件开发
阿尔卡特 Linux内核驱动
艾默生 嵌入式软件架构设计
西门子 嵌入式架构设计
更多...   
 
 
 
 
 
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号