"采用MapReduce模型"=可扩展性的通用答案吗？

Question

我一直在尝试理解MapReduce概念并将其应用于我目前的情况.我的情况怎么样？好吧,我这里有一个ETL工具,其中数据转换发生在源和目标数据源(数据库)之外.因此,源数据源纯粹用于加载的提取和目标.

因此,今天的这种转变行为,对于一百万条记录来说需要大约X小时.我想解决一个我将拥有十亿条记录的情况,但我希望在相同的X小时内完成工作.因此,我的产品需要根据数据规模进行扩展(添加更多商品机器).正如您所看到的,我只担心将产品转换功能分配到不同机器的能力,并利用所有这些机器的CPU功率.

我开始寻找选项,我遇到了Apache Hadoop,最后是MapReduce的概念.我在快速安装Hadoop时非常成功,而不会遇到集群模式的问题,并且很高兴能够运行wordcount演示.很快,我意识到为了实现我自己的MapReduce模型,我必须将我的产品转换功能重新定义为MAP和REDUCE功能.

这是麻烦开始的时候.我阅读了Hadoop:Definitive Guide的副本,我理解Hadoop的许多常见用例都在以下情况中:

• 未构造的数据和一个想要执行聚合/排序/或类似的东西.
• 未经编译的文本,需要执行挖掘
• 等等!

这是我的场景,我从数据库中提取并加载到数据库(具有结构化数据),我的唯一目的是以可靠的方式引入更多的CPU,并通过分发我的转换.重新定义我的转换以适应Map和Reduce模型本身就是一个巨大的挑战.所以这是我的问题:

1. 您是否在ETL场景中使用过Hadoop？如果是,可以具体说明您如何处理转换的MapReducing？你是否纯粹使用Hadoop来利用额外的CPU能力？

2. MapReduce概念是分布式计算的通用答案吗？还有其他同样好的选择吗？

3. 我的理解是MapReduce适用于大型数据集进行排序/分析/分组/计数/聚合/等,我的描述是否正确？

Answer 1

如果您想在许多系统上扩展处理问题,您必须做两件事:

1. 确保您可以在独立的部分处理信息.
2. 这些部分之间不应该有共享资源.

如果存在依赖关系,那么这些将是您的水平可伸缩性的限制.

因此,如果您从关系模型开始,那么主要障碍就是您有关系.拥有这些关系是关系数据库中的一项重要资产,但在尝试横向扩展时却是一种痛苦.

从关系到独立部分的最简单方法是跳转并将数据去规范化为包含其中所有内容的记录,并将焦点集中在要进行处理的部分.然后,您可以在一个巨大的集群上分配它们,并在处理完成后使用结果.

如果你不能做这样的跳跃,那你就麻烦了.

所以回到你的问题:

#您是否在ETL场景中使用过Hadoop？

是的,输入是Apache日志文件,加载和转换包括解析,规范化和过滤这些日志.结果不会放在正常的RDBMS中!

#MapReduce概念是分布式计算的通用答案吗？还有其他同样好的选择吗？

MapReduce是一个非常简单的处理模型,可以很好地解决任何处理问题,你可以分成许多较小的100%独立部分.MapReduce模型非常简单,据我所知,任何可以拆分成独立部分的问题都可以写成一系列mapreduce步骤.

但是:重要的是要注意,此时只能使用Hadoop完成面向BATCH的处理.如果你想要"实时"处理,你现在运气不好.

我不知道现在存在一个更好的模型,实际的实现存在.

#我的理解是MapReduce适用于大型数据集进行排序/分析/分组/计数/聚合/等,我的描述是否正确？

是的,这是最常见的应用程序.