Google，无疑是互联网时代最闪亮的明星。截止到今天为止，Google美国主站在Alexa排名已经连续3年第一，AlexaTop100中，各国的Google分站竟然霸占了超过20多个名额，不得不令人感叹Google的强大。不论何时，不论何地，也不论你搜索多么冷门的词汇，只要你的电脑连接互联网，只要你轻轻点击“google搜索”，那么这一切相关内容google都会在1秒钟之内全部搞定，这甚至比你查询“我的文档”都要快捷。这也就是为什么Google创业12年，市值超过2000亿美元的原因。有人可能认为Google拥有几台“蓝色基因”那样的超级计算机来处理各种数据和搜索，事实是怎样的呢？下面我们就将详细解析神奇Google的神奇架构。硬件：截止到2010年，Google大约有100万台服务器，有超过500个计算机集群，处理不同地域的不同任务。可惜服务器的详细配置和最新集群的具体情况，在多个文献库里面都查询不到，我个人理解，这可能属于商业机密。大概也是因为机密的缘故，强大的Google计算机集群并没有递交Top500计算机的申请，多年来我们在Top500中都看不到Google的影子。(进入Top500需要提交并且公开自己计算机系统的详细配置)不过根据文献资料，可以肯定的是，这45万台服务器都不是什么昂贵的服务器，而是非常普通的PC级别服务器，其中的服务器硬盘在两年前还普遍是IDE接口、并且采用PC级主板而非昂贵的服务器专用主板。Google的集群也全部是自己搭建的，没有采用Myricom的Myrinet或者Giganet的cLAN等先进昂贵的集群连接技术，Google各个数据中心和服务器间不同的耦合程度都随需而定自行连接。那么google的存储呢？Google存储着海量的资讯，近千亿个网页、数百亿张图片。早在2004年，Google的存储容量就已经达到了5PB。可能很多读者一开始都认为Google采用了诸如EMCSymmetrix系列磁盘阵列来保存大量的资讯，但是Google的实际做法又一次让我们大跌眼镜——Google没有使用任何磁盘阵列，哪怕是低端的磁盘阵列也没用。Google的方法是将集群中的每一台PC级服务器，配备两个普通IDE硬盘来存储。不过Google倒也不是都是什么设备都落后，至少这些硬盘的转速都很高，而且每台服务器的内存也还算比较大。最大的电脑DIY消费者是谁？恐怕Google又登上了这个DIY宝座。Google的绝大部分服务器甚至也不是采购什么大品牌，而是购买各种廉价零件而后自行装配的。有趣的是，Google非常不满意现存的各种PC电源的功耗，甚至还自行设计了Google专用服务器电源。很快，我们就有了疑问。这样的一个以PC级别服务器搭建起来的系统，怎么能承受巨大的工作负载呢？怎么能保证高可用性呢？的确，这些低端的服务器经常出现故障——硬盘坏道、系统宕机这类的事故其实每天都在45万台服务器中发生。而Google的方法是设立镜像站。以Google主站为例，2003年就在美国硅谷和弗吉尼亚设立了多个镜像站。这些镜像站其实不是传统的镜像站。真正的镜像站是双机热备，当一台服务器宕机时，另一台服务器接管相关任务。而Google的镜像站其实真正的职责是DNS负载均衡，所以有的Google镜像站本身还有自己的镜像站。这里举例说明Google镜像站的作用：一个访问，DNS正常解析到A处，但当A处负载过大时，DNS服务就将域名解析到B处，这样既达到了冗余，也缩减了投资。由于不是双机热备，某一时间，镜像站的内容可能略有不同，不过对于精确度要求不那么高的普通检索而言，并不是问题。平台：GFS/MapReduce/BigTable/LinuxGFS/MapReduce/BigTable/这三个平台，是Google最引以为傲的平台，全部架构在Linux之上。首先我们来看一看GFS（GoogleFileSystem）Google文件系统。我们知道，一般的数据中心检索时候需要用到数据库系统。但是Google的情况很特殊——Google拥有全球上百亿个Web文档，如果用常规数据库系统检索，那么检索速度就可想而知了。因此，当Crawlers采集到许多新的Web后，Google将很多的Web都汇集到一个文件里进行存储管理，而且Google将Web文件压缩成Chunk块，进一步减少占用空间(64MB一个chunk)。最后，Google只检索压缩后的部分。而GFS(GoogleFileSystem）正是在这样的检索技术上构建的文件系统，GFS包括了GFSMaster服务器和Chunk服务器。如下图所示，系统的流程从GFS客户端开始：GFS客户端以chunk偏移量制作目录索引并且发送请求——GFSMaster收到请求通过chunk映射表映射反馈客户端——客户端有了chunkhandle和chunk位置，并将文件名和chunk的目录索引缓存，向chunk服务器发送请求——chunk服务器回复请求传输chunk数据。如果读者您读着有点迷糊，这很正常，因为只有少数搜索引擎企业才采用这样的技术。简单来说是这样：Google运用GFS大大简化了检索的难度。除了GFS，MapReduce对Google也是功不可没。Google拥有不少于45万台服务器，看起来每台服务器的职能都非常明确，但是其中却有重要的协同问题有待解决：如何并发计算，如何分布数据，如何处理失败，如何负载均衡？我们可以预见，无数的代码将被用在协同问题上，而且很可能效率低下。这时候，MapReduce就派上用场了。MapReduce是Google开发的C++编程工具，用于大规模数据集的并行运算。MapReduce主要功能是提供了一个简单强大的接口，可以将计算自动的并发和分布执行。这样一来，就可以通过普通PC的集群，实现高性能。MapReduce主要从两方面提升了系统：首先是失效的计算机问题。如果某一台计算机失效了，或者是I/O出现了问题——这在Google以廉价服务器组建的集群中极为常见，MapReduce的解决方法是用多个计算机同时计算一个任务，一旦一台计算机有了结果，其它计算机就停止该任务，而进入下一任务。另外，在MapReduce之间传输的数据都是经过压缩的，节省了很多带宽资源。至于BigTable，这是一个用来处理大数据量的系统，适合处理半结构化的数据。Google心经：Google总是尝试用最少的钱，做最多的事情。不要小看那些便宜、不牢靠的PC级服务器，一台服务器也许确实不牢靠，但是45万台的有机集成却成为了全球最完善、最稳定的系统之一。在采购服务器方面，Google也从未一次性大量购买，都是有了需求再选购。另一个能够体现Google精打细算的方面是Google尽量压缩所有能够压缩的文件。包括软件和硬件，Google的设计构想都很前卫，Google尝试过许多还在实验室里的萌芽技术，如上文所说，很多都取得了巨大成功。Google早先的目标是0.5秒钟做出搜索结果，但实际上目前的平均时间已经缩减到了0.25秒。而且，Google从来没有停止研究的脚步，现在还在测试OpenSoalris，观察OpenSoalris是否能够替代Linux。Google的行为非常踏实。不参加Top500评选，文献里也鲜有相关资料。可见Google不吹嘘、也没有过度宣传，只是勤勤恳恳的更新程序、优化集群。今天，google收录了绝大多数人类语言的网页，并且在多数国家都建立了Google分站，收录的网页也是与日俱增，全球影响力更是不言而喻。向Google的架构学习，向Google的成就致敬。Google是伸缩性的王者。Google一直的目标就是构建高性能高伸缩性的基础组织来支持它们的产品。平台Linux大量语言：Python，Java，C++状态在2006年大约有450,000台廉价服务器，这个数量到2010年增加到了1,000,000台。在2005年Google索引了80亿Web页面，现在没有人知道具体数目，近千亿并不断增长中。目前在Google有超过500个GFS集群。一个集群可以有1000或者甚至5000台机器。成千上万的机器从运行着5000000000000000字节存储的GFS集群获取数据，集群总的读写吞吐量可以达到每秒40兆字节目前在Google有6000个MapReduce程序，而且每个月都写成百个新程序BigTable伸缩存储几十亿的URL，几百千千兆的卫星图片和几亿用户的参数选择堆栈Google形象化它们的基础组织为三层架构：1，产品：搜索，广告，email，地图，视频，聊天，博客2，分布式系统基础组织：GFS，MapReduce和BigTable3，计算平台：一群不同的数据中心里的机器4，确保公司里的人们部署起来开销很小5，花费更多的钱在避免丢失日志数据的硬件上，其他类型的数据则花费较少可信赖的存储机制GFS(GoogleFileSystem)1，可信赖的伸缩性存储是任何程序的核心需求。GFS就是Google的核心存储平台2，GoogleFileSystem–大型分布式结构化日志文件系统，Google在里面扔了大量的数据3，为什么构建GFS而不是利用已有的东西？因为可以自己控制一切并且这个平台与别的不一样，Google需要：-跨数据中心的高可靠性-成千上万的网络节点的伸缩性-大读写带宽的需求-支持大块的数据，可能为上千兆字节-高效的跨节点操作分发来减少瓶颈4，系统有Master和Chunk服务器-Master服务器在不同的数据文件里保持元数据。数据以64MB为单位存储在文件系统中。客户端与Master服务器交流来在文件上做元数据操作并且找到包含用户需要数据的那些Chunk服务器-Chunk服务器在硬盘上存储实际数据。每个Chunk服务器跨越3个不同的Chunk服务器备份以创建冗余来避免服务器崩溃。一旦被Master服务器指明，客户端程序就会直接从Chunk服务器读取文件6，一个上线的新程序可以使用已有的GFS集群或者可以制作自己的GFS集群7，关键点在于有足够的基础组织来让人们对自己的程序有所选择，GFS可以调整来适应个别程序的需求使用MapReduce来处理数据1，现在你已经有了一个很好的存储系统，你该怎样处理如此多的数据呢？比如你有许多TB的数据存储在1000台机器上。数据库不能伸缩或者伸缩到这种级别花费极大，这就是MapReduce出现的原因2，MapReduce是一个处理和生成大量数据集的编程模型和相关实现。用户指定一个map方法来处理一个键/值对来生成一个中间的键/值对，还有一个reduce方法来合并所有关联到同样的中间键的中间值。许多真实世界的任务都可以使用这种模型来表现。以这种风格来写的程序会自动并行的在一个大量机器的集群里运行。运行时系统照顾输入数据划分、程序在机器集之间执行的调度、机器失败处理和必需的内部机器交流等细节。这允许程序员没有多少并行和分布式系统的经验就可以很容易使用一个大型分布式系统资源3，为什么使用MapReduce？-跨越大量机器分割任务的好方式-处理机器失败-可以与不同类型的程序工作，例如搜索和广告。几乎任何程序都有map和reduce类型的操作。你可以预先计算有用的数据、查询字数统计、对TB的数据排序等等4，MapReduce系统有三种不同类型的服务器-Master服务器分配用户任务到Map和Reduce服务器。它也跟踪任务的状态-Map服务器接收用户输入并在其基础上处理map操作。结果写入中间文件-Reduce服务器接收Map服务器产生的中间文件并在其基础上处理reduce操作5，例如，你想在所有Web页面里的字数。你将存储在GFS里的所有页面抛入MapReduce。这将在成千上万台机器上同时进行并且所有的调整、工作调度、失败处理和数据传输将自动完成-步骤类似于：GFS->Map->Shuffle->Reduction->StoreResultsbackintoGFS-在MapReduce里一个map操作将一些数据映射到另一个中，产生一个键值对，在我们的例子里就是字和字数-Shuffling操作聚集键类型-Reduction操作计算所有键值对的综合并产生最终的结果6，Google索引操作管道有大约20个不同的map和reduction。7，程序可以非常小，如20到50行代码8，一个问题是掉队者。掉队者是一个比其他程序慢的计算，它阻塞了其他程序。掉队者可能因为缓慢的IO或者临时的CPU不能使用而发生。解决方案是运行多个同样的计算并且当一个完成后杀死所有其他的9，数据在Map和Reduce服务器之间传输时被压缩了。这可以节省带宽和I/O。在BigTable里存储结构化数据1，BigTable是一个大伸缩性、错误容忍、自管理的系统，它包含千千兆的内存和1000000000000000的存储。它可以每秒钟处理百万的读写2，BigTable是一个构建于GFS之上的分布式哈希机制。它不是关系型数据库。它不支持join或者SQL类型查询3，它提供查询机制来通过键访问结构化数据。GFS存储存储不透明的数据而许多程序需求有结构化数据4，商业数据库不能达到这种级别的伸缩性并且不能在成千上万台机器上工作5，通过控制它们自己的低级存储系统Google得到更多的控制权来改进它们的系统。例如，如果它们想让跨数据中心的操作更简单这个特性，它们可以内建它6，系统运行时机器可以自由的增删而整个系统保持工作7，每个数据条目存储在一个格子里，它可以通过一个行key和列key或者时间戳来访问8，每一行存储在一个或多个tablet中。一个tablet是一个64KB块的数据序列并且格式为SSTable9，BigTable有三种类型的服务器：-Master服务器分配tablet服务器，它跟踪tablet在哪里并且如果需要则重新分配任务-Tablet服务器为tablet处理读写请求。当tablet超过大小限制(通常是100MB-200MB)时它们拆开tablet。当一个Tablet服务器失败时，则100个Tablet服务器各自挑选一个新的tablet然后系统恢复。-Lock服务器形成一个分布式锁服务。像打开一个tablet来写、Master调整和访问控制检查等都需要互斥10，一个locality组可以用来在物理上将相关的数据存储在一起来得到更好的locality选择11，tablet尽可能的缓存在RAM里硬件1，当你有很多机器时你怎样组织它们来使得使用和花费有效？2，使用非常廉价的硬件3，A1,000-foldcomputerpowerincreasecanbehadfora33timeslowercostifyouyouuseafailure-proneinfrastructureratherthananinfrastructurebuiltonhighlyreliablecomponents.Youmustbuildreliabilityontopofunreliabilityforthisstrategytowork.4，Linux，in-houserackdesign，PC主板，低端存储5，Priceperwattageonperformancebasisisn’tgettingbetter.Havehugepowerandcoolingissues6，使用一些collocation和Google自己的数据中心其他1，迅速更改而不是等待QA2，库是构建程序的卓越方式3，一些程序作为服务提供4，一个基础组织处理程序的版本，这样它们可以发布而不用害怕会破坏什么东西Google将来的方向1，支持地理位置分布的集群2，为所有数据创建一个单独的全局名字空间。当前的数据由集群分离3，更多和更好的自动化数据迁移和计算4，解决当使用网络划分来做广阔区域的备份时的一致性问题(例如保持服务即使一个集群离线维护或由于一些损耗问题)学到的东西1，基础组织是有竞争性的优势。特别是对Google而言。Google可以很快很廉价的推出新服务，并且伸缩性其他人很难达到。许多公司采取完全不同的方式。许多公司认为基础组织开销太大。Google认为自己是一个系统工程公司，这是一个新的看待软件构建的方式2，跨越多个数据中心仍然是一个未解决的问题。大部分网站都是一个或者最多两个数据中心。我们不得不承认怎样在一些数据中心之间完整的分布网站是很需要技巧的3，如果你自己没有时间从零开始重新构建所有这些基础组织你可以看看Hadoop。Hadoop是这里很多同样的主意的一个开源实现4，平台的一个优点是初级开发人员可以在平台的基础上快速并且放心的创建健全的程序。如果每个项目都需要发明同样的分布式基础组织的轮子，那么你将陷入困境因为知道怎样完成这项工作的人相对较少5，协同工作不一直是掷骰子。通过让系统中的所有部分一起工作则一个部分的改进将帮助所有的部分。改进文件系统则每个人从中受益而且是透明的。如果每个项目使用不同的文件系统则在整个堆栈中享受不到持续增加的改进6，构建自管理系统让你没必要让系统关机。这允许你更容易在服务器之间平衡资源、动态添加更大的容量、让机器离线和优雅的处理升级7，创建可进化的基础组织，并行的执行消耗时间的操作并采取较好的方案8，不要忽略学院。学院有许多没有转变为产品的好主意。MostofwhatGooglehasdonehaspriorart,justnotpriorlargescaledeployment.9，考虑压缩。当你有许多CPU而IO有限时压缩是一个好的选择。Google主要以GFS、MapReduce、BigTable这三大平台来支撑其庞大的业务系统，我称他们为Google三剑客，网上也有说是Google的三架马车。一、GFS（GoogleFileSystem）这是Google独特的一个面向大规模数据密集型应用的、可伸缩的分布式文件系统，由于这个文件系统是通过软件调度来实现的，所以Google可以把GFS部署在很多廉价的PC机上，来达到用昂贵服务器一样的效果。下面是一张GoogleGFS的架构图：从上图我们可看到Google的GFS主要由一个master和很多chunkserver组成，master主要是负责维护系统中的名字空间、访问控制信息、从文件到块的映射以及块的当前位置等元素据，并通过心跳信号与chunkserver通信，搜集并保存chunkserver的状态信息。chunkserver主要是用来存储数据块，google把每个数据块的大小设计成64M，至于为什么这么大后面会提到，每个chunk是由master分配的chunk-handle来标识的，为了提高系统的可靠性，每个chunk会被复制3个副本放到不同的chunkserver中。当然这样的单master设计也会带来单点故障问题和性能瓶颈问题，Google是通过减少client与master的交互来解决的，client均是直接与chunkserver通信，master仅仅提供查询数据块所在的chunkserver以及详细位置。下面是在GFS上查询的一般流程：1、client使用固定的块大小将应用程序指定的文件名和字节偏移转换成文件的一个块索引（chunkindex）。2、给master发送一个包含文件名和块索引的请求。3、master回应对应的chunkhandle和副本的位置（多个副本）。4、client以文件名和块索引为键缓存这些信息。（handle和副本的位置）。5、Client向其中一个副本发送一个请求，很可能是最近的一个副本。请求指定了chunkhandle（chunkserver以chunkhandle标识chunk）和块内的一个字节区间。6、除非缓存的信息不再有效（cacheforalimitedtime）或文件被重新打开，否则以后对同一个块的读操作不再需要client和master间的交互。不过我还是有疑问，google可以通过减少client与master通信来解决性能瓶颈问题，但单点问题呢，一台master挂掉岂不是完蛋了，总感觉不太放心，可能是我了解不够透彻，不知道哪位朋友能解释一下，谢谢：）二、MapReduce，Google的分布式并行计算系统如果上面的GFS解决了Google的海量数据的存储，那这个MapReduce则是解决了如何从这些海量数据中快速计算并获取指定数据的问题。我们知道，Google的每一次搜索都在零点零几秒，能在这么短时间里环游世界一周，这里MapReduce有很大的功劳。Map即映射，Reduce即规约，由master服务器把map和reduce任务分发到各自worker服务器中运行计算，最后把结果规约合并后返回给用户。这个过程可以由下图来说明。按照自己的理解，简单对上图加点说明：1、首先把用户请求的数据文件切割成多份，每一份（即每一个split）被拷贝在集群中不同机器上，然后由集群启动程序中的多份拷贝。2、master把map和reduce任务交给相对空闲的worker处理，并阻塞等待处理结果。3、处理map任务的worker接到任务后，把以key/value形式的输入数据传递给map函数进行处理，并将处理结果也以key/value的形式输出，并保存在内存中。4、上一步内存中的结果是要进行reduce的，于是这些mapworker就把这些数据的位置返回给master，这样master知道数据位置就可以继续分配reduce任务，起到了连接map和reduce函数的作用。5、reduceworker知道这些数据的位置后就去相应位置读取这些数据，并对这些数据按key进行排序。将排序后的数据序列放入reduce函数中进行合并和规约，最后每个reduce任务输出一个结果文件。6、任务结束，master解除阻塞，唤醒用户。以上是个人的一些理解，有不对的地方请指出。三、BigTable，分布式的结构化数据存储系统？BigTable是基于GFS和MapReduce之上的，那么google既然已经有了GFS，为何还要有BigTable呢（也是我原先的一个疑问）？后来想想这和已经有操作系统文件系统为何还要有SQLSERVER数据库一样的道理，GFS是更底层的文件系统，而BigTable建立在其上面，不仅可以存储结构化的数据，而且可以更好的管理和做出负载均衡决策。以下是BigTable的架构图：它完全是一个基于key/value的数据库，和一般的关系型数据库不同，google之所以采用BigTable，因为它在满足需求的同时简化了系统，比如去掉了事务、死锁检测等模块，让系统更高效。更重要的一点是在BigTable中数据是没有格式的，它仅仅是一个个key/value的pairs，用户可以自己去定义数据的格式，这也大大提高了BigTable的灵活性和扩展性。四、总结这篇随笔主要是一些总结性的内容，Google架构远远不止这些。
AWSAWS(AmazonWebService)是亚马逊提供的云服务。它是当今最强大的云平台之一。近几年获得成功的多家网站，比如Pinterest,Foursquare,Airbnb,Spotify，都架设于该平台。AWS的影响力可见一斑。为了使用亚马逊云，需要有一个亚马逊账户。你可以使用已有的亚马逊购物账户，也可以重新注册。前往亚马逊AWS官网：上面的"MyAccount/Console"菜单中，我的账户(MyAccount)主要包括各种账户和账单信息。管理面板(AmazonManagementConsole)用于设置AWS的云服务。根据提示设置账户。你需要输入信用卡信息，并有一个电话用于验证。AWS有一个免费的计划可以选择，可以先拿来试用：上面的"MyAccount/Console"菜单中，我的账户(MyAccount)主要包括各种账户和账单信息。管理面板(AmazonManagementConsole)用于设置AWS的云服务。根据提示设置账户。你需要输入信用卡信息，并有一个电话用于验证。AWS有一个免费的计划可以选择，可以先拿来试用：注册完成后，依然从"MyAccount/Console"菜单，进入管理面板(AmazonManagementConsole)。AWS的大部分云服务都列在这里，包括我们后面要使用的EC2。EC2实例(instance)EC2(AmazonElasticComputeCloud)是亚马逊推出的“弹性云”服务。一个EC2的实例(instance)提供了一个虚拟主机。你可以像使用一台电脑或者一台服务器那样，使用这个虚拟主机。另一方面，EC2会根据你的实际消耗的计费，避免了主机的闲置耗费。随着网站的增长，EC2可以很容易的拓展，支持更多的来访。对于新注册的用户，可以免费创建一个EC2实例每月750小时主机时间30G存储空间2百万次IO1GB闪存15GB带宽收费细节可参考AWS计价。我们将创建一个EC2实例，并在该虚拟主机上架设WordPress。从管理面板进入EC2页面：这个页面中，有四个标出的选项：右上角的Singapore。你可以根据用户的主要所在地，设置服务器地址。左侧的Instances。列出所有已经创建的实例。你可以进一步设置。左侧的SecurityGroups。用于控制不同IP地址对某个实例的访问权限。中间的LaunchInstance按钮，新建实例 新建实例，并跟随指示设置。我选择的是：操作系统为Ubuntu13.10,64位t1，micro的实例类型(instancetype)，这是可以免费使用的实例类型。使用默认的用户组(securitygroup)，允许所有IP(0.0.0.0/0)访问22端口，即SSH端口。创建新的键值对(keypair)，该键值对用于SSH访问的加密。将生成的.pem文件保存为vamei.pem启动实例 在EC2页面的菜单中选择Instances，可以查看已经创建的所有实例及其相关属性。左键点击某个实例，可以从下面的窗口看到相关的信息，比如实例的域名和IP地址：访问权限这里主要说明SecurityGroups的访问权限设置。我们刚才在创建实例中，允许所有的IP访问SSH端口。由于我们的目的是架设一个WordPress的Web站点，我们还需要开放80和3389端口。在EC2页面选择SecurityGroups，选择实例所属的用户组。在下方的窗口中，选择Inbound标签页，并增加规则，开放80和3389端口给所有人。另一方面，我们的SSH端口依然是所有人都可以访问。这并不安全。可以增加关于22号端口的规则(rule)，限定可访问的IP范围。ApplyRuleChanges之后，这些规则就会生效。你可以在SecurityGroups页面下，创建多个群组。回到Instances页面中，右键点击相应实例，设置群组，让一个实例归属于多个群组。WordPress建站现在多个方面都已经准备好。使用保存的vamei.pem密钥，利用SSH登录到虚拟主机。在Linux和Mac下，可以直接使用SSH命令: 复制代码代码如下:ssh-ivamei.pemubuntu@ec2-54-254-225-107.ap-southeast-1.compute.amazonaws.com对于Ubuntu系统来说，用户名为ubuntu。对于AmazonLinux系统，用户名ec2-user。对于RHEL5,用户名可能是root，也可能是ec2-user。在Windows下，可以使用SSH软件登录，比如PuTTY。可参考使用SSH连接云。登录之后，你可以像使用单机Linux那样使用亚马逊云。架设WordPress博客的步骤，参考我上一篇文章WordPress快速建站。架设成功之后，可以根据实例的域名或者IP访问。我的实例的域名是http://ec2-54-254-225-107.ap-southeast-1.compute.amazonaws.com/***图片上传的权限问题：上传多媒体图片时，有可能出现无权建立文件夹的提示。这时，要登陆EC2，修改相应的母文件夹wp-content的权限，让apache的用户名拥有写入权限。apache服务器的用户名可以使用下面命令找到： 复制代码代码如下:apache2ctl-S我的apache的用户名为www-data，所在组为www-data。我的方式是将文件夹归属为www-data组，并让归属组拥有写入权限。域名设置AWS提供的域名是一个次级域名。我想申请一个正常的，易于人记忆的域名，比如vamei.me。到GoDaddy上搜索，这个域名还没有人注册，申请账户并注册该域名。(需要信用卡，每年支付十几美元的费用)域名注册之后，需要将已经创建的实例和该域名连接。登录GoDaddy的账户，访问自己的账户。所有注册的域名都在“Domain”一栏中列出。点击vamei.me一行的Launch按钮，进入vamei.me域名的详情页面。选择修改DNSZoneFile。将一开始的AHost的IP地址，改为实例的IP地址：这一修改可能需要一些时间才能生效。生效后，可以通过vamei.me访问我的博客了。上面的域名设置成功之后，WordPress可以通过两个域名访问，即原有的AWS域名和GoDaddy注册的域名。如果你尝试点击博客的不同页面，会发现这些链接依然使用的是旧的域名。我们可以在WordPress中修改。访问自己的博客，并登录。在Dashboard->Setting->General中，将WordPressAddress和SiteAddress两栏，修改为新的域名：在修改过程中，可能不小心输错，导致无法再次登录博客。这种情况下，可以根据WordPress关于修改站点URL的指导处理。 总结AWS云让曾经复杂而专业的服务器架设和管理变得简单。正如上面看到的，借用AWS云和WordPress这样的神器，程序员可以十分钟的时间搞定一个网站，简单而迅速。AWS云是一个虚拟主机，当然不止架设博客这么简单的功能。你可以在AWS云上设置其它语言的Web框架，或者用作代理服务器，或者手机APP的后端，或者进行数据的分析和运算。总之，创造变得自由。
YouTube发展迅速，每天超过1亿的视频点击量，但只有很少人在维护站点和确保伸缩性。这点和PlentyOfFish类似，少数人维护庞大系统。是什么原因呢？放心绝对不是靠人品，也不是靠寂寞，下面就来看看YouTube的整体技术架构吧。平台 ApachePythonLinux(SuSe)MySQLpsyco，一个动态的Python到C的编译器lighttpd代替Apache做视频查看状态支持每天超过1亿的视频点击量成立于2005年2月于2006年3月达到每天3千万的视频点击量于2006年7月达到每天1亿的视频点击量2个系统管理员，2个伸缩性软件架构师2个软件开发工程师，2个网络工程师，1个DBAWeb服务器1，NetScaler用于负载均衡和静态内容缓存2，使用mod_fast_cgi运行Apache3，使用一个Python应用服务器来处理请求的路由4，应用服务器与多个数据库和其他信息源交互来获取数据和格式化html页面5，一般可以通过添加更多的机器来在Web层提高伸缩性6，Python的Web层代码通常不是性能瓶颈，大部分时间阻塞在RPC7，Python允许快速而灵活的开发和部署8，通常每个页面服务少于100毫秒的时间9，使用psyco(一个类似于JIT编译器的动态的Python到C的编译器)来优化内部循环10，对于像加密等密集型CPU活动，使用C扩展11，对于一些开销昂贵的块使用预先生成并缓存的html12，数据库里使用行级缓存13，缓存完整的Python对象14，有些数据被计算出来并发送给各个程序，所以这些值缓存在本地内存中。这是个使用不当的策略。应用服务器里最快的缓存将预先计算的值发送给所有服务器也花不了多少时间。只需弄一个代理来监听更改，预计算，然后发送。视频服务1，花费包括带宽，硬件和能源消耗2，每个视频由一个迷你集群来host，每个视频被超过一台机器持有3，使用一个集群意味着： -更多的硬盘来持有内容意味着更快的速度 -failover。如果一台机器出故障了，另外的机器可以继续服务 -在线备份4，使用lighttpd作为Web服务器来提供视频服务： -Apache开销太大 -使用epoll来等待多个fds -从单进程配置转变为多进程配置来处理更多的连接5，大部分流行的内容移到CDN： -CDN在多个地方备份内容，这样内容离用户更近的机会就会更高 -CDN机器经常内存不足，因为内容太流行以致很少有内容进出内存的颠簸6，不太流行的内容(每天1-20浏览次数)在许多colo站点使用YouTube服务器 -长尾效应。一个视频可以有多个播放，但是许多视频正在播放。随机硬盘块被访问 -在这种情况下缓存不会很好，所以花钱在更多的缓存上可能没太大意义。 -调节RAID控制并注意其他低级问题 -调节每台机器上的内存，不要太多也不要太少视频服务关键点 1，保持简单和廉价2，保持简单网络路径，在内容和用户间不要有太多设备3，使用常用硬件，昂贵的硬件很难找到帮助文档4，使用简单而常见的工具，使用构建在Linux里或之上的大部分工具5，很好的处理随机查找(SATA，tweaks)缩略图服务1，做到高效令人惊奇的难2，每个视频大概4张缩略图，所以缩略图比视频多很多3，缩略图仅仅host在几个机器上4，持有一些小东西所遇到的问题： -OS级别的大量的硬盘查找和inode和页面缓存问题 -单目录文件限制，特别是Ext3，后来移到多分层的结构。内核2.6的最近改进可能让Ext3允许大目录，但在一个文件系统里存储大量文件不是个好主意 -每秒大量的请求，因为Web页面可能在页面上显示60个缩略图 -在这种高负载下Apache表现的非常糟糕 -在Apache前端使用squid，这种方式工作了一段时间，但是由于负载继续增加而以失败告终。它让每秒300个请求变为20个 -尝试使用lighttpd但是由于使用单线程它陷于困境。遇到多进程的问题，因为它们各自保持自己单独的缓存 -如此多的图片以致一台新机器只能接管24小时 -重启机器需要6-10小时来缓存5，为了解决所有这些问题YouTube开始使用Google的BigTable，一个分布式数据存储： -避免小文件问题，因为它将文件收集到一起 -快，错误容忍 -更低的延迟，因为它使用分布式多级缓存，该缓存与多个不同collocation站点工作 -更多信息参考GoogleArchitecture，GoogleTalkArchitecture和BigTable数据库 1，早期 -使用MySQL来存储元数据，如用户，tags和描述 -使用一整个10硬盘的RAID10来存储数据 -依赖于信用卡所以YouTube租用硬件 -YouTube经过一个常见的革命：单服务器，然后单master和多readslaves，然后数据库分区，然后sharding方式 -痛苦与备份延迟。master数据库是多线程的并且运行在一个大机器上所以它可以处理许多工作，slaves是单线程的并且通常运行在小一些的服务器上并且备份是异步的，所以slaves会远远落后于master -更新引起缓存失效，硬盘的慢I/O导致慢备份 -使用备份架构需要花费大量的money来获得增加的写性能 -YouTube的一个解决方案是通过把数据分成两个集群来将传输分出优先次序：一个视频查看池和一个一般的集群2，后期 -数据库分区 -分成shards，不同的用户指定到不同的shards -扩散读写 -更好的缓存位置意味着更少的IO -导致硬件减少30% -备份延迟降低到0 -现在可以任意提升数据库的伸缩性数据中心策略1，依赖于信用卡，所以最初只能使用受管主机提供商2，受管主机提供商不能提供伸缩性，不能控制硬件或使用良好的网络协议3，YouTube改为使用colocationarrangement。现在YouTube可以自定义所有东西并且协定自己的契约4，使用5到6个数据中心加CDN5，视频来自任意的数据中心，不是最近的匹配或其他什么。如果一个视频足够流行则移到CDN6，依赖于视频带宽而不是真正的延迟。可以来自任何colo7，图片延迟很严重，特别是当一个页面有60张图片时8，使用BigTable将图片备份到不同的数据中心，代码查看谁是最近的关于扩展性的思考以下虽然都不是什么新思想，但希望对你有所助益。分而治之是扩展性技术的灵魂。考虑以层次化的方式完成所有的工作。这也是数据分片的症结所在。要知道如何将数据分区，以及如何将已分区的数据进行关联。总而言之，保持简单与松散的耦合非常必要。充分利用Python的动态特性，构建易于扩展的软件架构。近似的正确性。要相信监控系统所报告的系统运行状态。如果问题没有出现，就认为一切良好。不一致的数据模型。例如，阅读评论的人和写评论的人对你刷新页面的动作会有不同的反应，但也不必完全基于事务处理进行系统设计，这会显得矫枉过正。我们依然需要不一致的数据模型。分布式系统的随机性。分布式系统就如同气象系统一样，对分布式系统进行调试会存在更多的随机性。例如，缓存过期。一般情况下，服务器会将流行的视频缓存24小时。如果一旦出现缓存同时过期的情况，服务器将同时开始缓存，荷载如闻惊雷！最快的函数调用就是不做任何调用。合理设计事务处理发生的间隔和次数。仔细观察API，并做到心中有数。如何定义输入、输出？所有的函数调用本质上都是围绕数据发生的，那在函数调用之后，又会发生什么？在Python中运用RPC重定向。程序员是代码的构建者，因此要做好约定。如果代码不幸失败了，还可以从RPC输出中追查原因。没有完美的组件。一个组件的运行周期可能持续1-6个月，具体多久，谁也说不清。随着时间的推移，我们会用Python和C重写一些东西，这证明你正在淘汰旧的组件，当你观察到一个新组件出现的时候，它诞生了。没有人了解整个系统的运作机制。因此，我们需要定义组件。视频转码和视频搜索截然不同，建立良好的数据规范非常重要。效率与扩展性并重。最有效率的是用C实现进程，但这样的方式缺乏扩展性。着眼于宏观层面、组件及其失败的原因。使用RPC是否明智？内联如何？进行分解研究，也许会发现不同之处。重视算法。与其绞尽脑汁用Python来实现高效的算法，不如用它做些更有实用价值的事。在这方面，C语言有它的优势。我们很少从事面向对象设计。我们使用了大量的名称空间，使用类来组织数据，但极少面向对象。我乐意用下面的词汇来形容我们的代码树：简单、实用、优雅、正交、可组合，这是我们的追求。总结YouTube解决问题的哲学只有一个词：简单。许多YouTube的产品最初只是源于一个简单的Python脚本。这正是应了我们的一句老话，不积跬步，无以至千里；不积小流，无以成江海。
据中国互联网络信息中心(CNNIC)1月22日发布的第37次《中国互联网络发展状况统计报告》中数据显示，截至2015年12月，中国网站总数为423万个，年增长26.3%，其中“.CN”下网站数为213万个。 可以看出，越来越多的企业开始重视企业网站的建设和运营。但是，除了专业的建站公司或者工作室，一般的企业并不具备网站建设和运营的能力，往往会走一些弯路，或者执行一些不利于网站运营的决策，比如之前写过的一篇文章《具体谈谈企业网站内容的规划》。在这里，笔者提醒企业相关负责人，建网站企业要有自己的想法，但是也要听取建站人员的建议。建站行业，也是鱼龙混杂，建站能力也是良莠不齐，就笔者从业经验，想给需要建站的企业或者团队一些建议。第一点、如何选择建站服务商有些企业网站的之所以会“胎死腹中”或者“难产”，就是因为没有选择合适的建站服务商。举个身边的案例，前一段时间，大学同学打电话联系我，问做网站的事情，说到他表哥公司的网站做4个月了，还没有完工，还有一大堆问题，问我怎么办。问清楚相关事情之后，突然觉得，这个行业真是鱼龙混杂。一个企业站，怎么能够4个月还不完工?而且，是死贵死贵的(参考本地建站行业的价格水平)，付的款可以做两个站了。还有就是另外一家公司的网站，亲人负责网站维护，问题一大堆，维护起来非常麻烦，连我去操作起来都很不方便。所以，选择合适的建站企业或工作室是很有必要的，也是最基本的前提。那么，如何选择建站企业呢?(1)看接待工作人员。如何看?自己阅人吧，不多说。(2)看成功案例。切记，并不是简单的看看图片，而是打开网站实际的去看，也可以咨询一下网站拥有公司。(3)看对需求的关心程度。如果不关心客户的需求，如何做出真正能用的网站?(4)看售后维护服务。没有完美的程序，总会有测不出来的BUG出现，因此一般都会有半年或者一年的免费维护期，不过仅限于网站出现某些问题影响使用，不包括新增功能。如果不想找第三方建站的话，企业也可以自己建站，具体参考《如何用WordPress快速搭建网站》一文，建议对网站定制性要求不高的客户选用。如果有需要可以联系笔者，笔者提供建站以及建站咨询服务。第二点、说出你的需求(认识你的客户)早在2015年8月，笔者就写过一篇文章《网站建设必修课:认识你的客户》，是真实感受。就因为，签合同之前，需求不明确，导致扯皮，拖延以及项目亏损，客户也不高兴，我们也不爽。所以，建议就是在签合同之前明确的表明自己的要求，列出来，不要说一些口头上的需求，也不要理所当然的认为哪些是必须的，要有的，都要列出来，让建站方清楚自己的需求，并确认需求。第三点、签订合作协议为保证项目质量、进度、需求等，不管是关系有多好，还是建议签署合作协议，写清楚需求、费用、工期、售后等内容。第四点、网站出现问题及时联系建站方有些时候，网站维护的时候遇到问题并不是维护人员的问题，而是建站方的服务不到位。就拿我亲人公司的网站举例，就是因为建站方没有服务好，导致维护起来问题重重，领导又觉得是自己的问题，没有及时联系售后。建议网站上线时，由建站方培训一下如何操作，再简单的网站，操作起来也有不熟练的地方，尤其是有一些奇葩的管理后台。就说到这里吧，这四点建议，希望能够给企业带来作用。希望少走弯路，网站尽快顺利上线。来源：zzu追梦人的博客
一、twitter的核心业务twitter的核心业务，在于following和befollowed（1）following-关注进入个人主页，会看到你follow的人发表的留言（不超过140个字），这是following的过程；（2）followed-被关注你发布一条留言，follow你的人将看到这条信息，这是befollowed的过程；二、twitter的业务逻辑twitter的业务逻辑也不复杂。following业务，查follow了哪些人，以及这些人发表的留言；followed业务，前端js轮询后端，看follow了的人有没有新留言，有则更新（更新及时性取决于轮询时间）；三、三层架构（three-tierarchitecture）网站的架构设计，传统的做法是三层架构，所谓“传统”不意味着“过时”，新潮的技术不成熟，传统的路子更稳健。（1）表示层（presentationtier）：apachewebserver，主要任务是解析http协议，将请求分发给逻辑层；（2）逻辑层（logictier）：mongrelrailsserver，利用rails现成的模块，降低工作量；（3）数据层（datatier）：mysql；表示层：表示层的主要职能有2个：（1）http协议处理（httpprocessor）；（2）分发器（dispatcher）；当然，访问twitter的不仅仅是浏览器，可能还有手机，由于可能存在其他协议，故可能存在其他processor。逻辑层：当用户发布消息时，依次执行：（1）存消息至msg表；（2）查用户relation表，找出其followed_ids；（3）获取followed_ids中用户的状态；（4）在线的ids，将消息push进一个队列queue；（5）queue中的msg，更新ids的主页；这里面要用到队列，其实现方式有很多种，例如apachemina，twitter团队自己实现了一个kestrel。数据层：twitter的核心是用户；消息；用户关系。围绕这几个核心，其核心数据的schema设计：（1）用户表userid,name,pass,status,…（2）消息表msgid,author_id,msg,time,…（3）用户关系表relationid,following_ids,followed_ids。无论如何，架构框架清晰如下：四、cache=cash即缓存等于收入cache的使用对大型网站架构至关重要，网站响应速度是影响用户体验最明显的因素，而影响响应速度最大的敌人又是磁盘I/O。twitter工程师认为，良好体验的网站平均响应时间应该在500ms左右，理想的时间是200-300ms。关于cache的使用，是twitter架构的一大看点，带cache的架构清晰如下：哪里需要cache？IO越频繁的地方，越需要cache。数据库是IO访问最频繁处，三大核心表是否有必要放入内存中？twitter的做法是，将表拆分，将其中访问最频繁的字段装入cache。（1）vectorcacheandrowcache即数组cache与行cache数组缓存：新发表消息的msgids，相关作者的ids，这些id的访问频率很高，存放它们的cache称为vectorcache；行缓存：消息正文的行cache；内存有限的情况下，优先vectorcache，实际结果vectorcache的命中率是99%，rowcache为95%；（2）fragmentcacheandpagecache访问twitter的用户除了网页（web通道），还有手机（API通道），而后者的比例占总流量的80%-90%。mysqlcache之外，cache的重心会在API通道上。手机屏幕的主体，是一屏一屏的消息，不妨把整个页面分割成若干局部，每个局部对应一些/一条消息，这些就是fragment。人气高的作者，缓存其页面的fragment，可以提高读取其发布消息效率，这就是fragmentcache的使命。人气旺的作者，人们也会访问其主页，这就是pagecache的使命。实际结果，fragmentcache的命中率为95%，pagecache为40%。虽然pagecache的命中率低，但由于是访问主页，其占用的空间是很大的，为了防止两种cache相互影响，这两种cache需要部署在不同的物理机器上。twitter的fragmentcache和pagecache都是使用的memcached。（3）httpaccelerator加速器web通道的缓存问题也需要解决，分析之后，web通道的压力主要来自搜索。面临突发事件时，读者们会搜索相关信息，而不会理会这些信息的作者是不是自己follow的那些人。为了降低搜索压力，可以将搜索关键词与搜索内容cache起来。这里，twitter的工程师使用了varnish。有趣的是，varnish通常部署在webserver外层，先访问varnish，其中没有相关的内容，才访问webserver；twitter的工程师却将varnish放在apachewebserver的内层，原因是他们认为varnish操作复杂，担心varnish崩溃造成系统的瘫痪，故采用了这种保守型部署方式。twitter没有公开varnish的命中率，他们声称，使用了varnish之后，整站的负载下降了50%。五、抗洪需要隔离twitter架构的另一大看点是其消息队列：隔离用户的操作，将流量高峰摊平。餐厅客满时，对于新来的顾客，虽然不能服务，但不是拒之门外，而是让他们现在休息厅等待。用户访问twitter时，接待他的是apachewebserver，而apache不能接待无限多的用户。2009年1月20日，奥巴马发表就职演说，twitter流量猛增，此时如何是好。面对洪峰，如何保证网站不奔溃？迅速接纳，但推迟服务。apache收到请求，转发给Mongrel，由Mongrel负责实际处理，apache则腾出手来，迎接下一位用户。但apache能够接待的用户数总是有限的，它的并发数受apache能够容纳的工作进程数量，这里不细究apache内部原理，图如下：六、数据流与控制流快速接纳，推迟服务，只是缓兵之计，目的是让用户不至于收到503（serviceunavailable）。真正的抗洪能力，体现在蓄洪与泄洪两个方面：（1）twitter有庞大的memcached集群，能大容量蓄洪；（2）twitter自己的kestrel消息队列，作为引流泄洪手段，传递控制指令（引流和渠道）；洪峰到达时，twitter控制数据流，将数据及时疏散到多个机器，避免压力集中，造成系统瘫痪。下面举例说明twitter内部流程，假设有两个作者，通过浏览器发消息，一个读者也通过浏览器阅读他们的消息。（1）登陆apachewebserver，apache分配一个工作进程为其服务，登陆，查id，写cookie等；（2）上传新写的消息，把作者id，消息等转发给Mongrel，apache等待Mongrel回复，以便更新作者主页，将新写的消息更新上去；（3）Mongrel收到消息后，分配一个msgid，将msgid与作者id等缓存到vectormemcached上去；同时，Mongrel让vectormemcached查找作者被哪些人follow，缓存如果没有命中会去后端mysql查找，并入cache；读者ids会返回给Mongrel，Mongrel把msgid与短信正文缓存至rowmemcached；（4）Mongrel通知kestrel消息队列服务器，每个作者及读者都有一个队列（没有则创建）；Mongrel将msgid放入读者的队列，以及作者本人的队列；（5）某一台Mongrel，它可能正在处理某一个id的队列，就会往返回该id用户的主页上添加上此条信息；（6）Mongrel将更新后作者的主页给前端等待着的apache，apache则返回浏览器。七、洪峰与云计算不细说了，洪峰扛不住时，只能加机器。机器哪里来？租云计算平台公司的设备。当然，设备只需要在洪峰时租用，省钱呀。八、push与pull的折衷可以看到，Mongrel的工作流程：（1）将相关ids放入vectormemcached和rowmemecached就算消息发布成功，而不负责mysql数据库的存入；（2）将相关msgid放入kestrel消息队列就算消息推送成功；Mongrel没有使用任何方式去通知作者、读者，让他们重新拉取消息。上述工作方式，反映了twitter架构设计分拆的理念：（1）将一个完整的流程分拆成独立工作的子流程，一个工作可以由各个服务负责（三层架构本身是一种分拆）；（2）多机器之间协作，细化数据流与控制流，并强调其分离；twitter业务流程的分隔，是一种事件驱动式的设计，主要体现在两个方面：（1）Mongrel与mysql的分离，前者不直接插手mysql的操作，而委托memcached全权负责；（2）上传、下载逻辑分离：只通过kestrel队列来传递指令；每时每刻都有用户在Twitter上发表内容，Twitter工作是规划如何组织内容并把它发送用户的粉丝。实时是真正的挑战，5秒内将消息呈现给粉丝是现阶段的目标。投递意味着内容、投入互联网，然后尽可能快的发送接收。投递将历时数据放入存储栈，推送通知，触发电子邮件，iOS、黑莓及Android手机都能被通知到，还有短信。Twitter是世界上活跃中最大的信息发送机。推荐是内容产生并快速传播的巨大动力。两种主要的时间轴：用户的及主页的。用户的时间轴特定用户发送的内容。主页时间表是一段时间内所有你关注用户发布的内容。线上规则是这样的：@别人是若被@的人你未关注的话将被隔离出来，回复一个转发可以被过滤掉。这样在Twitter对系统是个挑战。1.Pull模式有针对性的时间轴。像twitter.com主页和home_timeline的API。你请求它才会得到数据。拉请求的不少：通过RESTAPI请求从Twitter获取数据。查询时间轴，搜索的API。查询并尽可能快的返回所有匹配的推特。2.Push模式Twitter运行着一个最大的实时事件系统，出口带宽22MB/秒。和Twitter建立一个连接，它将把150毫秒内的所有消息推送给你。几乎任何时候，Push服务簇上大约有一百万个连接。像搜索一样往出口发送，所有公共消息都通过这种方式发送。不，你搞不定。(实际上处理不了那么多)用户流连接。TweetDeck和Twitter的Mac版都经过这里。登录的时，Twitter会查看你的社交图，只会推送那些你关注的人的消息，重建主页时间轴，而不是在持久的连接过程中使用同一个时间轴。查询API，Twitter收到持续查询时，如果有新的推特发布并且符合查询条件，系统才会将这条推特发给相应的连接。3.高观点下的基于Pull（拉取方式）的时间轴：短消息(Tweet)通过一个写API传递进来。通过负载平衡以及一个TFE(短消息前段)，以及一些其它的没有被提到的设施。这是一条非常直接的路径。完全预先计算主页的时间轴。所有的业务逻辑在短消息进入的时候就已经被执行了。紧接着扇出（向外发送短消息）过程开始处理。进来的短消息被放置到大量的Redis集群上面。每个短息下在三个不同的机器上被复制3份。在Twitter每天有大量的机器故障发生。扇出查询基于Flock的社交图服务。Flock维护着关注和被关注列表。Flock返回一个社交图给接受者，接着开始遍历所有存储在Redis集群中的时间轴。Redis集群拥有若干T的内存。同时连接4K的目的地。在Redis中使用原生的链表结构。假设你发出一条短消息，并且你有20K个粉丝。扇出后台进程要做的就是在Redis集群中找出这20K用户的位置。接着它开始将短消息的ID注入到所有这些列表中。因此对于每次写一个短消息，都有跨整个Redis集群的20K次的写入操作。存储的是短消息的ID,最初短消息的用户ID,以及4个字节，标识这条短消息是重发还是回复还是其它什么东东。你的主页的时间轴驻扎在Redis集群中，有800条记录长。如果你向后翻很多页，你将会达到上限。内存是限制资源决定你当前的短消息集合可以多长。每个活跃用户都存储在内存中，用于降低延迟。活跃用户是在最近30天内登陆的twitter用户，这个标准会根据twitter的缓存的使用情况而改变。只有你主页的时间轴会存储到磁盘上。如果你在Redis集群上失败了，你将会进入一个叫做重新构建的流程。 查新社交图服务。找出你关注的人。对每一个人查询磁盘，将它们放入Redis中。 MySQL通过Gizzard处理磁盘存储，Gizzard将SQL事务抽象出来，提供了全局复制。通过复制3次，当一台机器遇到问题，不需要在每个数据中心重新构建那台机器上的时间轴。如果一条短消息是另外一条的转发，那么一个指向原始短消息的指针将会存储下来。当你查询你主页的时间轴时候，时间轴服务将会被查询。时间轴服务只会找到一台你的时间轴所在的机器。 高效的运行3个不同的哈希环，因为你的时间轴存储在3个地方。 它们找到最快的第一个，并且以最快速度返回。 需要做的妥协就是，扇出将会花费更多的时间，但是读取流程很快。大概从冷缓存到浏览器有2秒种时间。对于一个API调用，大概400ms。因为时间轴只包含短消息ID,它们必须”合成”这些短消息，找到这些短消息的文本。因为一组ID可以做一个多重获取，可以并行地从T-bird中获取短消息。Gizmoduck是用户服务，Tweetypie是短消息对象服务。每个服务都有自己的缓存。用户缓存是一个memcache集群拥有所有用户的基础信息。Tweetypie将大概最近一个半月的短消息存储在memcache集群中。这些暴露给内部的用户。在边界将会有一些读时过滤。例如，在法国过滤掉纳粹内容，因此在发送之前，有读时内容剥离工作。
Facebook大数据技术架构的演进路线 Facebook一直是大数据技术最积极的应用者，因为它拥有的数据量极其巨大，一份资料显示2011年它拥有的压缩数据已经有25PB，未压缩数据150PB,每天产生的未压缩的新数据有400TB。在Facebook，大数据技术被广泛应用在广告、新闻源、消息/聊天、搜索、站点安全、特定分析、报告等各个领域。Facebook也是Apache大数据开源项目的最大贡献者之一。Facebook是2007年前后正式转向Hadoop计算框架，随之它向Apache基金会贡献了大名鼎鼎的Hive、ZooKeeper、Scribe、Cassandra等开源工具，当前Facebook的开源进程仍在积极推进着。Facebook大数据技术架构经历了三个演变阶段。 Facebook早期的大数据技术架构是建立在Hadoop、HBase、Hive、Scribe等开源工具基础上的。日志数据流从HTTP服务器产生，通过日志收集系统Scribe耗费秒级时间传送到共享存储NFS文件系统，然后通过小时级的Copier/Loader（即MapReduce作业）将数据文件上传到Hadoop。数据摘要通过每天例行的流水作业产生，它是基于Hive的类SQL语言开发，结果会定期会更新到前端的Mysql服务器，以便通过OLTP工具产生报表。Hadoop集群节点有3000个，扩展性和容错性方面的问题能够很好地解决，但是早期系统的主要问题是整体的处理延迟较大，从日志产生起1～2天后才能得到最终的报表。 Facebook当前的大数据技术架构是在早期架构基础上对数据传输通道和数据处理系统进行了优化，如图所示，主要分为分布式日志系统Scribe、分布式存储系统HDFS和HBase、分布式计算和分析系统（MapReduce、Puma和Hive）等。其中，Scribe日志系统用于聚合来自大量HTTP服务器的日志数据。Thrift是Facebook提供的软件框架，用于跨语言的服务开发，能够在C、Java、PHP、Python和Ruby等语言之间实现无缝的支持。采用ThriftRPC来调用Scribe日志收集服务进行日志数据汇总。ScribePolicy是日志流量和模型管理节点，将元数据传送给Scribe客户端和ScribeHDFS，采集的日志数据存储在ScribeHDFS。Facebook对早期系统优化后的数据通道称为DataFreeway，能够处理峰值9GB/s的数据并且端到端的延迟在10s以内，支持超过2500种的日志种类。DataFreeway主要包括4个组件，Scribe、Calligraphus、ContinuousCopier和PTail。Scribe用于客户端，负责通过ThriftRPC发送数据；Calligraphus在中间层梳理数据并写到HDFS，它提供了日志种类的管理，利用Zookeeper进行辅助；ContinuousCopier将文件从一个HDFS拷贝到另一个HDFS；PTail并行地tail多个HDFS上的目录，并写文件数据到标准输出。在当前架构中，一部分数据处理仍然以批处理的方式通过MapReduce进行小时级的处理，存储在中央的HDFS，每天通过Hive进行分析处理。另一部分接近实时的数据流则通过Puma来进行分钟级的处理。Facebook对专门分析提供Peregrine（Hipal）工具、对周期性分析提供Nocron工具进行分析。 Facebook未来的大数据技术架构的雏形已经出来。首先开源的是可能替代Hadoop系统中MapReduce的Corona，类似于Yahoo提出的YARN。Corona最大的一个进步是其集群管理器做到了基于CPU、内存和其他作业处理的需求资源的管理，这可以使得Corona既可以处理MapReduce作业，也可以处理非MapReduce作业，使Hadoop集群的应用领域更加广泛。二是Facebook最新的交互式大数据查询系统Presto，类似于Cloudera的Impala和Hortonworks的Stinger，解决了Facebook迅速膨胀的海量数据仓库快速查询需求。据Facebook称，使用Presto进行简单的查询只需要几百毫秒，即使是非常复杂的查询，也只需数分钟便可完成，它在内存中运行，并且不会向磁盘写入。第三是Wormhole流计算系统，类似于Twiitter的Storm和Yahoo的Storm-YARN。第四个重要项目是Prism，它能够运行一个超大的、能够将全球数据中心都连起来的Hadoop集群，可能在一个数据中心宕掉的时候即时的将数据重新分布，这是一个与Google的Spanner类似的项目。 Facebook的大数据技术架构演进路径代表了大数据技术的发展路线，难能可贵的是，开源是Facebook一贯的路线，它和Yahoo等公司一起为大数据技术的发展作出了巨大贡献。Facebook所用的软件从某些方面来说，Facebook还是属于LAMP类型网站，但是，为了配合其他大量的组件和服务，Facebook对已有的方法，已经做了必要的改变、拓展和修改。比如：Facebook依然使用PHP，但Facebook已重建新的编译器，以满足在其Web服务器上加载本地代码，从而提升性能；Facebook使用Linux系统，但为了自身目的，也已做了必要的优化。（尤其是在网络吞吐量方面）；Facebook使用MySQL，但也对其做优化。还有定制的系统，比如，Haystack—高度可扩展的对象存储，用来处理Facebook的庞大的图片；Scribe—Facebook的日志系统。下面展现给大家的是，全球最大的社交网站Facebook所使用到的软件。MemcachedMemcached是一款相当有名的软件。它是分布式内存缓存系统。Facebook(还有大量的网站)用它作为Web服务器和MySQL服务器之间的缓存层。经过多年，Facebook已在Memcached和其相关软件（比如，网络栈）上做了大量优化工作。Facebook运行着成千上万的Memcached服务器，借以及时处理TB级的缓存数据。可以这样说，Facebook拥有全球最大的Memcached设备。HipHopforPHP和运行在本地服务器上代码相比，PHP的运行速度相对较慢。HipHop把PHP代码转换成C++代码，提高编译时的性能。因为Facebook很依赖PHP来处理信息，有了HipHop，Facebook在Web服务器方面更是如虎添翼。HipHop诞生过程：在Facebook，一小组工程师（最初是3位）用了18个月研发而成。HaystackHaystack是Facebook高性能的图片存储/检索系统。（严格来说，Haystack是一对象存储，所以它不一定要存储图片。）Haystack的工作量超大。Facebook上有超过2百亿张图片，每张图片以四种不同分辨率保存，所以，Facebook有超过8百亿张图片。Haystack的作用不单是处理大量的图片，它的性能才是亮点。我们在前面已提到，Facebook每秒大概处理120万张图片，这个数据并不包括其CDN处理的图片数。这可是个惊人的数据！！！BigPipeBigPipe是Facebook开发的动态网页处理系统。为了达到最优，Facebook用它来处理每个网页的分块（也称“Pagelets”）。比如，聊天窗口是独立检索的，新闻源也是独立检索的。这些Pagelets是可以并发检索，性能也随之提高。如此，即使网站的某部分停用或崩溃后，用户依然可以使用。CassandraCassandra是一个没有单点故障的分布式存储系统。它是前NoSQL运动的成员之一，现已开源（已加入Apache工程）。Facebook用它来做邮箱搜索。除了Facebook之外，Cassandra也适用于很多其他服务，比如Digg。ScribeScribe是个灵活多变的日志系统，Facebook把它用于多种内部用途。Scribe用途：处理Facebook级别日志，一旦有新的日志分类生成，Scribe将自动处理。（Facebook有上百个日志分类）。HadoopandHiveHadoop是款开源Map/Reduce框架，它可以轻松处理海量数据。Facebook用它来做数据分析。（前面就说到了，Facebook的数据量是超海量的。）Hive起源于Facebook，Hive可以使用SQL查询，让非程序员比较容易使用Hadoop。（注1:Hive是是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供完整的sql查询功能，可以将sql语句转换为MapReduce任务进行运行。）VarnishVarnish是一个HTTP加速器，担当负载均衡角色，同时也用于快速处理缓存内容。Facebook用Varnish处理图片和用户照片，每天都要处理十亿级的请求。和Facebook其他的应用应用一样，Varnish也是开源的。Facebook可以平稳运行，还得利于其他方面虽然上面已经提到了一些构成Facebook系统的软件，但是处理如此庞大的系统，本身就是一项复杂的任务。所以，下面还将列出使Facebook能平稳运行的一些东西。虽然这里无法过多深入硬件方面，但硬件绝对是Facebook能达到空前规模的重要因素。比如，和其他大型网站一样，Facebook也用CDN来处理静态内容。Facebook还在美国西部的俄勒冈州建有一超大的数据中心，可以随时增加服务器。当然了，除了前面已经提到的，还有其他大量的软件没有说到。但是，希望能突出其中非常有特色的。
Facebook首先是大数据我以前有一个观点，或叫不同意见，与互联网同行交流起来，感到非常费劲。他们总是认为，Facebook首先是SNS；我却认为，Facebook首先是数据。我指出：“国内业界总是把脸谱当作SNS津津乐道。其实这是一种比较业余的看热闹的观点。脸谱确实是SNS，但他真正的核心竞争力，在数据核心业务上。”我这种异类的看法，在项目经理、尤其是标榜SNS概念的项目经理那里，很少得到共鸣。这一回，终于在投资人那里，遇到了知音。我认为资本人的观点，比项目经理的观点，更接近Facebook的实际。首先，资本人比项目经理视野更开阔，更长于把Facebook放在时代大背景中看，而不是项目经理那种单纯业务观点。资本人把Facebook放到了两个大背景中：1、在时代判断上认识到，社交网络(SNS)的价值挖掘引领互联网进入大数据时代，推动“大数据”产业发展。2、在产业链判断上认识到，以Facebook为代表的社交网络率先进入大数据时代，将进一步引领其他互联网领域的大数据应用，对用户价值的挖掘将驱动“大数据”产业链的发展。项目经理虽然注意到了Facebook的SNS，但对于SNS在更大范围做什么用，想得并不多，因此把SNS当作了目标本身。其次，资本人比项目经理更长于透过SNS的现象，看到其数据本质。资本人把Facebook这个“特殊”，放在了“一般”之中：1、资本人认识到SNS只是大数据在采集端的一个特例：大数据指的是“海量数据+复杂数据类型”，而社交网络(SNS)恰恰就是每秒钟都在生成海量的非结构化数据(文本、应用、位置信息、图片、音乐、视频等)，是典型的“大数据”的系统；2、SNS只是大数据的一种应用：“大数据”的核心在于数据的挖掘和应用产生的多方位价值。社交网络(SNS)的价值挖掘本身就是“大数据”和商业智能应用的重要应用。3、Facebook代表着一对一的消费驱动模式转型：Facebook用户数据蕴含着巨大的商业价值。用户所发表的评论、上传的图片、音乐、视频等均为典型的非结构化数据，其中蕴含的用户消费倾向，“数据”的挖掘分析可以大幅提升广告的精确投放效果，有利于Facebook开发对用户更具吸引力的应用，并且可以通过用户行为预测多个行业的发展趋势，蕴含巨大的商业价值。相形之下，项目经理对于Facebook的理解，过于集中到与转型无关的功能细节上了，而较少理解Facebook商业模式在转型上的含义。对扎克伯格来说，甚至资本人都不能读透他的心。资本只是在价值层面，解读Facebook是什么。而扎克伯格一再强调，Facebook的创建目的并非成为一家公司，需要在意义层面，读懂Facebook的使命。不是SNS之后的Facebook将是什么Facebook远不是SNS，SNS勉强可以说是Facebook的一种禀赋。对于禀赋来说，SNS甚至还只是多种可能的禀赋之一。这一点连商业分析人士都看出来了。FederatedMedia的约翰·巴特利(JohnBattelle)就看出，“Facebook正在进行的某种转变与我们过去的预测不同。该公司正尝试着对自身进行重新定义，不满足于做狭义方面的社交网站，而这恰是外界对它的理解”。1、成为人们生活的操作系统巴特利最看好的一个新方向，就是生活操作系统。巴特利表示，所有企业都抢着成为人们生活的操作系统，他们想成为这样一个中心地方，用户参与并将所有数据存储在那里，然后他们做任何事情都需要利用到这些中枢。扎克伯格本人说的则是：世界信息基础架构应当与社交图谱类似。扎克伯格的视野已经越过社交，从社交受到启发，扩展到图谱类似的“世界信息基础架构”。这个说法不如巴特利“成为人们生活的操作系统”到位。实际上扎克伯格的本义可能更接近这个意思，因为他说：人们分享得越多，他们就能够通过自己信赖的人，获得更多有关产品和服务的信息。他们能够更加轻松地找到最佳产品，并提高生活品质和效率。分明在强调生活的意义。“世界信息基础架构”同“生活操作系统”，都可能算是大数据背后的原型架构，相较而言，前者更侧重从客体把握数据的总体架构，而后者更侧重于主体把握数据的总体架构。对大数据来说，什么是生活操作系统呢？这是指用意义重构生活，数据不过是用来重构的意义的质料。用主体方面的意义一聚焦，数据就有了好坏之分：数据最终趋向于意义的，成为智慧的；最后背离意义的，成为愚蠢的。所以说，智慧地球也好，智慧城市也好，并不是数据的大堆积，而因为面向生活而显得更有意义的。工业社会的架构，没有把聚焦点放在意义之上，而是聚焦在价值上。价值与意义的关系，是手段与目的的关系。但是有价值不一定有意义，例如，有钱是有价值，快乐是意义，但有钱不一定快乐。也就是说，掌握了实现快乐的手段，但达不到快乐这个目的。工业社会的人性的基础架构，跟价值有关的，都是充分社会化的，极为专业；但是跟意义有关的，都处于小生产状态，极为业余。这使工业社会不完美，容易成为一个为了高度发达的手段而体制性地忘记目的和宗旨的社会。大数据的使命，不从技术这个手段看，而是从人的角度看，就是建立一个手段与目的之间的专业化、社会化的聚焦系统，从而体制性地让做事不要背离它的宗旨，从而让工业化条件下处于小农水平的人类意义系统，成为高度发达的社会总体架构。SNS与生活操作系统将是什么关系呢？SNS只不过捕鱼用的鱼网，建立一个聚焦于意义的生活操作系统，打到生活意义这网鱼，才是意图所在。而现在模仿Facebook的人，都被鱼网这个生活数据采集器吸引住了，建起一些一模一样的鱼网，模仿着Facebook的抛网动作，却不知那个动作是在打鱼，结果一网不捞鱼，二网不捞鱼，最后只碰上一些小尾巴的小尾巴鱼。殊不知，捕鱼除了用鱼网，还可以叉鱼、钓鱼、电鱼等各种手段，象SNS这样的数据采集器，还有许多，例如LBS、O2O、支付，甚至线下POS机。如果Facebook哪天不是SNS了，一定是发现有其它捕鱼方法，可以打到更多的鱼。打鱼，在这里比喻的就是意义或企业核心价值；捕鱼手段，在这里比喻的是禀赋(通常说的，你是干什么的，哪行的)。企业要基业常青，就要在保持核心价值的同时，让禀赋跟随环境的变化而变化。2、“重塑架构”：以客户为中心的倒置经济体系扎克伯格提出“重塑架构”的重要原则：我们希望通过帮助人们建立关系，重塑信息的传播和消费方式。我们认为，世界信息基础架构应当与社交图谱类似——它是一个自下而上的对等网络，而不是目前这种自上而下的单体结构。此外，让人们自主决定分享哪些内容，是重塑架构的基本原则。这种重塑架构的基本原则，实际上对大数据的结构化具有指导意义。在没有原则指导之下，大数据很可能在结构上是反的：仍然沿用传统的从生产者向消费者传导价值的结构，只是用新技术为老传统服务。这种服务虽然也是必要的，但却不是Facebook对大数据的定位。我们从扎克伯格的话中读出如下含义：1)重塑架构意味着大数据将倒置经济结构第一，“我们希望通过帮助人们建立关系，重塑信息的传播和消费方式”。重塑就是倒置，所谓倒置，就是颠倒价值生成的方向，原来是生产者到消费者，现在是消费者到生产者。这是从上到下，变为自下而上的第一重含义。在SNS和搜索引擎这种倒置的经济结构中，价值的生成，不是从生产者到消费者，而是反过来，从消费者到生产者。消费者首先在SNS和搜索引擎暴露(主动“生产”)消费意向信息，进入交换，使之形成抽象消费价值；第二步，由大数据对消费信息进行加工增值处理，相当于对消费进行资本化处理，使消费者主权象资本一样能够得到同样的获得剩余的待遇。第二，“它是一个自下而上的对等网络，而不是目前这种自上而下的单体结构”。传统经济和经济学，在生产与消费关系上，有一个重要的不对称。按“自生产这个上，到消费这个下”的顺序创造价值，生产者首先在商品和交换环节，将具体价值换化为抽象价值(交换价值)；第二步，将一般价值，通过资本机制，进行增值放大。但是消费者却没有这样的权利和权力，一是不能把消费者的具体价值转化为抽象价值，二是不能对这个价值进行增值，即消费没有资本化过程。大数据一旦走出就技术谈技术的原始阶段(2012-2014年)，进入大数据同经济结合的中世纪阶段(大约2015年以后)，人们就会发现，自下而上不光涉及信息传输，更关系到价值生成方式转变。变成通过大数据为消费者赋权的过程。我建议大家读读《公众风潮》和《创新推动者》这两本相反方向赋权的书，理解这种赋权对经济生活的改变。第三，“让人们自主决定分享哪些内容”。这里提到一个重要的概念：“自主”。在工业化经济结构下，人失去自主性，最主要的一步，是自主劳动异化为劳动力，因此在信息化中，人们通过信息获得自主性的先提，是将人性的因素，复归到劳动力，形成“人性+劳动力=自主劳动”的效果。扎克伯格由于历史局限，现在只是模模糊糊感到是在重塑消费方式，将来取代Facebook的小男生小女生，将需要把这一信息分享过程，深化为消费资本化过程。这将是大数据下一阶段(2018年以后)的课题。在那个阶段，人们将开始普遍思考海尔前些年解决的未来型问题：通过“人单合一”直接经济模式，解决由消费者生成数据，倒过来决定生产(特别是资本的战略结构的问题。现在美国管理会计师协会(IMA)暗暗盯住，并派人命名为ZEUS(宙斯)的海尔战略损益表，可能就透着资本化时期大数据的战略秘密通道。我昨天还专门同信息化企业首倡者胡建生讨论它对BI的决定性影响。Facebook到那个阶段，不再进步，小命就堪忧了。2)重塑架构意味着价值与意义的倒置工业社会的价值结构，是从价值到意义，人们先围绕手段进行生产，然后再用目的对手段纠偏；信息社会的价值结构，是从意义到价值，通过SNS和搜索引擎定位意义所在，然后再根据意义去做有价值的事。以往工业社会中，把握意义靠小农的方式。大数据要把意义，扩展为一个有数据结构的系统。在意义学研究中，这个结构要完成的任务，称为“意义的阐释”。这是一种读心术。大数据的体系结构，从主体意义角度看，就应该是读心术系统，是专业化地破除人类的斯芬克斯之谜的大系统。通过这样的生活操作系统，使人类得到提升，从仅仅有价值，变成不仅有价值，而且有意义。使人类因为意义而获得更高的满足。对于企业来说，道理也一样。关于从意义到价值这一决定方向，扎克伯格指出：在这一过程中，企业获得的益处是：他们能够制造更好的产品–即以人为本的个性化产品。除了制造更好的产品，一个更加开放的世界还将鼓励企业与客户展开直接而可靠的互动。这里说的以人为本及个性化，都是指意义所在；强调的是越过价值这个中间环节，实现生产者与消费者之间的“直接而可靠的互动”。用张瑞敏的话说，就是人单合一。意义需要解释，解释必须通过意义的循环实现。用扎克伯格的话说就是：它是一个自下而上的对等网络，而不是目前这种自上而下的单体结构。此外，让人们自主决定分享哪些内容。意义不是生产者(相当于作者)赋予的，而是通过消费者(相当于读者，即产品的接受者)赋予的。大数据系统通过意义在生产者与消费者之间的循环，实现价值与意义的统一，手段与目的的统一。另一方面，大数据的结构化还有另一方面，就是打通意义的语形、语义和语用三个环节。斯芬克斯之谜层面的意义，是可意会不可言传的。通过SNS这样的数据采集机制，形成的是意义的语形产业；接下来将形成语义产业，即对非结构化数据的加工产业链；最终形成语用产业，通过LBS、支付等手段，将数据挖掘与具体的一个人一个人的情境，进行锚定。这样才能破解语言层面之下的个性化意义和体验的意义。从人工智能角度讲，Facebook的数据计算模式有独特优点，它是人人计算，而非谷歌(微博)那种人机计算。人人计算，相当在对话中，人们互为搜索引擎，形成生态化的计算能力。这方面还存在很大的发展潜力。3、大数据生产力发动机内部的探索大数据作为新时代的生产力发动机，研究它的生产力特性，对于理解未来的商业狂潮，是一个基本功课。在大数据时代，对技术毫无感觉的人，很可能成为被狂奔的生产力战车拖来拖去的尸体。连对技术一窍不通的资本人，已经注意到Facebook大数据结构中“海量数据+复杂数据类型”，非结构化数据等典型问题。事实上，这还没有涉及Hadoop、NoSQL、数据分析与挖掘、数据仓库、商业智能以及开源云计算架构等诸多基础性问题。大数据大致的技术过程，是先以SNS、搜索引擎、POS机等采集器，将海量数据采集进数据仓库中，然后用分布式的技术框架(Hadoop)，对非关系型数据进行异质性处理(NoSQL)，通过数据分析与挖掘，发展一对一的商业智能。由于大数据问题比较复杂，我现在有些个人想法，但考虑成熟之前，先不拿出来误导大家。我们还是先顺着Facebook的实践和见识，自下而上归纳。Facebook在大数据这一行，也是显赫的主角之一。它在低成本整合海量数据方面，为大数据行内人士所称道。但目前Facebook的大数据战略在我看来，还没有完全定型，它主要集中发展的是内部数据管理这一块。数据分析：先结构化再挖掘把大量数据采集下来，它就有价值吗？人们看好Facebook因为它不光是把用户集合起来就了事。正如有学者判断：“Facebook之前数年的努力让接近10亿数字移民建立了联系和纽带，这个世界的边界仍要扩张，而下一步更重要的则是考虑如何让关系产生的海量数据更有价值。”现在，Facebook每天会采集到500+TB的数据，如果没有数据分析，Facebook在全球大数据的产业链中，充其量就是一个矿工、挖煤的。只有有了关键的一步——数据分析之后，它才真正实现了向“矿石加工”的角色转型，将采集到的数据，加以分类、提炼，发挥数据真正的价值。要处理这些数据信息，Facebook要过的第一关是归类。将用户发表的评论、上传的图片、音乐、视频这些碎片化、非结构化的数据进行瀑布式的分析，使其集结、归类成结构化的数据信息。形成身份类数据（用户注册的基本信息）、需求类数据（有“赞”按钮的显性信息、状态信息、心情信息）、关系类数据（通过用户关注的人和粉丝，判断与他与其他社交网络用户之间的关系）等多个数据模块。因此，当用户在Facebook上进行的分享、听音乐、点击无处不在的“赞”按钮，将状态改为“已订婚”的时候，Facebook要做的第一件事情就是将个人的杂乱数据，进行分类，结构化处理。数据分析的第二关会更难，就是要将这些结构化的数据进行解读，深入到数据背后的潜在意义。每当用户登录Facebook，Cookie会一直驻留在用户的浏览器中，从此它的浏览行为、浏览页面的关键字会被记录，通过对关键字和上传信息的持续分析，Facebook很容易得出用户的长期爱好和近期需求。再加上对你的朋友圈的分析，可以获得你的教育、工作、收入、地理位置等等诸多方面，这种挖掘和解读往往比个人主动填写的信息还要全面、真实。开心网副总裁郭巍对Facebook数据挖掘能力的羡慕之情溢于言表：“根据海量用户的使用习惯做数据挖掘，然后对用户进行‘画像’，是社交网络最强大的功能之一。相比其他社交网络，Facebook的‘用户画像’能力非常强，这会使它能更精准地把握用户需求和广告主的需求。如果以素描来做比方，国内的SNS网站可能画的是个大致的模样，但Facebook可能就会非常详细，睫毛多长，眼睛是灰色的还是蓝色的，发型是什么样子，然后穿着衬衫、领带、西装等，还有胡须。”正是基于这样细致的数据挖掘，Facebook给广告主带来了超乎想象的精准投放：在主页上刚刚宣布自己“订婚”了的波士顿女士收到了婚纱摄影的推送广告，而同是待嫁的印度孟买的准新娘则会收到结婚莎丽的广告。当两个好友在Facebook上正聊着未来某个时候计划去欧洲旅游时，Facebook就会在他们的右侧广告区滚动出现一则旅游公司的广告，上面会介绍去欧洲旅游的机票价格和出团时间。数据应用：广告、产品、用户三个层面数据应用在Facebook的大数据战略中还没有完全定型，主要集中在广告营销、产品服务和用户管理三个层面。基于数据挖掘的自助式广告下单系统在介绍Facebook的自助式广告下单系统之前，我们首先要理解Facebook的广告模式。我们知道谷歌Adword搜索引擎的关键词的广告模式是这样的：用户在搜索关键词，如果这个关键词和广告商竞价购买的那个词相吻合，它的广告就会出现。而Facebook的模式不同，它并不是用关键词来找目标消费者，而是利用用户的基本属性、粉丝、兴趣来找出潜在的用户群。而这种广告模式之所以可行，必然要求后台有强大的数据系统作为支撑。因此，基于这样的广告模式，Facebook的广告下单系统也基本上以自助式为主。投放广告的广告主都由自定义受众开始，Facebook会一步一步带领客户设定一系列的参数，主要有三种方式：第一根据人口统计特征进行筛选，即受众的基本属性，一共有11个维度，包括所在地、年龄、性别、性情对象、感情状态、语言、教育程度和学校、工作场所等。第二根据粉丝页进行筛选，即具体到哪类关系的人。第三根据兴趣进行筛选，每个用户在开设Facebook时都可以设定自己的兴趣，包括宗教、喜欢的事情（旅游、电影、阅读等）、喜欢的品牌等。接下来广告主需要提交广告活动的总预算和每天的预算额。系统会根据广告主设定的受众条件，运算出目标受众群的人数，然后根据广告主选择的广告方式（CPM/CPC）给出建议费用的范围。以LadyGaGa为例来做简单的说明：在美国加州喜欢LadyGaGa的女性约有15万人，而加入英国以后，喜欢LadyGaGa的女性人数大幅增加到近2百多万人。如此一来，如果广告商想针对喜欢LadyGaGa这类表演或歌手的受众打广告时，对于受众群的人数就有了大概的了解。假设产品是能量饮品（类似红牛一类的饮品）的话，还可以进一步针对喜欢运动（#sport）和冒险（#adventure）的Facebook用户，甚至将红牛等能量饮品的粉丝页设定为受众条件。由于和后台的数据实时相连，广告主可以在广告下单系统上了解每天新增/减少的粉丝数目、从哪里来、粉丝的基本信息以外，还可以看到每次广告投放所能接触到的人数、点击率和转化率，以便随时更改策略。在数据库的支撑下，这种全自助的系统具有的优势也十分明显：一来给更多缺乏广告代理公司的中小企业客户提供了自己制定广告预算和受众群体的工具；二来通过细致的指标选择，给广告客户带来专业、精准的投放体验；第三提升了广告经营效率，节省了广告经营开支；第四也避免了人为的服务错失将一些客户挡在门外。利用数据优化产品设计Facebook的数据挖掘和应用不仅对广告商具有很强的诱惑力，还能帮助产品设计团队优化网站的内容，掌握用户的使用模式，优化界面交互和操作。一个小例子：Julie是Facebook产品设计团队的一员，通过数据分析，掌握了Facebook是如何利用网站提供的各种功能的。以图片上传这个功能为例：Julie得到了以下几组数据：87%的用户在第一屏中的相册专辑名字提示框中选择类型，57%的用户打开文件选择功能来选择他们想上传的图片，52%的用户点击上传按纽，48%的用户会等待上传进度完成。数据很显然地说明了问题：那就是少于50%的用户能够成功上传图片。因此为了提高用户成功上传图片的比率，Facebook将Java/flashfacebook文件选择功能改成浏览器原生文件选择功能，结果上传量提高11%。这个问题运行了一段时间之后，团队又通过数据分析发现上传图片的用户中有85%仅仅上传一张图片。团队同时观察到用户不知道使用shift来选择多个图片进行上传，所以加了一个提示，在上传开始前出现上传多张图片的提示，结果数据从85%降低到40%。
现在很忙，过两天帮你做吧！”当你从技术部那里碰了一鼻子灰回来，这并不为怪——当你有事找他们的时候，他们的脸色可不怎么好看。然而所谓“巧妇难为无米之炊”，一场即将举办的活动如果没有专题网站，那如何去做推广，如何让更多的人知道你的活动信息，如何在活动前期抢占先机？ 对于一些新手站长来说，选择一款合适的建站工具是首要任务，选择不好，会导致后面的努力大打折扣。因此选择什么样的建站工具，是一项十分重要、且不易的工作，这点对于非技术性站长而言更加重要。 那么，非技术型站长该怎么选择正确的、最适合自己的网站制作工具呢?本文从“建站目的”、“站长自身侧重点”等方面跟大家说说“该如何选择适合自己的建站工具”。 非技术型站长可以分为2类：1)设计出身、且对代码不感冒的站长。2)对代码和设计都不感冒的站长。 显然他们需要的建站工具需要满足以下两点：1、简单快速的搭建一个专业的网站，解决设计和代码问题;2、让不懂代码的设计师在不需要程序猿插手的情况下有效的完成网站搭建工作(即使懂技术也可以借工具来节省时间)，解决代码编程问题。 目前市面上有很多种建站工具，通过零代码在线拖放工具，都能让你在几分钟内搭建一个网站，实现代码图像相结合，诸如Wordpress、Squarespace、Wix、微企点。 站长可根据自身情况对号入座，在认清自己属于哪种类型之后就可以大致选择下建站程序类型了。Squarespace和wix比较适合第一类，微企点是国内团队开发的建站工具，适合第一类和第二类。至于Wordpress适合懂点技术的站长，适合做博客性质的网站，非技术型站长用起来比较吃力。 Squarespace：不需代码、设计功底 Squarespace这款自助建站服务始于2004年，十二年的岁月使其发展成了使用最广泛的建站程序之一。不需要设计或是编程基础，便可通过Squarespace快速搭建一个精致的响应式网站。 Squarespacewww.Squarespace.com Squarespace的定价模式也较为灵活：可免费注册与建站。但若要发布网站，则有每月8至24美元的三种方案可供选择。 WIX：适合细化使用结构化模板的站长 跟Squarespace很像，wix建站工具也很适合非技术型站长，适合喜欢使用结构化模板的站长群体。wix有很大的模板库和第三方功能插件。WIXwww.wix.com 在价格方面，基本的建站计划是免费的，但如果需要电商模板、更多带宽等进阶要求，费用最高可能会达到25美元每月。 微企点：最适合非技术型站长的官网制作工具 微企点是国内团队开发，推出时间不长。作为一款使用H5技术制作企业官网的建站工具，能为用户免费提供搭建一个优秀官网所需的各种功能。微企点还有很多中文PC端和手机网站模板，对于需要制作跨屏官网的站长来说，无疑是个不错的选择。他们的网站模板跟国际最新流行的基本同步。 微企点 完全免费是微企点目前的一个绝对优势。此外，它还具有简单易用等特点。而且，随着微企点的普及，免费模板越来越多，功能插件也在丰富中，值得长期关注。 还有一点需要注意，国外的建站工具推出时间比较长，功能方便相对更加完善，不过做出来的网站，往往要走国际带宽，因此访问起来会比国内建站工具做出来的网站慢。另外国外的建站工具不能备案，如果要在百度和微信上推广的话，还是需要备案支持。站长需要衡量访问速度和网站功能和推广的需求，做出取舍。
Facebook作为全球知名的社交网站，拥有超过3亿的活跃用户，其中约有3千万用户至少每天更新一次自己的状态;用户每月总共上传10亿余张照片、1千万个视频;以及每周共享10亿条内容，包括日志、链接、新闻、微博等。因此Facebook需要存储和处理的数据量是非常巨大的，每天新增加4TB压缩后的数据，扫描135TB大小的数据，在集群上执行Hive任务超过7500次，每小时需要进行8万次计算，所以高性能的云平台对Facebook来说是非常重要的，而Facebook主要将Hadoop平台用于日志处理、推荐系统和数据仓库等方面。Facebook将数据存储在利用Hadoop/Hive搭建的数据仓库上，这个数据仓库拥有4800个内核，具有5.5PB的存储量，每个节点可存储12TB大小的数据，同时，它还具有两层网络拓扑。Facebook中的MapReduce集群是动态变化的，它基于负载情况和集群节点之间的配置信息可动态移动。Facebook的数据仓库架构，在这个架构中，网络服务器和内部服务生成日志数据，这里Facebook使用开源日志收集系统，它可以将数以百计的日志数据集存储在NFS服务器上，但大部分日志数据会复制到同一个中心的HDFS实例中，而HDFS存储的数据都会放到利用Hive构建的数据仓库中。Hive提供了类SQL的语言来与MapReduce结合，创建并发布多种摘要和报告，以及在它们的基础上进行历史分析。Hive上基于浏览器的接口允许用户执行Hive查询。Oracle和MySQL数据库用来发布这些摘要，这些数据容量相对较小，但查询频率较高并需要实时响应。一些旧的数据需要及时归档，并存储在较便宜的存储器上。下面介绍Facebook在AvatarNode和调度策略方面所做的一些工作。AvatarNode主要用于HDFS的恢复和启动，若HDFS崩溃，原有技术恢复首先需要花10～15分钟来读取12GB的文件镜像并写回，还要用20～30分钟处理来自2000个DataNode的数据块报告，最后用40～60分钟来恢复崩溃的NameNode和部署软件。表3-1说明了BackupNode和AvatarNode的区别，AvatarNode作为普通的NameNode启动，处理所有来自DataNode的消息。AvatarDataNode与DataNode相似，支持多线程和针对多个主节点的多队列，但无法区分原始和备份。人工恢复使用AvatarShell命令行工具，AvatarShell执行恢复操作并更新ZooKeeper的zNode，恢复过程对用户来说是透明的。分布式Avatar文件系统实现在现有文件系统的上层。基于位置的调度策略在实际应用中存在着一些问题：如需要高内存的任务可能会被分配给拥有低内存的TaskTracker;CPU资源有时未被充分利用;为不同硬件的TaskTracker进行配置也比较困难等。Facebook采用基于资源的调度策略，即公平享有调度方法，实时监测系统并收集CPU和内存的使用情况，调度器会分析实时的内存消耗情况，然后在任务之间公平分配任务的内存使用量。它通过读取/proc/目录解析进程树，并收集进程树上所有的CPU和内存的使用信息，然后通过TaskCounters在心跳(heartbeat)时发送信息。Facebook的数据仓库使用Hive，这里HDFS支持三种文件格式：文本文件(TextFile)，方便其他应用程序读写;顺序文件(SequenceFile)，只有Hadoop能够读取并支持分块压缩;RCFile，使用顺序文件基于块的存储方式，每个块按列存储，这样有较好的压缩率和查询性能。Facebook未来会在Hive上进行改进，以支持索引、视图、子查询等新功能。现在Facebook使用Hadoop遇到的挑战有：服务质量和隔离性方面，较大的任务会影响集群性能;安全性方面，如果软件漏洞导致NameNode事务日志崩溃该如何处理;数据归档方面，如何选择归档数据，以及数据如何归档;性能提升方面，如何有效地解决瓶颈等。解决Namenode顽疾Google在2004年创造了MapReduce，MapReduce系统获得成功的原因之一是它为编写需要大规模并行处理的代码提供了简单的编程模式。MapReduce集群可包括数以千计的并行操作的计算机。同时MapReduce允许程序员在如此庞大的集群中快速的转换数据并执行数据。它受到了Lisp的函数编程特性和其他函数式语言的启发。MapReduce和云计算非常相配。MapReduce的关键特点是它能够对开发人员隐藏操作并行语义—并行编程的具体工作方式。HDFS（HadoopDistributedFilesystem）是专为MapReduce框架而下大规模分布式数据处理而设计的，HDFS可将大数据集（TB级）存储为单个文件，而大多文件系统并不具备这样的能力。（编者注：NTFS5MaxFilesonVolume：264bytes(16ExaBytes)minus1KB，1EB=1,000,000TB）。这也是HDFS风靡全球的重要原因。目前FacebookHadoop集群内的HDFS物理磁盘空间承载超过100PB的数据（分布在不同数据中心的100多个集群）。由于HDFS存储着Hadoop应用需要处理的数据，因此优化HDFS成为Facebook为用户提供高效、可靠服务至关重要的因素。HDFSNamenode是如何工作的？HDFS客户端通过被称之为Namenode单服务器节点执行文件系统原数据操作，同时DataNode会与其他DataNode进行通信并复制数据块以实现冗余，这样单一的DataNode损坏不会导致集群的数据丢失。但NameNode出现故障的损失确是无法容忍的。NameNode主要职责是跟踪文件如何被分割成文件块、文件块又被哪些节点存储，以及分布式文件系统的整体运行状态是否正常等。但如果NameNode节点停止运行的话将会导致数据节点无法通信，客户端无法读取和写入数据到HDFS，实际上这也将导致整个系统停止工作。TheHDFSNamenodeisasinglepointoffailure(SPOF)Facebook也深知“Namenode-as-SPOF”所带来问题的严重性，所以Facebook希望建立一套系统已破除“Namenode-as-SPOF”带来的隐患。但在了解这套系统之前，首先来看一下Facebook在使用和部署HDFS都遇到了哪些问题。Facebook数据仓库的使用情况在Facebook的数据仓库中部署着最大的HDFS集群，数据仓库的使用情况是传统的HadoopMapReduce工作负载——在大型集群中一小部分运行MapReduce批处理作业因为集群非常庞大，客户端和众多DataNode节点与NameNode节点传输海量的原数据，这导致NameNode的负载非常沉重。而来自CPU、内存、磁盘和网络带来的压力也使得数据仓库集群中NameNode高负载状况屡见不鲜。在使用过程中Facebook发现其数据仓库中由于HDFS引发的故障占总故障率的41%。HDFSNameNode是HDFS中的重要组成部分，同时也是整个数据仓库中的重要组成部分。虽然高可用的NameNode只可以预防数据仓库10%的计划外停机，不过消除NameNode对于SPOF来说可谓是重大的胜利，因为这使得Facebook可执行预订的硬件和软件回复。事实上，Facebook预计如果解决NameNode可消除集群50%的计划停机时间。那么高可用性NameNode是什么样子的？它将如何工作？让我们来看一下高度可用性NameNode的图表。在此结构中，客户端可与PrimaryNameNode与StandbyNameNode通信，同样众多DataNode也具备给PrimaryNameNode与StandbyNameNode发送blockreports的能力。实质上Facebook所研发的AvatarNode就是具备高可用NameNode的解决方案。Avatarnode：具备NameNode故障转移的解决方案为了解决单NameNode节点的设计缺陷，大约在两年前Facebook开始在内部使用AvatarNode工作。同时AvatarNode提供了高可用性的NameNode以及热故障切换和回滚功能，目前Facebook已经将AvatarNode贡献到了开源社区。经过无数次的测试和Bug修复，AvatarNode目前已在Facebook最大的Hadoop数据仓库中稳定运行。在这里很大程度上要感谢Facebook的工程师DmytroMolkov。当发生故障时，AvatarNode的两个高可用NameNode节点可手动故障转移。AvatarNode将现有的NameNode代码打包并放置在Zookeeper层。AvatarNode的基本概念如下：1.具备PrimaryNameNode与StandbyNameNode2.当前Master主机名保存在ZooKeeper之中3.改进的DataNode发送blockreports到PrimaryNameNode与StandbyNameNode4.改进的HDFS客户端将在每个事物开始之前对Zookeeper进行检查，如果失败会转移到另外的事务之中。同时如果AvatarNode故障转移出现在写入的过程中，AvatarNode的机制将允许保证完整的数据写入。Avatarnode客户端AvatarnodeDataNode或许有人会Facebook这一解决方案的名字感到好奇，这是因为Facebook的Hadoop工程师DhrubaBorthakur来到公司时正好是JamesCameron《阿凡达》电影热映时间。（我们应该感到庆幸，如果是1998年的话或许应该叫TitanicNode了）。AvatarNode经受住了Facebook内部最苛刻的工作环境，未来Facebook将继续大幅度改善AvatarNode的可靠性和HDFS集群的管理性。并整合与一般高可用性框架的整合，还将实现无人值守、自动化与安全故障转移等特性。Facebook已将自身使用的Hadoop与AvatarNode解决方案托管到GitHub。感兴趣的朋友可下载研究。当然不止Facebook在试图解决Hadoop的缺陷，MapR和Cloudera的产品也具备相似的能力。
百度经验是百度旗下的一款产品，在百度有很好的权重，如果能够很好的利用百度经验进行网络推广，那么一定能够收到事半功倍的效果。今天笔者就给大家分享一下如何利用百度经验做网络推广。我们看一下百度经验的权重。可以看出，百度经验的权重确实特别高，一定是进行网络推广的一把利器。现在，正式教大家如何进行推广。首先，讲解推广方法。百度经验的审核是很严格的，想要在经验里留下推广信息是很困难的，但是聪明的网络从业者还是找到了很多方法，其中主要使用的推广方法分为三种方式。第一方法、图片宣传法百度经验审核的时候主要对经验内容进行审核，对一些图片内容可能有有些放松，因此很多人抓住这一点进行推广。比如：有些人想推广自己微信公众号二维码。可以看出，这个浏览量还是不错的，作者巧妙的把微信号的二维码植入图片中，这样就骗过了百度经验的审核。这种方法经验发布成功率高，但是转化较低。第二种方法、结尾宣传法这种方法，其实很巧妙的利用了百度经验的一个漏洞，那就是在每一个经验下面都会有一个“注意事项”栏目可以填写。有些人就是看着这个地方，然后进行网络推广。可以看到，图中作者在注意事项中写到“如有问题可以加我微信XXXX”，这也不是很明显违反百度经验规定，注意事项本来就是提醒读者的嘛，也是合情合理的。这种方法的转化率相对较高，特别是遇到一些经验并没有写清楚的时候，读者看到联系方式肯定会加你的。第三种方法、诱导推广法这种方法也是抓住了百度经验自身的把柄，既然百度经验让我分享经验，那我就去老老实实分享我自己的经验就好。只不过分享这个经验的过程中，把我自己的产品推广出去。比如有人做电影下载站，看他如何进行推广的。这个经验是教你如何下载《捉妖记》这部电影的。经验第一步，就是诱导你去百度搜索一个关键词。这个关键词，绝对是作者自己的网站长尾关键词，通过这个方法，他巧妙的推广了自己的网站，没有进行任何违规操作，完全是分享自己的经验，经验也没有任何问题。这种方法的优势在于经验通过率很高，并且转化率高，但是这个要求有自己的一个网站或者博客，并且在搜索引擎能够搜索到自己独特的长尾关键词。分析了网上常见的几种利用百度经验进行网络推广的方法后，接下来为大家讲解一下，操作百度经验的注意事项。1、多账号批量发帖。做网络推广，多账号操作是必然的，不可能保证你每一条经验都能审核成功，也不可能保证你每一条经验都能获得好的排名。2、多账号批量投票。在你发布的每一个经验底部都有一个投票按钮，你用多账号互相去投票，投票越多，获得好排名几率越大。3、换IP操作。这个是多账号批量操作的时候需要注意的问题，如果同一个IP操作很多账号，百度经验也会屏蔽你的账号，并且降低审核通过率。结束语：这只是介绍了百度经验的常用方法，你可以根据这些方法灵活变通，创造出适合自己产品的推广方法，希望大家在这篇文章中能够有所收获。
中国互联网举报中心