Azure介绍WindowsAzure是微软基于云计算的操作系统，现在更名为“MicrosoftAzure”，和AzureServicesPlatform一样，是微软“软件和服务”技术的名称。WindowsAzure的主要目标是为开发者提供一个平台，帮助开发可运行在云服务器、数据中心、Web和PC上的应用程序。云计算的开发者能使用微软全球数据中心的储存、计算能力和网络基础服务。Azure服务平台包括了以下主要组件：WindowsAzure;MicrosoftSQL数据库服务，Microsoft.Net服务;用于分享、储存和同步文件的Live服务;针对商业的MicrosoftSharePoint和MicrosoftDynamicsCRM服务。Azure是一种灵活和支持互操作的平台，它可以被用来创建云中运行的应用或者通过基于云的特性来加强现有应用。它开放式的架构给开发者提供了Web应用、互联设备的应用、个人电脑、服务器、或者提供最优在线复杂解决方案的选择。WindowsAzure以云技术为核心，提供了软件+服务的计算方法。它是Azure服务平台的基础。Azure能够将处于云端的开发者个人能力，同微软全球数据中心网络托管的服务，比如存储、计算和网络基础设施服务，紧密结合起来。Windowsserver虚拟机安装一、点击主页右上角>>门户会登录到后台，看到如图1-1的界面图1-1WindowsAzure二、鼠标移动到左侧虚拟机选项，右侧会出现提示尚未创建虚拟机(图1-1)，点击图1-1中的创建虚拟主机按钮。会看到图2-1中的创建选项，计算>>虚拟机>>快速创建图2-1创建虚拟机虽然是快速创建，但一些必要的信息还是需要我们填写的。DNS名称：3-15个字符，映像：点击下拉菜单进行选择，因为我们这里是创建windowsserver虚拟机，我选择了WindowsServer2008R2SP1(zh-cn)，大小：选择了A2(双核，3.5GB内存)，这两步相当于我们在选择操作系统和配置，可以根据自己需求来选择。设置用户名和密码就很简单了，按照要求填写即可。区域有中国北部和东部，我这里选择了中国东部。然后点击创建虚拟机，详细设置可参考图2-2图2-2WindowsAzure配置信息三、等待创建完成，可能需要花费几分钟，先去泡杯咖啡。创建成功后就能看到图3-1的界面，点击刚才创建的虚拟机按钮。图3-1WindowsAzure虚拟机四、点击仪表盘图4-1WindowsAzure仪表盘五、将鼠标往下移动，在仪表盘页面的右侧会看到输入端点的信息，复制第二个端点(第二个才是windows下的远程连接)图5-1WindowsAzure端点六、点击你电脑的开始菜单>>所有程序>>附件>>远程桌面连接，然后启用远程桌面连接，粘贴刚才我们获取的端点，格式为IP+端口，如图6-1图6-1远程桌面连接七、点击连接按钮后，遇到提示就选择是，然后让你输入用户名和密码。我们在第二步中已经创建，请查看图2-2，最后连接成功。图7-1远程桌面只需要简单的几步就能轻松的创建成功了。
1.Laravel-巨匠级PHP开发框架现在最流行的一款PHP框架，功能强大，学习和使用也非常简单方便，即使你是PHP新手，也不用担心入门问题。2.Phalcon-最快的PHP框架Phalcon是基于C语言的拥有高性能和低功耗等特点的开源PHP开发框架。它是一个全栈的PHP框架，为开发者提供了网站及应用开发所需的大量高级工具。Phalcon中的所有函数都以PHP类的方式呈现，开发者既无需学习和使用C语言，又无需担心性能的问题。性能优越是Phalcon受欢迎的最主要的因素。3.Symfony-开发速度和性能的结合体Symfony是一个基于MVC模式的面向对象的PHP5框架。它具有开源、开发速度快、性能高等特点。但是Symfony2的学习曲线也比较陡峭，没有经验的初学者往往需要一些练习才能掌握其特性。4.CodeIgniter-优雅的PHP框架这个框架非常特殊，它是一个非常老的PHP框架，很快可能就会被淘汰。但是它依然是一个值得一试的框架。5.Yii-快速、安全和专业的PHP框架Yii是一个高性能的，适用于开发WEB2.0应用的PHP框架。Yii几乎拥有了所有的特性，包括MVC、DAO/ActiveRecord、I18N/L10N、caching、基于JQuery的AJAX支持、用户认证和基于角色的访问控制、脚手架、输入验证、部件、事件、主题化以及Web服务等等。Yii采用严格的OOP编写，Yii使用简单，非常灵活，具有很好的可扩展性。6.Aura-干净、完整的PHP类库Aura为PHP5.4及以上版本提供独立的类库，它的代码非常干净，并且真正独立。这些包可以单独使用，也可以将它们合并到开发者自己的框架中。这个框架国内使用的人不多，资料也非常少，不建议使用。7.CakePHP-更简单、更快速、代码更少CakePHP是一个基于PHP的免费且开源的PHP框架，最开始从RubyOnRails框架里得到的灵感。它提供程序员所需要的基本体系架构，因此程序员可以使用它更快速且不失灵活性地创建网络应用程序。另外，CakePHP还拥有一个活跃的开发团队以及社区。8.ZendFramework由最流行最专业的PHPIDE产品ZendStudio的开发商开发，ZendFramework(简写ZF)是开源的，主要用于Web应用程序的开发和服务，ZF采用MVC(Model–View-Controller)架构模式来分离应用程序中不同的部分方便程序的开发和维护。9.FlightFlight是一个快速、简单、可扩展的微型PHP框架，允许用户快速的构建RestfulWeb应用程序，同样易于学习和使用，简单但是很强大！10.KohanaKohana是个开源的、面向对象的MVCWeb框架，是使用PHP5来构建的。它的优点是快速、安全和体积小。11.ThinkPHP -国产的力量ThinkPHP快速、借用了成熟的Java思想，但是实际使用呢过程中有些基本的CURD的关联操作居然存在错误。ThinkPHP基于PHP5，充分利用了PHP5的特性。让我十分喜欢的是ThinkPHP的数据验证和自动填充。但是这个也束缚了ThinkPHP导致不考虑添加自动统计字段等小功能.ThinkPHP还有一个特性是从自动生成数据，但是这个却不支持关联。唉，ThinkPHP有着十分优秀的特性和思想，却有着很一般的应用实践体验。ThinkPHP的文档号称最丰富，事实也是这样，但是ThinkPHP的文档和示例却又太泛泛，比如表关联只介绍了其在model里面的定义，其他的CURD操作都没有提及。12.FleaPHPFleaPHP是一个采用PHP开发（完全支持PHP4和PHP5）的应用程序框架，为开发者创建自己的应用程序提供了必要的基础功能和辅助组件。它成熟、快速、功能丰富。但在一些细节上不如ThinkPHP人性化。如url函数。在FleaPHP中url函数的前两个参数是控制器,动作名，而ThinkPHP恰好相反，因为只输入动作名的情况很多。而且数据库的操作上这种参数的安排也是没有ThinkPHP人性化。FleaPHP对数据的操作很强大，居然可以操作中间表。FleaPHP的文档和示例极少，学习成本大。但是一上手之后就很简单了。FleaPHP框架的核心非常小，但通过灵活的配置，可以组合出各种类型的基础架构。对于简单的脚本页面，FleaPHP不需要载入MVC模式，只需要为应用程序提供业务逻辑和数据库服务。而对于复杂的应用程序，FleaPHP可以完成从MVC模式调用、访问控制、数据验证到文件上传、图片处理等各种各样的任务。正是因为这种出色的定制和扩展能力，FleaPHP真正接近了“满足从简单应用到企业开发的各种需求”这个目标。而且与许多其他框架不同，FleaPHP是一个完全在实际开发中精炼出来的框架。FleaPHP作为一个完全国产的框架，具有完全中文化的文档、代码注释，并且在扩展功能上也注重考虑国内开发者的实际需求。因此相对于国外的各种框架，FleaPHP更容易被国内开发者所接受。
需求毫无疑问，Web框架技术在近几年已经得到了突飞猛进的发展和普及，在过去几年里，框架技术的普遍经历了比较大的完善过程，很大一部分可以归因于RubyonRails，以及在其他编程语言中流露出的MVC框架思想。 如果你是一个PHP忍者，而不是一个铁杆的Ruby追随者，你也许会惊奇市面上已经有这么多的框架，哪一个才是适合你的。当然回答和个问题取决于的诸多因素，今天我们将会回顾一下这个典型的问题，如何为你的下一个应用系统选择适合你的PHP框架。 同时我们也来看一下比较流行的PHP框架，比较一下他们的区别，这样可以帮你自己做出明智的选择，找到最适合你项目的框架。 明确你的需求 在你决定为你的项目选择一个框架之前，你当先理解需要，需求和了解一些开发团队幕后的工作，我们总结出了如下几个问题，在开始下一步之前你可以试着问问自己。 你的应用程序主要集中于解决哪些问题？ 你的应用可以是一个电子商务平台，一个社交网站，消息共享平台或者活动目录，举例来说，如果你正在构建一个电子商务网站，你也许更希望选用一些具有用于处理信用卡和交易会话的成熟的扩展函数库的框架。另一方面，如果是一个轻量级的消息平台（比如说微博类系统），则你也许更应该注重快速的扩展和跨服务器跨数据的支撑访问能力，为了实现负载均衡和快速连接访问。 你的主机运行环境将是什么？ 有些特殊的框架会需要使用到一些非默认的其它PHP扩展或者软件安装在服务器上，比如，有些框架的数据抽象层必须要求通过PDO来实现访问，而非直接调用更底层的MySQL或MySQLi，或者有些类似wiki类的程序的图像压缩和处理功能往往需要使用到ImageMagick或Graphiviz这些外部程序。而这些扩展也许并不会被所有的共享主机环境（虚拟主机）支持，此外即便是一个轻量级的小型框架，而且自我集成了所有所需的函数库并且也具有良好的可移植性和适应性，这样的框架应用在处理数据密集型的操作或者大型数据处理的系统时，性能又会成为它的主要瓶颈。 你的开发人员或团队的优势和劣势在于什么？ 如果你是个项目经理，一个重要的事情是了解清楚你的具体开发人员他们的能力和弱势，因为他们是真的闷头干活儿人，所以也许你可以选择一些更加面向开发人员友好的容易上手的框架。当然这个问题的也许并不是影响决定是否采用一个框架的决定性因素（不断地要求自己和团队学习新的技术总是好的），但着绝对是一个会影响到你的时间表、预算和安全等多方面因素的重要考量条件。 如何在“高耦合性”还是“低耦合性”的框架中做出选择？ 如果从框架产品自身的耦合性来将目前主流的php框架产品分为高耦合性和低耦合性两类。低耦合性的框架看起来更像是一个丰富的函数库和逻辑封装的抽象层，甚至有些好的框架自身就是PHP的一个高级扩展组件，比如PDO，它绝对算得上是一个数据访问的框架也是抽象层。还有一些其他值得一提的低耦合性框架，比如ZendFramework,CakePHP,以及国内开发的ThinkPHP都属于这个范畴。如果你将接手的项目历史问题比较多，并且对UI的自定义比较高，你恐怕需要一个低耦合性的框架来满足你灵活的需求。 另一方面是一些高耦合性框架的代表，比如一些由CRM衍生而来框架类似Drupal,Joomla，还有直接就是为了高耦合性而开发的OpenbizCubi框架，国内小范围流行的框架还有普元等。这些框架的最优秀的特点是可以让你完全只集中于实现你的核心业务逻辑，你甚至不用去管如何实现UI和用户会话管理这些基础特性，你只需要把你的代码和它们提供的接口规范进行“连接”就可以了。如果你负责的项目是一个新的项目，你肯定不希望把大部分的时间都花在实现基础业务逻辑上，比如可能是为客户公司开发一套“停车场管理系统”，还是选择类似OpenbizCubi这样的框架，在其之上直接去实现你的业务逻辑是最对得起你的时间预算和投资回报率的。简单的性能评测案例本次测试输出简单的helloword，简单MVC逻辑，(Router->Controller->Viewer)，没有数据库连接，没有任何逻辑.硬件平台CPU:IntelCorei5750(2.67GHzx4)RAM:4GB软件环境Debian6.0.4x86_64(2.6.32-41)apache2.2.16(mpm-prefork,mod-php5)php5.3.10php-apc3.1.9(Optimizationforinclude/require)Copyallprojectsto/dev/shm/*(Optimizationforfilesread/write)PHP框架列表*zf:ZendFrameworkSite:http://framework.zend.comVer:1.11.11*zf2:ZendFrameworkSite:http://framework.zend.comSite:https://github.com/zendframework/ZendSkeletonApplicationVer:2.0.0-beta1*symfony:symfonySite:http://www.symfony-project.orgVer:2.0.0*cakephp:CakePHPSite:http://cakephp.orgVer:2.0.4*ci:CodeIgniterSite:http://codeigniter.comVer:2.1.0*yii:YiiFrameworkSite:http://www.yiiframework.comVer:1.1.8*micromvc4:MicroMVCSite:http://www.micromvc.comVer:4.0.0*laravel:Laravel,APHPFrameworkForWebArtisansSite:http://laravel.comVer:2.0.2*slim:SlimFrameworkSite:http://www.slimframework.comVer:1.5.0*yaf:YetAnotherFrameworkinPHPExtensionSite:http://code.google.com/p/yafphpVer:2.1.3-beta(yaf.cache_config=1)*FuelPHP:Simple,Flexible,CommunitydrivenWebFrameworkSite:http://fuelphp.com/Ver:1.1*ColaPHP:Site:http://code.google.com/p/colaphp/Ver:1.2-ga#XHProf:AHierarchicalProfilerforPHPSite:http://pecl.php.net/xhprofVer:0.9.2#Thesourcecodeofthistesting:Source:https://github.com/eryx/php-framework-benchmark1.ApacheBenchmarkRequestspresecond(-c100-n30000),thebiggerisbetter请求/秒(-c200-n50000),数值越大越好2.系统负载压力测试一分钟内完成的负载图越小越好(-c100-n30000)3.内存使用率测试helloword占用的内存，越小越好.4.响应时间页面的响应时间.单位微妙5.调用方法的数量(FacebookXHProf)单个helloword页面调用了多少方法，zend5620个方法，是不是太臃肿了。 6.文件数量打开hellowword用到includedorrequiredin文件的数量.越小越好,zend很多,yii19个，yaf才4个，不快才怪。
可视化有许多“规则”。有的是实际的规则，有的则是帮助你做出选择的建议。如果是出于数据的要求，而且你也知道该怎么做，那么许多实际的规则也不必遵守。但是，的确有一些规则不应该违背。这些规则通常是用于一些特定种类、几乎只能用特定方式阅读的图表。当这些规则被打破，阅读过程中，数据有可能被误读。这会有点棘手。条形图的基线必须从零开始条形图依赖长度来呈现数据。短的条块代表较低的值，长一些的则表示较高的值。条形图的原理就是通过比较条块的长度来比较值的大小。当基线被改变了，视觉效果也就扭曲了。举例来说，请看上图。左边第一幅条形图比较了两个值：50和100，它有一条并且它有一条以零为起点的基线。很好。代表数值100的条块长度正好是数值50的两倍长，为100正好也是50的两倍大小。但当你把基线变为一个更高的、非零的值时，第一个条形的长度变短了，而另外一个条形的长度却没有变。此时值为100的条形不再是值为50的条形的两倍长。以此类推，当最后左边代表数值50的条形彻底消失了，意味着100无限地大于50了。条形图的基线必须从零开始。例：这张条形图是经福克斯新闻准许使用的。3月31日目标的值为7,066,000，比6,000,000高17.8%，然而第二个条形几乎是第一个条形长度的三倍。有人也许会反驳说，这张图的重点在于两个值的差而非这两个值本身。即便如此，用条形图来表示本身就是一个错误的选择。使用时间序列来呈现月累积数也许会更好。不要过分热衷于饼图有些人认为，应该完全避免饼图。他们也许是对的，也许又不是。有些人也许会说，使用饼图完全是一种不可原谅的错误。对此，我不同意。不管怎样，事实情况是人们仍然使用饼图，所以我们至少可以争取正确地使用它们。避免过度切割饼图，否则最终对它的阅读将难以为继。那么多少是“太多”？这是一个判断力的问题。不过，如果已经很难从图中看出其中一块扇形是另一块两倍大，或者好几个较小的扇形区域看起来差不多大时，在扇形切割上面就该收手了。此时可以考虑把较小的类目归入一个更大的：“其他”。圆环图也是一样。同时也考虑一下用其他种类的图表来表示比例。不要太依赖于饼图。例：这张饼图来自维基百科，它展示了国家的不同区域。左边这张饼图中已经切割了许多块，但旁边另分离出一张饼图，显示了左图中看不清楚的更小国家的情况，以此来提供更多的信息。有许多方式可以展示这组数据，比如树状图、按照数据比例制作的图标，或者就用普通的地图。单薄的饼图只适用于显示只有几组值的数据。尊重部分所占整体的比例相较于呈现数值，有些图更着重于表现部分与整体的关系，它们表现的数据是部分所占整体比例。比如，堆积式条形图，堆积区域图，树状图，马赛克图，圆环图以及饼图。在这些图表中，每一个部分都表示一个独立的、不重叠的比例。关于这一条，最常见的错误发生在调查问题允许多选时。比如说：“你上周使用了哪一种交通工具？可以多选。”这样的话，在人们多选的问题上就会出现比例的重叠，不同选项的百分比之和大于一。为了避免这种情况，你不能直接把比例做成统计图。例：这张饼图来自福克斯新闻下属机构，它表现了三个不属于同一个整体的百分比。每一个值都是一个单独的整体，因此在这一例中，用三个堆积式条块（或普通的条块）会更直观地表现每个值的比例。展示数据让读者看到数据，这是可视化的重点。如果数据的呈现不够清晰，就违背了做图表的初衷。这常常是因为一张图里的数据太多，于是读者的兴趣就被分散了。这是一个经典的“绘图过度”的问题，相关的研究有很多。但是对于基本的图表，也有一些简单的解决方式。首先是可以改变符号的大小，这样上图中的小圆点（或者是其他的符号）就不会占据太多空间。为了让数据直观清晰，主要要增加空白。调节透明度，多层次的图案就不会被覆盖。通过取样或者把对数据进行分类的方式，把总体分成几个更小的子群。从中，你可以采取小而多的方式，这样每张表里的信息就会少一些。数据进行再统计及分门别类。总而言之，更好地呈现数据。例：这张图展示了金州勇士队在2008-09赛季的每个投篮。这张图最终形成了一个球场的形状，并得出了对于球员们投篮最多的地点的一个小结论——近框，中距离，以及三分球。但是它们之间的差距是很小的，读者并不能看清真正量级上的差距。数据聚合法将有助于解决此类问题。解释编码通过一定的形状、颜色和几何图形的结合，将数据呈现出来。为了让读者能读清楚，图表设计者就要把这些图形解码回数据值。经典的例子是没有标注的坐标轴。有时编码不需要解释。比如说，读者也许知道怎样读条形图，就不必解释条的长度表示的是值的大小了。但是设计者的确应该解释数据，也就是图表的单位和主题。所以标明坐标轴代表的含义。要给读者提供线索或图例，解释图表。例：这个错误标注的图表来自温尼伯太阳报：我们要是能知道这是统计关于什么的问题就好了。2015年数据可视化十佳项目2015年，优秀的可视化作品生机勃勃，我可以确定，明年也会有很多好作品。横跨不同主题和应用形式的项目大量涌现，但如果让我选一个年度主题的话，那一定是“教学”，不管是通过解释说明，模拟说明还是深刻分析的方式。有时候会感到可视化创作者很大胆，试着让读者们不再用惯有的思维方式来理解数据和统计学。我很喜欢这一点。以下是我选出的2015最佳项目。按照惯例，排名不分先后。同时，也有很多不在这个名单上的作品，它们同样很优秀。我们一起来看看它们。1.亲爱的数据这是一个值得跟踪的有趣项目，它涉及的两个话题——可视化和自我监测——引起了我的注意。亲爱的数据是一个StefaniePosavec和GiorgiaLupi做的一年项目。每个人会追踪一周中每天发生的事情，比如每个人接多少次电话，然后把这些数据可视化在一张明信片上。然后他们把这些明信片寄给对方——Lupi现居纽约而Posavec住在伦敦。2.你来画：家庭收入如何预测孩子的大学入学几率感觉今年似乎是挑战读者如何在一个更高的统计学视角上理解数据的一年。纽约时报Upshot的GregorAisch,AmandaCox和KevinQuealy请读者画一条反映家庭收入和上大学孩子数百分比的线。所以你能看到你自己画的线，真实数据画出的线和其他人是怎么看待这个关系的。关于Upshot/NewYorkTimes和数据假设，参见thisquickpuzzletotestyourpattern-findingability（快速测试你的模式识别能力）和3-Dchartoftheeconomy’sfuture（经济未来发展3D图）。3.“黑”出你的科学荣耀纽约时报的538也通过他们的可视化互动进行了一些数据科学教学活动。其中最好的一节课是教人们如何通过“窃取P值”（p-hacking）来从同一数据集中得到你想要的结果.这个项目发布的时候正是一个刚毕业的学生被曝出伪造数据的时候（hyperlink）。ChristieAschwanden和RitchieKing的重点不是怀疑一个荒唐的结果是如何通过了严格的同行评审的，相反，他们想说的是，科学地做研究并解释数据才是真正的难点。4.制作歌曲“你现在在哪里”纽约时报的这个团队做了一个有关JustinBieber的访谈，不仅不错，还很有趣。尽管Bieber更像一个配角，因为Diplo和Skrillex才是详尽研究如何制作一首大卖歌曲的人，但是这个配在视频旁边的音乐可视化作品可以帮助你更好地理解音乐家们到底在说什么。5.麻疹如何在接种了疫苗的儿童中传播及何时不传播卫报的RichHarris，NadjaPopovich和KentonPowell展示了当一个国家的孩子们不接种麻疹疫苗时会发生什么。作为父母，我想把这整个列表做成交互式的。6.机器学习的可视化介绍机器学习似乎像一个有魔力的概念，仿佛意味着一个机器人可以不受你的教导去做奇怪的事。StephanieYee和TonyChu对此用一个可视化例子进行了解谜。这个可视化例子如卷轴般带着你一步一步了解机器是如何“学习”的。过渡图表让整个图衔接得非常顺畅。现有成果似乎是一个系列项目的第一部分，但是我们可能得等一段时间才能看到后面的。7.第二次世界大战的结束NeilHalloran的这个项目的一部分是记录，另一部分是交互式可视化，二者无缝衔接在了一起。我很惊讶地发现并没有很多人做这个类型的项目。当我意识到他们在做这样一个项目时，我非常希望这个能继续下去（阅读更多）。8.2014年是有记录以来最热的一年最直观的可视化这类数据的方式是单线图。但把线进行分解后，我们可以得到更多的信息。彭博社的TomRandall和BlackiMigliozzi做的这张动态图展示了月度平均气温。每条线代表一个完整的年份，随着时间由远到近，这条线在几英寸几英寸地升高。9.网络效应距离上一次看到JonathanHarris的这类项目已经过去一段时间了他和GregHochmuth合作了这个项目，“网络效应”是对整个互联网的点评，可以让人通过一种奇妙而引人入胜的方式了解互联网的方方面面，一次花几分钟。10.常用比喻“比喻修辞是写作者常用的，在读者脑海中有特定形象的，一种工具和写作习惯”。Bocoup数据可视化团队做的“常用比喻”项目研究了比喻修辞中常用的词。如果你想了解电影里的性别角色和人物性格，这个项目正是你要找的那个。
用户管理微博是一个很多人都在用的社交应用。天天刷微博的人每天都会进行着这样几个操作：原创、转发、回复、阅读、关注、@等。其中，前四个是针对短博文，最后的关注和@则针对的是用户之间的关系，关注某个人就意味着你成为他的粉丝，而他成为你的好友；@某个人意味着你想要他看到你的微博信息。微博被人们认为是“自媒体”，即普通大众分享与本身相关的“新闻”的途径。最近，有些人使用自己在自媒体上的影响力而盈利的报道屡见不鲜。那微博上个人影响力是怎样计算的呢？微博上还有哪些算法作为看不见的手在管理着我们？我们的每一个行为怎样影响着算法呢？直观上看，微博其实是人类社会的一个简单的缩影，微博网络的一些特点，也许可以启发我们得到真实的社会网络上的规律。得益于社交网络的爆发式发展，“社会计算”尤其是社交网络分析成为数据挖掘的新宠儿。下面我们就针对微博网络分析的一些算法进行简单的介绍，其中的有些算法对于其他的社交应用可能也适用。1.标签传播微博用户量浩大，不同的人有不同的兴趣。挖掘每个用户的兴趣有助于更加精准的广告投放、内容推荐。为了得到每个用户的兴趣，可以为用户打上标签，每个标签代表用户的一个兴趣，用户可以拥有一个或多个标签。为了得到最终的用户标签，先做第一个假设：每个用户的好友(或粉丝)中与该用户具有相同兴趣的人占多数。这就引出了本文介绍的第一个算法，即标签传播算法。在这个算法中，每个用户的标签取其好友或粉丝中标签最多的一个或多个。当然，可以将好友和粉丝的标签都考虑进来，整合的时候可以考虑赋予好友的标签和粉丝的标签不同的权重。标签传播算法的过程如下：1)对一部分用户给出初始标签；2)对每一个用户，统计其好友和粉丝的标签数目，赋予该用户出现次数最多的一个或者多个标签。3)循环进行第2步，直到用户的标签不再发生大的变化为止。2.用户相似度计算标签传播算法实现起来比较简单，其缺点在于当所做的假设不符合事实时，比如为了社交上的礼貌，我们一般会把自己的亲友添加关注，这些人不一定和我们拥有同样的标签；该算法的结果就会变得很差。解决的办法就是通过计算用户之间的相似度来衡量好友或粉丝的标签对用户标签的贡献率。因而得到第二个假设：与用户越相似的好友或粉丝，其标签越可能是用户的标签。那么，如何衡量用户之间的相似度呢？这就需要考虑到用户发表的微博信息了，包括转发的和原创的。这里是要考虑用户之间的相似度而不是用户微博之间的相似度，因而在实际计算时，将某个用户的所有微博信息聚集到一起进行计算。一个可选的方法是使用词袋法将微博信息表示成词语向量，然后直接使用余弦方法等计算其相似度。但这个方法太过简单，不容易达到好的结果，这里介绍一种基于LDA（隐含狄利克雷分布）的相似度计算方法。LDA仍然使用词袋法表示文本，但是在中间添加了一个主题层，形成了“文档-主题-词语”三层概率模型，即每篇文档看成是主题的一种概率分布，主题又被看成是单词的概率分布。在LDA模型下，文档可以被看成按照如下方式生成：1)对于每篇文档：2)从主题分布中抽取一个主题；3)从该主题的词语分布中抽取一个词语；4)重复第2步和第3步，直到该文档的所有词语都生成。LDA模型参数的估计算法不在本文的讨论范围之内。这里只需要知道，通过LDA可以得到每个用户的微博信息的主题分布。然后使用余弦方法、KL距离等计算相似度的方法来得到用户间主题分布的相似度，以之作为用户之间的相似度。而后使用该相似度对标签传播进行加权。3.时间因素和网络因素上述的算法还有什么缺点呢？随着时间的变化，用户的兴趣是会变化的，计算用户相似度的时候每次都把所有微博信息都聚合在一起不太合理。对此，可以通过选取距离当前时间较近的N条微博。比如，对每个用户，选取距离当前时间最近的50条微博聚在一起放到LDA中训练。此处的N既不能太大也不能太小。太大则不容易反映用户兴趣的时间变化，太小则由于用户发表微博的随机性容易引起兴趣的漂移。为了使效果最好，可以不拘泥于一个固定的N，比如可以考虑对每个用户按照其发表微博的时间序列做N值的自适应。至此，在算法中还没有考虑微博关系中由回复、转发、@等所构成的网络信息。以转发为例，如果在用户的微博中频繁的转发某个好友的微博，那么用户和该好友的相似度相比其他好友来说应该会更高。这里可以看做是假设三：用户转发某好友的微博的频率越高，用户与该好友的兴趣相似度越大。相似的，可以得到假设四：用户微博中@某用户的频率越高，用户与该好友的兴趣相似度越大。由此就得到了计算相似度的另外的因素。有很多方法可以添加一个新的因素到原有的相似度计算方法中，比如可以考虑将转发频率量化为值，作为权重添加到相似度的衡量中去。4.社区发现微博社区是指在微博中关系紧密的人组成的团体，社区内部的人之间联系紧密，社区之间的联系则比较稀疏。这里所指的关系紧密有两层含义，第一是社区内部的人之间的兴趣相似度大；第二是指社区内部的人之间的关系要近，比如要求社区内部的两个用户不能超过二度关联，二度关联即好友的好友。兴趣相似度在上文已有叙述，关系相似度则需要利用用户之间的关注关系来进行计算。以用户的关注关系为单向链，可以将所有的微博用户之间的关系表示为一个巨大的有向图。用户之间的关系相似度可以简单的考虑，比如使用用户间的最短路径的倒数。但是这种方法衡量的不精确，我们知道，在现实世界中，存在着六度理论，在微博网络及其他社交网络中，往往关系会更加紧密。因而这种简单的关系相似度只能有至多六个离散值，显然不够精确。为了达到更好的效果，这里不仅以最短路径作为显式量度，还要考虑一些隐式的量度。这里先给出两个假设，分别为假设五和假设六：两个用户的共同好友越多，这两个好友的关系相似度越高。两个用户的共同粉丝越多，这两个好友的关系相似度越高。这里可以借鉴Jaccard相似度的计算方式，将这两种假设的量化函数表示为交集的大小与并集的大小之商。以假设五为例，其量化指标又被称为共指向性相似度，量化时使用两个用户共同好友的数目除以两个用户所有好友的数目。假设六的量化指标被称为共被指向性相似度，计算方式与共指向性相似度类似。从意义上讲，这两种相似度不仅仅是关系上的度量，在一定程度上也衡量了用户之间的兴趣相似程度，直观上看，两个用户共同关注的好友越多，他们的兴趣相似程度也越大。这两种相似度还有一个专业的名字，是基于结构情景的相似度计算。得到了最短路径相似度、共指向性相似度、共被指向性相似度后，可以采用一种加权函数将它们融合起来，得到最后的相似度。之后，可以采用一些聚类算法如K-Means、DBSCAN等进行聚类操作，得到最后的社区簇。也可以采用相似度加权的标签传播算法，把具有相同标签的人作为一个社区。5.影响力计算在社区发现中，使用微博中的关系网络可以提高相似度计算的精确度。但关系网络能做的事情还有很多，影响力计算便是其中比较重要的应用。说到影响力的计算，这里借鉴了网页排名中的算法。网页排名中广为人知的算法当属PageRank了，该算法由google创始人拉里·佩奇和谢尔盖·布林发明，随着google在商业上的成功而声名鹊起。该算法根据网页之间的链接来确定网页的排名，其核心在于一个假设，质量高的网页所指向的网页的质量必定也高。根据PageRank的思想，可以得到微博上影响力的假设，称之为假设七：影响力高的用户关注的用户的影响力必定也高。将用户看成是PageRank中的网页，将关注关系看做是网页中的链接关系。从而，可以根据PageRank的算法流程得到在微博关注网络上的影响力计算算法：1)赋予所有用户相同的影响力权重；2)将每个用户的影响力权重按照其关注的人数等量分配；3)对每个用户来说，其影响力等于其粉丝分配给他的权重之和；4)第2步和第3步迭代，直到权重不再发生大的变化为止。在网页排名中，基于网络关系的算法还有HITS、HillTop算法等，这些算法也可以借鉴到影响力计算中来。上面的算法有什么缺点呢？如果只是基于关系网络的话，那么很容易就造成，粉丝数目多的人影响力必然会很高。这样就导致有些用户去购买一些僵尸粉就可以达到很高的影响力了。这样的算法显然是不能应对实际情况的，因为还有太多的信息没有用到。用户的影响力除了他的微博关系之外，还与他的个人属性有很大的关系，比如用户的活跃度、微文的质量等。用户的活跃度可以使用其发表微博的频度来衡量，微文的质量可以采用其被转发的数目、被回复的数目来得到。通过对这些值进行衡量，再加上上面算法的结果，就可以得到更加精确的影响力结果。当然，也可以这样考虑，用户之间的回复关系、转发关系、@关系均可以构成网络，它们也有相应的假设，分别为假设八、假设九、假设十：影响力越高的用户回复的微博的影响力越高，从而使该微博主人的影响力变高。影响力越高的用户转发的微博的影响力越高，从而使该微博原创作者的影响力变高。影响力越高的用户倾向于在其微博中@影响力高的用户。这样就又得到了转发网络、回复网络、@网络三种网络，借鉴PageRank算法，可以得到另外的三种影响力结果。将它们与关系网络的影响力结果进行融合，就可以最终的影响力结果了。这里的融合可以简单的考虑成结果的加权和，复杂的融合方法不在本文的范围之内。6.话题因素和领域因素得到了影响力的计算方法之后，可以做些什么呢？可以对当前的热点话题进行影响力分析，得到谁在微博上成为当前热点话题的意见领袖。具体做法是这样，找到和当前热点话题相关的微文，从而找到参与当前热点话题的用户。如何找到和当前热点话题相关的微文呢？有话题标签的微文自不必说，对于没有话题标签的微文来说，可以使用上文中介绍的LDA算法，它可以在用户的所有微文中找到用户的主题分布，也可以对一条微文找到主题分布，一般来说，由于微文的字数限制在140以内，比较短，因而一条微文包含的主题数目不会太多，取该微文的主题分布中概率最高的主题当做其主题即可。找到话题对应的微文与用户之后，运行影响力计算算法，就可以得到该话题中影响力较大的用户了。这也是舆情监测、社会热点监控的一个方面。对于标签传播算法得到的结果，对同一标签下的用户运行影响力计算算法，可以得到该标签下的影响力排名，即领域内影响力排名。比如，李开复在全部领域内的影响力或许不是最高的，但在IT领域，其影响力绝对是数一数二的。7.垃圾用户识别在影响力计算中，提到要避免僵尸用户对影响力计算的干扰。在算法中，如果可以识别这样的用户，在计算影响力时将其排出在外，不仅可以提高效果，还可以降低计算量。与影响力计算相似，垃圾用户的识别要同时考虑用户属性与链接关系两方面的因素。对于垃圾用户来说，有一些统计上的特征与正常用户不同。比如如下几点：垃圾用户一般发微文具有一定的时间规律性，可以使用熵值对此进行衡量，熵是衡量随机性的一种量度，随机性越大，熵值越小。具体做法为将一定的粒度进行时间切片统计，得到每个时间片内的博文概率，然后依照概率进行熵值的计算。熵值越大代表用户发微文的时间越有规律，越有可能是垃圾用户。垃圾用户有些倾向于在微文中恶意的@其他人，因而有些垃圾用户的微文中@使用的比例比一般用户高。有些垃圾用户的微文中为了进行广告的推广，添加大量的URL。可以通过微文中的URL比例进行衡量。也有些用户为了骗取URL的点击，微文中的内容与URL对应界面的内容不一致，这时需要判断微文与URL内容的一致程度，简单的做法可以使用词袋法将微文与URL对应界面表示成词语向量，查看微文中的词语在URL对应网页中出现的频度。对于那些为做广告推销的用户，还可以对其微文进行文本分类，判断其微文是否是广告，如果某用户的相当一部分微文是广告，则该用户可能是垃圾用户。垃圾用户一般随意的关注用户，故其粉丝数目与好友数目的比例与正常用户会有差别。而且正常用户一般是通过好友关系添加好友的，这样会形成关注三角形，如A看到其好友B关注了C，那么若A也去关注C，就形成了A关注B、C，B关注C的三角形。一般来说，由于垃圾用户关注的随意性，其关注三角形的比例与正常用户不同。当然，垃圾用户与正常用户的不同之处不止这些，本文不再一一枚举。垃圾用户的识别本质上是一个二分类问题，获得了这些属性之后，就可以将这些信息输入到一个机器学习的分类模型中，比如逻辑斯蒂回归（LR）、决策树、朴素贝叶斯等，就可以对其进行分类了。当然，还没有用到链接信息。一般来说，垃圾用户会去关注正常用户，而正常用户不会关注垃圾用户。这即是假设十一：正常用户不倾向于关注垃圾用户。这样就可以再次使用PageRank算法来对用户是否是垃圾用户的概率进行计算。这里需要注意的是，算法初始化时采用上面的分类器结果，将垃圾用户的概率设为1，正常用户的概率设为0。在PageRank计算过程中，不能通过简单的求和公式计算，比如如果一个用户关注了多个垃圾用户的时候，求和后概率可能大于1；因而需要使用一些归一化方法或指数族函数进行概率的更新。大数据利用1.聚合、计算、输出、反馈形成数据和业务闭环微博大数据其实是一个很闭环的业务，从底下的原始数据开始，微博一条一条的文本，实际都是非结构化数据。通过自然语言处理的技术，把每一条文本内容提取出来，之后放在底层网络上。如一个客户对一家饭的评论内容，将内容提取后就放到这个饭店的边框上。基于文本处理还可以做语义的分析，把这些非结构化的内容进行结构化，再上一层达到算法层，这个算法实际就是跟不同场景不同的算法，到达用户端，用户端再回到底层的数据算法当中。因此整个过程并不是一个孤立的，而且跟场景的理解关系非常大。每个点都非常灵活，要把这个合力用到整个闭环上。2.平台化思路建设计算能力、数据能力、服务能力大数据本身的建设如果从效率提升来讲，其实是一个平台化的东西。微博的在线场景非常多，每个在线场景都会留下用户的行为。所以对微博来说，大数据的建设是一个平台化的思路。所谓平台化的思路，要从不同的场景里面去做足够的抽象，这个抽象有三层含义，一个数据结构的抽象，还有一个是策略算法的抽象，还有就是输出的抽象，三个层面的抽象。从场景上来说，会分成内容流，用户流，推荐搜索，还有开放平台的输出，还有离线报告的应用，不同的业务，不会去针对每个业务特点去做，而会把场景要用的策略算法做一个梳理，具体在工程实施的时候，有一些是需要批处理的，有一些是需要流处理的。3.结合云计算技术挖掘大数据价值新浪微博数据类型非常多，内部分基本是几十个领域，而每个领域从一开始都是从底层往上做，做数据非结构化到结构化的转化。但是走到一定阶段，如果想要做到场景级别，还是需要垂直领域的理解。新浪有各个频道，跟音乐、电影这些门户频道有比较深入的合作，到这个阶段并不是技术层面的事情，而是跟垂直领域，跟行业关系密切。另外新浪微博也跟外面合作伙伴有一些合作，这些合作伙伴会把算法部署到新浪的计算环境当中来，因为毕竟涉及到一些数据的问题，不可能把这个开放的程度过大。如果能够有技术合作的公司把垂直领域的理解还有他们的算法部署在我们这个环境之上的话，他们获得数据的范围可以更大，这个也是新浪微博后面的一个发展方向。新浪微博提供一个云环境，在这个环境里面，可以用到基础的数据，微博基础数据。另外还可以用到大数据这边已经做到的一些标签，还有自然语言处理这些内容，甚至就是这些合作伙伴可以基于新浪微博提供的基础数据，还有挖掘出来的标签，他自己挖掘的标签，做一些APP，来满足用户的诉求。4.建立合作更好的满足客户需求新浪微博跟一些其他领域合作伙伴进行多方面的尝试。目标主要是围绕用户的衣食住行各种需求，目前已经跟央视索福瑞有一些合作，这是已经上线的产品，后台的数据包括给微博文本打上标签，还有大家平时见到的曲线图。在微博电视指数里面，想表达的是某一款电视在播出的时候，在社交媒体上会有口碑的影响力，还会有用户的覆盖度，这些都是节目制作方，电视台都非常关心的内容。我们从后台的数据来看，某一款节目在播前、播中、播后都有一个曲线，这个曲线那来之后，比如《爸爸去哪儿》，比如《中国好声音》，这款产品究竟在哪个地区哪类用户有非常好的反响，这个用户是什么年龄群的，微博上观众经常关注什么，看什么，在这样一个场景里面新浪微博都能够获得。前端展示出来的就是一个微博电视指数，但是后台其实还有很多要做的事情。5.开放微博大数据和云计算环境整个微博大数据建设的过程当中，也希望能够跟有共同服务用户这一点理解诉求一致的行业的合作伙伴去进行合作。这里面微博这边能够开放出来的就是UGC的内容流，还有基于微博这个生态体系所打的用户方面的一些标签。还有能够提供一个开放云计算的环境，具体合作也有三个层面，最基础的就是数据这个层面的合作，比如数据的互补，对奇。第二个是场景层面，比如在微博这个场景上面一些功能，用户在使用微博的时候，互联网产品本身就是在创造场景，不断满足人细分场景下的需求。新浪微博跟这个垂直行业的伙伴一起寻找，在其他场景还有哪些可以做的。第三个就是产品的层面，这个形式不一定在微博内，具体什么形式不确定。
序言微博平台第一代架构为LAMP架构，数据库使用的是MyIsam，后台用的是php，缓存为Memcache。随着应用规模的增长，衍生出的第二代架构对业务功能进行了模块化、服务化和组件化，后台系统从php替换为Java，逐渐形成SOA架构，在很长一段时间支撑了微博平台的业务发展。在此基础上又经过长时间的重构、线上运行、思索与沉淀，平台形成了第三代架构体系。我们先看一张微博的核心业务图(如下)，是不是非常复杂?但这已经是一个简化的不能再简化的业务图了，第三代技术体系就是为了保障在微博核心业务上快速、高效、可靠地发布新产品新功能。 第三代技术体系微博平台的第三代技术体系，使用正交分解法建立模型：在水平方向，采用典型的三级分层模型，即接口层、服务层与资源层;在垂直方向，进一步细分为业务架构、技术架构、监控平台与服务治理平台。下面是平台的整体架构图：如上图所示，正交分解法将整个图分解为3*4=12个区域，每个区域代表一个水平维度与一个垂直维度的交点，相应的定义这个区域的核心功能点，比如区域5主要完成服务层的技术架构。下面详细介绍水平方向与垂直方向的设计原则，尤其会重点介绍4、5、6中的技术组件及其在整个架构体系中的作用。水平分层水平维度的划分，在大中型互联网后台业务系统的设计中非常基础，在平台的每一代技术体系中都有体现。这里还是简单介绍一下，为后续垂直维度的延伸讲解做铺垫：接口层主要实现与Web页面、移动客户端的接口交互，定义统一的接口规范，平台最核心的三个接口服务分别是内容(Feed)服务、用户关系服务及通讯服务(单发私信、群发、群聊)。服务层主要把核心业务模块化、服务化，这里又分为两类服务，一类为原子服务，其定义是不依赖任何其他服务的服务模块，比如常用的短链服务、发号器服务都属于这一类。图中使用泳道隔离，表示它们的独立性。另外一类为组合服务，通过各种原子服务和业务逻辑的组合来完成服务，比如Feed服务、通讯服务，它们除了本身的业务逻辑，还依赖短链、用户及发号器服务。资源层主要是数据模型的存储，包含通用的缓存资源Redis和Memcached，以及持久化数据库存储MySQL、HBase，或者分布式文件系统TFS以及SinaS3服务。水平分层有一个特点，依赖关系都是从上往下，上层的服务依赖下层，下层的服务不会依赖上层，构建了一种简单直接的依赖关系。与分层模型相对应，微博系统中的服务器主要包括三种类型：前端机(提供API接口服务)、队列机(处理上行业务逻辑，主要是数据写入)和存储(mc、mysql、mcq、redis、HBase等)。垂直延伸技术架构随着业务架构的发展和优化，平台研发实现了许多卓越的中间件产品，用来支撑核心业务，这些中间件由业务驱动产生，随着技术组件越来越丰富，形成完备的平台技术框架，大大提升了平台的产品研发效率和业务运行稳定性。区别于水平方向上层依赖下层的关系，垂直方向以技术框架为地基支撑点，向两侧驱动影响业务架构、监控平台、服务治理平台，下面介绍一下其中的核心组件。接口层WebV4框架接口框架简化和规范了业务接口开发工作，将通用的接口层功能打包到框架中，采用了Spring的面向切面(AOP)设计理念。接口框架基于Jersey进行二次开发，基于annotation定义接口(url,参数)，内置Auth、频次控制、访问日志、降级功能，支撑接口层监控平台与服务治理，同时还有自动化的Bean-json/xml序列化。服务层框架服务层主要涉及RPC远程调用框架以及消息队列框架，这是微博平台在服务层使用最为广泛的两个框架。MCQ消息队列消息队列提供一种先入先出的通讯机制，在平台内部，最常见的场景是将数据的落地操作异步写入队列，队列处理程序批量读取并写入DB，消息队列提供的异步机制加快了前端机的响应时间，其次，批量的DB操作也间接提高了DB操作性能，另外一个应用场景，平台通过消息队列，向搜索、大数据、商业运营部门提供实时数据。微博平台内部大量使用的MCQ(SimpleQueueServiceOverMemcache)消息队列服务，基于MemCache协议，消息数据持久化写入BerkeleyDB，只有get/set两个命令，同时也非常容易做监控(statsqueue)，有丰富的clientlibrary，线上运行多年，性能比通用的MQ高很多倍。MotanRPC框架微博的MotanRPC服务，底层通讯引擎采用了Netty网络框架，序列化协议支持Hessian和Java序列化，通讯协议支持Motan、http、tcp、mc等，Motan框架在内部大量使用，在系统的健壮性和服务治理方面，有较为成熟的技术解决方案，健壮性上，基于Config配置管理服务实现了HighAvailability与LoadBalance策略(支持灵活的FailOver和FailFastHA策略，以及RoundRobin、LRU、ConsistentHash等LoadBalance策略)，服务治理方面，生成完整的服务调用链数据，服务请求性能数据，响应时间(ResponseTime)、QPS以及标准化Error、Exception日志信息。资源层框架资源层的框架非常多，有封装MySQL与HBase的Key-ListDAL中间件、有定制化的计数组件，有支持分布式MC与Redis的Proxy，在这些方面业界有较多的经验分享，我在这里分享一下平台架构的对象库与SSDCache组件。对象库对象库支持便捷的序列化与反序列化微博中的对象数据：序列化时，将JVM内存中的对象序列化写入在HBase中并生成唯一的ObjectID，当需要访问该对象时，通过ObjectID读取，对象库支持任意类型的对象，支持PB、JSON、二进制序列化协议，微博中最大的应用场景将微博中引用的视频、图片、文章统一定义为对象，一共定义了几十种对象类型，并抽象出标准的对象元数据Schema，对象的内容上传到对象存储系统(SinaS3)中，对象元数据中保存SinaS3的下载地址。 SSDCache随着SSD硬盘的普及，优越的IO性能使其被越来越多地用于替换传统的SATA和SAS磁盘，常见的应用场景有三种：1)替换MySQL数据库的硬盘，目前社区还没有针对SSD优化的MySQL版本，即使这样，直接升级SSD硬盘也能带来8倍左右的IOPS提升;2)替换Redis的硬盘，提升其性能;3)用在CDN中，加快静态资源加载速度。微博平台将SSD应用在分布式缓存场景中，将传统的Redis/MC+Mysql方式，扩展为Redis/MC+SSDCache+Mysql方式，SSDCache作为L2缓存使用，第一降低了MC/Redis成本过高，容量小的问题，也解决了穿透DB带来的数据库访问压力。垂直的监控与服务治理随着服务规模和业务变得越来越复杂，即使业务架构师也很难准确地描述服务之间的依赖关系，服务的管理运维变得越来难，在这个背景下，参考google的dapper和twitter的zipkin，平台实现了自己的大型分布式追踪系统WatchMan。WatchMan大型分布式追踪系统如其他大中型互联网应用一样，微博平台由众多的分布式组件构成，用户通过浏览器或移动客户端的每一个HTTP请求到达应用服务器后，会经过很多个业务系统或系统组件，并留下足迹(footprint)。但是这些分散的数据对于问题排查，或是流程优化都帮助有限。对于这样一种典型的跨进程/跨线程的场景，汇总收集并分析这类日志就显得尤为重要。另一方面，收集每一处足迹的性能数据，并根据策略对各子系统做流控或降级，也是确保微博平台高可用的重要因素。要能做到追踪每个请求的完整调用链路;收集调用链路上每个服务的性能数据;能追踪系统中所有的Error和Exception;通过计算性能数据和比对性能指标(SLA)再回馈到控制流程(controlflow)中，基于这些目标就诞生了微博的Watchman系统。该系统设计的一个核心原则就是低侵入性(non-invasivenss)：作为非业务组件，应当尽可能少侵入或者不侵入其他业务系统，保持对使用方的透明性，可以大大减少开发人员的负担和接入门槛。基于此考虑，所有的日志采集点都分布在技术框架中间件中，包括接口框架、RPC框架以及其他资源中间件。WatchMan由技术团队搭建框架，应用在所有业务场景中，运维基于此系统完善监控平台，业务和运维共同使用此系统，完成分布式服务治理，包括服务扩容与缩容、服务降级、流量切换、服务发布与灰度。cache设计这里简单说一下两个部分，一部分是Feed架构简介，第二是cache的设计。微博技术核心主要三个，一条微博有很多关注的人，分别将你发表的微博分发到你所有关注的人，聚合就是打开微博首页这里看到我关注人的信息，以及这个微博信息的展现，微博在技术上也称之为status或者Feed，下面图就是一个典型的Feed。Feed架构刚才是两种设计模式推或者拉，还有第三种方式叫做复合型。做到一定程度单纯推或者拉是不够的。推的话如果把Feed比喻成邮件，推就是inbo不惜是收到的微博，OUTPOX是已发表的微博，发表到所有的粉丝，查看就是直接访问到。PUSH优点就是实现简单，通常做一个种型是首选方案，缺点就是分发量。PULL发表是在自己的outbox，查看是所有关注对象的inbox。优点节约存储，缺点是计算大量，峰值问题。当前访问量比较大是不是计算得过来，服务器是不是够用，假如说你的服务器是按照你峰值规划你的服务器，在平时时候是非常多的空闲，这个是不合理，不管推和拉都有一些共同的难题比如说峰值的挑战，比如说世界杯活动在新浪微博每秒钟发表量达到2500条，可以使用异步处理2500个峰值，处理速度慢一点，你关注人不能马上看到，峰值过后保证系统不会被峰值压跨，下面就是cache，现在有一句话对于这种real—time就是说：传统硬盘已经不够用，很多东西要分放在硬盘里面才能满足需求。因此cache设计决定了一个微博系统的优劣。里面是一种复合型，不是一个简单的推或者拉的类型，因为就是说像新浪微博到这个级别要做很多优化，从模型上就是一个推或者拉的模型，按照它的关系来说，把cache分成需要四种存储的东西，这两个里面跟索引比较类似，第三就是列表和客户自己资料。看一下第一部分就是inbox微博首页开始ID列表，完全是内存里面，但是有一个缺点，要添加元素需要先AET再SET；第二部分outbox发出微博有存储最新ID在于聚合。为了高效，通常分两部分，第一就是说最新的一个ID列表比如说有100条内容，这个用户很久没有来，这个是空要过来取就要从我工作列表用ID地址聚合起来；第三部分是关注列表，这些都是纯ID，然后following，following加载开销比较大，上百万粉丝，越大的集合越容易变更，改变则需要deleteall减少使用followinglist场景；第四部分contetcache微博内容体里面有一个很重要的内容，热内容。这个用户有200万粉丝，这个内容是热内容，在线粉丝也非常多，多分防止单点访问瓶颈，最终格式预生成，apenAPI需要返回xml，json格式。刚才说了介绍cache的架构，现在介绍cache的第二个方面就是使用流程。有一个典型的场景，比如说发表cache怎么操作，首页展现怎么操作。发表需要改变三个内容，首先要声称contentcache，对于常规contentcache也要做复制，如果对方粉丝在线会在inbox数值ID变更。第三方面修改outbox，根据粉丝列表修改inbox数据列表，然后首页Feed操作流程。左边有两个：inbox，outbox。两个是可选的，如果inbox没有一个树型计算，会根据ID列表聚合起来反馈给I用户。获取首页Feed的流程，首先间看inbocache是否可用，获取关注列表，聚合内容从following关系，根据idlist返回最终Feed聚合内容。最常用两个流程就是这样。下面介绍微博cache经验谈，首先说流量。打开首页，这个时候打一个I来说，比如说contentcache为例，比如multigntn条Feed，cache大小等于N，并发清且如1000次/秒，总流量等于50，20K。假如微博机房里面有1万并发需要800MBPS贷款，如果不改变价格这个流量是实现不了。再一个1G内网做了很多压力测试，一般环境跑三四百兆已经不错了，你网内不光是访问cache开销，还有很多其他流量，因此微博需要优化带宽访问，可以把热门数据加载到localcache，要用压缩算法，可以做复制，有的时候将一个内部cache分组，不同的服务器组，访问不同的cache减少内网通信的开销。第一个问题就是带宽的问题，其中内销cache开销访问量大第一会碰到瓶颈。第二问题就是hotKeys，要访问姚晨的微博，要建设一个Ilocolcache，删除时间要把所有的都删除。cache规划方面一些问题，将不同业务，不同长度KEY存储到不同的MEMcache，不同的业务有不同的生命周期，LRUcache小量，memorystorage大部分，更高效的内存利用。mutex，什么情况会出现这个问题，比如说一个很热的内容，cache里面没有了，因为memcache不是很可靠的东西，你放在里面可能会消失，经常出现这样的情况：一个很热的cache没有了，因为微博系统有很多并发很热数据没有了，非常多的并发如果微博没有一个很好的策略，比如说几十个，几百个加一个内容这会是一个悲剧。给每个KEY加载MUTEX，这个并发连接取数据库，然后把mutex删除成规，这个时候我只需要一个连接，数据库加载到BD里面有可以了。因为前面已经介绍很多内容，我今天介绍一个很简单的东西就是想关注更多微博平台的技术，有三个方向一个就是S2技术沙龙，每个月举行一次，另外就是说对很多讲师光做讲座不过瘾，讲座只是传授别人东西，没有能够交流，所以微博对一线架构师有一个自己线下交流，一些实际中遇到的问题，对这些架构师有帮助提高，交流一下自己正在做，或者有一些东西还不成熟，不适合拿出来讲的东西，可以线下交流。另外微博有各新浪微博开发大会，会介绍更多微博平台架构分享的东西。S2技术沙龙介绍了希望关注分享Web2.0技术，下面有一个它的网址，另外就是说介绍一下即将举行一个新浪微博开发者大会，主要除了宣传作用，希望更多分享新浪微博技术，比如说这个平台需要架构与存储，可能到时候讲比今天更深入一些，会讲一些sinaappengine技术，数据挖掘，合作与商业模式，开发者与平台。目前有一个开发平台的网站。
我国互联网发展20多年，通过互联网创业的人不在少数，并且有人总结互联网草根创业指南为：从建站到融资六部曲。其实，无论是创业还是出于爱好，搭建网站已经变得十分简单。即使没有一点相关技术的新手，只要遵循基本的建站流程，也能轻松搭建相对专业的网站。那么，新手搭建个人网站的步骤有哪些呢?主机侦探小编这里给大家介绍一下基本流程：1.注册域名。域名是网站在网络上的门牌号，方便访问者快速找到你的网站;同时也是网络上的名片，一个个性、简单和易记的域名可以让你在互联网中拥有自己的网站品牌形象，像“A5站长网”的域名admin5.com就是一个很好的例子。域名需要在域名注册商那里注册，国内外有很多域名注册商，这里小编推荐国内的万网和国外的GoDaddy，他们都是比较知名的域名注册平台。2.购买空间。空间的作用是存储你网站网页、数据库等数据的。网站空间有很多种，虚拟主机、VPS、独立服务器等，个人站长选择虚拟主机就行了，既满足需求也降低成本。另外虚拟主机只需通过图形化的操作界面简单管理即可，而VPS和独立服务器还需要一定的技术，不适合新手站长。提供网站空间的服务商也有很多，这里小编推荐美国知名主机商HostEase，访问速度快而且不用备案，买来即用。3.选择程序。程序的选择同样是网站建设中重要部分，个人站长可以独立开发网站程序也可以选择现成的。如果没有建站经验的新手，建议直接使用现成的网站程序。网上的网站程序有很多，有WordPress博客程序、Shopex商城程序、织梦CMS管理系统等等，想要搭建什么类型的网站选择对应的程序即可。以上是网站建设之初必不可少的三大要素，缺一不可。当然，不是说准备好这些就可以直接访问网站了，还需要域名解析、网站程序的上传安装等操作。这些操作的具体步骤可能会因为空间商和网站程序的不同有所差别。不懂的新手朋友可以去站三界导航上提问交流。总之，搭建个人网站的步骤大同小异，只要掌握了基本流程就能快速搭建出属于自己的网站。如果你对建站感兴趣，不妨亲自去体验一番!
互联网的流量开始逐渐向移动端倾斜，手机已经占据了人们大多数的闲暇时间，而移动互联网已经成为大势所趋，但是还是有很多公司和站长不知道移动网站应该怎么建才能符合用户的使用习惯，才能获得用户的认可，今天小编根据自己的工作经验分享一下高质量移动网站应该如何创建。1、重点建立移动web网页现在有很多公司都在招兵买马组建app开发团队，认为只要自己的app上线网站移动端就算完成了，其实这是不正确的，移动web网页相对于app具有很多优势：：1）成本低廉：不用专门找团队开发app，直接进行移动适配即。2）降低访问门槛：app是需要下载的，如果拥有移动web，用户不用下载即可访问。3）追踪数据方便：移动app对统计下载来源、渠道无法做到精确统计，而移动web却可以很好的统计相关数据。4）更改方便：app修改之后需要重新上传和等待审核，而移动web只要输入相关代码调整之后即可更改完成，时间很短。2、直击用户痛点、需求由于移动端屏幕有限，用户操作和浏览都具有一定的局限性，这个时候就需要你的内容或者服务更加直接，让用户一目了解的看到其需要的内容，这样不但能提高用户体验，还能增加用户的粘性，为忠实用户打下良好的基础，因此在制作移动网站的时候一定要考虑用户的使用场景，能够为用户提供快捷、高效的服务，这样才能获得用户的青睐。3、网页打开速度要快用户使用移动设备打开网页都会担心流量的消耗，一般会认为打开时间越长消耗的流量越多，虽然这种观点不一定正确，但是如果用户在点击网页之后长时间看不到网页自然就会造成用户的流失，因此网页不要过大，尽量减小网页体积，如果可以尽量少使用视频、图片多使用文字。一般移动端网页的打开速度最好不好超过3秒，如果时间过长会影响用户的心情、对网站的印象，如果给用户留下不好的印象那么这个用户之后就算看到自己网站的网页能点击进来的机率也会大大减小，所以网页打开速度是用户非常关注的一点，一定要快。4、重点推广内容一定要显眼不管是哪个网站在某个时间段肯定都有自己希望重点推广的内容，由于移动界面有限，不可能把所有的内容都详尽的展现出来，这个时候就要根据公司的目标进行排序，重点推广的页面进行重点设计，让其体现出与众不同之处，这样容易让用户发现和发生点击，而一些次要的内容可以放在次要的位置以免与重点推广页面发生冲突。5、导航菜单要简单实用像PC端的网站导航一般都非常详细，稍微大点的网站都能分出20个频道，像一些大型新闻门户可能不止这个数字，而且还会分成大频道和小频道页，这种数量众多的分类在移动端千万要不得，移动端的导航一定要尽可能的减少，而且导航最好能使自己十分重要的业务，千万不要把那些无关紧要的内容放上去。例如优本财富是一家从事理财的网站，像网站首页、投资页面、行业新闻、联系我们等是重要内容一定要有，其他的像借款页面、帮助中心可以展现在pc端或者展现在其他位置。6、移动端列表导航是否要用图片？应该怎么用？移动端列表导航是否要用图片？很在移动网站的列表设计中，很多人都会遇到要不要使用图片进行导航？是只使用移动导航还是添加文字呢？其实这个问题要看自己网站所属行业和定位了，例如优本财富是从事投资理财的公司，图片导航就没有多大实际用处，这个时候使用图片导航还不如文字具有说服力。而卖水果的网站只使用图片或者文字说服力也比较有限，而两个都使用则能达到事半功倍的效果。图片应该放在页面左边还是右边呢？图片大小应该是多少呢？这个就要看图片是否重要信息了，如果图片是比文字重要的信息就需要放在左边，毕竟国人阅读习惯是从左往右，如果图片信息不重要就可以放在文字的右边。而图片的大小也需要根据图片的重要程度来估算，如果图片是重要的就需要放一些尺寸比较大的，方便用户观察和了解，如果图片体现的信息不重要则可以根据需要缩小图片尺寸。以上就是小编带来的高质量移动网站应该如何创建相关内容的介绍，希望对大家有所帮助！
姚键是优酷土豆集团CTO，据他介绍，优酷新上线的首页页面上，光是导航栏上的视频分类就有21个，21个不同类型的内容，这意味着会有各种不同的用户来优酷看视频，要想给不同的用户推荐他们喜欢的视频，这靠的是一个叫做“协同过滤推荐”的技术。百度百科上这样介绍协同过滤推荐（CollaborativeFilteringrecommendation）：“是在信息过滤和信息系统中正迅速成为一项很受欢迎的技术。与传统的基于内容过滤直接分析内容进行推荐不同，协同过滤分析用户兴趣，在用户群中找到指定用户的相似（兴趣）用户，综合这些相似用户对某一信息的评价，形成系统对该指定用户对此信息的喜好程度预测。”这是亚马逊、谷歌等互联网巨头都在使用的技术。亚马逊会告诉你“买了A商品的顾客也同时购买了B商品”，Youtube上，一个视频播放结束，马上就会出现相关推荐视频。看上去简单的相关推荐，其实在优酷的视频推荐中涉及上百个参数，每次要调整参数，都要手动调整十几甚至几十个参数，每天推荐视频的数据模型中要涉及的数据高达几十亿。一次小小的参数调整，带来的后果，可能是当天视频观看带来几百万的增长，也可能是在算法稳定后的未来几周，甚至几个月带来视频观看量的曲线变化。当然，数字证实，通过这种协同过滤推荐给用户的视频是靠谱的，因为在海量的视频中寻找自己喜欢的视频成本是很高的，推荐视频的打开率也令人满意。优酷土豆心中的“大数据”数据的挖掘、分析，用在推荐视频上，还只是个小意思。优酷在2010年推出的“优酷指数”把大数据精神进一步强化，把视频播放周期、用户核心特征、用户播放行为、视频热度排行等数据进行展示。姚键这样介绍优酷指数诞生的背景：“2010年的时候，优酷在PC互联网时代已经成为最有影响力的视频网站，优酷希望能够在行业内树立一个标杆，在强化优酷品牌的同时，也打造优酷指数这样一个概念。”今年，优酷指数进而演变成“中国网络视频指数”，加入了土豆网以及移动客户端的视频数据，对数字感兴趣的用户，可以从这个指数里读出很多内容。作为一款平台化的产品，“中国网络视频指数”在优酷土豆集团中的参考价值无处不在，从广告售卖，到版权购买，再到播放器产品的优化，等等，处处都能够作为指导依据。据姚键透露，优酷土豆集团推出的数据报告给节目制作方、影视剧公司、第三方分析机构等了解视频节目的播放信息，以及观众人群的分析提供了依据；在广告销售方面，能够为广告主呈现出用户行为特征，提供广告投放价值的分析；在进行版权购买的时候，可以根据指数的走向来帮助决策；公司内部，哪怕是播放器产品的用户体验优化，都可以查看数据分析结果，查看按钮的摆放和使用频率等。这些价值都是显而易见的，还有我们在表面看不到的，通过数据分析的结果来指导优酷土豆集团的自制内容。“比如说优酷有很多自制的内容，有很多的微电影、综艺节目等等，这些播放数据可以显示出哪些题材是用户喜欢的，用户看到哪里就看不下去了，在哪里是拖放观看的，一系列的用户行为可以清晰地告诉内容制作人员，应该怎么去剪辑视频，怎么去选择内容题材。”姚键说。 其实这个过程也是对视频质量进行分析的过程，在优酷土豆的搜索、推荐中按照视频质量进行排序，反过来也提高了推荐成功率。然而，大数据读出的数据，其指导意义还远不止此。每部电影、电视剧在播出后都会有对应的数据，哪些演员受欢迎，哪些题材受追捧，通过分析数据就可以慢慢发现背后的原因，把这个受欢迎的故事讲出来，这就是可见的未来。敢为人先优酷土豆用Spark完善大数据分析大数据，一个似乎已经被媒体传播的过于泛滥的词汇，的的确确又在逐渐影响和改变着我们的生活。也许有人认为大数据在中国仍然只是噱头，但在当前中国互联网领域，大数据以及大数据所催生出来的生产力正在潜移默化地推动业务发展，并为广大中国网民提供更加优秀的服务。优酷土豆作为国内最大的视频网站，和国内其他互联网巨头一样，率先看到大数据对公司业务的价值，早在2009年就开始使用Hadoop集群，随着这些年业务迅猛发展，优酷土豆又率先尝试了仍处于大数据前沿领域的Spark/Shark内存计算框架，很好地解决了机器学习和图计算多次迭代的瓶颈问题，使得公司大数据分析更加完善。MapReduce之痛提到大数据，自然不能不提Hadoop。HDFS已然成为大数据公认的存储，而MapReduce作为其搭配的数据处理框架在大数据发展的早期表现出了重大的价值。可由于其设计上的约束MapReduce只适合处理离线计算，其在实时性上仍有较大的不足，随着业务的发展，业界对实时性和准确性有更多的需求，很明显单纯依靠MapReduce框架已经不能满足业务的需求了。优酷土豆集团大数据团队技术总监卢学裕就表示：“现在我们使用Hadoop处理一些问题诸如迭代式计算，每次对磁盘和网络的开销相当大。尤其每一次迭代计算都将结果要写到磁盘再读回来，另外计算的中间结果还需要三个备份，这其实是浪费。”据悉，优酷土豆的Hadoop大数据平台是从2009年开始采用，最初只有10多个节点，2012年集群节点达到150个，2013年更是达到300个，每天处理数据量达到200TB。优酷土豆鉴于Hadoop集群已经逐渐胜任不了一些应用，于是决定引入Spark/Shark内存计算框架，以此来满足图计算迭代等的需求。Spark是一个通用的并行计算框架，由伯克利大学的AMP实验室开发，Spark已经成为继Hadoop之后又一大热门开源项目，目前已经有英特尔等企业加入到该开源项目。“我们大数据平台对快速需求的响应延时，尤其是在商业智能BI以及产品研究分析等需要多次对大数据做DrillDown与DrillUp时，等待成了效率杀手。”优酷土豆集团大数据团队技术总监卢学裕表示。用Spark/Shark完善大数据分析目前大数据在互联网公司主要应用在广告、报表、推荐系统等业务上。在广告业务方面需要大数据做应用分析、效果分析、定向优化等，在推荐系统方面则需要大数据优化相关排名、个性化推荐以及热点点击分析等。优酷土豆属于典型的互联网公司，目前运用大数据分析平台的主要工作是运营分析、机器学习、广告定向优化、搜索优化等方面。优酷土豆集团大数据团队技术总监卢学裕表示：“优酷土豆的大数据平台已经用了很多年，突出问题主要包括：第一是商业智能BI方面，公司的分析师提交任务之后需要等待很久才得到结果；第二就是大数据量计算，比如进行一些模拟广告投放之时，计算量非常大的同时对效率要求也比较高，用Hadoop消耗资源非常大而且响应比较慢；最后就是机器学习和图计算的迭代运算也是需要耗费大量资源且速度很慢。”因此，面对复杂任务、交互式查询以及流在线处理时，Hadoop与MapReduce并不适用。Spark/Shark这种内存型计算框架则比较适合各种迭代算法和交互式数据分析，可每次将弹性分布式数据集（RDD）操作之后的结果存入内存中，下次操作可直接从内存中读取，省去了大量的磁盘IO，效率也随之大幅提升。优酷土豆集团大数据团队大数据平台架构师傅杰表示：“一些应用场景并不适合在MapReduce里面去处理。通过对比，我们发现Spark性能比MapReduce提升很多。”“比如在图计算方面，视频与视频之间存在的相似关系，这就构成了一个图谱，通过图谱来做聚类，再给用户做视频推荐。”优酷土豆集团大数据团队技术总监卢学裕表示。优酷土豆集团大数据团队技术总监卢学裕表示：“我们进行过图计算方面的测试，在4台节点的Spark集群上用时只有5.6分钟，而同规模的数据量，单机实现需要80多分钟，并且内存吃满，单机无法实现Scale-Out，不能计算更大规模数据。”“在今天，数据处理要求非常快。比如优酷土豆的一些客户、广告商往往临时就需要看一下投放效果。所以在前端应用不变的情况下，如果能更快的响应市场的需要就变得很有竞争力。市场是瞬息万变的，有一些分析结果也需要快速响应成一个产品，Spark集成到数据平台正能发挥这样的效果。”优酷土豆集团大数据团队大数据平台架构师傅杰补充道。据了解，优酷土豆采用Spark/Shark大数据计算框架得到了英特尔公司的帮助，起初优酷土豆并不熟悉Spark以及Scala语言，英特尔帮助优酷土豆设计出具体符合业务需求的解决方案，并协助优酷土豆实现了该方案。此外，英特尔还给优酷土豆的大数据团队进行了Scala语言、Spark的培训等。“优酷土豆作为国内视频行业第一家商用部署Spark/Shark方案的公司，从视频行业的多样化分析角度来看是个非常好的方案。未来，英特尔将会继续与优酷土豆在Spark/Shark进行合作，包括硬件配置的优化以及整体方案的优化等”英特尔（中国）有限公司销售市场部互联网及媒体行业企业客户经理李志辉介绍道。未来：将Spark/Shark融入到Hadoop2.0对于大数据而言，Hadoop已经构建完成了较为完善的生态系统，特别是Hadoop2.0版本在推出之后，改善了诸多缺点。而Spark/Shark计算框架其实与Hadoop并不冲突，Spark现在已经可以直接运行在Yarn的框架之上，成为Hadoop生态系统之中不可或缺的成员。优酷土豆集团大数据团队大数据平台架构师傅杰表示：“目前Hadoop2.0已经发布了release版本，我们已经启动了对Hadoop2.0的升级预演。这中间还涉及到我们在1.0版本上修改的一些特性需要迁移和验证，我们希望做到在不影响业务的情况下实现平滑升级，预计在明年Q1完成升级。Hadoop2.0将会是非常强大的，不再仅仅是MapReduce，还能融入Spark，能够让用户可以根据数据处理应用需求的不同来选择合适的计算框架。”
为了更好的实现个性化视频推荐，2009年，优酷土豆开始使用Hadoop大数据平台来进行数据的分析及挖掘。起初整个平台平台只有十多个节点，而到2012年集群节点已经达到150个，2013年更是达到了300个。但是随着数据量的急剧增加以及业务的迅猛发展，每天优酷处理的数据量已突破200TB，优酷土豆的技术人员发现一些场景并不适合利用MapReduce进行处理。 优酷土豆的大数据平台已使用多年，核心业务数据量的增长与数据处理速度的失衡成为优酷土豆Hadoop大数据平台的一大瓶颈。这个问题主要表现在三个方面：首先，在BI方面，分析师提交任务后需要等待很久才得到结果。其次，在进行一些模拟广告投放之时，在调优、筛选方面的计算量十分大，对计算效率的要求也较高，用Hadoop消耗资源过大而且响应较慢。同时，MapReduce在机器学习和图计算的迭代运算方面不仅需要耗费大量资源，处理速度也不尽人意。 优酷土豆集团大数据团队大数据平台架构师傅杰介绍道：“虽然很多互联网企业都在用MapReduce来处理自己的业务，但是由于优酷的视频量大概在2亿的级别，视频的关系量目前在10亿的级别，这个级别的数据量利用MapReduce来计算CPU资源消耗比较高，而计算效率比较低，单纯依靠MapReduce框架已经无法满足视频推荐、广告投放效果预估等情景对实时性和准确性的要求。” 优酷土豆如何打造Hadoop平台 目前傅杰老师主要负责优酷土豆集团大数据基础平台建设，以支撑集团其他业务团队的存储与计算需求，包含Hadoop平台、日志采集系统、实时计算系统、消息系统以及天机镜系统等。据了解，Hadoop平台在优酷的发展，主要有以下几个阶段： 平台搭建期：这个阶段主要解决一些技术问题，比如安全问题、整体规划，以及制定相关流程； 平台发展期：这个阶段主要是在集团内部进行推广，伴随着会遇到各种各样的需求，以及解决各种各样的问题，修正相关流程，使平台进入一个稳定、高可用的水平； 平台稳定期：这个阶段主要是从优化资源入手，内部培训调优作业，统计资源消耗合理性，构建自动化优化流程。 “现阶段我们主要在调研Hadoop1.X到Hadoop2.0的升级方案，预计明年初对Hadoop进行升级。今年我们也搭建了基于Storm的实时计算平台、kafka消息系统，推广到集团的线上业务中，也逐步流程化的运营起来了。”傅杰老师介绍说。 新手如何入门Hadoop? 据傅杰老师介绍，目前Hadoop在国内有很好的发展态势，各大企业对Hadoop的需求也比较旺盛，同时，应用Hadoop的行业也越来越多。但目前存在的问题是，Hadoop的优秀技术人才比较短缺。那么对于想踏入Hadoop领域的新手来说，应如何入门呢? 傅杰老师给出的建议是： 1.经常关注Hadoop官方网站; 2.深入了解Hadoop原理，比如HDFS、MapReduce。并思考目前所在企业哪些应用可以用Hadoop解决; 3.阅读Hadoop相关书籍。据悉，目前傅杰老师翻译的《Hadoop实战手册》将在年底出版，这本书也很适合新手阅读; 4.搭建环境实战，比如可以试着跑一个wordcount。和英特尔一起Spark/Shark 为此，优酷土豆在英特尔公司的帮助下率先尝试了Spark/Shark内存计算框架来解决多次迭代以及复杂的算法。以计算实力著称的英特尔，在项目中在软件优化、方案设计、Scala语言培训等方面给优酷土豆提供了多方面的帮助，以过硬的软实力及对整个行业的深入洞察，与优酷土豆的需求不谋而合。 作为典型的互联网公司，优酷土豆大数据平台主要应用在广告、日常报表、推荐系统等核心业务上。随着对低延时的、实时要求很高的应用场景的增多，Spark/Shark在快速报表，交互式查询，做Ad-hoc的查询的表现，机器学习以及迭代式算法方面的优越性吸引了优酷土豆。Spark/Shark可每次将弹性分布式数据集(RDD)操作之后的结果存入内存中，下次操作可直接从内存中读取，省去了大量的磁盘IO，效率也大幅提升。 在瞬息万变的互联网市场，用户的个性化需求越来越多，而将Spark/Shark集成到优酷土豆原有的大数据平台后，在用户偏好分析、Top-N榜单计算等方面看到了喜人的变化。“与前几年不同，为了更加精准的为用户做出视频推荐，我们已经不再是简单的匹配视频的元信息了。计算视频与视频之间的相似关系，我们用到了图计算。利用图计算，我们将搜集到的视频图谱做聚类，然后再推荐给用户。”优酷土豆集团大数据团队技术总监卢学裕介绍道，“通过测试与对比，我们发现，计算相同规模的数据量，以前在单机上实现需要80多分钟，而在四台节点的Spark集群上运算时间缩短到了5.6分钟。” 通过混搭的方式，Hadoop与Spark/Shark结合的架构不仅使计算资源能够更加协调的被利用，也完善了优酷土豆的大数据分析，而重复视频推荐、刷浏览量冲击榜单的情况也减少了很多。作为国内视频行业第一家部署Spark/Shark解决方案的公司，优酷土豆在Spark/Shark方面的经验对整个视频行业有突出的价值。未来，双方也将继续进行深入合作，将整体方案进一步优化，并分享给更多行业合作伙伴，帮助他们更好的解决业务中面临的大数据挑战。
中国互联网举报中心