为什么 HBase 全扫描和聚合比 parquet 慢，尽管它也是列式数据库？答案

【问题标题】：Why is HBase full scan and aggregation slower than parquet, despite of also being columnar database?为什么 HBase 全扫描和聚合比 parquet 慢，尽管它也是列式数据库？
【发布时间】：2018-12-23 13:05:48
【问题描述】：

我一直在尝试将“正确”技术用于 360 度客户应用程序，它需要：

一个宽列表，每个客户是一行，有很多列（例如 > 1000）
我们每天运行约 20 个批量更新分析作业。每个分析作业查询并更新一小组列，用于所有行。它包括聚合用于报告的数据，以及为机器学习算法加载/保存数据。
我们在几列中更新客户信息，每天

我尝试过使用 Hbase，第 1 点和第 3 点都满足了。但我发现在 HBase 上进行分析（加载/保存/聚合）非常缓慢，可能比 Parquet 慢 10 倍。我不明白为什么，Parquet 和 Hbase 都是柱状数据库，我们已经很好地分散了 HBase 集群中的工作负载（“每个区域的请求数”这么说）。

有什么建议吗？我是否使用了错误的工具来完成这项工作？

【问题讨论】：

标签： hbase aggregate parquet nosql-aggregation column-aggregation

【解决方案1】：

Parquet 和 Hbase 都是柱状数据库

这个假设是错误的：

Parquet 不是数据库。
HBase 不是列式数据库。它经常被认为是一个，但这是错误的。 HFile不是面向柱状的（Parquet 是）。

HBase 非常慢，比 Parquet 慢 10 倍

HBase 完整扫描通常比等效的 HDFS 原始文件扫描慢得多，因为 HBase 针对随机访问模式进行了优化。您没有具体说明您是如何扫描表的 - TableSnapshotInputFileFormat 比天真的 TableInputFormat 快得多，但仍然比原始 HDFS 文件扫描慢。

【讨论】：

我们在 HBase 上使用 Phoenix 和 Spark SQL 数据帧来读取/聚合/写入 HBase。版本为 HDP 2.5.0，带有 HBase 1.1.2、Phoenix 4.7 和 Spark 1.6
@TungVs 上次我检查时，所有连接到 spark 的 hbase 连接器默认使用 TableInputFormat。
如果我们需要 Spark 连接到 Hbase，我们可以做些什么来提高性能，或者 HBase 不是适合这项工作的工具，还是有“标准”方式/架构解决我们不知道的问题？最近我考虑过像 Ignite 这样的内存解决方案，但它是一个基于行的数据库，因此如果我们只需要缓存几列，这是不可能的（很可能我们没有足够的 RAM 来缓存所有表)。另一个选择是 Kudu，但它的最大缺点是 300 列限制，我们有 1000 多个。
我已经看到再也没有人来回答这些问题了。对于您的回答，澄清原始标题（为什么 Hbase 扫描速度慢）就足够了，所以我会接受它并分叉另一个线程以进一步提问。感谢您的宝贵时间。