本节书摘来异步社区《MapReduce设计模式》一书中的第1章，第1.5节，作者： 【美】Donald Miner , Adam Shook 译者： 徐钊 , 赵重庆 责编： 杨海玲，更多章节内容可以访问云栖社区“异步社区”公众号查看。
1.5 Pig和Hive
在Hadoop生态系统中有了Hive和Pig这类工具，对MapReduce设计模式没有太强烈的需求。但我们还是想借本书的开始部分解释为什么MapReduce设计模式依然如此重要。
Pig和Hive是对MapReduce更高层次的抽象。虽然它们提供的接口与“map”和“reduce”无关，但实际上它们会将较高级的语言翻译成一组MapReduce作业。就像关系型数据库管理系统（RDBMS）中的查询计划器（query planner）会将SQL语句解析成对数据的实际操作一样，Hive和Pig也是将它们各自的语言翻译成MapReduce操作。
在本书相关章节中可以看到，相对于用Java写的原生Hadoop实现，使用Pig和SQL（或HiveQL）将更为简洁。例如，用Java实现一个全排序，可能要写上几页代码，但用Pig只需要几行。
既然Hadoop提供了像Pig和Hive这样的工具给我们选择，为什么还要用Java去实现MapReduce？为什么用几行代码就能实现的功能，本书作者要花时间解释如何用几百行代码实现？目的是什么？这里有两个核心原因。
首先，对于像MapReduce这样的系统，了解其底层的工作原理具有理论价值。如果开发者知道Pig是如何执行reduce端连接操作的，那么在使用时将会做出更明智的选择。不理解MapReduce原理，只知道如何使用Pig和Hive，在某些情况下可能会导致危险情况的发生。尽管你得益于高层次的接口，但这并不意味着你可以忽视底层的细节。大规模的MapReduce集群就像重型机械一样，需要得到足够的重视。
其次，Pig和Hive在功能的完整性以及成熟度上目前还有所欠缺（截至2012年）。很显然，它们还没有完全发挥出自己的潜能。目前，它们根本不能像Java写的MapReduce那样解决所有的问题。随着时间的推移，伴随着bug的修复、新特性的增加以及重要版本的发布，这种现状将会改变。假设，基于Pig v0.6，你所在的机构可用Pig实现50%的分析工作。那么，基于Pig v0.9，这个比例将增加到90%。随着一个个新版本的发布，会有越来越多的工作可以通过高级抽象方法实现。但是在软件工程中有一个有趣的趋势：不能通过高级抽象方法解决的最后10%的问题，有可能是最关键的和最具挑战性的。此时，像Java这样的工具是解决这些问题最好的选择。就像在有些时候依然必须使用汇编语言一样！
如果可以，请使用Pig或Hive编写你的MapReduce。使用这种高级抽象语言写MapReduce的主要好处在于可读性、可维护性、开发时间及自动调优方面。然而对于常见的性能下降问题，我们很少会考虑Pig和Hive的间接影响。Pig和Hive的分析是按批处理的方式运行，本身就需要耗费好几分钟，那么，耗费的一两分钟真的不重要吗？在大部分情况下，Pig或Hive的查询计划优化器在优化代码上会比你做得更好。但在小部分情况下，因为Pig和Hive多消耗的几分钟十分重要，此时应该使用Java写MapReduce。
Pig和Hive对MapReduce设计模式的影响可能比其他工具更大。它们需要的新特性，有可能成为一种MapReduce设计模式。同时，随着越来越多MapReduce设计模式的开发，一些流行的模式也将在高层次抽象中成为重要操作。
Pig和Hive有自己的模式，并且随着更多问题被解决，专家们记录的模式也会越多。虽然Hive从发展了几十年的SQL模型中获得了益处，但是并不是所有的SQL模式都适用于Hive，反之亦然。当然，如果这些平台越来越受欢迎，相关的手册和设计模式书籍就会出现。
