大数据计算新贵Spark在腾讯雅虎优酷成功应用解析

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享

Spark作为Apache顶级的开源项目,项目主页见http://spark.apache.org。在迭代计算,交互式查询计算以及批量流计算方面都有相关的子项目,如Shark、Spark Streaming、MLbase、GraphX、SparkR等。从13年起Spark开始举行了自已的Spark Summit会议,会议网址见http://spark-summit.org。Amplab实验室单独成立了独立公司Databricks来支持Spark的研发。

为了满足挖掘分析与交互式实时查询的计算需求,腾讯大数据使用了Spark平台来支持挖掘分析类计算、交互式实时查询计算以及允许误差范围的快速查询计算,目前腾讯大数据拥有超过200台的Spark集群,并独立维护Spark和Shark分支。Spark集群已稳定运行2年,我们积累了大量的案例和运营经验能力,另外多个业务的大数据查询与分析应用,已在陆续上线并稳定运行。在SQL查询性能方面普遍比MapReduce高出2倍以上,利用内存计算和内存表的特性,性能至少在10倍以上。在迭代计算与挖掘分析方面,精准推荐将小时和天级别的模型训练转变为Spark的分钟级别的训练,同时简洁的编程接口使得算法实现比MR在时间成本和代码量上高出许多。

Spark VS MapReduce

尽管MapReduce适用大多数批处理工作,并且在大数据时代成为企业大数据处理的首选技术,但由于以下几个限制,它对一些场景并不是最优选择:

 

  • 缺少对迭代计算以及DAG运算的支持
  • Shuffle过程多次排序和落地,MR之间的数据需要落Hdfs文件系统

 

Spark在很多方面都弥补了MapReduce的不足,比MapReduce的通用性更好,迭代运算效率更高,作业延迟更低,它的主要优势包括:

 

  • 提供了一套支持DAG图的分布式并行计算的编程框架,减少多次计算之间中间结果写到Hdfs的开销
  • 提供Cache机制来支持需要反复迭代计算或者多次数据共享,减少数据读取的IO开销
  • 使用多线程池模型来减少task启动开稍,shuffle过程中避免不必要的sort操作以及减少磁盘IO操作
  • 广泛的数据集操作类型

 

MapReduce由于其设计上的约束只适合处理离线计算,在实时查询和迭代计算上仍有较大的不足,而随着业务的发展,业界对实时查询和迭代分析有更多的需求,单纯依靠MapReduce框架已经不能满足业务的需求了。Spark由于其可伸缩、基于内存计算等特点,且可以直接读写Hadoop上任何格式的数据,成为满足业务需求的最佳候选者。

应用Spark的成功案例

目前大数据在互联网公司主要应用在广告、报表、推荐系统等业务上。在广告业务方面需要大数据做应用分析、效果分析、定向优化等,在推荐系统方面则需要大数据优化相关排名、个性化推荐以及热点点击分析等。

这些应用场景的普遍特点是计算量大、效率要求高。Spark恰恰满足了这些要求,该项目一经推出便受到开源社区的广泛关注和好评。并在近两年内发展成为大数据处理领域最炙手可热的开源项目。

本章将列举国内外应用Spark的成功案例。

1. 腾讯

广点通是最早使用Spark的应用之一。腾讯大数据精准推荐借助Spark快速迭代的优势,围绕“数据+算法+系统”这套技术方案,实现了在“数据实时采集、算法实时训练、系统实时预测”的全流程实时并行高维算法,最终成功应用于广点通pCTR投放系统上,支持每天上百亿的请求量。

基于日志数据的快速查询系统业务构建于Spark之上的Shark,利用其快速查询以及内存表等优势,承担了日志数据的即席查询工作。在性能方面,普遍比Hive高2-10倍,如果使用内存表的功能,性能将会比Hive快百倍。

2. Yahoo

Yahoo将Spark用在Audience Expansion中的应用。Audience Expansion是广告中寻找目标用户的一种方法:首先广告者提供一些观看了广告并且购买产品的样本客户,据此进行学习,寻找更多可能转化的用户,对他们定向广告。Yahoo采用的算法是logistic regression。同时由于有些SQL负载需要更高的服务质量,又加入了专门跑Shark的大内存集群,用于取代商业BI/OLAP工具,承担报表/仪表盘和交互式/即席查询,同时与桌面BI工具对接。目前在Yahoo部署的Spark集群有112台节点,9.2TB内存。

3. 淘宝

阿里搜索和广告业务,最初使用Mahout或者自己写的MR来解决复杂的机器学习,导致效率低而且代码不易维护。淘宝技术团队使用了Spark来解决多次迭代的机器学习算法、高计算复杂度的算法等。将Spark运用于淘宝的推荐相关算法上,同时还利用Graphx解决了许多生产问题,包括以下计算场景:基于度分布的中枢节点发现、基于最大连通图的社区发现、基于三角形计数的关系衡量、基于随机游走的用户属性传播等。

4. 优酷土豆

优酷土豆在使用Hadoop集群的突出问题主要包括:第一是商业智能BI方面,分析师提交任务之后需要等待很久才得到结果;第二就是大数据量计算,比如进行一些模拟广告投放之时,计算量非常大的同时对效率要求也比较高,最后就是机器学习和图计算的迭代运算也是需要耗费大量资源且速度很慢。

最终发现这些应用场景并不适合在MapReduce里面去处理。通过对比,发现Spark性能比MapReduce提升很多。首先,交互查询响应快,性能比Hadoop提高若干倍;模拟广告投放计算效率高、延迟小(同hadoop比延迟至少降低一个数量级);机器学习、图计算等迭代计算,大大减少了网络传输、数据落地等,极大的提高的计算性能。目前Spark已经广泛使用在优酷土豆的视频推荐(图计算)、广告业务等。

Spark与Shark的原理

1.Spark生态圈

如下图所示为Spark的整个生态圈,最底层为资源管理器,采用Mesos、Yarn等资源管理集群或者Spark自带的Standalone模式,底层存储为文件系统或者其他格式的存储系统如HBase。Spark作为计算框架,为上层多种应用提供服务。Graphx和MLBase提供数据挖掘服务,如图计算和挖掘迭代计算等。Shark提供SQL查询服务,兼容Hive语法,性能比Hive快3-50倍,BlinkDB是一个通过权衡数据精确度来提升查询晌应时间的交互SQL查询引擎,二者都可作为交互式查询使用。Spark Streaming将流式计算分解成一系列短小的批处理计算,并且提供高可靠和吞吐量服务。

2.Spark基本原理

Spark运行框架如下图所示,首先有集群资源管理服务(Cluster Manager)和运行作业任务的结点(Worker Node),然后就是每个应用的任务控制结点Driver和每个机器节点上有具体任务的执行进程(Executor)。

与MR计算框架相比,Executor有二个优点:一个是多线程来执行具体的任务,而不是像MR那样采用进程模型,减少了任务的启动开稍。二个是Executor上会有一个BlockManager存储模块,类似于KV系统(内存和磁盘共同作为存储设备),当需要迭代多轮时,可以将中间过程的数据先放到这个存储系统上,下次需要时直接读该存储上数据,而不需要读写到hdfs等相关的文件系统里,或者在交互式查询场景下,事先将表Cache到该存储系统上,提高读写IO性能。另外Spark在做Shuffle时,在Groupby,Join等场景下去掉了不必要的Sort操作,相比于MapReduce只有Map和Reduce二种模式,Spark还提供了更加丰富全面的运算操作如filter,groupby,join等。

Spark采用了Scala来编写,在函数表达上Scala有天然的优势,因此在表达复杂的机器学习算法能力比其他语言更强且简单易懂。提供各种操作函数来建立起RDD的DAG计算模型。把每一个操作都看成构建一个RDD来对待,而RDD则表示的是分布在多台机器上的数据集合,并且可以带上各种操作函数。如下图所示:

首先从hdfs文件里读取文本内容构建成一个RDD,然后使用filter()操作来对上次的RDD进行过滤,再使用map()操作取得记录的第一个字段,最后将其cache在内存上,后面就可以对之前cache过的数据做其他的操作。整个过程都将形成一个DAG计算图,每个操作步骤都有容错机制,同时还可以将需要多次使用的数据cache起来,供后续迭代使用。

3.Shark的工作原理

Shark是基于Spark计算框架之上且兼容Hive语法的SQL执行引擎,由于底层的计算采用了Spark,性能比MapReduce的Hive普遍快2倍以上,如果是纯内存计算的SQL,要快5倍以上,当数据全部load在内存的话,将快10倍以上,因此Shark可以作为交互式查询应用服务来使用。

上图就是整个Shark的框架图,与其他的SQL引擎相比,除了基于Spark的特性外,Shark是完全兼容Hive的语法,表结构以及UDF函数等,已有的HiveSql可以直接进行迁移至Shark上。

与Hive相比,Shark的特性如下:

1.以在线服务的方式执行任务,避免任务进程的启动和销毁开稍,通常MapReduce里的每个任务都是启动和关闭进程的方式来运行的,而在Shark中,Server运行后,所有的工作节点也随之启动,随后以常驻服务的形式不断的接受Server发来的任务。

2.Groupby和Join操作不需要Sort工作,当数据量内存能装下时,一边接收数据一边执行计算操作。在Hive中,不管任何操作在Map到Reduce的过程都需要对Key进行Sort操作。

3.对于性能要求更高的表,提供分布式Cache系统将表数据事先Cache至内存中,后续的查询将直接访问内存数据,不再需要磁盘开稍。

4.还有很多Spark的特性,如可以采用Torrent来广播变量和小数据,将执行计划直接传送给Task,DAG过程中的中间数据不需要落地到Hdfs文件系统。

腾讯大数据Spark的概况

腾讯大数据综合了多个业务线的各种需求和特性,目前正在进行以下工作:

1.经过改造和优化的Shark和Spark吸收了TDW平台的功能,如Hive的特有功能:元数据重构,分区优化等,同时可以通过IDE或者洛子调度来直接执行HiveSql查询和定时调度Spark的任务;

2.与Gaia和TDW的底层存储直接兼容,可以直接安全且高效地使用TDW集群上的数据;

3.对Spark底层的使用门槛,资源管理与调度,任务监控以及容灾等多个功能进行完善,并支持快速的迁移和扩容。

(没有打分)

The Mathematics of Romance (2):Same you, while attractive to more

The Mathematics of Romance (2):Same you, while attractive to more

副标题:头像那些事儿

废话不多说:这是个看脸的社会。

社交网站(屌丝级的新浪微博,或意识形态上高攀不起的Facebook or Twitter),求职网站(这个……),还有相亲网站……好像很难想到一个不需要上传头像(或personal profile)的网络服务。而彩笔都很难记清,从什么时候开始,人类(或具体地说祖国人民)进入网络时代,男女老少逐渐都有了自己难以割舍的网络服务。

对任何(正常)人来说,无论什么情境下的头像,都是一个展示自己的渠道。展示自己长得好看,展示自己逼格很高,展示自己的人生理想,展示自己的三观。

展示的目的是吸引。不知道“正常”的人们都怎么看,“吸引”在彩笔看来是个很暧昧的词儿。当“相互吸引”关系确立时,后面的事情就不好说了。但无论如何都是很有趣的事情,你值得拥有哦。

插注:前面一段话实质上与本文、大数据关系不大,但因彩笔坚信“文以言志”,而彩笔的是传递价值观,所以这些内容也不是完全没有必要。

 

本文关于头像选择,更具体的说,是相亲网站用户的头像选择(不负责任一点地说,社交网站也是类似的逻辑吧)——因为原始数据来自相亲网站的用户(看过preliminary的读者应该知道了)。

我想,所有人都会不同程度的同意下面这句话:

No matter how much time you spend polishing your profile, honing your IM banter, and perfecting your message introductions, IT’S YOUR PICTURE THAT MATTERS MOST.

 

一、谁敢说自己“不看脸”

这就是一个看脸的社会,don’t deny it。(我又没说只看脸)

1. 对异性的评价与挑选目标

旁白:题目中的评价挑选并不矛盾。假设所有人都给章子怡5分(满分5分)(此之谓评价),但并非所有人在挑选去民政局登记的对象的时候,均是以子怡为首选(此之谓定制目标)。弱水三千,只取一瓢饮,这里无需多言吧。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

两张图中的虚线表示的是各个性别群体对异性的评价分布(数据来源及操作方法将在文章结尾处尽表)。粗实线表示的是他们/她们向异性发送消息的比例分布。

从图中可以看出,男性对女性的(整体)评价(左图虚线)接近对称,但是在挑选“目标”的时候他们的倾向性非常明显(还需要彩笔明说嘛[捂嘴笑])。女性对男性的评价分布(右图)用“苛刻”来形容毫不为过。大多数(80%)男性在她们看来是worse-looking than medium,然而在选择发送信息的对象时,她们又变得宽容。

产生这种差异的原因值得玩味,但不在此处细表。图中的数据似乎是在告诉我们:不管长成什么样(异性对“你”的评价如何)都会收到信息(在这篇文章中,彩笔不想纠结群体与个体的关系——群体有并不代表群体中的每个个体都有)。而在本文中,我们用到的信息是:对于女孩子,头像中的你长得越漂亮,收到的信息就越多;男性的话,好难讲,彩笔一直觉得女性从男性那里寻求的并非“美颜”,所以才会出现上图中的神奇分布,但至少头像中的形象能让女性找到她们寻求的某样东西或某种感觉。

 

2. 数量化ATTRACTIVENESS

之前说到,头像在异性们心目中的好看程度与最终收到的信息数量是有关系的,并且按照“常理”,越好看的人收到的信息数量就越多(姑且忽略男女两性在对对方评价以及最终挑选目标时的差异)。

 

 

 

 

 

 

 

 

 

 

 

图中的信息呼之欲出:长相(头像)越好看的人,收到的信息越多(注意:纵坐标是“倍数”,而非绝对数量哦)。Female recipients的曲线斜率的增加速度快过male recipients——原来我们的小伙子们都是行动派嘛。

对于任何一个读到这里的读者,在此刻可以确认头像的重要性了吧。

 

3. 成功率与头像(长相)

前面讲的都是作为一个被动的receiver,头像与接收到的求*信息数量的关系。这一节中,展示的是作为sender,信息被回复(即“求*初步成功”)与头像的关系。长得好看的人收到的信息越多,那么发出的求*信息的成功率(被回复)是否也越高呢?请看下图。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

根据图表中的信息,说“越好看的人发出去的信息成功率越高”好像可以,但也好像有点牵强。Most attractive male senders在least attractive female recipients会遇到点挫折呢。不过还好,总的来说,也是“越好看,成功率就越高”的啦(如下图)。然后姑娘的成功率弱弱的高于小伙子们(果然,在社会大家庭中,蓝孩纸还是很照顾铝孩纸的)。

 

 

 

 

 

 

 

 

 

 

 

 

二、选头像时的does and don’ts

人就长成这无法被拯救的样子了,但是头像还是可以挽回一些的。能挽回多少?就看你怎么玩儿了~

1. FACIAL ATTITUDE

头像中的表情与每月新增联系人的数量关系如下。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

从图中可以看出,对于女生来说,笑比不笑的效果(吸引力)好,但是效果最好的头像表情是flirty-face。但要注意flirty face要对着镜头,如果没对镜头的话,可能会是相反的作用。男生的情况相对简单了:look away from the camera and don’t smile。

 

2. The MySpace Angle is busted.

The universally-maligned MySpace angle is achieved by holding your camera above your head and being just so darn coy.——我大中华的仰拍什么的,原来在异国他乡是有名字的啊!

 

 

 

 

 

 

这种自拍类照片往往是头像界所不齿的类型,然而,它在吸引新联系人(女性吸引男性)方面有着意料之外的正面效果,如下图。

 

 

 

 

 

 

 

 

 

 

 

 

这让研究人员百思不得其解,the Myspace shot对于女性来说几乎是唯一一种有效的照片类型。研究人员怀疑过,是否是因为这样的角度能够获得从上往下看女生上衣的角度(这么说十分隐晦,不过……应该能懂吧)。但当研究者将所有“能看到”的照片剔除,重复分析,得到的结果是一样的。甚至,the Myspace shot的效果还要好于直接“露”,嗯。

 

3. Guys should keep their shirts on.

同样与人类常识相反的是“男生秀腹肌”。在人们的印象中,Ab shot通常让人觉得PO主很二。然而实际的情况是这样的:

 

 

 

 

 

 

 

 

 

 

 

研究人员认为产生这种现象的原因是:Normally,将此类照片作为头像的人都有show off的资本,and naturally the best bodies get lots of messages。但是,如果是这个原因让这类照片火了的话,这个举措就不适合推荐给所有男士了哦。

 

4. Make sure your face is showing(?)

OkCupid过去是将露脸作为推荐项(强制项)出现在用户提交personal profile的页面的,然而in fact, not showing your face can be a positive, as long as you substitute in something unusual, sexy, or mysterious enough to make people want to talk to you.成功的例子如下:

 

 

 

 

 

 

 

 

 

 

 

这些用户收到的信息数远高于一般水平,但他们并没有很出众的个人介绍,正是他们的头像帮助他们达成了这样的效果。

写到这里,好像又与初衷矛盾了——不是说,这是个看脸的社会么?我想这个问题大家随意思考一下就可以了,无需彩笔给出一个答案(或答案之一)。而且我在最开始的时候就说过了:我又没说“只”看脸。

 

数据来源与操作方法

The data set was chosen at random from all users in big cities, with only one profile photograph, between the ages of 18 and 32. We then lopped the most and least attractive members of the pool, fearing that they would skew our results. So all the data in this post is for “average-looking people.”

 

We finalized our data pool at 7,140 users. Aside from running each picture through a variety of analysis scripts, we tagged, by hand, each picture for various contextual indicators. We double-checked the tags before generating our data.

 

To quantify “profile success” for women, we used new messages received per active month on the site.

 

We had to do something different than this for guys, because of the fundamentally different role they play in the online courtship process: they are the ones reaching out to new people; women send only a small fraction of the unsolicited “hellos” that men do. As you’ve seen, the metric we settled on is, “women met per attempt”, which is:

(new incoming messages + replies to outgoing first contacts) / outgoing first contacts

 

Basically, this is how many women a guy has a conversation with, per new woman he reaches out to, and we feel it’s the best way to measure his success per unit time on OkCupid. Note that if a guy has a particularly compelling photo, this ratio could exceed 1, as he’d be getting messages from the women who come across his profile, as well as the women he himself is reaching out to.

 

总结

多么有意思的结论。而且,是这么多有意思的结论。

不曾跟进过笔者其他文章的读者是否压根看不到这里:这跟大数据有半毛钱关系?!

其实此时此刻的彩笔根本压抑不住内心的狂热,想要大声告诉任何人:在有“大数据”(好吧,彩笔必须承认,这里的大数据定义有些模糊)之前,这些事情是无法做到的。——虽然其实不是,或者彩笔也不能确定的知道是或者不是。

 

在系列“GFT你这么diao,你的伪粉丝们造吗”最后一篇文章的结尾,笔者提出,GFT内生的一个drawback是:GFT自身是大数据的一套方法体系,然而它却是为预测一个由传统的统计方法得到的数据而存在的。在这种交错中,没有人知道伴生着什么问题(影响预测的准确性,或者对“准确性”的解读)。

在Lazer的文章[1]中也给出建议:Google可以通过combine big data and small data来优化预测过程。笔者认为,OKCUPID的这群研究人员做到了,或者说做了很好的尝试。

这个研究团队的主要成员已经在本系列的第一篇文章(约2个月前[惭愧])中有过简单介绍。

关于头像,他们在证明头像中人物的“质量”与收到陌生人信息的数量之间的相关关系甚至数量关系的基础上[参考文章6],还总结了拍摄照片的技巧[参考文章4](当然是以吸引力为衡量标准)以及头像内容与吸引力[参考文章3](收到陌生人信息数量)的关系,另外还从男性心理的角度出发,指导女性选择头像[参考文章2]。作为成果之一,他们还一度提供一项帮你判断哪张照片更适合作为头像的服务[参考文章5]。

作为一个基于online dating网站的研究团队,他们的兴趣内容还涉及发给对方的第一句话怎么说更容易收到回复?第一次约会怎样操作更容易lead to下一次?等等。

按照国内学术圈的惯用标准,既有科学意义,又有实践意义,“业界良心”好好嘛!

 

另注:

这真的是一篇关于大数据的文章(很难理解么)。之前的系列“the Big Data Concerns You HOW”出街之后,相信仍然会有不死心人士。本文提到的这类“工作”的门槛低,成就高(我就随口说说而已,哪有这么容易的事),不失为一个很好的切入角度。

这真的是一篇关于大数据的文章,所以我没有任何念头教读者如何选头像。将原科研人员的数据来源以及预处理过程交代清楚,其目的除了将原作拖下神坛,方便更多的不死心人士踩踏入门之外。另外一个目的也是告诉读者,这虽然是一个“大数据案例”,但也有其内源性的适用对象。虽然,作为参考而借鉴是没什么的。

——在这里也要深刻反思对“大数据”的界定模糊。

 

相关文献:

[1] Lazer D, Kennedy R, King G, et al. The Parable of Google Flu: Traps in Big Data Analysis[J]. Science, 2014, 343(6176): 1203-1205.

[2] The Mathematics of Beauty, 2011.01.10, Christian Rudder:http://blog.okcupid.com/index.php/the-mathematics-of-beauty/

微信公众账号《数据分析》的一篇文章基本算是原文的译文,但是没有标注任何引用,着实可耻:

大数据分析看如何成为美人。[八卦]2014.04.18:mp.weixin.qq.com/s?__biz=MjM5MjAxMDM4MA==&mid=200226343&idx=1&sn=714db607d786fab9504080fc4617815c#rd

[3] The 4 Big Myths of Profile Pictures, 2010.01.20, Christian Rudder, http://blog.okcupid.com/index.php/the-4-big-myths-of-profile-pictures/

[4] Don’t Be Ugly by Accident, 2010.08.10, Christian Rudder, http://blog.okcupid.com/index.php/dont-be-ugly-by-accident/

[5] What Is Your Best Profile Picture, 2010.05.06, Christian Rudder, http://blog.okcupid.com/index.php/my-best-face/

[6] Your Looks and Your Inbox, 2009.11.17, Christian Rudder, http://blog.okcupid.com/index.php/your-looks-and-online-dating/

(1个打分, 平均:5.00 / 5)

大数据 。社会医疗健康

(没有打分)

美国白宫 。大数据 。《BIG DATA: SEIZING OPPORTUNITIES, PRESERVING VALUES》

(没有打分)

大数据跟“所有人”什么关系(下) ——写给“普通人”看的“Big Data Concerns You How”

大数据跟“所有人”什么关系(下)

——写给“普通人”看的“Big Data Concerns You How”

废话不多说,续前文。

 

三、哎呀我说人类啊

本小节标题请用二手玫瑰(artist)《命运(生存)》一曲中“哎呀我说命运呐对应的旋律来发声。

彩笔黄是个很矫情的人,表现之一是不喜欢回答一些明明是哲学范畴,却被世俗的搞不清楚状况的人问出来,然后还不得不回答。比如常见于门卫大哥小哥的“你是谁?”、“你从哪里来?”、“你要到哪里去?”,[抓狂]真的是完全不知道要如何开口。

随着社会生活内容的增多,这种奇葩问题的来源也越来越多,招架不住。比如美容店、理发店或者美甲的地方,这类服务往往要以小时计(一困就是若干小时的节奏)。服务人员通常会找话题。常见的除了“你从哪里来?”之外,笔者遭遇最多的就是“你是做什么的?”

而这个问题,真!的!很!复!杂!

简单地说,笔者是做“数据分析”的。但在笔者看来,这四个字说!了!等!于!没!说!啊!笔者很抵触这样明摆着会造成误解的答案。可是,第一次被问时不说,便会有“下次”。这些天真的人们不知道有没有想清楚便执着地强迫我给出答案(我不知道他们为什么觉得我一定要说,大约正如他们不知道我为什么会不想说)。于是彩笔只得勉强挤出那四个字“数据分析”。

然而,出人意料,彩笔给出答案之后,对方会仿佛什么都知道了似的“哦~~~~~”(“我还以为是什么呢,这个我知道啊”之类的)。这让笔者很不舒服。

彩笔黄深知自己给不出可以让人“哦~~~~~”的答案(并深刻质疑这个世界上究竟是否存在对数据分析这个职业的一致的认识)。So,作为信息源的我并没有输出“数据分析”的清晰认识,为什么接收方会认为自己“知道了”呢?彩笔很痛苦。

痛点1:我热爱数据分析这个职业,但是谈到对“数据分析”本体的认识,目前的现状还很复杂,不是百废待兴,而是群魔乱舞;彩笔不知道为什么要在一个休闲放松的时候、如何跟一个处理身体美容的孩子介绍这个话题(我知道是我考虑问题太严肃了,我就是不想敷衍)。

痛点2:在我明明没有说清楚的前提下,那些人,凭什么以为自己理解了!(彩笔觉得这很荒谬,也让彩笔很气愤)

 

说着这么一大段有的没的(但绝对不是可有可无的),是为了引出下面要用到的这种先进的价值观:

1. 世界上也许根本没有communication,只有每个人兀自地talking。就像笃信外星人存在的组织和个体不间断地向外太空发送信号一样,漫无目的,却满怀希望。地球上的人类个体之间是不是也是这样:我们都以为自己会被理解而不停地向外界发送有关我们自己的描述。因为视野中从不缺少“同类”,所以我们会过高的估计被理解的可能性。以为自己是在跟对面的人communicating,但其实只不过是大家互相各自你说一句,我说一句(如果有人固执地把这种行为叫做communication)。

2. 所以我们根本没资格谈论understanding,在生存或相处中,我们的选项只有一个:compromise。

 

如此粗略地介绍一个道听途说、但是很伟大的价值观,彩笔无非是想表达:即便你找到一个人(你认为的、或你认为业内公认的能够把大数据的前生今世说清道明的人,或者不是一个人,而是一个可以实现上述功能的虚拟对象),TA说的,你又能领悟多少(当然你永远可以觉得,你领悟了,或多或少)?

 

四、一个虚构的例子

究竟什么是大数据?让我们看个虚构的例子(网上转载,出处不明,如有需要,原作者可与本人联系):

某披萨店的电话铃响了,客服人员拿起电话。

客服:***披萨店。您好,请问有什么需要我为您服务?

顾客:你好,我需要一份……

客服:先生,麻烦您告诉我您的会员卡号。

顾客:16846146***

客服:陈先生,您好!您是住在泉州路一号12楼1205室,您家的电话是2646****,您公司电话是4666****,您的手机是1391234****。请问您想用哪一个电话付费?

顾客:你为什么知道我所有的电话号码?

客服:陈先生,因为我们联机到CRM系统。

顾客:我想要一个海鲜披萨。

客服:陈先生,海鲜披萨不适合您。

顾客:为什么?

客服:根据您的医疗记录,您的血压和胆固醇都偏高。

顾客:那你们有什么可以推荐的?

客服:您可以试试我们的低脂健康披萨。

顾客:你怎么知道我会喜欢吃这种的?

客服:您上星期一在中央图书馆借了一本《低脂健康食谱》。

顾客:好,那我要一个家庭特大号披萨,要付多少钱?

客服:99元,这个足够您一家六口吃了。但您母亲应该少吃,她上个月刚刚做了心脏搭桥手术,还处在恢复期。

顾客:那可以刷卡吗?

客服:陈先生,对不起。请您付现款。因为您的信用卡已经刷爆了,您现在还欠银行4807元,而且还不包括房贷利息。

顾客:那我先去附近的提款机提款。

客服:陈先生,根据您的记录,您已经超过今日提款限额。

顾客:算了,你们直接把披萨送到我家吧,家里有现金。你们多久会送到?

客服:大约30分钟。如果您不想等,可以自己骑车来。

顾客:为什么?

客服:根据我们CRM全球定位系统的车辆行驶自动跟踪系统记录,您登记有一辆车号为SB-748的摩托车,而目前您正在解放路东段华联商场右侧骑着这辆摩托车。

顾客当场晕倒。

 

这是个极一般的网络段子而已,语言很粗糙,逻辑也有很多经不起推敲的地方。但话糙理不糙,其中涉及到一个社会人日常生活的若干方面:经济信息、健康信息、实时的位置信息,还有现代社会基础服务如图书馆,甚至包括个体之间的关系信息(或曰户籍信息?),以及基础规则(比如健康与饮食、历史经济信息与将来的经济行为的对应等)。任何一个人(一般人/普通人),都很难讲自己的信息完全脱离与上述系统之外。

 

所以,对于大多数人,大数据是一种全新的服务形式,而已。LET IT FLOW,放松全身心,JUST ENJOY IT,不需要想太多。

 

写在最后的话

以管窥豹,可见一斑。简单的说,这篇文章的意思是:如果你不知道大数据是什么,那么,说不定你压根就不需要知道大数据是什么。或者,你知道的也是不准的。而且即便找到别人”跟你说,你也不会明白。对于其工作逻辑来讲,就这么回事儿。把它作为你的苹果手机,你不需要因为不知道它的供应链、制造商的运作而感到焦虑,你会用它打电话、发短信、接入互联网享受五彩斑斓的Web服务,就够了。

(4个打分, 平均:2.00 / 5)

大数据跟“所有人”什么关系(上) ——写给“普通人”看的“Big Data Concerns You How”

大数据跟“所有人”什么关系(上)

——写给“普通人”看的“Big Data Concerns You How”

 

写在前面的话

很少见地,这是一篇散文。(之所以少见,是因为笔者在求学的那些年写所谓的“考试作文”,写散文从未得过高分——彩笔从未排除是评判标准的问题。)

 

一、我有一个朋友

该青年在广州某大型政府投资性企业工作,为人靠谱(我会乱说),领导看好,目测有一个Promising的将来(我其实不懂,不过少女们弱弱地发一下花痴就好,此人已订婚)。

这样一个朋友(本应跟彩笔的二笔人生毫不搭界),偶尔会以请吃饭为诱饵,创造机会跟笔者扯一段什么是大数据之类的话题。可见他原本的工作内容、以及社交圈子跟大数据的相关程度有多稀疏;也可见他是有多绝望——找到彩笔这种边缘人。

这个朋友代表这样一类人:

1. “社会意识”开始觉醒;

2. 部分精神世界开始脱离低级趣味;

3. 有意愿跻身于“大数据”这个ongoing时代潮流中;然而,

4. 无法摆脱“术业有专攻”的桎梏,“专业能力”不对路,至少目前做不到为“大数据”的宏伟蓝图的实现添砖加瓦。

若是在以前(对不起,彩笔也不知道至少要追溯到多久之前),“隔行如隔山”,现如今这种大范围的跨行业“乱入”应该完全不能想象吧。所以,《世界是平的》这种内容的书会成为比尔盖茨推荐的畅销书,还竟然可以“再来一本”。这种现象的出现,也便由意料之外,变为情理之中了。

这个又热又挤又平的世界,好像可以让人不费吹灰之力就可以看到其他行业的人在忙什么。这种零高度差创造出一种“好像很容易”、“我也可以做到啊”之类的幻觉。于是,越来越多的人开始觉得,自己就是那个厨子,以为“不想当裁缝的司机,不是好厨子”的励志的句子说的正是自己。

笔者本想说,每个人做好自己的本分就够了。然而转念一想,如何在这个扁平的毫无遮拦的世界里界定“本分”?有难度。同时,作为一个自由主义者,笔者坚定地维护每个人“天马行空”、“异想天开”以及做任何不切实际的梦的自由,即便倾向于以结果为导向的笔者找不到论据JUSTIFY他们的各种妄想。

因为上文的种种(也会因为下文的种种),每次SENSE到这位大叔是要FEED有关大数据的内容而请求见面时,彩笔黄就会很纠结。且不说彩笔能说出来的东西不多,彩笔也更加不知道大数据concerns him how,不知道要跟他说什么。钱可以浪费,但粮食不能浪费。这样的饭,彩笔吃不下[委屈]。

 

二、我有一个同学

笔者求学期间的一个同学,现在是鄙人母校的在读博士。当年(2012年6月末至7月初的时候),我们是一同在武汉大学图书情报与档案管理研究生暑期学校的讲座上,听张李义老师的讲座“大数据背景下的信息处理工具与方法”。有生之年for the first time,聆听有关“大数据”的福音。自那时始,大数据便渐渐“走进了彩笔的内心深处”,扎根下来,变成了彩笔黄的一生挚爱,谁都抢不走。然而,截然相反地,这位同学却在随后的时间里,走上了一条几乎完全相反的路。用她的话说:大数据对于我们这种没有数据处理技术,没有数据处理设备,更压根就没有数据的(一般)人来说,就是个坑(绕着走)。”

 

/*下面是一段插叙*/

笔者在之前的一篇文章中提到过(我就是不说是哪篇),大数据不过是在新的技术水平下,某旧物展现出来的新姿态。所谓“老树发新芽”。“老树”是经典的数理统计理论,以及在漫长的实践过程中添加和反复验证的方法体系。“新芽”便是分布式、云计算这些我本身就一知半解、说出来你以为你懂但其实你根本不可能懂的“新技术”了。

如果一定要用一句简短的话表述什么是大数据,笔者会选择:大数据即全部的数据。”

什么是“全部的数据”呢?假设你经营一家上世纪八九十年代的“小卖部”,售卖烟酒糖茶等种类有限的货品。这时,“全部的数据”可以是每种货品的成本、单价、销售、库存等等(抱歉笔者并没有实际经营经验,这里只是列举几个作为例子,看官可结合自身丰富的经验自行脑补“等等”的部分)。然后,继续假设你经营的是一家21世纪的跨国连锁超市,对于你来说“全部的数据”仍然是:每种货品的成本、单价、销售、库存等等(注:一个字都没有改动哦)。

是的,我们惊喜地发现了,这个以数据命名的时代(“大数据时代”)并没有新数据的诞生。或许一些行业的资深业内人士仍然能够想到一些现在“能看到”并且当年“看不到”的数据类型。彩笔黄的解释是,这种数据类型或许是新的,但是这些数据类型所描述的对象是一直存在的。(有些诡辩了是不是)

这些业内人士的疑问可以很好的引出我们的下一个环节:是什么让这些新的“数据类型”诞生(成为可能)?答曰:“(新)技术。”

彩笔实在是不想讨论什么是大数据,所以以上内容虽未得尽表,但也到此为止。

/*插叙的内容结束*/

 

终于回到我的同学这里。虽然我们分别决定走上不同的路,但是我们对大数据的一些基本认识是一致的(上述插叙的内容啦)。她之所以决定绕路,是因为认识到大数据的门槛其实很高(在这个普遍认为“THE WORLD IS FLAT”的人世间,能意识到这里实属不易)。而她本人的兴趣、专业的技能等,不足以将她提升至与大数据共舞的高度。

 

 

写到这里,笔者决定暂且告一段落。总结一下文章进行到这里的思路:

在文章中,笔者介绍了笔者身边两类人的代表,描述了他们对于大数据的态度(趋之若鹜VS避之唯恐不及)以及这种态度的形成过程。期望是能够引发有关Big Data Concerns Everybody How的思考。这两类人即便不能完全cover现在社会上的所有人,“所有人”都可以在这两个分类中找到部分自己的归属感。接下来便可以自行思考Big Data Concerns Yourself How了。因为笔者确定有下文,也确定下文的内容与解答这个问题完全无关(突然觉得这个系列——虽然确定下来只写上下两篇——应该叫做“彩笔黄的价值观输出”)。

(6个打分, 平均:1.00 / 5)

GFT你这么diao,你的伪粉丝们造吗(4)

GFT诞生背景与应用基础

副标题:愿科技进步惠及每一个人

 

这是一个给GFT舔脚的系列。前面三篇文章从方法论的角度解剖GFT,本文作为这个系列的终结,为达到“划上圆满句号”的华丽特效,将从(伪)“形而上”的高度俯视GFT,品味一个高科技产品的人文情怀。

 

作为一个自由主义者,笔者拥护“个人自治权”,认为理想的社会组织应能够确保每个个体的行为不受限制,正当的“灵魂”运行模式应是由内而外的感受“什么是我想做的”,而非由外而内的将“什么是需要我做的”强加到个体身上。

在这样的指导思想下,本文首先用明确的语言表述GFT团队想做的事,其次证明这样一件事是被“需要”的(上纲上线[狂汗],笔者很无奈),再后是这件事的“可行性”,最后有关GFT的实现过程前面三篇文章已介绍过。这个逻辑顺序自然是笔者主观臆测。笔者只是按照自己的情感倾向,在孤立的环节间建立关联。然而作为一个理想主义者,笔者愿意为营造这样美好的未来而奔走。

言归正传。

 

1. What is it?

心理学上有名的five stages of grief中蕴含着一个很有趣的现象。五个阶段分别是[2]:

1)         “否认”:“不会吧,不可能会是这样。我感觉没什么事啊。”

2)         “愤怒”:“干嘛啊,这不公平!这怎么可能让人接受!”

3)         “讨价还价”:“让我活着看到我的儿子毕业就好。求你了,再给我几年时间。我什么都愿意做。”

4)         “抑郁”:“唉,干嘛还要管这些事啊?反正我都要死了。也没什么意义了。”

5)         “接受”:“我没问题的。既然我已经没法改变这件事了,我就好好准备吧。”

心理学家用这五个阶段描述人们经历哀伤或失去的过程。“有趣”的地方在于,“接受”是最后一个环节。在前面四个阶段,人们拒绝正确地认识现实,对“客观”也抱持着偏激的态度。我们可以从中学到的是,在到达“正确”之前,必然会受到“干扰项”的蛊惑。为避免弯路和不脚踏实地的态度,“明确定义”是第一步。而将模棱两可的想法实实在在的写下来的过程最有助于厘清思路。

简单粗暴地说,GFT analyze large numbers of Google search queries to track influenza-like illness in a population [1].如果将GFT比作奶牛,它吃进去的草是Google服务器日志中记录的用户提交的检索词,它挤出来的奶是人口中的流感患病情况。

单看效用(理想情况下),它可以向地球人提供每个区域的人口中流感(后来又增加了登革热)患病比例。为追求更高的准确率,需满足的前提是(区域)人口中包含足够数量的Google用户(这其中又隐含了互联网基础设施建设、公民教育普及、人权实现率等,这些都是后话)。

 

2. Why is it?

运用大数据技术(吐槽:这个说法太模糊了)可以做很多改变世界、造福人类的事,比如运用贝叶斯概率模型结合random walk theory预测股市波动(准确率还蛮高,隐约记得高于80%——但这个概率在实际应用中对应的具体损失有待具体分析),可观的利润自然是池中之物,探囊可取。为什么选择预测流感发病情况呢?GFT团队是这样理解的:

(1)流感是人类个体遭受的苦难,减少社会累积财富。Seasonal influenza epidemics are a major public health concern, causing tens of millions of respiratory illnesses and 250,000 to 500,000 deaths worldwide each year. In addition to seasonal influenza, a new strain of influenza virus against which no previous immunity exists and that demonstrates human-to-human transmission could results in a pandemic with millions of fatalities.

(2)提前判断疫情有利于降低损失。Early detection of disease activity, when followed by a rapid response, can reduce the impact of both seasonal and pandemic influenza.

在前面的文章中提到过,在这几句类似宣言的外国文字的字里行间,笔者清晰地看见了三个代表中“代表最广大人民群众的根本利益”(笔者政治觉悟不高,如果理解的偏差太大,还请看官们多多包涵),也有与美国英雄们“拯救人类”的行为等同的崇高感。

整个思维过程既脚踏实地、接地气(“流感面前人人平等”),也充斥着人间大爱。GFT向人类世界输出每个区域的疫情严重情况,接下来各个层次的决策者就可以考虑资源分配问题了。

 

写这一部分的目的就是想传递出:GFT并不是一群人无所事事,以圈钱为最终目的和唯一考虑。它的人文主义情怀(对世界的责任感)下文还有提及。

 

3. How it’s done?

改善公共卫生状况的途径有很多。GFT拥有大量存储在服务器日志中的检索词(与flu或有关或无关),从Google Search queries到CDC ILI data,是否有可能?GFT团队可能是这样下定决心的:

(1)皮尤研究中心2006年发布的一项关于互联网的调查显示,每年有9千万美国成年人在互联网上检索与疾病或用药有关的信息。

(2)在文章[1]的补充资料部分,Google提供了一个其他主题的例子,证明特定检索词的数量变化与现实生活中某些“事件”的发生有关联。如下图所示,曲线表示有关日食的检索词的数量随时间的变化(按周汇总数据),黑点对应日食发生时间。清晰可见,每次日食出现的日期附近,检索词“solar eclipse”的提交数量都明显高出日常水平。也就是说,倘若我们无从得知日食何时会出现,监控Google用户检索“solar eclipse”的次数可以给我们提供很准确的预测。

文献来源:参考文献[1]的supplementary

上述事实不仅能够证明,特定检索词的数量变化与客观世界中的一些事件是“相关的”(大数据所强调的相关关系哦),也暗示了特征检索词数量变化能够反映流感患病的门诊数量(在总人口中的比例)的潜在可能性。准备工作进行到这里,只剩下谨遵Michael Jordan的教诲:JUST DO IT。

 

总结:

伟大的工作其实一直都有人在做,对公共卫生基础水平的关注并非GFT之始。比如我们熟悉的这个星球上最大的慈善基金会Bill & Melinda Gates Foundation。其下设专门的division Global Health关注和推动有关传染病、疫苗等的科学和技术项目。相比于这些“传统”的做法,GFT的优势是:快。在参考文献[1]中我们知道,GFT比CDC的统计提前2周,即实时。而它若是结合时序分析的技术,实现“提前”预警也不足为奇。这对于资源准备和分配、提前疏散(隔离)等决策的指导意义不言自明。这也难怪很多public health officials都是GFT的用户。(参考文献[3]:In addition  to the general public, an important target audience for GFT has been public health officials, who can benefit from reliable daily estimates and often make far-reaching decisions based on predicted flu incidence (such as how to stock and distribute vaccine, and the content of public health messaging).

God is a bitch,祂能力有限或心怀不轨,坐视整个人类社会千疮百孔。GFT的内生性不完美略表如下:

1. GFT整个技术体系是大数据,预测的目的却是传统的统计数据。预测的“不准”是因为GFT的结果与“现实”不一致,还是因为CDC根本就代表不了“客观的显示”?(这对于强迫症、完美主义来说,简直闹心死了。)

2. 上一篇文章大言不惭地说,GFT的核心矛盾是无上限的优化统计学习过程的需要。不假。但也还有其他。“联系”的观点,GFT并非独立存在,GFT的问题也并不单一。伴随着Google的推广普及,甚至人类社会的进步(更多的互联网基础设施,更普及的基础教育,基本人权的基本保障等等,GFT会越来越完美,也或许到那个时候,GFT也便不再被需要。

 

相关文献:

[1] Ginsberg J, Mohebbi M H, Patel R S, et al. Detecting influenza epidemics using search engine query data[J]. Nature, 2009, 457(7232): 1012-1014.

[2] http://zh.wikipedia.org/wiki/%E5%BA%93%E4%BC%AF%E5%8B%92-%E7%BD%97%E4%B8%9D%E6%A8%A1%E5%9E%8B

[3] Copeland P, et al. Google Disease Trends: an Update. International Society for Neglected Tropical Diseases. 2013. available at: http://patrickcopeland.org/papers/isntd.pdf

(没有打分)

GFT你这么diao,你的伪粉丝们造吗(3)

GFT 3.0: updated (2013)

副标题:旁观一个技术主管的verbal reasoning ability

 

注:本文“内容”若非特别注明,均来自“Copeland P, et al. Google Disease Trends: an Update. International Society for Neglected Tropical Diseases. 2013. available at: http://patrickcopeland.org/papers/isntd.pdf一文。

 

GFT 2.0针对GFT 1.0对非季节性流感的Underestimate做出改进(在建模过程中增加了09年H1N1爆发期间的检索数据)。GFT 3.0是针对在2012年流感季节,GFT 2.0对实际数据的overestimate作出的改动。

第一次更新时,GFT 1.0 underestimate的原因被归结为季节性流感和非季节性流感期间用户的health-seeking behavior不同,但并未明确指出究竟为何不同。

在构建GFT 3.0时,GFT团队将导致GFT 2.0 overestimate的原因归结为媒体的放大效应。表现为:大众媒体对流感疫情的报道,使更多的未患病个体也进行flu-related检索,导致检索词出现次数与ILI病例比例之间原有的数字关系不再“有效”。

 

作者尝试在文章中给出以下问题的答案。

1. 为什么12-13年度的流感季节中,GFT的预测过高?Why were this season’s predictions so high?

2. GFT模型是否过于简单粗暴?Is our model too simple?

3. GFT 2.0中是否仍有未考虑到的影响因素?Were there unforeseen side effects from the 2009 update?

4. GFT是否能表现出CDC的ILI数据之外的现象?Does this reveal a phenomenon not captured in incidence data provided by the US Centers for Disease Control and Prevention (CDC)?

 

旁白:都是好问题,从实际问题出发(overestimation),既有对GFT本身的反思(too simple),也对有关GFT的舆论做出回应。层层递进,有理有据。

 

1. 怎么就overestimate

GFT 1.0刚上线时,计划对它每年更新一次。然而在GFT 2.0和GFT 3.0之间,未有annually update。原因是,每个流感过后对GFT模型评估,GFT 2.0的表现so far so good。团队的观点是:不断添加新数据确实能够提高估计的准确性,但对于truly anomalous years的情况无改善。

GFT 2.0一直doing well,直到2012-2013 flu season,模型输出的预测结果明显偏离了真实数据源,(However, in the 2012-13 season, the overestimation peaked at 6.04 percentage points, an estimate more than twice the CDC-reported incidence (week starting Jan. 13: CDC data 4.52%, GFT estimate 10.56%).),drastically overestimated peak flu levels [1]。

 

2. 简单粗暴,不失有效

GFT团队承认,他们的算法容易受到短期内检索词数量不规则变化的影响,而这些“数量的不规则变化”可能是concerned people对流感相关的媒体报道做出反应的结果。(所以,GFT的直接目的是预测CDC ILI data,但它所能描述的远不止于CDC ILI data。)

GFT团队在承认他们的算法sensitive to sudden changes in query volume的同时,也巧妙地表达了不能公开组成模型的检索词的必要性。作者回忆在2008年发布GFT 1.0时,New York Times的一篇报道碰巧包含一个模型中的检索词。他们马上就看到了这条检索词流量的增加。笔者不禁想到,Lazer [2]在他的文章中一边要求Google公开GFT的内部细节,一边也担心所谓的red team issues(用户有预谋地操纵“数据生成过程”),是赤裸裸的自相矛盾啊。

 

3. Unforeseen side effects肯定是有的了

基于上述推理,GFT团队进一步修正了模型,以摆脱媒体报道的影响。

(1)为降低算法的sensitivity,GFT团队用“spike detectors”监测数据中inorganic检索词流量,并将其从模型中剔除。做法:The system receive time series data of the flu-related queries as input and validates whether the latest counts are within expectation, based on statistical variations from what we have seen in the past.

从2008年以来的数据得知:大多数由新闻报道引发的关注所导致的query spikes大约持续3-7天。这种情况导致,上述处理过程只能solve for short-term spikes,对在整个流感期间延续的high query volume无能为力。

(2)除此之外,作为对于外界普遍吐槽的GFT模型简单的回应,GFT 3.0也尝试了几个高大上的优化算法。

  • 比如Least Angle Regression(LARS)算法:

LARS是更适合高维数据(比如:变量数多,案例数少)的一种回归算法。在对多个自变量回归分析,得到1个因变量的预测的分析过程中,LARS算法可以确定哪些自变量参与回归,并得到这些自变量的系数。

  • 再比如LASSO和Elastic Net:

LASSO和Elastic Net均是对回归模型进行规范化(regularization)的方法。LASSO(Least Absolute Shrinkage and Selection Operator)的penalty function为

 

 

,而Elastic Net的求解方程为

 

 

 

。Penalty function为包含λ1(线性)和λ2(二次)的部分。

写这些并不是为了让每个读者都看懂甚至理解,而是为了给大家营造一种身临其境的感觉:GFT不再是那个国内本科学生毕业设计的非专业水平了。各个优化版本模型的预测效果可见下图。

从图中可以明显看出Current Model对CDC data的overestimate,但究竟哪个优化的模型效果最好却不显而易见。特此为每个模型的预测输出计算RMSE,Elastic Net的RMSE最小(1.22),即其效果最好。

 

 

写在最后的话

纵使笔者心中仍有千万次的问,作者的文章到此便戛然而止了。笔者很忧伤,却也毫无办法,只能开始总结。

从逻辑上讲,GFT的一切行为都是合理的。对于在每一处关键点上的选择,不排除其他alternatives的存在,但是不存在比GFT的选择明显更优的处理方式。

纵观整个GFT模型更新的过程,第一次更新向仅有季节性流感数据的旧模型添加非季节性流感的数据,自此,GFT双腿健全,可以稳健地丈量CDC数据。

CBS热播剧《BONES》中的starring actress有一句频繁出现的台词:I believe in patterns。还没想清楚的人不妨认真考虑一下了:GFT并不是literally“神来之笔”,它的诞生机制和工作原理决定了它的输出结果(对CDC数据的预测值)是依赖统计学习习得的“规律”,将现有值与未来某时间的“可能值”建立联系,而已。期待它给出一个确定的真实值这个愿望是不切实际的。

私以为,pattern比truth更加客观。每个人都可以把自己坚持的称作“真理”,并拒不接受说教。Pattern却不然。A出现10次中,有8次B也同时出现(贝叶斯[崇拜样]),这就是一个pattern。下次A出现时,笔者愿意投入成本做好B伴随出现的准备。也许有人会问,会不会A出现的10次中B也出现10次?To这样可爱的同学:当然会啦。只是这样的情况,如何确定B不是A的天然组成部分)?哈利波特偷偷去霍格莫德村,穿着隐形衣帮忙打架,不小心将头露了出来,马尔福少爷回学校打小报告时的推理过程是这样的:你的头出现在了那里,那么你的身体也一定在那里。See the beauty of uncertainty。换句话说,当pattern变成了“注定”的(definite),也便失了趣味性。【写这一段的目的是想传达:GFT是应用统计学习方法做出来的一个产品,各界都需要调整好对GFT的期望值。同时,也从逻辑上引出下一段。】

所以说GFT团队的vision也是极其精辟的。对GFT的第二次更新并没有纠结那些学者们不肯放手的检索词问题,可重复性问题——这些都不重要。GFT的核心矛盾必须是对统计学习方法的无上限的完善过程好么。按照大数据的处理思维,从原始数据中直接捞出来的(may not be perfect),但一定是best | available了。文章[3]点到为止地总结了入选模型的几个检索词的主题,以及数量和体量(占比)等,只不过是可视化不可见“模型”的一种手段而已。一些矫情的人类个体给点儿阳光就灿烂,嫌弃“描述性”的内容太少,各种,已经不单是避重就轻的迟钝,甚至是买椟还珠的愚蠢。

GFT的第二次更新考虑了多种优化模型的算法,反映了统计领域的state of art,不管从战略还是战术上看,都妙极,妙极。

 

关于副标题:都说是“旁观”了,顺便看一下得了。总的来说,原文是一篇虎头蛇尾的文章。前面铺垫的絮絮叨叨,像极了革命战士喜欢的千层底儿的鞋,结尾却只有戛然而止,断没有余音绕梁,徒留笔者独自在电脑前神伤好嘛。

 

 

相关文献:

[1] Butler D. When Google got flu wrong[J]. Nature, 2013, 494(7436): 155.

[2] Lazer D, Kennedy R, King G, et al. The Parable of Google Flu: Traps in Big Data Analysis[J]. Science, 2014, 343(6176): 1203-1205.

[3] Ginsberg J, Mohebbi M H, Patel R S, et al. Detecting influenza epidemics using search engine query data[J]. Nature, 2009, 457(7232): 1012-1014.

(1个打分, 平均:5.00 / 5)

GFT你这么diao,你的伪粉丝们造吗(2)

GFT 2.0: updated (2009)

Add unseasonal influenza to seasonal influenza

 

前一篇文章完整地记录了GFT诞生的全过程。

 

GFT 1.0发布于2008年11月,建模参考的CDC数据为2003-2008年3月(全部为季节性流感的统计数据),预测2008-2009年的疫情。GFT 1.0在线期间,有评论表示担心,GFT 1.0之所以能够准确的预测流感疫情(以CDC发布的ILI统计数据为准),很可能是由于用户在网上检索医疗信息的“群体行为”在时间上的一致(may be limited by the consistency of inline health-seeking behavior)。如果是这样,那么,在季节性流感和非季节性流感爆发期间的不同情境下,用户的检索行为是否仍能保持一致?是否会有不同的terminology规律?等。

Thus, an open question was whether GFT could provide accurate estimates of NON-SEASONAL FLU.

 

2009年爆发的H1N1为GFT提供了预测非季节性流感疫情的训练数据(The 2009 influenza virus A (H1N1) pandemic [pH1N1] provided the first opportunity to evaluate GFT during a non-seasonal influenza outbreak.)。

GFT 2.0发布于2009年9月24日,预测了2009年9月-12月的疫情。

 

2.0与1.0的methodology是相同的。本文依据参考文献[1],从模型所包含检索词的数量(number)和体量(volume)、模型对历史数据的拟合效果两个方面对比1.0与2.0两个版本的GFT。检视GFT 2.0的准确率,并从检索词的数量和体量(volume)变化窥探用户检索行为和terminology的变化。

 

一、构成两个模型的检索词的特点

(1)采纳的检索词数量和体量

l  GFT 2.0包括160个与流感活动有关的检索词,而1.0的版本中只有40个。

尽管2.0的版本使用的检索词数量将近是1.0版本的4倍,但是,GFT 2.0的检索词体量只有GFT 1.0的1/4因为GFT 2.0使用了更多不常见的检索词(due to the inclusion of less common queries than in the original model)。

l  两个模型有11个重合的检索词,占GFT 2.0体量的50%,却只有GFT 1.0的11%。

(2)内容

GFT 2.0包含的检索词直接与influenza有关,而非是与流感有关的病症(比如:influenza infection, such as “pnumonia”,拼写错误是故意为之,保持与检索词的原始形态一致):

a)         (流感引发的疾病)主题是influenza complication和symptoms of an influenza complication的检索词占GFT 1.0体量的48%,但是在GFT 1.0中只有17%;

b)         主题是general influenza symptoms和specific influenza symptoms(即与流感直接相关)在GFT 2.0中占69%,但在GFT 1.0中只有8%;

c)         在GFT 2.0中,包含flu的检索词有72%(个数38%),在GFT 1.0中只有14%(个数2%)。

 

将检索词按照主题汇总,比较每个主题的大小如截图Table 1。

 

文献来源:参考文献[1]

 

二、两个模型的预测效果对比

首先,将整个研究区间划分为4个时间段:

(1)阶段1:pre-H1N1 (2003年9月-2009年3月)

(2)阶段2:H1N1 overall (2009年3月-2009年12月)

(3)阶段3:Summer H1N1 (2009年3月-2009年8月)

(4)阶段4:and Winter H1N1 (2009年8月-2009年12月)

 

接着,对比两个模型的预测效果的参考指标,结果如截图Table 2:

(1)相关性 Pearson Correlation

(2)误差 RMSE

文献来源:参考文献[1]

 

结论:

1. 在4个阶段中,模型的估计值与ILI数据的相关性

在阶段1和阶段2,两个模型都与ILI数据高度相关;

在阶段3(H1N1流行期间前半段),GFT 1.0与ILI数据无关(0.290),而GFT 2.0与之非常相关(r = 0.945);

在阶段4(H1N1流行期间后半段),两个模型均与ILI数据高度相关,相关系数分别为(r = 0.916 and r = 0.985)。

 

2. 两个模型对ILI数据的描述程度

粗略地讲,在统计学中,用R2表示所建立模型对变量之间关系的描述了多少,取值在0-1之间,RMSE = 1- R2

所以,根据Table 2中的数据可知,GFT 1.0对ILI数据的描述能力比GFT 2.0差,在阶段2最差(GFT 2.0的RMSE是GFT 1.0的3倍多)。

 

3. 总体趋势

虽然,两个模型的估计值与ILI的数据均强相关,从Figure 1的2个图(尤其是A图)中还是可以明显看出拟合效果的差异。

两个模型都能够对2009年早期季节性流感期间的疫情做出准确的估计。在整个pre-pH1N1期间,2.0与ILI数据的相关性比1.0稍好(1.0: r = 0.906, RMSE = 0.006; 2.0: r = 0.942, RMSE = 0.005)。并且,2.0的预测值与4个ILI峰值一致(共出现6个峰值);而1.0只与3个峰值一致。

 

文献来源:参考文献[1]

 

三、H1N1期间的检索行为

通过前文的对比,可以得出,在整个时间段,两个模型的估计值与ILI数据均强相关,但GFT 2.0的效果略好于GFT 1.0。然而,在阶段3,也就是H1N1爆发期间的前半段,GFT 1.0的估计值与ILI数据不相关,而GFT 2.0强相关。也就是说,改进后的模型不仅能够拟合原有的ILI数据(季节性流感爆发的数据),也能够拟合新产生的数据(非季节性流感爆发期间的数据)。

同时,旧模型完全不能够拟合新产生的非季节性流感的数据,也说明,在季节性流感和非季节性流感两个阶段,数据中确实发生了变化。

 

如本文开头提到,主流的观点是认为是用户的信息检索行为发生了变化。

参考文献[1]对用户行为的探索是通过对构成模型的检索词的数量前后变化的比较进行的。

作者们观察到,在整个H1N1期间,GFT 1.0中检索词的数量比期望的要低(考虑之前得到的检索词数量与ILI数据之间的数量关系),导致其对ILI数据预测值偏低。为了检测这种变化对模型的影响,用每个主题的检索词数量和ILI数据建立模型。结果,这些模型几乎都低估了在H1N1期间的ILI数据。原文给出了2个例子,如Figure 2。

同样,在用地区数据进行的类似分析中,也表现出,GFT 1.0对实际值的预测偏低(与使用全国范围的数据得到的结果一致)。

 

Figure 3展示的是ILI数据和单个检索词构建的模型预测值,“symptoms of flu”, “symptoms of bronchitis”, and “symptoms of pneumonia”。在H1N1之前,这三个检索词能够很好的拟合ILI数据。在H1N1期间,“symptoms of flu”仍能很接近的拟合ILI数据,但是“symptoms of bronchitis”和“symptoms of pneumonia做出的估计已经明显的低于实际值,尤其是在H1N1爆发期间的后期。

 

文献来源:参考文献[1]

 

讨论:

从上面的过程中,我们可以得出,在季节性流感和非季节性流感爆发季节,用户检索医疗卫生信息所使用的检索词确实发生了变化(用户行为变化)。

然而,要准确地指出导致这种行为变化的原因是很困难的。作者列出了几个可能原因,解释GFT 1.0低估H1N1活跃度的原因。

1. 用户减少了使用与influenza complications such as bronchitis and pneumonia有关的检索词。这个主题的检索词在GFT 1.0中占据很大比例。

2. H1N1病毒出现于春夏的月份,与秋冬月份(季节性流感高发时期)不同。人们极有可能在冬天和夏天使用不同的检索词。

3. GFT建模使用的ILI数据,来自各地各类医疗卫生机构向CDC的报告,因此,CDC统计的数据可能跟ILI的真实情况有差。另外,ILI的数据估计的是因流感而到访门诊的病人在总人口中的比例,这个数据既有赖于实际的流感发病情况,也依赖患病者中实际去门诊的比例。后者的变化能显著影响ILI的数据以及GFT模型的估计值。(三个数据的转化关系见下图)

 

CDC实际统计到的ILI数据为:(上报的)门诊到访流感病人/总人口数,然而,它将“上报的门诊到访流感病例数”作为对“门诊到访流感病人数”估计。而GFT的社会使命是估计流感患病人数/总人口数。由此也可以看出,模型“与生俱来”的假设才是导致“预测不准”的根源。只是这种根源,有点宿命的不可改变的韵味。(即便GFT能够“准确”地预测出CDC统计的ILI数据,ILI数据又代表了什么?)

 

写在最后:

请牢记,除了每年更新一次GFT建模数据之外,GFT的Methodology到目前为止只更新过2次。本文记录了第一次,接下来会有一篇文章介绍第二次更新。

作为第一次更新,GFT补充了在非季节性流感爆发时的数据。从GFT 2.0与ILI数据的相关系数和RMSE来看,模型2.0对现实数据的拟合情况是很好的。So,until now,GFT已经prepared for everything。能想到GFT第二次更新了什么吗?敬请期待。

 

参考文献:

1. Cook S, Conrad C, Fowlkes A L, et al. Assessing Google flu trends performance in the United States during the 2009 influenza virus A (H1N1) pandemic[J]. PloS one, 2011, 6(8): e23610.

 

小吐槽:这篇文章在内容上的组织结构并不好(就更别说“巧妙”了),不知道是不是因为不是正式出版物所以标准降低。

(没有打分)

Google Flu Trends: Algorithm Dynamics

正文中的指代:

文章A:Lazer D, Kennedy R, King G, et al. The Parable of Google Flu: Traps in Big Data Analysis[J]. Science, 2014, 343(6176): 1203-1205.

文章B:Butler D. When Google got flu wrong[J]. Nature, 2013, 494(7436): 155.

文章C:Copeland P, et al. Google Disease Trends: an Update. International Society for Neglected Tropical Diseases. 2013. available at: http://patrickcopeland.org/papers/isntd.pdf

 

本文继续讨论文章A作者认为导致GFT出错的因素(two issues that contributed to GFT’s mistakes)之二:Algorithm Dynamics。

在系列(一)中简单提过,作者(在所有可能产生混淆的情况下,下文出现的“作者”均指文章A的作者,没有例外)所说的Algorithm Dynamics包括2个意思:1. Google的工程师为改善服务对算法做出改动;2. 用户使用行为的改变。作者认为,这两个因素致使GFT对流感趋势的反映不稳定。(At a minimum, it is quite likely that GFT was unstable reflection of the prevalence of the flu because of algorithm.)

 

在文章A发表之前,对GFT预测有偏最常见的解释是:在(前一个)流感期间,媒体的宣传报道引起更多本身没有生病的人进行与流感有关的检索,(The most common explanation for GFT’s error is a media-stoked panic last flu season.)导致对今年流感样病例的较高估计。

比如,在2013年初,GFT的预测值是实际值的2倍,文章B中写过,一些专家认为the problems may be due to widespread media coverage of this year’s severe US flu season, including the declaration of a public-health emergency by New York state last month. The press reports may have triggered many flu-related searches by people who were not ill.

文章C(第一作者Patrick Copeland,目前职位:Senior Engineering Director – Google)记录了针对GFT(以及Google Dengue Trends)在2012年表现出来的overestimating influenza-like illness (ILI)所做的改进。其作者在文章中提到:We have concluded that our algorithm for Flu and Dengue were susceptible to heightened media coverage.

 

然而文章A的作者认为:媒体报道导致用户群体行为模式的改变是可能的影响因素,却无法解释为什么GFT曾经在连续108个星期中有100个星期的预测值偏高。(Although this may have been a factor, it cannot explain why GFT has been missing high by wide margins for more than 2 years.)(GFT has missed high for 100 out of 108 weeks starting with August 2011.)如下图,参考线右侧为包括100个overestimate数据点的108个星期的数据。

他们认为可能性更大的原因是Google搜索算法的变动。(A more likely culprit is changes made by Google’s search algorithm itself.)并用blue team和red team来比喻来自两个方面的作用力。

注:”blue team”和”red team”在英语中义项较多,在此不做过多解释。

文献来源:文章A

 

1. “blue team” dynamics

– where the algorithm producing the data (and thus user utilization) has been modified by the service provider in accordance with their business model

也就是前面提到的Google主动修改算法。在文章A随附的supplementary materials中,从第10页开始图文并茂的展示了多个作者认为会导致GFT结果不准的Google对算法的改动。这里拣选作者在正文提及的供大家管窥。

案例1

2011年6月,也就在GFT开始持续高估ILI的前几个星期,Google新增了相关检索这一功能。比如,检索“flu”会返回流感诊断和治疗的推荐。作者认为,这导致了流感诊断和治疗检索次数的虚高,并进一步使得GFT的预测不准。(是的,没有提供“事实”,只有“推测”。案例2也是这样。)

案例2

2012年2月,Google推出Health Search Box服务:当用户检索某种症状时,会返回症状可能的诊断。作者尝试检索“runny nose and fever”,返回的结果中“flu”和“common cold”分别排在第一、二位(见下图)。作者由此推断,Health Search Box可能导致了2012-2013年间流感高发季节,GFT统计的 “cold vs flu”和“cold or flu”的搜索数量激增。(As the reader can see, the top two results are for the flu and the common cold. This seems a likely reason why searches like “cold vs flu” and “cold or flu” seem to spike up in the 2012-2013 flu season.)

文献来源:文章A的supplementary materials

或许作者也意识到,单纯罗列假设很难make a case,于是在另外的切入点提供了一个用户行为确实被改变的事实论据。

案例3

Google发布Health Search Box时,提供了一个演示案例,如下图。作者认为,这种情况相对罕见。

注:“这种情况”是指用户一次性输入检索词“abdominal pain on my right side” exactly。因为Google在为GFT建模时,统计的是一次完整的用户输入为基本单位,不对其做其内容任何处理。

文献来源:Improving health searches, because your health matters, Google; http://insidesearch.blogspot.com/2012/02/improving-health-searches-because-your.html,转引自文章A supplementary materials

而实际上,在Google发布公告前后,“abdominal pain on my right side”的检索次数(模式)真的有明显不同,见下图。

文献来源:Google Trends, www.google.com/trends/,转引自文献A supplementary materials,downloaded data available in replication materials.

 

结合三个案例来看,作者说的不无道理。(作者意欲证明,Google对检索服务的改进会影响用户检索模式,并进一步导致GFT模型失效。)但也未到言之凿凿的程度。

写过GRE Analytical Writing的同学应该很容易在上述推理中找到不止一个unstated assumptions,笔者出于写作方便随机总结若干如下:

1. 在案例3中确实能够看到“用户群体行为”的“突发性”变化,但并不意味着这种突发性也存在于案例1和案例2的过程中(待证明);

2. 在案例3中肉眼可见的“突发情况”的极端情况,无非是对“abdominal pain on my right side”的检索由0次增加至约100次。这种变动幅度,在以“某检索词被检索次数占同时期所有检索次数比例”为建模依据的GFT中,对最终结果会产生影响吗(同样待证明);

 

此外,Blue team issues并非Google独有。类似Twitter和Facebook都会频繁被重新设计。作者十分担忧blue team issues对科学实验的可重复性的影响(虽然他们这样担忧的依据也并不充分)。

 

2. “red team” dynamics

– occur when research subjects (in this case Web searchers) attempt to manipulate the data-generating process to meet their own goals, such as economic or political gain

也就是用户利用系统逻辑来达成自己的目的(在过程中可能会扭曲系统逻辑本来的目的)。作者认为这GFT暂时不存在这类问题,但需引起科研人员的注意。

 

小结:

原文:Search patterns are the result of thousands of decisions made by the company’s programmers in various subunits and by millions of consumers worldwide.这一点无需否认。但笔者始终认为,作者将search patterns的变化与GFT预测结果联系起来的推理证据不足。

 

反思:

写到这里,文章A的主体内容介绍完了。围绕文章A展开讨论GFT的系列文章亦到此为止,特此告知。

笔者很消沉。原来,把“一本书”读厚再读薄之后,并没有满溢的成就感,反而是铺天盖地的空虚。

GFT的模型是不完美的,然而这个世界上存在“完美”吗?(据说在英语文化中,perfect一词连比较级的派生含义都没有。)出于对大数据应用的热爱,对GFT自然是爱屋及乌。最初看到这样一篇发表在Science上,为GFT提供改善建议的文章,笔者兴奋坏了。果壳网的简单报道(http://www.guokr.com/article/438117/)对(不读论文原文的)中文读者远远不够,Time.com(http://time.com/23782/google-flu-trends-big-data-problems/)上的内容太通俗,只简单改写了论文内容,以便于更一般的读者接受。然而笔者这一个系列的文章写下来,像是激情过后(It doesn’t have to be sexual.-_-|||。如果是sex过程,涉及到的激素就远不止肾上腺素啦:P),肾上腺素恢复正常水平,空落落——连被子都抱不紧。作者的points都是老生常谈(大言不惭地说,所有的统计分析都需要纠结这些问题)。退一步讲,即便是旧瓶装新酒,作者也没有给出solid evidence,证明GFT存在这些常见统计分析问题,并且,就是这些统计分析过程降低了GFT预测的准确程度。

 

另外,文章A的supplementary materials还给出了一些实证研究的结果,证明结合使用“大数据”与“小数据”,对ILI的预测准确程度高于仅使用单一类型数据所做的预测结果。对此,笔者的看法是这样的。

笔者(还是那个“大数据婊”)在系列(二)中提到过,GFT的伟大之处在于“即时”,甚至“超前”。GFT比CDC提前发布预测结果的2个星期时间,人类有机会去挽救,死亡或痛苦。笔者认为,在“实时”甚至“超前”面前,准确率必须退居次要位置。更何况GFT到目前为止的预测结果在变化方向上无差错。作者纠结的只是数值大小。

正因大数据的这个特性是传统数据所不具备的,所以将两者综合使用会损失掉大数据的这一优势。也正因如此,笔者同意GFT需不断完善其算法,提高准确率,但“提前性”不容compromise。

“I’m in charge of flu surveillance in the United States and I look at Google Flu Trends and Flu Near You all the time, in addition to looking at US-supported surveillance systems,” says Finelli. “I want to see what’s happening and if there is something that we are missing, or whether there is a signal represented somewhat differently in one of these other systems that I could learn from.”(from文章2)

——笔者看来,对于非大数据应用研发人员,这种心态就很健康。

(没有打分)