作者：IT架构设计研究组
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
大数据时代的IT架构设计试读：
卷首语——架构与建筑
架构与建筑在英文里是同一个词，都叫Architecture。建筑已经有几千年的历史，而IT架构不过几十年的光阴。在人类光辉灿烂的建筑史面前，IT架构还只是一个小婴儿。
在谈到IT架构时，很多人喜欢把它和建筑做比较。笔者这里也不妨一试。翻了翻关于建筑的历史，名言名句数不胜数，这些建筑经验的规律性总结，对IT或有启发之益。
建筑与房子的区别在于，前者是艺术，后者只是一种东西。美国建筑大师F.L.赖特说：“建筑，是用结构来表达思想的科学性的艺术”。当我们在胜地观光时，总喜欢拍下那些或精巧、或宏伟的建筑——因为它的美。可我们有多少人能欣赏到虚拟世界里的IT架构之美呢？当Till Adam等人的《架构之美》成为畅销书时，我们恍然大悟，IT架构也是一种艺术。
要成为艺术家，离不开想象力和创造力。在很多公司关于架构师的招聘广告以及一些架构师的经验分享中，“想象力和创造力”已为大家所推崇，可我们想想，有多少人真的做到了呢？站在艺术而不只是科学的角度看，难怪有人会质疑中国到底有没有真正的架构师存在？或许美籍华人建筑师贝聿铭的这段话会给我们启发：“建筑是研究如何浪费空间的艺术。建筑始于工程完结之处。建筑师必定是伟大的雕塑家和画家。如果他不是雕塑家和画家，他只能算个建造者。”
年轻的中国架构师们，想办法把你所掌握的技术变成艺术吧，而不只是为了完成一份工作、一个项目。“当技术实现了它的真正使命，它就升华为艺术。”德国建筑大师密斯·凡·德罗如是说。
相信“少即是多”这句话已经被许多软件架构设计人员、互联网产品经理、UI设计师奉为圭臬。比如在敏捷软件开发方法中就到处体现出了这一原则，并因此让软件开发变得精益而高效。乔布斯和苹果公司更是把这种简约之美发挥到了极致。面对数据中心里日益复杂的IT基础架构，许多大型IT厂商也都把简化作为自己努力的方向。可你是否知道，“少即是多”正是出自密斯·凡·德罗之口。
作为20世纪中期世界上最著名的四位现代建筑大师之一，密斯·凡·德罗坚持“少即是多”的建筑设计哲学，在处理手法上主张流动空间的新概念。他的设计作品中各个细节精简到不可精简的绝对境界，不少作品结构几乎完全暴露，但是它们高贵、雅致，已使结构本身升华为建筑艺术。
平衡感、和谐感是建筑设计中的一个美学原则。建筑不仅内部结构需要平衡，其外观也需要与环境变化相平衡。建筑大师张开济有句名言：“建筑设计不能只顾自己的一个设计，而要和整个城市的风格相和谐。”试想，当梁思成看到今天中国内地占到全球70％的摩天大楼时，会不会继续发出他几十年前曾经发出过的感慨：“中国没有建筑，只有房子。”
IT架构何尝不是一种需要“平衡”的艺术——业务与技术之间、子系统之间、局部与全局之间、性能与稳定之间。不夸张地说，架构的不断优化、升级、改造、创新，本身就是在试图找到一种新的平衡。
世上没有永恒，只有变化。科学如此，艺术亦如此。建筑如此，IT架构亦如此。著名现代主义建筑大师格罗庇乌斯曾说：“建筑学必须前进，否则就要枯死。建筑没有终极，只有不断变革。”“变革”这个词对于搞IT的人来说，再熟悉不过了。回顾架构师大会走过的五年，今天大家关心和讨论的话题已经大不一样。时下，大数据、云计算、移动正在成为时代的弄潮儿。翻翻这本《大数据时代的IT架构设计》，你不难看到这些变化。
年轻的架构师们，让我们在变化之中，发挥想象力，借助技术之手，发现和创造“平衡高效、简约灵活”的IT架构之美吧！IT168企业级总编 洪钊峰
第1篇 Hadoop平台应用架构
Hadoop技术在电信运营商上网日志处理中的应用架构
方建国一、电信运营商上网日志处理的现状在移动互联网如此普及的今天，每天会产生大量的上网日志，这些上网日志由于数据量巨大，产生后只能被保留3天，就因为存储空间等原因被丢弃。目前，电信运营商只能基于CDR（详细通话记录）为主的客户行为分析可能缺失了大量的客户行为有效信息。例如，两个通话行为相似的人可能是完全不同类型的客户，如果将之同等对待，客户的接受度必然很差，浪费大量资源，并且无法取得良好的效果。这种分析，由于无法知晓通话内容，两个通话行为模式类似（例如夜间长时间的长途电话），实际通话目的及生活方式（其中一个是晚上与朋友聊天，另一个是加班需要的工作电话）完全不同的两个人往往在分析中被误归为一类，从而导致对客户的理解有较大偏差，营销效果不佳。
用户的上网行为中蕴含着大量的客户特征和客户需求信息，这些信息至关重要，而又是传统的CDR话单分析所不能提供的。因此，这就要求用户的上网日志记录必须被保存，而且还需要进行数据分析挖掘处理，然后根据处理结果定义用户的行为习惯，为电信运营商实现精细化运营提供重要的营销依据。
随着Hadoop技术平台系统的出现，可以实现上网日志的存储，同时提供数据挖掘处理功能。二、上网日志数据处理方法的流程
上网日志数据处理方法的流程如下：
1．对上网日志数据的URL地址进行提取。
2．对已知的URL数据，按照基准URL分类准则进行分类。
3．对未知的URL地址，首先爬取网页数据，然后对爬取的网页数据按照网页分类模型，进行网页分类，不断优化模型，提高网页分类的准确性。
4．根据每个人访问网址和对应网址的网页分类，利用模型统计出每个手机号码的个人喜好，为精准营销提供依据。
具体流程如下图所示。三、上网日志系统的技术架构方案
基于上述处理流程，上网日志处理系统的逻辑架构方案如下图所示。
针对每一部分的具体功能介绍如下。
数据源
从电信运营商系统服务器定时获取用户基本信息和上网日志信息，输入到集群HDFS文件系统和HBase数据库中。
接口层
接口层负责与外部系统的数据进行交换，包括用户数据、上网日志数据的采集，互联网网页内容的爬取和对外围系统提供访问接口。
数据接口可实现对关系型数据库，如Oracle、DB2等的数据交换，包括采集和加载过程，同时也支持文件类型的数据，可以通过FTP等方式进行采集。系统对外提供统一访问接口，具有开放性、高性能、可监控管理和安全性等特征。
数据层
数据层是分布式大数据处理平台，从数据源抽取出所需的数据，经过数据清洗，最终按照预先定义好的数据模型，将数据加载到分布式存储中去。通过分布式计算框架可以实现数据的清洗、转换、校验和装载等过程。
资源层
由于分布式架构带来的硬件部署的复杂度，需要对物理资源层和系统平台层提供进一步的抽象，以提供自动化部署和弹性的运维能力，因此资源层实现了对物理资源的自动部署和动态扩展，对分布式集群中不同角色进行灵活部署。
功能层
功能层实现了数据处理流程模块的模块化处理，提供集群的访问控制，并负责Hadoop集群的运行管理和系统报警日志管理。数据处理能够进行任意串并联的流程调度，并且能够控制节点的优先级、超时时间、重试次数，同时具备路由判断能力，能够在多分支的情况下通过条件进行不同的流程流转。采用异步调度策略，能够支持大并发量的调度。
应用层
负责应用功能的具体算法实现。实现了网页分类索引，通过互联网注册URL及其类别的爬取，对数据进行统一管理，并置于持久化存储中。将其中的类别进行模块化重组，划分至对应的层次结构，如（社交-社区）或（社交-微博），对类别进行索引。实现了词库分类管理，通过对网络热门词汇及常用词汇的爬取，根据所属类别构建分词词库。词库定期更新，不断完善。实现了用户行为统一分析，基于客户的访问行为，识别其偏好特征，根据内容偏好特征进行客户细分，并支持目标客户群提取，以便支撑营销活动，实现了URL地址统一管理。
展示层
负责将应用功能处理结果通过Web页面展示，并且提供交互页面，熟练使用各种应用处理功能，并对处理结果进行动态展示。
网络爬虫
负责从互联网系统中爬取网页的具体内容信息。具体处理流程是一种按照一定的规则，自动抓取万维网信息的程序或者脚本。程序从日志文件中提取URL地址，并进行过滤、去重操作。其中过滤操作去除图片、视频、软件等内容的URL地址；去重会把重复的URL、已经抓取的URL、已经分类的URL地址去掉。剩下的URL地址送入爬虫的地址库中，爬虫会根据一定的规则产生要抓取的URL地址，然后通过MapReduce的方式并发抓取产生的URL地址，最终把抓取到的URL地址的内容存储到HDFS文件系统中。
由于网络爬取流程需要互联网资源支持，数据处理Hadoop集群是和电信运营商内部网络互联，而且Hadoop集群的安全处理措施不够完善，因此，它们之间的访问需要严格控制，以保证网络部署安全。
在物理架构设计上，需要设计两个完整的内部集群网络，集群网络之间需要用防火墙进行访问控制。上网日志处理系统的物理网络部署拓扑如下图所示。四、上网日志系统方案的优势
上网日志系统采用Hadoop技术解决方案的优势有如下几点。
1．Hadoop技术方案是基于分布式基础架构，充分利用分布式两大核心技术——分布式文件系统与分布式计算框架，构建了一整套完整的分布式存储和分布式计算系统。
分布式系统有着高容错性的特点，并且设计用来运行在采用X86架构的普通PC服务器上，大大降低了服务器和存储的成本，以及数据库License的成本，有效缓解了系统扩容带来的高成本压力。
2．Hadoop技术方案采用并行处理大数据集的软件框架。在处理大数据的时候，通过分布式计算将其任务分解并在运行的多个节点中处理。当集群中的服务器出现错误时，整个计算过程并不会终止，同时分布式系统可保障在整个集群中发生故障错误时的数据冗余。这种设计方案可以使网络爬虫、网页分类和上网行为等模型快速、高效运行。
目前在国内，像天云大数据、华为、亚信等多家知名的大企业都针对上网日志处理系统按照上述架构，提出了完整的解决方案。尤其是天云大数据公司，他们依托自主研发的BDP平台软件（包含Hadoop平台的完整解决方案）和公司强大的算法支持团队，已经成功地在某省级运营商运行平台上部署了上网日志处理系统，为该公司的用户精准营销提供了强有力的支撑。作者介绍：方建国，微软三届MVP，某知名房地产公司资讯科技高级主任。多次参与大型实际生产环境的部署及维护，对服务器存储以及虚拟化架构、解决方案（服务器整合、虚拟桌面架构）有深入的研究，尤其是基于Windows虚拟化解决方案。
Hadoop平台在金融银行业的应用架构
薛强彦一、金融银行业现状随着我国金融银行业的发展和网络通信基础设施水平的提高，金融银行业信息化已经逐渐普及，但是随着互联网技术和应用的飞速发展，许多新兴的支付方式不断涌现，金融银行业的数据信息量也在快速增长，相关业务数据量急剧上升，金融银行业即将进入大数据时代。
由于关系型数据库先天性不足，巨大的数据量会对传统的关系型数据库模式带来巨大的压力。因此，目前金融银行业采取的普遍应对策略是：1．增加核心系统的机器性能和存储空间，提高业务数据处理能力；2．备份历史数据，减少核心系统的数据存储量，减轻核心系统的压力，从而提高业务数据处理能力。但是采取以上的策略会导致以下不足：1．增加机器性能和存储空间，直接加大了核心系统运营维护成本；2．大量数据离线存储，导致客户无法快速获得交易信息，降低客户满意度，导致客户流失；3．由于大量数据离线存储，银行企业无法分析全量业务数据，无法正确把握银行业发展方向，从而不利于银行企业竞争和快速发展。二、Hadoop技术的发展现状
Hadoop平台架构是对传统架构的颠覆和革新，它可以实现低成本的海量数据存储，完全支持分布式计算，支持高级数据挖掘算法模型，将大数据的挖掘应用推到了一个新的高度。
Hadoop技术目前已经在互联网行业和电子商务行业得到了广泛的应用，它可以实现海量数据的低成本存储、数据的高效计算和数据分析。目前，阿里巴巴集团采用Hadoop技术实现了淘宝商品数据存储和交易数据动态分析，已经为他们带来了巨大的利润。采用基于Hadoop技术在应对大数据时代的优势十分明显，越来越多的企业会采用这种技术解决他们面临的大数据问题。三、Hadoop技术在金融银行业的应用架构
基于Hadoop技术的特点，可以用它来存储银行业的离线数据，并开发相应的算法对这些数据进行挖掘分析，提高银行企业对历史数据的利用价值。
目前，银行企业的业务基本逻辑架构由外围系统、前置业务系统和核心业务系统组成，如下图所示。
外围系统：负责直接与客户进行交互，提供业务服务，所有与银行业务相关的系统，均可以归为外围系统。
前置业务系统：业务交易数据的跳转，它负责接收来自外围系统的交易数据，然后根据交易码的不同，转送不同的核心系统进行处理，同时把从核心系统返回的处理结果返回到外围系统。
核心业务系统：负责处理所有交易业务的具体实现。
银行企业使用Hadoop平台技术的基本思路是：保持原来系统架构不变；在核心系统层，增加Hadoop平台系统，实现核心系统的历史数据存储备份；对外提供数据查询功能；还可以根据数据存储特点，提供数据挖掘处理功能。
增加Hadoop平台系统后，银行业务基本逻辑架构如下图所示。
外围系统：不发生不化。
前置业务系统：根据不同的业务代码，将外围系统的某些查询业务转送到Hadoop平台系统中进行处理，然后将处理结果返回到外围系统。
核心业务系统：定时备份需要的核心数据到Hadoop平台系统中，以实现某些查询业务需求。
Hadoop平台系统：根据业务需求，利用从核心系统导入的历史数据，对业务交易进行处理，并将处理结果，通过前置业务系统，返回到外围系统，也可以将处理结果返回到核心系统的数据仓库，以供某些报表功能展示需要。
Hadoop平台系统为了满足金融领域服务需求，系统内部架构采用MVC的模式进行设计。首先系统上层，通过接口模块和展示模块，从外部系统获取资源，然后将处理后的结果通过展示模块进行展示。系统中间处理层，会针对不同的业务需求提供不同的业务处理功能模块，对数据进行加工处理和数据算法挖掘，以便生成满足需求的各种数据。系统底层，利用Hadoop平台系统，进行数据大规模存储，提供HBase数据库，进行非结构化的数据存储。
通常采用的功能模块结构如下图所示。
每个功能模块的具体说明如下。
源数据模块
主要功能是为系统提供加工处理的源数据。在金融银行业中，这些源数据是他们的核心业务数据。
接口模块
主要功能是针对不同的数据源和数据格式，提供对应的数据导入处理方法。
功能应用模块
主要功能是根据业务处理需要和系统运行需要提供对应的功能处理模块，功能应用模块中包含数据挖掘算法、业务处理流程等。
数据模块
主要功能是提供HBase数据库，对非结构化数据进行统一存放管理，提供HDFS文件系统，提供数据多副本备份存储管理。
展示模块
对处理后的结果进行Web页面展示，同时还要根据原有系统的需求，提供不同的数据展示处理方式。
金融银行业对数据存储安全要求非常高，因此系统必须设计异地容灾备份存储。应将Hadoop平台系统软件在不同的机房集群中进行部署，系统采用主备集群的模式进行部署，通常采用的物理部署结构如下图所示。四、Hadoop技术的架构优势
将上述架构方案引进金融银行业中，将充分利用以下优势。
1．充分利用Hadoop平台技术的存储优势。Hadoop平台可以提供PB级的数据存储，可以把银行业务产生的所有业务数据都存储到Hadoop平台系统中，实现海量数据存储。
2．充分利用Hadoop平台技术海量数据快速搜索功能。百万亿条记录，毫秒级搜索结果，可以为用户实时提供任何交易时间的交易数据，提高了客户的满意度，实现了以客户为中心，提高了银行的竞争力。
3．充分利用了Hadoop平台技术的数据挖掘功能。可以根据业务需求，编写数据挖掘算法，利用交易数据，快速定位企业非法洗钱的交易记录，为监管帮忙，提供了有力的技术支撑。
4．利用Hadoop平台系统，承担了核心系统某些消耗性交易（例如：账号历史数据打印查询功能的交易），让核心系统更好地处理实时交易业务，充分发挥传统数据库的优势，做到优势互补，从而保证金融银行业IT信息系统的持续健康发展。
目前，天云大数据公司，已经将上述架构解决方案成功应用到某银行的历史数据查询系统中，实现了该银行所有账号的交易历史记录毫秒级响应查询结果。因此，Hadoop平台技术必将对金融银行业应对大数据时代的到来提供强有力的技术保证。作者介绍：薛强彦，计算机专业硕士，长期从事存储软件、大数据相关技术的开发工作，有多个电信运营商、金融行业的大数据解决方案架构师经验及项目管理经验。目前在云基地——天云大数据担任项目经理及架构师。
优酷土豆Hadoop平台开放之路
傅杰背景早在2011年之前，只有优酷网数据团队在使用Hadoop。两年间随着Hadoop技术的推广以及大数据的影响，越来越多的领域都在使用Hadoop，公司的其他团队也在逐步引入Hadoop技术。2012年3月12日，优酷土豆宣布合并，这个新闻足以让业界沸腾。随之而来的需要我们对两个视频网站的数据进行整合、业务进行整合。在整合之前，两边各自拥有一个比较大的Hadoop集群。为了更好地支撑业务合并，以及对其他团队大数据存储与技术的支持，我们需要将两个Hadoop集群合二为一，构建一个开放且安全的Hadoop统一平台。搭建开放平台
所谓开放，就是能够开放给公司任何有需要数据平台的其他职能团队，这其中包括技术团队与非技术团队。开放即共享Hadoop集群：HDFS上存有各种数据，有公用的，有机密的，不同的用户可以访问不同的数据。这意味着平台用户随时可能进行一些破坏平台的动作（包含恶意及非恶意）。所以我们首先要保证平台的安全性及健壮性。拓扑架构
大家在初接触Hadoop时，不管是学习还是生产应用，不可避免地需要搭建Hadoop。下图为一个比较安全的Hadoop集群的拓扑结构图。
NameNode与JobTracker分开部署，SecondNameNode也独立于NameNode部署，此外，SecondNameNode还充当了备用机的角色，当JobTracker或者NameNode出现故障时可以快速恢复服务。用户对集群的操作只能通过平台提供的客户端机器来执行，用户不能直接访问集群中的任何一个节点，这样在运营管理上我们只需要关注几个关键的节点。此外，随着开放的用户越来越多，为了方便后续的扩展，我们将分配多个客户端机器，将不同的团队分配到不同的客户端机器上，同时也起到备用的作用。
为了充分利用资源，我们按照各个团队使用的情况分配相应的客户机，这会出现某个客户机有多个团队共同使用的情况。由于每个人的习惯不同，很可能出现某个用户的操作使得整个客户端宕机。所以在构建客户端的初期就需要制定严格的规范，哪些目录供生产使用、哪些目录供测试使用以及对每个用户团队实行配合管理。当然还需要对机器资源进行监控，防止用户在客户机上提交非相关的程序。前期规范好可以减少很多后期维护成本。安全架构
任何系统要实现开放都要先解决安全问题。我们知道大部分团队引入Hadoop都是因为它的存储能力以及分布式计算能力，至少在早期并不会考虑太多安全问题。但是Hadoop确实存在一些安全问题。比如身份认证问题、用户权限问题、Web界面访问控制问题等。
Linux终端的随意连接
Hadoop集群默认并没对连接其服务的Linux终端做身份认证，所以只要知道服务地址就可以访问资源。假设用户A通过另一台未知的Linux终端连接到我们的集群，并且该用户拥有这个终端的root账户，那么该用户就可以通过这个终端操作HDFS的所有资源，这对开放数据平台来说是极度不安全的。
非法应用的连接
一般我们会开发一些应用连接Hadoop的HDFS服务，比如日志采集系统将外部的业务系统采集过来的日志直接上传到HDFS上。在之前的数据平台中并没对第三方应用做身份认证，任何APP只要知道其服务地址就可以往HDFS上存储数据、修改数据，这样对现有的数据是极其不安全的。同时还可以开发一些私有的应用程序用来过度消耗数据平台的计算资源，导致日常的业务计算得不到足够的计算资源从而影响正常的业务报表。
用户身份的冒充
在我们提交MapReduce作业时，只要将user.name的属性设置成你期望伪造的身份，就可以冒充该身份进行作业提交。这将导致其一：A用户冒充B用户提交作业，访问本来A用户并没有权限访问的数据，其二：在平台做成本估算报表时会将A消耗的计算资源都算到B用户身上，这样导致估算的结果不准确。
slave节点随意添加
Hadoop的两个主要部分HDFS和MapReduce都是master/slave结构的，所以在master节点确定以后，slave节点在之前的集群是可以随意添加到master中的，这样一些不可靠的slave添加有可能导致数据的丢失以及作业的失败。假设我们每一份文件都是三个备份存储，随后被其他用户添加几个未知的slave节点到集群中，恰好某个文件的三个备份都存储在这新添加的slave节点上，之后如果非法用户恶意将这些节点同时下架，那么将导致这个文件的丢失。此外，在MapReduce框架中我们设置了某个task尝试4次如果不成功则将被视为失败，如果新添加的这些slave节点环境配置以及扩展包配置与集群中的其他节点不一致，很可能导致task的多次失败最终将导致作业的失败。
引入Kerberos
Hadoop在1.0以后的版本中支持了Kerberos，我们将Kerberos安全认证开启，上述描述的相关问题都能得到解决。下图所示为Kerberos的主体结构图，包括Identity Store和KDC两部分。其中Identity Store主要包含身份认证信息，KDC为密钥分发服务器。引入Kerberos后，新增用户、新增节点需要在Kerberos上分配相应的身份信息。我们通过自动化脚本可以一键解决。
用户请求服务的时候需要先从KDC分发Ticket，这样KDC存在一个单点故障问题。引入一个新的系统，多了一个环节必然会带来一些新的问题。我们配置了主从KDC服务，同时利用脚本实时同步主从库的认证信息，这样大大增强了Kerberos的可靠性。
用户组信息控制
HDFS文件系统设计模拟了Linux文件系统，所以HDFS文件属性的设计也遵从Linux文件。每个文件拥有读、写、执行三种操作，每个文件只能归属于一个所有者，归属于一个组，每个文件都定义了所有者和组用户的权限。这样三种不同的身份对三个不同的操作进行排列组合，即一共拥有9种不同的配置策略。这样的设计比较简单，但是其权限分配却不够灵活。
我们发现，Hadoop若要对文件实现灵活的权限控制需要设置组用户的权限。而Hadoop本身并没有存储用户的权限信息，而是在进行用户权限判断的时候通过调用一个接口来获取Linux客户端的用户组信息，也就是说，如果客户端用户的组信息与HDFS上的权限信息不匹配，那么程序就会报错。
此外，如果组信息依赖于客户端机器的话也很容易使用户的组信息被造假。此外，连接到数据平台的客户端机器数量较多，如果需要在多个客户机上维护一些相同的用户组信息，那么会导致用户组信息的数据不一致。
若想对某个用户的组信息进行更改，需要先知道哪几台客户端机器拥有这个用户的登录信息，然后分别需要在这些机器上将客户端的组信息全部更改。这样在操作管理上极为不方便，有时候一些用户的权限信息更改比较频繁而且又比较迫切，这样就会为难管理员。
综上分析，我们发现Hadoop默认Linux客户端的组信息存在以下几个不足之处：
1．任何客户端的不安全都会破坏集群的安全。
2．客户端机器众多，映射关系数据的一致性比较困难。
3．复杂的权限资源配置需求无法得到满足。
4．管理极其不方便。
鉴于上面分析的结果，我们将Hadoop读取用户组信息的接口进行重写，将信息持久化到一个独立的关系数据库中。如下图所示，将hadoop.security.group.mapping配置为自己实现的一个类，使得Hadoop是通过MySQL数据库获取用户的组信息，这样所有用户的组信息都集中在一个地方进行管理。另外，我们开发了一个DPM工具，用于修改MySQL中的用户组信息，这样如果用户需要访问一个新的资源，管理员只需要通过DPM工具就可以轻松授权。
Web UI访问控制
Hadoop默认提供两个Web界面（50030和50070）用来供用户查询信息。默认这两个界面并未对用户身份进行认证，任何用户都可以访问HDFS上的数据，这对一些私有数据的安全性是没有保证的。此外，用户可以看到所有作业运行信息以及相关配置信息，有时我们会将一些数据库配置的账号密码加载到配置文件中，这样通过Web界面暴露出来，会带来一些其他安全问题。
针对这个问题，我们修改了Hadoop默认的Serverlet过滤器，用户第一次访问Web UI界面会自动跳转到一个登录界面，要求用户输入用户名和密码，该用户名和密码在注册时由用户自行设定，管理员进行审核。用户登录认证通过则会生成一个访问token并存储到cookie中，下次访问时无须登录。此外，用户的token与用户的身份也是绑定的，用户只能访问其有权限的数据，这样就可以实现对Web UI的访问控制。
安全架构图
下图所示为整体安全架构图，其中管理员通过DPM工具可以操作Kerberos、用户信息、Linux客户端，其中用户信息存储在MySQL数据库中。Hadoop通过MySQL数据库中的用户组信息对用户的请求进行权限判断，管理员修改用户信息5分钟后就可以生效到Hadoop系统中。DPM还提供用户注册、管理员审核、报警等功能。平台运营
解决了安全问题只能说Hadoop平台开放出去了，完成这个阶段只是起步，代表平台处于一个可用的状态。当然我们期望的结果不仅仅是能开放而是要开放好。如何才能运营好一个Hadoop平台，技术往往占很少的一部分，还需要从很多方面进行规范和监控。
规范
每个用户的使用习惯不一样，每个用户的操作水平不一样，如果没有统一的规范会使平台不好用，会增加用户之间的沟通成本，会提高管理员的维护成本。Hadoop主要提供了两个服务：存储与计算，我们需要制定存储规范和计算规范。HDFS是一个文件系统，从根目录开始制定每一级的目录以及相应的业务含义，从用户角度来看，我们在根目录创建了一个user和work目录，其中user为用户的私人空间，设置一定配额，供用户存储个人数据；work目录为团队目录，配额比较大，用于存储团队业务信息，线上的业务信息不允许放置在user下。当然还有其他目录，如：/tmp、/common、/tmp、/warehouse等，具体要根据每个公司的业务而定。当然我们还设置了命名规范，所有的目录都用小写字母命名等。规范保证了随着时间的推移，平台依旧像刚部署时一样。规范的制定不求一次到位，可以在实践中不断完善。
流程
用户注册新账户需要流程，这样会促使用户先熟悉平台规范，同时在一进入平台就养成良好的习惯。用户申请权限需要流程，保证数据访问的安全。平台发布新特性需要走升级流程。流程减少了管理人员与用户的不必要沟通。流程的制定需要把握合适的度，不能多余烦琐，把握住关键的点就好。流程一旦推行，一定要坚持，这样才能保证后续新流程的顺利执行。流程实施的情况在某种程度上可以反映平台的运营情况。
监控
所谓监控就是在事故发生前发现前兆，采取措施避免造成损失，或者将损失最小化。监控实际上也是对现有服务的分析，可以通过监控的结果指导集群参数调优。
节点健康监控
编写脚本监控各节点是否存活，以及相应的报警措施，以免大批量的节点宕机未及时发现，造成损失。特别是SecondNameNode存活状况的检查。
磁盘使用监控
需要监控每个节点的每个磁盘的具体使用情况，并对磁盘使用做配额限制，及时报警。
异常分析
对NameNode、DataNode的日志中的异常定期进行分析，分析到最后几乎没有不熟悉的异常信息。
用户存储配额监控
对用户的HDFS配额进行监控，提醒用户及时清理过期数据。
队列监控
监控队列的实时调度信息，每个作业的等待信息，以及Mapslot和ReduceSlot的消耗比，以此来调整队列的参数，以及MapSlot与ReduceSlot数。
历史作业分析
分析历史作业运行情况，核算每个团队消耗的计算资源，根据历史作业对集群参数进行调整。总结
平台开放至今大大小小的问题也遇到不少，每一次问题的出现都会促使我们思考是否需要修改流程、是否需要添加规范、需要要新增监控点。从最初的1个团队在使用平台，目前全集团已经有20多个团队在使用，超过100多个注册用户，每天提交作业数超过7000，平台运营至今一共运行的作业数超过200万。目前平台运营比较稳定，每周只需投入1个人日进行日常维护即可。作者介绍：傅杰，优酷土豆数据平台架构师，新浪微博：cloudfire。
第2篇 推荐系统架构
腾讯个性化精准推荐平台架构
洪坤乾腾讯个性化精准推荐平台架构是一个非常复杂的体系，本文将更多地关注平台架构以及我们要解决的业务问题。一、关于推荐
我们先看一下第一个场景，经常坐火车的人应该会比较熟悉，在列车上叫卖水果、水等，他们也是在做推荐。用学术界的词来看，这种推荐是热度推荐，因为他不会随便乱卖东西，他不会卖苹果手机、单反相机，卖的只是常用的东西，因为在这样的场景下，这些东西是最受欢迎的。实际上在很多做推荐的网站上也可以看到这样的场景，比如有的网站，今天下雨了它就卖雨伞，情人节了就卖花，冬天到了就卖羽绒服，典型的热度推荐。这种推荐有什么特点：第一点是简单易行，但是它的不足就是盲目，效果不好，没有考虑到每个人不同的需求。
第二个场景，这是公司内部发生的一件真实的事件。上半年时，有一位腾讯女员工在公司内部的论坛上发表了一篇文章，引起了激烈讨论。内容大概是说她昨晚跟朋友用QQ聊天，讲到她今天吃了一碗木瓜汤，然后QQ的旁边就弹出了丰胸的广告，她认为一定是扫描了她的聊天记录。这件事情当时在论坛上引起非常大的反响，因为这件事情太敏感了，涉及扫描用户聊天记录（必须强调，公司绝不会扫描用户的聊天记录）。但是当时论坛上对于这件事情有两种完全不同的观点，一种是比较赞成并且同情她的遭遇，另外一种观点认为这个是很正常的。扫描聊天记录这个事情要看怎么看，如果是被人看了就属于泄露隐私，但是如果是被机器看了不算泄露隐私，并且他们还举出了例子：比如说Google的邮箱在邮件中推广告，并且会很明确地告诉你之所以给你推这个广告是基于你邮件里的内容，还有的认为这件事情不但跟隐私没有关系，反倒很自豪，认为这是一个很好的商业模式，实时性非常好。这件事情当时的影响真的非常大，后来还专门去跟当事人沟通过，首先没有人扫描过聊天记录，然后她也比较认同最后的解释，她之前确实也有过一些电商的购买行为，所以才会出来这样的广告，其实跟她说木瓜没有关系。撇开那些非技术的因素，单从纯技术的角度来看，如果我们真的知道用户当时的一些需求我们再有针对性地给他做一些推荐，效果会更好，这种叫作个性化实时推荐，这在腾讯的推荐里面实际上也会做这样的事情。现在在QQ空间相册中上传一张相片，我们基本上能看到你这张照片是用什么相机拍的，就可以大概分析出你的收入水平，就能有针对性地推荐一些东西，这种效果会比较好，因为考虑到了用户的实时因素，但是系统会非常复杂。二、腾讯精准推荐发展历程
通过这种发展历程我们能看到我们的架构为什么这样做。很久之前在网上看到一句话我非常认同：架构不是设计出来的，架构是进化出来的。这个故事很长，腾讯真正开始做跟精准推荐相关的工作是在2009年。2009年当时的背景是，雅虎的一个人来到了腾讯，然后他成功地说服了高层，让我们来做一件事情，使剩余流量变现，所以从那时候真正开始做精准推荐，这是当初高层说要做精准推荐的时候团队很快拿出来的第一代架构，如下图所示。
这其中其实真正需要做的内容不是很多，第一个是广告投放系统，然后是文件传输，也不需要去写什么样的系统，然后是下面的分布式计算平台，基本上也是现成的，然后就是实时查询引擎，这是真正需要去搭建的。这代架构的特点是，所有的数据是以离线的方式传输过来，然后在分布式计算中批量暴力计算。一个特点是实时匹配查询，也就是说把所有预测的结果在这里面全部算好了，算好了以后把结果放进来，然后当前端有需求的时候就直接能查询到。实际上只有查询引擎是当初新推的，其他的相对工作量比较小。如下图所示，这个系统当时做出来以后大家都觉得很自豪。
这个系统用到了当时非常时髦的云计算，2009年时，云计算这个概念炒得很火，并且用到了很时髦的数据挖掘，当时的流量不算太大，但是也有十亿。每天十亿的推荐流量，由IDC部署，我记得全国当时只有5个IDC，这个不是重点，重点是这样做了之后比原来提升了大概150％的效果，当时大家都挺自豪的，但是在光环之下就看不到“阴暗”的东西了。
这个架构其实有非常不合理的地方：第一就是系统高度耦合，从产生数据到使用数据基本上是一条线耦合到一起，就是比如说产品有10个节点，那我就把数据分成10份，这种方式基本上是耦合在一起了。第二因为是离线的文件传输，所以延迟很厉害，整个过程下来大概延迟2小时，2小时之后我们经常发现算上去的东西预测的广告都已经下线了。第三是一些不可控的因素，因为我的数据要从深圳发到全国各地，当时这个系统还没挣多少钱，而且数据量很大也不太敢走公司的内网，所以没办法只能走公网，结果就会有很多问题。天津的机房是联通的，上海的机房是电信的，非常痛苦，但是尽管如此，大家还是沉浸在第一代架构的喜悦中，因为毕竟还是正面的东西多。记得当时公司运营的同事，晚上基本两小时起来一次，要么是死机，要么是文件传输的问题，后来开发的人都已经很过意不去了，但还是没办法。
2010年8月，腾讯收购了康盛创想，这件事对很多人来说是一件好事，但是工程师们看了这个消息就哭了。我们在第一代架构中，刚才讲到了暴力法，来看它是怎么个暴力法。我们当年的做法是：那时候有6亿用户，当时广告位比较少，只有50个广告位，有500个广告，然后就计算这6亿用户对50个广告位上的500个广告，每一个可能点击的概率，就是算这些东西。但是收购了康盛创想之后，我们预计量级会达到10亿用户，10万个广告位和10万个广告，意味着计算量会增大60万倍，所以意味着原来那种暴力的办法没法完成了，基本上是不可能的事情。可能对做搜索广告的人来讲，这种10万乘10万的量级不算什么，但是真正在精准广告中，因为要考虑到用户的力度，所以这样的量级是比较大的。另外一个就是，搜索广告有一个优势就是用户会带着非常明确的主观性，因为搜索关键词，然后再跟广告匹配，但在这里面就没有。你要去猜他要干什么，所以必须得重构，当时重构的时候考虑到以下几点：第一点是，真正彻底让我们崩溃的就是计算量太大了，所以我们要想办法怎样让计算量更少，实际上我们现在的做法是把所有用户在所有广告位上所有的广告全部批量算一遍，但是实际上最后用户真正来的肯定到不了这么多位置。也就是说，这里面有大量的计算是浪费的，但是你怎么去区分这些计算哪些是浪费的，哪些是不浪费的。第二点是，第一代架构可以使效果提升150％但是能不能更高，之前我们的数据是两小时的延迟，怎样能更快一点，这也是当时想的一个问题。第三点是一些遗留问题。主要是这三个问题，把这三个问题列出来之后发现只有一条路就是实时，实时的意思是说，如果实现了实时，就不用去批量暴力计算，就能减少计算量，使准确度更高，也可以解决遗留的问题，这是从2010年年底决定重构到2011年年中大概明确的技术方案，然后确定了一些细节，到2011年年底完成了第一个版本的上线。
一直到2012年年初，基本上是大规模应用，然后做了一些优化调整，一直到现在，这就是2010年拿出来的第二代架构，如下图所示。
跟之前不同的地方在于，原来的离线文件传输现在变成了实时接入，分布式计算平台还是以前的，数据实时接入之后引入了流式计算的技术。计算完后计算结果会落到一个分布式的cache中，当有用户实时请求时，用推荐引擎去访问这些数据，然后调用相应的预测算法来预测这个用户可能会对哪些广告感兴趣。这个架构与之前第一代的明显的区别在于所有的东西都实时化了。好处也是很明显的，第一是秒级延迟，用户在电商网站上浏览了哪些物品，然后有没有放入购物车，这些信息都是秒级传过来。最重要的一点是低耦合，数据的产生者跟数据的消费者通过一个分布式cache解耦开了，这样就解决了上一代没法扩容的问题，所以这样扩展性和可运营性就会非常好，但是从我们拿出这套架构一直到现在这几年，我们一直都在被它的先天不足所折磨。
2013年本质上也一直是这样的架构，但是做了一些局部的优化调整，一个是业务支撑，从原来大概每天十亿的流量到现在的百亿级，我们的设计目标是能达到每天三百亿的支撑，另外就是业务种类从原来的1个到现在的10个。比如广告推荐、视频推荐、电商推荐甚至还有一些QQ秀或者APP的推荐。然后在平台方面做了一些优化，第一个是分布式cache系统全面优化；第二个是用Storm替换了S4，主要考虑到业务种类越来越多，Storm在支撑多业务时比S4要方便很多；第三个是做了一些平台级组件抽象，最重要的是效果提升，在原来的基础上推荐效果进一步提升30％以上，这就是腾讯精准推荐历程，其实一直到现在这套架构本质上还是当初设计的那一套。三、系统架构及实现
接下来给大家详细介绍一下这套架构，这是最终的加强型第二代架构，如下图所示。
这是2013年平台优化之后的架构，上面讲的一个平台的优化就在这里面。我们把实时接入、实时计算和分布式存储给抽象出来了，抽象成实时计算平台，然后跟下面的离线计算平台相对应，所以现在的架构就是实时计算加离线计算并存的模式。然后推荐引擎作为实时计算平台的一个应用方，这里面多了一个运营平台，当规模达到一定程度以后，传统的运营方式基本上没法做了，比如说每天几百亿的请求量，然后这些请求里有多少是成功的多少是失败的，为什么会是失败的？在哪一个环节失败的？这些东西如果想实时知道的话，传统的方式基本上是做不到的，所以这些系统内部的运行情况也会实时反馈到实时计算平台，由实时计算平台来做实时分析。
接下来为大家展示几个数据：第一个是300亿，是这套架构的设计支撑能力，也就是每天支撑的推荐请求量；第二个是15000亿，是流式计算平台每天支撑的多维度交叉计算量，其实就是300亿乘以50；第三个数据是70万，是推荐引擎每秒钟支撑的请求量；第四个是7000万，因为每个推荐请求不止算一个广告，一个推荐请求里面有100个候选广告，也就是每秒处理70万个推荐请求，每个请求里会计算100个广告，所以每秒整个推荐引擎是需要计算7000万的广告预测，这些全部是实时的，然后根据不同的人，不同的算法去做实时预测；第五个是21亿，这是分布式cache理论上要承担的访问量，我们看到推荐引擎每秒钟会产生7000万的实时预测量，但是计算每一个广告平均下来需要访问30种不同的数据，比如用户和广告的交叉，用户和广告位的交叉，广告和广告位的交叉，这些数据平均下来一个广告算法基本上需要使用30种不同的数据，30种是以前，现在最新的算法应该已经有60多种了，所以按这样算下来推荐引擎每秒钟需要访问的数据量是21亿。
下面来看一下常见的实时系统的一些架构设计，下图所示为最简单的。有一个业务Server，我需要访问数据，需要访问数据库。
当请求量很小的时候就是这种方式，请求量再大一点的时候可能需要做一个数据库集群。很多人可能都在做这样的事情，当你的压力更大数据库受不了的时候，常见的解决办法就是架一个cache。当你的压力更大的时候就再加一个cache，形成一个cache集群，然后再对应到我们的数据，这就是整个平台所面临的挑战，就是分布式cache系统要承担每秒21亿的访问压力，推荐引擎要承担每秒7000万的计算量。如果按每台机器承担40万算的话大概需要多少台机器呢？五万或五千台机器，基本上是不可能的，所以这套看起来很漂亮的架构背后是具有先天不足的。接下来介绍我们是怎么处理这些问题的。分四个部分：一是实时接入这部分相对来说不会太大，主要的作用就是一个管道的作用，然后把不同业务的数据实时接入进来，接入进来会分发给实时计算平台（参见下图）。
二是进行流式计算，最大的特点是它需要支持秒级滑动窗口，这是我们在技术方面做的。流式计算这部分真正有意思的不是它的平台架构，如下图所示。它的业务特点、业务场景，如果这个场景是更多的类似于流式计算统计类的话，第二个场景会更有意思。
第三个是存储引擎，我们刚才讲过这里是做过优化的，之前的做法是完全的主备，最后导致一部分机器浪费，且扩容没法做。虽然设计的时候是要做到易扩容，但真正扩容的时候没法做，所以后来我们把它改进了，这是一个多线的流程。就是说，写的话就写入主机，然后主机会同步到备机上去，然后读的话也是读主机，但是不一样的地方就在于，每个机器都会被访问，如下图所示。
第四是推荐引擎。推荐引擎的架构分为几层：第一层是接入，第二层是分法计算，第三层是真正做计算，所有的算法都在这里进行，这里最重要的问题是事务很重。前面说到每个广告要访问30次数据，导致压力非常大，而且用到的算法需要用到的数据量也非常大，解决办法就是在这一层再加一层cache。就是说，cache的cache，这样极大地减少了对底层的压力，这样的解决办法看起来也很漂亮。但是因为这套架构引入的这些不足，所以即使用了这样的解决方案，最后会发现也只是在缓解问题，并没有真正解决问题。加一层cache之后，底层压力会小很多，但是会有一个新的问题，就是一旦这个cache失效了，底下的这一层就瞬间被打死了，这种情况会对底层造成非常大的压力。架构如下图所示。四、整个推荐的一些体系
做精准推荐有三个固有的挑战：第一个是海量，海量的用户、数据和行为；第二个是实时；第三个是精准。广告的特点第一是可能有的广告80％的用户最近三个月是从来不点广告的，怎么样让这些用户去点广告；第二个就是用户体验；第三个是业界口碑。这是我们基于数据＋算法＋系统的设计理念，为业务提供全流程数据驱动的海量、实时、精准的个性化推荐服务。
腾讯的数据体系基本上覆盖了互联网几乎所有的产品，这部分是关于移动分析统计的MTA，MTA可以帮你分析你的移动端的用户画像是什么。下图所示为我们的算法体系，这里展示了你手上有什么样的数据、在什么样的场景下你就用什么样的推荐方法，这是整个腾讯精准推荐的一个历程。
2009年到2010年我们做了第一代架构，当前自认为处于第三代的状态，就是说，到现在我们所有的算法会实时化，计划到明年进入第四代，特点是所有东西全部实时化。我们预计2015年能够进入全面的机器智能时代，明年要做的是怎样让系统更加实时，更加精准，更加通用，更加通用包括怎样支撑更多的业务，以及在移动端的投放，以及怎样对第三方开放。
在不久的将来，我们会想几个问题：第一个问题是纵向进化，你今天的行为会对未来产生什么影响；第二个问题是横向覆盖，你、你的家人和你的朋友喜欢什么，就是推送给你可能你不喜欢但是会买的东西，我们预计2015年之后会开始进入这样的状态，因为我们已经开始在跟学术界做一些这方面的合作。作者介绍：洪坤乾，现任职腾讯公司数据平台部，主要负责腾讯个性化精准推荐平台的系统架构设计；拥有10年以上软件设计开发经验，在分布式系统设计以及海量数据处理方面具有丰富的经验。
社交网络大数据挖掘与社会化推荐引擎的构建
邓雄本文的主要内容是：以人人网为例，阐述在社交网络中进行社会化图谱挖掘（social graph）以及构建社会化推荐引擎的通用原理、算法和实践应用。人人网是中国社交网络的代表，它组织了一个2亿左右注册用户及超过0.5亿左右月登录用户的大型社交图谱。主要内容包括但不限于社交图谱与社会化推荐系统面临的重要挑战，人人网社会化推荐系统架构，人人网社会化推荐主要模型和算法及人人网社会化图谱挖掘的其他进展。大数据挖掘在社交网站中的地位
登录人人网的首页，可以看到与Facebook很相似的页面：左边是一些浏览标签，中间是新鲜事，右边是包括好友推荐在内的一些附加内容和广告，如下图所示。
人人网现在的规模，根据艾瑞的统计来看（参见下图），2011年的时候能达到两亿注册用户，这个数据在目前社交网络中是一个比较大的数据。
在互联网的大数据的环境下，数据挖掘和推荐成为一个主导的技术。在人人网中，和推荐以及挖掘相关的产品和应用大概占到全部的70％，这一点，在Facebook也有基本一致的看法。就以我们刚才看到的页面为列（参见下图），右上角是一个搜索框，搜索的时候会涉及搜索结果的排序问题，这是一个通过大数据分析和挖掘进行排序的应用；页面中间部分的新鲜事排序以及用户关系的建模也会涉及跟推荐或者数据挖掘相关的技术；左边的导航优化也会有一些智能排序，即把什么样的标签排在第一位，什么样的标签排在第二位会更有利于人人网的点击流量的增加和用户体验的提升，这里也会有数据智能分析和个人性偏好挖掘的工作；最右边就比较明显了，主要是好友推荐和广告的展示，都会涉及大数据的挖掘。所以整体来讲，在社交网络中，大数据挖掘或者推荐排序应用占到了70％～80％是非常正常的事情。推荐系统的发展历史
我先讲一下社会化推荐系统这个话题，也是本文的主要话题。先来看看推荐系统的发展历史：“推荐引擎”这个概念大概是20世纪90年代初协同过滤（CF）算法诞生后出现的，这时比较有代表性的是Grouplens这个项目。这之后，推荐技术因为在一些电子商务类型的互联网站中得到较多的应用而产生了实质性的飞跃，比较典型的是在Amazon。Amazon把user-based的CF改进成为item-based，这使得推荐技术可以在更大数据规模上发挥作用，也使得推荐系统被很多人真正了解到。然后，到了2004年，推荐系统变得越来越人性化。个性化的逐步成熟，在Google中体现得比较明显。Google news就是一个非常个性化的产品，而且推荐具有接近实时化需求。到了2009年，我们可以发现，推荐系统中的推荐算法发展到一个多元化的状态。这个时候就有人在提一个看似比较夸张的口号，就是“搜索已死，推荐上位”。这其实是因为在这个时刻，无论学术界还是工业界对于推荐系统已经非常重视并已经在加速发展，而这时的搜索已经处于比较成熟的程度，发展开始放缓。尤其在2010年后，Facebook推出了二度好友推荐算法，这是推荐系统在社会化方面做的一次成功尝试，也标志着社会化推荐系统的诞生。就是说，所推荐的对象不仅仅是像Amazon上面的一些商品，而是更复杂的、规模更大的、网状结构的好友关系或者叫社交关系。同时，包括我们目前经常会用到的大数据处理平台包括Hadoop、HBase等的开始广泛普及，也对推荐系统向社会化推荐方向发展起到了重要的基础和催化作用。社会化推荐系统的特质
社会化推荐系统区别于一般推荐系统的特质是什么呢？首先，推荐系统产生的背景就是大数据，大数据对我们真正的挑战就是信息过载，而在社交网络中，大数据的挑战第一次开始真正体现出来。我们可以看到，在一分钟内互联网产生的信息是非常惊人的，不可能被一个人或者一群人全部接受，比如：在Youtube，一分钟内会产生大概48小时的新视频；在Twitter，会产生10万多条Tweet。那么我们怎样才能从这海量级的数据中找到一个人或者一个群体感兴趣或者更相关的内容，就成了一个非常复杂的问题。所以有人在说，我们已经从一个信息时代转化为一个推荐时代。推荐系统就将在这种背景下产生，这些推荐系统也是非常多元化的，比如日志推荐、视频推荐、好友推荐、音乐推荐、应用推荐等，也有很多公司在做这个事情，比如Amazon、Google、Facebook、Apple等。而在社会化推荐系统中有一个更重要的特性就是，信息是非常多样化和网状化的。例如在Facebook、微博、人人网，我们看见的实体对象是非常异构的，有广告、新鲜事、照片、视频、音乐、日志等，这些实体对象又都和社交网络中的主要实体——人——相互联结起来，这样就形成了一个非常复杂的、异构的、网状的大数据（参见下图）。这也是社会化推荐系统区别于一般推荐系统最大的特征和面临的最不同且更艰巨的挑战之一。
社会化推荐系统区别于一般推荐系统的第二个特征是数据的社交属性，即所谓的社交图谱。这个图谱实际上就是指人与人通过社交关系包括诸如好友关系、关注关系等联结起来形成的拓扑结构，这种数据往往具有传递性或者相互影响的特性（参见下图）。例如，二度好友这个推荐算法就假设在社交图谱中，我和我好友的好友可能也存在好友关系。
第三个特征是信息的流动性。即在社交图谱中传播的信息是一些流动的信息，通过人到另外一个人，再到更多的人。这个信息流在社交网络中是加速成长的，也就是说，通过你传播之后就有可能下一个看到这信息的用户也会转发传播，这个过程中就会产生很多噪声。比如说一个话题，通过一些关键节点转发后会形成一个多叉树甚至网状的传播结构图，如下图所示。社会化推荐系统在社交网站中的应用场景
社会化推荐系统有哪些具体的应用呢？在人人网上具体的数据化推荐应用有很多地方，比如说好友推荐、人人头条、视频、照片、小组以及小组中间的人，为什么会有这么多不同推荐的表现以及应用场景，其实就是社会化推荐的信息是非常异构的，就是有很多类型的数据结构。社会化推荐系统架构
设计社会化推荐引擎的时候不能简单地看成是满足几个孤立的推荐需求或者解决几种孤立的数据上的推荐问题。基于这些业务场景，我们目前有一个完善的社会化推荐引擎架构。这个引擎分为5个层次，最下边是数据中心，存储原始数据；之上是社交图谱层，是基于原始数据抽取的一些中间的基于内容和基于用户关系的数据；再往上是算法层或者算法库；第四层是推荐架构层，是一个处理线上推荐请求的核心逻辑层，也是一个实时的处理模块；第五层是业务逻辑层，负责整合不同的推荐业务。这样就形成了一个结合线上和线下的架构。社会化推荐引擎
好友推荐模型库：挑战
下面，重点讲一下社交图谱中好友推荐的一些算法。好友推荐算法推荐的实体是好友关系，即人与人之间的双向联系。这不同于Amazon的商品，也不同于微博的单向关注关系，所以好友推荐的挑战之一，就是它需要考虑一个两步的好友关联的建立：A推荐给B，希望B能最大限度地认可这个推荐结果，并申请添加A为好友，这只是第一步；A选择是否接受B的好友申请而决定这对好友关系是否能最终建立，这是第二步。数据统计显示，这两步都会有实质的效果损失。第一步和第二步的成功率分别大概是千分之几和十分之几。好友推荐的第二个挑战是提升推荐效果。首先，在社交网络中，有很多地方都有好友推荐的位置，在不同推荐位置展现不同的内容，尽量减少推荐冗余是好友推荐需要考虑的重要问题，因为如果推荐内容没有大的差别，用户在浏览过程中会被反复推荐同样的好友，推荐效果自然会很差。
好友推荐模型库：关键算法
下面介绍几个比较有代表性的好友推荐模型或者算法。第一个就是friends of friends算法。这是Facebook比较出名的一个标志运算，这个算法的原理是将我朋友的朋友推荐给我，即推荐二度好友。算法的难点在哪里呢？第一个难点在于如何选择最相关二度好友。比如说，如果平均好友个数是100，那么平均二度好友就是10000，一般推荐位只能展示几个好友推荐结果，这时候需要权衡如何展示最重要的二度好友。我们有一个相关的排序算法来解决这个问题，大概涉及建立朋友时间、朋友间交互行为和资料相似度，以及共同好友的个数，这些所有的属性构成了一个排序的标准（参见下图）。第二个难点是数据规模，Facebook每天处理这样大的数据量，使用的是非常大的集群实时计算，这个集群的代价是非常大的，在国内目前来说好像很少有这样的集群来做这个实时的处理，所以我们能考虑的就是线下先把这个数据算出来，我们能做的就是让这个数据更新的速度更快，或者增量。
第二个算法是好友簇算法。这个算法的原理是社交网络拓扑结构中存在大量的强关系紧密结构，这个紧密结构有可能就是你的同班同学、同事等，他们不一定都加了你为好友，所以我们可以将这些人推荐给你。这是比较简单的。
第三个算法好友圈演化趋势预估的算法。这个算法所做的事情很简单，就是我们想知道用户建立自己好友的趋势是什么，有些人对于数据挖掘的“大牛”感兴趣，有些人当前加入了一个新公司倾向于新同事好友圈的扩展。大家看一个实际的例子：人人网的某一员工，他在两年内大概增加了700个好友。好友变化的趋势非常明显，他加了很多同事为好友，而且在不同部门之间增加好友也是有趋向性的。做这个算法我们必须搞清楚用户的潜在好友圈有哪些，比如说一个项目组的同事，一个活动中结识的朋友等。需要有一个数据挖掘算法发现用户在不同时间点的朋友圈，然后对比一下两个时间点的朋友圈，就能知道用户好友关系扩散的趋势。
第四个算法主要提升前述第二个步骤的比率，这个算法叫好友接受率模型。这是一个比较典型的数据挖掘模型。数据挖掘的过程也比较典型：通过线下收集接受好友的用户特征，用一个预测模型进行分类预估，放在线上实验以后把它做成一个最终的模型。我们在这里没有用经典的LR模型，而是用到了一个多模型方法。
第五个算法是多图谱融合的推荐算法。这个方法有一个实质性的使用场景，就是在社交网络移动客户端中经常用到的通讯录推荐。有一些用户比较喜欢把她的通讯录上传，而通讯录作为一个关系来说更有价值，这个时候我们就要对通讯录中的好友和社交网络好友关系进行识别和融合。问题的关键有两点：1）我们希望可以实时地将用户的好友推荐过去；2）如何尽可能匹配这两个图谱。做这件事情的时候我们做了一些探索，我们利用传统的搜索来做推荐。此外，除了用传统的手机号来关联之外我们还用了诸如姓名等其他信息进行匹配。社交图谱挖掘的通用路标
下面讲一下我们在其他社会化图谱方面挖掘的一些探索。第一步我们首先关注的是人和人之间点与点的关系，比如除了好友推荐这个任务之外，我们还做了好友间亲密度的建模；再往上一步，我们从点对点的任务上升到对一个群组的探索，即朋友圈相关的任务。典型的任务就是好友圈的自动划分。这个在QQ中做过，而且他们有一些天然优势，但是在人人网上做这个就是一个挑战；再往上一步，社交图谱的构建就到了一定地步，这个时候我们就会关注一些用户或者用户群组的兴趣相关的任务，比如热门话题发现、兴趣相关的内容推荐。社交图谱挖掘的其他一些任务
首先看一下好友亲密度模型。这个模型为什么非常有用呢？它主要可以用在好友排序和UGC排序两方面。比如你有一些当前特别关注的好友，特别喜欢点他们的头像聊天，那么我们就会把他排序到你好友列表的前面，让你更方便地找到他们，不需要再翻页。还有一种就是UGC排序，例如在新鲜事智能排序中，为什么要把某一些新鲜事排列在前面，这些就和好友亲密度有关。做这件事情的时候就是一个大数据比较典型的开发场景，即收集用户的静态资料和从历史信息中提取的用户行为信息进行建模。
第二个就是friend grouping好友圈智能分组。所做的事情就是想理解用户的好友中哪些人可能是结构非常的紧密，属于同一个朋友圈。怎么做呢？我们用了社区划分的基本思想，利用好友关系的密度来计算朋友圈划分。同时，利用一些用户提供的信息，诸如特别关注、黑名单、已有分组等，来进一步优化这个朋友圈的分圈结果。对这个算法的评估，我们搜集了一些用户评价，很多是非常正面的评价，甚至令我们感动。社交图谱和兴趣图谱挖掘全景视图
最后做一个社交图谱挖掘的展望。第一层面是user层面，就是个人层面，在个人层面需要做好友关系推荐，好友圈密度预估，用户影响力衡量模型，搜人排序和用户身份和场景识别等任务。在这个基础上，会有第二个层面，就是考虑Groups，就是群组，即从单个人到多个人。需要做的任务包括，好友圈智能划分、小组小站推荐、聊天群组推荐、LBS推荐等。前面这两个层面可以看作社交图谱挖掘在拓扑结构方面的任务。
第三个层面是相对这个静态结构而言的，叫信息流cascades，这是一个动态的部分。用户通过他们的诸如转发、分享、回复、点赞等行为来彼此传播内容形成信息流。信息流在我们的社交图谱中的流动会带来一些社交图谱挖掘的任务，包括新鲜事的排序、UGC的热点预测。
信息流加上拓扑结构挖掘就是我们所谓的社交图谱挖掘了。
相对社交图谱挖掘，我们还有另一大方面的任务就是兴趣图谱挖掘。相关任务有很多，比如，用户兴趣的发现、UGC的推荐、智能用户召回、广告定向等。
社交图谱挖掘和兴趣图谱挖掘合起来就形成了社交网络大数据挖掘的一个比较完整的任务构成和大体结构（参见下图）。作者介绍：邓雄，2014年后任职58同城总监。英国帝国理工（Imperial College London）数据挖掘博士，长期从事数据挖掘、社交网络、计算广告、搜索等方面的研究和实践工作。现任58同城数据智能与应用部总监，全面开展数据挖掘、数据架构、数据应用、数据安全、数据分析等相关工作。加入58之前，他任人人网应用研究中心、人人网清华联合实验室负责人，技术经理，开展社交网络中的大数据挖掘的研究与开发工作，实现了人人网在诸如用户保留与增长、好友推荐及内容推荐等业务指标的大幅提升。他曾就职于百度，主要从事搜索广告研发。近两年获得数据挖掘相关专利10余项，并已在产品中实际应用。新浪微博：@邓雄John。
第3篇 应用架构实践
微博用户兴趣建模系统架构
张俊林在微博环境下，构建微博用户的个人兴趣模型是非常重要的一项工作。首先，从可行性方面而言，微博是一个用户登录后才能正常使用的应用，而且用户登录后会有阅读/发布/关注等多种用户行为数据，所以微博环境是一个构建用户兴趣模型的非常理想的环境，因为围绕某个特定用户可以收集到诸多的个性化信息。另外，从用户兴趣建模的意义来说，如果能够根据用户的各项数据构建精准的个人兴趣模型，那么对于各种个性化的应用比如推荐、精准定位广告系统等都是一种非常有用的精准定位数据源，可以在此基础上构建各种个性化应用。
事实上，新浪微博在两年前已经构建了一套比较完善的用户兴趣建模系统，目前这套系统挖掘出的个人兴趣模型数据已经应用在10多项应用中。对于每个微博用户，通过对用户发布内容以及社交关系挖掘，可以得出很多有益的数据，具体而言，每个微博用户的兴趣描述包含以下三个方面：用户兴趣标签、用户兴趣词和用户兴趣分类。
用户兴趣标签是通过微博用户的社交关系推导出的用户可能感兴趣的语义标签；用户兴趣词是通过对用户发布微博或转发微博等内容属性来挖掘用户潜在兴趣；用户兴趣分类则是在定义好的三级分类体系中，将用户的各种数据映射到分类体系结构中，比如某个用户可能对“体育/娱乐明星”这几个类别有明显兴趣点。以上三种个性化数据，用户兴趣标签和用户兴趣词是细粒度的用户兴趣描述，因为可以具体对应到实体标签一级，而用户兴趣分类则是一种粗粒度的用户兴趣模型。本文主要从体系结构角度来简介用户兴趣词以及用户兴趣分类这两类用户兴趣的挖掘系统架构。一、微博用户兴趣建模系统整体架构
微博用户兴趣建模系统整体架构如下图所示，其由实时系统和离线挖掘系统两个子系统构成。因为每时每刻都有大量微博用户发布新的微博，实时系统需要及时抽取兴趣词和用户兴趣分类，而离线挖掘系统的目的则是优化用户兴趣系统效果。
每当有用户发布新的微博，则这条微博将作为新信息进入实时Feed流队列，为了增加系统快速处理能力，实时系统由多台机器的分布式系统构成。通过Round Robin算法将实时Feed流队列中新发布的微博根据发布者的UID分发到分布式系统的不同机器中。为了保证系统的容错性，由Master主机和Slave机器组成一个机器组，监控系统实时监控机器和服务的运行状态，一旦发现Master机器故障或者服务故障，则实时将服务切换到Slave机器，当故障机器恢复时，监控系统负责将服务切换回Master机器。
离线挖掘系统是构建在Hadoop系统上的，通过MapReduce任务来执行挖掘算法，目标是优化用户兴趣词挖掘效果。二、实时抽取系统
对于实时抽取系统来说，每台服务器可以承载大约1亿用户的用户兴趣挖掘。当用户发布微博后，此信息实时进入原始Feed流队列中，语义处理单元针对每条微博快速进行语义计算，语义处理单元采取多任务结构，依次对微博进行分词、焦点词抽取以及微博分类计算。焦点词抽取与传统的关键词抽取有很大差异，因为微博比较短小，如果采取传统的TF.IDF框架抽取关键词效果并不好，所以我们提出了焦点词抽取的概念，不仅融合传统的TF.IDF等计算机制，也考虑了单词在句中的出现位置、词性、是否是命名实体、是否是标题等十几种特征来精确抽取微博所涉及的主体内容，避免噪声词的出现。微博分类则通过统计分类机制将微博分到内部定义的多级分类体系中。
当微博经过语义处理单元处理后，已经由原始的自然语言方式转换为由焦点词和分类构成的语义表示。每条微博有两个关键的Key：微博ID和用户ID，经过语义处理后，系统实时将微博插入“Feed语义表示Redis数据库”中，每条记录以微博ID为key，value则包含对应的UID以及焦点词向量和分类向量。考虑到每天每个用户可能会发布多条微博，为了能够有效控制“Feed语义表示Redis数据库”数据规模在一定范围，系统会监控“Feed语义表示Redis数据库”大小，当大小超出一定范围时，即将微博数据根据用户ID进行合并进入“User语义表示Redis数据库”。单机实时抽取系统架构如下图所示。
在用户不活跃时段，系统会将“User语义表示Redis数据库”的内容和保存在MySQL中的用户历史兴趣信息进行合并，在合并时会考虑时间衰减因素，将当日微博用户新发表的内容和历史内容进行融合。为了提高系统效率，会设立一个历史信息缓存Redis数据库，首先将部分用户的历史数据读入内存，在内存完成合并后写入MySQL进行数据更新。三、离线挖掘系统
出于精准定位用户兴趣的目的，在实时抽取系统已经通过“焦点词抽取”以及历史合并时采取一些特殊合并策略来优化算法，但是通过实际数据分析发现，有些用户的兴趣词向量还包含不少噪声。主要原因在于：微博用户在发布微博或者转发微博时有很大的随意性，并非每条用户发布的微博都能够表示用户的兴趣，比如用户转发一条“有奖转发”的微博，目的在于希望能够通过转发中奖，所以其微博内容并不能反映用户兴趣所在。为了能够更加精准地从用户发布内容定位用户兴趣词，我们通过对实时系统累积的用户历史兴趣进行离线挖掘来进一步优化系统效果。
离线挖掘的基本逻辑是：微博用户发布的微博有些能够代表个人兴趣，有些不能代表个人兴趣。离线挖掘的基本目标是对实时系统累积的个人兴趣词进行判别，过滤掉不能代表个人兴趣的内容，只保留能够代表个人兴趣的兴趣词。我们假设如果用户具有某个兴趣点，那么他不会只发布一条与此相关的微博，一般会发布多条语义相近的微博，通过是否经常发布这个兴趣类别的微博可以作为过滤依据。比如假设某个用户是苹果产品的忠实用户，那么他可能会经常发布与苹果产品相关内容。
但是问题在于，如何知道两条微博是否语义相近？更具体而言，通过实时抽取系统累积的用户兴趣已经以若干兴趣词的表示方式存在，那么问题就转换成：如何知道两个单词是否语义相近？如何将语义相近的兴趣词进行聚类？如何判别聚类后的兴趣词？哪些可以保留哪些需要过滤？
我们通过图挖掘算法来解决上述问题，将某个用户历史累计的兴趣词构建成一个语义相似图，任意两个单词之间的语义相似性通过计算单词之间的上下文相似性来获得，如果两个单词上下文相似性高于一定值则在图中建立一条边。然后在这个图上运行Pagerank算法来不断迭代给单词节点打分，当迭代结束后，将得分较高的单词保留作为能够表达用户兴趣的兴趣词，而将其他单词作为噪声进行过滤。
下图是兴趣词语义相似图的一个具体示例，通过这张图可以看出，如果用户某个兴趣比较突出，则很容易形成一个连接密集的子图。通过在语义相似图上运行Pagerank算法，语义相近的兴趣词会形成得分互相促进加强的作用，密集子图越大，其相互增强作用越明显，最后得分也会越高，所以通过这种方法可以有效识别噪声和真正的用户兴趣。
在具体实现时，因为每次运算都是在单个用户基础上，记录之间无耦合性，所以非常适合在Hadoop平台下使用MapReduce来分布计算，加快运算效率。四、小结
用户兴趣建模在微博环境下有着非常重要的作用，一个好的用户兴趣建模系统可以有效支持个性化推荐、搜索以及个性化广告推送系统。本文主要从体系结构角度，简单介绍了微博用户兴趣建模分布式体系结构，并介绍了其中比较关键的数据挖掘算法。作者介绍：张俊林，中科院软件所博士，《这就是搜索引擎：核心技术详解》的作者。曾经在阿里巴巴、百度、新浪微博担任资深研究员，前新浪微博数据挖掘技术专家，新浪微博技术委员会成员（负责算法策略方向）。主要研发方向：搜索技术、自然语言处理、社交挖掘、推荐系统。
针对移动互联网应用的网络建设和优化
李永斌本文主要分享小米公司在移动互联网方面做的一些基础设施的建设和调优。
分享的内容主要分4部分：移动互联网现正在快速增长的背景；移动互联网与传统PC互联网可能还会有一些不同，而且在运维方式上和运维挑战上都有很大的不同，存在一些新的挑战，这些挑战是什么；小米在做移动互联网的开始，也就是基础设施建设的时候我们是怎么思考、应对这些问题的，我们的思路是怎样的；最后介绍小米的一些具体的做法。一、背景——移动互联网快速成长
根据百度发布的一个移动互联网发展报告可以看出，从2012年Q3开始，移动互联网的访问时长已经超越了传统PC互联网的访问时长，到2013年Q1报告的时候可以看出，移动互联网的访问时长已经超出了传统PC互联网访问时长的三分之一左右，而且这个趋势还一直在迅猛发展着。如下图所示。2011年Q1—2013年Q1移动互联网与PC互联网人均上网时长趋势对比（数据参考：百度移动互联网发展趋势报告2013Q1）
人们通过传统PC上网的这个过程逐渐过渡到通过一些移动终端设备来上网，获取信息，进行交流，手机无疑已经成为第一上网终端。
提到小米，可能大家比较了解的是小米的一些硬件产品，比如小米手机、小米盒子，让大家以为小米是一家硬件厂商，实际上小米最初的定义是移动互联网公司，我们有非常多的移动互联网应用，如下图所示。根据分析，我们不同的产品线有60％～80％的请求都是来自于移动互联网。小米做了这么多移动互联网的应用，所以就把自己定位为移动互联网公司了。二、移动互联网下运维的新挑战
1．数据依靠电波传输，质量不稳定
当我们在做移动互联网的时候遭遇了一些什么样的挑战呢？我们一起来看一下，以前上网的时候，可能大多数电脑都是连接网线或者是在家里搭一个WiFi，这些相对来讲是比较有保障的传输。PC互联网的建设相对来讲已经比较成熟了，但是当我们变为移动终端来访问的时候，要通过运营商的网络来访问这些资源。运营商的网络都是经过传统的电波来进行传输的，电波在传输的过程中可能会有各种直射、反射、绕射（参见下图），另外还会受到一些信号强弱的影响，所以它会非常不稳定，传输也可能非常慢。
试读结束[说明：试读内容隐藏了图片]