中国移动研究院常耀斌：商用大数据平台的研发之路

导语：我是中国移动研究院的资深架构师常耀斌。2007年，我加入中国电科，参与并主导设计的“全军一体化指挥作战平台”荣获国家科技进步特等奖。2009年，我出任华为云第一代架构师，带领团队研制并运营了国内首个公有云平台。回首10年多的科研工作历程，也是中国经济高速发展的10多年，中国高铁、核电、航空、互联网、云计算、大数据、人工智能等领域无不铭刻着“中国名片”，这就是科技是第一生产力的实践验证!2007年，获得北邮计算机工学硕士后信心满满的踏上了科研之路，一干就是十多年，有苦有泪有艰辛，但收获的是一种为国家科技发展能奉献和敢担当的责任感。

今天，又一次站在了移动互联网这个朝阳产业的跑道上，和诸多大数据和人工智能的世界级大咖共商创新发展!2012年加入中国移动集团研究院，担任资深大数据专家和研究员，主攻大数据和人工智能平台架构设计和关键技术研究，并多次受邀在大数据行业和主流峰会进行学术交流，在见证我的学生们历练为BAT/TMD的技术专家同时，也悄然实现着我的技术梦想-让高科技研发标准化和平民化。今天有幸分享商用大数据平台研发经验，让大数据知识图谱在各位的脑海里转起来，并形成商用产品的作战体系，这是“作为架构师，何谓正确?”的行动基础。我分享四大部分：知识分类，系统架构，核心技术，经验分享。具体如下：

01大数据知识结构归类:

* 文件存储：

Hadoop HDFS、Tachyon、KFS

* 离线计算：

Hadoop MapReduce、Spark

* 流式、实时计算：

Storm、Spark Streaming

* K-V、NOSQL数据库：

HBase、 Redis 、MongoDB

* 资源管理：

YARN、Mesos

* 日志收集：

Flume、Scribe、Logstash、Kibana

* 消息系统：

Kafka、StormMQ、ZeroMQ、RabbitMQ

* 查询分析：

Hive、Impala、Pig、SparkSQL、Flink

* 分布式协调服务：

Zookeeper

* 集群管理与监控：

Ambari、Ganglia、Nagios、Cloudera Manager

* 数据挖掘、机器学习：

Mahout、Spark MLLib

* 数据同步：

Sqoop

* 任务调度：

Oozie

02 知识汇总及系统架构形成:

以物联网大数据平台的架构为例，围绕着这条主线：基础架构-》离线分析-》离线迁移-》离线同步-》实时计算-》实时交换-》实时调度-》实时存储-》智能分析。

03 核心技术(10个单元)

第一单元：基础架构-Hadoop的破冰之旅

Hadoop是一个由Apache基金会所开发的分布式系统基础架构。Hadoop是实现了真正意义上的去“IOE”，尤其是开启了摆脱国外高科技公司的全球垄断时代，让全球用户可以轻松地在免费的Hadoop上开发和运行处理海量数据的应用程序。建议先把Hadoop集群构建起来，具体操作见我的博客：https://blog.csdn.net/peter_changyb/article/details/81195920。它主要有以下几个优点：

* 高可靠性。

Hadoop按位存储和处理数据的能力值得人们信赖。

* 高扩展性。

Hadoop是在可用的计算机集簇间分配数据并完成计算任务的，这些集簇可以方便地扩展到数以千计的节点中。

* 高效性。

Hadoop能够在节点之间动态地移动数据，并保证各个节点动态平衡，因此处理速度非常快。

* 高容错性 。

Hadoop能够自动保存数据的多个副本，并且能够自动将失败的任务重新分配。

Hadoop可以算是大数据存储和计算的开山鼻祖，现在大多开源的大数据框架都依赖Hadoop或者与它能很好的兼容。具备如下：

• Hadoop 1.0、Hadoop 2.0
• MapReduce、HDFS
• NameNode、DataNode
• JobTracker、TaskTracker
• Yarn、ResourceManager、NodeManager

1.1 HDFS是Hadoop的关键技术所在

HDFS目录操作命令;上传、下载文件命令;提交运行MapReduce示例程序;打开Hadoop WEB界面，查看Job运行状态，查看Job运行日志。知道Hadoop的系统日志在哪里。

1.2 了解并行计算的核心原理

MapReduce：分而治之的优秀思想;HDFS：数据分片和数据复制为核心的技术。数据到底在哪里，什么是副本;

Yarn如何用分层管理思想革命性的改变了MapReduce的核心架构?NameNode职责?;Resource Manager职责?

1.3 亲自写MapReduce程序

第二单元：离线分析

2.1 SQL On Hadoop之Hive

什么是Hive?官方解释如下：The Apache Hive data warehouse software facilitates reading, writing, and managing large datasets residing in distributed storage and queried using SQL syntax.

数据仓库物理上是数据库，逻辑上仓库。有两个特点：海量数据、相对稳定的;相对稳定，指很少会被更新和删除，只会被大量查询。而Hive，也是具备这两个特点，因此，Hive适合做海量数据的数据仓库工具，而不是数据库工具。Hive核心技术讲解参见我的博客 https://blog.csdn.net/Peter_Changyb/article/details/81977665

2.2 安装配置Hive

2.3 使用Hive

2.4 Hive核心原理

2.5 Hive的基本命令：

创建、删除表;加载数据到表;下载Hive表的数据，需要你掌握如下技能：

• MapReduce的原理;
• HDFS读写数据的流程;
• 学会查看日志解决问题;
• 会SELECT、WHERE、GROUP BY等 SQL 语句;
• Hive SQL转换成MapReduce的关键流程;
• Hive中常见的语句：创建表、删除表、往表中加载数据、分区、将表中数据下载到本地;

第三单元：离线迁移

3.1 HDFS PUT操作

put命令在实际环境中也比较常用，通常配合 shell 、 python 等脚本语言来使用。

3.2 HDFS API调用

HDFS提供了写数据的API，自己用编程语言将数据写入HDFS，put命令本身也是使用API。实际环境中一般自己较少编写程序使用API来写数据到HDFS，通常都是使用其他框架封装好的方法。比如：Hive中的INSERT语句，Spark中的saveAsTextfile等。

3.3 Sqoop迁移工具

Sqoop是一个主要用于Hadoop/Hive与传统关系型数据库，Oracle、 MySQL 、SQLServer等之间进行数据交换的开源框架。就像Hive把SQL翻译成MapReduce一样，Sqoop把你指定的参数翻译成MapReduce，提交到Hadoop运行，完成Hadoop与其他数据库之间的数据交换。自己下载和配置Sqoop。了解Sqoop常用的配置参数和方法。使用Sqoop完成从MySQL同步数据到HDFS;使用Sqoop完成从MySQL同步数据到Hive表;如果后续选型确定使用Sqoop作为数据交换工具，那么建议熟练掌握，否则，了解和会用Demo即可。Sqoop导入Hbase核心代码见我的技术博客https://blog.csdn.net/Peter_Changyb/article/details/82557741

3.4 Flume分布式采集框架

Flume是一个分布式的海量日志采集和传输框架，因为“采集和传输框架”，所以它并不适合关系型数据库的数据采集和传输。Flume可以实时的从网络协议、消息系统、文件系统采集日志，并传输到HDFS上。因此，如果你的业务有这些数据源的数据，并且需要实时的采集，那么就应该考虑使用Flume。下载和配置Flume。使用Flume监控一个不断追加数据的文件，并将数据传输到HDFS;Flume的配置和使用较为复杂，如果你没有足够的兴趣和耐心，可以先跳过Flume。核心技术参见我的技术博客https://blog.csdn.net/Peter_Changyb/article/details/81213997

第四单元：离线同步

Hive和MapReduce进行分析了。那么接下来的问题是，分析完的结果如何从Hadoop上同步到其他系统和应用中去呢?其实，此处的方法和第三章基本一致的。

4.1 HDFS GET命令

把HDFS上的文件GET到本地。

4.2 HDFS API

4.3 Sqoop

使用Sqoop完成将HDFS上的文件同步到MySQL;使用Sqoop完成将Hive表中的数据同步到MySQL。

4.4 DataX

DataX 是一个异构数据源离线同步工具，致力于实现包括关系型数据库(MySQL、Oracle等)、HDFS、Hive、ODPS、HBase、FTP等各种异构数据源之间稳定高效的数据同步功能。之所以介绍这个，是因为我们公司目前使用的Hadoop与关系型数据库数据交换的工具，就是之前基于DataX开发的，非常好用。现在DataX已经是3.0版本，支持很多数据源。DataX本身作为离线数据同步框架，采用Framework + plugin架构构建。将数据源读取和写入抽象成为Reader/Writer插件，纳入到整个同步框架中。三个核心模块要理解。Reader：Reader为数据采集模块，负责采集数据源的数据，将数据发送给Framework。Writer： Writer为数据写入模块，负责不断向Framework取数据，并将数据写入到目的端。Framework：Framework用于连接reader和writer，作为两者的数据传输通道，并处理缓冲，流控，并发，数据转换等核心技术问题。

第五单元：实时计算

Spark对MapReduce做了大量的改进和优化，主要包括以下个方面：

1)磁盘I/O的读写优化：

中间结果缓存在内存中：随着实时大数据应用越来越多，Hadoop作为离线的高吞吐、低响应框架已不能满足这类需求。Hadoop MapReduce的map端将中间输出和结果存储在磁盘中，reduce端又需要从磁盘读写中间结果，从而造成磁盘I/O成为瓶颈。Spark则允许将map端的中间输出和结果缓存在内存中，从而使得reduce端在拉取中间结果时避免了大量的磁盘I/O;应用程序上传的资源文件缓存在Driver本地文件服务的内存中：Hadoop YARN中的ApplicationMaster申请到Container后，具体任务需要利用NodeManager从HDFS的不同节点下载任务所需的资源(如Jar包)，增加了磁盘I/O。Spark则将应用程序上传的资源文件缓存在Driver本地文件服务的内存中，当Executor执行任务时直接从Driver的内存中读取，从而节省了大量的磁盘I/O。

2)任务的并行处理优化：

由于将中间结果写到磁盘与从磁盘读取中间结果属于不同的环节，Hadoop将它们简单地通过串行执行衔接起来。而Spark则把不同的环节抽象为Stage，允许多个Stage既可以串行执行，又可以并行执行。

3)任务调度中的资源过滤：

当Stage中某个分区的Task执行失败后，会重新对此Stage调度，但在重新调度的时候会过滤已经执行成功的分区任务，所以不会造成重复计算和资源浪费。

4)Shuffle排序：

Hadoop MapReduce在Shuffle之前会将中间结果按key的hash值和key值大小进行两层排序，确保分区内部的有序性。而Spark则可以根据不同场景选择在map端 排序 还是reduce端排序。

5)内存管理优化：

Spark将内存分为堆上的存储内存、堆外的存储内存、堆上的执行内存、堆外的执行内存4个部分。Spark既提供了执行内存和存储内存之间固定边界的实现，又提供了执行内存和存储内存之间“软”边界的实现。Spark默认使用“软”边界的实现，执行内存或存储内存中的任意一方在资源不足时都可以借用另一方的内存，最大限度地提高资源的利用率，减少对资源的浪费。Spark由于对内存使用的偏好，内存资源的多寡和使用率就显得尤为重要，为此Spark的内存管理器提供的Tungsten实现了一种与操作系统的内存Page非常相似的数据结构，用于直接操作操作系统内存，节省了创建的 Java 对象在堆中占用的内存，使得Spark对内存的使用效率更加接近硬件。Spark会给每个Task分配一个配套的任务内存管理器，对Task粒度的内存进行管理。Task的内存可以被多个内部的消费者消费，任务内存管理器对每个消费者进行Task内存的分配与管理，因此Spark对内存有着更细粒度的管理。核心技术参考我的博客https://blog.csdn.net/Peter_Changyb/article/details/81904066

5.1 关于Spark和SparkSQL

什么是Spark，什么是SparkSQL。Spark有的核心概念及名词解释。SparkSQL和Spark是什么关系，SparkSQL和Hive是什么关系。SparkSQL为什么比Hive跑的快。

5.2 如何部署和运行SparkSQL

Spark有哪些部署模式?如何在Yarn上运行SparkSQL?使用SparkSQL查询Hive中的表。Spark不是一门短时间内就能掌握的技术，因此建议在了解了Spark之后，可以先从SparkSQL入手，循序渐进。关于Spark和SparkSQL，如果你认真完成了上面的学习和实践，此时，你的”大数据平台”应该是这样的。

第六单元：实时交换

在实际业务场景下，特别是对于一些监控日志，想即时的从日志中了解一些指标，这时候，从HDFS上分析就太慢了，尽管是通过Flume采集的，但Flume也不能间隔很短就往HDFS上滚动文件，这样会导致小文件特别多。为了满足数据的一次采集、多次消费的需求，这里要说的便是Kafka。

6.1 关于Kafka

什么是Kafka?Kafka的核心概念及名词解释。

6.2 如何部署和使用Kafka

使用单机部署Kafka，并成功运行自带的生产者和消费者例子。使用Java程序自己编写并运行生产者和消费者程序。Flume和Kafka的集成，使用Flume监控日志，并将日志数据实时发送至Kafka。

这时，使用Flume采集的数据，不是直接到HDFS上，而是先到Kafka，Kafka中的数据可以由多个消费者同时消费，其中一个消费者，就是将数据同步到HDFS。

1. 为什么Spark比MapReduce快。
2. 使用SparkSQL代替Hive，更快的运行SQL。
3. 使用Kafka完成数据的一次收集，多次消费架构。
4. 自己可以写程序完成Kafka的生产者和消费者。

第七单元：实时调度

不仅仅是分析任务，数据采集、数据交换同样是一个个的任务。这些任务中，有的是定时触发，有点则需要依赖其他任务来触发。当平台中有几百上千个任务需要维护和运行时候，仅仅靠crontab远远不够了，这时便需要一个调度监控系统来完成这件事。调度监控系统是整个数据平台的中枢系统，类似于AppMaster，负责分配和监控任务。

7.1 Apache Oozie

1. Oozie是什么?有哪些功能?当你的系统引入了spark或者hadoop以后，基于Spark和Hadoop已经做了一些任务，比如一连串的Map Reduce任务，但是他们之间彼此右前后依赖的顺序，因此你必须要等一个任务执行成功后，再手动执行第二个任务。

• * Oozie是管理Hadoop作业的工作流调度系统
• * Oozie的工作流是一系列的操作图，Oozie协调作业是通过时间(频率)以及有效数据触发当前的Oozie工作流程
• * Oozie是针对Hadoop开发的开源工作流引擎，专门针对大规模复杂工作流程和数据管道设计
• * Oozie围绕两个核心：工作流和协调器，前者定义任务的拓扑和执行逻辑，后者负责工作流的依赖和触发。

2. Oozie可以调度哪些类型的任务(程序)?

3. Oozie可以支持哪些任务触发方式?

4. 安装配置Oozie。

7.2 其他开源的任务调度系统

Azkaban，light-task-scheduler，Zeus，等等。另外，我这边是之前单独开发的任务调度与监控系统。

第八单元：实时处理

在介绍Kafka的时候提到了一些需要实时指标的业务场景，实时基本可以分为绝对实时和准实时，绝对实时的延迟要求一般在毫秒级，准实时的延迟要求一般在秒、分钟级。对于需要绝对实时的业务场景，用的比较多的是Storm，对于其他准实时的业务场景，可以是Storm，也可以是Spark Streaming。

8.1 Storm

1. 什么是Storm?有哪些可能的应用场景?
2. Storm由哪些核心组件构成，各自担任什么角色?
3. Storm的简单安装和部署。
4. 案例实战参见我的技术博客https://blog.csdn.net/Peter_Changyb/article/details/82380603

8.2 Spark Streaming

1. 什么是Spark Streaming，它和Spark是什么关系?
2. Spark Streaming和Storm比较，各有什么优缺点?
3.  使用Kafka + Spark Streaming，完成实时计算的Demo程序。

第九单元：实时存储

HBase属于存储层，是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，可在廉价PC Server上搭建起大规模结构化存储集群。Hbase依托于很多框架和工具。其中，Hadoop HDFS为HBase提供了高可靠性的底层存储支持，Hadoop MapReduce为HBase提供了高性能的计算能力，Zookeeper为HBase提供了稳定服务和failover机制。Pig和Hive还为HBase提供了高层语言支持，使得在HBase上进行数据统计处理简单快捷。Sqoop为HBase提供了方便的RDBMS数据导入功能，使得传统数据库数据向HBase中迁移更灵活。

HBase的 Client客户端借助HBase的RPC机制与HMaster和HRegionServer进行通信，Zookeeper Quorum中除了存储了-ROOT-表的地址和HMaster的地址，HRegionServer也注册到Zookeeper中，使得HMaster可以随时感知到各个HRegionServer的存活状态。HMaster解决了单点故障问题，HBase中可以启动多个HMaster，通过Zookeeper的Master Election机制保证总有一个Master运行，HMaster在功能上主要负责Table和Region的管理工作，包括管理用户对Table的增、删、改、查操作，管理HRegionServer的负载均衡，调整Region分布，在Region Split后负责新Region的分配，在HRegionServer停机后负责失效HRegionServer 上的Regions迁移。

HRegionServer职责是负责响应用户I/O请求，向HDFS文件系统中读写数据，属于HBase中最核心的模块。它内部管理了一系列HRegion对象，每个HRegion对应了Table中的一个Region，HRegion中由多个HStore组成。每个HStore对应了Table中的一个Column Family的存储，每个Column Family就是一个集中的存储单元，设计师最好将具备共同IO特性的column放在一个Column Family中，一般来说，我们只设置一个Column Family。HStore存储是HBase存储的核心，其中由两部分组成，一是MemStore，二是StoreFiles。MemStore是Sorted Memory Buffer，用户写入的数据首先会放入MemStore，当MemStore满了以后会Flush成一个StoreFile(底层实现是HFile)，当StoreFile文件数量增长到一定阈值，会触发Compact合并操作，将多个StoreFiles合并成一个StoreFile，合并过程中会进行版本合并和数据删除，所以HBase其实只有增加数据，所有的更新和删除操作都是在后续的compact过程中进行的，这使得用户的写操作只要进入内存中就可以立即返回，保证了HBase I/O的高性能。

第十单元：智能分析

机器学习核心技术参见我的技术博客https://blog.csdn.net/Peter_Changyb/article/details/82347169。常用的机器学习解决的问题有三类：

* 分类问题：

包括二分类和多分类，二分类就是解决了预测的问题，就像预测一封邮件是否垃圾邮件;多分类解决的是文本的分类;

* 聚类问题：

从用户搜索过的关键词，对用户进行大概的归类。

* 推荐问题：

根据用户的历史浏览和点击行为进行相关推荐。

04 经验分享

总之，对商用大数据平台而言，我们要考虑应用场景，用户规模和数据处理能力，以及未来3年的目标等。在应用场景的设计中，会考虑业务和技术的结合度量，业务的规模和流程设计。用户规模和数据处理能力，会考虑技术选型和架构设计。具体要考虑架构设计。架构中重要的核心指标：性能、可用性、伸缩性、扩展性的等。

一、性能

性能就是核心要素之一，具体如下：

• * CDN加速
• * 反向代理
• * 分布式缓存

* 异步化：

通过分布式消息队列来实现削峰的目的。通过业务配合技术来解决问题。

* 集群：

采用集群也是服务虚拟化的一个体现。用以避免单点问题，同时提供更加高可用，高性能的服务。

* 代码优化：

多线程中，如果是密集型计算，线程数不宜超过CPU核数。如果是IO处理，则线程数=[任务执行时间/(任务执行时间-IO等待时间)] * CPU核数。除此之外，我们应该将对象设计成无状态对象，多采用局部对象，适当将锁细化。进行资源复用。比如采用单例模式，比如采用连接池。合理设置JVM参数。

* 存储性能优化：

关系型数据库的索引采用B+树进行实现。而很多的nosql数据库则采用了LSM树进行存储。LSM在内存中保留最新增删改查的数据，直到内存无法放下，则与磁盘的下一级LSM树进行merge。所以对于写操作较多，而读操作更多的是查询最近写入数据的场景，其性能远高于b+树;采用HDFS结合map reduce进行海量数据存储和分析。其能自动进行并发访问和冗余备份，具有很高的可靠性。其等于是实现了RAID的功能。

* 数据访问接口优化：

数据库层其实是最脆弱的一层，一般在应用设计时在上游就需要把请求拦截掉，数据库层只承担“能力范围内”的访问请求，所以，我们通过在服务层引入队列和缓存，让最底层的数据库高枕无忧。

二、高可用性

衡量一个系统架构设计是否满足高可用的目标，就是假设系统中任何一台或者多台服务器宕机时，以及出现各种不可预期的问题时，系统整体是否依然可用。一般就三个手段、冗余、集群化、分布式。高可用的主要手段就是冗余，应用部署在多台服务器上同时提供服务，数据存储在多台服务器上相互备份。安全服务是指计算机网络提供的安全防护措施，包括认证服务、访问控制、数据机密性服务、数据完整性服务和不可否认服务。特定的安全机制是用来实施安全服务的机制，包括加密机制、数据签名机制、访问控制机制、数据完整性机制、认证交换机制、流量填充机制、路由控制机制和公证机制。普遍性的安全机制不是为任何特定的服务而特设的，属于安全管理方面，分为可信功能度、安全标记、事件检测、安全审计跟踪和安全恢复。

三、高扩展性

扩展性指对现有系统影响最小的情况下，系统功能可持续扩展或提升的能力。表现在系统基础设施稳定不需要经常变更，应用之间较少依赖和耦合，当系统增加新功能时，不需要对现有系统的结构和代码进行修改。扩展性依赖于前期良好的架构设计。合理业务逻辑抽象，水平/垂直切割分布式化等等。可扩展架构的主要手段是事件驱动架构和分布式服务。事件驱动通常利用消息队列实现，通过这种方式将消息生产和处理逻辑分隔开。服务器服务则是将业务和可复用服务分离开来，通过分布式服务框架调用。新增加产品可用通过调用可复用的服务来实现自身的业务逻辑，而对现有产品没有任何影响。

四、高伸缩性

服务尽量同构。DB、cache在考虑分布式时尽量提前设计好扩展方案。也可以采用一些主流的对水平伸缩支持较好的nosql、 memcached 、hbase等