在twitter搞数据科学是怎样一种体验？

摘要：回顾两年来的心路历程，样本量N=1

原文：Doing Data Science at Twitter

原作者: Robert Chang

引子

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

· 许多Twitter的非机器学习主导的核心产品中，机器学习的比重正在不断增加（例如“While you were away”功能——Twitter把你下线时可能错过的头条推文推送到你的个人首页）。

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

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

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

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

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

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

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

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

分析型数据科学家v.s.构建型数据科学家

来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各位，更为重要的是享受这其中的乐趣！

来源：Intetix

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