脱离jvmhadoop生态圈的挣扎与演化-过往记忆.pdfVIP

脱离JVM？ Hadoop生态圈的挣扎与演化 Spark大数据博客 - 脱离JVM？ Hadoop生态圈的挣扎与演化 新世纪以来，互联网及个人终端的普及，传统行业的信息化及物联网的发展等产业变化产生 了大量的数据，远远超出了单台机器能够处理的范围，分布式存储与处理成为唯一的选项。从20 05年开始，Hadoop从最初Nutch项目的一部分，逐步发展成为目前最流行的大数据处理平台。H adoop生态圈的各个项目，围绕着大数据的存储，计算，分析，展示，安全等各个方面，构建了 一个完整的大数据生态系统，并有Cloudera，HortonWorks，MapR等数十家公司基于开源的Had oop平台构建自己的商业模式，可以认为是最近十年来最成功的开源社区。 Hadoop的成功固然是由于其顺应了新世纪以来互联网技术的发展趋势，同时其基于JVM的平 台开发也为Hadoop的快速发展起到了促进作用。Hadoop生态圈的项目大都基于Java，Scala，Cl ojure等JVM语言开发，这些语言良好的语法规范，丰富的第三方类库以及完善的工具支持，为Ha doop这样的超大型项目提供了基础支撑。同时，作为在程序员中普及率最高的语言之一，它也降 低了更多程序员使用，或是参与开发Hadoop项目的门槛。同时，基于Scala开发的Spark，甚至因 为项目的火热反过来极大的促进了Scala语言的推广。但是随着Hadoop平台的逐步发展，Hadoop 生态圈的项目之间的竞争加剧，越来越多的Hadoop项目注意到了这些JVM语言的一些不足之处， 希望通过更有效率的处理方式，提升分布式系统的执行效率与健壮性。本文主要以Spark和Flink 项目为例，介绍Hadoop社区观察到的一些因为JVM语言的不足导致的问题，以及相应的解决方案 与未来可能的发展方向。 注：本文假设读者对Java和Hadoop系统有基本了解。 背景 目前Hadoop生态圈共有MapReduce，Tez，Spark及Flink等分布式计算引擎，分布式计算引 擎项目之间的竞争也相当激烈。MapReduce作为Hadoop平台的第一个分布式计算引擎，具有非 常良好的可扩展性，Yahoo曾成功的搭建了上万台节点的MapReduce系统。但是MapReduce只支 持Map和Reduce编程范式，使得复杂数据计算逻辑需要分割为多个Hadoop Job，而每个Hadoop Job都需要从HDFS读取数据，并将Job执行结果写回HDFS，所以会产生大量额外的IO开销，目前 MapReduce正在逐渐被其他三个分布式计算引擎替代。Tez,Spark和Flink都支持图结构的分布式 计算流，可在同一Job内支持任意复杂逻辑的计算流。Tez的抽象层次较低，用户不易直接使用，S park与Flink都提供了抽象的分布式数据集以及可在数据集上使用的操作符，用户可以像操作Scala 数据集合类似的方式在Spark/FLink中的操作分布式数据集，非常的容易上手，同时，Spark与Flin k都在分布式计算引擎之上，提供了针对SQL，流处理，机器学习和图计算等特定数据处理领域的 库。 随着各个项目的发展与日益成熟，通过改进分布式计算框架本身大幅提高性能的机会越来越 少。同时，在当前数据中心的硬件配置中，采用了越来越多更先进的IO设备，例如SSD存储，10 G甚至是40Gbps网络，IO带宽的提升非常明显，许多计算密集类型的工作负载的瓶颈已经取决于 底层硬件系统的吞吐量，而不是传统上人们认为的IO带宽，而CPU和内存的利用效率，则很大程 度上决定了底层硬件系统的吞吐量。所以越来越多的项目将眼光投向了JVM本身，希望通过解决J VM本身带来的一些问题，提高分布式系统的性能或是健壮性，从而增强自身的竞争力。 JVM本身作为一个各种类型应用执行的平台，其对Java对象的管理也是基于通用的处理策略 1 / 10 脱离JVM？ Hadoop生态圈的挣扎与演化 Spark大数据博客 - ，其垃圾回收器通过估算Java对象的生命周期对Java对象进行有效率的管理。针对不同类型的应 用，用户可能需要针对该类型应用的特点，配置针对性的JVM参数更有效率的管理Java对象，从而 提高性能。这