张鹏 的技术

Big Data 最近在互联网圈子很流行，互联网在创造大量数据的同时，面临这如何存储，检索，分析，利用这些数据的难题。但是如果没有应用场景，大数据本身，除了浪费资源外，没有太大的实际价值。因此，不管你是因为怀有对高科技的热情而关注这个热点领域，还是因为公司战略而研究海量数据，下面的问题是每个从业者都需要思考的:

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

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

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

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

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

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

团队成员如何产出

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

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

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

人人都想了解数据分析

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

工具问题

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

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

Amazon的EC2 继上次的人为错误以后，再次出现重大故障，据说这次是雷击，IDC附近的变压器被雷击中起火，备用电力系统启动失败。目前的影响范围包括 Reddit, Heroku, Foursquare, Instagram, Fab, Quora, Turntable.fm, Netflix 等，持续时间已经超过了30min。

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

SPDY 目前是一种应用层实验性协议，旨在让互联网访问更快速，减少web页面的延迟。

SPDY 设计特点

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

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

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

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

基本特性包括

1  流复用

SPDY最牛逼的地方，是允许在一个TCP连接里面，允许无限并发流（在双方资源可承受的情况下）。因为请求是在一个单一的通道交错传输，TCP的可以达到很高的效率，从而更少的网络连接需要，可以以很高的 数据密度做传输。 2  具备优先级的请求 虽然无限的并行数据流的解决了序列化的问题，但是它们引入了另一个问题：如果由于信道带宽的限制，客户端可能会阻止怕堵塞通道的要求。为了克服这个问题，SPDY实现请求的优先次序：客户端可以请求尽可能多的项目，每个请求分配一个优先级。这样即使高优先级的请求仍处在pending状态，通道也不会传输非关键的，低优先级的请求，这样就有效地阻止了传输拥塞。 3  HTTP Header 压缩 对于HTTP 请求，响应头，SPDY都做了压缩，这样包更小，对于RESTFUL类型的WEB2.0 ,or OpenAPI 业务，将会有可观的效率提升。 高级特性 1  服务器端推送 SPDY通过X-Associated-Content 协议头来向客户端推送数据，头通知客户端，我要向你推送资源，准备接收好了。最近火爆的Google+ ,如果你用chrome浏览器，默认就采用SPDY技术，并且开启了服务器推送技术。服务器的推技术，全面提升了用户体验，是G+ 产品很快占据了足够多的优势，最近Facebook 开发自己的浏览器，也有摆脱现在技术限制的考虑 2  服务器暗示 不像上面提到的PUSH 技术，服务器会先告诉浏览器，你可以下载ABC资源了，这个ABC资源，可能就是下一个页面的JS ,CSS ，或者内容。服务器不会主动推送的，仍旧等待客户端请求，这对于低速网络，是个很大的优化，有点类似于我们的预加载技术 效果测试 TOP25 网站的平均页面加载时间 DSL 2 . . . → Read More: SPDY 协议介绍

Facebook 已经在很多领域，成功超越了互联网一哥。这次他开源了他的IDC设计方案，服务器设计方案，一个很庞大的系统工程。低成本，低能耗，定制的硬件，一度被Google一哥，视为独家秘籍，因此业内只知道Google很牛，但是怎么牛，依旧很神秘。 这次Facebook 在他的博客中，还可以挖苦了一把Google，没有及时公开相关的技术。对于我们行业来讲，Facebook的公开，也是一次非常难得的学习机会，造福全行业.

Facebook这个项目，已经研发了2年。因为目标是新建IDC，因此全部都可以采用最新的设计，不用担心兼容性问题。他们的服务器，变电站，电池供电系统，服务器机架都是全新设计的。我们来看看细节。

变电站采用480v的输出电压，我们知道，电压越高，中间的能量变换损失越小 去掉了服务器中无效的部件，尽量提高效能 利用外部的冷空气，冷却机房，利用机房的热空气，加热办公区 多路电源供应，降低单一变电站故障风险

新的IDC能够减少30%的电力供应，降低24%的成本开销

Open Compute Project的核心，和基础是开放硬件系统。 就像我们熟悉的开源软件，硬件设计的开放，也逐渐成为了趋势。目前的Ardunio平台，就是非常成功的一个产品。 开源硬件就像开放软件一样，在颠覆旧有的商业模式的同时，必将创造新的商业生态，同时极大促进他所在领域的技术进步。目前的商用服务器制造商，比如DELL,IBM，Huawei 等，会倍感压力，通用的硬件架构，必将像专业化，定制化的方向发展，开放硬件也给了像英业达，富士康，广达，锐捷等ODM厂商，已新的机会。或许他们中的某位，也会像HTC一样，超越了传统的硬件厂商NOKIA.

下图是OpenCompute 项目，第一代服务器

另外，推荐一篇文章，是关于商业文明，IDC 与工程师文化思考的文章。