Hadoop为数据带来代码是实现扩展的唯一方法吗?

时间:2012-04-09 21:22:58

标签: .net architecture hadoop

这是使用map& amp;降低?

我讨厌的是持久性无知全都被淹没了。它应该是HDFS通过接口暴露自己,你不应该关心它写的是什么语言,或者为什么。就像你如何编写ODBC一样,它将插入Oracle,Sql Server以及任何未在任何操作系统上运行的内容。

我知道Hive,但我认为它不适合较重的计算,如矩阵操作,高斯分析等。

另一个问题是编写复杂的指令集以及这种依赖所需的依赖性。这意味着您必须弄清楚如何移植代码并将其与任何依赖项一起安装到服务器本身。这是很多基础设施成本!在(平台即服务)Paas云中也很难做到。

使用Hadoop流的示例。你必须确保你的二进制文件是针对目标服务器内核编译的。例如。 Linux与Windows等。您还必须确保所有项目都引用相同版本的依赖项。这又是公牛。如果你有多个团队,这就是很多协调和开销。我们转向SOA以摆脱其中的一些。

我理解数据比代码重,并且将代码放在数据本身旁边效率更高,但这是实现扩展的唯一方法吗?在处理Hadoop应该解决的大量数据时,你绝对不得不牺牲Seperation of Concern。

例如,是的,您可以将CLR嵌入到Sql server中,但实际上这只保留给无法以任何其他方式解决的真正严重的瓶颈。又名 - 如果你想称它为黑客或反模式。执行此操作太多,您的产品与Microsoft Sql Server紧密耦合。你不能只为Oracle换掉它,或者不需要改变它。不好。

同样在所有计算历史中,我们总是将数据带到代码中,而不是相反。例如。您将数据从数据库加载到Orm,服务,内存,缓存,然后加载到指令集。这代表了SOC的原因

我的问题是,是否地图& reduce + no sql是你必须将代码放在数据旁边的情况之一,而不是根据需要将数据加载到指令集(例如,云中某处的负载均衡服务)。

1 个答案:

答案 0 :(得分:0)

这取决于您拥有多少数据。

在某些时候,通过网络移动数据变得不切实际。如果你需要减少数TB的数据,那么即使使用千兆网络,数据传输时间也很重要。

如果您的数据位于云端,那么您还需要考虑从云服务传输数据的成本。