I-P*_* Ou 2 hadoop hbase hive apache-phoenix
Phoenix 是否适合 ETL 和聚合？
我正在尝试对我的数据进行一些 ETL。现在我正在使用 hbase 来存储我的数据（在我们网站上的足迹）。我需要对这些数据进行一些聚合，例如每个网址的页面视图...等。
根据我的研究，我知道hive可以对hbase数据进行ETL，而且hql提供了sql语言，因此我们不需要自己编写map-reduce代码。但是当我尝试使用 hive(pyhive) 在 hbase 上查询时，需要很长时间才能完成。此外，如果我有phoenix在hbase上执行sql，我的hbase上还需要hive吗？
现在当我尝试使用一些复杂的sql时，phoenix会超时。而且蜂巢非常非常慢。那么对hbase数据进行ETL有什么好方法呢？
如果您有 OLTP 类型的查询，即您的查询模式仅限于点获取或小范围查询，那么 HBase 是一个合适的选择。
Phoenix 只是 HBase 之上的 SQL 层，它为用户提供使用 SQL 结构查询 HBase 中的数据的能力。
当您提交任何 SQL 查询时，Phoenix 将对其进行解析并创建一个执行计划，该计划可以根据您查询的内容将查询分为全扫描、范围扫描或点获取。
对于处理结果，Phoenix 使用谓词下推，因此 HBase 执行所有处理（从所有区域服务器扫描并获取必需的行），Phoenix 聚合/整理结果行并将其返回给用户。
现在回答您的问题“ phoenix 适合 ETL 和聚合吗？ ” -不，如果您需要使用聚合执行大型扫描（全面或大范围扫描）并期望在几秒或亚秒内处理结果，那么它不适合。如果您的表占用空间很小（几百 GB），这些查询可能会正常工作，但随着表大小会随着时间的推移而增加，您最终会遇到严重的性能问题。这是 OLAP 场景，您应该寻找其他替代方案。
我假设当您说将 Hive 与 HBase 结合使用时，您计划在 HBase 表之上创建一个 Hive 外部表，该表可以使用 HiveHBaseTableInputFormat 直接查询 HFile。这将使用 MapReduce 来处理查询，并且您无法真正通过分区、分桶等方式利用性能优化。
我建议考虑使用 HBase + Phoenix 选项进行点获取和小范围查询，对于大型聚合/ETL 类型查询考虑使用 Spark，它会比 Hive 选项更好、更快。
如果您的数据仅附加，您可以考虑使用一些替代的 OLAP 支持存储选项，例如 Driud、Clickhouse 或 Hive on Tez、Hive with Impala 或 Presto 选项，而不是 HBase。
根据评论更新 -
Spark 将比 Hive (MapReduce) 选项更快；仅将 Spark 用于使用大范围或全扫描并随后进行聚合的查询。
尽管Phoenix利用协处理器和谓词下推到HBase区域，但可用资源量可能会成为限制，Phoenix将按照GUIDE_POSTS_WIDTH决定的块并行化查询，对于大型表，这很容易从几百到几千秒不等，创建 RPC 队列的争用，并且在扫描期间 HFiles 将被读取并加载到 Regionserver 堆中，如果扫描无法在分配的堆中容纳结果，则可能会遇到 GC 或 OOM 问题。扫描仪可能会受到 rpc 等待时间和可用内存的限制，从而导致超时。
您可以在一定程度上调整上述情况，但 HBase/Phoenix 不适用于 OLAP。使用 Spark，您可以直接读取 HFile 并随后应用过滤器，这将消除超时问题。如果一次又一次查询相同的数据子集，您可以尝试使用外部 rdd/dataframe 缓存来 Ignite。
我想补充一点，在寻找替代方案之前，您应该分析您在 HBase 中存储数据的方式是否与您的查询模式一致？如果您的查询计划正在创建全扫描，请重新审视您的行键设计，尝试重新设计行键或查询以避免全扫描？检查您的数据是否均匀分布在所有区域？您的高写入速率会影响您的读取性能吗？
如果您需要分析点击流类型的数据，请查看 Clickhouse，Yandex 为类似的用例开发并开源了它，但它也适用于其他 OLAP 用例。
希望这有帮助。