Twitter 数据分析师: 我们实际工作内容究竟是哪些

今天就让我们走进 Twitter 的数据分析世界，看看科技公司对于一个数据分析师的要求是什么？他们的实际工作内容究竟是哪些？

到了今年 6 月 17 日，Robert Chang 就在 Twitter 工作两年了。根据他个人的工作经历，Twitter 数据分析（以下简称为 DS）有了下面三个层面的变化：

1.机器学习已经在 Twitter 多个核心产品中扮演越来越重要的角色，而这之前完全是「机器学习」的禁区。最典型的例子就是「当你离开时」这个功能。当用户离开页面或者电脑，去干别的事情后再次返回页面，电脑会立刻给你推送出来某些由你关注的人所发出，而有可能被你错过的「优质内容」。

2.开发工具越来越优秀了。整个团队摆脱了对 Pig 的依赖，全新的数据管道是在 Scalding 中写出来的。

3.从团队组织上而言，Twitter 已经转向了一个嵌入式的模型中。其中数据分析比以往更加紧密地与产品/工程团队发生着联系。

在 Twitter 的工作确实是令人兴奋的，因为你能站在这个平台上，引领目前世界最前沿的数据科技，打造最具竞争力的优势。而同时，人们对于大数据的渴望也一天比一天高。

Dan Ariely 曾经有一句话说得特别好：

「大数据其实有点儿像青少年的性。每一个人都兴致勃勃地谈论它，但是没有任何一个人真的知道该怎么做。每一个人都觉得身边的人都在尝试，为了不落人后，于是每个人都在外面宣城自己也已经有『伴儿』了」

现如今，有太多的人在如何成为一名优秀称职的数据分析师上表达着看法，给出自己的建议。Robert Chang 毫无疑问也是受益者。但是他回过头来再想想大家的讨论，会觉得人们往往更加侧重于去谈「技术」、「工具」、「技能组合」，而在 Chang 看来，那些东西确实很重要，但是让新人们知道数据分析师每一天的生活到底是什么样子的，具体的工作内容都是什么，这也非常重要。

于是，Chang 凭借着自己在 Twitter 工作两年的经历，以自己作为例子，首次打开 Twitter 数据分析师这扇神秘的大门。

A 型数据分析师 VS B 型数据分析师

Chang 在没来 Twitter 之前，总觉得数据分析师一定是在任何领域都能看堪称「独角兽」，不管是数据还是数学专业，都是顶尖人才。除了技术上很牛之外，书面写作和口头交流的能力也会特别强。更重要的是他们能够分清楚当下工作的轻重缓急，领导和管理一个项目团队。是啊，如今本身就是以数据为主导的文化，作为「数据分析师」，当然要给这个文化注入灵魂与活力啊！

在 Chang 加入 Twitter 的几个月后，他逐渐意识到：符合上述形容的「独角兽」确实存在，但是对于大部分人来说，上述的要求未免有点儿太不切实际了。人们没有办法做到面面俱到。后来，Chang 通过 Quora 中的一篇回答，更深刻地理解了数据分析师的角色。在那篇文章中，数据分析师分成了两种类型：

A 型数据分析师： 他们主要负责「分析」。他们最关心数据背后的意义，往往使用统计等方式探知真相。其实他们的工作有点儿像「统计学家」，但是不一样的地方是，统计学专业涉及的内容他们统统掌握，但是他们还会一些统计学课本里面压根不曾出现的内容：比如数据清洗，如何处理超大数据组，数据视觉化，有关数据层面的报告撰写等等。

B 型数据分析师：B 型负责「建造」。他们跟前一种分析师有着相似的统计学背景，但他们同时还是非常牛叉的程序员，又或者是训练有素的软件工程师。B 型数据分析师往往感兴趣于「如何利用数据来生产」。他们建立一些能够与用户互动的模型，往往以「推荐/推送」的形式出现，比如「你也许会认识的人」，「广告」，「电影」，「搜索结果」等等功能。

Chang 看到这样清楚的划分，非常后悔如果早几年有这么清楚的概念认识该多好啊。这样他就能够有选择性的发力，择其一方向来继续发展。这是数据分析师职场规划首先要考虑的标准。

Chang 的个人专业背景是「数学」、「运营研究」、「统计学」。所以他更倾向于把自己定位于 A 型数据分析师，但是与此同时他对 B 型分析师能够涉及那么多的工程开发工作而向往不已。

初创公司早期、快速发展的初创公司、以及实现规模化发展的初创公司中的数据分析师职位区别

在选择投身于科技行业的时候，最经常遇到的一个问题就是到底是加入一个大的科技公司好呢？还是加入一个小的科技公司好。在这个话题上已经有很多争论了，但是在「数据分析」上面的争论并不是很多。所以在本章节要具体谈到的是，不同公司的规模、发展阶段中，数据分析师不同的角色定位。

处于不同发展阶段的科技公司生产数据的量与速度都是不一样的。一个还在尝试着寻找到「产品市场契合点」的初创公司完全不需要 Hadoop，因为公司本身就不存在多少的数据需要处理；而一个处在快速发展中的初创公司往往会遭遇更频密的数据冲击，也许 PostgreSQL 或者 Vertica 更适合这家公司的需要；而像 Twitter 这样的公司如果不借助 Hadoop 或者 Map-Reduce 框架，就完全无法有效地处理所有数据。

Chang 在 Twitter 学到的最有价值的一点内容就是：数据分析师从数据中提取出价值的能力，往往跟公司本身数据平台的成熟度有着密不可分的关系。如果你想要明白自己从事的是哪种类型的数据分析工作，首先去做做调研，看看你意向中的这家公司的底层系统架构能够在多大程度上支持你的目标，这不仅仅对你好，也对公司好，借此看你个人的职业发展目标是否跟公司的需要契合起来。

在初创公司早期，最主要的分析重点是为了实现 ETL 进程，模块化数据，并且设计基模架构，将数据记录应用到上面。这样数据就能够追踪并存储。此处的目标是打下分析工具的基础，而不是分析本身。

在快速发展的初创公司的中期，因为公司在快速发展，那么数据也在不断的增长。数据平台需要适应不断发展的新形势，新条件，在已经打好基础的前提下，开始逐渐实现向分析领域的过渡。一般来说，此时的分析工作主要围绕着制定 KPI，推动增长，寻找下一次增长机会等工作展开。

实现了规模增长的公司。当公司实现了规模化增长，数据也开始呈几何倍数的增长。此时公司需要利用数据来创造，或者保持某种竞争性优势，比如更好的搜索结果，更加相关的推荐内容，物流或者运营更加的高效合理。这个时候，诸如 ML 工程师，优化专家，实验设计师都可以参与进来一展拳脚了。

在 Chang 加入 Twitter 的时候，Twitter 已经有了非常成熟的平台以及非常稳定的底层结构。整个数据库内容都是非常干净，可靠的。ETL 进程每天轻松处理着数百个「任务调度」工作。（Map-Reduce）。更重要的是，在数据分析领域的人才都在数据平台、产品分析、用户增长、实验研究等多个领域，多个重点工作齐头并进一起展开。

关于 Chang 本人的经历

他是在用户增长领域安排的第一名专职数据分析师。事实上，这花了他们好几个月来研究产品、工程、还有数据分析到底该如何融合，才能实现这样一个岗位角色。Chang 的工作与产品团队紧密连接，根据这方面的工作经验，他将自己的工作职责划分成为了下面几类内容：

产品分析

数据传输通道

实验（A/B 测试）

建模

下面将会按照排列次序逐一解释

产品分析

对于一家消费级科技公司来说，产品分析意味着利用数据来更好地理解用户的声音和偏好。不管什么时候用户与产品进行着互动，Twitter 都会记录下来最有用的数据，存储好它们，以待未来某一天分析之用。

这个过程被称之为「记录」（logging）或者「工具化」（instrumentation），而且它还不断地自我演进。通常情况下，数据分析往往很难实现某个具体的分析，因为数据要么是不太对，要么是缺失，要么是格式错误的。在这里，跟工程师保持非常好的关系非常有必要，因为数据分析能够帮助工程师确认 bug 的位置，或者系统中一些非预期的行为。反过来，工程师可以帮助数据分析弥补「数据鸿沟」，使得数据内容变得丰富，彼此相关，更加准确。

下面举出来了 Chang 在 Twitter 展开的几项与产品有关的分析案例：

推送通知分析：有多少用户能用得到「推送通知」？不同类型的推送通知具体的点击率都分别是多少？

SMS 发送率：在不同的数字载体上，Twitter 的 SMS 发送率都是怎么计算的？是不是在发展中国家这个发送率相对比较低？我们该怎样提升这个数字？

多账户：为什么在某些国家，一个人持有多个账户的比例会相对较高？背后是什么动机让一个人持有多个账户？

分析会以多种形式展开。有些时候公司会要求你对一次简单的数据拉取进行最直白的解读，又或者你需要想出一些新的方式方法来机选一个全新，且重要的运营指标。（比如 SMS 发送率），最后你会更加深刻地理解用户的行为。（比如一个人拥有多个账户）

在产品分析中不断研究，得到真知灼见，这是一个不断迭代演进的过程。它需要不断地提出问题，不断地理解商业情境，找出最正确的数据组来回答相应的问题。随着时间的累积，你将成为数据领域的专家，你会正确地估计出来执行一次分析大概得花多长时间。更重要的是，你将逐渐从一个被动响应的状态，逐渐过渡到主动采取行动的状态，这其中会牵连出来很多有趣的分析，这些内容都是产品负责人曾经压根没有考虑过的，因为他们不知道这些数据存在，又或者不同类型的数据以某种特殊的方式组合到一起竟然会得出如此惊人的结论。

此处需要的技能：

保存和工具化：确认数据鸿沟。与工程部门建立良好的协作关系；

有能力引导和确认相关的数据组，知道正确使用它们的方式；

理解不同形式的分析，能够在不同的分析执行之前就正确地估算出难易程度，所需时间长短；

掌握你的查询语言。一般来说是利用 R 或者 Python 来实现数据再加工；

数据管道

即使 A 型数据分析师不太可能自己编写代码，直接应用到用户那里，但是出乎很多人意料的是，包括 Chang 在内的很多 A 型数据分析师确实在给代码库写东西，目的只有一个：为了数据管道处理。

如果你从 Unix 那里听说过「对一系列命令的执行」，那么一个数据管道就意味着多个系列命令的执行，我们能够不断周而复始地自动捕捉，筛选，集合数据。

在来到 Twitter 之前，Chang 的分析绝大部分都是点对点的。在 Chang 的本地机器上，代码执行上一次或者几次。这些代码很少得到审查，也不太可能实现版本控制。但是当一个数据通道出现的时候，一系列的功能就浮出水面：比如「依赖管理」、「调度」、「源头分配」、「监控」、「错误报告」以及「警告」。

下面介绍了创建一个数据管道的标准流程：

你忽然意识到，如果一个数据组能够周而复始地自我重新产出，那么这个世界估计会因此受益；

在确认了需求之后，你开始设计「生产数据组」的「数据架构」；

开始编写你的代码，不管是在 Pig，Scalding，或者 SQL 中。这取决于你的数据环境是什么；

提交代码，进行代码审查（code review），准备后得到回馈，并做相应额外的修改。要么是因为你的设计逻辑不太对，要么是你的代码出于速度和效率的目的并没有优化到位；

应该有一个「测试」和「试运转」的环境，确保所有的运行都在既定的轨道上。

将你的代码融合到主库中

建立「监控」、「错误报告」以及「警告」等功能，以防止未来出现预期之外的状况。

很显然，数据通道比一个点对点的分析工具来说更加复杂，但是优势也非常明显，因为它是自动化运行着的，它所产出的数据能够进一步强化面板，这样更多的用户能够消费你的数据/结果。

数据管道

通过上文的描述，也许在很多人的概念中 A 型数据分析师不太可能自己编写代码，直接应用到用户那里，但是出乎很多人意料的是，包括 Chang 在内的很多 A 型数据分析师确实在给代码库写东西，目的只有一个：为了数据管道处理。

如果你从 Unix 那里听说过「对一系列命令的执行」，那么一个数据管道就意味着多个系列命令的执行，他们能够不断周而复始地自动捕捉，筛选，集合数据。

在来到 Twitter 之前，Chang 的分析绝大部分内容都是点对点的。在 Chang 的本地机器上，代码执行上一次或者几次。这些代码很少得到审查，也不太可能实现版本控制。但是当一个数据通道出现的时候，一系列的功能就浮出水面：比如「依赖管理」、「调度」、「源头分配」、「监控」、「错误报告」以及「警告」。

下面介绍了创建一个数据管道的标准流程：

1.你忽然意识到，如果一个数据组能够周而复始地自我重新产出，那么这个世界估计会因此受益。

2.在确认了需求之后，你开始设计「生产数据组」的「数据架构」。

3.开始编写你的代码，不管是在 Pig，Scalding，或者 SQL 中。这取决于你的数据环境是什么。

4.提交代码，进行代码审查（code review），准备后得到回馈，并做相应额外的修改。要么是因为你的设计逻辑不太对，要么是你的代码出于速度和效率的目的并没有优化到位。

5，应该有一个「测试」和「试运转」的环境，确保所有的运行都在既定的轨道上。

6.将你的代码融合到主库中。

7.建立「监控」、「错误报告」以及「警告」等功能，以防止未来出现预期之外的状况。

很显然，数据通道比一个点对点的分析工具来说更加复杂，但是优势也非常明显，因为它是自动化运行着的，它所产出的数据能够进一步强化面板，这样更多的用户能够消费你的数据/结果。

另外，更加重要但是往往被人忽略的一点结果是，对于如何打造最优化的工程设计，这是一个非常棒的学习过程。如果你在日后需要开发一个特别定制的数据通道，比如机器学习，之前所做的工作就成为了扎实的基础。

实验（A/B 测试）

此时此刻，非常有可能你现在使用的 Twitter App 跟我手机上装的 App 是有一点小小的不同的，并且很有可能你在用着一个我压根没有见到过的功能。鉴于 Twitter 的用户很多，它可以将其中很小的一部分流量（百分之几）导入到一次实验中，去测试这个尚未全面公开的功能，去了解这些被选中的用户如何跟这个全新的功能互动，他们的反响跟那些没有见到这个功能的用户进行对比。

这就是 A/B 测试，去让我们方便测试各种变量，通过 A 和 B 到底哪个方案更好。

Chang 个人的看法是：为一些较大的科技公司做事，能够享受到的一点优势，就是能够从事开发和掌握业界最神秘的技能：「A/B 测试」。作为一名称职的数据分析师，你必须利用可控制的实验，在其中进行随机测试，得到某种确定的因果关系。而根据 Twitter 负责工程部分 A/B 测试的副总 Alex Roetter 的话来说，「Twitter 的任何一天中，都不可能在没有做一次实验的前提下就草率放出某个功能。」A/B 测试就是 Twitter 的 DNA，以及产品开发模式的基础。

A/B 测试的循环周期是这样的：取样-> 分组->分别对待-> 评估结果-> 作出对比。这听上去是不是觉得挺简单的？其实事实完全相反。A/B 测试应该是天底下最难操作的分析之一，也是最容易被人低估难度的一项工作。这方面的知识基本上学校是不教的。为了更好的阐述观点，分了下面五点内容，分别是五个阶段，其中一些部分有可能是你从事 A/B 测试时会遇到的一些困难和挑战。

取样— 我们需要多少的样本？每一组分多少个用户？我们是否能够让实验具有足够的可信度和说服力？

分组— 哪些人适用于出现在这次实验中？我们从代码的哪一处开始起手，分出两个版本？是否会出现数据稀释的情况？（数据稀释的意思就是，有些用户被纳入到了新改动的版本测试中，但是实际上他们却压根不打开这个 App，见不到这个新变动的功能。）

区别对待-整个公司中是否还有其他的团队在做其他的测试，瞄准的用户是否跟此时我们锁定的用户群发生重叠？我们该怎样应对「测试冲突」这种情况，保证我们的数据没有被「污染」？

评估结果-测试的假设前提是什么？实验成功或者失败的指标是哪些？我们是否能做到有效的追踪？我们是否要增加一些其他方面的数据存储？

做出比较-假设某个条件下的用户数量发生了激增，它是不是因为其他的一些因素？我们是如何确保这些统计具有实际的意义？就算具有实际的意义，这个意义对于下面的产品改良又具有多大的指导作用？

不管回答上述的哪一个问题，都需要对统计学很好的掌握才能办到。就算你一个人能力很强，但是团队其他同事还是有可能给这个 A/B 实验添乱子。

一个产品经理有可能特别心急，没等试验结束就要偷窥数据，又或者想当然地，按照他们想象的方式挑选自己想要的结论。（这是人性，别怪他们）。一个工程师有可能忘记存储某个特殊的信息，又或者错误的写出测试用的代码，实验结果出现了非常离谱的偏差。

作为数据分析师，这个时候不得不对自己和他人严厉一些，让整个团队都能高效、准确地运转，在实验的每一个细节上面都不能有任何的差池。时间浪费在一次徒劳无功，设计错误的实验中，这些时间是找不回来的。甚至还会出现更糟糕的情况，依据一次错误的实验结论形成错误的决策，最终给整个产品带来极大的风险。

在此处所需要用到的技能：

假设条件测试： 统计学测试，统计数据可信度，多重测试。

测试中有可能出现的偏差： 按照自己想要的结果去推断结论，延滞效应，数据稀释，分组异常

预测型建模以及机器学习

Chang 在 Twitter 负责开发的第一个重大项目是将一组「疲劳标准」添加到 Twitter 目前的邮件通知产品中，这样能够降低邮箱过滤机制将 Twitter 的信息视为垃圾信息的概率，从而实现让用户更频繁在收件箱中看到 Twitter 发来的电子邮件。

尽管邮件过滤机制不失为使一次伟大的发明，但是邮件通知也确实是提升客户留存率的特别有效的办法之一。（这个结论是 Twitter 曾经做的一次实验中无疑中发现的）。所以，Chang 的目标就是在这其中取得平衡。

在基于上述的观察和思考之后，Chang 想到了一个点子：触发式的邮件发送机制。也就是只有在用户与产品之间发生了某种互动的情况下，这封邮件才会发送到用户的电子邮箱。作为刚刚加入团队的数据分析师，Chang 特别想要通过这个项目来证明自己的价值，于是决定利用非常棒的机器语言模型来预测电子邮件的 CTR（点击率）。他将一大堆用户级别的功能集合在 Pig 工具中，并建立了一个随机预测模型来预测邮件点击。这背后的想法是，如果用户在过去很长一段时间内都对电子邮件有着低点击率，那么 Twitter 就会保留这封邮件，不再给他发送。

上述的想法都很好，但是只有一个问题，所有的工作都是放在本地机器的 R 中处理的。人们都很赞赏 Chang 的工作成果，但是他们不知道如何利用这个模型，因为它是无法进一步转化成产品的。Twitter 的系统底层是无法与 Chang 的本地模型展开对话的。

这一课带来的教训让 Chang 终生难忘。

一年之后，Chang 和增长团队中的两个人共同捕捉到了一个全新的机会，能够打造一个用户流失率预测模型。这一次，Chang 已经在开发数据管道上有了非常充足的经验。这一次他们做的非常好，模型能够针对每一个用户自动的生成一个用户流失概率！

几个星期之后，他们开发了数据管道，并且确认它真的具有很有效的预测能力，他们通过将分数写入到 Vertica，HDFS，以及 Twitter 内部一个称之为「曼哈顿」的关键价值商店。这样大家都知道了它的存在。公司无数分析师，数据分析师，工程服务部门都过来试用，进行查询，帮其宣传，评价非常好。这是 Chang 在 Twitter 最值得骄傲的一件事，真正把预测模型纳入到了产品当中。

Chang 认为绝大部分杰出的数据分析师，尤其是 A 型的数据分析师都存在这样一个问题，他们知道怎样去建模，但是却不知道怎样把这些模型嵌入到产品系统当中。Chang 的建议是好好跟 B 型数据分析师聊聊吧，他们在这个话题上有着足够丰富的经验，发现 A 型和 B 型数据分析师职能重合的那一部分，想想接下来需要的一些技能组合是什么，这样才能让自己在数据分析师的道路上走的更深更远，更加宽广。

「机器学习并不等同于 R 脚本。机器学习起源于数学，表达在代码中，最后组装在软件中。你需要是一名软件工程师，同时需要写一点可读的，重复使用的代码。你的代码将被更多人重新读取无数次-来自 Ian Wong 在哥伦比亚数据学课堂上的讲座节选。

在这里所用到的技能：

模式确认：确认哪些问题是可以通过建模的方法来加以解决的

建模以及机器语言的所有基础知识：探索型数据分析，开发功能，属性选择，模型选择，模型评估，练习/确认/测试。

产品化：所有上面的内容有关于数据管道的建立，使得不同的人都能够在上面执行查询

最后的一些话：

成为一个数据分析师确实是一件挺让人激动的事。你能从别人根本无法达到的角度获取真相，这足够酷炫了。从底层开始开发数据管道或者机器语言模型，会给人带来深层次的满足感，当执行 A/B 测试的时候，有太多时刻会给你一种当「上帝」的趣味。即便这条路充满了曲折以及不确定性，有很多挑战摆在眼前，但是走在这条路上的人永远不会退缩。任何一个聪明，有想法的年轻人都应该考虑成为一名数据分析师。