实践课堂｜QingCloud 大数据云平台之架构与实践

[Arron]

主持人：今天的活动没有设茶歇时间，我们有准备饮料和点心，大家听的过程中可以自取，我们的沙龙是一个轻松的活动。

QingCloud的大数据推出了Spark、Hadoop，即将推出其他新的大数据服务，我们工程师李威将会分享这一话题，欢迎北大的高材生，IBM的金牌讲师李威。

李威：大家好！QingCloud的分享是一个非常烧脑的活动，在座都是高智商的人群，我今天下午带来的话题比较烧脑，大家可以集中注意力，里面涵盖的内容比较多，对大数据的平台有比较强的了解，不会超出这个范围。我带来的话题是大数据均一平台之架构与实践，包括几块内容，一是大数据和云计算以及他们之间的关系；二是在云上做大数据有什么挑战，我们如何解决；三是大数据平台系统架构，基本涵盖大数据整个生命周期和从上到下的所有层次；四是最佳实践，包括我们部署、运维大数据平台的最佳实践。

一是大数据，这个词用得比较多，每个人的理解不一样，原因很简单，大数据本身是一个海洋，里面的成分非常多，有的人说的是AlphaGo，人工智能深度学习，有的人说的是大数据存储，有的人说的是调度。我们拿自己客户的案例来说，QingCloud上有一个非常大型的互联网社交平台，它用大数据做什么事情？要做User Profiling（用户画像），用户有哪些特点，把信息计算出来，在推荐消息时会非常精确，就像精准营销一样。在互联网金融行业用到比较多的是风控的分析上，大家对互联网金融行业有了解就知道，在互联网金融里最核心的是风控的模型，原因是在传统的金融行业里，他们针对的是大客户的贷款活动。像我们这样的个人小客户，之所以做不到是计算成本非常大，要收集很多信息，决策过程等流程非常长。互联网金融为什么能做到，他们有非常好的海量数据处理系统，他们会建立非常好的风控模型，可以在非常短的时间内决定是否给你借贷。政府的客户里，它有全国各地的海量数据，有一个用户输入名字，马上判断这个人有没有违规记录、犯罪记录以及其他危险信息，你要处理公证证明时就会遇到一些麻烦。所有的客户应用的是大数据每一个不同层面的能力。

在说大数据的时候，很多人认为这个东西很复杂，它和云计算有什么关系，我们是这么理解的。在云上做大数据，它的好处非常多，我们说几个例子，在大数据选型时，所有的公司都需要解决方案，而不是一个产品就能满足需求。这时候有架构选型上的决定，如果说你有一个比较灵活的平台，比如云平台上提供各种大数据的服务，你可以非常快的验证这些服务的组成能否满足需求，而不是你需要自己招聘一些人或是大数据各个层面的专家，花很长时间部署大数据平台，部署好平台后验证发现不满足需求，重新再搭一套，成本非常高。在云上做这个事情，成本非常低。选择在云上做大数据的原因是现在的互联网，包括物联网的发展非常迅速，在你做自己业务的时候，你很难判断半年后、一年后的数据量、用户量会不会爆发式的增长，有这种不确定性在里面，云平台的特性可以满足这一点。

你可以想象一个场景，公司要建100台机器的Hadoop集群，自己运维、进行数据分析，如果没有云计算平台给你提供这些服务，你要花多少时间和精力做这些事情。当你的大数据平台很复杂，你有计算层、Spark服务、存储等，突然有一天你想切换成Spark，你在云上做这个事情非常简单，不用动数据，直接切换引擎就可以了，这是计算漂移。第二个比较有特点的是在云上，大数据的每一个产品都可以做成服务，包括传统的数据库服务、路由器服务、负载均衡器服务等都可以组件化，都有服务编排。这些都是大数据在云上的好处，更重要的是在云上的大数据挑战并不是刚刚这些点，这只是它的好处。

它的挑战体现在三点，一是云的稳定性，有时候之所以看到很多公司的大数据没在云上做，因为他们没有非常好的IaaS平台做支撑；二是物理机和虚拟机有两点考虑，虚拟化的机器肯定没有物理机快，肯定没有物理机的网络快。我们在网络I/O层面，陈海泉说我们在SDN/NFV 2.0上有非常大的突破，点对点的网速可以达到8G，和实际的物理网卡非常接近。硬盘I/O层面有自己的转换，包括硬件架构层面的设计，让硬盘I/O有非常好的提升；三是数据迁移的问题，包括云上的迁移以及云和传统数据中心间的迁移。比如像关系数据库迁移到Hadoop数据库，现在比较流行的是Kafka和Flume，可以把每台机器上的收集到对象存储，直接连接到Kafka的队列里。

我们有了云上的好处，解决云上的条件，我们会形成比较通用的大数据平台。这个平台的涵盖面是最全的，从左往右看，左边是数据的生成，包括Kafka或是Flume，我们没有把所有的产品列出来，基本上是现在在每一个步骤或是模块上最主流的产品，在每一个模块里，QingCloud都会有相应的，至少有一个服务提供出来，以后会越来越多，比如在收集、采集这一块我们有Kafka，数据有存储，我们已经上线HDFS、Hbase，这一层是分布式内存文件系统，现在在Spark能用上。分析有三块，一是实时分析，Storm、Spark Streaming、Big SQL、Kylin、GreenPlum、Hive、lmpata等，在数据的收集、存储和分析后，提供对数据的计费、安全、协调等服务，还有ZooKeeper的服务。我的数据存储完，我要交付给用户使用，我们在这一层属于用户交互的层面，我们有了MongoDB、MySQL，很快也有会Elastic Search。当我的用户需要UI展现时，我可以简单的调用这一层的服务。

接下来我的分享是按照这个架构一层层剖析现在的主流产品，包括QingCloud提供的服务。这些产品和服务的对比有什么特点，在什么情况下，我们会选择什么样的产品。

第一，我们提供的是Hadoop和Spark，了解Hadoop的人比较清楚，里面主要分为三部分，左边是Hadoop客户端，中间是两个主节点，从节点上有几个重要的进程，一是DataNode，管理数据存储；二是Node Manager，做资源分配，我们是基于Hadoop2.0后提供的Hadoop集群服务，里面没有1.0的机制，取代的是container。它主要用来保证任务的完成。

Spark架构，包括底层的Hadoop存储、Spark SQL解析、实时分析、图计算等都有提供。用户有一个疑问，在计算平台上，在大数据架构里，有三个经典的选择，我们怎么选？MapReduce分析的数据量最大，在做架构设计时，它的设计点是用海量数据大文件处理，它可以做高吞吐量的数据计算；往Spark Streaming来看，数据量可以很大，但没有MapReduce大，它有自己的技术，它有全局优化引擎。最快的是Storm，它是无状态的计算，计算是毫秒级的。要选择海量数据时，还是选择MapReduce。如果你的公司有Hadoop的相关投入，比如你的人才、公司数据资源由Hadoop现在系统管理，我建议你用Spark Streaming，人才投入不会耗费掉。Storm是一个单独的系统，如果你的公司里没有Hadoop的基础或是人员投入在里面，你想非常快的实施实时分析系统，Storm是一个很好的选择，因为它的架构很简单，不牵扯到存储。

很多时候我们选择Spark、MapReduce或是Storm，你要写很多代码，效率比较低，大家比较喜欢用SQL on Hadoop，这些产品非常多，我们举几个比较通用的词，这是非常主流的。对一亿行的记录进行查询，Phoenix是性能最高的。这是在存储之上包括了关系数据库，上面最慢的是Hive，当你处理数据量达到T级时，目前能处理过来的还是Hive，其他的还不行。

大家比较生疏，这是一个数据库，为什么Hive做分析非常慢，因为它把所有的计算都变成了它的任务，我把硬盘的读写变成内存的计算，完全抛弃了MapReduce的引擎。它只是在HAWQ，里面的词汇非常多，基本上涵盖了我说的每个领域的主流。HAWQ的作者是中国人，这是Apache的顶级开源项目，QingCloud在四月底有底会推出Greenplum服务。这三个作者以前是雅虎的Hadoop开发工程师，后来做Greenplum开发工程师，他们三人开发了阿帕奇的HAWQ项目，他们的加入让我们对数据仓库服务增加了非常多的信心。

说完计算，我们谈谈存储。比较典型的是HDFS，相信很多研究Hadoop的小伙伴都看过，这里可以说的是NameNode，相当于存储系统要做的事，只对元数据进行管理，它对数据是不管理的，进行数据读写、创建目录只在NameNode进行操作。另一个设计初衷，为什么不能存取海量小文件，每一个文件的数据特别小，再小也要存储数据，你存了1000万的数据，里面只有1K，数据量会非常大。当你要海量小文件的时候，内存会吃不消。这是专门适合大数据存储，而不是海量小文件的。

HBase，这里有Region Table A，在每一个节点上是分片的。保证HBase是可扩展的，这是独特的数据库，如果说之前是研究关系数据库的，可能对HBase研究起来有点困难，只要理解这一句话，HBase的精髓就理解了。A sparse，我在物理上是按照一列数据存储，比如姓名、年龄都有共同的属性，你定义的时候，属性长度都可以定义。每一行存的数据，第一行可能有一个数据没存，第二行有两个是空着的，从关系数据库来看到处都是空的，按照行的，MySQL的存储方式，你在硬盘上有很多浪费空间，HBase没有浪费，它是按列存储的，空间都可以利用上，因为每一列的属性一样，比如每一列的宽度是一样的，就算是空值，我可以把这一列有效的存储。distributed，persistent，HBase所有的数据都会持久到分布式存储这一层。multidimensional，在每一个最终的存储单元里，每一个存储值都有时间戳，有一个历史的概念。我可以存两个时间的。sorted map也很好理解，理解成关系数据库的Row Key来排序。map，可以把每一行看作一个值，每一个有自己的名字值，所有的加起来是HBase的核心定义。

简单的例子，在这个数据结构里，外面的00001是它的Row Key，这一个是它的Column Families，第三层是Column Qualifiers，不同的时间有对应的值。

我的同事王煜会介绍第三种非常好的对象存储。在HDFS和HBase做存储选择需要有一个考量。HBase擅长的是快速随机读写，最重要的是随机两个字，HDFS满足不了，它是正常的文件系统，并没有数据库里的索引概念，只能扫描，你要处理所有的数据上，它比HBase快。当你要随机读写数据，HBase会比它快非常多。他们俩中间有均衡的项目，这是一个比较不错的性能。

数据仓库的存储，Greenplum Database，它涵盖了存储层、计算层。它和以前的Hadoop上的HBase有什么区别？一是它支持标准的SQL，这对传统行业的企业非常重要，你以前怎么写SQL，现在还怎么写，没有任何改变。也会有支持分布式。它会有一些线性横向扩展的能力，这是NoSQL有的。什么企业喜欢选Greenplum，你有传统的产品，你对Hadoop、HBase这一套没有验证过，你需要非常平滑的移动到一个数据仓库里，Greenplum的数据仓库是非常好的选择。

把计算层、存储层说完，现在说的是传输层。比较多的是Flume跟Kafka，他们没有绝对的区分。Flume里有一个非常好的特点是集成了很多数据源、Data，可以很好的做收集工作，它直接支持数据加密，Kafka不支持。Kafka的特点很明显，前面是分布式、可分区，关键是它是高吞吐量、低延迟。比如一秒钟可以好几百万行数据可以处理。（下图）是我们从大型互联网用户截出来的，（左图）是数据录入，（右图）是数据流出。Kafka是持久化的，它的数据会落到硬盘里，当你有这个数据，为什么网络的输入是平的？Kafka有独特的设计方式在里面，它的处理方式是在写数据的时候，并不是所有的数据立马写在硬盘上才返回，它会写到页面缓存、内存里就可以处理。在读的时候，我要从网络上发出去，这时候它用的是Kernel内核的系统调用，也就是所有的数据根本不落地，虽然它最后会落到硬盘里，处理的时候可以完全不落。Kafka的用户本身是Kernel的开源者。Kafka的架构可以稍微说一下，这是一个可以有很多数据生产者，下面是数据的消费者，所有的Producer可以往一个主题写，不需要考虑同步的问题，原因是Kafka已经帮你做这个事情，会变成很多分片，你往每个分片里写，每一个分片都是一个队列。Kafka在Consumer数据读的时候，你可以组成Consumer消费者，可以消费同一组消息，这个消息分为四个P0、P1、P2、P3，这是测试组，这是开发组，他们消费的是同一份消息，也不会出问题，原因是Kafka已经用ZooKeeper帮你处理同步数据的问题，它会记录处理这个主题到哪一步，中间不会有冲突。比如C3只消费P0的数据，并发处理并没有问题。

计算、存储、传输，包括ZooKeeper、Hadoop都说完了。接着谈谈我们觉得比较重要的实践，一是在云上做Hadoop，比如我们的存储HDFS，到底要几个副本，物理机上要三个副本，三个副本的原因是考虑数据的安全性，它害怕物理机死机时，它只有两个副本，物理机就不可用了，它一定要第三个副本存在物理机上。真的要在云上做三个吗？不一定，看你的IaaS层有没有非常好的能力。QingCloud的IaaS非常稳定和健壮，我们可以完全依赖IaaS层做到这个数据，比如一台物理机死机时，另一台就会起来，数据不会丢失。这时候可以设置两个副本，在Hadoop的HDFS上做，可以节省空间。可以优化的空间在什么地方？IaaS层提供两个副本，HDFS有两个副本，一共有四个副本。表面上物理机省了，实际上比它多一个。因为IaaS层的副本是可以去掉的，把这一层副本去掉，可以在自己的PaaS层，也就是HDFS这一层做三个副本，跟物理机一样。还有一个原因是我们自己是云服务的提供商，我知道每一台物理机的拓扑结构是怎样的。我们之前传统的B1、B2、B3，有两个副本不需要。我们现在做的是恢复三个副本，把底层IaaS的副本也去掉，在PaaS层做高可用，完全达到像物理机这样的效果。

参数调优，Hadoop本身是非常复杂的系统，包含存储层、资源调度层、计算引擎层面，它的参数非常多，估计有三、四百个参数。你在运行时，老是会碰见一些问题，你的container被Kill了等等。在调优层面时会很抓狂，你调了一个参数后发现别的又出来了，原因是你在做调优的时候，一定要对系统的架构、运行机理了解得比较明白，你调优参数后，它和别的参数有什么关系，会影响系统的运行什么程度。这里有一些图片，大家在做参数调优的时候会有帮助。你在调优时，这些参数有关系。最外层有一个专门控制Node Manager，这是最大的值，如果这个值配错了，如果这是24G，你配成8G，这是最大的限制。在YARN这个几百要控制，它有最大分配单元，应该是8G。你分配任务9G或者10G，在YARN的层面是不成功的，你改的时候记住不要超过上面这个值。Map和Reduce不要超过上面的最大分配值。下面是JVM的值，也不要超过它设置的值就行了。很多人知道在JVM里，为什么还有两个参数值，难道他们不一样吗？就是不一样。当你设置很多参数时，你要注意比较重要的点，当你设置1024的时候，YARN给你分配的内存不是1.5G，而是2G。YARN分配资源时，最小的单位是1G，对它来说要么是1G、2G或3G，不会有1.5G的概念。这里物理内存的概念。YARN还会做一层检查，当你设置MapReduce内存时，在虚拟内存也会做3.2G的检查。

最佳实践分享是数据格式，很多人不注意，因为数据格式太多了。它有一个非常重要的地方，如果你没有选对，很可能造成整个性能下降非常严重，控件利用率非常低。选数据格式中最重要的有两点，一是可分割，二是可块压缩的。可分割的是CSV、JSON记录。可块压缩的是每一个分出来的块都是可以压缩的，哪些不是可块压缩的？比如GC压缩软件，它一定要把所有的块连在一起才能一起解压，它不是块压缩的。因为所有的分布式计算都要把数据并行发送到每一个节点上，如果不是可块压缩的，每次处理都要把所有的数据垄在一起才能处理，我们这里列举了一些支持可分割的是Avro、Lzop。这是我今天的分享，谢谢大家。

提问：我们处理日志的时候，不能用Hadoop处理，我们用这样的功能很多，我们要把标准化提供给不同的部门，不能说是标准化数据，我们要把数据处理方式统一发出去。我们做处理时和做数据仓库时应该怎么思考。

李威：你的问题是要处理的数据源种类特别多，你要给别人是统一的。

提问：我对别人不能提供SQL的标准，我希望提供一种API出去。

李威：有几个地方可以说，你涵盖的层面比较多。一是你可以通过从数据格式的层面，你可以用通用的格式，Hadoop的格式非常通用，你可以把数据处理完后转换成别的格式，这样所有要用到处理结果的产品都可以这样处理；二是你需要自己提供比较好的API，我建议你用SQL的方式比较好。

提问：上面的业务层，下面的数据层。

李威：还有一点可以处理，如果你的源数据非常多，处理后你要消费数据的点也特别多的时候，可以考虑中间把所有的数据塞到Kafka，有高吞吐量的消息队列里，让所有需要处理的消费数据的产品都订阅这个队列，这时候Kafka相当于提供了很好的API给所有的数据消费者使用。