劲擎Linux 运行Hadoop_Spark的技术创新和经验分享

由咪咪 · 2016年4月27日

演讲嘉宾：IBM Linux技术总监徐宁

速记整理：卫柏仰

今天很高兴能给大家分享一下我们做的一些工作。大家知道IBM提供一个全系列的IT服务。我们从最前面和客户的业务咨询到软件的平台，再到我们硬件的解决方案都有相应的产品提供。刚才工程师也介绍了在Spark方面IBM有哪些贡献。我这个题目实际上是两个部分。第一部分，我会介绍IBM运行Linux的服务器，基于我们的power平台，它对于Spark和Hadoop做了哪些优化和设计。在第二部分，因为我们在过去的一年当中接触了很多客户，在很多场合做了性能的调优和优化的工作，所以我们在这里会分享一下在我们的平台上做Spark和Hadoop的性能调优有哪些经验可以给大家借鉴。这些东西对大家理解Spark和Hadoop的整个计算模式会有比较好的帮助。最后我的同事还会给大家介绍我们在Spark和Hadoop上有哪些创新的技术。

大数据发展到现在这个阶段，它到底需要一个什么样的平台。我在IT行业已经工作十几年了，十年之前和现在对计算的要求是有非常大的区别的。第一个就是CPU和内存的关系。十年之前通常我们做一个传统的数据库，一个CPU配一个2G或4G的内存就可以了。但是发展到今天，大家看到很多的技术开始基于内存计算，像Spark完全就是一种内存计算，包括现在的一些商用，像Hana这种内存计算的模式。随着这些技术的发展，我们看到内存和CPU的配比是大大提高了。在某些应用场合，甚至出现了一个CPU配96G的内存。CPU技术发展非常快，但是内存技术相对滞后一些。所以为了满足一个CPU计算能力的需求，我们就需要越来越多的内存来提供数据。所以在系统的设计中内存的带宽是非常重要的。另外包括分布式计算的发展。分布式计算的发展需要很大的I/O的带宽，每个节点都需要大量的数据访问，因此对I/O的部分也有很高的要求。所以整个大数据、内存和分布式计算是对技术架构有非常大的需求的。我们最新的power8的CPU就是为大数据而生。这个产品在设计的时候就充分考虑到大数据的业务，对大的内存带宽，对高速的I/O需求来进行整个的设计。从另一个方面来说，IBM也非常注重基础技术的研发，只有基础技术的研发才会带来质变的效果。之前的大家都知道是冯诺依曼式体系架构的计算机。CPU是一种处理单元的模式。现在更多的基础架构研究趋向于新的负载。前面提到过人工智能，人工智能就催生了一种神经元芯片。IBM也在研究很多神经元芯片的技术。神经元芯片和传统芯片最大的区别在于，神经元芯片是模拟人脑的。大家知道人脑是通过突触来传递电流的信号。我们神经元芯片现在可以做到在一个芯片里有几百万个处理单元来模拟人脑。虽然和人脑相比还差得很远，但是神经元芯片的技术会带来一种新的革命。神经元芯片再往下发展，计算机就越来越类似于人脑的结构。20年前IBM在做深蓝的时候做的是32个节点的集群系统，那现在一部手机就可以有相同的计算能力。那可能二十年之后，甚至不需要二十年，一个神经元芯片就可以模拟整个AlphaGo的计算效果。另外，比如说量子计算。量子计算很大程度上也会改变整个计算构架和计算效果。

大数据的需求带来的计算体系架构的变化，这里讲到几点东西。第一个CPU技术发展非常快，但内存相对落后。为了满足一个CPU的计算能力，一个是说我们要配备大量的内存，另一个是说我们需要很多级的cache。大家知道多级cache是解决如何满足CPU持续运算能力的一个非常关键的技术，因为每一级cache都会比前一级cache速度快得多。在新的power8构架里面会有四级的cache来提供更高的能力。另外一个就是多点互联的技术。当CPU节点多了，怎么样能够让各节点有非常高的系统互联。从power7的16个socket的CPU需要三跳才能连接，到power8的16个socket的CPU只需要两条就可以直接连接。那内存构架，刚才我们说了，一方面每个CPU要设计超大的内存结构来满足CPU计算时数据供给的问题。同时，大家知道现在计算机的CPU和内存之间是非对等结构。什么叫非对等结构呢？就是说不论是Intel还是IBM，CPU都有一些直连的内存模块。如果一个CPU要去访问另一个CPU直连的内存模块，就会产生一个相比访问本地内存模块的比较大的延迟。怎么解决这个延迟的问题，我们power8的技术相比上一代也有了非常大的提高。上一代中CPU访问远端内存要比访问近端内存慢47%。现在最新的power8只慢10%，非常好的解决了远端内存访问延迟的问题。第三个是说，我们最新的每个CPU的socket可以提供230G的内存访问带宽，这样就为像spark这种应用带来很好的内存访问的性能。第四块叫多线程技术，这个也是现在大家讨论非常多的一个技术。CPU现在越来越快，怎么样充分发挥CPU的性能。多线程技术就可以让多个线程同时跑在一个CPU上来充分发挥CPU的性能。Power8已经可以做到8线程，就是说一个CPU可以同时跑8个线程。我们有些用户在调试Hadoop或者Spark应用的时候，在同样的负载情况下，已经可以把Intel的CPU压满，但是压power8压不满。为什么呢？就是因为我们CPU的能力更强。这也是我们power8 的一个调度优势。大家如果有经验的话，可以去跑一些性能测试。在Intel的CPU上，大概跑一个70%的CPU利用率的话，在前端敲一些命令它就会有延迟。但是在我们的环境下，因为它支持更大的并发的负载。即使在我们的CPU上跑更多的应用，CPU利用率压到90%以上，你的交互依然能保持一个很好的响应。

I/O集成。刚才讲了，我们的I/O带宽从上一代的60G提高到了192G。另外我们有一个CAPI技术。这个CAPI技术可能大家不是很了解，CAPI技术相当于一个加速。就是说，CPU开放一个接口，可以让你的卡和我的CPU结合起来协同工作。我们举一个简单的例子，比如GPU，大家知道在很多情况下，比如机器学习，都会用GPU来进行应用的加速。传统的方式GPU是插在一个PCI的槽上。但GPU和CPU之间的通讯就会受限于这个PCI槽。因为PCI槽是一个I/O槽，它的速度远远跟不上GPU的速度，也远远跟不上CPU的速度，所以GPU和CPU之间的通讯就会产生大量的延迟和损耗。另一方面，GPU插在PCI槽上就相当于一个I/O设备。大家知道系统里对I/O设备的访问是要做内存拷贝的，所有的数据必须要从系统的内存拷贝到GPU的内存上才可以进行相应的计算。这些数据算完了也需要重新拷贝到CPU上系统才能用到这些数据。如果一个应用他们有大量的CPU和GPU之间的数据交换，那这个性能就会收到很大的影响。我们CAPI技术就会解决这个问题。它不是把I/O卡作为一个I/O设备，它是把I/O卡作为一个CPU的扩展。而且它可以直接访问内存。所以使用CAPI技术可以大大提高访问的速度。我们后面会介绍使用CAPI以后比使用传统的CPU性能大概会提高20到30倍。

那有哪些应用场景会非常适合上面所讲的我们Linux Server的一些优化方式呢。第一个就是大数据场景。我们现在已经和很多用户有运行Spark和Hadoop应用的案例。我们发现一个非常有意思的现象。同样一个负载，在Intel平台上把这个跑下来，跑第一遍可能二十分钟跑完，跑第二遍可能二十五分钟跑完，跑第三遍可能又变成十八分钟。它每次跑的速度都不一样而且偏差很大。但是在我们的平台上跑很可靠，比如说第一遍十八分钟跑完，第二遍可能就十八分二十秒，第三遍可能就十七分五十秒，偏差非常小。这就是机器的不同带来的不同。在我们的大数据平台上，可以使用IBM的IOP的平台，这是一个现成的平台，大家可以拿过来直接用。另外我们和星环科技也有很深的合作，他的大数据解决平台也在我们的平台上做一些测试和认证。现在在某些场景上我们可以提供3.65倍的性能跟Intel的平台相比。

第二部分我们谈谈开源的数据库。开源的数据库我们有一些全球的合作伙伴，比如说MariaDB，大家知道MariaDB是MySql的一个分支。包括PostgreSQL的database。跟国内我们也有和巨杉、南大通用有非常好的合作。

第三部分我们和Sap Hana也有很多的合作。Sap Hana已经全线支持我们劲擎Linux平台。Sap是一家德国公司，它对平台的认证是非常严谨的。大家如果去查的话，它和别的不一样。别的比如说认证操作系统，认证机型就可以了。它不一样，它配置都需要认证。这个机器里到底是多少个CPU的socket，到底是多少个内存，它必须要经过认证。这种认证的机器才能去跑它自己的应用。所以你可以看到，可能有些厂商，因为机型比较多，它有几十台，甚至上百台，上百种配置需要去过Sap的认证。因为我们power平台强大的能力，我们power平台他们只需要认证机型就可以了。只要机型的配置是他们设定的下限之上就可以去做相应的工作。所以针对我们power的全系列产品它都只认证产品而不需要去认证整个机器的配置。

第四部分就是云的资源池。现在我们有一些用户已经开始把我们Linux平台放在他的资源池来做整个负载的调用。他的资源池中可能既有power平台，也有X86平台，他需要来进行统一的调用和管理。我们也支持这样的一个集成。

最后我们来说说高性能计算。我们以前叫HPC，High Performance Computing。现在已经有人把它叫做HPA。高性能计算开始越来越多地和大数据或者分析的技术相结合。比如NVIDIA的新一代的叫做NVLINK的技术就在使用我们前面提到的CAPI技术来进行快速的CPU和内存之间的数据交换。在这一块可能再提到block chain，区块链和开放式账本。区块链技术现在在某些领域，包括国外的一些新的研究机构里都是一个非常热的技术。大家知道比特币就是使用的区块链技术。很多人把比特币和区块链对等，但实际上是不一样的。区块链是一种技术，比特币只是采用区块链技术的一种实现。区块链技术解决的一个最根本的问题就是信用问题。现在中国有一些不好的东西，比如说在互联网金融里，有些公司的鱼龙混杂使得大家都不能信任互联网金融里的一些产品或者相应的一些解决方案。我觉得区块链技术和开放式账本会最大程度地保证这样一个产品是可靠的。

以上是给大家简单介绍一下我们整个平台的技术。下面请我们的技术专家来介绍一下我们的一些优化经验。这个技术相对比较通用，可能会带有我们自己的一些技术特点。但是我觉得在Spark也好，在Hadoop也好，大家可以看你关注哪些点，什么样的东西会对你的整个解决方案形成一些瓶颈。通过这些点来看你应该怎么样来调试你的解决方案的性能。

我将给大家做一些劲擎Linux的服务器在运行Hadoop和Spark时候的经验分享和我们的一些具体创新点。

首先我们看一张图，这是我们Linux服务器运行Hadoop的时候截取的CPU的运行图。在这个图上的红颜色，绿颜色，蓝颜色表示在运行大数据的工作负载的时候，我们的CPU正在处理的每一种任务的状态。绿颜色表示CPU正在执行用户的一个任务，红颜色表示CPU正在执行操作系统内部的一个系统调用，蓝颜色表示CPU进入了一种未知状态，它在等待某种东西。一个良好的应用系统，不论是大数据应用系统还是传统的应用系统，它的健康运行状态中CPU的表现应该以图上绿颜色为主。那为什么说蓝颜色多是有问题的。蓝颜色多表示CPU是处于一个等待状态，但等待状态并不等同于空闲状态。CPU在等待的时候是什么事情都做不了的，它在等待某种资源就绪。在我们劲擎Linux平台上，CPU的主频，包括它的SMT，都是非常高的。那么在运行这么一个大数据场景的时候，CPU就出现了大部分蓝颜色这种未知状态。那我们接下来看CPU是在等待哪种资源。通常来说，我们在一个计算机系统中，文件系统中的读取是比较慢的。文件系统的读取相对于内存的访问时间相差很大。而大数据场景的典型特征是数据量大。在Hadoop这样一个计算框架中，它的Map reduce过程中会大量的把数据从文件系统读取到内存中进行计算。然后在下一个Map reduce过程中再进行读取和运算。在这样的过程中就产生了大量的对文件系统的I/O操作。现在改进的Spark虽然号称内存计算，但它也存在中间某个阶段，将内存中放不下的数据刷到盘上这样一个过程。在这个大数据场景中，由于大量的读取刷盘过程，会产生大量的I/O的量，使得CPU等待这个资源。那我们该如何优化呢？首先第一点我们可以采用压缩技术。由于我们保存在文件系统中的数据量越大，每次读取的数据就可能越多。通过减少数据量，当然不是从业务上减少，比如我们可以通过压缩的方式把它减少，那读取的量就会少很多。数据压缩都是可以在HDFS中进行配置的。利用CPU的处理能力来换取数据的存储空间。第二我们可以通过配置更多的磁盘来均衡I/O的读写。这个其实做的方法有很多，包括可以在Hadoop层配置多个读写目录，或者在存储层配置多个盘，可以在存储层中做各种读取。接下来我们在一些Spark场景中，因为有可能需要将内存计算中的数据中途导出来再导进去，有点像操作系统中的swap过程。在这样的场景中，我们可以使用这样一个方案，利用一些SSD或者Ramdisk作为中间缓冲的存储目录，让Spark在数据导出的时候可以导出到较快的I/O设备上，这样就可以减少由于I/O层面导致的性能下降。当然我们还可以利用一些服务器产品的一些特性，比如PowerLinux，也就是劲擎Linux的Easy Tier功能。它在数据的存储层面，在硬件层面，可以自动对数据进行分层，对数据访问层进行智能的挪移，把一些经常访问的数据放到速度较快的盘上去。

接下来我们看第二张图。这张图看起来有点像股市大盘。这张图是操作系统在运行过程中有关网络的一个截图。

这个图的意思是说，在刚才那张图解决完CPU的问题之后，系统运行起来了，我们又对同样的系统做的一个监控，抓取的一个截图。每一行是一个时间点的记录。第一列是网络的receive，表示的是操作系统这一秒钟在这个网卡处进来的数据量，第二列是send，表示这一秒钟发送出去的数据量。谈到网络，我们要注意一个物理限制。我们现在使用的网卡一般都是百兆卡，千兆卡，再高端一些有万兆卡。这些百兆卡，千兆卡，万兆卡每秒钟单向传送的极限大概是带宽除以十，比如千兆卡的极限就是一百兆。单向传送的时候如果有一百兆就可以认为这个卡到极限了。这个意思就是说这个卡中的数据已经发送不出去了，再发送的话需要在队列中排队才能发送出去。万兆卡除以十也就是一千兆。我们看这个图中，当时监控到数据的收和发都已经到了一千兆左右。所以在大数据的场景中，网络经常会影响系统的性能。网络可能出现的一些性能瓶颈会导致大数据集群无法再提高性能。下面是一些方法。首先第一个还是数据压缩，利用CPU的额外的处理能力在数据发送之前进行压缩，减少数据体积。第二点可以利用服务器上的多块网卡做一个负载均衡。一个端口是千兆的，那两个端口就是两千兆的。可以把这两个端口做一个Bond来把这两个端口聚合。还有一个就是可以做一些网卡TCP的调整。因为Linux方案其实是一个可调试性非常强的系统，它能适合各种不同的应用。对不同的应用它都有相应的内核插座都可以去调谐。我们可以针对网卡插座进行一些适应性的调整。

如果说一个服务器，它有很强劲的CPU，有很多的内存，比如说劲擎Linux，那它能对大数据集群带来哪些好处呢？或者说我们应该如何配置，才能把机器的资源用满。下面举一个例子。这边截取了一些参数。我们运行的这个Spark例子取得的是配置在一个集群的一个节点上的。运行这个spark应用的是劲擎的一个PowerLinux的822L节点，它有20个物理核心，有512G的内存。其实我们IBM的一个物理核心可以支持SMT8，也就是说它可以同时开启8个物理线程。20个核心乘8线程就是160个CPU。我们在配置的时候，就是想办法把这160个CPU，512G的内存都用起来，这样才对得起采购的这台设备，才能让数据分析的业务运行的更快。我们知道在Spark集群里有上百个参数，但影响Spark集群并行度的参数有哪几个呢？我们总结了这几个：SPARK_WORKER_CORES，SPARK_WORKER_MEMORY，SPARK_WORKER_INSTANCES。

SPARK_WORKER_INSTANCES这个参数是说在这一台物理机器的节点上，可以同时并行的Spark实例的数量。打个比方来说就是在这一个屋子里有几个可以干活的人。

SPARK_WORKER_CORES表示在一个INSTANCE里可以并行地执行任务的线程数量。至于一个Spark实例可以用到多少资源，是靠SPARK_WORKER_MEMORY来加以限制。

SPARK_WORKER_INSTANCES设为8，SPARK_WORKER_CORES设为18，SPARK_WORKER_MEMORY设为60。8个实例，每个实例有18个执行任务线程，8乘18等于144，小于160，剩下CPU资源留给操作系统使用。接下来再看内存，8乘60等于480，剩下32G留给操作系统。我们可以看到集群的并行度对性能有什么影响。这是我们做过的一个例子，我们设定了不同的并行的任务数，在不同的情况下，不同的组合做相同的Hadoop WordCount实验。我们可以看到SPARK_WORKER_INSTANCES为3，SPARK_WORKER_CORES为96的时候，可以将200GB的WordCount查找降低到2分钟，而默认的情况下是要将近5分钟的。所以通过调整不同的配置可以将运算时间降低一半。

我们接下来看一下IBM JDK在大数据所起的作用。其实大数据，包括Hadoop和Spark，它的底层都是一个JDK，从传统技术人员来说，就是一个java。这个java的好坏就会影响在大数据平台上跑的一个好坏。一个解决方案想了一个不好的JDK那可能就会比较糟糕。在IBM自己的Linux服务器上预装的都是IBM自己的JDK。那我们来看一下IBM的JDK在大数据里面有哪些好处。在最新版本的JDK8发行版中，提供了大量的针对Spark的优化。这些优化分布在Garbage Collector，内存回收，垃圾回收，java类库JCL，VM虚拟机核心和JIT代码转换。IBM的JDK开发队伍透露计划说他们正在做一些JDK和GPU的工作。刚才徐总也说了GPU可以做很多CPU的事情，而且效率可能比CPU更高。他们也在研究是不是JDK有些工作可以让GPU去做。甚至还有一些CAPI+Flash可以作为机器的一个内存扩展。

我们看一个JDK优化的例子，IBM JDK和Open JDK 。Open JDK其实就是Oracle JDK的一个社区版。这是一个比较例子。这个例子是HiBench。在相同的机器配置，相同的测试环境下，HiBench的结果数字越高表示越好。我们先看一下这个表格什么意思。表格中从左到右依次是，HiBench中各个子项，优化过的IBM JDK8，未优化的IBM JDK8，优化过的Open JDK。我们取Open JDK的成绩作为基准。我们可以看到IBM JDK8相对于Open JDK有很优异的表现。

下面是我们IBM JDK的一些优化的要点。首先是开启SMT多线程技术。开启这个选项后一个CPU可以同时执行8条指令。第二点设定java进程与CPU进行绑定。因为在多CPU环境下，比如说像刚刚这个二十核，它开了多线程之后就是160个核心。默认情况下这些操作系统的进程是会在CPU之间来回切换的，它会根据你的调度来回切换。那这样就会出现一些上下文的转移，暂停，打断。当我们把这些进程和CPU进行绑定之后，进程就可以固定在那些地方，不会发生多CPU环境下的切换。还有一个技术是开启PowerLinux服务器的16M 页面。我们知道Linux默认情况下64K的页面，16M的页面就成为大页面。大页面可以减少页面边界的数量，从而提高硬件预取的成功率。接下来是比较重要的一个，就是我们要会调整进程的HeapSize和GC策略。我们可能会经常碰到这些问题，一个集群可能有很多个节点，在某个节点上executer或者datanode突然崩溃，不见了。那具体怎么解决这些问题呢？首先第一点先做一下优化，启用64位指针压缩技术。因为64位的JDK寻址空间大，地址长度较长。我们可以把地址进行压缩。第二点关闭一些显式的GC调用。再就是启用Power硬件预取。这些是固定三板斧。下面是在经常出问题的Spark进程或者datanode进程中，把GC的verbosegc打开。这样就可以根据这个来设定合适的GC策略，从而很好地解决集群不稳定的问题。

接下来我给大家具体介绍IBM的一些黑科技。首先是CAPI+Flash+NoSQL。CAPI可以让卡机直接访问内存，绕过I/O接口。POWER8的CAPI+Falsh解决了NoSQL领域内存不够的问题。我们知道Redis是内存数据库。随着业务量的增长，数据量的增长，对内存的使用也会增长。一个节点、一个服务器的内存是有限的。数据量这么大，解决方案就是加节点加机器，构建新机群。节点越来越多，管理起来越来越麻烦。在节点之间的互相通信、网络传输和拷贝的损耗也越来越多。那IBM怎么解决的呢？IBM有自己的Flash闪存加速技术。这个技术好处是它的扩充性远远优于内存，而响应速度虽然不及内存，但是基本上跟内存处在同一的档次上。而且它的价格也便宜。通过CAPI把Flash接起来之后，Flash就可以作为操作系统的扩展内存，Redis就可以把数据放到Flash上去。

下面是GPU。我们很多产品也在利用GPU的技术，包括IBM JDK和IBMDB2里的一些模块，会用GPU来做一些加速。还有一个黑科技叫Hadoop的Erasure Codes。我们知道Hadoop存储备份需要存储三份。但是当集群越来越大的时候，造成的存储浪费是很严重的。那在Hadoop里有没有像传统的采用raid的机制，就像raid5，既能保证可靠性，又不用那么多副本。Hadoop里面其实也有。Google、Facebook和Microsoft，他们在自己的云计算环境中都已经有了相关的研究。通过类似于raid5机制减少副本的容量。通过当前的一些算法，编码解码已经可以将副本从3份降低到1.5份左右。但现在Erasure Codes算法还不是一个标准。Microsoft、google和Facebook都有自己的算法。一个好消息说，Hadoop在3.0的时候将在HTFS里提供这个功能支持。刚才讲的Erasure Codes可能通过某种算法实现了，但这些算法是软件层面实现的，会对CPU产生大量的消耗。IBM所做的事情更高远一点。我们有CAPI、有FPGA的这些技术，我们能不能把Erasure Codes这种删除码算法做到FPGA里面去，由它来实现高效的编码解码过程呢？其实我们IBM已经实现了。

我要讲的内容就是这些，谢谢大家。本文相关PPT与音频下载请点击【查看】。