Hadoop 猪与蜂巢与本地地图减少

我对什么是猪、蜂巢抽象有基本的了解。但我不清楚需要蜂巢、猪或本地地图还原的场景

---

我浏览了几篇文章，基本上指出了Hive用于结构化处理，Pig用于非结构化处理。我们什么时候需要本机map reduce？您能指出一些使用Pig或Hive无法解决的场景，但在本机map reduce中可以解决吗？

简短回答-我们需要MapReduce，因为我们需要对处理数据的方式进行深层次和细粒度的控制。有时，用Pig和Hive查询来准确地表达我们所需要的并不十分方便

使用MapReduce，通过Pig或Hive，应该不是完全不可能做到的。有了猪和蜂巢提供的灵活性，你可以设法实现你的目标，但可能不是那么顺利。您可以编写UDF或做一些事情并实现它

这些工具的使用没有明确的区别。这完全取决于您的特定用例。根据您的数据和处理类型，您需要决定哪种工具更适合您的需求

编辑：

Strengths:
      works both on structured and unstructured data.
      good for writing complex business logic.

Weakness:
     long development type
     hard to achieve join functionality

Strengths:
     less development time.
     suitable for adhoc analysis.
     easy for joins

Weakness :
     not easy for complex business logic.
     deals only structured data.

不久前，我有一个用例，我必须收集地震数据并对其进行分析。保存这些数据的文件的格式有些奇怪。部分数据已编码，而其余数据为二进制格式。它基本上是一个平面二进制文件，没有\n之类的分隔符。我费了好大劲才找到用Pig或Hive处理这些文件的方法。因此，我不得不与MR.安定下来。最初，这需要时间，但随着MR.在准备好基本模板后变得非常敏捷，情况逐渐变得更加顺利

所以，就像我前面说的，它基本上取决于您的用例。例如，在Pig中迭代数据集的每条记录非常容易（只是一个foreach），但是如果需要foreach n？？因此，当您需要对处理数据的方式进行“那种”级别的控制时，MR更合适

另一种情况可能是数据是分层的而不是基于行的，或者数据是高度非结构化的

涉及作业链和作业合并的元模式问题更容易直接使用MR而不是使用Pig/Hive解决

有时，与使用Pig/hive相比，使用某些xyz工具完成特定任务非常方便。事实证明，MR在这种情况下也会更好。例如，如果您需要对BigData进行一些统计分析，那么与Hadoop流媒体一起使用的R可能是最好的选择

---

HTH

复杂的分支逻辑，其中包含大量嵌套的if。。其他的结构在标准MapReduce中更容易、更快地实现，对于可以使用的结构化数据的处理，它还简化了JOIN之类的事情。此外，标准MapReduce还为您提供了完全控制，以最大限度地减少数据处理流所需的MapReduce作业数量，从而转化为性能。但是，编写代码和引入更改需要更多的时间

Apache Pig也适用于结构化数据，但其优点是能够处理数据包（所有分组在一个键上的行），实现以下功能更简单：

获取每组前N个元素

计算每组的总计，然后将总计放在组中的每一行上

使用Bloom过滤器进行连接优化

多查询支持（当PIG试图通过在单个作业中做更多工作来最小化MapReduce作业的数量时）

配置单元更适合于临时查询，但其主要优点是它有一个存储和分区数据的引擎。但它的表格可以从Pig或标准MapReduce中读取

---

还有一件事，Hive和Pig不适合处理分层数据。

Mapreduce:

Strengths:
      works both on structured and unstructured data.
      good for writing complex business logic.

Weakness:
     long development type
     hard to achieve join functionality

Strengths:
     less development time.
     suitable for adhoc analysis.
     easy for joins

Weakness :
     not easy for complex business logic.
     deals only structured data.

蜂巢：

Strengths:
      works both on structured and unstructured data.
      good for writing complex business logic.

Weakness:
     long development type
     hard to achieve join functionality

Strengths:
     less development time.
     suitable for adhoc analysis.
     easy for joins

Weakness :
     not easy for complex business logic.
     deals only structured data.

清管器

Strengths :
      Structured and unstructured data.
      joins are easily written.

Weakness:
     new language to learn.
     converted into mapreduce.

蜂巢

优点：

类Sql 数据库的人喜欢这样。 对结构化数据的良好支持。 目前支持数据库模式和类似结构的视图 支持并发多用户、多会话场景。 更大的社区支持。蜂巢，蜂巢服务器，蜂巢服务器2，黑斑羚，中心已经

缺点： 随着数据的增长，性能会下降—无需多做，内存溢出问题。没什么用。 分层数据是一个挑战。 非结构化数据需要类似udf的组件 在大数据等情况下，多种技术的结合可能是UTDF的噩梦

清管器： 赞成的意见： 伟大的基于脚本的数据流语言

缺点：

非结构化数据需要类似udf的组件 不是很大的社区支持

MapReudce： 赞成的意见： 不要同意“难以实现连接功能”，如果您了解要实现哪种连接，只需几行代码即可实现。 大多数情况下，MR产生更好的性能。 MR对分层数据的支持非常好，尤其是实现树状结构。 更好地控制数据的分区/索引。 工作链

缺点： 需要非常了解api以获得更好的性能等

---

编码/调试/维护

我们可以使用PIG和HIVE完成的所有事情都可以使用MR实现（尽管有时会很耗时）。猪和蜂巢在下面使用MR/SPARK/TEZ。所以MR能做的所有事情在蜂箱和猪身上都可能，也可能不可能

其中Hadoop Map Reduce优先于Hive或PIG

当您需要明确的驱动程序控制时

每当作业需要实现自定义分区器时

如果已经存在作业的预定义Java映射器或还原器库

如果在组合大量大型数据集时需要良好的可测试性

如果应用程序