从数据仓库系统对比看Hive发展前景

   <div id="news_body">     <p>        <strong>文 / 杨栋</strong></p>     <p>        大数据时代的信息爆炸，使得分布式/并行处理变得如此重要。无论是传统行业，还是新兴行业（特别是互联网行业），日常业务运行所产生的海量用户 和服务数据都需要更大的硬件资源来处理。需要并行处理的应用领域主要为网页搜索、广告投放和机器翻译等。从单机应用到集群应用的过渡中，诞生了 MapReduce 这样的分布式框架，简化了并行程序的开发，提供了水平扩展和容错能力。</p>     <p>        虽然 MapReduce（Hadoop）的应用非常广泛，但这类框架暴露出来的编程接口仍然比较低级，编写复杂处理程序或 Ad-hoc 查询仍然十分耗时，并且代码很难复用。目前，Google、非死book 和微软等公司都在底层分布式计算框架之上又提供更高层次的编程模型，将开发者不关心的细节封装起来，提供了更简洁的编程接口。</p>     <p>        目前应用最广泛的当属 非死book 开源贡献的 Hive。Hive 是一个基于 Hadoop 的数据仓库平台，通过 Hive，可以方便地进行数据提取转化加载（ETL）的工作。Hive 定义了一个类似于 SQL 的查询语言 HQL，能够将用户编写的 SQL 转化为相应的 MapReduce 程序。当然，用户也可以自定义 Mapper 和 Reducer 来完成复杂的分析工作。从 2010 年下半年开始，Hive 成为 Apache 顶级项目。</p>     <p>        基于 MapReduce 的 Hive 具有良好的扩展性和容错性。不过由于 MapReduce 缺乏结构化数据分析中有价值的特性，以及 Hive 缺乏对执行计划的充分优化，导致 Hive 在很多场景下比并行数据仓库慢（在几十台机器的小规模下可能相差更大），Hive 的架构如图 1 所示。</p>     <p style="text-align:center;"><a rel="attachment wp-att-11863"><img title="0530图1" alt="从数据仓库系统对比看Hive发展前景" src="https://simg.open-open.com/show/438d726a26e75f5feb85fc0ca39a076e.jpg" width="278" height="159" /></a></p>     <p style="text-align:center;">图 1 Hive 架构图</p>     <p>        强大的数据仓库和数据分析平台至少需要具备以下几点特性。</p>     <ul>      <li>灵活的存储引擎</li>      <li>高效的执行引擎</li>      <li>良好的可扩展性</li>      <li>强大的容错机制</li>      <li>多样化的可视化</li>     </ul>     <p>        本文将简要阐述 Hive 是否完全具备了以上几点，以及与传统的并行数据仓库对比优劣如何。</p>     <p>        <strong>存储引擎</strong></p>     <p>        Hive 没有自己专门的数据存储格式，也没有为数据建立索引，用户可以非常自由地组织 Hive 中的表，只要在创建表时告诉 Hive 数据中的列分隔符和行分隔符，Hive 就可以解析数据。Hive 的元数据存储在 RDBMS 中，所有数据都基于 HDFS 存储。Hive 包含 Table、External Table、Partition 和 Bucket 等数据模型。</p>     <p>        并行数据仓库需要先把数据装载到数据库中，按特定的格式存储，然后才能执行查询。每天需要花费几个小时来将数据导入并行数据库中，而且随着数据量的增长和新的数据源加入，导入时间会越来越长。导入时大量的写I/O与用户查询的读I/O产生竞争，会导致查询的性能很差。</p>     <p>        Hive 执行查询前无需导入数据，执行计划直接执行。Hive 支持默认的多种文件格式，同时也可以通过实现 MapReduce 的 InputFormat 或 OutputFormat 类，由用户定制格式。因为公司的数据种类很多，存储于不同的数据源系统，可能是 MySQL、HDFS 或者 Hypertable 等，很多时候 Hive 的分析过程会用到各种数据源的数据。当然使用多个存储数据源，除了功能上要能够支持导入/导出之外，如何根据各种存储源的能力和执行流获得最优执行计划也 是件麻烦事儿。</p>     <p>        <strong>执行引擎</strong></p>     <p>        并行数据仓库使用优化器。在生成执行计划时，利用元数据信息估算执行流上各个算子要处理的数据量和处理开销，进而选取最优的执行计划。并行数据 仓库实现了各种执行算子（Sort、GroupBy、Union 和 Filter 等），它的执行优化器可以灵活地选择这多个算子的不同实现。此外，并行数据仓库还拥有完备的索引机制，包括磁盘布局、缓存管理和I/O管理等多个层面的优 化，这些都对查询性能至关重要。而这恰恰是 Hive 的不足之处。</p>     <p>        Hive 的编译器负责编译源代码并生成最终的执行计划，包括语法分析、语义分析、目标代码生成，所做的优化并不多。Hive 基于 MapReduce，Hive 的 Sort 和 GroupBy 都依赖 MapReduce。而 MapReduce 相当于固化了执行算子，Map 的 MergeSort 必须执行，GroupBy 算子也只有一种模式，Reduce 的 Merge-Sort 也必须可选。另外 Hive 对 Join 算子的支持也较少。另外，内存拷贝和数据预处理也会影响 Hive 的执行效率。当然，数据预处理可能会影响数据的导入效率，这需要根据应用特点进行权衡。</p>     <p>        <strong>扩展性</strong></p>     <p>        并行数据仓库可以很好地扩展到几十或上百个节点的集群，并且达到接近线性的加速比。然而，今天的大数据分析需要的可扩展性远远超过这个数量，经 常需要达到数百甚至上千节点。目前，几乎没有哪个并行数据仓库运行在这么大规模的集群上，这涉及多个方面的原因。并行数据仓库假设底层集群节点完全同构； 并行数据仓库认为节点故障是很少出现的；并行数据仓库设计和实现基于的数据量并未达到 PB 级或者 EB 级。</p>     <p>        与并行数据仓库不同的是，Hive 更加关注水平扩展性。简单来讲，水平扩展性指系统可以通过简单的增加资源来支持更大的数据量和负载。</p>     <p>        Hive 处理的数据量是 PB 级的，而且每小时每天都在增长，这就使得水平扩展性成为一个非常重要的指标。Hadoop 系统的水平扩展性是非常好的，而 Hive 基 MapReduce 框架，因此能够很自然地利用这点。</p>     <p>        <strong>容错性</strong></p>     <p>        Hive 有较好的容错性。Hive 的执行计划在 MapReduce 框架上以作业的方式执行，每个作业的中间结果文件写到本地磁盘，最终输出文件写到 HDFS 文件系统，利用 HDFS 的多副本机制来保证数据的可靠性，从而达到作业的容错性。如果在作业执行过程中某节点出现故障，那么 Hive 执行计划基本不会受到影响。因此，基于 Hive 实现的数据仓库可以部署在由普通机器构建的分布式集群之上。</p>     <p>        如果当某个执行计划在并行数据仓库上运行时，某节点发生故障，那么必须重新执行该计划。所以，当集群中的单点故障（可能是磁盘故障等）发生率较 高时，并行数据仓库的性能就会下降。在实际生产环境中，假设每个节点故障发生率是0.01%，那么 1000 个节点的集群中，单点故障发生率则为 10%。这个数字并不是耸人听闻的，处理海量数据的I/O密集型应用集群，平均每月的机器故障率达到1%~10%。当然这些机器可能是2~3万元的普通机 型。</p>     <p>        <strong>可视化</strong></p>     <p>        Hive 的可视化界面基本属于字符终端，用户的技术水平一般比较高。面向不同的应用和用户，提供个性化的可视化展现，是 Hive 改进的一个重要方向。个性化的可视化也可以理解为用户群体的分层，例如，图形界面方式提供初级用户，简单语言方式提供中级用户，复杂程序方式提供高级用 户。</p>     <p>        <strong>相关系统</strong></p>     <p>        除了 Hive，近年来业界系统也诞生了其他各种类型的数据仓库，像 Google 的 Tenzing、Dremel、微软的 DryadLINQ、Hadapt 的 HadoopDB 等。Tenzing 和 DryadLINQ 在框架分层上类似于 Hive，Dremel 除了语言层还实现了计算执行层，而 HadoopDB 的目标是结合并行数据仓库和 Hadoop 的优点。</p>     <p>        Tenzing 的目标是支持 Google 对数据的 Ad-hoc 分析，当然之前的分析都是基于传统的关系数据库的。Tenzing 在性能方面做了大量优化，包括编译优化以及对 MapReduce 本身的增强等，这些都使得 Tenzing 的性能在很多方面接近甚至超过了并行数据仓库。另外，基于 LLVM 的 Tenzing 执行引擎可以将单点执行性能提升 10 倍左右。</p>     <p>        DryadLINQ 的目标是对并行程序的开发进行抽象，使其和单机开发一样。与 Hive 不同的是，DryadLINQ 并不是一种全新的语言，它将特定语法直接集成到宿主语言（C#等高级语言），充分利用宿主语言的抽象和组合等编程语言机制。与 Tenzing 类似，DryadLINQ 的扩展性和可用性都依赖于底层的执行系统 Dryad。</p>     <p>        Dremel 是 Google 用于满足交互式查询的系统，主要目标是执行一次性的、结果数据较小的聚合运算，不支持 join、update 等复杂算子。与 Tenzing 和 DryadLINQ 不同，Dremel 没有基于 MapReduce 或 Dryad 之类的底层计算框架，它实现了一个树状的执行层，这个执行层管理节点的失效或竞争，包括优先级等，与 MapReduce 的实现机制相似。Dremel 的底层存储系统是 GFS，基本概念是按列分割数据，把树形结构的数据按列分割。</p>     <p>        HadoopDB 希望整合并行数据仓库和 Hadoop 用于大数据分析，这既能保证高性能，又能提供可扩展和高可用能力。HadoopDB 的基本思想是在节点上运行并行数据库实例，MapReduce 作为这些节点的执行层，尽可能地将执行计划放到并行数据库中完成，利用其已有的优化技术。当然，这会牺牲一部分导入数据的性能，导入数据时会执行一部分表 的布局和重组。</p>     <p>        <strong>总结</strong></p>     <p>        作为互联网领域应用最为广泛的开源数据仓库，Hive 是份免费的午餐，尤其它在扩展性和容错性方面有强大的优势，其前景被大家一致看好。不过对比传统并行数据仓库，Hive 在存储引擎支持、执行引擎高效化以及多样化接口等方面，还有很多工作要做。此外，业界的其他数据仓库，像新兴的 Tenzing、DryadLINQ、Dremel 或 HadoopDB 等，都有 Hive 值得借鉴的地方，Hive 原有的实现也还有很大的优化空间。</p>     <p>        Hive 的诞生带动了 Hadoop 开源栈系统的进一步发展，也使得很多公司能够从零开始快速搭建数据仓库系统，推动了整个产业链的进步。真心地希望 Hive 能够继续成长，不断演进，成为全面而强大的通用数据仓库标准。</p>     <p>        <strong>作者杨栋，百度分布式高级研发工程师，从事 Hypertable、Hadoop 及流式计算的研究和开发。</strong><br /> 来自: <a id="link_source2" href="/misc/goto?guid=4958341994617609458" target="_blank">www.programmer.com.cn</a></p>    </div>