在每个我曾经工作或者指导的组织，总会发现数据科学家的影响力和他们的数量很不相称。他们可以扮演的角色遍布于以下领域。

决策科学和商业智能

长期以来，数据在广告领域及协助运作及战略思维中发挥重要的作用。关于决策制定支撑(decision-making support)的一个关键部分便是定义、监测和报告重要的度量(metric)。尽管这些可能看起来很容易，但是定义合适的度量可以用来帮助一个商业组织了解自身的强项和关键项(此处用杠杆和控制按钮作比喻)。不经设计的度量会导致盲点的产生。例如，使用百分位数，这仍然是观察原始数据的重要方面。同样也会跟随商业的复杂化过程不断增加。举个例子，假设一个气象学家只能测量温度。此人的预测结果肯定会比另外一个懂得测量气压的气象学家的结果要差。当然再来一个懂得使用湿度进行预测的人又能产生比前面两个更好的预测结果。

一旦度量和报告建立后，数据的传播就成为至关重要的部分。目前有大量的发布数据的工具，从简单的电子表格和网页表格，到更加精密复杂的商业智能产品。当工具变得越来越精密时，他们一般会增加动画和操作的功能来加强对数据的洞察力。

更多庞大的数据驱动组织热衷于数据的民主化。数据不仅仅是哪个分析组织或者管理层独享的。每个人都应当能够合法地使用到尽可能多的数据。Facebook在这个方面走得很远。他们公司允许任何人使用Hive语言来查询海量的基于Hadoop存储的数据。以这种方法，基本上每个人都可以通过定期地运行脚本建立个人的数据dashboard。Zynga使用完全不同的技术组合建立过类似的东西。他们有两个自己数据仓库的副本。其中一个用来负责需要严格的服务层协议来确保报表和关键度量总是可以获得的运作。另一个则是可以提供给公司内人员使用，当然这里的性能并不能保证最优。

eBay使用的是更为传统的模型，一般是像Teradata那样为每个团队建立数据立方体。这些立方体就是一些自包含的数据集合和存储，对应的团队可以与之交互。

当组织使用报表和分析功能愈来愈和谐，就产生了使用数据对于战略决策制定的需求。我们一直将这个领域称为“决策科学”。这些团队钻入已经获得的数据中，将这些数据和外部数据源进行整合来了解竞争力的全貌，优先化一些策略和战略，并提供对战略计划影响的假设的澄清。一个决策科学团队可能会遇到一个问题，像下一个扩展国家的选择，亦或调查某一特定的市场已经饱和。这种分析可能会需要综合内部的数据建立预测模型，可以使用已有的数据和欲采集数据进行测试。

注意：不熟知数据科学的人们可能会经常寻找一个银弹，以此建立整个系统。如果你找到了，那么恭喜你，不过幸运的人没有几个。最好的组织会寻找能够产生最大效益的方法，再在此基础上寻的可能提高商业价值的方法。

产品和市场分析

产品分析代表一种相对新颖的数据使用方式。团队会建立直接和客户交互的应用，例如:

提供高度个人化的内容(如，一个新闻feed中的信息的排序)

帮助推动公司的价值主张(value proposition)(例如，“PYMK”和其他一些建议好友或者其他类型关系的应用)

利于介绍另外的产品(如，“Group You May Know”)，将用户推送至LinkedIn的群体产品区域)

防止进入死胡同(如，协同过滤技术促成用户购买新的产品，Amazon的“People who viewed this item also viewed …”)

其他的(如，新闻相关的Google News和LinkedIn Today等等)

基于快速下降的计算成本，现在比从前更容易使用到通用的算法和数值技术来测试这些产品的有效性。

类似于产品分析，市场分析使用数据来解释和展示服务或者产品的价值主张。OKCupid’s blog就是一个市场分析的绝佳例子，它使用内部和外部数据源来探讨大趋势。例如，有篇关于使用不同手机的用户的性伙伴的数量的文章。iPhone用户有更多的乐子?只有OKCup知道。另一个文章基于产生的新的联系，研究了什么类型的个人简介照片是有吸引力的。这些文章得到了传统媒体的报道，同时在社交媒体渠道也得到快速传播。结果便是产生了一种市场推广策略，刺激了新用户和老客户数量增长。另一些公司将博客作为市场推广策略，如Mint、LinkedIn、Facebook和Uber。

Email长期以来便是公司与当前客户及潜在客户在线交往的基础。使用分析作为邮件投放策略的一部分不是新出来的手段，但强大的分析的确可以帮助建立提供丰富内容的Email推广项目。例如，LinkedIn周期性地发送给客户他们的社交网络的变动：新工作、重要文章发布、新的社交关系等等。如果仅仅是LinkedIn的广告，那么这类邮件容易被过滤掉。但是事实上并非如此，这些邮件的信息都是与客户息息相关的，它们是与你认识的人相关的。类似地，当用户有段时间不活跃时，Facebook使用邮件来鼓励用户回到社交网站上。这些邮件强调你最相关的朋友近期进行的活动。因为我们不大会删除那些告诉你你的朋友的动态的邮件，所以这种方式格外有效。

在线犯罪者不希望被发现。他们尽可能地藏在数据之中。在不断进化的攻击者和防御者之间的战争中有几个关键的环节：数据采集、侦测、攻击的缓解(mitigation)和司法科学(forensics)。这些数据科学家的技巧与这些环节无瑕结合。

任何防止和侦测欺诈的策略最初都是从数据搜集开始。数据采集常常是一种挑战性工作，因为很难确定多少量的数据是足够的。攻击者总是在找寻能够获得的数据的极限，但是成本和存储容量的限制意味着不可能搜集到所有你想要的数据。因此识别出那些数据是我们所需的是至关重要的。在攻击中，常常会有“if only”现象。仅当我们搜集到x和y，我们才能知道将发生什么。

另一个对安全事件的反应的方面是所需要处理数据的时间。如果攻击以分钟为单位进行演化，但处理层需要数小时来分析数据，这样，就不能高效地作出反应。许多组织意识到他们需要数据科学家和精密的工具来足够快速地处理和分析数据。

一旦知道被攻击，下一个动作便是缓解攻击。减轻影响通常需要关闭一个资源，或者开发一个模型来将坏用户和正常用户辨别开来。在这个环节成功需要有将已有数据转化为新的可以使用的变量。这是个微妙而又关键的步骤。例如，IP地址。任何日志功能都可以搜集到访问你网站的IP地址。IP地址本身并没多大用。但是IP地址可以转化为下列变量：

在某段时间内从一个IP地址发出访问的坏用户
一个IP地址的所属国，及其他地理信息
这个IP地址是否是一天中这段时间的典型

从数据中，我们可以获得可以构造一个可行的模型的变量。领域专家若是数据科学家，懂得如何从数据中获得这些变量。用这些变量，你便可以设计检测方法来找出坏用户。

最终，司法科学(forensics)给出一个工具箱来抵御攻击者，并帮助你学到攻击的本质和了解如何避免(或者限制)未来类似的攻击。司法科学可能是耗时的过程，数据科学筛过所有数据，最终将结果组合从而获得解决方案。一旦问题被摆在一块，新的工具、工程和监测可以按需设置。

数据服务和运营

数据服务和运营是任何数据组织的基础环节之一。这个团队负责数据库、数据存储、数据结构(数据模式scheme的设置)和数据仓库。他们也负责监测和保护这些系统。另一个功能部分不能离开顶级数据服务和操作团队;甚至可以这么说，组织的其他团队都是存在于这个团队之上。一些组织中，这些团队是独立于传统操作团队的。在我看来，当这些系统复杂性增加，便需要更多地与操作团队合作。这个功能领域提供的这些系统和服务需要被部署在传统数据中心或者云上，也需要被监测以保证稳定性;员工也应该随时待命，以防止系统崩溃。建立好的运营团队需要在这些领域有配置，以提供对应的服务。

当一个组织建立起汇报需求时，数据服务和运营团队需要对汇报层负责。当团队成员可能不会关注定义度量时，他们在确保报告准时生成至关重要。因此，数据服务和决策科学的合作是绝对根本的。例如，当一个度量可以能在纸上很容易定义，但实现起来作为一个规则话的报表的一部分时变得不现实时：因为完成这个报表的度量的计算所需要的数据库查询太过复杂而难以达到所需频率。

数据工程和基础架构

去轻描淡写用来规模化产生、跟踪、移动和处理数据的工具的复杂程度很难。开发和实现这些技术是数据工程和基础架构团队的工作。过去十年，这些技术已经发生了巨大的变化，其中有若干开源项目的大量合作。这里举一些例子：

Kafka、Flume和Scribe是搜集流数据的工具。尽管这些模型不大相同，主要想法都是从多个数据源获得数据;聚合数据;然后将数据交给数据库，如Hadoop还有其他一些。

Hadoop是目前最广泛使用的处理数据的框架。它是一个有Google在2004年公开的MapReduce程序设计模型的开源实现。本质上是一种批处理;S4和Strom都将目标汇聚在一些更新的处理流数据的技术

Azkaban和Oozie是工作调度器，他们管理和协调复杂的数据流

Pig和Hive是大型非关系型数据存储的查询语言。Hive与SQL非常类似。Pig则是面向数据的脚本语言

Voldmort、Cassandra和Hbase是设计为高性能大数据的数据存储。

同等重要的是为这些系统建立监测和部署技术。

除了建立基础架构，数据工程和基础架构可以使用产品和市场分析团队的思想，实现这些想法以达到可以规模化产品操作的目的。例如，视频推荐引擎可以使用SQL、Pig或者Hive来建立远行。如果测试显示推荐系统效果很好，那么就可以将推荐系统部署让它支持SLA，表明合适的可获得性和潜伏性。将产品从原型向产品化移植可能需要重新实现使得可以规模化性能。如果SQL和一个关系型数据库运行得很慢，可能需要移到HBase，使用Hive或则好Pig来进行查询。一旦应用被部署好，必须处在监测之下，来保证其持续满足需求。同样也要确保产生合理的结果。达到这个目标需要更多高难度的软件开发工作。

组织和汇报合作

一个组织应当以根据我讨论过的功能领域设计，还是通过其他的机制?没简单的答案。关键点包含参与的人员、组织的大小和规模和企业的组织动态(如，这个公司是产品驱动、市场驱动还是工程驱动)。

在发展早期，人们必须负责很多工作。例如，在一个初创公司，不可能负担起分析、安全、运营和架构等分开的团队：一两个人可能需要做所有的事情。但是当一个组织变大了，人们自然会变得专业化。另外，去除任何简单的失败点很重要。一些组织使用“精英个体中心模型”，这是一种中心化数据团队。其他的使用一个集成和说话模型，这种是指有一个中央团队，成员被安进支撑团队种(例如，销售团队可能会支持分析团队来支撑商业需求)。还有一些组织完全去中心化，每个团队自己雇用满足自身需求的员工。

以下三点是我的感受：

如果团队较小，成员应当坐在一起。与数据打交道常常有很多理解差异，团队之间的快速交流可以解决那些折磨人却很简单的问题。

授人以渔——这只会增强成为更好的数据驱动组织。如前面讨论过的，像Facebook和Zynga这样的组织高效地民主化自己的数据。于是，这些公司有更多的人员参与到分析和观察关键度量的工作。这样的获得方式在50年前根本不可能听到。当然这样也有另外一面：对于基础架构和训练人员的需求提高了。基础架构挑战是技术问题，最简单的达到训练的方式是开设办公室时间并计划数据课程。

所有那些功能领域必须有定期的联络和交流。当数据科学的领域不断扩大，技术和过程创新不可避免同样得到发展。为了保持同步性，所有团队都应当分享自己的经验。即使他们不是同一结构，共同使用的数据将他们绑在一起。