Kappa是一种大数据(离线、实时)处理的方法论，主要为了实现低延时地处理所有的大数据，同时又不用为一份数据开发两份代码(相对于Lambda架构来说)，本文是阅读Kappa论文的一篇笔记。
Lambda Architecture
Lambda架构的核心在于: 对于同一份数据开发对应的两套处理逻辑：批量处理逻辑和实时处理逻辑。而前端查询数据的请求通过综合实时和离线的数据，来得到最终的结果。
Lambda架构的优点很明确，它让我们有了从来没有的能力:
可以以非常低的Latency来处理大数据的能力，而且这个"数据"是我们的全量数据。
但是它的缺点也很明确:
对于同一份数据，我们要维护两套逻辑
Kappa
Kappa觉得为一份数据维护两套逻辑不可行。它提出两种可能的方式:
- 定义一种新的语言，这种语言可以被编译成"实时"和"离线"的版本。
- 增强实时处理框架的能力，让它可以处理所有数据
定义一种新的语言，这种语言可以被编译成"实时"和"离线"的版本
这说的不就是Apache Beam么？
作者认为即使可以代码只写一份。但是运维的负担（运行和调试）会非常高。虽然代码只写一份，但是用户在实际使用过程中必然需要对实时和离线的系统都非常的了解。
而且任何新的抽象只能提供下层框架能力的交集，如果使用上层新的语言，新的抽象会使得我们不得不抛弃底层系统比如: Hadoop生态系统那些优秀的框架(Hive, Pig, Crunch, Cascading, Oozie之类的)。
而且要给底层不同的框架抽象出一层上层语言非常的不容易，作者举的例子是那些ORM(Object Relational Mapping), ORM实现其实非常难、坑很多(对这个实现细节不是太了解，不作太多评论)，而且相对来说各种数据库的差异性其实不大，而实时、离线框架的差异性就大多了。
我比较同意这一点，要给不同的底层系统抽象一层共同的语言，非常的不容易。
但是现在Beam确实就走在这么一条路上了, 但是可能又稍有不同。因为Beam的影响力在那里，而且有Google在背书。它相当于定了一个大数据的规范，适配不适配这个规范你们框架看着办吧，反正我这套规范很牛逼(Google嘛，大数据界的翘楚)，你不适配就等着被淘汰吧。现有的以及新的框架很可能会考虑适配Beam的标准，以使自己的框架不至于落伍。
而且Google推Beam的主要目的不是为了统一大数据语言而统一，它有它背后的商业目的。统一之后可能运行在Hadoop上， Storm上都可以。但是运行在Google的云平台上会运行的最有效率。当大家都使用这种语言来开发大数据处理程序的时候，让大家迁移到Google云平台的代价就小了。所以Google的目的从来不是为了统一语言而统一，最终还是为了更好的卖自己的服务。
增强实时处理框架的能力，让它可以处理所有数据
作者其实更推崇这种方案，感觉作者是个实干派，不相信那种理想的可以同时处理和实时的新语言。也不愿意把一份处理逻辑写两份。因此他的方案是要用一个实时的系统把所有的事情都干掉。
- 利用消息队列(Kafka)保存历史数据，以备数据处理逻辑变更的时候可以对数据进行重新处理(reprocessing)。
- 当业务逻辑发生变化的时候，我们更新实时处理逻辑，并且运行这个更新过的实时处理任务(老的任务先不停)，这个实时处理任务会把结果数据写进一个新表。
- 新的任务从消息队列里面读历史数据来得到新的、全量的数据
- 新的任务经过一段时间运行之后处理完所有的历史数据，可以替代原来的老的任务了。
- 停掉老的任务。
这样通过一份代码、使用一套框架就可以实现所有的数据处理逻辑。但是这需要消息队列有能力保存足够长时间的历史数据。LinkedIn的Kafka其实就是为了这个目的而设计的。
这个方案的缺点在于当我们更新数据处理逻辑的时候，需要的机器的数量是平常的两倍而且存储成本也会比平时多。
感觉这个方案也不是很靠谱，每次代码变更都要把所有的历史数据利用实时系统从头跑一遍，感觉蠢哭了。不会是最终的方案。
但是这种想法确实很新颖。
