4.11Pig Latin 实现与优化在线视频

下面我们简单地看一下

PIG LATIN是怎么在

Map-Reduce实现的

以及它一些个优化这个

流水线的一些技巧

那么这个PIG LATIN

它是怎么使的

那么用户可以直接写

基于pig写程序

那么这个pig的系统

收到了用户的程序之后

它可以对这程序进行一系列的

优化和重写

它把它重写成一系列的

Map-Reduce的任务

然后它把它交给Hadoop的

Map-Reduce来运行
Hadoop Map-Reduce
就像运行Map-Reduce一样

在这儿运行多个PIG LATIN

写出来的程序

运行整条流水线

最后得到结果

当然用户说我有些个任务

我觉得还是前面Map-Reduce

比较顺了

那他也可以直接写成

Map-Reduce

当然我们也可以做一个

更高级的抽象

就是让用户

直接写一个SQL的语言

这样的话

连那一步一步都不写了

我直接写我要在哪个数据机上

select点什么东西

哪几个东西group在一起

我要最后我要得到什么

这种情况下

SQL的语言当然它可以

直接地转化为Map-Reduce

但是如果觉得那个太麻烦的话

也可以利用PIG LATIN的引擎

把它转化成一个

PIG LATIN的语言

然后由PIG把它优化成Map-Reduce

因为从SQL到PIG

其实大家想想

它也不太远了

因为这些个PIG的操作

基本上也是SQL

背后支持的那些操作

所以这个是PIG LATIN

几种使用方法

可以直接用

可以跟Map-Reduce一起用

或者我们再做一种

更高级的语言来生成PIG LATIN

写出来的PIG的这种程序

它实际上会变异

然后它会成为一个

Map-Reduce的程序

然后怎么做呢

基本的操作就是说

每一次有group

或者有个Join

那个这个group和Join

根据它的定义

那么它一定就是一大堆的记录

把它要放在一起

那么怎么把一大堆记录

放在一起

在Map-Reduce当中

唯一的方法就是跑一个reduce

那就把类似的记录放在一起了

那么所以每一次group

或者Join它就会形成一个

Map-Reduce

那么其他的操作

包括引用或者定义的这种过滤

这些操作

那么都会变成map

或者reduce当中处理的一部分

比如说这个流水线

那么我们首先看起来

这个读文件

读文件肯定要从map来了

然后它后边跟了一个group

group后边根据foreach

group然后generate count

那这一步肯定是要做一个

reduce

那么数着这个有一个map了

再接着一个reduce

正好有一个group

所以group就基本上是从map

到reduce这么一个过程

然后这边有一个Join对吧

这儿有一个Join on url

那么我们这有个load

所以load的话肯定是要map

然后reduce可以放到Join那里

后边 这边又有一个group

一个group就成了一个map

和一个reduce之间的

这个我们必须要在这里

做一次map和reduce的交接

所以呢

那么之前的这个map

实际上是把之前的输入读进来

然后再reduce一把
然后它就把它group by category

然后最后对每一个

category来做

这跟我们刚才讲到的是一致的

那么就是我们是用三个

Map-Reduce来实现这个流水线

那么PIG它是能够

你写好了这个程序之后

它看了这个程序

它自动地能够找到

到底在哪里能够做一次

map或者一次reduce

当然这个是一个非常非常简单

也是非常switchfor这么一种

翻译的方法

我们可以非常机械地

把一个PIG的程序

来翻译成一个Map-Reduce的

流水线

但是它是不是

一个最好的方法呢

那不是

因为这里头有很多可以

优化的地方

这也是一个为什么我们用一个

更加抽象的语言

比如说像PIG LATIN

这样的语言 一个

或者我们

甚至我们用SQL

一个最大的优势

就是说这个抽象是非常好的

一个抽象的语言

你要用户

它只是一种概念性的

让用户写出来的程序

用户只告诉你逻辑

具体里头是怎么实现的

那么系统在背后可以做

很多很多的工作

但是用户根本就不需要知道

用户只知道他的程序

过两天就跑的更快了

他就会很高兴

但是你不用让他改程序

如果你抽象的不够

你系统的实现一改了

他的程序跟系统实现是相关的

他就必须要改他的程序

这时候就麻烦

你就不可能每天都优化

你的系统

因为你不可能每天让用户

改这个程序

所以这也是抽象的一个

很大的优势

那么底下的这张图了什么

这是表示PIG最开始

最出来的时候是2008年9月份

那个时候你跑一个程序

比你手工调的这个Map-Reduce

要 在时间要长7.6倍

所以它还是很慢的

你手工调了之后

还是调的很好的

但是转眼过了两月

它就剩2.5倍了

但是到2009年的时候

过了不到一年

它基本上就是

是1.4倍于那个时间

就基本上跟你跑一个

Map-Reduce的时间

已经差不了太多了

所以这就是说

你只要是抽象

你做出来一个东西

立刻就可以

人家就可以使

然后你背后还可以

做很多很多的优化

然后来不断地提升这个性能

而你不用等到

你把它做到已经完美了

你再投放市场

这个时候

因为大家已经等不及了

可能大家已经用其他了系统了

或者大家已经忍着

用map又重新写了

所以你这个系统再出来

到时候再出来

已经没太大用了

所以这个是一个抽象的

一个非常好的地方

就是你可以在

不是那么成熟的情况下

把这个东西推出来

然后你再慢慢地优化

不影响用户的使用

这个PIG里边的优化

是非常多的

而且它也有很多的论文来讲

它各种各样的优化

我觉得这里头比较重要的几个

我们在这里简单地提一下

如果大家有兴趣的话

可以去看PIG的那篇论文

以及后续的一系列的

关于怎么优化这个

PIG这种查询的

这一系列的论文

那我们当然数据库

优化的一个核心思想就是说

你中间的过程

你传递的数据越少越好

你不要把没用的数据

都传到最后一步去

这个 你早点

如果数据没用的话

你能早扔掉就早扔掉

你能够早把一些求和

一些聚合的方法算出来

那你就早点算出来

这个是PIG一个比较

就是反正整体数据库

当然PIG也采取了

这些数据库的这些观念

就是一种优化的思想在这里头

那么这个优化是一个Combiner

这个Combiner干了啥

它说我先把所有的

能够聚合在一起的东西

或者说我先把所有的key

这些东西我都先放在一起

这样放在一起之后呢

它将来这个（06：16）的时候

就会快

因为我先把所有的（06：20）

先做掉

然后这样做掉之后

我如果将来这个里头

有一些个聚合的函数

比如说我要求一个（06：25）

或者我有求一个

合并两个东西

合并一下什么东西

这样的话我就会比较快了

比如说我这两个k1

这里有k1

这里有k1

那我先把这k1放到一起

然后如果我想去重

比如说我想知道这里头

有重复的数据

那么我在合并的过程中

Combiner的过程中

我就都去掉了

如果我想算一下（06：47）的方式

比如说我想求个和

求个均值

那我也在这里头

也能全部算出来

这样的话

有些数据就不用

把每一个Combiner

全部往后边传了

你把这个聚合的数据

往后传就行了

所以它要把这些东西

然后提前

要能够Combiner的东西

先把它做到前边去