一、系统概述1、Amazon平台概述 Amazon平台是一个由数百服务组成的面向服务的架构，其秉承高度去中心化、松散耦合、完全分布式的原则，具体架构参考下图。在这种环境中，尤其需要一个始终可用的存储系统，由此，Dynamo诞生了。2、Dynamo概述Dynamo是Amazon提供的一款高可用的分布式Key-Value存储系统，其满足可伸缩性、可用性、可靠性。CAP原理满足：通过一致性哈希满足P，用复制满足A，用对象版本与向量时钟满足C。用牺牲C来满足高可用的A，但是最终会一致。但是，是牺牲C满足A，还是牺牲A满足C，可以根据NWR模型来调配，以达到收益成本平衡。Dynamo内部有3个层面的概念：Key-Value：Key唯一标识一个数据对象，Value标识数据对象实体，通过对Key来完成对数据对象的读写操作。节点node：节点是指一个物理主机。在每个节点上，会有3个必备组件：请求协调器（requestcoordination）、成员与失败检测、本地持久引擎（localpersistenceengine），这些组件都由Java实现。本地持久引擎支持不同的存储引擎，最主要的引擎是BerkeleyDatabaseTransactionalDataStore（存储数百K的对象更合适），其它还有BDBJavaEdtion、MySQL以及一致性内存Cache。本地持久化引擎组件是一个可插拔的持久化组件，应用程序可以根据需要选择最合适的存储引擎，比如：如果存储对象的通常为数千字节则可以选择BDB，如果是更多尺寸则可以选择MySQL。生产中，Dynamo通常使用BDB事物数据存储。实例instance：从应用的角度来看就是一个服务，提供IO功能。每个实例由一组节点组成，这些节点可能位于不同的IDC，这样IDC出现问题也不会导致数据丢失，这样会有更好的容灾和可靠性。二、背景条件1、系统假设与要求（1）查询模型基于Key-Value模型，而不是SQL即关系模型。存储对象比较小，通常小于1MB。（2）ACID属性传统的关系数据库中，用ACID（A原子性、C一致性、I隔离性、D持久性）来保证事务，在保证ACID的前提下往往有很差的可用性。Dynamo用弱一致性C来达到高可用，不提供数据隔离I，只允许单Key更新。（3）效率在廉价的机器上满足SLA，通过配置来满足延时和吞吐量的要求，因此，必须在性能、成本、可用性和持久性保证之间做权衡。（4）其它假设Dynamo仅在Amazon内部使用，因此，认为其使用环境是可信赖的。2、服务水平协议（SLA） 所谓服务水平协议是指客户端和服务端在某几个指标上达成一致的一个协议，通常包括客户端请求API的速率、服务端的预期延时，比如：在客户端每秒500个请求负载的高峰时，99.9%的响应时间为300毫秒。 一般业界，对这种面向性能的SLA采用平均数（average）、中值（median）和预期变化（expectedvariance）。但是这些指标只能对大多数客户端有良好体验，而不是所有。为了解决这个问题，Dynamo采用99.9%百分位来代替这些指标。3、设计考虑（复制数据）传统的数据复制算法，在出现故障时，为了保证数据一致性被迫牺牲掉可用性，即：与其不能确定数据是否正确，不如让数据一直不可用直到数据绝对正确时。但是，一个高度灵活的系统应该能够让用户知道在何种情况下能到达哪些属性，Dynamo就是如此。对于故障是常态的系统来说，采用乐观复制技术可以提供系统的可用性，但带来的问题是需要检测并协调解决冲突，协调解决冲突的过程又包含两个问题，即：何时协调和由谁协调。Dynamo的设计是数据存储最终一致，即所有更新操作最终到达所有副本。（1）何时协调无外乎两种情况：写或者读时协调冲突。传统数据存储在写时协调冲突，即如果给定时间内数据不能达到所要求的所有或大多数副本数，则写入可能会被拒绝。Amazon认为拒绝客户的更新操作会导致糟糕的用户体验，典型应用是购物车服务，即使出现故障，客户仍然可以向购物车添加或者删除物品，基于此，Dynamo的目标定位为“永远可写”（alwayswritable）即数据存储的“写”是高可用的。也就是说Dynamo为了确保“写”永远不会被拒绝，那么数据存储在读时协调冲突。（2）由谁协调无外乎两种情况：由数据存储本身或客户端应用程序来协调。如果是数据存储本身协调，则只能使用简单策略来协调冲突的更新操作，比如：“最后一次写入获胜”（lastwritewins）。如果是客户端应用程序协调，则应用程序可以根据业务需求来选择最适合协调冲突的方法。Dynamo选择了后者，典型应用还是购物车服务，返回所有数据对象版本，最后选择合并完冲突的版本。三、关键技术Dynamo作为一类分布式系统的典型代表，其众多关键技术给其带来一系列的优势，具体参看下表：1、数据分区Hash算法：使用MD5对Key进行Hash以产生一个128位的标示符，以此来确定Key的存储节点。为了达到增量可伸缩性的目地，Dynamo采用一致性哈希来完成数据分区。在一致性哈希中，哈希函数的输出范围为一个圆环，如图2所示，系统中每个节点映射到环中某个位置，而Key也被Hash到环中某个位置，Key从其被映射的位置开始沿顺时针方向找到第一个位置比其大的节点作为其存储节点，换个角度说，就是每个系统节点负责从其映射的位置起到逆时针方向的第一个系统节点间的区域。一致性哈希最大的优点在于节点的扩容与缩容，只影响其直接的邻居节点，而对其它节点没有影响。这样看似很完美了，但是亚马逊没有因此而停止脚本，这是其伟大之处，其实还存在两个问题：节点数据分布不均匀和无视节点性能的异质性。为了解决这两个问题，Dynamo对一致性哈希进行了改进而引入了虚拟节点，即每个节点从逻辑上切分为多个虚拟节点，每个虚拟节点从逻辑上看像一个真实节点，这样每个节点就被分配到环上多个点而不是一个单点。2、数据复制为了实现高可用，Dynamo将每个数据复制到N台主机上，其中N是每个实例（per-instance）的配置参数，建议值为3。每个Key被分配到一个协调器（coordinator）节点，协调器节点管理其负责范围内的复制数据项，其除了在本地存储其责任范围内的每个Key外，还复制这些Key到环上顺时针方向的N-1个后继节点。这样，系统中每个节点负责环上从其自己位置开始到第N个前驱节点间的一段区域。具体逻辑见图2，图中节点B除了在本地存储键K外，还在节点C和D处复制键K，这样节点D将存储落在范围(A,B]、(B,C]和(C,D]上的所有键：对于一个特定的键都有一个首选节点列表，由于虚拟节点的存在，为了解决节点故障的问题，构建首先节点列表时会跳过环上某些位置，让这些节点分别位于不同的物理节点上，以保证高可用。为了保证复制时数据副本的一致性，Dynamo采用类似于Quorum系统的一致性协议实现。这里涉及到三个关键参数(N,R,W)，其中，N是指数据对象复制到N台主机，协调器负责将数据复制到N-1个节点上，亚马逊建议N配置为3，R代表一次成功的读取操作中最小参与节点数量，W代表一次成功的写操作中最小参与节点数量。R+W>N，则会产生类似于Quorum的效果。该模型中，读（写）延迟由最慢的R(W)复制副本决定，为了得到比较小的延迟，R和W通常配置为小于N。亚马逊建议(N,R,W)设置为(3,2,2)以兼顾性能与可用性。R和W直接影响性能、扩展性和一致性，如果W设置为1，则一个实例中只要有一个节点可用，也不影响写操作，如果R设置为1，只要有一个节点可用，也不会影响读请求，R和W值过小则影响一致性，过大则可用性，因此，需要在R和W两个值之间平衡，这也是Dynamo的一个亮点之一。3、版本合并由前文可知，Dynamo为了保证高可用，对每份数据都复制了多份（建议3份），在数据没有被异步复制到所有副本前，如果有get操作会取到不一致的数据，但是Dynamo提供最终一致性。在亚马逊平台中，购物车就是这种情况的典型应用，为了保证购物车永远可用，对任何一个副本的任何一次更改操作的结果都会当做一个数据版本存储起来，这样当用户get时就会取到多个版本，这样也就需要做数据版本合并了。Dynamo将合并工作推给应用程序，在这里就是购物车get时处理。Dynamo用向量时钟来标识同一数据在不同节点上多个副本之间的因果关系。向量时钟实际上就是一个列表，列表的每个节点是一个(node,counter)对，即(节点，计数器)列表。数据版本之间的关系要么是因果关系，要么是平行关系，关系判断依赖于计数器值大小，如果第一个时钟对象的计数器小于或等于所有其它时钟对象的计数器时则是因果关系，那么因是果的祖先可以认为是旧版数据而直接忽略，否则是平行关系，那么就认为数据版本产生了冲突，需要协调并合并。在Dynamo中，当客户端更新一个对象时，必须指定更新哪个版本数据，更新版本依赖于早期get操作时获得的向量时钟。向量时钟的使用过程图上图3所示，具体流程解析如下：客户端写入一个新对象。节点Sx处理了这个请求，处理对key的写：序列号递增，并创建数据的向量时钟，这样在该节点上生成对象D1和向量时钟[(Sx,1)]。客户端更新该对象。假设由同样的节点即Sx处理了这个请求，由于该节点有了D1和向量时钟[(Sx,1)]，则更新该对象后在该节点上生成对象D2和向量时钟[(Sx,2)]，D2继承自D1，即D2覆写D1，计数器增1，但其它节点此时可能是D1，也可能是D2，这取决于网络和节点状态。假设同一客户端更新该对象但被不同的服务器处理了。节点Sy处理了这个请求，则更新该对象后在该节点上生成对象D3和向量时钟[(Sx,2),(Sy,1)]。假设另一客户端读取到了D2并尝试更新它但被另一个不同的服务器处理了。节点Sz处理了这个请求，则更新该对象后在该节点上生成对象D4和向量时钟[(Sx,2),(Sz,1)]。节点数据版本回收。现在有4个版本的数据存在并在各个节点之间传递了，当节点收到D3或D4时，会根据向量时钟将D1和D2回收掉，因为其是D3和D4的祖先。但是收到D3和D4的节点，根据向量时钟发现它们之间是并行关系，则保留二者，并在客户端get时将二者都提交给客户端由其来协调并合并版本。假设客户端读取数据，则会获取到D3和D4，根据两者的向量时钟，会合并为D5和向量时钟[(Sx,2),(Sy,1),(Sz,1)]，节点Sx协调写操作，并更新对象和向量时钟。从上面的过程中可以看出，在节点比较多且情况极端时，向量时钟列表会增长，Dynamo对此采用时钟截断方案来解决此问题，即(node,counter)对带有时间戳，在数目达到阈值（比如：10）时，将最早的一对从向量时钟中删除。4、故障检测（1）RingMembership每个节点启动时存储自己在环上的映射信息并持久化到磁盘上，然后每个节点每隔一秒随机选择一个对等节点，通过Gossip协议传播节点的映射i信息，最终每个节点都知道对等节点所处理范围，即每个节点都可以直接转发一个key的读/写操作到正确的数据集节点，而不需要经过中间路由或者跳。（2）ExternalDiscovery如果人工分别往Dynamo环中加入节点A和B，则RingMembership不会立即检测到这一变化，而出现暂时逻辑分裂的Dynamo环（A和B都认为自己在环中，但是互相不知道对方存在）。Dynamo用ExternalDiscovery来解决这个问题，即有些Dynamo节点充当种子节点的角色，在非种子节点中配置种子节点的IP，所有非种子节点都与种子节点协调成员关系。（3）FailureDetectionDynamo采用类Gossip协议来实现去中心化的故障检测，使系统中的每个节点都可以了解其它节点的加入和likai5、故障处理传统的Quorum，在节点故障或者网络故障情况下，系统不可用。为了提高可用性，Dynamo采用SloppyQuorum和HintedHandoff，即所有读写操作由首选列表中的前N个健康节点执行，而发往故障节点的数据做好标记后被发往健康节点，故障节点重新可用时恢复副本。如上面所示Dynamo配置N为3。如果在写过程中节点A暂时不可用（Down或无法连接），则发往A的副本将被发送到节点D，发到D的副本在其原始数据中有一个hint以表明节点A才是副本的预期接收者，D将副本数据保存在一个单独的本地存储中，在检测到A可用时，D尝试将副本发到A，如果发送成功，D会将数据从本地存储中删除而不会降低系统中的副本总数。一个高可用的存储系统具备处理整个IDC故障（断电、自然灾害、网络故障灯）的能力是非常重要的，Dynamo就具备此能力。Dynamo可以配置成跨多个IDC复制对象，即key的首选列表由跨多个IDC的节点组成，这些IDC之间由高速专线连接，跨多个IDC的复制方案使得Dynamo能够处理整个IDC故障。此外，为了处理在hinted副本移交会预期节点之前该副本不可用的情况，Dynamo实现了anti-entropy协议来保持副本同步，为了更快递检测副本之间的不一致性并减少传输量，Dynamo采用MerkleTree。6、扩容/缩容（1）扩容当一个新节点X加入到系统中时，其得到一些随机分配到环上的token，节点X会负责处理一个keyrange，而这些key在节点X加入前由现有的一些节点负责，当节点X加入后，这些节点将这些key传递给节点X。以图2为例，假设节点X添加到环中A和B之间的位置，当X加入到系统中后，其负责的key范围为(F,G],(G,A],(A,X]，节点B、C和D都各自有一部分不再需要存储的key范围，即在X加入前，B负责(F,G],(G,A],(A,B]；C负责(G,A],(A,B],(B,C]；D负责(A,B],(B,C],(C,D]，而在X加入后，B负责(G,A],(A,X],(X,B]；C负责(A,X],(X,B],(B,C]；D负责(X,B],(B,C],(C,D]。节点B、C和D在收到节点X加入的确认信号后出发这一过程。（2）缩容当从系统中删除一个节点时，key的重新分配情况与步骤（1）正好相反。 7、读/写操作读取和写入由请求协调组件执行，每个客户端请求都将导致在处理该请求的节点上创建一个状态机，每个状态机都包含以下逻辑：标识负责一个key的节点；发送请求；等待回应；可能的重试处理；加工和包装返回客户端响应。每个状态机实例只处理一个客户端请求，如果是一个读请求，则状态机如下：发送读请求到相应结点；等待所需的最低数量的响应；如果在给定的时间内收到的响应太少，则请求失败；否则收集所有数据的版本，并确定要返回的版本；如果启用版本合并，则执行语法协调并生成一个对客户端不透明的写上下文，其中包含一个囊括所有版本的向量时钟。返回读取响应给客户端后，状态机等待一段时间以接受任何悬而未决的响应，如果任何响应返回了过时的版本，则协调员用最新版本更新这些节点，以完成读修复。写请求通常跟随在读请求之后，则协调员由读操作答复最快的节点充当，这种优化能提高读写一致性。五、解决问题1、可用性完全去中心化，无单点，永远可写。2、伸缩性带虚拟机节点的一致性hash：一致性hash解决扩容/缩容问题，虚拟节点解决机器异质性问题。3、可靠性数据复制多份副本，用向量时钟解决版本合并问题。4、可配置平衡性可调，即根据（N,W,R）模型平衡可用性和一致性，建议模型参数为（3,2,2）。
原创自媒体春天的到来过去的2015年至少能让不少的自媒体原创作者感到欣慰，原创越来越受到重视，原创自媒体人的生成环境在逐渐变好。微信开通了原创认证标志，那些依靠抄袭和整理出名的大号面临没落危机；今日头条开展了”千人万元计划”，只有开通原创功能的作者才可以申请；百度推出“原创星火2.0项目”，其他的自媒体平台也在加强对原创的保护措施。虽然在站长圈子，大家依然习惯不带任何说明的复制别人的文章，但是几个比较知名的站长在这方面做到比较到位。拿百度的星火计划来说，可以预期的是原创文章的排名是会越来越高，这是许多原创站长多年的梦想。当然了，实际情况是怎样，我们只能拭目以待了。音频是与视频自媒体的影响力越来越大现在的年轻人很少愿意抱着一长篇文章慢慢看了，社会的节奏变快了，大家都比较浮躁，并且由于互联网信息太多，或多或少的有些视觉疲劳了。很多人越来越习惯听音频和直接看视频而不是文字了。所以懒人听书这样的app很多人在用，音频自媒体平台喜马拉雅发展情况也非常不错。公开的数据显示喜马拉雅”2012年底网站上线，2013年4月份IOS版本上线，2013年8月安卓版上线。现在应该有两亿多激活用户，六万认证主播，一千八百万条内容。2013年获得1150万美元A轮融资，2014年获得五千万美元B轮融资。最近刚完成了拆VIE。”至于视频自媒体，除了比较知名的《逻辑思维》，其实想搜狐，今日头条等自媒体平台都开了视频栏目，更不用说优酷，美拍，卫视等视频和段视频平台了。尽可能多的注册自媒体平台目前的自媒体平台多不胜数，隔三差五就会冒出个自媒体平台，我比较推荐的是:今日头条，庞大的读者群体。搜狐自媒体：在搜索引擎中较高的排名。百度百家，收录的速度比较快。一点资讯，阅读量仅次于今日头条。还有腾讯自媒体，新浪自媒体，凤凰自媒体，百度还出了个百度媒体号，还有其他自媒体平台大约不下20个。如果站长们能尽量抽出时间，我建议尽可能多的把文章发到这些自媒体平台。增加原创文章的数量由于原创文章越来越受到重视，现在站长们想要在没有原创的情况下把排名做上去是有难度了。当然也不排除一些seo技术比较高的站长使用一些灰色手法将做出排名，但是这样终究不是长久之计。我一个站长朋友曾经有好几千的关键词，通过站群和垃圾文章做出来的，最后在一夜之间掉的一个不剩。写原创文章的另外一个好处是投稿，写完文章我们可以投稿到其他站长博客上去。所说在刚开始一段时间，文章可能会被权重比较高的博客所淹没，但终究会上来的。要不然，百度的星火计划也就是一纸空文了。如果条件允许，设计音频或者视频是个不错的做法这一步朱海涛是没能做到，不是不想做，是没有相关资源，主要还是缺少这方面的资源。做音频或者视频最重要的是的人才，做视频需要口才和表现力，做音频需要有一个好嗓子，这些都是文字自媒体人难以企及的。武汉有一团队的做法是签约主播方式做视频自媒体，这个当然也是需要经验和资源才能操作的。,找到适合的商品或者项目很多自媒体站长做不了多久就倒下，最主要的原因是无法盈利，能坚持一年没有任何盈利的站长就很少了。本身做自媒体一般来说还是不太缺流量的，关键有了流量有，我们需要有自己的项目或者产品来转化出利润。比如，朱海涛这边就打算在2020年做做电商，当然了也是有电商人才加入进来。自媒体站长还可以操作一些网络项目，不管是实体项目还是网络虚拟项目，我曾经做的借贷宝就是个例子。我在那篇文章中有一点没有写到，“利用网络流量发动地推团队，是最好的结合线上线下的方式”。可以说只有流量没有产品项目，就好比是浮水之萍，难以扎根。团队配合操作如果是专职做自媒体做网络的，我建议是一定要有一个团队。作为一个初期单打独斗者，已经深深的感受到了个人力量的单薄。个人能力太强大，精力总是有限的，毕竟我们是人，不是机器，不可能一天24小时不吃不喝的去战斗。个人操作，意味着，无论大事小事，每件事我们都要去亲力亲为。而有些事实毫无技术含量的，这样我们大量的事情浪费在一些次要因素上，导致最重要的事情没有时间去做。况且有些团队成员可能会给我们带来不同的经验，资源或者思维方式。这样也能尽可能的弥补我们自身的不足。2020年自媒体生存之道做的就是三点：顺应趋势；生存才能发展；团队力量大。当然这三点这个也是创业和生存的哲学，我发现目前生存的比较好的自媒体站长和网络人，在这三个点上都做得极为优秀的。希望做自媒体的站长们在2020年能达到新的高度。以上就是对浅析2020年自媒体站长和网络营销人生存之道全部内容的介绍，更多内容请继续关注站三界导航！
建网站是传统企业连接互联网最普遍的方式，各种类型的网站都已随处可见，成功者山外有山，都是小巫见大巫的时代。但随着互联网技术的高速发展，网站也开始有了偏重的方向，就如当前，已经越来越多的企业重视建设营销型的网站，这种网站的价值体现在哪里呢? 所谓营销型网站的运用还得基于对其真正的认识和理解，才能发挥其最大价值。这类网站出现的主要目的是能够让企业以最直接的方式达到营销效果，且实现最终的盈利目标。第一，重在本质。传统的展示型网站往往是以审美视觉为重，只要做到让企业信息内容通过网站能够美美地展示在用户面前就达到目的，不管有没有营销效果，页面足够精美丰富就足矣，这也许就只是用户眼中的“花瓶”，除了观赏也别无所用。但营销型网站更注重用户的实际体验，甚至是搜索引擎营销价值，因此从网站内部架构，程序编写的本质来看，都严格按照营销型网站建设的原则进行，譬如不利于页面加载速度、搜索引擎抓取的那些图片视频动画等元素都将省去，以保证用户体验。第二，易于推广。一个成功的营销型网站都有一种神奇的力量，通过网站的配色效果，整体页面布局，内容排布等等，成功引导客户从网站上搜寻需要的产品，激发客户的购买欲望。这种营销型网站普遍都有专门的营销栏目进行各种营销活动的设计，并放置于最显眼的位置，让用户一目了然，进而促成营销效果。这些都是关于网站站内推广的特征，其次在站外推广起来也比较容易，刚刚奇亿网络在上面提到的构建营销型网站的技术特征，对于网站的优化推广是非常有帮助的，有好的网站结构更受搜索引擎的青睐，更容易提升网站权重和排名。第三，方便交易。营销的最终目的是获得转化率，然而营销型的网站功能设置明显区别于其他类型的网站，一般都会包含直接的线上交易功能，当用户浏览网站之后看到喜欢的产品，可以下单支付到完成交易，这就是最直接的流量转化，网站能不能达到营销效果，从订单的转化就可作出判断，满足了用户的购买需求，同时对于企业收集用户需求数据也极其便利，为企业作下一步的营销计划提供有利的帮助。建网站更多的是从运营角度来看一个网站的价值，归根结底，能给企业带来效益就是网站价值的最终体现。营销型网站不仅有企业展示的功能，更多是的在互联网上具有实现品牌营销以及完成订单的作用，也即是其备受企业欢迎的价值所在。
这用户为王的时代，做好网站的用户体验才是重中之重;一个企业的建站最终目的是引进客户，把产品推出去。但对于一个新站如何做到面面俱到，赢得用户的心?又怎样保证用户的客户群，面对种种挑战，新站又该如何着手?下面小编就为大家详细介绍一下，来看看吧!首先从竞争对手出发，各行各业都有着无数的竞争对手，想要自己网站收获更好的排名，引进更大的客户量，首要了解竞争对手的推广模式，看看他的网站哪些地方博得搜索引擎的青睐，客户为什么选择了他。参考自己的网站，取其精华，补齐不足;懂得逆袭思维，制作一份更好的建站方案。其次要注重界面的美观;看一个人美不美，首要是看脸，身材再好，脸上有疙瘩，也引不了别人的注意;所以简洁美观的界面是用户体验的基本，界面的设计对用户有很强的视觉冲击力。不管是颜色的运用、字体的调节、图片的使用;网页界面的好坏直接决定了产品是否能够成功。若视觉效果做的极其糟糕，用户会很快离开你的页面。连最基本的产品视觉美化都做不好，还能指望它的用户体验能有多好?对于服务器的购买，域名的选择，前面的文章已经说过很多次了;建站方案的策划、页面的美观都是建网站的基石，基石打好了，后期优化才能顺流而上;那么上线过后，新站又该怎样在最短的时间内让用户更容易找到你了;提升搜索引擎的排名，引来百度蜘蛛的青睐;在这个信息大爆炸的时代，有价值的原创文章是最抢手的;所以，对于新站在后期管理中，添加价值的信息才能冲出前线。站在用户的角度上，唯有新鲜好奇有价值的信息能博得用户的青睐;所以可以在页面上适当的添加一些激发用户点击率的信息，可以是产品有趣的简介，可以是充满新鲜感的内容等;抖了包袱不直接给予答案，更吸引用户。做到以‘悬’引人，以‘密’迷人。当然，对用户的理解，以上只是我的一下见解，毕竟每个人有每个人的视觉感知;虽然不能做到最好，但我们要奔着更好的目标出发;最终给予用户舒适的视觉享受和阅读兴趣。
阿里巴巴作为国内使用Hadoop最早的公司之一，已开启了ApacheHadoop2.0时代。阿里巴巴的Hadoop集群，即云梯集群，分为存储与计算两个模块，计算模块既有MRv1，也有YARN集群，它们共享一个存储HDFS集群。云梯YARN集群上既支持MapReduce，也支持Spark、MPI、RHive、RHadoop等计算模型。本文将详细介绍云梯YARN集群的技术实现与发展状况。MRv1与YARN集群共享HDFS存储的技术实现以服务化为起点，云梯集群已将Hadoop分为存储（HDFS）服务与计算（MRv1和YARN）服务。两个计算集群共享着这个HDFS存储集群，这是怎么做到的呢？在引入YARN之前，云梯的Hadoop是一个基于ApacheHadoop0.19.1-dc版本，并增加许多新功能的版本。另外还兼容了ApacheHadoop0.19、0.20、CDH3版本的客户端。为了保持对客户端友好，云梯服务端升级总会保持对原有客户端的兼容性。另外，为了访问数据的便捷性，阿里的存储集群是一个单一的大集群，引入YARN不应迫使HDFS集群拆分，但YARN是基于社区0.23系列版本，它无法直接访问云梯HDFS集群。因此实现YARN集群访问云梯的HDFS集群是引入YARN后第一个需要解决的技术问题。Hadoop代码主要分为Common、HDFS、Mapred三个包。Common部分包括公共类，如I/O、通信等类。HDFS部分包括HDFS相关类，依赖Common包。Mapred部分包括MapReduce相关代码，依赖Common包和HDFS包。为了尽量减少对云梯HDFS的修改，开发人员主要做了以下工作。使用云梯的HDFS客户端代码替换0.23中HDFS，形成新的HDFS包。对0.23新的HDFS包做了少量的修改使其可以运行在0.23的Common包上。对0.23新的HDFS包做了少量修改使0.23的Mapred包能运行在新的HDFS包。对云梯的Common包的通信部分做了hack，使其兼容0.23的Common。图1云梯Hadoop代码架构新的云梯代码结构如图1所示，相应阐述如下。服务端存储部分使用原有的HDFS。MRv1计算集群中提供原MRv1服务。YARN集群提供更丰富的应用服务。客户端云梯现有的客户端不做任何修改，继续使用原有的服务。使用YARN的服务需要使用新客户端。云梯MR服务切换为YARN要经过三个阶段服务端只有MRv1，客户端只有老版本客户端。服务端MRv1和YARN共存（MRv1资源逐渐转移到YARN上），客户端若需使用MRv1服务则保持客户端不变；若需使用YARN服务则需使用新版客户端。服务端只剩下YARN，客户端只有新版本客户端。通过上述修改，云梯开发人员以较小的修改实现了YARN对云梯HDFS的访问。SparkonYARN的实现云梯版YARN集群已实现对MRv2、Hive、Spark、MPI、RHive、RHadoop等应用的支持。云梯集群当前结构如图2所示。图2云梯架构图其中，Spark已成为YARN集群上除MapReduce应用外另一个重要的应用。Spark是一个分布式数据快速分析项目。它的核心技术是弹性分布式数据集（ResilientDistributedDatasets），提供了比MapReduce丰富的模型，可以快速在内存中对数据集进行多次迭代，来支持复杂的数据挖掘算法和图形计算算法。Spark的计算调度方式，从Mesos到Standalone，即自建Spark计算集群。虽然Standalone方式性能与稳定性都得到了提升，但自建集群毕竟资源较少，并需要从云梯集群复制数据，不能满足数据挖掘与计算团队业务需求。而SparkonYARN能让Spark计算模型在云梯YARN集群上运行，直接读取云梯上的数据，并充分享受云梯YARN集群丰富的计算资源。SparkonYARN功能理论上从Spark0.6.0版本开始支持，但实际上还远未成熟，经过数据挖掘与计算团队长时间的压力测试，修复了一些相对关键的Bug，保证SparkonYARN的稳定性和正确性。图3展示了SparkonYARN的作业执行机制。图3SparkonYARN框架基于YARN的Spark作业首先由客户端生成作业信息，提交给ResourceManager，ResourceManager在某一NodeManager汇报时把AppMaster分配给NodeManager，NodeManager启动SparkAppMaster，SparkAppMaster启动后初始化作业，然后向ResourceManager申请资源，申请到相应资源后SparkAppMaster通过RPC让NodeManager启动相应的SparkExecutor，SparkExecutor向SparkAppMaster汇报并完成相应的任务。此外，SparkClient会通过AppMaster获取作业运行状态。目前，数据挖掘与计算团队通过SparkonYARN已实现MLR、PageRank和JMeans算法，其中MLR已作为生产作业运行。云梯YARN集群维护经验分享云梯YARN的维护过程中遇到许多问题，这些问题在维护YARN集群中很有可能会遇到，这里分享两个较典型的问题与其解决方法。问题1问题描述：社区的CPU隔离与调度功能，需要在每个NodeManager所在的机器创建用户账户对应的Linux账户。但阿里云梯集群有5000多个账户，是否需要在每个NodeManager机器创建这么多Linux账户；另外每次创建或删除一个Hadoop用户，也应该在每台NodeManager机器上创建或删除相应的Linux账户，这将大大增加运维的负担。问题分析：我们发现，CPU的隔离是不依赖于Linux账户的，意味着即使同一个账户创建两个进程，也可通过Cgroup进行CPU隔离，但为什么社区要在每台NodeManager机器上创建账户呢？原来这是为了让每个Container都以提交Application的账户执行，防止Container所属的Linux账户权限过大，保证安全。但云梯集群很早前就已分账户，启动Container的Linux账户统一为一个普通账户，此账户权限较小，并且用户都为公司内部员工，安全性已能满足需求。解决方案：通过修改container-executor.c文件，防止其修改Container的启动账户，并使用一个统一的普通Linux账户（无sudo权限）运行Container。这既能保证安全，又能减少运维的工作量。问题2问题描述：MRApplicationMaster初始化慢，某些作业的MRApplicationMaster启动耗时超过一分钟。问题分析：通过检查MRApplication-Master的日志，发现一分钟的初始化时间都消耗在解析Rack上。从代码上分析，MRApplicationMaster启动时需要初始化TaskAttempt，这时需要解析split信息中的Host，生成对应的Rack信息。云梯当前解析Host的方法是通过调用外部一个Python脚本解析，每次调用需要20ms左右，而由于云梯HDFS集群非常大，有4500多台机器，假如输入数据分布在每个Datanode上，则解析Host需要花费4500×20ms=90s；如果一个作业的输入数据较大，且文件的备份数为3，那么输入数据将很有可能分布在集群的大多Datanode上。解决方案：开发人员通过在Node-Manager上增加一个配置文件，包含所有Datanode的Rack信息，MRApp-licationMaster启动后加载此文件，防止频繁调用外部脚本解析。这大大加快了MRApplicationMaster的初始化速度。此外，云梯开发人员还解决了一些会使ResourceManager不工作的Bug，并贡献给ApacheHadoop社区。在搭建与维护云梯YARN集群期间，云梯开发人员遇到并解决了许多问题，分析和解决这些问题首先需要熟悉代码，但代码量巨大，我们如何能快速熟悉它们呢？这需要团队的配合，团队中每个人负责不同模块，阅读后轮流分享，这能加快代码熟悉速度。另外，Hadoop的优势在于可以利用社区的力量，当遇到一个问题时，首先可以到社区寻找答案，因为很多问题在社区已得到了解决，充分利用社区，可以大大提高工作效率。云梯YARN集群的优势与未来之路当前云梯YARN集群已经试运行，并有MRv2、Hive、Spark、RHive和RHadoop等应用。云梯YARN集群的优势在于：支持更丰富的计算模型；共享云梯最大的存储集群，访问便捷、快速；AppHistory信息存储在HDFS上，各种应用的作业历史都能方便查看；相对于MRv1集群，云梯YARN能支持更大规模的集群； 相对于MRv1集群，云梯YARN集群支持内存和CPU调度，资源利用将更加合理。未来，云梯将会把大多业务迁移到云梯YARN集群。针对YARN版本，云梯将增加资源隔离与调度，增加对Storm、Tez等计算模型的支持，并优化YARN的性能。
近日，backlinko发布了一份根据1百万搜索结果统计出来的Google排名数据，说明了什么样的页面倾向于有好的Google排名。两个说明：相关性不说明因果性。统计数据只说明这样的页面通常有好的排名(这是相关性)，不说明页面有这些特征就是好排名的原因(这是因果关系)。对百度排名有卵用呢?简单但不准确地说，今晚的Google就是明早的百度。什么样的页面在Google排名好呢?1、链接还是最重要因素首先，外链总数越多，排名还是越好。不管有多少人声称，外链没有用啦什么的，统计表明，与排名最相关的还是外链。尤其是，外部链接总域名数是与排名最正相关的因素。从10个不同域名得到各一个链接比从一个域名得到10个链接效果好得多。或者说，一个域名一张票，投票10次，也许效果比一张票多点，但不会变成10张票。2、域名权威度高，页面排名就好这个域名权威度搜索引擎不告诉我们，但很多外链工具有估算值，比如Ahrefs的domainrating，Moz的domainauthority之类。域名的权威值比页面本身的权威值与排名更有相关性。所以，给某个页面带来链接，受益的是整个域名，所有页面。3、深度主题内容有利于排名现在Google的排名不再局限于通过页面上出现的关键词来计算相关性，Google现在能理解查询词的意义。这点可以参考Google蜂鸟算法帖子。比如搜索“小时代的导演是哪位啊”，Google并不仅仅是搜索含有这些词的页面，Google其实知道你要找谁，所以直接给出了答案：这种人工智能和语义理解能力将使SEO产生全面、重大变化，从关键词研究到网站架构，从内容撰写到页面优化等等。以后有时间再仔细说。4、篇幅长的页面排名好以前一般建议页面内容最好在两三百字以上，现在看来可能还是不够。Google第一页结果的平均内容长度居然达到了1890个单词。中文比较简洁，应该没有这么长，但折半的话也够长的了。篇幅长可能与前面第3条也有关，要深度，就得篇幅长。有其他统计表明，篇幅长的页面也更容易得到社会化网络的分享，如FB,twitter等。本帖子怎么都得1千字以上吧，哼哼。5、https有一定帮助使用https的页面排名有些优势，但不是很大。Google前年就公布过给予https页面排名提升。百度去年5月也跟进，公布给予https页面收录和排名优先对待。(所以，前面两点说明的第2条不是瞎说的。再想想Google的熊猫、企鹅更新，百度的绿萝、石榴算法。)如果是新网站，当然直接做成https的。老网站怎么办?建议从http版本做301到https版本，但建https版本并不是加个证书那么简单，可能面临一些技术问题，目前好处没那么明显，先慎重点吧，不必仅仅为SEO原因改成https版。6、Schema标注没有作用用schema做页面结构化数据标注是Google、百度都支持并提倡的。Google排名与是否用schema标注没有相关性。不过Schema标注经常对页面展现有帮助，例如电子商务网站页面列表可能列出价格、是否有货、用户评价等信息，从而对点击率可能有帮助。所以，能做就做。Google的JohnMueller说过，以后Schema标注可能成为排名因素。7、短URL有利于排名首先，短URL看着舒服。其次，短URL一般意味着离首页更近。最早的SEO每天一贴的帖子URL是使用WordPress的缺省设置，URL里是带着日期的，这个目录形式：年/月/日/帖子名，看着很不顺眼，所以后来把URL结构改成了：分类名/帖子名，看着舒服多了。8、使用图片有利于排名使用至少一个图片有利于排名。再多放图片就没有明显区别了。这个我之前说过，文章里有图片比没图片要赏心悦目得多，有利于用户体验。但看看我的博客帖子，不是特别必要，真懒得放图片。这也正是百度在他们自己的质量指南中提到的根本原因：内容制作成本往往是内容质量的重要指标，这是个门槛，看起来简单，坚持跨过去的没几个。放上视频就更难了。9、Title中完整匹配出现关键词对排名有一点作用这是经典SEO技术了，有一点作用，但相关性并不是很强。目前由于语义分析的进步，对完整匹配出现关键词的要求已经大大降低。同样，搜索引擎正在尽量理解意义，而不是关键词匹配。10、速度快的网站明显比速度慢的排名好Google从2010年就把网页打开速度作为排名因素了。目前看来作用还不小。排名明显提升是否是速度快的直接结果，并不能肯定。前面说过，相关性不是因果关系。也许速度快带来了好的用户体验，进而提高排名。也许因为有钱的公司既能提高打开速度，又能做高水平SEO。无论如何，在可能的情况下，让页面打开快点，反正没坏处，尤其是移动搜索超越桌面搜索的现在。11、完全匹配锚文字链接与排名强正相关Google企鹅更新后，一般认为，链接锚文字是完全匹配的关键词，是比较危险的，可能带来惩罚。而统计结果表明，完全匹配关键词的锚文字与好排名有很强的正相关。这可让SEO们为难了，这之中的度是很难把握的。还是保守点好。12、低跳出率与排名有强相关性SEO们一直怀疑一些用户体验指标，比如跳出率、停留时间、点击率，是Google排名因素，但Google一直明确否认。统计表明，低跳出率的网站明显排名比较好。这与Google的否认并不矛盾，这两个现象可能都是其他因素造成的，比如内容质量。以上就是对SEO统计数据分析Google排名高的网页特点全部内容的介绍，更多内容请继续关注站三界导航！
微软大数据解决方案使企业可以从自己的结构化和非结构化数据中施展业务洞察力。企业中的任何人通过Office和SharePoint等熟悉的工具从他们所有的数据中施展可执行的洞察力；还能通过连接到公用的全球数据和服务，发现新的价值。此外，微软大数据解决方案还通过简单的部署以及与ActiveDirectory和SystemCenter等组件的集成，为Hadoop提供了Windows的易用性和可管理性。凭借WindowsAzure上基于Hadoop的服务，微软为其大数据解决方案在云端提供了灵活性。微软端到端的大数据解决方案：令人瞩目的BI工具套件，可帮助用户通过分析获得洞察力。更深入的洞察力，将企业的数据和来自外部源的数据及服务相结合。强大的扩充层，用于发现、转换、共享和监管数据。灵活的数据管理层，可支持所有数据类型，包括结构化、半结构化和非结构化的静态或动态数据。主要优势身临其境的洞察力，无论你身在何处，都可以通过熟悉的Office和商业智能(BI)工具来从任何数据中获取。使用熟悉的工具来分析Hadoop数据：Hadoop数据通过大家非常熟悉的由Excel的Hive插件所生成的MicrosoftExcel界面来呈现，使分析师和业务用户可以进行交互，并从中获得有价值的洞察力。从任何数据中获取身临其境的洞察力:使用熟悉的BI工具，如SQLServerAnalysisServices(SSAS)、PowerPivot、以及基于HiveOpenDatabaseConnectivity(ODBC)驱动的PowerView，在Hadoop中分析非结构化数据。还可以使用SQLServer2012中的PowerPivot和PowerView功能在关系型数据中实现自助式BI。通过简化编程来推升洞察力：通过集成.NET和新的JavaScript库，微软简化了Hadoop中的编程。开发者可以在JavaScript中使用新的JavaScript库来轻松编写MapReduce程序，然后通过一个简单的浏览器来部署他们的JavaScript代码。连接世界的数据，通过将内部与公开的数据及服务——包括社交媒体网站相结合，来揭露隐藏在背后的模式。通过将公开提供的数据和服务——包括社交媒体网站与你的数据相结合，释出突破性的发现。使用应用程序和WindowsAzureMarketplace中的挖掘算法来揭开隐藏的模式。结合世界的数据：将数据、智能挖掘算法和防火墙外部的人以及社交媒体数据一起连接起来整合到业务应用程序中。WindowsAzureMarketplace可以提供数百个受信任的第三方供应商的数据集。精炼外部数据：通过企业信息化管理工具，将丰富数据中的原始数据转换成可靠一致的数据，并且使用Mahout库来做先进的分析，以对你的数据进行精炼。通过Hadoop数据流，使用C++，C#，Python，Ruby和Pearl来开发定制的挖掘算法。任何数据，任何规模，任何地方，通过一个由简化的Windows和SQLServer以及灵活且可伸缩的云所构建而成的支持任何数据的现代化数据管理平台。通过一个现代化的数据平台来管理所有类型的数据。享受简单易用的WindowsforHadoop，通过Hadoop来扩展你的数据仓库，并充分利用具有BigData功能的弹性可扩展的云。HDInsight——企业就绪的Hadoop：通过微软的HDInsight，来获取最可靠的、创新的和值得信赖的发行版本，一种构建于HDPforWindowsServer和WindowsAzure之上的可供企业使用的Hadoop服务。与ActiveDirectory集成，使IT人员可以使用基于企业的安全策略来保护他们的Hadoop集群。与SystemCenter集成，使IT人员能够轻松地管理他们的Hadoop集群，并且有效地满足SLAs。将Windows的简易性和可管理性带给Hadoop：微软提供的智能封装，可使你的Hadoop集群实现简单和直接的安装。通过在WindowsAzure上部署Hadoop集群，可加快云中的系统环境准备，整个过程只需短短的10分钟!使用HDInsight来无缝地扩展你的数据仓库：HadoopconnectorsforSQLServer和ParallelDataWarehouse应用可以令Hadoop与MicrosoftEnterpriseDataWarehouses和BI解决方案易于集成在一起。此外，你还可以使用HCatalog将Hadoop与你的关系型数据仓库整合到一起。无缝伸缩和具弹性的云：对于在云中或者企业内部部署Hadoop—HDInsight，微软提供了两种选项。在微软的云平台中，WindowsAzureHDInsight可以提供具弹性的千兆级分析。它还提供向运行于企业内部的微软HDInsight服务器进行无缝迁移。开放的大数据平台：由于是构建于HDP之上，HDInsight可以100%地兼容ApacheHadoop。微软已经向Apache提交了提案，当中包含用于Hadoop新的JavaScript库(由微软开发)，以及HiveODBCDriver。客户面临的挑战今天，企业正想方设法从前所未有的巨量数据中获取业务洞察力，这些数据捕获自企业内部和外部资源，其中包括社交媒体网站。他们希望能轻易地实时挖掘、处理和分析这些大规模的非结构化数据(如文件、图像、视频、博客、点击流和地理空间数据)，而且无需担心所需的系统环境。企业正在寻找一个开放且灵活的平台,使他们能够将其解决方案部署在本地或者在云里。为什么选择微软?在BigData流行之前，微软早已进行着与其相关的应用。例如,微软Bing分析超过100PB的数据,以交付高质量的搜索结果。通过大家熟悉的工具,如微软Office和SharePoint，企业可以利用微软BigData从任何数据中释放出可行的洞察力。HDInsight是微软新的基于Hadoop的发行版本，以HortonworksDataPlatform(HDP)为基础。它将简化的Windows和一个与ApacheHadoop完全兼容的发行版本相结合，可从所有数据中揭示洞察力。它还使客户能够通过连接世界的数据和服务来发现新的价值。微软拥有一套全面的BigData策略，可以提供：现代化的数据管理层，支持所有的数据类型结构化、半结构化和非结构化的静态或动态数据。富集层，通过探索及结合世界的数据并加以先进的分析与精炼来提升你的数据的价值。洞悉层，通过大家熟悉的工具，如微软Office，来为所有用户提供洞察力。
着陆页为访问者提供了一种“目标超明确”的访问体验:通过呈现一个特定页面,为他们指出一条明确的路径继续加深与你公司的关系。虽然百度会收录网站中的各类文章，同时也会在搜索结果中以适当的排名进行展示，可是有一点要明确，一个网站总会有一个着陆页会优先的展现，也就是百度会自然而然的推介这个网站的着陆页，从而由此让用户能够在该网站上冲浪。通常而言，网站的着陆页实际上就是网站的首页，有的也是一些网站的栏目页，但是无论是怎样的着落页，都有一个重要的特征，那就是着陆页的内容要丰富，而且大多是以标题的形式呈现，从而给用户起到一定的导航作用。当然着陆页也应该具有相当的的美感，也就是要具有良好的形象，只有如此才能够吸引用户进一步浏览的欲望，从而为网站培养忠诚用户打下重要基础。下面就来重点研究一下企业网站着陆页的设计，从而给站长朋友们提供一定的设计思路。第一，着陆页的顶端。着陆页必须要有网站的logo，如果是企业网站，那就需要布置企业的logo，客人能够据此一看便知你的网站是什么，进而能够清楚的传达给用户你的网站是做什么的，能够为用户提供什么样的服务。另外在logo的一侧还需要放置网站的定位语，这样就能够和行业进行一定的区分，让用户明白你的网站和同行之间的区别，接着右边可以放置网站的联系方式，通常是企业的400电话，这能够展现出企业实力，让用户觉得这是大企业。第二，着陆页要配置相应的Banner图，对于企业网站而言，Banner上可以配置企业曾经的一些成功案例，或者企业的产品，抑或是企业的核心优势。这些图一定要设计成高大上，同时要注意图和网站内容的相关性，有的企业网站的着陆页就在这里出现了只要好看，不突出和企业的相关性，就显得不够专业大气，进而影响到企业的形象。第三，接下来就是要重点介绍产品大类。对于一个企业而言会存在着很多产品，这些产品又分属不同的大类，而在着陆页上就要重点展现这些大类，然后再由这些大类列出相应的产品名称，同时每个产品下面有一小段简要介绍，用户可以通过这些介绍点击相应的文字，进而打开这些产品的详细页，也即是说，要发挥出企业网站着陆页的导航功能。第四，要发布一定的荣誉以及相应的证书。对于企业网站而言，这是展现企业的最佳平台，着陆页更是展现中的重点环节，用户大多是通过着陆页浏览网站的内部内容，如果你在着陆页上展现的内容充分证明你的网站的优势，并且得到了权威部门的认证，这样就具有更好的说服力。也就是说，在着陆页上要尽可能的列出企业曾经所获得荣誉，而且这些荣誉都是可以查询的，千万不是虽然有着荣誉，但是却不能够说服用户，这就给用户带来造假的疑问，反而不利于提升网站的权威度。第五，要布置相应的联系方式，尤其是互动的联系方式，增强和用户的互动，解决用户提出的问题，从而引导用户点击相应的内容，这样的在线服务能够有效的提升服务水平，而且通过和用户的良好互动，也有助于增强网站的黏贴力，进而为网站培养更多的忠诚用户。总而言之，网站着陆页对于吸引用户，提高转换率具有重要的作用，我们在努力提升着陆页的权重的同时，还需要注意增强着陆页的设计体验度，增强用户的体验度，进而为网站的成功奠定重要基础。
TA(TencentAnalytics，腾讯分析)是一款面向第三方站长的免费网站分析系统，在数据稳定性、及时性方面广受站长好评，其秒级的实时数据更新频率也获得业界的认可。本文将从实时数据处理、数据存储等多个方面带你深入探寻TA的系统架构及实现原理。网站分析(WebAnalytics)主要指的是基于网站的用户浏览行为，对网站的点击流数据和运营数据进行分析，以监控网站的运营状况，为网站的优化提供决策依据。网站分析系统已成为站长日常运营必不可少的工具，业界比较流行的网站分析系统主要有GoogleAnalytics、CNZZ和百度统计等产品。TA作为网站分析产品的后起之秀在社区分析、用户画像、网站工具等多方面形成了自己的特色，其秒级的实时数据更新频率更是业界翘楚。在数据稳定性、准确性和及时性方面，TA在站长圈也是享有良好的口碑。随着接入业务量的不断发展，TA日均需要处理和计算的数据量达到TB级。如此庞大的数据量想要达到秒级实时且保证系统的高可用并非件易事。TA的实时计算框架借鉴了一些业界流行的流式计算系统的思路。虽然在构建系统中遇到了一些问题，但由于海量数据的实时处理、实时存储具备一定的典型性与通用性，所以将TA的解决方案分享出来，希望能给大家一些启示。基本原理及系统架构TA的基本原理是通过嵌入站长网站的JavaScript脚本收集用户访问行为数据，并发送TA采集集群，采集集群收到数据后将其过滤、编码、格式化后继续向后分发。数据处理集群负责按照业务逻辑计算数据，并将计算结果“写入”到数据存储集群，最后将结果数据展现给广大站长使用。TA的基本原理如图所示。TA后台是一套完整的数据流处理系统：由JavaScript采集的用户行为数据像川流不息的河水一样流入TA后台，经过清洗、计算后源源不断地流出到TA存储集群，供用户浏览和查询。TA的具体架构及核心部件如图所示。TA的后台分为离线和实时两部分：实时部分负责系统的主要功能计算，数据更新频率为秒级；离线部分负责系统复杂的关联分析及跨天计算，数据更新频率为天级。HttpAccess：主要负责HTTP协议的解析，数据的清洗及格式化。ESC：EventStreamingCoder，主要负责将系统不可枚举的数据类型编码成为整型，并将对应关系持久化。ESP：EventStreamingProcessor，主要负责将数据按照站点、UID重新组织并计算PV、UV、停留时长和蹦失率等网站分析指标。ESA：EventStreamingAggregator，主要负责汇总ESP计算后的数据按照站点，并写入到Redis。Center：系统的中心节点，负责系统配置、数据路由管理，并承担容灾切换功能。Logserver：负责将Access收集到的数据以字符串形式写入文件，并上传到TDCP上。TDCP：腾讯分布式计算平台，负责离线数据的计算，并由脚本将结果数据写入MySQL中。实时解决方案前TA日均需要处理几十万网站的上TB级数据，处理过后的URL个数仍有上亿条，系统存储的key个数超过十亿。如何高效、低延迟地处理如此大量的业务数据是TA实时系统面临的主要挑战。TA解决方案的主要思路可以概括为数据全二进制化、计算全内存化、存储NoSQL化。下面就实时计算和实时存储这两大子系统进行深入的讨论。实时计算对于计算子系统，我们参考了Hadoop、S4和Storm等开源项目，力图设计为一个较为通用，扩展性较强的全内存实时Event处理系统(或者套用流行的术语称为流式实时Event处理系统)。对于这样的一个系统，我们设计支持的典型输入输出流程大致如图所示。实时计算系统的设计要点在数据组织、协议和增量计算模型上。数据组织。万物皆int，考虑到内存以及计算过程的性能需求，我们将所有非int的数据类型转化为int。可以枚举的数据类型，将其配置化映射为唯一int；不可枚举的数据类型，则利用MD5算法近似得到唯一的int。例如，页面URL属于不可枚举的类型，则预处理通过MD5算法近似得到唯一的int；UserAgent里的浏览器类型字符串则属于可枚举的数据，则预先配置化映射为int。这个方法节省了较多内存，提高了整个系统的计算性能。协议。协议层面上，我们首先设计实现了一种可扩展的Event结构，这种Event结构支持半自动化的序列化/反序列化机制(参考自msgpack的设计)和紧凑的二进制编码(基于Zigzag编码，参考Protobuf的实现)。这种Event结构在流式高性能I/O(网络传输和持久化)方面表现得相当良好。实时计算子系统被设计为可以扩展支持任意的Event实现。增量计算模型。增量计算模型，指的是基本计算过程，被定义为以下三部分(如图所示)Processor：负责具体业务逻辑的计算处理。DataHolder：负责保存增量结果数据，以及计算依赖的中间状态数据。Emitter：负责定期输出清空增量计算结果。具体到流程方面，分为以下三步(如图所示)。接收Event，计算处理—Processor。保存计算结果以及计算依赖中间数据—DataHolder。定时触发输出时间片内计算结果，清空计算结果—Emitter。增量计算模型弱化了分布式系统中单台机器的事务状态，相应地简化了分布式计算系统的实现，同时也提高了整个系统的性能。实时存储在TA系统中，实时存储的数据都是需要通过Web展示层读取的统计数据。这类数据存在两个典型特点。频繁更新写。更新频度视系统实时性而定，每条统计结果更新频度最快可以达到1秒。少量读取。“少量”是相对上述更新而言的。同时根据业务逻辑，可将统计数据划分为两类。固定不变数据：主要是URL、搜索关键词等数据。这一部分数据理论上是在不停地增加，不会修改旧有数据。动态数据：主要是频繁更新的结果统计数据。这一部分数据则需要不停地更新。例如，www.qq.com域名下的PV和UV统计结果。考虑到上述的TA实时统计数据的特点，我们选择NoSQL实现我们的存储系统；同时，针对两类不同的数据类型，分别选用LevelDB和Redis来存储。RedisTA实时存储的主要构件。考虑到TA系统本身就是一个比较完善的分布式集群系统，因此我们需要的存储构件是“notclustering,butsharding”。也就是说像HBase和MongoDB这样的“重武器”并不适合TA，而NoSQL数据库中的“瑞士军刀”Redis凭借其出色的性能走入我们的视野。同时TA的结果数据类型也比较丰富，有像站点PV、UV、VV和IP等Hash类型的数据，也有像用户访问轨迹这样set类型的“动态数据”，而Redis丰富的数据结构很好地完成了这项任务。选择Redis的另一个原因是它足够简单且易于扩展。在实际应用的过程中，我们发现的问题都可以通过扩展Redis命令来解决。例如，TA中有这样的一种应用场景：为了消除ESA模块的状态，存储在Redis中的数据往往并不是最终的结果数据，而是还需要进一步运算的中间数据。像bouncerate这个指标(bouncerate=bouncesession数/totalsession数)，需要前台查询两次再做一次运算后最终展示给用户。在高并发的情况下，无疑会影响系统的响应速度。本着“移动计算，而不是移动数据”的原则，我们对Redis的sort、hmget命令进行了扩展使其支持四则运算，成功地将原来的两次查询优化为一次。扩展四则运算的另外一个目的是可以“通过计算换取存储”，例如需要将两种类型加总成总和的类型数据，可以只存储两份，加总数据“通过计算换取”。除了数据读取，数据的写入也可以进行类似合并数据的优化。例如，TA在写入URL的PV、UV、VV、IP、停留时长和bouncerate这6个指标时，需要调用6次Redis命令。而实际上这6个指标是存储在同一个Hash内的，通过扩展hmincrby命令，支持将Hash的所有field一次更改，便能将调用次数优化至一次。上线之后也取得了良好的效果，峰值时的CPU利用率几乎下降了一半，同时也大幅提升了上层模块ESA的吞吐量。LevelDB它是Redis的有效补充。考虑到Redis为内存数据库，而使用内存的成本要高于硬盘，因此选择引入了基于磁盘存储的LevelDB作为补充。由于LevelDB的写性能足够好，而读性能也远远超过目前“在线少量读取”的需求，所以我们选择LevelDB存储“固定不变数据”。在数据存储的架构设计上，由于实时数据服务与在线系统，可靠性要求较高，因此我们主要采取双写复制+Sharding的设计方法。双写复制。所有的数据存储都会至少同步写两份，以提高在线系统服务的可用性。数据分片(Sharding)。基于域名：所有的数据以域名为单位组织分片；任何域名可以调整到任意分片中；单个域名数据原则上存储在一个分片中。动态调整(如图所示)：只调整分片策略，不移动数据；基于数据量计算分片负载。此外，针对分片集群数据的查询，我们主要做了三项工作(如图所示)。RedisProtocolStack是一个较为完整的Redis协议栈，是上层应用的基础。直接用Redis协议作为对外提供查询的通用协议，这样外部用户可直接通过目前各种RedisClient实现来查询访问数据。QueryRuleEngine是一个灵活的查询引擎。能够根据规则智能地在多个Redis、LevelDB数据源中查询，执行类join的操作；也简单扩展支持其他的异构数据源，如MySQL、HBase等。QueryComputeEngine是一个实时查询计算引擎，能根据基础查询结果实时计算。引入此部分的主要目的在于减少Redis数据空间占用。未来展望目前TA虽然在后台上已经做到数据秒级更新，但展示方式仍为传统的静态方式。后续TA会在数据的动态刷新上进行更多尝试，让站长可以第一时间了解网站营销效果，时刻感受网站心跳。
BigTable是Google设计的分布式数据存储系统，用来处理海量的数据的一种非关系型的数据库。BigTable是非关系型数据库，是一个稀疏的、分布式的、持久化存储的多维度排序Map。Bigtable的设计目的是快速且可靠地处理PB级别的数据，并且能够部署到上千台机器上。Bigtable已经实现了以下的几个目标：适用性广泛、可扩展、高性能和高可用性。Bigtable已经在超过60个Google的产品和项目上得到了应用，包括GoogleAnalytics、GoogleFinance、Orkut、PersonalizedSearch、Writely和GoogleEarth。这些产品对Bigtable提出了迥异的需求，有的需要高吞吐量的批处理，有的则需要及时响应数据给最终用户。它们使用的Bigtable集群的配置也有很大的差异，有的集群只有几台服务器，而有的则需要上千台服务器、存储几百TB的数据。在很多方面，Bigtable和数据库很类似：它使用了很多数据库的实现策略。并行数据库和内存数据库已经具备可扩展性和高性能，但是Bigtable提供了一个和这些系统完全不同的接口。Bigtable不支持完整的关系数据模型；与之相反，Bigtable为客户提供了简单的数据模型，利用这个模型，客户可以动态控制数据的分布和格式（alex注：也就是对BigTable而言，数据是没有格式的，用数据库领域的术语说，就是数据没有Schema，用户自己去定义Schema），用户也可以自己推测(alex注：reasonabout)底层存储数据的位置相关性(alex注：位置相关性可以这样理解，比如树状结构，具有相同前缀的数据的存放位置接近。在读取的时候，可以把这些数据一次读取出来)。数据的下标是行和列的名字，名字可以是任意的字符串。Bigtable将存储的数据都视为字符串，但是Bigtable本身不去解析这些字符串，客户程序通常会在把各种结构化或者半结构化的数据串行化到这些字符串里。通过仔细选择数据的模式，客户可以控制数据的位置相关性。最后，可以通过BigTable的模式参数来控制数据是存放在内存中还是硬盘上。特点:1、适合大规模海量数据，PB级数据；2、分布式、并发数据处理，效率极高；3、易于扩展，支持动态伸缩；4、适用于廉价设备；5、适合于读操作，不适合写操作。6、不适用于传统关系型数据库；应用:BigTable为谷歌旗下的搜索、地图、财经、打印、以及社交网站Orkut、视频共享网站YouTube和博客网站Blogger等业务提供技术支持。CloudBigtable此外，Google也为用户提供Bigtable云数据库——他们的自有数据库，在其搜索、Gmail、地图或YouTube等服务中使用已超过十年时间。Bigtable不像Google的其它产品一样开源，因此这一新的云服务只能通过开源接口ApacheHBase1.0.1API访问。谷歌承诺，CloudBigtable的延迟时间将限制在几毫秒(个位数)，每美元性能是HBase、Cassandra等类似数据库的两倍。由于CloudBigtable支持HBase的应用程序接口，所以它能够与分布式系统基础架构Hadoop生态系统中的现有应用相整合，但也支持谷歌的云数据分析工具CloudDataflow。Bigtable云的特性如下：1.可扩展至成百上千个PB2.高可用性3.可复制4.数据以加密形式传输和存储5.全托管6.与Hadoop生态系统集成适用于金融、物联网、时序和市场等领域的数据Google称Bigtable凭借“个位数毫秒级延迟以及两倍于其它非托管NoSQL产品的性价比”提供“无与伦比的性能”。数据如下图所示，该图由Google发布，目前还没有被某个独立衡量基准验证核实过。
中国互联网举报中心