如果我理解的话，您已经有效地将rdbms中的表以原始形式复制到hadoop中，以便将扁平视图创建到一个或多个新表中。你用Hive来做这个。所有这些听起来都不错。
为什么要花这么长时间，有很多种可能性，但我想到了几个。
首先，yarn将分配容器（通常每个cpu核一个），Map器和还原器将使用这些容器来运行查询的并行部分。这将允许您利用所有可用的资源。
我使用cloudera，但我假设hortonworks有类似的工具，可以让您看到有多少容器正在使用，有多少Map器和还原器是由hive创建的，等等。您应该看到大部分或所有可用的CPU都在不断地使用。工作应该以合理的速度完成（也许每分钟，或者每15分钟）。根据查询的不同，hive通常能够将其分解为不同的“阶段”，这些阶段分别执行，然后在最后重新组装。
如果是这样的话，一切都会很好，但是您的集群可能资源不足。但在抛出更多的aws示例之前，请考虑查询本身。
首先，hive有几个工具对优化性能至关重要，最重要的是分区。当您创建表时，您应该找到一些将结果数据集划分为大致相等的子集的方法。常用的方法是使用日期，例如年+月+日（可能是20160417），或者如果您希望有大量历史数据，可能只是年+月。这还将允许您显著地优化可受日期约束的查询。我似乎记得hive（或者它是Yarn）会将分区分配给不同的容器，所以如果您没有看到所有的工作人员都在工作，那么这可能是一个原因。使用 PARTITIONED BY 你方合同中的条款 CREATE TABLE 声明。
选择date之类的内容的原因可能是您的数据在时间（日期）上分布相对均匀。在早期的实现中，我们选择了一个customer\u id作为分区密钥，但是随着我们的发展，我们的客户也在增长。数以百计的小客户将在几分钟内完成，然后数以百计的中型客户将在一个小时内完成，然后我们的几个大客户将需要10个或更多小时才能完成。我们将看到在第一个小时内完全利用集群，然后在最后几个客户中只使用几个容器。不好的。
这种现象被称为“数据倾斜”，所以您要谨慎地选择分区以避免倾斜。有一些选择涉及 SKEW BY 以及 CLUSTER BY 这可以帮助处理可以考虑的大小均匀或更小的数据文件。
请注意，原始导入数据也应该分区，因为分区的作用类似于rdbms中的索引，所以对性能很重要。在本例中，选择使用较大查询所连接的键的分区。有多个分区是可能的，也是常见的，因此基于日期的顶级分区，在join键上有一个子分区可能会很有帮助。。。也许 吧。。。取决于你的数据。
我们还发现优化查询本身非常重要。hive有一些暗示机制，可以引导它以不同的方式运行查询。与rdbms相比，它还很初级， EXPLAIN 对于理解配置单元如何分解查询以及何时需要扫描完整的数据集非常有帮助。很难阅读解释输出，因此请熟悉配置单元文档：-）。
最后，如果您不能让配置单元以合理的方式进行操作（如果它的优化器仍然导致不平衡的阶段），您可以使用一个额外的配置单元查询创建中间表，该查询在构建最终的数据集之前运行，以创建一个部分转换的数据集。这似乎很昂贵，因为您要添加一个额外的新表的写入和读取，但是在您描述的情况下，总体上可能要快得多。此外，有时使用中间表来测试或采样数据也很有用。
编写配置单元不像编写常规软件那样简单——在大多数情况下，您可以很快完成配置单元查询。为了让它跑得快，我们花了10或15次尝试在少数情况下。祝你好运，我希望这对你有帮助。