我在 Greenplum DB 中有 TB 的结构化数据。我需要对我的数据运行本质上是 MapReduce 作业。
我发现自己至少重新实现了 MapReduce 的功能，以便这些数据适合内存（以流式传输方式）。
然后我决定到别处寻找更完整的解决方案。
我查看了 Pivotal HD + Spark，因为我使用的是 Scala，而且 Spark 基准测试令人惊叹。但我相信其背后的数据存储 HDFS 的效率将低于 Greenplum。 （注意“我相信”。我很高兴知道我错了，但请提供一些证据。）
因此，为了与 Greenplum 存储层保持一致，我查看了 Pivotal 的 HAWQ，它基本上是 Greenplum 上的 Hadoop 和 SQL。
这种方法丢失了很多功能。主要是Spark的使用。
或者直接使用内置的 Greenplum 功能更好？
所以我现在正处于十字路口，不知道哪条路最好。我想要处理非常适合关系数据库模型的 TB 级数据，并且我想要 Spark 和 MapReduce 的优势。
我的要求是不是太多了？
在发布我的答案之前，我想根据我的理解重新表述问题（以确保我正确理解问题）如下：
你有 TB 级的数据，非常适合关系型 DB 模型，并且大多数时候你想使用 SQL 查询数据（我认为这就是你将其放入 Greenplum DB 的原因），但有时你想使用 Spark 和 MapReduce 来访问数据，因为它们的灵活性。
如果我的理解是正确的，我强烈建议您尝试一下HAWQ。 HAWQ的一些功能使其完美满足您的要求（Note:我可能有偏见，因为我是 HAWQ 的开发人员）。
首先，HAWQ 是一个 SQL on Hadoop 数据库，这意味着它使用 HDFS 作为数据存储。 HAWQ 与 Greenplum DB 存储层不一致。
其次，很难反驳“HDFS 的效率将低于 Greenplum”。但性能差异并不像您想象的那么显着。我们对HDFS数据的访问做了一些优化。举个例子，如果我们发现一个数据块存储在本地，我们会直接从磁盘读取它，而不是通过普通的 RPC 调用。
第三，HAWQ 有一个名为 HAWQ InputFormat for MapReduce 的功能（Greenplum DB 没有）。借助该功能，您可以编写 Spark 和 MapReduce 代码来轻松高效地访问 HAWQ 数据。与 Hadoop 提供的 DBInputFormat 不同（这会使 master 成为性能瓶颈，因为所有数据首先经过 master），HAWQ InputFormat for MapReduce 允许您的 Spark 和 MapReduce 代码直接访问存储在 HDFS 中的 HAWQ 数据。它是完全分布式的，因此非常高效。
最后，当然，您仍然可以使用 SQL 通过 HAWQ 查询数据，就像使用 Greenplum DB 一样。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
