Twitter 数据分析师独家披露他们的工作内容（下）

在 上一章节 ，我们聊到了数据分析师的两种类型，以及笔者 Chang 在 Twitter 一部分具体的工作内容。在本章节中，会继续接受一个 A 型数据分析师在「数据管道、实验（A/B 测试）、以及建模」这三个领域的工作内容。

---

数据管道

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

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

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

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

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

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

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

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

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

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

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

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

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

在此处需要用到的技能：

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

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

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

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

实验（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 测试的时候，有太多时刻会给你一种当「上帝」的趣味。即便这条路充满了曲折以及不确定性，有很多挑战摆在眼前，但是走在这条路上的人永远不会退缩。任何一个聪明，有想法的年轻人都应该考虑成为一名数据分析师。

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

End.