Pinot是一个每秒可以处理数以万计分析类查询的系统，支持近实时地从流式数据源进行数据摄取。简单来说作为一个分析类系统：数据进得快、查询返回快。
为了达到数据消费的实时性，Pinot采取了Lambda的架构，Pinot把它叫做"Hybid table", 一份数据同时存在实时和离线两部分，用户将查询的时候，Pinot同时查离线和实时的数据，然后把merge的结果返回给用户，关于这种Lambda架构的特点，后面还会详细讨论一下。
Pinot里面数据也是按照传统的数据库、表的形式来组织的。在物理上 Pinot 的表是被切分成一个个 Segments，而这些Segments会被复制多份保存，以保证数据可用性。Segment数据是不可变的, 要插入新数据，或者对数据进行更新是通过替换整个segment来完成。(Segment的内容是不可变的，但是Segment整个是可以被替换掉的)。Segment里面的数据是按照列来存的，这算是分析性数据库的标配了，主要为了查询的时候可以扫描最少的数据，达到更大的存储压缩比等等。
Pinot的查询语言是标准SQL的一个子集：PQL，不支持JOIN，不支持嵌套子查询，不支持DDL(表结构是通过souce control工具来维护的，感觉在他们内部可能是需要通过提申请才能添加新表的)，而且不支持任何单条记录级别的创建、更新、删除操作等等。
限制太多了啊，在目前这个时间点看来，感觉有点弱啊。
跟Storm设计思想类似的是，Pinot也是一个Share Nothing的架构，所有的组件都是无状态的，任何节点随时都可以被停掉，然后再另外一台机器起另外一个实例代替。
Lambda架构
上面提到Pinot采用了Lambda架构以达到数据已最快的速度可以被用户查询到的目的。Lambda架构这个概念是Storm的作者Nathan Marz提出来的，它主要的目的在于让我们可以既能及时的获取到最新的数据(通过流计算引擎), 同时又要保证数据的准确性(通过离线计算引擎)。典型的 Lambda 架构如下图:
每次查询过来会分别取查询离线和实时的数据、在合并之后返回给用户。
但是从目前的大数据领域来看，Lambda架构并不是一个特别好的方式，原因就在于它的复杂性，对于同一份数据，要同时维护离线和实时两套代码，而这两套在模型上不完全一样，但是要强行糅合到一起进行配合，Pinot特性上的一些限制，比如不支持join，不支持嵌套查询，我怀疑跟这种复杂架构是有关系的。而且要使用好这一套架构需要你同时对离线和实时计算引擎都非常精通，以便进行性能调优，问题排查。LinkedIn的Jay Kreps这段评价我深以为然:
The API meant to hide the underlying frameworks proved to be the leakiest of abstractions.
-- Jay Kreps (LinkedIn Principal Staff Engineer)
Lambda架构(包括我们的主角Pinot)尝试要解决的一个问题就是要通过一个系统把离线和实时的底层框架糅合在一起了，我感觉这个事情太难了。现在比较流行的，看起来应该也是未来发展方向的是一种叫做Kappa的架构, 这种架构认为Lambda架构之所以出现是因为它确实解决了数据实时性 + 准确性的需求，其根本原因还是在于实时计算引擎的能力问题，只要实时计算能够:
- 有办法以流计算引擎可读的形式保存大量的历史数据。
- 非常快的处理历史数据。
- 可以非常精准的处理数据。
那么完全可以把离线计算引擎那条路去掉，整个架构就大为简化:
而目前在Kafka, Flink等等先进的流计算/存储框架出现的情况下，感觉时机已经成熟了。我觉得这个应该是未来，因为一是简单，二是实时是未来，计算引擎的方向应该也是实时。
多租户
正如论文里面所说，在一个大公司里面，为不同的业务、不同的场景搭建单独的集群肯定是有问题的，原因有很多，一是会造成资源浪费：不同的业务使用会有波峰波谷，搭建单独集群使得不同集群之间资源无法在业务波谷的时候给别的业务使用。但是也不能什么措施也不做，直接混用一个集群，这会使得一个业务的过分使用导致其他业务得不到资源。因此多租户是个必须要做的事情。
Pinot里面多租户的实现手段非常的简单，它给每个业务发放一些token，这些token会随着时间的推移以一定的速度不停的发放，但是达到指定的最大值之后不再增长。每当一个查询过来，就从这个token池子里面消耗一些token，当token被消耗完之后，再来新的查询就要等待了，等待产生足够的token之后再继续执行。
这个方法的特点是特别的简单易懂，看上去很漂亮。后面要看看其它系统是怎么做的，有没有更精细的做法。
Pinot VS Others
说实话从这个对比来看，Pinot对我的吸引力很小，首先我最看重的 Query Flexibility, 从前面我们知道Pinot查询能力方面很受限制，JOIN都不支持，感觉用户压根就没法用。而 "Fast ingest and indexing" 目前通过Lambda架构首先的思路不是很好，维护的难度，运维的复杂性都很高，如果只考虑通过Kafka接进行写入的思路，而把流计算那部分去掉的话倒是一个解决数据实时性的不错思路。
另外Pinot这里提到了一个"Offline OLAP"的概念，这里它指的是类似Hive, Impala, Presto这类引擎，之所以说作者把他们成为offline，我理解可能还是数据实时性的问题，这类系统接的基本都是分布式文件系统，数据一般都是 T - 1 的。
总结
从这篇论文里面我个人最大的收获是两个，一是学习了这种多租户资源隔离的技术，非常简单，非常优雅，为后续读其他论文找到了一个新的方向；另外一个是重温了Lambda架构，Lambda架构本身是有它的历史和现实意义的，但是由于他的复杂性，终究不会成为一种主流的架构方式。
