CTO俱乐部AWS百度Intel的大数据实践

1、【CTO俱乐部】AWS百度、In tel的大数据实践简介CTO沙龙俱乐部，做中国最有影响力的 TMT技术创业交流平台，依托强大的人脉关系，CTO的技术，相信CTO沙龙都比其他IT投资创业机构都有潜力，让我们互相认识，资源共享，成为朋友。如果你是企业的 CTO、 CEO、创始人、高层人士都欢迎参加， 干货资源共享，跨界结交朋友是我们沙龙一贯的宗旨！ CTO俱乐部是CSDN社区为IT公司的高级技术管理者，如CTO、技术总监、开发总监、工程总监而设计的一个交流、沟通的平台。本次CTO俱乐部活动请到了亚马逊AWS首席云计算顾问方国伟、百度商务搜索部资深研发工程师陈雨强和英特尔中国研发中心主任研究员杨栋

2、，三位嘉宾分别介绍了各自在大数据实践中的一些经验。方国伟：当大数据遇上 AWSAWS概览AWS平台的最终目的是想把IT基础设施和服务的使用变得用水用电一样，提供统一的接口，按需付费。首先是全球的基础设施，然后是数据中心，也就是Region，全球有9个大的Region，其中4个在美国，巴西、爱尔兰、新加坡、日本和澳大利亚各有一个。 为了提高Region的可用性，在下面又分为不同的 AZ（ Applicable Zones ， 可用区），AZ是独立的，是多个数据中心组成的区域，本身是高可用的。比如跨AZ的服务，如果一个 AZ坏了，不会影响其可用性。这个之上是基础服务，包括计算，存储，数据库，网络。

3、再往上是应用服务和部署&管理层。亚马逊提供了从基础设施到应用服务，再到管理等一系列完整的服务，你的应用就部署在这些之上，大家提云计算都会说IaaS，PaaS, SaaS，但就我们来讲，是用户需要什么服务，我们就构建什么样的服务，我们不会考虑你需要的服务到底在哪一层。AWS有多大关于AWS的规模，方国伟举例说：亚马逊在九几年开始做零售业，2003年的时候业务达到了 52亿美金，有7800名左右的员工。到 2013年，AWS每天增加的服务器可以支撑整个亚马逊在2003年的业务。AWS大数据服务大数据对处理速度、数据量和数据存储有很多要求，一个非常好的解决平台和解决方法，就是云平台。首先在AWS的S

4、3上可以存储海量数据，有些客户在AWS上一天产生的数据就可以达到1PB。然后就是大数据的处理，云平台有很多服务器资源，可以并行进行处理大量的计算。另外，因为并不是大数据分析不一定每天都有，AWS可以根据客户的需要来按需按时提供服务，分析完了将服务关闭，就不用付费了，所以大数据的场景很适合云平台。很多平台都有一个Key Application , Windows 上的 Key Application 是 Office，互联网的 Key Application 是 Email，而云平台的Key Application可能就是大数据。|大数据的处理主要分为以下几个阶段：数据生成、数据收集和存储、数据

5、分析和计算、协作和共享。有很多种方式可将数据传输到AWS，包括：控制台上传、FTP、AWS Import/Export 、S3 API、Direct Connect、Storage Gateway、第三方商业应用、Tsunami UDP |然后是数据的分析和计算，AWS很容易实现自动扩展，好处是不需要用钱换时间，一个实例运行100个小时，和100个实例运行1小时，成本一样的。你花同样的钱用不同的方式，可以大大节约时间。2011年AWS还构建了超级计算机，排名达到了421,064个CC2类型的EC2实例，17,024个核240 teraflops 群集 （240万亿次计算/秒）$2,554/小时

6、（100% 按需计算）现在大数据分析用的最多的框架就是Hadoop，很多科学家都需要使用大数据的分析服务，但是Hadoop集群的搭建过程很复杂，让科学家去做这个工作代价太高了。从长远来看，Hadoop会慢慢退到大数据应用的后台，展现在客户面前是一个用户体验较好的界面，用户直接使用大数据分析计算服务即可。亚马逊的EMR服务就是基于这个理念。并且 EMR可以跟其它服务做集成，大数据处理的各个环节，都可以通过EMR串起来。案例互联网上很多流行的服务，都是部署在AWS上的，比如Dropbox和Yelp。Yelp是美国著名的商户点评网站，类似于我们的大众点评网，是AWS的典型用户。Yelp主要的大数据应

7、用包括：自动拼写更正、自动完成搜索关键词和服务推荐。Yelp使用的AWS服务主要有S3和EMR，它会定期把日志传输到S3上去，然后使用亚马逊的EMR服务分析这个日志。分析完之后，数据再放回到S3，EMR服务就可以关闭了。这个过程可能会花几个小时，根据任务的大小。陈雨强：大规模机器学习在百度搜索广告中的应用大数据创造价值陈雨强以百度的凤巢系统为例，给大家介绍了大数据是怎么给百度带来真金白银的。百度的广告搜索现在不是竞价排名，而是靠重视用户体验的凤巢系统实现的。比如你在百度上搜索酒店，左侧是 质量度较高的搜索广告。底下这部分，叫做自然结果，比其它的自然结果更结构化一点，是百度针对不同需求推 出的产

8、品。再底下才是自然的搜索结果。百度用大规模机器学习要解决的问题是：哪些广告会出现在左侧，左侧的广告哪些会在前面，哪些会在后面，哪 些广告展现在左侧会损坏用户体验，什么样的组合会为百度带来最大的收益，会为网民带来最好的体验等。凤巢本质上是百度的搜索广告的变现方式，现在主流的搜索广告的变现方式是CPC( Cost Per Click )变现，按点击来付费，有点击的广告收费，没有点击的广告免费做展现。收入主要是下面这个公式决定的：收入=搜索流量？单位流量广告展示量 ？点击率(CTR)?平均点击价格 可以看到百度的收入取决于四个因素：有多少流量进来，多少流量能产生广告，多少广告能被点，每个点击的价 格

9、。相应的提高收入的方式也包括四种：优化流量、优化点击率、提高出广告的流量、提高评级价格。CTR预估陈雨强重点介绍了百度如何利用机器学习的技术提供更好的CTR预估模型，优化点击率。大数据天生适合于机器学习，让机器去学习数据内在的一些联系，对未来数据预估，它明显会好于人根据经验的预测。百度首先会记录 日志数据，包括所有网民在百度的搜索和点击行为，通过日志来预估将来是否会发生一些点击。在预估的时候，使用特征值作为判断点击的依据。 比如搜索词的商业价值， 一些导航性的关键词如新浪、 网易等, 商业价值很低，广告的点击率就会很低。而鲜花、礼物、钻戒等词，商业价值就很高。采用Logistic regres

10、sion模型。具体的操作流程如下图：百度搜索广告中的拍卖词触发、广告推左、广告排序都是通过CTR预估实现的。CTR优化为了提高性能，百度还进行了一些 CTR优化。百度的很多经验与学术界大相径庭，学术界可能会在小数据集上做很多复杂的模型优化来实现结果的优化。然而在大数据的环境下，不同的模型实现的结果差别并不大，真正产生 差别的是数据量、特征值以及计算规模。所以百度主要从这三个方面进行CTR优化。数据量的优化，主要就是使用更多的数据，增加数据源。特征优化的具体实现如个性化特征，这是去年百度最高奖的获奖项目。百度通过线下数据挖掘，发现每个人点击 倾向，点击行为和兴趣点都是差别很大的，为每个人出相同的

11、广告显然是不合理的。百度就设计了一个模型，使 得每个人看到的广告都基于他之前在百度的搜索历史，这个模型使点击率有了巨大的提升。使用更好的函数优化算法，实现计算规模的优化。在机器学习中有一个损失函数，对损失函数优化得越好，这个 模型会越准确。损失函数是个数据函数，对这个数据函数的优化主要可以采用牛顿法。百度近期进展百度去年成立了深度学习研究所，除了研究所以外，其它各个部门内也在尝试深度学习的工作。商务搜索部也开 始意识到了在机器学习里面，结构是决定一切的根本之一。曾经的网络是一个扁平的网络，特征特别多，但是网 络层次很浅。百度现在计划把它变成这样一个深层的、瘦高的网络。这个瘦高的网络可以通过层次

12、化学到特征之 间的联系。深度学习在广告搜索平台上的应用，最大的问题是计算复杂度，因为特征实在太多。采用一些手段，将比较大的 特征降到比较低的维度上。这个学习系统已经在线上使用，每天为上亿的搜索进行服务，同时用户体验也得到了 很大提升。有了深度学习以后，也可以在将来做一些更加有趣的事情。深度学习会学概念之间的联系，以后搜索广告平台可 能会使用别的产品线的数据，能使用更多的数据，有助于理解用户的搜索习惯。杨栋：Hadoop 至ij Spark （上）杨栋认为，MPI和Spark就像女儿红和洋酒，你选择哪个，完全取决于个人的喜好以及团队的实力。如果你没有百度那么有钱，会构建上百台集群，而且用万兆网卡

13、，来build高性能计算，在上面跑MPI的话，而且要配上MPI的维护人员，加上前端的算法工程师的话，你可能更愿意使用慢一些的Hadoop，或者不太稳定的Spark。我相信在座的大部分还是以几十人的开发团队为主，这样的话你可能更愿意选择一些开发效率更高或更容易开发的系统。每一种系统都有它存在的意义，存在即合理，之所以它存在，就一定有很多的人在用。所以Spark和MPI，以及Hadoop都有它各自适合的场景。Spark是Scala语言写的，Scala本来是基于JVM来写的函数式语言，函数式语言的开发效率很高，但是都会受 到Java序列化和GC的影响。所以这个问题在于这套系统的时间周期是多少，你对性

14、能的要求是多少。杨栋还是更看好 Spark，不是它比 MPI慢一些就不好，而是它的方向是对的，它能做到和Hadoop全兼容。Shark的意思就是 Spark和Hive的接口，另外 Spark也实现了 Storm 这样的Stream Computing。当然它不是 Stream，因为Storm本身是一个tuple 一个tuple的处理，Spark和很多做 MapReduce改进的项目很像，就是把| 数据切成一个个的trunk或一组组的tuple去处理。从这个层面上来讲，Spark的兼容性做的很好。而且，Spark已正式申请加入 Apache孵化器。现在有两条路，一条路是继续卖Hadoop，或者用

15、Hadoop的人，希望 Hadoop变得更快。还有一部分人，要丢 |掉Hadoop，把Spark做得更好，但这部分人还是小众。Hadoop 为什么这么慢Hadoop每个任务都很简单，从HDFS读进来数据，然后做一个Partition ，然后再sort，再Shuffle到每个reduce | 有两个瓶颈，首先是 I/O Bound，没有人考虑数据类型的组织，或者没有人考虑硬件配置。第二，它的算法不是很优化。另外，Java有很多额外的开销。最后是GC的影响。如何加快第一，从IO bound到CPU bound。比如，现在内存便宜多了，意味着Hadoop I/O 的buffer可以调的很大，这样sp

16、lit的次数可以减少，I/O就不是Bound 了。第二，从Cache-aware到Cache-oblivious。其实Sort的性能和 Cache有很大关系，最优秀的工程师应该既懂顶|层的Data Mining，也懂底层的硬件。如果想把性能做到极致，Cache是非常重要的。第三，从Java到C+，比如说压缩，现在所有压缩的都是用C写，Java去调C的时候要用JNI这个接口，这个可能是个瓶颈。优化工作如何保持兼容性Hadoop单机上还有很多的性能可以挖掘，但是做任何优化的时候，你必须要考虑兼容性，兼容在整个行业里要比性能更重要。Hadoop Streaming和Pipes是两个最常用的兼容性改进，它相当于从JVM中抽两块出来，通过标准输入输出或|通过Socket来做数据交互，但它不是从性能的角度出发，是从编程语言的角度出发，目的是为了支持多语言。性能优化的兼容性有两个方法：第一个是把所有的东西都拿到C里去实现。第二个是一个.so的加载。优化后的系统如何保持鲁棒性除了兼容还有鲁棒性，你不能保证你的代码百分之百不出任何问题，但你要保证出现问题时有应对措施。比如，故障超过阈值时会触发自动切换；task执行失败时，可以通过增删一个