如何与高权重网站进行互动

Intetix Foundation（英明泰思基金会）由从事数据科学、非营利组织和公共政策研究的中国学者发起成立，致力于通过数据科学改善人类社会和天然环境。通过联络、动员中美最顶尖的数据科学家和社会科学家，以及分布在全球的志愿者，我们创造性地践行着我们的使命：为夸姣糊口洞见数据价值。

原作者: Robert Chang

2015年6月17日是我在Twitter工作两周年的纪念日。回想起来，两年间，数据科学在Twitter的应用方式和范围发生了很大变化：

·   工具的智能化上，Pig已经由期了，现在的数据流水线都是用Scalding(建立在串联之上的Scala领域特定语言，便于具体描述Hadoop MapReduce任务——译者注)编译的。

·   组织结构上，数据科学家和产品经理、工程师的工作环环相嵌，合作之紧密亲密史无前例。

以上只是众多改变中的一小部门。拿我来说，我的研究领域最近从Growth延伸到PIE (Product产品, Instrumentation实施, and Experimentation实验) ，工作是研究Twitter自家开始的A/B测试平台上的统计学方法。

在Twitter工作真的很刺激。在这里，我能直接观察学习一个大型科技公司是如何使用数据与数据科学来创造竞争上风的。

与此同时，人们对于数据科学的需求与渴想在不断攀升。

“大数据就像青春期的性：每个人都在讨论，但鲜有人在行，大家觉得所有人都在做，所以大家都声称自己在做。”——Dan Ariely（行为经济学大牛，著有《怪诞行为学》—译者注）

关于如何成为一名数据科学家的讨论有良多良多。尽管这些探讨信息量都很大（我便是众多受益者之一），人们老是倾向于过分夸大技术、工具和技巧的重要性。我认为，对于那些有志成为数据科学家的人来说，充分了解数据科学家的实战操纵是怎样一番体验，是平等重要的。

因此，在我在Twitter工作两周年之际，我但愿以这次回顾为契机来分享我的个人经历，同时但愿数据科学行业的同事们也能加入到这个行列中！

来Twitter之前，我认为数据科学家都是“珍稀动物”——做数学/统计/计算机/机器学习/ 算法/数据可视化等等出身。另外，写作技巧和沟通能力与专业技能平等重要。进一步讲，在执行任务的过程中，理清项目环节中的轻重缓急、领导团队、治理项目的能力是最最重要的。除此以外，你还应该向大众传播一下由数据驱动的文化是多么夸姣。Good luck!

在Twitter工作了几个月后，我发现“珍稀动物”们确实存在，但对于大多数努力跻身于“珍稀动物”行列的数据工作者来说，一下子把握那么多学科是不现实也不可能的。也就是说，几乎所有和数据沾边的东西都和“数据科学”这个概念是相关的。那时，仍是菜鸟一枚的我，寻找自己定位的时候感觉怯生生的。

久而久之，我意识到数据科学家可以被分为对立的两类。这种分类有些过于简朴粗暴，却十足精准。Quora用户Michael Hochster将我想表达的这种分类方法漂亮地总结如下：

A型数据科学家：A，即Analysis（分析）。分析型数据科学家主要致力于寻找数据背后的含义，或是以一种静态的方式使用这些数据。分析型数据科学家类似于统计学家（他们很可能本来就是搞统计的），但他们还懂得统计课程里不涉及的与数据工作相关的详细的实际操纵，好比数据清理、大型数据集、数据可视化、对某一领域的深度了解和如何用数据讲一个漂亮的故事，等等。

B型数据科学家：B，即Building（构建）。构建型数据科学家和分析型分局科学家的共同点是都有统计学背景，但前者仍是编程高手，抑或是练习有素的软件工程师。构建型数据科学家的关注点是把数据“投入出产”。他们建立的模型通常以“推荐”的方式与用户互动，好比产品、你可能熟悉的人、广告、片子、搜索结果等。

真但愿自己早些知道这两种数据科学家的分别。假如你想成为一名数据科学家，注意这种分别——这对你选择职业道路以及做取舍长短常有匡助的。

个人而言，我是学数学、操纵研究和统计出身的。我以为我是一名分析型数据科学家，但我非常享受用到编程设计的构建型项目！

在初期创业公司、成长期创业公司和具有一定规模的公司担任数据科学家，工作异同有哪些？

技术型人才找工作时往往要考虑，是去大企业任职，仍是加入小型企业。固然关于这种选择的讨论有良多，但针对数据科学家的讨论就很少了——即，企业的发展阶段与规模各有不同，那么数据科学家在这些企业里扮演的角色会有什么不同呢？

处于不同发展阶段的企业所产生的数据的速度、种类和量级是不同的。对于一个正在探索产品定位的创业公司，他们多半用不到Hadloop这样的软件，由于这种公司并没有那么多数据可处理。成长性创业公司通常会产生更密集的数据，但对他们来讲，PostgreSQL和Vertica这样的数据库治理系统就足够了。但是像Twitter这种规模的公司，就必需使用Hadoop和MapReduce来处理数据了。

我在Twitter学到了重要的一课——数据科学家从数据中提炼、创造价值的能力与企业数据平台的成熟度是高度相关的。假如你想保证达到企业和个人之间双向选择的最优化，做到以下是机智而枢纽的：搞清自己到底想做什么类型的数据科学工作，然后下功夫衡量这个企业的体系体例举措措施能不能帮你实现你的目标。

发展初期的创业公司：数据分析主要致力于执行记实(log)，建立ETL过程（Extract-Transform-Load 的缩写，用来描述将数据从来源端经由抽取（extract）、转换（transform）、加载（load）至目的真个过程——译者注），模拟数据，设计一个框架来追踪并储存数据。这种公司的工作重点在于打好分析数据的基础，而不是分析数据本身。

发展中期的创业公司：企业在成长，相应地，企业的数据也会增长。数据平台需要适应增长的数据，但因为数据的“地基”已经建好了，公司会天然地从单纯收集数据转向从数据中形成观点、提炼价值。除非这个企业本来对数据的战略用途就长短常规的，大多数分析型工作主要涉及定义枢纽绩效指标、促进业绩增长、寻找增长的下个契机。

达到一定规模的公司：企业规模增长，数据规模会随着增长。这时，企业需要利用数据创造或保持它的竞争上风，好比：搜索结果要更加优化、推荐内容的相关性要更高、物流与企业运作要更加高效。机器学习工程师、企业运营优化专家、实验设计者之类的专家能够有效匡助企业实现以上各种诉求。

我入职的时候，Twitter的数据平台已经非常成熟了，基础举措措施也非常不乱。数据仓库干净而不乱，ETL过程可以日常性、毫无压力地处理无数MapReduce任务。最重要的是，在这里，有一群优秀的数据科学家们致力于数据平台、产品的洞悉、Growth、实验、检索/相关性以及许很多多其他方面的工作。

我是第一个专攻Growth的数据科学家。告诉你一个真实的故事：产品部分、工程部分和数据科学部分花了好几个月才共同熟悉到数据科学在Growth中扮演着至关重要的角色。根据与产品部分紧密亲密合作的经历，我的工作内容可以分为以下四大类：

产品洞见

数据流水线

A/B测试

建模

下面我会分别我做这几类工作的经历与心得。    

产品洞见

在消费者技术公司做数据科学有个独特之处：我们可以利用数据来理解并推测用户的意见和偏好。当用户与产品互动时，我们能记实到有价值的数据与元数据（描述其他数据并提供相关信息的数据集），把它们储存起来以便日后分析。

这个过程叫做“记实日志”或“丈量”，而且在不断进级。数据科学家们常常会由于数据不正常、数据不匹配或数据缺失而难以开展某一项分析。这时候，和工程师建立良好的工作关系就显得很重要了：数据科学家可以匡助工程师识别系统中的bug和意外行为。反过来，工程师可以帮数据科学家缩小数据断层，让数据变得更丰硕、相关性更强、更精确。

以下是我在Twitter做的几个典型的产品分析：

推送动静分析——多少用户合用推送动静？这个比例是用户组维度的吗？仍是客户端维度？各种类型的推送动静点击率是多少？

短信投放率——如何计算不同移动运营商下Twitter的短信投放率？新兴国家用户的投放率更低吗？如何进步这一比率呢？

多个账户——为什么某些国家的用户拥有多个Twitter号的比例更高？人们使用多个Twitter号的念头是什么？

详细分析形式多种多样——对简朴的数据行为（推送分析）给出直白的解释；创造新生（却重要的）业务指标的计算方法；最后，你可能会负责深入分析用户行为（小号）。

通过产品分析进而形成洞见是一个迭代过程。想做到这一点，你需要质疑以上题目的谜底，理解产品所处的业务环境，找到合适的数据集来解决题目。久而久之，你将能够纯熟地定位你需要的那组数据并对其含义了如指掌。你将能够正确地估算做一项分析需要多长时间。更重要的是，你会逐渐从被动转为主动，提出新奇有趣的分析角度——产品负责人可能都没想到，由于他们根本不知道某组数据的存在，抑或是不知道截然不同的数据源可以以某种方式互补结合。

涉及的技能：

?  记实日志和丈量。识别数据断层。与工程师建立良好的工作关系。

?  定位、识别并使用相关数据集。

?  理解类型的分析，正确估算各种分析的耗时或难易程度。

?  玩转查询语言。能用R或Python做典型的数据处理。

数据流水线

固然分析型数据科学家不怎么写直接面临用户的代码，为了处理数据流水线，我们仍是会常常向代码库贡献一些代码。

假如你对Unix公司的Pipe（一个运行一系列指令的操纵）有所耳闻，数据流水线就很好理解了——不外是一系列操纵，整合在一起以后能够自动捕获数据，轮回地处理并整合数据。

我在Twitter以前的公司任职时，所做的分析工作大多是Ad-Hoc(Ad-Hoc结构是一种省去了无线中介设备AP而搭建起来的对等网络结构)。我一般只在自己的电脑上跑程序，也就跑个一两次、两三次。几乎没有人来检查我的代码写的怎么样；运行的时候也不会控制代码的版本。写数据流水线的时候，一系列题目就泛起了：依靠关系治理、计划铺排、资源配置、监测、错误讲演，甚至还有警报。

下面是创建数据流水间的典型过程示例：

首先，你熟悉到，轮回性地出产数据集将会是一件功德无量的事。

确认了这个需求以后，你先设计出终极产品，例如设计输出数据集的数据架构。

根据数据所在环境用Pig, Scalding或SQL写代码。

把代码提交至code review（代码评审），预备改代码。也许你的贸易逻辑有题目，或者你的代码没能做到速度与效率的最优化。

也许你需要测试程序，空运行（不带数据跑代码——译者注）一下，看看代码是否运行正常。

整合代码。把代码配置好，铺排好每一个事项。

设置监控、错误讲演、警报机制，以防代码运行犯错。

数据流水线显然比临时性分析复杂得多，但数据流水线的好处是，它可以自动运转，出产出来的数据可以被仪表板所利用，这样更多的用户就可以使用你的数据或结果。更重要（但往往被忽视）的一点是，简历数据流水线的过程是个软件工程实操的绝佳机会。你可认为日后建立专业化流水线打好基础，好比机器学习模型（本文最后一部门会对此进行具体说明）、A/B测试平台。

涉及的技能：

?  版本控制。一般来讲，最常用的工具是Git（软件开发时用到的源代码治理系统——译者注）。

?  学会做code review，迅速地给出反馈。

?  程序犯错时，知道该怎么测试、空运行、找bug。

?  把握依靠治理、计划铺排、资源配置、监测、错误讲演，以及给出提示信息。

A/B测试

此时此刻，你用的Twitter APP很有可能和我的有所不同，很可能你有的功能我没有。从内部工作职员的角度讲，Twitter的用户非常多，因此Twitter可以抽出一小部门流量来体验尚未面世的新功能，以便将这部门实验组用户对新功能的反馈情况与控制组用户（即未体验新功能的用户——译者注）作对比——这就是A/B测试，即用来测试变量A与变量B哪个效果更好。

个人以为，A/B测试是在大型消费者技术公司工作的特殊福利。数据科学家可以通过使用真实随机样本的控制实验来研究因果关系（用观测值是很难做到这一点的）。在Twitter，“几乎天天都要做至少一个实验——Alex Roetter，高级工程师”。A/B测试已经深深烙在Twitter的数据科学家心里，也是产品开发环节不可或缺的一环。

典型的A/B测试过程是这样的：收集样本-用户分组-开始测试-衡量结果-对比分析。听上去很简朴对吧？然而，我以为A/B测试是最被低估、相称棘手的分析工作，而且学校一般不教你这种技能。为了说明这一点，让我们往返顾一下一上五个步骤以及实战过程中的常见题目：

?  收集数据：样本量需要多少？每组应该分配多少用户？能不能保证明验效果足够显著？

?  用户分组：哪些用户合用于这个测试？应该在程序的哪个阶段开始分组并对用户展示测试的新功能？这种分组是否会造成数据稀释（好比某些测试组的用户在使用过程中根本用不到我们测试的新功能）？

?  开始测试：有没有其他项目组和我们用统一批样本做测试？假如和他们发生样本冲突，如何确保我们的数据没有被污染？

?  衡量结果：实验结果的预期是什么？衡量实验成功与否的尺度是什么？衡量尺度可追踪吗？如何追踪？需要额外记实哪些信息？

?  对比分析：如果在线用户激增，这是来自其他变量的干扰吗？如何判定结果是否统计明显？假如确实是统计明显的，实际上用户组之间的差别真的显著吗？

处理好以上题目需要很强的统计学功底。即使你自己设计实验的时候思维足够严谨，你的队友也有可能掉链子。产品经理会比较喜欢对数据先睹为快，或者挑几个自己想要的结果（这是人的天性）。工程师可能会健忘记实数据科学家用来计算成败指标的某些数据，或者实验代码“姿势”分歧错误，造成偏误。

对于数据科学家来说，故意唱唱反调、匡助团队完善实验是极其重要的，由于铺张在运行设计不公道的测试上的时间会一去不复返。更有甚者，根据不良数据做出的不良决议计划会造成非常严峻的后果。

涉及的技能：

?  假设检修：统计检修、p值、统计明显、统计力、效应值、多重检修

?  实验缺陷：滞后效应、指标选择、数据稀释、分组异常

猜测模型与机器学习

我在Twitter做的第一个大型项目是对现有的邮箱通知产品增设一套繁琐的规则，进而减少对用户的骚扰。固然这一举措十分圣母，我们实在也清晰邮件通知是留住用户的最有效的手段之一（我们曾对此进行试验，验证了这一点），所以找到一个合适的度是枢纽。

针对这个枢纽点，我旋即决定研究触发性邮件——当用户在Twitter上有流动时，这种邮件会像雪片一样飞进用户的邮箱。作为一个正在努力证实自己的价值的野心勃勃的新晋数据科学家，我决定建立一个高端机器学习模型来猜测用户水平上的邮件点击率。我用Pig收集了一大堆用户特征，建立了随机森林模型来猜测邮件点击率。我的思路是，假如一个用户的点击率长期保持在很低的值，我们就可以安心撤销该用户的触发性邮件。

其他的都好说，只有一个题目——我的程序都是用本地电脑上的R写的。别人承认我很努力，但他们无法利用我的模型来创造价值，由于我的没有被产品化，公司的组织架构无法和我的局部模型交互。多么惨痛的教训！

一年后，我得到了与两名来自Growth的数据科学家一起建立顾客流失猜测模型的宝贵机会。这一次，有了足够的建立数据流水线的经验，我知道建立机器学习流水线实在是类似的——在练习阶段，我们可以用Python在线下做轮回模型更新；在猜测部门，我们可以逐日收集用户特征，用猜测公式（大多数只是“点产品”）天生每个用户的流失率评分。

我们花了几个星期建起来流水线，确认其具有良好的猜测能力，全面部署，将用户流失率评分输入到Vertica、Hadoop文件分散系统，以及我们的内部键值存储“Manhattan”。我们把这些scores涉及的非常便于分析师、数据科学家和工程师查询。这一点大大匡助我们宣传并促进这个模型的使用。这是我在建造出产模型时学到的最重要的一课。

我故意没有提及建立机器学习模型的步骤——建立题目框架，定义标签，手机练习数据，设计特征，建立样品，客观地测试模型的可行性。这些步骤显然都很重要，但我以为这些步骤前人都已经讲得很明白了，无需我来提供相关建议。

我觉得大多数优秀的数据科学家，特别是分析型数据科学家，都不存在不会建模的题目。他们的困惑在于，知道该怎么建模，但不清晰怎么把自己的模型融入到整体生态环境里。我对此的建议是，多和经验丰硕的构建型数据科学家交流，搞清你需要把握什么技能，潜心修炼，届时天然能得心应手地接管相关项目。 请用许我引用以下这段话来为本章画上句号：

“机器学习并不等同于R编程。机器学习是以数学为根基，用代码表达，整合到软件里的。你需要把握电脑工程师的技能，学着写可读、可重复使用的代码：别人读你的代码的次数将远远多于你自己，所以你要写得能让别人看懂。”——Ian Wong，于哥伦比亚大学数据科学课程客座讲座

说得非常好。

这里所涉及的技能：

? 模式识别：识别可以用模型解决的题目。

? 建模和机器学习的基本功：探索式数据分析、简历特征、特征选择、模型选择、练习/验证/测试、模型评估

? 出产化：把握上文提到和数据流水线相关的一切知识。建立索引标志以便他人查询。

一些感想

数据科学家的工作确实非常令人高兴，那种突然窥到天机的高兴感堪比肾上腺素爆发。从零开始构建数据管道和机器学习模型会令你成就感满满，做A/B测试时，那种翻手为云覆手为雨的上帝姿态也非常有乐趣。数据科学家这条路有苦又累，沿途九九八十一难，但智慧努力的人会迅速克服的。

任重而道远，同道仍需努力。Good luck各位，更为重要的是享受这其中的乐趣！