7月18日,"云用户生态发展论坛暨第三届中国云计算用户大会"在北京国家会议中心召开。在下午的会议中,青云QingCloud系统工程师及大数据平台负责人李威带来主题为“大数据云平台之最佳实践”的精彩演讲,以下是他的演讲实录:
青云李威:在云上做大数据平台有什么独特的挑战
李威:大家好,我是QingCloud青云的系统工程师李威。今天我讲的这个话题可能技术性有点强,可能需要大家费点脑子。分成几大块。第一,先说一下云计算和大数据的关系。第二,在云上做大数据平台有什么独特的挑战。第三,我们会讲一下大数据平台它有一个比较基本的,或者说通用的一个系统架构是什么样子。最后,分享一些我们自己的,包括和在客户那儿的一些跟大数据相关的最佳实践。
大数据的例子,我就不说太多了,说一些我们的一些企业客户的。比如说第一个是一个非常大型的一个跨国的一个互联网社交企业。然后他们会用我们在云上的大数据的一些平台,包括一些具体的技术,会做比如用户画像。就是你在社交网络里面,然后为什么推荐给你的朋友正好是你可能会认识的,然后为什么推荐给你的信息可能就是你感兴趣的。这个都是用户画像用大数据来做的。
第二,像一个非常大型的互联网的金融企业,它会用大数据做一些风控分析。因为在互联网金融,尤其是互联网金融行业里面,它之所以可以和传统金融PK,就是因为它在风控这方面可以用大数据技术把风险控制的非常小。大家可以想一想,在P2P平台上面,凭什么没有像以前传统银行各种人来调查你,没有什么抵押金,但是可以让你用钱。包括政府部门海量信息检索,比如它需要把全国的各种部门联合起来,然后我需要有一个犯罪嫌疑人他有没有可能在各个地方有一些其他数据,我可以搜索,可以挖掘,然后进行一些分析。
大数据很火,它跟云计算到底什么关系?其实我们认为大数据现在大家可能觉得到什么地方都听见大数据,其实很可能每个人说的不一样,也得人说的是大数据平台,有的人说的是大数据的某个产品,有的人可能说的是大数据的某个应用,比如AlphaGo。
尤其在企业里面,我们和客户谈的时候,客户第一个比较想不明白的就是大数据的产品和技术太多了,而且每个场景都区别不是那么明显。所以,在大数据这个技术里面,我们第一个要解决的就是到底怎么选择大数据的解决方案,怎么为企业做大数据解决方案。但是,每个企业需求变化又特别大,或者有很多企业,就是传统企业他们对大数据的需求不是非常明确,互联网企业他们需求变化非常快。按照传统的比如建一套大数据平台,可能花费很多成本,时间成本、人力成本,包括金钱。但是云平台,大家知道IaaS、PaaS、SaaS,最后所有东西都变成服务器。你要构建一个非常复杂方案的时候成本就低,因为你只需要按照服务构建的方式来做,而且这样非常灵活,如果你发现其中方案某一部分有问题,你可以很快的替换掉,因为很多都是平台上的服务。所以,它可以满足你的业务不确定性的需求,包括业务弹性的需求。因为大家知道现在变化太快了。
第二,云计算给大数据带来的好处是什么?比如它可以自动化运维,一些复杂系统的安装、部署、监控都不用你自己做,在界面上非常快的就可以,非常简单就能做完。然后还有一些包括稳定、性能,这个不多说了,云计算的好处大家肯定知道特别多,说几个有意思的。
比如,网络和存储,计算引擎的切换,这个比较有意思。也就是当你的平台足够复杂,足够大的时候,每块部分都是一个服务器,每一块变成一个服务器之后,可以非常灵活的替换掉它,把他换成别的产品实现,或者别的技术实现。后面就是ServiceOrchestration,就是比如你有一个界面,需要画各种图,或者工具也好,但是他们有一个非常致命的缺点,你画的那个图是不能执行的,就是是不能部署,不能执行的。ServiceOrchestration是给你一个大的拓扑图,这也是青云今年年初发布的一个产品,叫做资源编排。可以在云平台把一整套的架构部署出来,这是云上他们这些带来的一些好处。
云上大数据平台的挑战。很多企业做大数据平台在物理机上做,为什么没有在云上做?因为挑战非常多。第一,稳定性的挑战,比如高可用、灾备。第二,性能。一直被人垢病的,因为你是虚拟机,肯定没有网络机的硬盘快。在青云第一个IaaS层的稳定性已经运行好几年了,没有太多可说的。垢病性能这一块,我们去年做了软件定义网络的2.0,2.0出来之后,这个是为云计算,为大的IaaS平台专门研发的一套SDN,可以做到点对点之间的网络传输,可以达到物理网卡。第二,在硬盘这块一直被垢病的,我们容器技术,可以把硬盘的技术降的非常低。第三个好处就是迁移,迁移技术非常好,因为现在已经有一些比较成形的,比如关系型数据库和非关系型数据库。
我们说解决这些挑战之后,我们会有一个大数据的平台系统架构出来这个架构其实都是一个非常通用的架构。就是你可能在很多企业里面,不管京东、美团、亚马逊,可能看到的基本都是这样的样子。其实先从左开始看起,其实是一个数据的生命周期,就是数据从哪个地方收集,可能是日志,可能是传感器,收集过来到中间的核心平台,最下面一层就是IaaS,青云所有PaaS层的服务都是基于IaaS做的,就是都是在云上面的。然后到第一个就是存储。中间三个大块,第一个叫实时计算,叫Storm,当然Twitter现在出来的可能宣称比Storm更强。第二,就是BatchProcessing,第三个就是BigSQL,包括像Kylim等。右边就是你做所有平台可能都会做的,包括它的数据管理、监控、安全,包括用来做分布式的配置中心的一项东西。
所有的数据经过存储、计算之后,你可能会通过一些,就是你想要一些非常好的用户友好的方式使用这些数据,我们一般可能会把数据提交到比如说像一些交互性比较好的技术组件里面,这样在最上层,不管报表还是可视化,像Hadoop生态圈里面比较流行的做可视化就比较方便。
我现在画的这个图里面,基本上就是在大数据的生命周期里面最核心的,或者说最主流的产品或者技术都涵盖在里面了,青云自己的大数据平台也是按照这个架构来做的。
接下来先说一下,我会按照这个架构,挨个的挨个的说。第一,先说一下计算。计算上面最经典的就是Hadoop,这个图不需要太多说。如果大家平时研究大数据,可以提一点,从2.0后之,它的HDFS有高可用,把之前的变成Yarn来支持,这样会提升很大的性能。第二个计算型的架构就是Spark,比如它上面有主流的一些功能。如果做实时计算,Storm肯定首选的。MapReduce延迟非常高,但是吞吐量很大。MapReduce的硬盘非常高,SparkStreaming由于它是硬盘计算,所以计算还好。如果之前有一些Hadoop生态圈的基础,可能选Spark比较好,如果不是要求非常实时,因为Spark平台非常强,它本身就是一个平台,现在的平台发展非常快,所以可能选Spark,对你要求非常高,现在我们碰见的客户都有。第二,BigSQL里面,提几个,一个是Phoenix,提供了SQ语言上包装的产品。第二种就是MPP的。
存储。最初就是HDFS,第一,一定是为大文件设计的,不是为海量小文件设计的。如果想处理海量小文件,在青云平台上有一个想象就是对象存储,我们当时设计的时候不管文件什么类型,不管文件什么大小,都可以用这个存储。HDFS为什么不能存海量小文件,原因很简单,像Linux里面所有数据都有一个索引,如果存海量小文件,索引的数据有一个特点,不管数据文件大还是小,索引的数据都是一样的大。存海量小文件的时候其实文件没有多大,它会非常影响性能,导致数据整个存储空间没有利用慢,但是性能已经不可用了。
第二个比较主流的存储就是Hbase,Hbase是架构在HDFS之上,它可以存非常宽的样表,也可以存非常高的样表,所有表的数据分布在每个节点上,其实它的架构比这个复杂多了。其实你可以看成对应一个表的概念。不知道大家有没有人看Hbase,可能刚开始看Hbase比较费解,因为它是列式的存储,和以前看到的数据库解的不一样。其实它的定义非常简单,就是最上面,第二行那句话,是一个稀疏的、分布式的、多维的、持久化的一个影射。稀疏的就是是一个单位格的比,Hbase在存储格式上已经解决了这个问题,可以存一个稀疏的表。第二,分布式的就不用解释了。这个图里面可以看到有一些时间戳的概念在里面,这是一个比如第一个是一个记录的RowKey,然后有一个ColumnFamilies,然后有一个版本号。
存储里面的选型,刚才说了几个,做存储选型怎么选?并不一定是一开始肯定会听到很多人说Hbase一定比HDFS快,这些说法都是不责任的,都是一定要在什么场景下。比如说Hadoop,这样的方式就是在做全局文件扫描的时候是快的,但是像Hbase做随机存储的时候是快的,所以也是分场景的。但是像中间这个KUDU,昨天一个客户说他们正在用一个KUDU,属于一个中间的方案,介于HDFS和Hbase之间的一个存储引擎,现在还没有看到大规模的生产应用。这个就是今年年初做的一个数据仓库,GreenplumDatabase,是去年开源的。之前Greenplum的核心就能工业他们自己出来,它最大的一个好处,我们觉得有几个,第一个是标准的SQL,你可能看到很多市面上的产品都说支持SQL,但是其实都不是标准的。不是标准的意味着什么?比如很多语法不一样,你以前像数据工程师,数据分析师,他们用的比较高级的用法都没法用。但是,GreenplumDatabase不一样,因为它的核心计算引擎我们觉得比MySQL更好,它还有很多别的特点。
我们说完计算的产品,说完存储的产品,接下来一些数据的传输。数据传输我们说一个最经典的Kafka,是分布式、可分区、多副本、低延迟的。低延迟什么意思?左右这两张图长的很像,其实就是Kafka相当于进入和留出的数据,Kafka就是领英开源的,因为我们平台提供了Kafka服务,他们现在也在用,这是他们是使用出来的一个产品。意思就是Kafka的延迟非常低,基本数据不落下来,直接就出去了。
为什么它可以这样?有两个非常本质的原因:第一,它在写数据的时候是直接写到PageCatch里面,往外发的时候直接通过Linux发出去的,所以它的吞吐量延时非常低,这是两个核心的原因。Kafka的架构非常简单,就是三个松偶合的,比如最上层是它的生产者,然后是一个集群,中间是一个服务器,Kafka的服务器,下面是它的消费者。它的生产者一个集群都可以往broker里面发数据,相当于broker把数据发到第一个Partition里面,第二个发到第二个Partition里面,Partition第一个主要概念就是你发布的消息是什么,你生产出的消息相对于在Kafka里面有几个队列,每个队列就是一个Partition。
第二个集群就是它的消费者,消费者可以提比较重要的一点,它有一个消费组的概念,这个组的概念非常重要。当你想把一个Topic的消息想多播出去,想被很多个消费者处理的时候,这个时候需要建多个消费组,这个消息才能被多个消费者来消费。如果只建了一个消费组,哪怕这个消费组有好几个消费者,每次都是由一个消费者处理的。第二个问题,就是消费组里面消费者的数量,这里面一个是两个,一个是四个,就是一个消息里面有四个Partition,如果有四个消费者,正好一对一,每个消费者消费一个Partition,如果只有一个消费者,有一个会消费两个Partition。这种情况比较好。有一种情况要避免,就是比如有5个消费者,你那个Topic只有4个队列,你就会浪费掉一个消费者。这个是需要注意的。
说完了计算,说完了存储,说完了传出,然后说一些我们碰到的问题。第一个大问题就是复制因子的问题,为什么原生的不用考虑,但是云上为什么要独特考虑呢?原因很简单,因为在云上面所有的服务都是基于IaaS做的,IaaS这一层本身有高可用,就是它的数据本身就是有副本的,如果你还照搬物理机上的做法,你就找三个副本,你想想2×3就是6个。所以,第一个就是要去副本,把它用两个副本,这是我们最开始想的方案,用两个副本就行了。但是,后来我们觉得两个副本还是2×2=4,还是空间浪费上会多一点。
后来我们想更高级的方案是什么?就是我们在IaaS这一层提供一种能力,让PaaS层可以选择,说我要几个副本,就是变成一个选项,这样比如像大数据这样,或者非常脆弱的应用,但是有时候比如不需要,有它自己的一个副本的策略,完全不需要IaaS层的副本,这个时候就根据你自己的配置,或者根据你自己的产品的需要可以配置IaaS层的副本策略,这样跟物理就是一样的了。
这个参数调优,比如像典型的大数据里面每个产品或者每个平台都有两三百个参数,这个太正常了,这个时候做调优第一个重要的步骤就是你应该知道我们应该尽量去知道这些调优的参数之间什么关系,他们之间到底什么关系,不能只知道每一个参数是干什么的,要不然调一个,影响另外一个,或者调按没有任何反应,那是因为你没有把这个关系搞清楚。像这样的图,可以把yarn里面的NodeManager都弄的比它小,然后是yarn里面分配的内存,这个之间的关系嘎明白,在做性能调优的时候是很重要的。
最后一个比较重要的最佳实践就是在数据格式上,这个肯定很多人都会忽略。但是在大数据里面非常重要,为什么?因为数据很大,数据量非常大的时候,如果不注重数据格式就会导致这几个问题。比如可能性能会下降,然后你的空间反而浪费了很多,成倍的上升。
其实数据格式比较注意的项非常多。我们挑出两个比较重要的准则,第一这个数据格式要可分隔。可分隔支持的格式有这些,比较多的像Avro、ParquetLzop index、SequenceFile,不支持的就是XML、JSON文件。
然后可块压缩的,支持的就是Avro、Parquet、Lzop index、SequenceFile,不支持的就是CSV、JSON记录。大家可以想一下,我们在大数据平台里面计算都是并行计算,它所有的数据都是分开来计算的,然后每一个分片对它进行计算,所以,第二个是可块压缩的。其实还有很多点,比如数据格式是不是支持眼镜的,像Avro就支持,就是数据格式的老版本和新版本还是可以兼容的。包括像SequenceFile,可伸缩,可压缩,但是它只在Hadoop这个生态系统,不像Avro和Parquet。