管道概念
　　以面向对象的思想去理解，整个流水线，可以理解为一个数据传输的管道；该管道中的每一个工作线程，可以理解为一个整个流水线的一个工作阶段stage,这些工作线程之间的合作是一环扣一环的。靠输入口越近的工作线程，是时序较早的工作阶段stage,它的工作成果会影响下一个工作线程阶段（stage）的工作结果,即下个阶段依赖于上一个阶段的输出，上一个阶段的输出成为本阶段的输入。这也是pipeline的一个共有特点！

　　为了回应用户对简单数据访问的需求,MongoDB2.2版本引入新的功能聚合框架（Aggregation Framework） ，它是数据聚合的一个新框架，其概念类似于数据处理的管道。 每个文档通过一个由多个节点组成的管道，每个节点有自己特殊的功能（分组、过滤等），文档经过管道处理后，最后输出相应的结果。管道基本的功能有两个：

一是对文档进行“过滤”，也就是筛选出符合条件的文档;
二是对文档进行“变换”，也就是改变文档的输出形式;

管道操作符：

SQL和NOSQL对比:

管道表达式:
管道操作符作为“键”,所对应的“值”叫做管道表达式。
例如{$match:{status:"A"}}，$match称为管道操作符，而status:"A"称为管道表达式，是管道操作符的操作数(Operand)。
每个管道表达式是一个文档结构，它是由字段名、字段值、和一些表达式操作符组成的。

关于$lookup

MongoDB 的核心分析工具是 aggregation，通过这个，你能创建一个任务管道（pipeline），对选中的文档施加各种操作，最后得到需要的数据。当你要聚合订单表时，首先在 pipeline 中添加个运算符，来匹配特定的几类产品的订单，然后用另一个运算符分组计算每类产品的销量。问题是 pipeline 只能对一个集合中的文档进行操作，因此，如果还需要操作另一个集合的时候，就玩不转了。MongoDB 3.2添加了一个 $lookup 操作符 用以引入其它集合的数据。

$lookup 操作符有一个 from 参数，用来指定你想从哪个集合拖数据。还有一个 on 参数用来指定另一个集合中的哪个字段跟 pipeline 中的哪个字段应该匹配。最后当匹配到一个文档，该文档会被插入管道中的文档，通过 as 参数设定一个 key 把该文档就放到这个 key 中。这个方式看上去有点暴力， 使文档变得很大， 别担心，其它的聚合操作符会把数据切小的。 $lookup 在聚合管道中有巨大的潜力，可以使用户不需要刻意将数据非正规化。不过我们要等到 alpha/beta 发布才能知道 $lookup 在实践中到底有多有效。