英语原文共 38 页，剩余内容已隐藏，支付完成后下载完整资料

Building a Hybrid Warehouse: Effificient Joins between Data Stored in HDFS and Enterprise Warehouse

构建混合仓库:HDFS与企业仓库数据之间的高效连接

Hadoop分布式文件系统(HDFS)已成为企业中重要的数据存储库，并且已然成为包括SQL查询、机器学习以及报告等所有业务分析的中心。而与此同时，企业数据仓库（EDBs）仍旧支持着关键业务分析。这就产生了在类似Hadoop的大数据平台和众多EDW之间建立新一代特殊联合的需求，我们称之为混合仓库。有许多应用需要将存储在HDFS的数据与EDW的数据相关联，例如将存储在HDFS的点击日志与存储在数据库中的销售数据相关联的分析。假设Hadoop端没有有效的SQL支持，所有现有的解决方案都会联系HDFS，并将数据读入EDW来执行连接。

在本文中，我们展示了这样一个结论。当我们在Hadoop端利用复杂的执行引擎进行连接时，在HDFS端进行大部分数据处理表现更好。我们通过研究连接数据库和HDFS表的各种算法来确定最佳的混合仓库体系结构。我们利用布隆过滤器最大限度地减少数据移动，并最大限度地利用两个系统中所拥有的大量并行性。我们描述了一种新的Zigzag连接算法，并证明它是一种适用于混合仓库的健壮连接算法，在几乎所有情况下都表现良好。我们进一步为各种连接算法开发了一个复杂的代价模型，并证明了在不同的谓词和连接选择性下，它可以帮助混合仓库中的查询优化选择正确的算法。

1.引言

Hadoop分布式文件系统(HDFS)已成为企业数据的核心存储系统，包括企业应用程序数据、社交媒体数据、日志数据、点击流数据和其他互联网数据。HDFS受欢迎的主要原因是它有许多优点，包括可扩展性、弹性和极低的代价(商用硬件和开源软件)。众多企业也都在使用各种大数据技术来处理数据并获取可行的见解。 HDFS充当存储，其他分布式处理框架（如MapReduce和Spark）可在其中访问并处理大量数据。

同时，企业数据仓库（EDW）继续支持关键业务分析。EDW通常是不共享的并行数据库，支持复杂的SQL处理、更新和事务(在本文的剩余部分中，我们使用EDW和数据库交互)。因此，他们管理最新数据并支持各种业务分析工具，如报告和仪表板。

现如今也出现了许多新的应用程序，它们要求访问和关联存储在HDFS和电子数据仓库中的数据。例如，运行广告活动的公司可能希望通过将存储在HDFS的点击流数据与存储在数据库中的实际销售数据相关联来评估其活动的有效性。这些应用程序，加上HDFS和电子数据仓库的共存，创造了在类似Hadoop的大数据平台和电子数据仓库之间的新一代特殊联合也就是混合仓库的需求。

为什么说强调混合仓库的独特挑战非常重要:

（1）我们正在处理两个完全不同的系统。一个全耦合的关系型数据库(EDW)和一个基于SQL-on-Hadoop的查询处理器具有非常不同的特性。首先，数据库拥有自己的数据，并且它控制着分区和数据组织。而对于一个SQL-on-Hadoop的查询处理器来说，情况就不一样了，因为它可以处理HDFS上的现有文件。它们并不规定数据的物理布局，因为在处理之前将千兆字节的HDFS数据转换成专有格式是不允许的。这从根本上不同于数据库。第二，数据库可以有索引，但是SQL-on-Hadoop的处理器却不能利用相同的记录级索引。因为它们不控制数据，所以可以在查询处理器的控制之外插入数据。此外，HDFS没有提供与本地文件系统相同级别的小读取性能，它主要是为大扫描而设计的。最后，HDFS不支持就地更新，因此，SQL-on-Hadoop系统主要用于处理没有更新或经常更新的数据。这两个系统之间的差异使得这个问题既混合但又不太对称。

（2）在容量和群集设置方面也存在差异。EDW通常部署在高端硬件上，而Hadoop/HDFs通常部署在商用服务器上。Hadoop/HDFS集群通常具有更大的规模(多达10，000台机器)，因此比EDW集群具有更多的存储和计算能力。事实上，今天越来越多的企业投资已经从电子数据仓库转移到像Hadoop这样的大数据系统。

（3）最后，混合仓库也并不是两个数据库之间的典型联合。现有的联合解决方案使用客户机-服务器模型来访问远程数据库和移动数据。他们使用JDBC/ODBC接口来下推最大子查询并检索其结果。这种解决方案通过单个JDBC/ODBC连接串行地接收结果数据，因此仅适用于少量数据。在混合仓库的情况下，需要一个连接到较低系统层的新解决方案来利用大量Hadoop/HDFS端和EDW端的并行性，并在两者之间并行移动数据。这需要两个系统之间相当大的协调和沟通。

1.1现有数据库和Hadoop混合解决方案

许多现有的集成HDFS和数据库数据的解决方案，例如面向Hadoopp 的SQoop和Teradata连接器，都使用实用程序将数据库数据复制到HDFS。然而，清空仓库并使用HDFS并不总是可取的，因为许多现有的应用程序已经与仓库紧密耦合。更重要的是，HDFS仍然没有一个好的解决方案来进行更新，而仓库总是有最新的数据。

与之相反，其他解决方案可以在查询之前以静态方式或在查询时动态地将HDFS数据加载到数据库中以执行联接。这些解决方案隐式假定SQL-on-Hadoop系统无法有效执行联接。尽管对于诸如Hive之类的早期SQL-on-Hadoop解决方案来说确实如此，但尚不清楚当前解决方案对于诸如IBM Big SQL，Impala和Presto之类的是否仍然适用。在过去的两年中，SQL-on-Hadoop解决方案领域发生了重大变化。这些新系统已从MapReduce转向无共享并行数据库体系结构。他们使用在每个HDFS DataNode上执行的自己长期运行的守护程序来运行SQL查询。这些系统不是物化中间结果，而是在计算阶段之间输送它们。而且，HDFS表通常比数据库表大得多，因此，提取HDFS数据并在数据库中执行联接并不总是可行的。另一个重要的观察结果是，企业在Hadoop等大数据系统上的投资增加了，而在昂贵的EDW系统上的投资却减少了。结果就是Hadoop端具有更大的容量。将HDFS数据远程读取到数据库中会给EDW带来巨大的开销和负担，因为现有应用程序已经充分利用了它们，因此需要对其进行仔细的监视和管理。

值得注意的是在新一代SQL-on-Hadoop系统之前，MapReduce的替代大数据平台，例如Stratosphere，Asterix，已经证明了将并行数据库技术应用于大数据处理的好处。

在数据库和Hadoop之间的拆分查询处理已经被PolyBase应用，以此来利用大量Hadoop资源。 但是，PolyBase仅考虑将有限的功能（例如选择和投影）下推到Hadoop，并且仅在两个表都存储在HDFS中时才考虑下推联接。

1.2加入混合仓库

在本文中，我们通过研究有效执行HDFS和EDW数据之间的连接这一重要问题，设想了一个混合仓库的体系结构。我们考虑在数据库和HDFS端执行连接。

我们从改编著名的分布式联接算法开始，并提出在混合仓库环境中可以正常工作的扩展。 请注意，这些联接算法的设计选择权衡与传统的并行数据库联接算法完全不同，因为我们要处理混合仓库中的两个非对称，异构且独立管理的分布式系统。

并行数据库使用各种技术来优化连接并最大程度地减少数据移动。 当参与联接的表中的一个表足够小而另一个表很大时，它们将使用广播联接，以节省通信代价。 数据库还可以利用物理数据组织来进行连接。 它们依靠查询工作负载来识别大型表之间的联接，并根据联接键对它们进行比较，以避免在查询时进行数据通信。

而在混合仓库中，这些技术的适用性有限。广播连接只能在有限的情况下使用，因为涉及的数据通常非常大。由于数据库和HDFS是两个独立的系统，它们是分开管理的，因此不能对相关的表进行比较。因此，当两个表都没有在连接键上分区时，我们需要调整现有技术来优化非常大的表之间的连接。同样非常重要的是要注意，当今市场上没有一个EDW公司有一个很好的解决方案，可以在两个大的表没有被分割的情况下将它们连接起来。

我们利用布隆过滤器来降低混合仓库连接中的数据通信代价。布隆过滤器是一种紧凑的数据结构，允许以受控的误报率非常有效地测试给定值是否在集合中。布隆过滤器虽然已经在分布式关系查询设置中提出，但由于引入了额外的计算和通信开销，因此并未得到广泛使用。在本文中，我们展示了当在集成了两个异构和大规模并行数据平台的混合仓库中通信数据时，布隆过滤器几乎一直是有益的，这与同构并行数据库相反。此外，我们描述了一种新的连接算法，Zigzag连接，它使用布隆过滤器两种方式来确保仅需要参与联接的记录才需要通过网络进行传输。当连接中涉及的表没有好的本地谓词来减少它们的大小而连接本身是选择性的时，Zigzag连接是最有效的。

我们使用商业上不共享的并行数据库IBM DB2 LUW作为EDW，为混合仓库实现了所提出的连接算法。为了加快原型开发工作，并使我们的解决方案能够移植到多个数据库，我们使用用户定义函数(UDFs)提供的可扩展性实现了连接的数据库端操作。请注意，现在大多数EDW都有UDF对可扩展性的支持。在HDFS/Hadoop方面，我们采用了I / O层的原型，来自现有的SQL-on-Hadoop系统IBM Big SQL的调度程序，并使用我们自己的运行时对其进行了扩展以执行联接，该运行时能够进行流水线操作，并通过处理和数据扫描覆盖网络通信。此外，为了实现跨两个系统的联接，我们还通过协调服务增强了HDFS端执行引擎，并提供了以并行流方式将数据高效地移入和移出数据库的功能。这种增强引擎称为JEN。我们观察到，在HDFS上使用如此复杂的执行引擎，通常在Hadoop方面执行联接会更好。这一发现挑战了现有数据库和Hadoop混合的常识解决方案。

最后，为了在不同的查询设置中选择最合适的算法，我们针对提出的联接算法进一步开发了复杂的代价模型，并通过实验验证了其有效性。 由于混合仓库架构引入的复杂性，这种代价模型远远超出了用于连接的并行数据库的代价模型。 它不仅需要捕获两个分布式系统中每个系统的资源消耗，还需要捕获两个系统之间的资源消耗。 而且，它还需要考虑两个系统之间的个体功能和不对称性，此外，我们还设计了代价模型以适合标准优化器框架，以便可以轻松地将其插入为大数据设计的模块化或独立查询优化器中，如Orca。此代价模型构成了混合仓库体系结构中未来优化程序的重要且必要的构建块。

1.3贡献

本文的贡献总结如下:

（1）我们重新讨论了分布式查询处理中使用的连接算法，使它们适应在两个异构大规模并行数据平台之间的混合仓库中工作。我们也利用布隆过滤器来最小化数据移动，并达到利用两个系统中大量并行性的目的。

（2）我们描述了一种新的连接算法，Zigzag连接。它在两者上都使用了布隆过滤器，并提供了一个非常有效的实现，使布隆过滤器计算和交换的开销最小化。我们证明了Zigzag连接算法是一个健壮的算法，在大多数情况下对于混合仓库表现良好。

（3）通过详细的实验，我们看到随着数据量的增长，通常在HDFS / Hadoop端执行连接最好。而这有个前提是HDFS端具有复杂的执行引擎。 这也是混合仓库中的第一项工作，它系统地研究了连接算法，并提出了将计算结果划分为两个系统的解决方案。

（4）首先我们为混合仓库提出了一种架构，其中EDW和Hadoop集群共同执行联接。 其次我们描述了一个叫JEN的系统，在这个系统中我们实现了提出的连接算法。我们想强调的是，JEN不仅仅是一个复杂的HDFS端连接执行引擎，它利用了无共享并行数据库架构所采用的各种优化策略，包括多线程、流水线、基于散列的聚合等等。JEN还包含两个关键组件，这两个组件支持两个独立管理的分布式系统之间的协调和通信，以此来支持跨连接。我们设想现有的SQL-on-Hadoop系统可以通过JEN的功能得到增强。

（5）我们通过描述每个分布式系统内以及两者之间的资源消耗，为各种连接算法开发了一个复杂的代价模型。通过实验，我们也证明了这个代价模型能够捕捉连接算法的相对性能，并在不同的谓词和连接选择性场景下正确选择最佳算法。这也是我们知道的第一个为混合仓库环境中的连接算法开发的代价模型。

2.一个示例场景

本文主要研究混合仓库中的连接问题。我们将使用以下示例场景来说明我们关注的查询工作负载类型。这个例子也可以代表广泛的实际应用需求。

一个零售商，如沃尔玛或塔吉特，在当地商店和网上销售产品，所有的交易，无论是离线还是在线，都被管理并存储在一个并行数据库中，而用户的在线点击日志则被捕获并存储在HDFS。

零售商希望分析顾客在线行为与销售数据的相关性。这需要将并行数据库中的事务表T与HDFS上的日志表L连接起来。一个这样的分析可以表示为下面的SQL查询：

SELECT L.urlPrefifix, COUNT(lowast;)

FROM T,L

WHERE T.category = lsquo;Canon Camerarsquo;

AND region(L.ip) = lsquo;East Coastrsquo;

AND T.uid = L.uid

AND T.tDate gt;= L.lDate AND T.tDate lt;= L.lDate 1

GROUP BY L.urlPrefifix

该查询试图找出拥有东海岸IP地址的客户在在线访问后1天内购买佳能相机的URL浏览次数。

现在，我们来看看示例查询的结构。它在两个表上都有本地谓词，后面跟了一个等联接。此连接还与连接结果上的谓词以及分组和聚合相关联。在本文中，我们将使用这个示例查询来描述我们的算法。

在常见的设置中，并行数据库部署在少量(10到100台)高端服务器上，HDFS部署在大量(100

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[240347]，资料为PDF文档或Word文档，PDF文档可免费转换为Word