原标题：在Twitter做数据科学 　　

　　

　　作者：罗伯特常 　　

　　

　　翻译：孙涛 　　

　　

　　校对：苏 　　

　　

　　这篇文章的长度是6000字.建议阅读12分钟. 　　

　　

　　从已经在Twitter工作了两年的Robert Chang写的这篇文章中，你不仅可以一窥Twitter整个产品链的构成，还可以了解数据科学如何在各种类型的公司中发挥作用。 　　

　　

　　 　　

　　

　　动机 　　

　　

　　2015年6月17日，我在Twitter工作了两年(https://twitter.com/search？q=#twitterversarysrc=typd).回顾过去，Twitter的数据科学发生了许多变化： 　　

　　

　　Twitter的许多核心产品最初都不是基于机器学习的，但现在机器学习在其中发挥着越来越重要的作用(例如，当你不在时，我们会为你打掩护)(https://blog.twitter.com/official/en _ us/a/2015/while-you-wave-0 . html) 　　

　　

　　在工具方面，我们放弃了猪语言，使用https://github.com/twitter/scalding来编写所有新的数据管道。滚烫是基于层叠的Scala DSL，很容易定义Hadoop MapReduce任务。 　　

　　

　　一步一步来，我们选择了嵌入式模型，因为数据科学家可以与产品和工程团队更紧密地合作。 　　

　　

　　这些只是众多变化中的一小部分。我个人的工作领域最近从增长部扩展到了PIE部(产品、仪器仪表和实验)，研究我们独立的A/B测试平台的统计方法。 　　

　　

　　在Twitter工作令人兴奋，因为我可以观察和学习大型技术公司如何使用数据和数据科学创造竞争优势的第一手资料。 　　

　　

　　同时也越来越强烈的想学习数据科学。 　　

　　

　　“大数据就像青少年性行为：大家都在谈论，却没人知道怎么搞。人人以为别人都在搞，所以自己也宣称正在搞”-丹艾瑞里 　　

　　

　　已经有无数的讨论(http://www.datatau.com/；https://www.quora.com/topic/Data-Science)围绕如何成为一名数据科学家展开。这些讨论非常有益，许多人受益，我也是其中之一。但是讨论者过于强调技术、工具和技能。而且我觉得对于充满斗志的数据科学家来说，了解实战中的工作内容和前景同样重要。 　　

　　

　　为此我在推特上留下了我的两周年印记(这篇文章)。我想用这篇文章分享一下我的个人经验，希望同行们能借鉴我的经验。 　　

　　

　　A类数据科学家v.s. B类数据科学家 　　

　　

　　在加入Twitter之前，我印象中的数据科学家应该是全才，从数学/Stat(数据统计分析软件)，到cs(客户端/服务器)/ML(机器学习)/算法，再到data viz(数据可视化)。除了专业技能，写作和沟通能力同样重要。此外，对项目进行优化、指导和管理对项目的后期实施非常重要。哦，对了，你要推广数据导向的文化。无论如何，祝你好运！ 　　

　　

　　入职几个月后，我明白了一件事。虽然多面手确实存在，也有无数人在不断努力成为多面手，但是一下子满足以上所有要求是不现实的。几乎所有与数据相关的东西都离不开数据科学。作为新人，我怕找不到地方。 　　

　　

　　渐渐地，我意识到数据科学家之间是有明确分类的。当时我还不能理解的这么透彻，直到后来迈克尔霍赫斯特(https://www . quora . com/profile/Michael-hoch ster)在Quora上的回答让我不知所措。他巧妙地总结道： 　　

　　

　　A类数据科学家：代表分析。这类科学家主要侧重于用统计方法来理解和处理数据。他们类似于统计学家(某种程度上)，但他们也知道数据处理的实际细节，这些细节不会包括在统计教学大纲中，如数据清洗，处理大型数据库的方法，可视化，特定领域的深入知识，数据相关的写作等。 　　

　　

　　B类数据科学家：代表建筑。这类科学家拥有和A类数据科学家一样的统计背景知识，但他们是优秀的编码员，甚至是训练有素的软件工程师。B类数据科学家主要专注于将数据应用于生产。他们建立模型与用户互动，经常推荐产品、他们可能认识的人、广告、电影和搜索结果。 　　

　　

　　我希望我早点知道这件事。事实上，作为一名有抱负的数据科学家，在进行职业规划时，你必须记住数据工程师之间的这种差异。 　　

说到自己，我专业背景是数学、运筹学和统计学。我认为自己是A类数据科学家，但是我也很欣赏B类和工程更加关联的项目。

　　

初创型公司、成长型公司和具有一定规模的公司中的数据科学

　　

在找科技类工作时最普遍的一个选择就是该选择大型公司还是小型公司（https://medium.com/the-year-of-the-looking-glass/start-ups-versus-big-companies-f275800e78e5）。关于这个话题已经有很多不错的探讨，然而专门涉及数据科学的信息少之又少。问题也就是说，在依赖于公司阶段和规模的情况下，数据科学的角色会如何变化。

　　

不同阶段的公司产生数据的速度、种类和数据量是不同的。一家着眼于让产品和市场匹配的初创型公司可能不需要Hadoop，因为没有那么多需要处理的数据。成长型公司和数据关系更加紧密，但可能使用PostgreSQL （https://www.postgresql.org/）或者Vertica就已经绰绰有余了。但像Twitter这类大公司如果不用Hadoop和Map-Reduce框架就不能高效处理所有数据。

　　

在Twitter我理解最深的一点就是数据科学家从数据中获取价值的能力和所在公司数据平台的完善度息息相关。你得想明白以后想成为哪类数据科学家，也得评估下公司是否支持你的目标。这不仅很明智，而且对确保上述相关性的合适正确也非常重要。

　　

初创型公司：主要的分析工作聚焦于日志记录、ETL程序建立、数据建模和模型设计，从而来跟踪和储存数据。目标则是关注于分析基础建立而不是分析行为本身。

　　

成长型公司：因为公司在成长，所以数据量也可能在增加。数据平台因此需要调整，但在已有的分析基础上，会有一个到洞察的自然过渡。除非公司本意是为了策略差异化而运用数据科学（http://multithreaded.stitchfix.com/blog/2015/03/31/advice-for-data-scientists/），不然很多分析工作都是在围绕制定KPI、推动增长和寻找下一个增长点。

　　

具有一定规模的公司：当公司形成规模了，数据方面也会形成规模。公司需要使用数据来产生新优势或维持既有优势。例如，搜索结果需要优化，建议需要更加关联，物流和运作需要更高效――在这个时间段和工作环节中，像机器学习工程师、优化专家、体验设计师等专业人士都会扮演着重要角色。

　　

我加入Twitter的时候，Twitter已经拥有非常成熟的数据平台和稳定的基础设施。仓库干净可靠，ETL程序每天能轻松处理成百上千的Map-Reduce任务。更重要的是，我们有一批才华卓越的数据科学家，潜心研究数据平台、产品洞察、增长、实验、搜索/相关和其他聚焦领域。

　　

我的历程

　　

我是当时第一个投身增长部的数据科学家。而且事实上，把产品、工程学和数据科学融合在一起就花费了好几个月，才最终让数据科学家在整个过程中扮演着至关重要的角色。基于我和产品团队紧密合作的经验，我把我的职责分成四个方面：

　　

产品洞察

　　

数据管道

　　

实验（A/B测试）

　　

建模

　　

我将介绍在这四个方面我的体验和学习。

　　

　　

1. 产品洞察

　　

在消费者导向科技公司工作的独特之一就是我们可以利用数据来理解和推测顾客的心声和偏好。当用户和产品互动时，我们会记录有用信息，存储下来用于后期分析。

　　

这个过程称作日志记录或者仪表化，而且内容一直在变化。数据科学家经常发现某个分析异常困难，因为数据要么变形了，要么就是不合适或者缺失了。因此，数据科学家和工程师建立良好的合作关系非常重要，因为数据科学家能够帮助工程师确认bug或系统中非计划行为。反过来，工程师也能够帮助数据科学家解决“数据缺陷”问题，让数据更饱满、更相关和更准确。

　　

下面是我在Twitter的几个产品关联分析的例子：

　　

推送通知分析――多少用户可以享受推送通知功能？遍布用户端？还是客户端？各种推送通知的点击率如何？

　　

短信发送率――如何计算Twitter依靠不同运营商的短信发送率？我们在新兴国家的发送率更低么？如何提升呢？

　　

多个账号――为什么在某些国家一人拥有多个账号的情况更多见？是什么驱使了人们去开好几个账号？

　　

分析可从多层面入手――有时你只需要根据简单的数据来提供直接的答案（推送通知分析的例子），有时你得想出一些新方法来计算新颖重要的运算标准（短信发送率的例子），最终你可能得深入理解用户行为（多个账号）。

　　

通过分析产品来做洞察是一个反反复复的过程。它需要你不断质疑提出的问题，理解任务环境，做出正确数据库来回答问题。随着时间的推移，你就会成为数据方面的大师，理解数据的真实含义。你能更加准确的评估完成一个分析需要多长时间。更重要的是，你会慢慢地从一个被动的状态转变成主动积极的状态，开始推荐一些领导们没想到的有趣分析。因为这些领导们不知道数据在那些环节有这么重要的作用，也不知道迥然不同的数据源可以互补并以一种特殊的方式来合并。

　　

用到的技能：

　　

日志记录和仪表化。识别数据缺陷。和工程师建立良好关系。

　　

操控、识别和使用数据库的能力。

　　

理解不同类型的分析。更准确的判断分析的难度和所需时间。

　　

知道你的查询语言。使用R或者Python的经典数据清理技巧。

　　

　　

2. 数据管道

　　

尽管A类数据科学家可能不编写直接面对客户的代码，但令人惊讶的是，他们却经常把代码存进代码库里，用于数据管道处理。

　　

你如果知道Unix中管道符号“|”是用来优化一系列命令的执行的，那么你也会知道数据管道也很简单，就是组合在一起的一系列运算，可帮助我们反复自动获取、清理和整合数据。

　　

加入Twitter之前，我的分析工作大部分都是临时性的。代码在我的电脑上运行一两次，很少复查，不受监控。而现在数据管道诞生了，一系列新的问题又出现了，例如依赖性管理、进程调度、资源分配、监督、错误反馈和警告发送。

　　

下面是创建数据管道的典型过程：

　　

STEP1:得意识到若能反复产生数据库，那么世界会得到改善。

　　

STEP2: 确定需求后，从设计最终产品入手，例如设计输出数据库的数据模型。

　　

STEP3:编写代码，可以用Pig、Scalding或者SQL，这个取决于数据存放形式。

　　

STEP4:提交代码来做代码评审。收到反馈后可做一些额外调整，因为要么你的任务逻辑可能是错的，要么你的代码在速度和效率上可能不是最优。

　　

STEP5:实施空运行来测试一切是否如期运行。

　　

STEP6:合并代码到master上。部署代码并安排任务。

　　

STEP7:创建监督、错误报告和警告提示等功能以防任何错误。

　　

很显然，数据管道比临时性分析要更加复杂，但优点就是任务可以自行运行，产生的数据可以启动dashboard，从而分享给其他用户。更重要的也是容易忽略的一点，就是这是一个很好的学习过程。你接受了工程方面最好的训练，打下了基础，说不定以后你就需要建立特定管道，例如机器学习模型（本文最后部分我会讨论）和A/B测试平台。

　　

用到的技巧：

　　

控制版本，目前最常用的软件是Git

　　

学会做代码评审并高效提供反馈

　　

当任务失败时知道如何测试、空运行和修正代码

　　

依赖性管理、任务安排、资源分配、监督、错误报告和警告发送。

　　

　　

3. 实验（A/B测试）

　　

此时此刻，你正在使用的Twitter App可能和我用的会有微妙的不同。你拥有的一些功能特征可能我根本看不见。因为Twitter有很多用户，所以后台会让一小部分用户先体验一些还未公布的新功能，来观察分析这些特定用户的反应，并和那些不享受新功能的用户进行比较。这就是A/B测试，用来测试哪种情况更好。

　　

个人认为A/B测试是在大型消费者导向型科技公司工作的特别福利之一。作为一个数据科学家，你得通过运行随机、可控的实验来建立因果关联（使用观察数据真的很难做到这一点）。在Twitter，“没有一天不在运行实验”――工程副总裁AlexRoetter说到。A/B测试已扎根于我们的DNA和产品发展周期中。

　　

做A/B测试的典型过程是：采集样本->分配bucket->开始处理->测量结果->对比分析。听起来很简单？恰恰相反，我认为A/B测试是最被低估和最需要技巧的分析工作。这些技巧在学校是学不到的。为了阐述我的观点，我们再来看看上面五个步骤和一些实际可能遇到的问题：

　　

采集样本――我们需要多少样本？每个bucket得有多少用户？我们如何确保实验有说服力？

　　

分配Bucket――哪些用户可以参加实验？代码中从哪儿开始放置bucket并开始显示处理结果？Bucket的放置会导致数据稀释么（例如有些用户虽然享受额外功能却从未发现）？

　　

开始处理――是否有其他团队也在努力攻克app中的同样“领地”？如何解决实验冲突？又如何确保数据不受污染？

　　

测量结果――实验假设是什么？实验的成功标准是什么？我们可以追踪么？又怎么追踪？我们需要额外做记录么？

　　

对比分析――假设我们发现已登陆用户使用“#”的频率大幅度增加，这是信息噪音导致的么？我们如何确定结果具有统计学显著性？就算有统计学显著性，那有实际显著性么？

　　

若想解决上述问题，得精通统计学。即使你在设计实验的时候非常严格，保不准别人拖后腿。项目经理可能会忍不住过早地读取数据或者只挑选想要的结果（这就是人性）。工程师可能会忘记记录用来计算成功标准的特别信息。也可能实验代码也错了，导致形成非预期偏差。

　　

作为一个数据科学家，一定要“吹毛求疵”，严管团队。因实验设计出错而浪费的时间是不能挽回的。更糟糕的是，基于错误数据的错误决定比任何东西都更具有摧毁性。

　　

用到的技能：

　　

假设检验：统计检验、P值、统计显著性、统计功效、效应大小、多重检验

　　

实验中的隐患：延滞效应、标准筛选、数据稀释和bucket异常

　　

　　

4. 预测型模型与机器学习

　　

在Twitter工作期间，我第一个大项目是给现有的邮件通知产品增加一系列疲劳规则，从而让用户收到更少的垃圾邮件。尽管这还挺高大上，但是我们也深知邮件推送是挽留用户的最大法宝（我们是对此做过实验才得出的结论），因此在两者之间达成一种平衡才是关键。

　　

理解了这个关键点后，我很快决定专注于开发触发式邮件。只有交互发生时，邮件才会抵达用户收件箱。作为一枚满怀抱负、年轻有为并一心想证明自身价值的数据科学家，我决定建立一个别致的机器学习模型来预测用户的邮件点击率。我一鼓作气，用Pig收集了一大堆用户层面特征，并建立了一个随机森林模型来预测邮件点击。我的想法的核心就是如果用户长时间保持很低的点击率，那么我们就可以放心的封停那封邮件。

　　

但是有一个问题――上面所有的任务都是在我自己计算机上用R语言完成的。虽然人们欣赏我的成果，但是他们却不能使用我的模型。因为我的成果还没有产品化，基础设施也不能和我的模型兼容。多么痛的一课！

　　

一年后，我有一个很好的机会，可以和增长部的另外两位数据科学家一起建立流失预测模型。因为之前已经积累了建立数据管道的经验，这次我发现建立机器学习管道其实挺大同小异的――得有训练阶段，可以离线通过Python进行周期性模型更新；得有预测环节，得每天整合用户特征，再让预测功能一展拳脚来给每个用户打出流失率分值。

　　

我们花费数周创建管道，最终确定它有很好的预测效果，并且通过评分应用到Vertica、HDFS 和 Manhattan（Twitter自己的重要商店）。由于我们的模型让分析专家、数据科学家和工程服务都更容易评分，这无疑在宣传和推动我们模型的使用。这是我学到的关于建立产业化模型最重要的一课。

　　

讨论到现在我一直特意不提建立机器学习模型所需要的其他步骤――确定问题、定义标签、收集训练数据、筛选工程师、建立雏形和客观验证模型。这些当然很重要，但是我感觉这些知识已经被研究的很透彻了，关于这些话题也有很多好建议（http://ml.posthaven.com/machine-learning-done-wrong）。

　　

我认为大部分优秀的数据科学家，特别是A类数据科学家都有着相反的问题。他们知道怎么做，但是不确定如何把这些模型应用到生态系统中。我的建议是多和在这个方面拥有丰富经验的B类数据科学家交流，从而找到自己需要的技能，发现突破口，磨练技能。这样在时机成熟之际，你就可以转到这些项目上了。让我用下面引用的话来总结下这部分：

　　

“机器学习不等同于R语言脚本。机器学习是立足于数学，用编码来表达，再汇集成软件。你得成为一个工程师，学习编写可读、可反复使用的代码：你的代码会被其他人反复的阅读，远超过你自己，因此要学着用一种别人也能阅读的方式去编写代码。”――Ian Wong，来自于他在哥伦比亚数据科学课上的嘉宾讲座。

　　

用到的技能：

　　

模式识别：识别那些可以通过建模技术来解决的问题

　　

建模和机器学习的所有基础：探索性数据分析、特征建立、特征筛选、模型筛选、训练/验证/测试和模型估值

　　

产品化：上述提到的关于数据管道的所有东西。设置你的输出值，这样别人和别的服务都能访问。

　　

一些后续思考……

　　

成为一名数据科学家是令人激动的。发现一个特别的洞察结果是无与伦比的欢喜的。从零开始一步一步创建数据管道或机器学习模型会让人得到深深的满足感。在A/B测试中，有一种“扮演上帝”的乐趣。当然这条路荆棘密布、困难重重，并非说的那么轻松。不过，有志者事竟成，那些满怀热情、才华横溢的有志者定能橘子洲头、挥斥方遒。

　　

原文链接：

　　

https://medium.com/@rchang/my-two-year-journey-as-a-data-scientist-at-twitter-f0c13298aee6