一骑绝尘引发的思考–关于hive程序员是否需要学习mapreduce

标题是一篇文章，为新华社记者杨明所写，文中讨论了中国在亚运会团购金牌的事，认为泱泱中华不应该再以金牌论英雄，而需将竞技体育转移到全民运动中来，让全社会都来热爱体育，热爱运动。
引用此文，不是在此讨论体育，而是因为前些天巴真同学的拍砖引起了我的一些想法！为什么会有这么多想法？因为本人活到现在还没有人在我的文章后留言如此之长，为表敬重，单独再开一贴。
其实我们所要争论的核心议题很明确，就是hive程序员是否应该了解mapreduce！对于巴真的板砖，我有一点不同的想法：
其一，hive和mapreduce的关系其实没有C语言和编译语言，JAVA和汇编程序这么深。就我认为，hive和pig等语言类似，只是一个shell,一个包装了mapreduce的shell,他使得编写m/r程序更加的方便入手，使得步入云计算的程序员门槛更低。但是，就像编写C语言你依然需要去了解指针，学习JAVA你也肯定会去研究GC一样，为了编写精美和高效率的代码，一个程序员应该去了解你的SQL是如何转为m/r的。
其二，工业由利润推动，我很赞同这句话。这就像hive的诞生一样，推动着云计算的使用人群从篮球框变大到了足球门！但是就像摘掉了“东亚病夫”帽子的中国再也不能唯金牌论一样，公司发展到了一定程度也就不能唯利润论了。经过了刀耕火种的资本原始积累之后，接下来就应该保住利润，降低成本。正所谓创业容易守业难，我们需要降低成本，就需要更深入的设计，更深入的发展。学习mapreduce可以帮助我们更好的理解hive的运行过程，以至于写出更好的代码，开源节流。
其三，要说点实际情况。在hive的优化过程中，曾经碰到过两表join时候OOM的情况。解决问题一句话:”小表放前，大表放后”！其背后的本意是：“对于同一个key来说，对应的value值小的放前，大的放后”，如果没有接触过m/r,单一的SQL程序员是很难理解这句话的意思的。
给你一份简谱，你可以“弹”出一首很美的歌曲，但如果你想“创作出”优美的旋律，你就必须懂得五线谱；中国可以团购金牌，但要成为体育强国，必须要深层次的发展体育；hive可以很快很好的带来效益(这就好像临时需求)，但是要持续不断的稳定产出(这就类似上线代码)，则需要理解m/r的原理。
以上愚见，仅供参考。

SQL是OO的吗？

最近写多了HiveSQL,今天偶尔改了一个很老的java程序，突然想到SQL到底是不是一种OO的语言？
按照历史来说，SQL应该和OO几乎是出生于同一个年代，我无法得知发明SQL的人是否借鉴了OO，或者想出OO的人是否吸纳了SQL的精髓，但是某一些容易被人忽略的东西还是可以印证这两个东西的相似性！
OO的三个基本特点:封装性/继承性/多态性对于SQL来说几乎全部拥有，特别是对于HiveSQL来说，原本的hadoop壳就是基于java,因此转义过来的类SQL更具有OO的特性。
拿封装性来说，类就等于表，当我们在敲打table.的时候，等后续变量出来的感觉就相当于等待class.后面的变量出来；而hiveSQL提供的UDF更像是方法，遗憾的是作为单一的UDF函数不能针对表级别进行处理，如果有table.UDF的话那对于SQL的封装性来说就更趋完美。当然，table.method也不是没有–如果用streaming来做的话–对于一个table进行一个streaming操作，例如python,也就相当于对一个table进行了一个方法。
继承性粗粗看起来没有，其实SQL也可以很好的进行继承。当我们组织中间层的时候，会构造满足tableA同时也满足tableB的表tableC,这里的tableA和tableB不也就是tableC的超类了吗？
多态性目前我还看不出来，如果真要扯一个关系的话，UDF函数算是多态吗？可惜本身就是JAVA！或者说是hive的作者为了将hiveSQL真的做成OO而弄了这么一个玩意出来？不得而知！
上面的这些看起来有点扯淡，其实是因为在平时用SQL的时候有很多东西因为SQL的语法不灵活导致了数据效率的降低！比如可以一道m/r做完的工作，由于SQL的局限性而必须要在两道m/r中完成的情况比比皆是！我觉得其根本原因是程序员很难通过控制SQL去控制mapreduce。如果有一天，我们将SQL变成了类java的语言，生产力一定会有很大的飞跃！我们所有表的变更都能够通过方法来实现，例如tableA.drop,tableA.create,tableA.join,再在这基础上进行重载，可以细化控制到每一个mapreduce,SQL会不会从此变成一门全新的语言呢？

使用MRUnit实现MapReduce程序的单元测试

Hadoop的MapReduce程序的测试，一直比较麻烦。因为不方便抽取出来，作为独立的Junit测试。所以很多时候，我们都是写一个Main函数，然后在里面手工调用Map或者Reduce，用System.out.println打印出结果，人眼测试，而且还要判断OutputCollector是否为空，不然直接Main调用还会抛NullPointerException。 这样最大的弊端，是无法实现自动化的断言判断，达到测试驱动和检查的目的。那么对程序的任何改动，都需要放到Hadoop集群上，跑个十几分钟才能肯定到底对不对。我们需要一个更快的方法，能够方便的自动化的对MR程序进行测试，从而达到测试驱动和敏捷开发的状态。 What’s MRUnit：

写好Hive 程序的五个提示

使用Hive可以高效而又快速地编写复杂的MapReduce查询逻辑。但是某些情况下，因为不熟悉数据特性，或没有遵循Hive的优化约定，Hive计算任务会变得非常低效，甚至无法得到结果。一个”好”的Hive程序仍然需要对Hive运行机制有深入的了解。 有一些大家比较熟悉的优化约定包括：Join中需要将大表写在靠右的位置；尽量使用UDF而不是transfrom……诸如此类。下面讨论5个性能和逻辑相关的问题，帮助你写出更好的Hive程序。

Hive 随谈（六）– Hive 的扩展特性

Hive 是一个很开放的系统，很多内容都支持用户定制，包括： 文件格式：Text File，Sequence File 内存中的数据格式： Java Integer/String, Hadoop IntWritable/Text 用户提供的 map/reduce 脚本：不管什么语言，利用 stdin/stdout 传输数据 用户自定义函数: Substr, Trim, 1 – 1 用户自定义聚合函数: Sum, Average…… n – 1 File Format TextFile SequenceFIle RCFFile Data type Text Only Text/Binary Text/Binary Internal Storage Order Row-based Row-based Column-based Compression File Based Block Based Block Based Splitable YES YES YES

阅读全文 >

Hive 随谈（四）– Hive QL

Hive 的官方文档中对查询语言有了很详细的描述，请参考：http://wiki.apache.org/hadoop/Hive/LanguageManual ，本文的内容大部分翻译自该页面，期间加入了一些在使用过程中需要注意到的事项。