4.10Pig Latin 嵌套数据类型在线视频

关于PIG LATIN的语法

它实际上是非常简单的

但是比较值得一提的是

它的数据结构

尤其是它这个比较嵌套的

数据结构

这一点跟数据库里头

还是有相当大的差别的

大家知道数据库的表

一般来讲它是一行

一行它是一个扁平的结构

它是多少列

一般来讲我们不推荐

在一个 一行的一列里头

放多个不同的值

就放一个数组在里头

那个一般来讲

在数据库里头

它是不推荐的一种做法

但是PIG LATIN它采取的是

完全可以嵌套的数据模型

那么它里头有一系列的这种

叫（00：38）type

就是说它是有一系列的能够

表示一组数据的这样的类型

比如说像tuples

比如说像bags或者叫lists

或者叫maps它有各种不同的

可以表示一组数据

数据集合这种的模型

所以它是完全支持这样的

就是说这个域里头只有一个值

是一个Atomic Values

是一个原子值

那这个域里头就是一个列表

所以它是好多个值

放到一个域里头

这个实际上虽然跟传统的

数据库不一样

但是实际上对人来说

对程序员来说

实际上这个是一种比

扁平的这种数据库的格式

要更自然

因为大家觉得跟yahoo对应的

它就是有这一组值

你非要把它yahoo复制三份

然后把它放在不同的组里头

或者你

比如说你要是学过数据库的话

你要想到那些范式什么的

非要把这个表拆成好几个表

这时候你不光做得会比较的

这个麻烦

人不容易理解

而且会造成很多不需要的这个

Join的操作

为什么

因为如果你把这个表打开

你为了不想让

把yahoo这个词重复三遍

那你一会儿要把它分成两个表

第一个表里头写的你有一个ID

1叫做yahoo

然后这个表里头写的是

那么1对应的另外一个表

这个表写的1对应的是finance

1对应的是email等等等等

然后你要想知道

yahoo和email放到一起

你比较得在这个1上做一个Join

所以它就相当于白白地

做了一次Join的操作

只是为了防止这个yahoo

被重复多遍

防止把所有的这些东西

都塞到一个

作为一个数组塞到

一个域里头去

但是这种嵌套的数据模型

现在很多做大数据的处理的

因为做Join实在是太昂贵了

在小的数据里头Join

其实也昂贵

但是大家还是觉得

这是可以接受的

我们为了防止这个数据的重复

因为重复的数据

有很多管理的问题

比如说你改变一个副本的话

你得保证所有的副本一起改变

这有很多其他的问题

但是基于这些问题

大家觉得我宁愿多做一些Join

没关系

那大数据谁也不愿意

做这些Join

所以我们大部分大数据的

这个系统都是支持嵌套模型的

那嵌套的模型比如说怎么做呢

比如说group by这个操作

group by这个操作在传统的

在数据库里头

group by你是不能单独做的

因为它group by的结果它

根据定义

那么就是一个key

带着一团数据

这些数据都是有着相同的key

才把它group在一起嘛

这叫group by的定义

就是这样的

但是因为传统的数据库

它不能够表示你的这个

好多个值在同一个行里头

或者跟着同一个key

所以在传统的数据库

就是大家考虑的（03：11）

考虑（03：12）这些东西的话

它必须要求group by后边跟着

一个（03：15）

否则的话它那个编译器

会出错的

就比如说你group by完了之后

你必须求个平均值

或者你必须求个median（03：22）

你必须求一个和 求个

你必须

反正把这些数据集合起来

这样的话让它变成

还是变成一行里只有一个值

但是PIG LATIN因为它支持

嵌套的数据模型

所以无所谓

你group by完了之后

它group by的结果就是一个

group的key加上一个数组

这个数组里都是你的这个值

这样就有什么好处呢

这样的好处就是说

你group by完了之后

如果你不想把它求和

而只是你想对每一个组

你比如说求tap ten这件事情

那么它返回的结果还是有10个

那你可以说

你就可以写foreach foreach什么

foreach你group by的结果

就foreach这个table那么为什么

foreach table了

后边还可以做

就是因为你foreach的话

那每一个each 每一个元素

那么里头还是一个数组

所以你可以在这个数组上

做很多的操作

这样的话

实际上group by

这为什么叫解耦了grouping
就是把grouping和这个（04：15）

这两个本身没有

特别大关系的操作

把它分开了

这样你group了之后

不一定要做（04：20）

这是能够支持

嵌套的数据模型的

一个重要的操作

这个还有一个重要的操作

叫做CoGroup

那么CoGroup可以理解为

是一种广义的grouping

这里举一个例子

比如说

因为PIG是用来分析广告的

所以这种例子很多

都是跟广告的这种排名有关系

比如说第一个表里头显示了

如果大家查询

就是搜索的时候

我搜索这个Lakers湖人队

如果搜索Lakers的话

那么我打出来的广告

排第一的是nba.com

那么它是广告排名在第一

如果搜Lakers的话

espn是美国的一个体育频道

那么它的排名可能是第二

这个广告排名是根据一些

竞价一些什么来的

它记住了这个结果

我搜索这个词的时候

它排名第几

另外一个表记录了

它的广告收入是多少钱

那么什么意思呢

就是说如果这个Lakers的这个

这个查询

在这种情况下

如果我广告位显示在广告页面

顶端的那个广告栏上

那么它收了50块钱

那么它显示在边上的那个广告

它收了20块钱

它就是这么一个意思

那么我们想

它这是两个不同的表

一个是结果的排名

一个是它能够放在什么地方

它能收入多少

但是我如果想把这两个东西

联合起来看

我想看一看它在不同的

排名结果

和不同的显示位置情况下

那它的收入到底是什么样子呢

我们就可以实行这样一个

PIG操作

CoGroup是PIG里头的

一个操作的名字

我group了两个表

哪两个表呢

一个表叫results

这个是叫results

然后这个表就叫revenue

所以我把这两个表group在一起

然后results我用的是

queryString

那么就是这个queryString

revenue也用的queryString
就是这个String

这个group之后的结果是什么

那group的key
那当然就是这个by什么的

就是什么的key了

那就是group by Lakers
那么对Lakers来说

它就是后边它是跟着是两个表

每个表里头都有不同的值

那么它都是跟Lakers有关系的

所以你看这个

它这会儿跟Lakers有关的

这些东西都放在一起
跟Lakers有关的东西

都放在一起了

那它实际上相当于把两个表

排了一下序

但是它用的是前头得group

这个东西有什么好处

因为传统来讲

你就要来做个Join

你怎么样把两个东西

搁在一起看

把这个表的东西

和这个表的东西搁在一起看呢

那么你就要做一个Join

这个Join是Join on这个queryString

就是Join on这第一个域的

所以那么你得出的是什么

这种东西的Join

基本上你得出的是一个

cross product的

实际上是一个叉乘的

这么的一个结果

因为如果这个表Lakers

所以这个有两个Lakers

其中这个表里有两个Lakers

那么它们Join的结果是几行

实际上是四行

因为nba.com对top是多少钱

nba.com在side是多少钱

espn.com到top是多少钱
espn.com在side是多少钱

所以这种模式出来的

是四行的结果

所以它做完了之后

它是把整个的重复了两遍

然后是四行

底下的这也是一样的

这个是可以的

在数据库里

大家也都是这样做的

然后你再想选出哪几行来

然后你就再去

根据那几行一选就行了

但是这个东西它是无意义地

计算了一个cross product

万一如果用户做完了

这件事之后

他并不想把每两个东西

都组合在一起

万一他用户还有一些个

更加（07：36）

或者说更加的自身定义的

一些（07：39）的方式

你非要把它Join在一起

反而对它来讲

就是一个浪费了这个Join

然后它要再把它重新洗开

洗干净洗开了

因此它这种CoGroup

还是给用户两个表的抽象

这儿有一个表

这儿有一个表

他可以自己再写一个操作

他对这个表做一下处理

对这个表做一下处理

然后剩下的一点点小的

再Join在一起

这个也是一种非常重要的

性能上的优化

因此我们的结论是什么

这个数据一大了

有些个操作

你在数据库里看起来

是非常非常容易的一些操作

我们往往要把它切得更细

为什么

因为这一个Lakers

可能这里头有无数无数个

results

这个表也可能很大

然后你一求叉乘

历史里的内存或者是硬盘

磁盘就爆了

所以它能不求就不能求

能不用算的东西

就不要算

因为用户可能有更聪明的办法

在中间你还没算的过程中

就帮你把这个结果解决了

所以你就不用再算了

所以它要一定要保存这样的中间结果

所以这是一个

叫CoGroup的过程

它也是为什么我们一定要支持

嵌套的数据结构的

一个重要的原因