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），准备后得到回馈，并做相应额外的修改。要么是因为你的设计逻辑不太对，要么是你的代码出于速度和效率的目的并没有优化到位；

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

将你的代码融合到主库中

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

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

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

在此处需要用到的技能：

版本控制，目前最流行的就是 Git；

知道如何去做「代码审核」，并且知道如何有效地给予反馈；

知道如何去测试，如何去试运行，当出现错误的时候知道如何「debug」；

「依赖管理，调度，资源分配，错误报告，警告」功能的设置。

接下来的篇章中，我们将谈到除了“产品分析”之外，其余的三种工作内容，它们分别是：数据传输通道、实验（A/B 测试）、以及建模。

本文来源：Medium 译文创见首发 由 TECH2IPO/创见 花满楼 编译

End.