2016-05-31 63 views
1

我们有数据(不是在这一点上分配),我们想要转换/聚合/转到wazoo。要hadoop或不要hadoop

我在www上看了一眼,我要求的所有答案都是指向hadoop的可扩展性,运行便宜(无需SQL服务器和许可证),快速(如果您拥有数据分配),可编程你拖动的小盒子)。

只是有一个问题,我一直来面对

现在我们甚至没有1GB的数据(在这个阶段)是即“如果你比的数据10GB有更多的只使用Hadoop”仍然可行。

我的其他选择是SSIS。现在我们使用SSIS来处理当前的一些ETL,但是我们没有资源,并且将SQL放入云中会花费很多,甚至不会让我着手可扩展性成本和配置。

谢谢

+2

1GB不是大数据。它实际上是平均值。 10GB也不是。目前数据仓库基准测试的起始容量为100GB。一个4岁的笔记本电脑可以轻松处理10GB的负载。事实上,您可以将所有数据存储在内存中,例如SQL Server 2014或2016.至于便宜且快速的情况,只有*如果您拥有一个群集,在这种情况下,它非常便宜。 –

+1

“除非增加5TB /年,否则您没有大数据。”这是最近一次会议的一句话。尽管Excel可以使用列存储来汇总数百万个数据行,但它不会显示*所有这些数据行都是相关的博客文章[https://www.chrisstucchio.com/blog/2013/hadoop_hatred.html] –

+0

@Pintac :参考这篇文章:https://www-01.ibm.com/software/in/data/bigdata/和http://stackoverflow.com/questions/32538650/hadoop-comparison-to-rdbms/32546933#32546933和 –

回答

2

您目前的数据量似乎太低,无法进入hadoop。只有在处理大量数据(TB /年)并且怀疑数据量按指数级增长时,才能进入hadoop生态系统。

让我解释一下为什么我建议不要这么低数据量的hadoop。 默认情况下,hadoop将文件存储为128MB的数据块,同时处理也需要128MB的块来处理(并行)。如果您的业务需求涉及大量CPU密集型处理,那么您可以将输入块大小从128MB减小到更小。但是,再次通过减少要并行处理的数据量,最终会增加IO seak的数量(低级块存储)。最后,你可能会花费更多的资源来管理任务,而不是实际的任务。因此,尝试避免分布式计算作为您的(低)数据量的解决方案。

0

正如@Makubex所建议的,不要使用hadoop。

SISS是一个很好的选择,因为它处理内存中的数据,因此它将以比在存储过程中使用临时表写入磁盘更快的速度执行数据聚合,数据类型转换,合并等。

Hadoop是为了大量的数据,我建议它只适用于数据以兆兆字节为单位。 SISS(运行在内存中)用于小型数据集的速度会更慢。

请参阅:When to use T-SQL or SSIS for ETL

+0

嗨ii去了另一种方式。看到我知道在不远的将来我们将获得更多的数据我去了hadoop nodejs streaming方式,而不是使用hadoop,我只是直接调用node.js脚本,然后当数据很庞大时只是插槽haddop英寸。唯一的问题是我必须编写node.js脚本的hadoop方式。谢谢 – Pintac

+0

@Pintac哦好。 –