大数据处理引擎应该怎么选择

列存储是当今大数据处理和存储领域中经常被讨论的话题，有数百种格式、结构和优化方式可用于存储数据，甚至还有更多的检索方式，具体取决于计划如何使用这些数据。这种众多选项的出现，是由于不仅需要使用在线事务处理（OLTP）工具快速地摄入数据，而且需要使用在线分析处理（OLAP）工具更高效地消耗和分析数据。

成千上万种不同的用例都有其自己的特定需求，因此出现了许多选项。例如，阅读股票市场的股票数据需要完全不同的思维方式，与分析制造业生产线的质量指标也不同。在所有这些选项中，要选择适合自己的工具很容易迷失方向。

我们想通过讨论以下三个工具/引擎及其关联的存储格式来进行比较：

1、Apache Hive使用Apache ORC作为高效的列存储格式，可以为OLAP和深度SQL查询处理提供性能优势。

2、Apache Phoenix/Apache HBase共同组成了一种OLTP数据库，可以在数十亿条记录上进行实时查询，并提供快速的基于随机键的查找和更新。

3、Apache Druid是一种高性能数据存储，可以在事件流上进行实时时间序列分析，并在历史数据上进行OLAP分析，具有极低的延迟。

在本文中，我们打算阐述哪种工具适用于特定的用例，对各种工具进行比较和对比，并提供选择适当的工具或工具集来解决用例的基本指南。

01

大数据处理及其相似性

将数据按列进行分组存储是因为我们通常试图在特定列上缩小求和、平均值或其他计算范围。比如，你是一家航空公司，想要了解停靠时应该给飞机多少燃料。你可能想要从航班数据表中计算出每个航班的平均飞行英里数。这将需要对单个列执行平均函数。我们将使用列式存储格式存储这些数据，因为磁盘上的顺序读取速度很快，而在这种情况下，我们想要做的是从表中按顺序读取一个完整的列（然后执行平均计算）。

这些引擎之间存在许多差异，但无论选择哪个数据处理引擎，都会受益于一些共同点。其中之一是共享缓存功能。这三个引擎都与内存缓存密切配合，以在不改变后端存储格式的情况下提高处理性能，实现亚秒级响应时间。HBase拥有BlockCache，Hive拥有LLAP IO层，Druid拥有几个内存缓存选项。通常，为了响应查询，需要解析请求并去持久存储检索用户感兴趣的数据子集，这是一个耗时的过程。然而，当使用类似于许多列式存储格式所使用的内存缓存机制时，可以避免重复整个步骤，允许进程在几分之一秒内访问先前查询的数据。

让我们回到我们的燃料计算示例：假设我刚刚要求计算公司所有航班的平均飞行英里数，但是我意识到国内航班的燃料需求与国际航班有很大不同。然后，我将希望使用WHERE country='US'（或等效的国家代码）子句过滤我的上一个查询。这种查询模式在数据探索中非常常见。由于我们已经将先前查询的数据存储在内存中，因此可以返回此查询的结果，而无需执行耗时的磁盘读取。Hive的LLAP层结构——其内存空间的一部分用于缓存，而长期存储在HDFS上。HBase和Druid也有类似的缓存和存储的概念。

这些引擎之间存在另一个相似之处，即它们用于定位正在查询的特定数据的快捷方式。HBase具有基于哈希映射的O(1)随机访问，Druid使用倒排位图索引来确定哪些列值在哪些行中，而Hive表则具有统计信息、索引和分区等功能来快捷地访问数据。这些功能使引擎能够将数据存储方式与访问方式结合起来，实现快速分析，同时优化硬件效率并充分利用可用的CPU和RAM。

最后一个相似之处是这些引擎的企业级可用性。

在数据冗余方面，这三个引擎都使用HDFS作为它们的深度存储机制；HDFS的3倍复制因子确保即使两个节点同时故障，数据的副本也存在于其他地方。数据可以立即重新复制到健康的节点上，以保持冗余。

在集群内容错方面，每个工具都以某种方式填补了空白。HBase提供region复制，Druid具有主节点和工作节点的复制以及增加HDFS的复制因子，而Hive具有与YARN框架的容错逻辑一起使用的HDFS。企业级可用性确保这些引擎具有抗故障能力，并且从第一天起就准备好在生产环境中运行。

02

大数据处理引擎之间的差异

获取数据的最佳方式是什么？一旦获取数据，怎样快速的从中挖掘数据价值？让我们深入探讨这三个大数据处理引擎如何支持这些数据处理任务。

由于它们存储和处理大数据的能力，这些引擎有时会组合使用，但正如我们将发现的那样，它们被选择用于特定的用例和目的，而且特别适合它们自身的优势。

Hive是使用最广泛的OLAP引擎，通常使用Hadoop分布式文件系统（HDFS）作为其存储层，允许存储几乎任何类型的数据。它可以查询、处理和分析非结构化文本数据、CSV文件、XML、半结构化JSON、列式Parquet和许多其他格式。Hive还支持扩展其他存储介质，如云存储、Isilon等。Hive推荐的存储格式是ORC，它可以最有效地优化和利用列式存储的优势。一旦转换为ORC，你的数据就会被压缩，并且你表中的列会按顺序存储在磁盘上，允许Hive的内存缓存层LLAP从磁盘中读取数据一次并从内存中多次提供数据。Hive LLAP的组合用于自由查询分析、计算大量聚合和低延迟报告。Hive的一个很好的用例是为用户每天生成报表；重复查询不仅利用了LLAP缓存，还利用了“查询结果缓存”功能。如果数据没有更改，则立即返回结果（附注：查询结果缓存是Hive 3.0中提供的功能）。除此之外，通过使用Hive来创建一个数据仓库，用户可以从多个数据源中组合和查询数据，同时运行多个查询，并使用ACID事务来保持数据一致性。因此，Hive有处理各种类型数据和支持复杂查询的能力，使其成为构建数据仓库的合适工具。在这方面，可以将Hive视为全面的sql引擎，而另外两个计算引擎则适用于快速查询和分析的场景。

HBase，是一个分布式key-value存储，具有随机读取、写入、更新和删除功能。HBase（一种NoSQL变体）旨在成为一个OLTP引擎，允许大量事务操作的架构。比如在用户之间不断交换消息或在金融系统中生成交易的消息平台。HBase非常随机读写的场景。它不适合聚合和连接数据。这个功能是通过Phoenix实现的，它是HBase上面的SQL层和引擎，但不建议处理较大量的数据，因为数据结构不利于实现最佳性能（建议使用Hive代替）。总之，HBase在处理大量的创建-更新-删除操作方面表现出色，但在将数据呈现为用户可消费的格式时表现不佳。

Druid，适用于低延迟的OLAP时序工作负载以及流数据的实时索引。Druid为集群提供快速的多维数据集的OLAP查询。Druid的时序性质是引擎的基础。它是这样设计的，因为在分析基于时间的数据时，时间是一个主要的过滤器。想象一下分析航班时间以预订旅行的场景，想知道在这个特定的2周时间框架内到意大利的成本最低的航班。Druid非常适合快速摄取数据以及在请求时定位数据。另一方面，它也允许业务用户和分析师通过与Druid密切相关的可视化层Superset查询和理解数据。

Druid在数亿或数十亿行数据中快速定位少量数据行方面表现优异，并且在极短的时间内计算这些数据的聚合值。但是它不进行连接，因此不能用于组合数据集进行分析。如果您计划在Druid中分析组合数据集，最好在将其插入Druid之前预连接数据，或者使用Hive（和由Druid支持的Hive表）执行连接操作。换句话说，Druid非常适合在数据经过处理并转化为业务用户访问数据的最后一环。对于业务分析师来说，Druid非常好用，因为他们可以登录Superset，在不编写任何查询的情况下，以仪表板形式可视化指标。他们只需使用GUI选择查询数据源和过滤器。由于其快速查询时间，它还非常适合作为系统监控指标的存储源。

以下是三个工具使用场景的概要：

03

统一SQL

每个系统都有自己的访问数据的方法。为了减少企业对不同工具使用的学习成本，使用Hive 3.0，您可以使用Hive类似SQL的HQL语法与该空间中的许多不同数据存储进行交互。Hive可以用作访问和修改Druid、HBase以及任何提供JDBC接口和驱动程序的门户。Hive可以用来管理一个监听Kafka的Druid摄取任务，为实时摄取提供一种简单的方法。最后，Hive可以用来将所有数据整合在一起——将数据存储在最有意义的地方，并从一个地方访问数据。甚至可以把新的结果存储在另一个地方。可能性有很多，但界面已经大大简化，因此用户可以花更少的时间学习工具，而花更多的时间为业务带来价值。

04

结论

正如我们从前面的分析中看到的那样，Hive、Druid和HBase在数据体系结构中有着不同的地位。它们是相辅相成的工具。您可以通过HBase的快速查找获取事务数据，将数据移动到Druid中进行快速分析/聚合，并让Hive将两者与自己管理的数据集成在一起，使数据分析师能够在不关心数据存储位置或学习新语法的情况下，使用Hive作为单一接口获取知识和洞察力。这种数据架构可以将数据存储在不同的位置，然后通过Hive集成在一起，使用户能够从单个视图中组合数据并获得更多的见解。

此外，Hive 3.0引入了许多重大改进，包括物化视图、与Druid和许多其他引擎的集成以及增加了类似数据仓库的功能，使这些工具可以解决几乎所有的用例。架构师可以设置数据流水线，将数据放在其基于用例的位置，然后数据分析师可以使用Hive来获取知识和见解。这样，用户能够集中精力在发现数据价值上，而不必关心数据存储的位置或学习新的语法。