我在greenplum数据库中有结构化数据的tbs。我需要在我的数据上运行本质上是mapreduce作业。
我发现自己至少重新实现了mapreduce的特性,这样这些数据就可以放入内存(以流方式)。
然后我决定去别处寻找一个更完整的解决方案。
我看了pivotal hd+spark,因为我使用的是scala,spark基准是一个令人惊叹的因素。但我相信这背后的数据存储hdfs的效率会低于greenplum(注意“我相信”。我很高兴知道我错了,但请提供一些证据。)
所以为了保持greenplum存储层,我查看了pivotal的hawq,它基本上是greenplum上带有sql的hadoop。
这种方法会丢失很多特性。主要是Spark的使用。
还是只使用内置的greenplum功能更好?
所以我正处在不知道哪条路最好的十字路口。我想处理符合关系数据库模型的tbs数据,并且我想要spark和mapreduce的好处。
我要求太多了吗?
2条答案
按热度按时间1aaf6o9v1#
你试过使用spark-jdbc连接器来读取spark数据吗?
使用分区列、下限、上限和numpartitions将greenplum表拆分为多个spark worker。
例如,您可以使用此示例
aemubtdh2#
在发布我的答案之前,我想根据我的理解(以确保我正确理解问题)将问题重新表述如下:
您拥有非常适合关系数据库模型的tbs数据,并且大多数情况下都希望使用sql查询数据(我认为这就是为什么您将其放入greenplum db中),但有时您希望使用spark和mapreduce访问数据,因为它们具有灵活性。
如果我的理解是正确的,我强烈建议你试试hawq。hawq的一些特性使它完全符合您的需求(注意:我可能有偏见,因为我是hawq的开发人员)。
首先,hawq是一个基于hadoop的sql数据库,这意味着它使用hdfs作为数据存储。hawq不支持greenplum db存储层。
其次,很难反驳“hdfs的效率将低于greenplum”。但性能差异并不像你想象的那么显著。我们对访问hdfs数据做了一些优化。一个例子是,如果我们发现一个数据块存储在本地,我们直接从磁盘读取它,而不是通过正常的rpc调用。
第三,hawq有一个特性,名为hawq inputformat for mapreduce(greenplum db没有这个特性)。有了这个特性,您可以编写spark和mapreduce代码来轻松高效地访问hawq数据。hawq inputformat for mapreduce与hadoop提供的dbinputformat不同(它会使主机成为性能瓶颈,因为所有数据都首先通过主机),它允许spark和mapreduce代码直接访问存储在hdfs中的hawq数据。它是完全分布式的,因此非常有效。
最后,当然,您仍然可以使用sql使用hawq查询数据,就像使用greenplum db一样。