你的数据分析团队需要做什么？

摆在我们面前的可能是一堆数据，访问日志，性能日志，行为日志 … 。同时还有一堆问题，如何提升用户转化率？ 提升设备利用率？ ,我们如何把数据同问题联系起来，如何建立起描述问题的数据模型？，度量数据的指标Metric 是不是得到大家的认可？ 谁需要这些数据？ ，在生产环境中，如何检验数据或者模型的效果?

第一个问题直接导致了第二个问题: 你现在思考问题的方式或许是错误的

在构建数据分析团队时候，你需要招聘个大拿进来，获取你给他个数据科学家，或者数据分析师什么的Title 。这个人进来，或许要推翻你旧有的想法。国外给这个人的时间是3个月，国内的团队可能会更长一些，把问题丢给他们。在3个月的时间内，让他们用全新的方式思考问题。这里有篇文章可以参考 “创建一个数据分析团队”

如何为数据分析团队配置资源

数据分析团队成员的背景会比较多元化，有搞统计的，搞建模的，搞数据清洗的，搞基础设施的。 我们要解决这个联队，如何融入现有的组织结构。 因为团队目标不同，所以同普通的工程团队项目，支持方式也不同，比如要不要在数据分析团队适用现有的开发，运维规范？。

团队成员如何产出

数据分析最终会落实到生产环境代码中，比如一个模型，需要20台机器，每天定时跑。一般情况下数据分析人员会缺乏生产环境经验，比如写代码，部署，运维等。因此在工程团队和数据分析团队中，要有数据会商，沟通机制。 在人力资源允许的情况下，是不是可以考虑工程师轮岗机制，工程团队的同事，定期轮岗到数据分析团队中，处理数据团队的工程难题

数据科学家能够让你更好的思考你的问题集了吗？

数据科学家一般来源于不同于工程团队的背景，比如数据系，统计系。这些人的背景和技能，在工程团队会比较稀缺。在同数据团队每天的沟通中，你要能够从新的角度思考问题，并且在公司范围内，让更多的人了解到数据团队的产出。

人人都想了解数据分析

在公司里面，要把数据团队比较好的隔离开来，与其跟其他部门解释比较复杂的数据分析过程，还不如让大家关注业务上面的产出。类似的沟通问题，可以参考产品经理团队和工程团队沟通的经验。

工具问题

虽然有开源的软件栈，比如Mysql, Pentaho , Hadoop ,Hbase ，R 但是这些产品本身非常工程化，使用成本很高，并且存在诸多不稳定因素。因此目前的数据分析人员，更多的像拿着原始的步枪在工作。 在实际工作中，不要忽略数据处理工具本身，对团队产出的影响

本文部分观点，来源于 http://kurt.karmalab.org/2012/01/30/building-a-data-team/?

无觅猜您也喜欢：
航空公司如何使用twitter，数据统计	Kettle 集成 Google Analytic 数据	Twitter 一些数据	向infobright中导入数据时报错的解决办法
无觅

虽然EC2做了很多工作，来确保云服务的可用性，但是对于他们的客户来讲，他们放上去的业务，实际就是放到了Amazon那个篮子里面，并且，还只有一个篮子。

无觅猜您也喜欢：
云计算市场全景图	Jconsole 不能连接远程服务的问题	航空公司如何使用twitter，数据统计	关于斑马是如何形成的，四格漫画
无觅

米国人民深刻理解什么才能持续发展，什么才能生产财富啊

而我们，看来是更愿意当消费者，问题结果恰恰相反，我们是世界工场

美国才是世界最大的消费者…

无觅猜您也喜欢：

小马同学推荐得在线电视软件

infobright安装简要说明，mysql往infobright中按天导数据脚本

向infobright中导入数据时报错的解决办法

简单工程中的细节处理

无觅

SPDY 设计特点

协议在SSL层的基础上，增加了一个session 层，从而在一个tcp 连接基础上，实现了多并发和交叉流传输

HTTP 的GET ,POST 仍旧采用旧有的消息格式，当然SPDY 协议对原有的数据做了封装和编码，这里采用Wrapper设计模式。

流是双向的，比如，既可以从客户端发起，也可以从服务器端发起（PUSH）

SDPY的目标就是通过其基本特性和高级特性，来达到低访问延迟

基本特性包括

1  流复用

无觅猜您也喜欢：
The Likability of Angry Birds	我的智能机器人平台	张瀚文轶事 2011.3.18	摇篮网9周年现场照片
无觅

我们最近讨论了消息系统的后端组件，以及我们如何扩展我们的服务以处理来自Email ，SMS， Facebook Chat ,收件箱的海量消息，本文我们就分享一下应用服务器的设计细节。

应用服务业务逻辑层

应用服务器整合了很多Facebook服务，封装了访问这些服务的复杂性。 他为客户端，封装了一个简单的接口来处理标准的消息操作，包括创建，读取，删除，更新消息和收件箱。

下面介绍一个每个操作的流程。

当创建一个新的消息或者回复一个消息的时候，应用服务器将消息投递到接收方（用户），如果接收方是个email地址，应用服务器还会去HayStack检查一下，是否有附件，然后创建一个html格式，遵从RFC2822标准的消息。

当消息（邮件）通过外部的邮件地址发送到Facebook内部用户系统的时候，服务器会将消息投递到用户的收件箱，根据一些预设的条件，对消息进行必要的处理，决定消息投递到哪个目录，那个话题里面。

当读取消息的时候，服务器会获取多项关于用户Mailbox的统计数据，例如容量，消息数量，话题数量，回复数量； 用户的活跃联系人数量。 服务器还会获取收件箱里面目录的统计信息和属性信息。在读取话题列表的时候，是通过一系列的搜索条件（目录，属性，作者，关键词等），话题列表里面包括话题的基本属性和话题下面的消息。

当删除消息的时候，服务器将消息和话题标识成删除状态，然后一个离线的作业会执行具体的删除消息操作。

当更新消息和话题的时候，服务器变更消息和话题的属性，比如【已读/未读】 ，归档状态，Tag 等等。更新操作还负责处理针对话题的订阅，退订操作。

管理话题组

Facebook 通过聊天室的模型管理群组话题消息。 用户可以加入（订阅），或者离开（退订）某一话题。在回复某个话题，当收件人不是某个用户，而是一个Email地址的时候，应用服务器会创建一个回复处理器，就像聊天室ID一样，当收件人通过回复了这个话题，消息会通过回复处理器，直接投递到那个话题。

为了优化读性能，简化迁移和备份过程，话题消息存储通过一个非规范化的模式来存储，因此每个用户，都有他自己的一份话题元数据，和消息的拷贝。服务器广播订阅和退订事件，在所有的接收者中，同步话题的元数据数据，从而可以用去中心化得方式，来处理订阅和回复等请求。当处理老的系统时候，比如用户的老的收件箱，或者通过Email地址来订阅，应用服务器会做些特别的适配工作，以保证业务流畅。

缓存用户的元数据

当用户访问收件箱的时候，应用服务器加载用户常见的元数据，（我们叫做活动元数据），然后缓存在LRU里面，后续请求可以尽量少查询HBASE，从而提升效率。

我们尽量减少对HBASE          的查询，是因为HBASE不支持join. 为了服务一个读请求，服务器可能要查找多个索引，在不同的     HBASE查询中抓取元数据和消息内容。Hbase针对写，而不是读做的优化，幸运的是，用户行为通常具有良好的时间和空间局部性，因此通过Cache可以解决性能问题。

我们也做了很多努力，通过减少用户内存痕迹，采用更细粒度的架构来提高Cache效率。我们可以缓存5%-10%的用户，命中率在95%左右。对于超热点数据，比如主页的未读消息数，我们将其放到全局的Memcache层。当新的消息到达时，应用服务器负责将缓存中的数据做过期处理。

同步

HBase对于交易的隔离提供了有限的支持。因此对于用户的多个并发更新，为了解决更新冲突，Facebook采用应用服务器来解决这个问题。每个用户，都会被分配到特定的应用服务器，因此针对这个用户的更新操作，都可以在这个应用服务器内，通过代码做到完全的同步隔离。

存储模式

MTA代理，将附件和大的消息到达应用服务器以前，将他们提提取出来，存储在Haystack中。当然元数据，包括搜索索引数据和小消息体，存储在HBASE中，由应用服务器来维护。每个用户的邮箱同其他用户的邮箱，都是相互独立的；用户数据在Hbase中，是不会共享的。每个用户的数据，都会存储在HBase中的一行中，Hbase行的数据结构如下：

元数据实体和索引

元数据实体，包含着收件箱对象的属性，比如文件夹，话题，消息等等。 每个实体存储在他自己的HBASE列中，不像传统的RDBMS，HBASE没有原生的索引支持。我们在应用层面，维护着二级索引。每个单独的列都已key/value对的形式存储。

例如，当我们查询“在其他目录的第二页加载未读话题”，应用服务器首先查询元数据索引，获取符合查询条件的话题，然后抓取特定话题的元数据实体，通过他们的属性来构造响应对象。

就像我们前面提到的，缓存和有效的预加载减少了Hbase的查询次数，提升了系统效率。

动作日志

任何对于用户收件箱的操作（例如创建，删除，标记话题为已读等） 都会按照时间寻出立刻追加到一个列族，这个动作被动作日志。小的消息体也会存储在动作日志里面。

我们通过重放动作日志，可以重建或者恢复用户当前的收件箱的状态。我们用最后动作日志的ID作为元数据实体和索引的版本。当加载一个用户的收件箱的时候，应用服务器比较元数据版本和最后动作日志ID，如果元数据的版本号落在了后面，那么更新收件箱的内容。

在应用端存储动作日志带来了巨大的灵活性：

a)         我们可以通过重放动作日志，产生新的元数据实体和索引，重建的过程既可以通过离线的MapRedue 任务，也可以通过应用服务器在线完成，从而保证我们可以无缝的切换到新的存储架构。

b)         我们可以进行大批量的Hbase异步写入以节省网络带宽和Hbase压缩成本。

c)         他是一个跟其他组件进行持久层数据交换的标准协议。例如，我们可以通过将动作日志写入到Scribe日志上，实现在应用级别进行备份。迁移管道将用户老的收件箱转换成动作日志，然后通过离线的MapReduce生成元数据和索引。

搜索索引

为了支持全文检索，我们维护了一个关键词的倒排索引列表。当新的消息到达时，我们用Apache Lucene 来解析和转换成包含关键词，消息ID,位置的有序列表，然后将列表增量的添加到Hbase的列族上面。每个关键词，有他自己的列。所有的消息，包括聊天的历史，email,sms,都会被实时的索引。

通过Dark Launch进行测试

应用服务器是我们从概念开始设计起来的全新软件，在我们将其用于5亿用户之前，我们需要监控他的性能，可靠性，扩展性。 我们最初开发了一个压力测试机器人，用来发起测试请求，但是我们发现测试结果，会受一些因素的影响，比如消息大小，不同请求类型的分布，不同用户活动程度的分布等待。

为了模拟生产环境下的负载情况，我们做了个Dark launch,通过这个系统我们镜像了来自聊天室和显存的收件箱的流量，将10%的用户流量导入了一个测试的集群. Dark  launches 帮助我们发现了很多性能问题和性能瓶颈。 我们同时也用他来做性能改善的评价标准。随着时间的推移，我们会向所有用户推出我们新的消息系统。

无觅猜您也喜欢：
Facebook 开源Open Compute Project	PR2 快速应用大赛	Facebook 用户性别和相册使用情况分析	lsof 命令高级应用
无觅

新浪微微博除了有大量的政经科内容外，也有普通人的故事，普通人的浪漫遭遇

感谢echo 提供线索，以及 视频里链接   http://v.ku6.com/show/T6TUhw5g9pqBjzKj.html

无觅猜您也喜欢：

微软收购雅虎 弱弱联合

分享我在新浪网的技术讲座PPT 面向对象与设计模式

朋友三个新站上线，友情推荐

团购网站引发新一轮互联网投资热潮

无觅

书单由顶尖高手Russell ，  Norvig 推荐

原文链接 http://aima.cs.berkeley.edu/books.html

无觅猜您也喜欢：
我的智能机器人平台	我来推荐2008年IT年度图片	推荐一个系统状态查看工具–DSTAT	Hulu 的个性化推荐 (Personalization in Hulu)
无觅