当你说你在伪分布式模式下安装hadoop时，你是说你只在一台服务器上运行它？如果是这样的话，它就永远不会像db2那么快了。hadoop和hive被设计成在集群和规模上运行。在一个集群中运行3到4台服务器，您应该会发现，在大型数据集上，您可以看到一些令人印象深刻的查询速度。
检查您是否允许cognos查询服务访问超过其java堆的默认内存量(http://www-01.ibm.com/support/docview.wss?uid=swg21587457)我目前运行8gb的初始大小和12gb的最大值，但仍然设法吹偶尔。
您将遇到的下一个问题是，cognos不知道hivesql的细节（或者我正在使用的impala）。这意味着任何非基本查询都将被转换为selectfrom，也可能是groupby。最大的缺失部分是where子句，这意味着cognos将尝试从hive表中吸收所有数据，然后在cognos中进行过滤，而不是将其传递给它所属的hive。cognos知道如何编写db2sql和所有细节，这样它就可以通过这个工作负载。
查询越复杂，或任何特定于平台的函数等通常不会传递到配置单元（日期函数、分析函数等），因此请尝试对数据和查询进行结构化，以便它们在筛选器中是必需的。
使用配置单元查询日志来监视cognos正在运行的查询。还可以尝试向查询中添加字段，然后将该字段拖到过滤器中，而不是直接从模型拖到过滤器中。我发现这有助于让cognos在where子句中包含过滤器。
另一种选择是在reportstudio中使用passthrough sql查询，并将其全部写入hive的sql中。我刚刚为一组 Jmeter 板做了这项工作，这些 Jmeter 板需要一个500万行的事实表中的前5名堆栈。对于5行，cognos提取了所有500万行，然后在cognos中对它们进行排序。这样做了很多次，突然之间，cognos就要挣扎了。通过passthrough查询，我可以使用impala rank（）函数，只得到5行，比db2在一个适当（但很小）的集群上运行要快得多。
使用hive的另一个考虑因素是您是在map reduce上使用hive还是在tez上使用hive。根据一位同事的发现，在cognos运行的查询类型上，tez上的hive要比map reduce上的hive快得多。