互联网平台已经成为企业推广的重要平台，适应客户碎片化时间的网络营销不断在逐步发展，正由于互联网发展的巨大潜力，互联网时代和适应互联网时代的企业的潮流和趋势已成为必然。而在我国，企业向互联网转型的过程中，在面临新的机遇和领域时往往会产生很多这方面的问题。企业知道自己需要一个网站，但是对于网站建设和推广方面因为缺乏足够的了解，而导致其自身的传统行业并没有得到互联网平台带来的推动。这也是由于传统营销理念不能很好的过渡到网络营销理念所导致的。现在，就来说明一下网站建设中忽略的因素以及一些误区。一、网站的定位网站的定位一定要和企业定位相呼应，这是整个网站建设中最基本的要素。对于企业和产品的定位，企业客户在随着自身企业发展中已经能很好的把握，我们的目标受众是什么，我们的卖点是什么，我们带给消费者的形象是什么。而转向互联网平台时，客户往往忘记了这些。往往追求着企业网站的高端，上档次。但是企业卖的不是网站，卖的是产品。网站的高端设计往往能吸引住消费者的需求，但它对于成单来说加成不大，并且当消费者在你的网站上找到他需要的信息时，这反而成为了用户体验差的表现。 这里需要注意的一点就是，企业在传统行业中是如何定位的，在网站定位时，将这些信息通过网站的展示最快最有效传达给消费者，这才起到了推广的目的。互联网带来的流量很大，但是每个消费者留给一个网站的时间也很少，你需要在那短的时间内将一个产品的形象通过网页中图文让消费者达到认识，最好能有着不错的印象和偏爱。所以，可见，网站的花俏设计不一定是件好事，它某方面占用了消费者浏览你网站的时间。也许，你应该向淘宝学习，在产品的美工上下功夫。 二、一般网站都应该注意的问题现如今，css3.0让网页的动画效果炫丽多样，国内大多数企业网站设计都让人体会到了单单浏览网站是件惬意的事情，这样能让人体会到建站企业的实力。实力往往是体会到了，但是有时候试问一句，你的受众是高消费层次吗，也许定位在高档产品的企业适合这样做。 但是我想说的另一个方面是，考虑到一个一般性客户的网络情况，最为重要的是他愿意为一个网站所掏出的时间，这个往往跟一个消费者有没有钱没有关系。这时候网站的高端设计很有可能成为网站打不开响应慢的重要原因。Flash、图片、frame，js这些都会影响到网页的打开速度，一两秒的延迟也许不影响什么，但是我担心的是，他会不会有足够的时间浏览到最终产品页呢。这时候多余的花俏的弊害就能体会到。这些东西没有为你的营销加分，反而是减分了。另外，Flash会占用太大的空间，这个对于搜索引擎也不是很友好，要知道优化才是营销过程中首先最关键的。每个用户喜欢的网站：结构清晰明了、简洁大方、条理分明、内容丰富。可以在很短时间找到他要的信息，不必被太多视觉污染所干扰。 三、网站的推广优化这个是所有企业最常犯的也是最致命的一个地方。网站建成了，就好像他已经开好了店面，不用管了，等待客户上面找他了。我们要知道，一个网站的成本很低，相对于开个店面来说确实很低，可正因为低所以建个网站是件很容易的事。互联网带来的流量很大，但是跟你去竞争流量的对手相对于开店面的来说多了太多。在此，我想说的事，建设一个网站并争取到互联网带来的流量促成交易，这才是成功的网络营销。一个有钱开店的企业的网站结果没有没钱开店的个人的网站排名高，这是最悲哀的事情。 显然，网站的优化应该得到企业的高度重视。因为只有网站排名高了，才能得到真正比较高的流量，将优化进行的投资，相比优化带来的流量相比来说才显得微不足道，只有这样，企业才能经过互联网平台得到更长远的发展。
使用adx的朋友可以注意一下了，因为默认情况下adx的代码都是普通的不是异步加载的代码，可能会影响页面的加载，所以这里为大家分享一下将普通代码替换为异步代码的方法，需要的朋友可以参考下。 在您完成设置代码且代码ID（如835477075）自动分配到该代码后，系统将在您保存该代码后填充广告代码信息。此时，您可以复制广告代码并将其粘贴到您的广告投放系统中。默认的代码类型为同步代码。 包含同步广告代码的网页加载速度慢，还有可能完全停止加载。延迟和缓慢的加载速度都会导致用户部署广告拦截工具或不愿意访问体验不佳的网站。如果您网页的加载速度不足为虑，则可以继续使用同步广告代码。 目前，无法在用户界面中为基于规则的发布商生成异步广告代码。此外，DFP广告管理系统尚无法与这些代码兼容。不过，如果您要在您的网站上实现异步代码，则可以手动生成。异步广告代码可以加快网页的加载速度，从而最大限度地降低访问者流失率。因此，如果您的网页结构复杂且包含许多第三方元素（如网站分析、Flash电影和社交媒体Feed，那么我们建议您使用异步代码来提高速度。此外，异步广告代码兼容使用SSL/HTTPS的网页。要修改现有的广告代码，请进行以下代码更新：同步广告代码段JavaScriptCode复制内容到剪贴板异步广告代码段JavaScriptCode复制内容到剪贴板查看异步广告代码示例。您最好不要在同一网页上混合使用异步和同步广告代码，因为这样做可能会导致定位问题。
因此做好网站临时关闭的一些工作，是所有SEOs的必备功课。下面我将教大家怎么处理好网站临时关闭时跟用户还有搜索引擎的一些三角关系！让用户与蜘蛛知道网站正在维护当一家餐厅的老板，因为某些原因不得不临时关闭餐厅，老板会在餐厅门口贴公告，告知顾客餐厅临时关闭以及恢复营业的时间，这样顾客就不会误以为餐厅倒闭，而不再次光临。同样的道理也可以套用在网站上，如果一个网站因为某些原因必须临时关闭，那么站长有责任通知蜘蛛还有用户，并告知恢复的时间，这样蜘蛛还有用户才会再次访问网站，而不是误以为网站已经永久关闭。但是怎样做好告知工作，就不像餐厅那样贴贴告示就能搞定，网络的世界比较复杂，因此告知用户与蜘蛛是一名艺术，下面我们列举两个站长朋友经常犯的错误。 错误一，网站关闭没有告知有些站长朋友，没有做好告知工作，随随便便就把网站关闭，导致用户以及蜘蛛访问时，显示404页面。最糟的情况是，用户以及蜘蛛会误以为网站已经倒闭，而不会再次光临，就跟餐厅一样，关门，没有贴公告，同样的其顾客会以为餐厅已经倒闭了，下次不会再来了。 错误二，单一页面告知有些站长则会制作一个单一页面，告知用户网站正在维护，并将全站其他的页面都指向这一页面，这也是非常不智的行为，因为这样做只告知了用户，而没有通知蜘蛛，这样蜘蛛只会以为其他页面被删除了，只剩下这个页面。在详细介绍网站临时关闭时的SEO处理步骤前，我们先复习下几个SEO最常碰到的HTTP状态码SEO过程中最常见的HTTP状态码有：200-服务器成功返回网页301-请求的网页已永久移动到新位置。当URLs发生变化时，使用301代码。搜索引擎索引中保存新的URL。302-请求的网页临时移动到新位置。搜索引擎索引中保存原来的URL。404-请求的网页不存在503-服务器目前无法使用（由于超载或停机维护）。通常，这只是暂时状态。如何告知用户以及蜘蛛网站正在维护？如果我们网站临时关闭，必须告知用户以及蜘蛛，让用户跟蜘蛛知道网站只是临时关闭，而不是永久关闭，这样用户跟蜘蛛就会隔断时间再次访问网站，具体做法是创建一个返回503状态的文件。 1、百度站长平台有个闭站保护功能，大家可以到zhanzhang.baidu.com注册认证一下，最好提前。 2.创建一个503.php的文件，并把它放到服务器的根目录网站名称网站名称网站维护中将于2016/10/8恢复第一二句告知搜索蜘蛛网站处理暂时关闭状态，第三句告知搜索蜘蛛，网站将于2012年10月8日18:27从新开放，注意：这里用的是格林威治标准时间。但是光放一个503信息到服务器里还是不够的，蜘蛛会访问网站不同的页面，因此我们必须引导所有的蜘蛛到503.php这个页面，让蜘蛛知道，整个网站处于临时关闭中，而不是个别页面。如果站长使用的是Apache/Linux服务器，我们只需在.htaccess设置一下，引导所有的蜘蛛到505.php页面，这里我们要使用302跳转，注意：在这里千万不要使用301跳转，因为301是永久的，在这种情况下会毁灭掉整个网站。 3.引导蜘蛛到503.php将下面这段代码保存到.htaccess文件，并上传到网站根目录Options+FollowSymLinksRewriteEngineOnRewriteBase/RewriteCond%{REMOTE_ADDR}!^00\.00\.00.\.00RewriteCond%{REQUEST_URI}!^/503.php[NC]RewriteRule,*/503.php[R,L]最后一行的[R，告知蜘蛛，这个是302跳转，属于暂时的。这样我们就完成了网站临时关闭的部署，可以放心关站了！
1确定体验评估指标1.1移动阅读及其组成要素移动阅读是指利用手机、平板电脑、电子阅读器等移动终端进行的所有阅读行为，包含通过浏览器浏览网页以及书城客户端、新闻客户端、资讯客户端、杂志客户端、微博、公众号文章等阅读途径，浏览小说、报纸、图书、杂志、动漫、文献等内容的阅读行为。从移动阅读组成要素来讲，主要有三个：移动阅读用户（主体）、电子读物（由内容和移动载体组成的客体）、行为（用户的态度与行为表达），如下图所示。1.2影响移动阅读绩效的指标有关影响移动阅读绩效指标的研究很多，相关指标主要可以分为四类：主体评价、数字内容、硬件性能、软件功能（详见下表）。1.3纯文本文章阅读体验的评价指标本研究旨在为公众号用户提供更好的文章阅读体验，结合产品当前的现状，在评价指标上有其独特性。其中“数字内容”是开放性的，未来会通过运营推荐等方式进行优化，不在此次研究范围内；“硬件性能”整体上取决于用户本身的手机终端和手Q版本运行带来的影响，较为复杂，因此现阶段研究只关注显示舒适度，通过主流屏幕测试结果适配到不同屏幕中；“软件功能”目前尚不完善，未来会随着文章的价值定位而进行差异化设计，因此现阶段研究主要关注版面设计，即字体、字号、行距等因素对阅读产生的影响。确定本研究的目的是优化纯文本文章的阅读体验，及对应的二级指标（表格中“*”）后，结合产品特性，我们对指标进行了细化。版面设计的显示舒适度通常可以从视觉绩效（即可用性）和视觉主观偏好（即美观性）两个角度进行评估。根据以往研究发现，两者显著相关，主观偏好评分较高的往往辨识绩效较佳。这一点也可以从影响视觉绩效的元素与设计元素的关联性中得到验证。不同版式设计在一定文章长度内对视觉绩效产生的影响是比较有限的（用户保持高度注意力集中的情况下，任务完成的准确性和时间差异不会很大），但却可以通过视觉疲劳表现出来（也是用户注意力高度集中之后的一种体现）。在视觉疲劳的相关研究中，主要有以下结论：A.文本与背景的亮度对比当白色背景遇到黑色文字时，提高了文字的反射率，从而容易被注意理解，但色差较大，长久注视会产生疲劳感，相对注视时间短。用户偏好正极性（文本为深色，背景为浅色），但实际上负极性（文本为浅色，背景为深色）更不易疲劳。B.文字最小可接受的视角通常由字号大小与阅读视距决定，实验室测量方法如下图所示。在电子书阅读测试中，针对接近正方形的中文字（即，字高等于字宽），一般可接受最小视距为30cm以上，适当视距为50cm。青年组（20-35岁）“字高”至少为4.8mm（24pt），中年组（36-50岁）至少为5.14mm（25pt）。当固定近似正方形中文字体的字高4.85mm与行距3mm，字元间距为0.61mm或1.21mm会有较好的绩效，而且也不会增加视觉疲劳[2]。综上所述，在确定字体的情况下，字色、背景、字号、字距、行距是影响视觉绩效的主要因素。此外，屏幕亮度，屏幕尺寸，屏幕分辨率，环境光线，阅读视距，用户年龄，文本长度，阅读目的等都会对用户的阅读体验产生影响，我们将在研究中进行控制。视觉主观偏好可以通过清晰度、美观性、视觉舒适性三个指标进行综合评价。 2研究方法与展望2.1研究范式本研究主要分两个部分进行，第一部分为主观调试，如下图所示，请用户在电脑上调节研究相关的参数值，参数所对应的视觉效果会同步显示在手机上，用户需要调节出自己最舒适的视觉感受。2.2变量控制本研究采用2*2被试内设计，自变量为阅读视距（水平1：习惯视距，水平2：适当视距-50cm）与手机机型（水平1：iPhone6，水平2：iPhone6plus），各测试通过ABBA平衡顺序效应，每完成一个测试进行主观反馈，并休息5分钟，再进行下一个测试。采用统一的环境光线，及iPhone自适应的屏幕亮度，用户年龄从14-35岁，每篇文章的长度，错别字分布都相对均衡，要求用户在校订测验中保持固定的视距，尽可能快和多的找到错别字写在纸上。2.3小结与研究展望本研究在设计师选定的几种字体下，对用户主观偏好的阅读体验进行了视觉绩效的测量，用以确定字色、背景、字号、字距、行距等设计元素的参数值。回顾本文研究结果可以发现，用户在手机阅读中的视距要比电子书阅读视距更近，平均视距30cm，近一半用户视距在10-30cm之间。屏幕大小、视距、年龄对字号、行距、背景、字色等参数均有不同程度的影响。另外，字体在其中起了非常重要的作用（如，兰亭正文36-38pt，汉仪正文34-36pt），不同的字体在不同视距等因素的影响下，会得到不同的结果参数，详见后续视觉同学的分享文章。字体服务于文本阅读。不论是为阅读设计而选择字体的设计师，还是因文本阅读而反复注视字体的读者，都会在有意或无意间，逐渐形成自己关于字体及文字排版的评价标准。所以通常我们会认为存在人群普遍的视觉认知心理，以及专业设计师通过长期工作经验所获得的综合评估能力，两者之间可能是有差异的，如不同的个体对不同的字体偏好是不同的，对美观性与可用性之间分配的权重是不同的。在运用字体时，设计师需要根据设计需求选择合适的字体，设定相应的字号、字距、行距、字色等，契合成本要求，以获得最优的视觉效果，这个过程就会涉及到美观性与可用性之间的平衡。当字体使用场景复杂，面对的用户差异大的时候，这种平衡就显得尤为重要。因此，未来的研究可以有两个方向：一、从字体研究出发，在不同的使用场景下，获得用户的普遍视觉认知心理；二、从移动阅读绩效出发，对指标体系的其他方面进行评价与优化。
对于做过SEO的人来说，深知网站首页的重要性，通常我们把标题还有网站布局一分为二，标题的重要性占40%，而网站首页布局也同样占有40%的重要性，至于其他的操作，小编认为，这仅仅只是影响网站排名的20%左右，这也是很多新站在没做好标题和网站首页布局，只是操作着影响排名关键因素的20%的操作，例如：发外链，做锚文本，做友情链接，更新文章等，很多新手都只是会操作这些东西，因此网站迟迟上不去，然后苦喊百度抽风，做SEO没前途，SEO之路已死等。好的首页布局应注意哪些问题：1.利于蜘蛛抓取一个好的首页布局，最好采用DIV+CSS进行布局，用html进行编写，使用静态页面，这样的代码是很容易让蜘蛛识别抓取的，很多新手，为了追求网站的华丽效果，采用一些JS特效和flash，在之前就有朋友给我分析一个网站，说网站很好，但为什么收录那么少，于是我打开源代码进行查看，天呐，全是JS代码，只有少部分的文字说明，这样的网站，连蜘蛛都识别不了，谈何排名呢?2.内容一目了然，主题不冲突首页，说白了也只是一个页面，作为整个网站的核心部分，引导着用户更深入的了解，因此，内容要简单，有的老板和新手，本身熟悉SEO，总是认为自己的服务全满就可以，把首页布局得满满的，让用户花了很多时间去寻找内容，例如：一个专门做卖电冰箱的网站，一般新手和不懂SEO的老板总会想，既然我们是电冰箱，当然先要考虑自己的冰雪如何卖，于是，导航上就有了【产品展示】，其次，当用户找到了电冰箱，肯定会要了解厂家是否合格，于是，又有了【关于我们】，再次，当电冰箱坏了，用户可能要维修，【产品维修】就出世了，然后实在想不出什么东西把导航填满，导航就只有几个，显得非常不美观，然后又去看同行导航是如何布局的，最后又添加了一些【在线留言】【新闻中心】【工程案例】【人才招聘】等毫不相关的导航;其实这么做是不合理的，电冰箱的用户总共分为“买前”和“买后”的客户，而买前的客户才是一家公司必须争取的客户，如果你做的是买后的客户，那么，你的订单量就小得多，如果你买前买后都做，那么你的竞争力就分散成了2份，也会让首页内容复杂化，主题相互冲突，一个页面，最好使用一个服务，一个核心，利于网站的集权，这一点听不懂的新手朋友可以联系我。3.首页不宜过长首页最好不要过于太长，之前看过几个朋友网站的首页，几乎都是美观大气，但首页过长，在首页可谓是什么内容都有啊，恨不得把所有东西都写上去，我的鼠标愣是滑动了好几秒才到底部，在站长的角度来看，这样的网站确实很大气美观，但从用户的体验来看，这样的网站会让人浏览非常累，首页应以简洁为主，美观为辅，如果你的首页要滑动好几秒才能到底，那么，你的网站就在用户体验得分上被扣分，鉴于很多新手不知道页面得分这一概念，只知道权重概念，所以，在这里岑辉宇就不做过多说明了。4.首页导航和logo要突出logo和导航是直接引导用户选择的地方，先说logo，很多企业都做到了logo突出，也有很多企业做到了logo突出的同时，也让logo显得复杂，原因是很多企业老板为了让用户找到自己的电话和信息，把这些信息放到了首页最顶部，和logo放在一起，造成了logo那一块杂乱无章，主次不分，这样就有些画蛇添足了，添加信息是可以，但不要抢了logo的主角戏份;其次是导航，导航也要布局突出一些，有部分网站把导航的字体布置得非常小，或者是使用图片作为导航，建议导航一定用文字，文字不要太小，同时，尽量减少导航下拉框的使用，也就是鼠标滑动到某个导航的时候，会有下拉导航显示，这类导航能不用就不用，至于原因，我就不再这里和大家详细说明了。5.友情链接只出现在首页对于一些新手来说，若是不会做友情链接的版块，会把友情链接在每一个页面显示，这样的做法也是非常不明智的，一般老鸟都不会犯这样的低级错误，友情链接最好只出现在网站的首页，而且放在底部，这样就不会分散掉过多的权重，这一点希望不知道的朋友谨记。6.好的首页布局能降低用户跳出率，提升转换率首页是每一个用户浏览所见到的第一个页面，因此，首页好不好，直接决定了用户是否进行下单的关键，也能减少网站的跳出率，跳出率低的网站，一般都很稳定，不会出现今天在首页，过几天又没排名了，我们把用户觉得好的网站内容称之为“受众”，至于如何降低跳出率，当然是看网站内容是否布局合理了，在这里就不一一举例说明了，有兴趣的就可以联系小编。以上6点就是总结的首页如何布局更加符合用户体验，当你的网站已经具备了这样的条件，那么，你只需要稍微做一下引流工作，那么，你的网站快速获取排名就很轻松，至于如何引流，我也不做过多说明了。以上就是对更利于排名的首页布局技巧汇总全部内容的介绍，更多内容请继续关注站三界导航!
前言美团是数据驱动的互联网服务，用户每天在美团上的点击、浏览、下单支付行为都会产生海量的日志，这些日志数据将被汇总处理、分析、挖掘与学习，为美团的各种推荐、搜索系统甚至公司战略目标制定提供数据支持。大数据处理渗透到了美团各业务线的各种应用场景，选择合适、高效的数据处理引擎能够大大提高数据生产的效率，进而间接或直接提升相关团队的工作效率。美团最初的数据处理以HiveSQL为主，底层计算引擎为MapReduce，部分相对复杂的业务会由工程师编写MapReduce程序实现。随着业务的发展，单纯的HiveSQL查询或者MapReduce程序已经越来越难以满足数据处理和分析的需求。一方面，MapReduce计算模型对多轮迭代的DAG作业支持不给力，每轮迭代都需要将数据落盘，极大地影响了作业执行效率，另外只提供Map和Reduce这两种计算因子，使得用户在实现迭代式计算（比如：机器学习算法）时成本高且效率低。另一方面，在数据仓库的按天生产中，由于某些原始日志是半结构化或者非结构化数据，因此，对其进行清洗和转换操作时，需要结合SQL查询以及复杂的过程式逻辑处理，这部分工作之前是由HiveSQL结合Python脚本来完成。这种方式存在效率问题，当数据量比较大的时候，流程的运行时间较长，这些ETL流程通常处于比较上游的位置，会直接影响到一系列下游的完成时间以及各种重要数据报表的生成。基于以上原因，美团在2014年的时候引入了Spark。为了充分利用现有Hadoop集群的资源，我们采用了SparkonYarn模式，所有的Sparkapp以及MapReduce作业会通过Yarn统一调度执行。Spark在美团数据平台架构中的位置如图所示：经过近两年的推广和发展，从最开始只有少数团队尝试用Spark解决数据处理、机器学习等问题，到现在已经覆盖了美团各大业务线的各种应用场景。从上游的ETL生产，到下游的SQL查询分析以及机器学习等，Spark正在逐步替代MapReduce作业，成为美团大数据处理的主流计算引擎。目前美团Hadoop集群用户每天提交的Spark作业数和MapReduce作业数比例为4：1，对于一些上游的HiveETL流程，迁移到Spark之后，在相同的资源使用情况下，作业执行速度提升了十倍，极大地提升了业务方的生产效率。下面我们将介绍Spark在美团的实践，包括我们基于Spark所做的平台化工作以及Spark在生产环境下的应用案例。其中包含Zeppelin结合的交互式开发平台，也有使用Spark任务完成的ETL数据转换工具，数据挖掘组基于Spark开发了特征平台和数据挖掘平台，另外还有基于Spark的交互式用户行为分析系统以及在SEM投放服务中的应用，以下是详细介绍。Spark交互式开发平台在推广如何使用Spark的过程中，我们总结了用户开发应用的主要需求：数据调研：在正式开发程序之前，首先需要认识待处理的业务数据，包括：数据格式，类型（若以表结构存储则对应到字段类型）、存储方式、有无脏数据，甚至分析根据业务逻辑实现是否可能存在数据倾斜等等。这个需求十分基础且重要，只有对数据有充分的掌控，才能写出高效的Spark代码；代码调试：业务的编码实现很难保证一蹴而就，可能需要不断地调试；如果每次少量的修改，测试代码都需要经过编译、打包、提交线上，会对用户的开发效率影响是非常大的；联合开发：对于一整个业务的实现，一般会有多方的协作，这时候需要能有一个方便的代码和执行结果共享的途径，用于分享各自的想法和试验结论。基于这些需求，我们调研了现有的开源系统，最终选择了Apache的孵化项目Zeppelin，将其作为基于Spark的交互式开发平台。Zeppelin整合了Spark，Markdown，Shell，Angular等引擎，集成了数据分析和可视化等功能。我们在原生的Zeppelin上增加了用户登陆认证、用户行为日志审计、权限管理以及执行Spark作业资源隔离，打造了一个美团的Spark的交互式开发平台，不同的用户可以在该平台上调研数据、调试程序、共享代码和结论。集成在Zeppelin的Spark提供了三种解释器：Spark、Pyspark、SQL，分别适用于编写Scala、Python、SQL代码。对于上述的数据调研需求，无论是程序设计之初，还是编码实现过程中，当需要检索数据信息时，通过Zeppelin提供的SQL接口可以很便利的获取到分析结果；另外，Zeppelin中Scala和Python解释器自身的交互式特性满足了用户对Spark和Pyspark分步调试的需求，同时由于Zeppelin可以直接连接线上集群，因此可以满足用户对线上数据的读写处理请求；最后，Zeppelin使用WebSocket通信，用户只需要简单地发送要分享内容所在的http链接，所有接受者就可以同步感知代码修改，运行结果等，实现多个开发者协同工作。Spark作业ETL模板除了提供平台化的工具以外，我们也会从其他方面来提高用户的开发效率，比如将类似的需求进行封装，提供一个统一的ETL模板，让用户可以很方便的使用Spark实现业务需求。美团目前的数据生产主体是通过ETL将原始的日志通过清洗、转换等步骤后加载到Hive表中。而很多线上业务需要将Hive表里面的数据以一定的规则组成键值对，导入到Tair中，用于上层应用快速访问。其中大部分的需求逻辑相同，即把Hive表中几个指定字段的值按一定的规则拼接成key值，另外几个字段的值以json字符串的形式作为value值，最后将得到的对写入Tair。由于Hive表中的数据量一般较大，使用单机程序读取数据和写入Tair效率比较低，因此部分业务方决定使用Spark来实现这套逻辑。最初由业务方的工程师各自用Spark程序实现从Hive读数据，写入到Tair中（以下简称hive2Tair流程），这种情况下存在如下问题：每个业务方都要自己实现一套逻辑类似的流程，产生大量重复的开发工作；由于Spark是分布式的计算引擎，因此代码实现和参数设置不当很容易对Tair集群造成巨大压力，影响Tair的正常服务。基于以上原因，我们开发了Spark版的hive2Tair流程，并将其封装成一个标准的ETL模板，其格式和内容如下所示：source用于指定Hive表源数据，target指定目标Tair的库和表，这两个参数可以用于调度系统解析该ETL的上下游依赖关系，从而很方便地加入到现有的ETL生产体系中。有了这个模板，用户只需要填写一些基本的信息（包括Hive表来源，组成key的字段列表，组成value的字段列表，目标Tair集群）即可生成一个hive2Tair的ETL流程。整个流程生成过程不需要任何Spark基础，也不需要做任何的代码开发，极大地降低了用户的使用门槛，避免了重复开发，提高了开发效率。该流程执行时会自动生成一个Spark作业，以相对保守的参数运行：默认开启动态资源分配，每个Executor核数为2，内存2GB，最大Executor数设置为100。如果对于性能有很高的要求，并且申请的Tair集群比较大，那么可以使用一些调优参数来提升写入的性能。目前我们仅对用户暴露了设置Executor数量以及每个Executor内存的接口，并且设置了一个相对安全的最大值规定，避免由于参数设置不合理给Hadoop集群以及Tair集群造成异常压力。基于Spark的用户特征平台在没有特征平台之前，各个数据挖掘人员按照各自项目的需求提取用户特征数据，主要是通过美团的ETL调度平台按月/天来完成数据的提取。但从用户特征来看，其实会有很多的重复工作，不同的项目需要的用户特征其实有很多是一样的，为了减少冗余的提取工作，也为了节省计算资源，建立特征平台的需求随之诞生，特征平台只需要聚合各个开发人员已经提取的特征数据，并提供给其他人使用。特征平台主要使用Spark的批处理功能来完成数据的提取和聚合。开发人员提取特征主要还是通过ETL来完成，有些数据使用Spark来处理，比如用户搜索关键词的统计。开发人员提供的特征数据，需要按照平台提供的配置文件格式添加到特征库，比如在图团购的配置文件中，团购业务中有一个用户24小时时段支付的次数特征，输入就是一个生成好的特征表，开发人员通过测试验证无误之后，即完成了数据上线；另外对于有些特征，只需要从现有的表中提取部分特征数据，开发人员也只需要简单的配置即可完成。在图中，我们可以看到特征聚合分两层，第一层是各个业务数据内部聚合，比如团购的数据配置文件中会有很多的团购特征、购买、浏览等分散在不同的表中，每个业务都会有独立的Spark任务来完成聚合，构成一个用户团购特征表；特征聚合是一个典型的join任务，对比MapReduce性能提升了10倍左右。第二层是把各个业务表数据再进行一次聚合，生成最终的用户特征数据表。特征库中的特征是可视化的，我们在聚合特征时就会统计特征覆盖的人数，特征的最大最小数值等，然后同步到RDB，这样管理人员和开发者都能通过可视化来直观地了解特征。另外，我们还提供特征监测和告警，使用最近7天的特征统计数据，对比各个特征昨天和今天的覆盖人数，是增多了还是减少了，比如性别为女这个特征的覆盖人数，如果发现今天的覆盖人数比昨天低了1%（比如昨天6亿用户，女性2亿，那么人数降低了1％＊2亿＝2万）突然减少2万女性用户说明数据出现了极大的异常，何况网站的用户数每天都是增长的。这些异常都会通过邮件发送到平台和特征提取的相关人。Spark数据挖掘平台数据挖掘平台是完全依赖于用户特征库的，通过特征库提供用户特征，数据挖掘平台对特征进行转换并统一格式输出，就此开发人员可以快速完成模型的开发和迭代，之前需要两周开发一个模型，现在短则需要几个小时，多则几天就能完成。特征的转换包括特征名称的编码，也包括特征值的平滑和归一化，平台也提供特征离散化和特征选择的功能，这些都是使用Spark离线完成。开发人员拿到训练样本之后，可以使用Sparkmllib或者Pythonsklearn等完成模型训练，得到最优化模型之后，将模型保存为平台定义好的模型存储格式，并提供相关配置参数，通过平台即可完成模型上线，模型可以按天或者按周进行调度。当然如果模型需要重新训练或者其它调整，那么开发者还可以把模型下线。不只如此，平台还提供了一个模型准确率告警的功能，每次模型在预测完成之后，会计算用户提供的样本中预测的准确率，并比较开发者提供的准确率告警阈值，如果低于阈值则发邮件通知开发者，是否需要对模型重新训练。在开发挖掘平台的模型预测功时能我们走了点弯路，平台的模型预测功能开始是兼容Spark接口的，也就是使用Spark保存和加载模型文件并预测，使用过的人知道Sparkmllib的很多API都是私有的开发人员无法直接使用，所以我们这些接口进行封装然后再提供给开发者使用，但也只解决了Spark开发人员的问题，平台还需要兼容其他平台的模型输出和加载以及预测的功能，这让我们面临必需维护一个模型多个接口的问题，开发和维护成本都较高，最后还是放弃了兼容Spark接口的实现方式，我们自己定义了模型的保存格式，以及模型加载和模型预测的功能。以上内容介绍了美团基于Spark所做的平台化工作，这些平台和工具是面向全公司所有业务线服务的，旨在避免各团队做无意义的重复性工作，以及提高公司整体的数据生产效率。目前看来效果是比较好的，这些平台和工具在公司内部得到了广泛的认可和应用，当然也有不少的建议，推动我们持续地优化。随着Spark的发展和推广，从上游的ETL到下游的日常数据统计分析、推荐和搜索系统，越来越多的业务线开始尝试使用Spark进行各种复杂的数据处理和分析工作。下面将以Spark在交互式用户行为分析系统以及SEM投放服务为例，介绍Spark在美团实际业务生产环境下的应用。Spark在交互式用户行为分析系统中的实践美团的交互式用户行为分析系统，用于提供对海量的流量数据进行交互式分析的功能，系统的主要用户为公司内部的PM和运营人员。普通的BI类报表系统，只能够提供对聚合后的指标进行查询，比如PV、UV等相关指标。但是PM以及运营人员除了查看一些聚合指标以外，还需要根据自己的需求去分析某一类用户的流量数据，进而了解各种用户群体在App上的行为轨迹。根据这些数据，PM可以优化产品设计，运营人员可以为自己的运营工作提供数据支持，用户核心的几个诉求包括：自助查询，不同的PM或运营人员可能随时需要执行各种各样的分析功能，因此系统需要支持用户自助使用。响应速度，大部分分析功能都必须在几分钟内完成。可视化，可以通过可视化的方式查看分析结果。要解决上面的几个问题，技术人员需要解决以下两个核心问题：海量数据的处理，用户的流量数据全部存储在Hive中，数据量非常庞大，每天的数据量都在数十亿的规模。快速计算结果，系统需要能够随时接收用户提交的分析任务，并在几分钟之内计算出他们想要的结果。要解决上面两个问题，目前可供选择的技术主要有两种：MapReduce和Spark。在初期架构中选择了使用MapReduce这种较为成熟的技术，但是通过测试发现，基于MapReduce开发的复杂分析任务需要数小时才能完成，这会造成极差的用户体验，用户无法接受。因此我们尝试使用Spark这种内存式的快速大数据计算引擎作为系统架构中的核心部分，主要使用了SparkCore以及SparkSQL两个组件，来实现各种复杂的业务逻辑。实践中发现，虽然Spark的性能非常优秀，但是在目前的发展阶段中，还是或多或少会有一些性能以及OOM方面的问题。因此在项目的开发过程中，对大量Spark作业进行了各种各样的性能调优，包括算子调优、参数调优、shuffle调优以及数据倾斜调优等，最终实现了所有Spark作业的执行时间都在数分钟左右。并且在实践中解决了一些shuffle以及数据倾斜导致的OOM问题，保证了系统的稳定性。结合上述分析，最终的系统架构与工作流程如下所示：用户在系统界面中选择某个分析功能对应的菜单，并进入对应的任务创建界面，然后选择筛选条件和任务参数，并提交任务。由于系统需要满足不同类别的用户行为分析功能（目前系统中已经提供了十个以上分析功能），因此需要为每一种分析功能都开发一个Spark作业。采用J2EE技术开发了Web服务作为后台系统，在接收到用户提交的任务之后，根据任务类型选择其对应的Spark作业，启动一条子线程来执行Spark-submit命令以提交Spark作业。Spark作业运行在Yarn集群上，并针对Hive中的海量数据进行计算，最终将计算结果写入数据库中。用户通过系统界面查看任务分析结果，J2EE系统负责将数据库中的计算结果返回给界面进行展现。该系统上线后效果良好：90%的Spark作业运行时间都在5分钟以内，剩下10%的Spark作业运行时间在30分钟左右，该速度足以快速响应用户的分析需求。通过反馈来看，用户体验非常良好。目前每个月该系统都要执行数百个用户行为分析任务，有效并且快速地支持了PM和运营人员的各种分析需求。Spark在SEM投放服务中的应用流量技术组负责着美团站外广告的投放技术，目前在SEM、SEO、DSP等多种业务中大量使用了Spark平台，包括离线挖掘、模型训练、流数据处理等。美团SEM（搜索引擎营销）投放着上亿的关键词，一个关键词从被挖掘策略发现开始，就踏上了精彩的SEM之旅。它经过预估模型的筛选，投放到各大搜索引擎，可能因为市场竞争频繁调价，也可能因为效果不佳被迫下线。而这样的旅行，在美团每分钟都在发生。如此大规模的随机“迁徙”能够顺利进行，Spark功不可没。Spark不止用于美团SEM的关键词挖掘、预估模型训练、投放效果统计等大家能想到的场景，还罕见地用于关键词的投放服务，这也是本段介绍的重点。一个快速稳定的投放系统是精准营销的基础。美团早期的SEM投放服务采用的是单机版架构，随着关键词数量的极速增长，旧有服务存在的问题逐渐暴露。受限于各大搜索引擎API的配额（请求频次）、账户结构等规则，投放服务只负责处理API请求是远远不够的，还需要处理大量业务逻辑。单机程序在小数据量的情况下还能通过多进程勉强应对，但对于如此大规模的投放需求，就很难做到“兼顾全局”了。新版SEM投放服务在15年Q2上线，内部开发代号为Medusa。在Spark平台上搭建的Medusa，全面发挥了Spark大数据处理的优势，提供了高性能高可用的分布式SEM投放服务，具有以下几个特性：低门槛，Medusa整体架构的设计思路是提供数据库一样的服务。在接口层，让RD可以像操作本地数据库一样，通过SQL来“增删改查”线上关键词表，并且只需要关心自己的策略标签，不需要关注关键词的物理存储位置。Medusa利用SparkSQL作为服务的接口，提高了服务的易用性，也规范了数据存储，可同时对其他服务提供数据支持。基于Spark开发分布式投放系统，还可以让RD从系统层细节中解放出来，全部代码只有400行。高性能、可伸缩，为了达到投放的“时间”、“空间”最优化，Medusa利用Spark预计算出每一个关键词在远程账户中的最佳存储位置，每一次API请求的最佳时间内容。在配额和账号容量有限的情况下，轻松掌控着亿级的在线关键词投放。通过控制Executor数量实现了投放性能的可扩展，并在实战中做到了全渠道4小时全量回滚。高可用，有的同学或许会有疑问：API请求适合放到Spark中做吗？因为函数式编程要求函数是没有副作用的纯函数（输入是确定的，输出就是确定的）。这确实是一个问题，Medusa的思路是把请求API封装成独立的模块，让模块尽量做到“纯函数”的无副作用特性，并参考面向轨道编程的思路，将全部请求log重新返回给Spark继续处理，最终落到Hive，以此保证投放的成功率。为了更精准的控制配额消耗，Medusa没有引入单次请求重试机制，并制定了服务降级方案，以极低的数据丢失率，完整地记录了每一个关键词的旅行。结论和展望本文我们介绍了美团引入Spark的起源，基于Spark所做的一些平台化工作，以及Spark在美团具体应用场景下的实践。总体而言，Spark由于其灵活的编程接口、高效的内存计算，能够适用于大部分数据处理场景。在推广和使用Spark的过程中，我们踩过不少坑，也遇到过很多问题，但填坑和解决问题的过程，让我们对Spark有了更深入的理解，我们也期待着Spark在更多的应用场景中发挥重要的作用。
【基础篇】1.图片没有加上alt属性；图片大小没有控制好，导致网站加载速度过慢；2.动态路径，最好转换成静态化路径；3.标题堆砌关键词，过长；4.没有做好404页面；5.没有做好301重定向跳转，规范路径唯一化；6.首页标题重复出现（一些用织梦搭建的企业站，如果没有设置的话，每一个页面都带有首页标题，是非常不好的，做优化，要保证首页标题的唯一性。）7.大量的采集内容；8.购买刷流量软件（很多人认为只要流量高，排名就会上来，其实所谓的流量是指自然用户的流量，一般对100名以内的网站有效果，而且还有访问来源，百度会根据用户通过哪些途径进入网站的，如果是没有流量来源，百度几乎都认为是作弊流量，不作为计算流量，如果你发了一篇高质量的外链，用户通过外链来到网站上，并进行多个页面的PV投票，久而久之，你的排名自然就上去了，而非靠流量刷上来。）9.购买链接（分两种，一种是购买黑链，一种是购买明链，相对来说明链的安全性要高一些，但并不建议购买链接，友情链接要考虑相关性、导出链接、流量权重来进行综合选取。）10.大量的回链。11.过于追求多功能，豪华美观感，大量的flash和js程序。【思维篇】1.网站头部布置无关紧要的东西：很多人在建站的时候，往往只是为了填满网站内容，就算是建站公司做出的网站，你要是问他，这个为什么布局在这里，可能他们都说不出个所以然，最常见的就是一个导航重复的问题，请看下图：这样的布局从营销的角度来说并没有错，把自己的联系方式展示在最显眼的地方是可以的，但若是从优化的角度来说，放在这里并不合理，大家都知道，网站的权重分配是从左到右，从上到下递减，把这个东西放在这里，无疑分散了过多的权重，对用户来说，最显眼的地方不是放置用户最关心的东西，也间接的增加的网站跳出率，而且【联系我们】和导航中的【联系我们】重复，多此一举。2.网站整体的布局误区：导航的布局也是非常重要的，用于用户搜索，但很多SEOer都滥用导航，想到什么就放什么，甚至把所有关键词都放在导航上，完全忽视了用户的体验，一般的企业站都有着一个通病，这也是岑辉宇观察了很久才发现的，很多人喜欢把【关于我们】放在第二个导航上，仅次于【首页】，可能他们也不知道为什么这么做，大多网站都这么做，我也这么做，如果做seo是靠参考，那么也是走在同行后面，别人错，你也错。至于把【关于我们】放在第二个合不合理，我不敢妄下定论，因为不同行业有着不同的用户需求，如果是一家培训学院，主要推广学院的品牌，那么，把【关于我们】【荣誉资质】等放在前面自然是明智之举，因为大多搜索的用户群体的需求就是需要了解该培训学院到底好不好；但如果是一些企业站，主要推广产品的呢，用户群体的搜索范围大多关心产品呢，那么把【关于我们】放在第二个就显得略有失策，如果是推销产品的，那么，排在前面的一定是产品大全，而不是公司新闻，公司介绍等信息。要充分抓住用户所关心的内容进行填充布局。3.样板文字过多：什么是样板文字？就是网站每一个页面都出现的内容称之为样板文字，之前说过的首页标题经常出现也是会被百度认为是样板文字，样板文字通常并不具有价值，如图所示：导航算不算样板文字？算，只要是每个页面重复的内容都算是样板文字，并不是是要把所有样板文字去掉，而且要减少多余的样板文字，不能对用户提供引导和价值的样板文字，就可以考虑去掉，当样板文字的比例比正文内容还要多，那么百度会认为页面重复率过高，认为你这个网站价值低，每个页面的评分就低，何来排名？4.在线客服的自动弹框：现在大多数企业站都做了在线客服功能，这个功能解决了用户和企业在线交流的问题，用的好就能提高用户的体验，用的不好就会让用户赶紧关闭网站，什么样的弹框会让用户关闭网站呢？第一种就是自动弹框，当打开进入网站3秒左右，立马弹出一个“有什么能帮助您的？”这类弹框是最令人反感的，没有人愿意在浏览网站的时候被打扰，最好做网站边上的浮动框，这样既不影响用户正常浏览，也方便用户咨询，同时，也要避免自动播放的视频和声音。以上就是对用户体验相关内容的全部介绍，更多内容请继续关注站三界导航！
Facebook的数据仓库存储在少量大型Hadoop/HDFS集群。Hive是Facebook在几年前专为Hadoop打造的一款数据仓库工具。在以前，Facebook的科学家和分析师一直依靠Hive来做数据分析。但Hive使用MapReduce作为底层计算框架，是专为批处理设计的。但随着数据越来越多，使用Hive进行一个简单的数据查询可能要花费几分到几小时，显然不能满足交互式查询的需求。Facebook也调研了其他比Hive更快的工具，但它们要么在功能有所限制要么就太简单，以至于无法操作Facebook庞大的数据仓库。2012年开始试用的一些外部项目都不合适，他们决定自己开发，这就是Presto。2012年秋季开始开发，目前该项目已经在超过1000名Facebook雇员中使用，运行超过30000个查询，每日数据在1PB级别。Facebook称Presto的性能比Hive要好上10倍多。2013年Facebook正式宣布开源Presto。本文首先介绍Presto从用户提交SQL到执行的这一个过程，然后尝试对Presto实现实时查询的原理进行分析和总结，最后介绍Presto在美团的使用情况。Presto架构Presto查询引擎是一个Master-Slave的架构，由一个Coordinator节点，一个DiscoveryServer节点，多个Worker节点组成，DiscoveryServer通常内嵌于Coordinator节点中。Coordinator负责解析SQL语句，生成执行计划，分发执行任务给Worker节点执行。Worker节点负责实际执行查询任务。Worker节点启动后向DiscoveryServer服务注册，Coordinator从DiscoveryServer获得可以正常工作的Worker节点。如果配置了HiveConnector，需要配置一个HiveMetaStore服务为Presto提供Hive元信息，Worker节点与HDFS交互读取数据。Presto执行查询过程简介既然Presto是一个交互式的查询引擎，我们最关心的就是Presto实现低延时查询的原理，我认为主要是下面几个关键点，当然还有一些传统的SQL优化原理，这里不介绍了。完全基于内存的并行计算流水线本地化计算动态编译执行计划小心使用内存和数据结构类BlinkDB的近似查询GC控制为了介绍上述几个要点，这里先介绍一下Presto执行查询的过程提交查询用户使用PrestoCli提交一个查询语句后，Cli使用HTTP协议与Coordinator通信，Coordinator收到查询请求后调用SqlParser解析SQL语句得到Statement对象，并将Statement封装成一个QueryStarter对象放入线程池中等待执行。SQL编译过程Presto与Hive一样，使用Antlr编写SQL语法，语法规则定义在Statement.g和StatementBuilder.g两个文件中。如下图中所示从SQL编译为最终的物理执行计划大概分为5部，最终生成在每个Worker节点上运行的LocalExecutionPlan，这里不详细介绍SQL解析为逻辑执行计划的过程，通过一个SQL语句来理解查询计划生成之后的计算过程。样例SQL： 复制代码代码如下:selectc1.rank,count(*)fromdim.cityc1joindim.cityc2onc1.id=c2.idwherec1.id>10groupbyc1.ranklimit10;上面的SQL语句生成的逻辑执行计划Plan如上图所示。那么Presto是如何对上面的逻辑执行计划进行拆分以较高的并行度去执行完这个计划呢，我们来看看物理执行计划。物理执行计划逻辑执行计划图中的虚线就是Presto对逻辑执行计划的切分点，逻辑计划Plan生成的SubPlan分为四个部分，每一个SubPlan都会提交到一个或者多个Worker节点上执行。SubPlan有几个重要的属性planDistribution、outputPartitioning、partitionBy属性。PlanDistribution表示一个查询Stage的分发方式，逻辑执行计划图中的4个SubPlan共有3种不同的PlanDistribution方式：Source表示这个SubPlan是数据源，Source类型的任务会按照数据源大小确定分配多少个节点进行执行；Fixed表示这个SubPlan会分配固定的节点数进行执行（Config配置中的query.initial-hash-partitions参数配置，默认是8）；None表示这个SubPlan只分配到一个节点进行执行。在下面的执行计划中，SubPlan1和SubPlan0PlanDistribution=Source，这两个SubPlan都是提供数据源的节点，SubPlan1所有节点的读取数据都会发向SubPlan0的每一个节点；SubPlan2分配8个节点执行最终的聚合操作；SubPlan3只负责输出最后计算完成的数据。OutputPartitioning属性只有两个值HASH和NONE，表示这个SubPlan的输出是否按照partitionBy的key值对数据进行Shuffle。在下面的执行计划中只有SubPlan0的OutputPartitioning=HASH，所以SubPlan2接收到的数据是按照rank字段Partition后的数据。完全基于内存的并行计算查询的并行执行流程PrestoSQL的执行流程如下图所示Cli通过HTTP协议提交SQL查询之后，查询请求封装成一个SqlQueryExecution对象交给Coordinator的SqlQueryManager#queryExecutor线程池去执行每个SqlQueryExecution线程（图中Q-X线程）启动后对查询请求的SQL进行语法解析和优化并最终生成多个Stage的SqlStageExecution任务，每个SqlStageExecution任务仍然交给同样的线程池去执行每个SqlStageExecution线程（图中S-X线程）启动后每个Stage的任务按PlanDistribution属性构造一个或者多个RemoteTask通过HTTP协议分配给远端的Worker节点执行Worker节点接收到RemoteTask请求之后，启动一个SqlTaskExecution线程（图中T-X线程）将这个任务的每个Split包装成一个PrioritizedSplitRunner任务（图中SR-X）交给Worker节点的TaskExecutor#executor线程池去执行上面的执行计划实际执行效果如下图所示。Coordinator通过HTTP协议调用Worker节点的/v1/task接口将执行计划分配给所有Worker节点（图中蓝色箭头）SubPlan1的每个节点读取一个Split的数据并过滤后将数据分发给每个SubPlan0节点进行Join操作和PartialAggr操作SubPlan1的每个节点计算完成后按GroupByKey的Hash值将数据分发到不同的SubPlan2节点所有SubPlan2节点计算完成后将数据分发到SubPlan3节点SubPlan3节点计算完成后通知Coordinator结束查询，并将数据发送给Coordinator源数据的并行读取在上面的执行计划中SubPlan1和SubPlan0都是Source节点，其实它们读取HDFS文件数据的方式就是调用的HDFSInputSplitAPI，然后每个InputSplit分配一个Worker节点去执行，每个Worker节点分配的InputSplit数目上限是参数可配置的，Config中的query.max-pending-splits-per-node参数配置，默认是100。分布式的Hash聚合上面的执行计划在SubPlan0中会进行一次Partial的聚合计算，计算每个Worker节点读取的部分数据的部分聚合结果，然后SubPlan0的输出会按照groupby字段的Hash值分配不同的计算节点，最后SubPlan3合并所有结果并输出流水线数据模型Presto中处理的最小数据单元是一个Page对象，Page对象的数据结构如下图所示。一个Page对象包含多个Block对象，每个Block对象是一个字节数组，存储一个字段的若干行。多个Block横切的一行是真实的一行数据。一个Page最大1MB，最多16*1024行数据。节点内部流水线计算下图是一个Worker节点内部的计算流程图，左侧是任务的执行流程图。Worker节点将最细粒度的任务封装成一个PrioritizedSplitRunner对象，放入pendingsplit优先级队列中。每个Worker节点启动一定数目的线程进行计算，线程数task.shard.max-threads=availableProcessors()*4，在config中配置。每个空闲的线程从队列中取出一个PrioritizedSplitRunner对象执行，如果执行完成一个周期，超过最大执行时间1秒钟，判断任务是否执行完成，如果完成，从allSplits队列中删除，如果没有，则放回pendingSplits队列中。每个任务的执行流程如下图右侧，依次遍历所有Operator，尝试从上一个Operator取一个Page对象，如果取得的Page不为空，交给下一个Operator执行。节点间流水线计算下图是ExchangeOperator的执行流程图，ExchangeOperator为每一个Split启动一个HttpPageBufferClient对象，主动向上一个Stage的Worker节点拉数据，数据的最小单位也是一个Page对象，取到数据后放入Pages队列中本地化计算Presto在选择Source任务计算节点的时候，对于每一个Split，按下面的策略选择一些minCandidates优先选择与Split同一个Host的Worker节点如果节点不够优先选择与Split同一个Rack的Worker节点如果节点还不够随机选择其他Rack的节点对于所有Candidate节点，选择assignedSplits最少的节点。动态编译执行计划Presto会将执行计划中的ScanFilterAndProjectOperator和FilterAndProjectOperator动态编译为ByteCode，并交给JIT去编译为native代码。Presto也使用了GoogleGuava提供的LoadingCache缓存生成的ByteCode。上面的两段代码片段中，第一段为没有动态编译前的代码，第二段代码为动态编译生成的ByteCode反编译之后还原的优化代码，我们看到这里采用了循环展开的优化方法。循环展开最常用来降低循环开销，为具有多个功能单元的处理器提供指令级并行。也有利于指令流水线的调度。小心使用内存和数据结构使用Slice进行内存操作，Slice使用Unsafe#copyMemory实现了高效的内存拷贝，Slice仓库参考：https://github.com/airlift/sliceFacebook工程师在另一篇介绍ORCFile优化的文章中也提到使用Slice将ORCFile的写性能提高了20%~30%，参考：https://code.facebook.com/posts/229861827208629/scaling-the-facebook-data-warehouse-to-300-pb/类BlinkDB的近似查询为了加快avg、countdistinct、percentile等聚合函数的查询速度，Presto团队与BlinkDB作者之一SameerAgarwal合作引入了一些近似查询函数approx_avg、approx_distinct、approx_percentile。approx_distinct使用HyperLogLogCounting算法实现。GC控制Presto团队在使用hotspotjava7时发现了一个JIT的BUG，当代码缓存快要达到上限时，JIT可能会停止工作，从而无法将使用频率高的代码动态编译为native代码。Presto团队使用了一个比较Hack的方法去解决这个问题，增加一个线程在代码缓存达到70%以上时进行显式GC，使得已经加载的Class从perm中移除，避免JIT无法正常工作的BUG。美团如何使用Presto选择presto的原因2013年我们也用过一段时间的impala，当时impala不支持线上1.x的hadoop社区版，所以搭了一个CDH的小集群，每天将大集群的热点数据导入小集群。但是hadoop集群年前完成升级2.2之后，当时的impala还不支持2.2hadoop版本。而Presto刚好开始支持2.xhadoop社区版，并且Presto在Facebook300PB大数据量的环境下可以成功的得到大量使用，我们相信它在美团也可以很好的支撑我们实时分析的需求，于是决定先上线测试使用一段时间。部署和使用形式考虑到两个原因：1、由于Hadoop集群主要是夜间完成昨天的计算任务，白天除了日志写入外，集群的计算负载较低。2、PrestoWorker节点与DataNode节点布置在一台机器上可以本地计算。因此我们将Presto部署到了所有的DataNode机器上，并且夜间停止Presto服务，避免占用集群资源，夜间基本也不会有用户查询数据。Presto二次开发和BUG修复年后才正式上线Presto查询引擎，0.60版本，使用的时间不长，但是也遇到了一些问题：美团的Hadoop使用的是2.2版本，并且开启了Security模式，但是Presto不支持Kerberos认证，我们修改了Presto代码，增加了Kerberos认证的功能。Presto还不支持SQL的隐式类型转换，而Hive支持，很多自助查询的用户习惯了Hive，导致使用Presto时都会出现表达式中左右变量类型不匹配的问题，我们增加了隐式类型转换的功能，大大减小了用户SQL出错的概率。Presto不支持查询lzo压缩的数据，需要修改hadoop-lzo的代码。解决了一个having子句中有distinct字段时查询失败的BUG，并反馈了Presto团队https://github.com/facebook/presto/pull/1104所有代码的修改可以参考我们在github上的仓库https://github.com/MTDATA/presto/commits/mt-0.60实际使用效果这里给出一个公司内部开放给分析师、PM、工程师进行自助查询的查询中心的一个测试报告。这里选取了平时的5000个Hive查询，通过Presto查询的对比见下面的表格。
作为一个建站新手真的很不容易!天天泡在百度贴吧、站长论坛、站长QQ群等站长扎堆的地方。然并卵，啃再多的干货，依然建不好一个站。作为一个有着4年的建站老鸟，我认为选择一款靠谱的建站工具才是建站的关键，建站工具选的不好，后面的效果就会大打折扣，这一点对于不懂代码和设计的新手尤其重要。市场上建站系统大多都是鱼目乱珠，各位新手朋友们在选择建站系统时要擦亮眼睛啦!那么，怎么样的建站工具对于新手来说，才是靠谱的呢?我认为以下三点非常重要：一、功能要强大不管你是新手还是老鸟，在选择建站工具的时候，一定要慎重，不要看到官方介绍的很牛，就买下了，用到一半之后才发现没有自己想要的功能，反倒问题一箩筐，折腾一番，费钱费力费时间，我深有体会。正确的做法应该是，先申请一个免费版试用，试用的时候要了解，是否有自己想要的功能，后台前台的界面如何、扩展性如何、兼容性如何。现在很多建站系统都有免费版的，免费也是可以拥有很好的体验的。二、要简单易上手新购一套系统，要研究个三个天，添加一张图片，要打开三四个页面，这样的系统，你还会用吗?现在大家都那么忙，那还有时间折腾，所以选择一套简单易用的建站系统，可以减少一些不必要的时间浪费。何为简单呢?用目前市场上很火的云指建站系统来举例，直接安装心仪的网站样板，添加需要的模块，更换LOGO，添加图片文章，半天不到就完成了一个网站，不用懂代码和设计，简单快速;且PC站和手机站同一个后台管理，数据同步更新，省时省力。但是简单并不是简陋，简单的是操作步骤，并不是网站，简单易上手但是一定要保证功能齐全。三、网站SEO优化效果要佳很多建站新手最容易忽略的就是这个问题。我觉得SEO优化效果对于网站系统来说是非常重要，这涉及到后期网站的推广收录问题，无收录，做的最多也是白费功夫。搜索引擎的蜘蛛爬过来时是爬的你的程序，做好SEO第一步，肯定从程序代码的优化做起。网站代码的要精简，结构要严密，才有利于索引擎的蜘蛛的爬行。云指建站之所以能这么火，它超棒的SEO效果应该是其中的原因之一。要搭建出一个好网站，不能一味的啃干货，还是得付诸实践中去，现在有很多公司推出了免费版建站，例如云指建站，他们推出了终身免费版建站，还可以绑定顶级域名，新手朋友们可以去申请试试
性能的重要性不言而喻，需要申明的是，美团今天不讲业界最佳性能实践，这些实践已经有很多沉淀，具体可以参考《高性能网站》和《高性能浏览器网络》等书，另外，美团不打算讲性能优化的结果指标，比如页面完全加载时间，首屏时间，结果指标固然重要，是美团工作成果的量化衡量，但是对于做性能优化工作的工程师来说，过程指标对其起到的帮助作用更大。既然不讲最佳实践，那讲什么呢？美团按最佳实践提供的方法去实践，但是后来遇到了瓶颈，到底遇到了什么瓶颈？美团是如何突破这个瓶颈的？成效如何？这些对在座的各位又有什么借鉴意义呢？遇到什么瓶颈？在遇到瓶颈之前，美团做了很多工作，主要包括：简单的数据采集，包括完全加载时间，DomReady时间，需要注意的是这些都是结果指标；依照“业界最佳实践”快糙猛的做了很多事情：比如异步化，静态化，LazyLoading，BigRender，这些实践效果都还不错；因为只有结果指标数据，这个阶段美团绝大部分决策都是基于别人的经验，甚至拍脑袋，而不是基于应用的实际性能细节数据；快糙猛的方式注定不是可持续的，很快，美团遇到了瓶颈，具体是什么瓶颈呢？首先，如果把业界最佳实践当成燃料，而性能优化当成驾车远行的话，美团的燃料很快就烧完了，因为大家总结出来的通用的优化手段总是有限的，而美团的目标还没有达到；其次，因为美团只采集了结果指标，只知道整体表现如何，面对异常波动美团显得特别无力，因为显示世界影响性能的因素太多了，对于到底发生什么事情了，美团无从得知；再次，由于对性能缺少内窥，美团无法找到更多的优化点，实际上，美团需要一个类似于显微镜的东西，来看看应用内部还有哪些可优化的地方；如何突破瓶颈？面对这些瓶颈，美团需要想办法去突破它。在坐下来想办法之前，美团往后退一步，仔细考虑这样一个问题：美团到底在优化什么东西？是文档的生成速度？页面资源的加载速度？页面的渲染速度？或者说更高大上的用户体验？这些问题想清楚了，才能分析的更彻底。其实，大多数的性能优化工作都开始于瀑布流图的分析，下面美团就来看看美团项目详情页的瀑布流图：美团把项目详情页的资源分为以下几部分：主文档，即页面的内容，在拿到主文档之前，浏览器啥都干不了；核心CSS，和首屏图片，在拿到这些之后，浏览器可以开始渲染了；核心JS，拿到这些内容之后，页面的交互被丰富，但是也会阻塞；其他内容，比如雪碧图，统计脚本等；从技术上来讲，美团优化的就是这个瀑布流图的每个环节，那么瀑布流图的背后是什么？其实就是页面加载过程中各个资源的加载时间分解：从上到下的箭头表示时间轴，从浏览器跳转，缓存检查，再到DNS、TCP建连，然后发起主文档请求，再到接收完最后一个字节，再到浏览器开始CSS、JS、图片的下载，最后是页面渲染和交互响应。根据《高性能网站建设指南》上的数据以及美团的观察，整个页面的加载可以划分为3大块：网络时间、后端时间、前端时间，发生在网络和后端的时间占到整体加载时间的10%和20%，而前端资源加载时间占到整体加载时间的70%~80%。前端资源加载是否快速对性能影响是最大的，这里面资源的加载顺序，并发数量，都有很多的工作可做：比如，如果你发现CSS加载之前的阻塞时间很长，那很可能是资源加载顺序不合理，这必然会导致浏览器渲染延后。页面的加载时间还能分解的更细么？到目前为止，美团都是站在浏览器的视角，划清了各个环节。浏览器拿到文档之前，是不会做任何事情的，后端响应速度的变动多数时候能引发性能上的蝴蝶效应，美团的突破口就在后端处理时间上：服务器收到请求之后，会经历请求分发、业务逻辑处理、文档生成这三个阶段，在业务逻辑处理阶段，会涉及到和数据库、缓存以及内部服务的通信，拿到所有的数据之后，渲染模板，最后发送给浏览器。对页面加载过程中涉及到的所有环节进行分解和细化，就形成了美团的分析框架。如何把控性能？有了分析框架，那么如何全面的把控网站的性能呢？基于这个框架，美团通过统计脚本加上必要的数据统计（这里的统计都是过程指标，只反映页面加载过程中某个环节的健康状况），就能获得对整个网站的很多内窥。具体来说，美团对数据的要求是这样的：整个流程各环节的，多维度（比如分页面、分地理区域、分浏览器）的，实时的（方便美团快速实验）。所有的数据都必须是能够反映整体的统计量。而对于统计脚本，需要满足两个条件：避免对业务代码的入侵；不影响被测量的页面的性能；针对第1个要求，需要开发独立的统计脚本，避免其与现有的框架耦合，方便移植到其他项目；而针对第2个要求，需要在主文档加载完毕之后，再注入统计脚本收集数据，并且尽可能的合并数据请求，减少带宽消耗。确定了数据统计脚本的约束条件之后，美团从哪里得到这些数据呢？目前使用的主要途径有：主文档加载速度，利用NavigationTimingAPI取得；静态资源加载速度，利用ResourceTimingAPI取得；首次渲染速度，IE下用msFirstPaint取得，Chrome下利用loadTimes取得，美团的Chrome浏览器用户占比超过70%；文档生成速度，则是在后端应用内打点来获得；对于主文档加载速度，美团从宏观到微观的做了这样的分解，从上到下的时间流，右边的时刻标记了每个指标从哪里开始计算到哪里截止，比如，跳转时间redirect由redirectEnd-redirectStart计算得到，其他的类推：采集主文档加载速度的具体做法是：在主文档load之前提供可缓存数据的接口，方便在统计脚本载入前就可以准备数据；在主文档load之后注入数据收集脚本，该脚本加载完成之后会处理所有的数据；利用NavigationTimingAPI收集计算得到上图中的指标；给所有数据打上页面、地理位置、浏览器等标签，方便更细维度的分析；对于静态资源的加载速度，美团也做了类似的分解和采集：需要特别提示的是，如果你使用CDN的话，需要让CDN服务商加上Timing-Allow-Origin的响应头，才能拿到静态资源的数据。而对于主文档生成速度，美团则开发了性能统计的Library，在框架级别集成后端性能的时间指标。实际效果如何？通过上面的各种数据采集，美团拿到了页面加载全流程、全方位、多角度的真实用户数据，有这些数据之后，美团能做什么呢？之前遇到的瓶颈不再是瓶颈，因为美团可以利用这些数据做很多事情，下面举几个实际的例子：FlushEarly是否有效？《高性能网站进阶指南》上提到要尽快输出文档的第首字节提高性能，美团很早的时候做了这个事情，但是从数据上看，在页面完全加载时间上的收益不大，做了更细的数据采集之后，美团快速的在线上做了这样的实验：在特定页面把FlushEarly关掉，结果发现，浏览器接收到第1个字节的时间增加了100+ms，如下图（红色箭头表示变更上线时间点）：而完成文档传输的时间减少了150+ms，如下图：表面上看，似乎禁用FlushEarly效果好些，但是再看看浏览器的首次渲染时间，增加了300+ms，如下图：也就是说，有些优化措施，总结果指标上看貌似没啥效果，但是换个角度看效果非常明显。有了全方位的数据，美团能更高效的试错。发现新的优化点为了优化文档生成速度，美团一度想到优化函数级别的调用，利用FaceBook的HipHop为PHP加速，通过数据发现，在美团生成文档的时间构成中30%是在和缓存交互，这个比例太高了，当优化缓存服务器之后，后端时间大幅下降，缓存占比降到10%以下。另外，美团主站的迭代速度非常快，每天大概50次左右的上线，通过数据发现，每次上线都会导致性能的轻微恶化，如果某天上线次数越多，那么性能就好不到哪里去？原因美团合并了大量的JS请求，当其中的某个模块在某次迭代中被修改，整个合并的文件需要被重新下载，这就对模块拆分和加载提出了更高的要求。有了更细节的数据美团能有效发现新的优化点。性能监控平台美团不光突破了之前遇到的瓶颈，实际上，美团走的更远，因为美团觉得解决一个问题不如解决一类问题，美团解决问题的思路和工具同样能适用于公司的其他产品线：于是美团在做性能优化的过程中逐步建设起来性能监控平台，目的是为公司的其他产品线和内部系统提供一站式的性能数据收集、计算、存储和展示服务。目前性能监控平台已经接入20余个公司内部系统，能够支持任意指标、任意维度的实时数据查询。该平台为不同的项目提供了性能仪表盘功能，方便快速了解整体的性能状况：同时还为做性能优化的工程师提供了简单的数据分析功能，方便其以数据驱动的方式的开展性能优化工作：总结以上，就是美团做性能优化时遇到的问题，以及解决的办法，下面大概说下，我对这些事情的总结：首先，需要深入的剖析问题，性能分析问题的框架，让很多死角暴露无疑；其次，在性能优化这件事情上，只关注结果指标是不会给你多大帮助的，如果想真的优化，你需要测量过程指标，从过程指标发现更多；再次，解决一个问题比如解决一类问题，解决问题的思路和工具可以沉淀下来，服务更多的团队和同事；
中国互联网举报中心