SnappyData--一个统一OLTP+OLAP+流式写入的内存分布式数据库_snappydata官网

一、背景：

    阔别个人博客有大半年了，这大半年来我从一个all in flink的角色转变到了一个兼顾实时流式处理与实时OLAP处理的角色。

    最近由于工作需要，在关注实时的OLTP+OLAP的HTAP场景的数据处理，优先保证低延迟的OLAP查询。说到这里，很容易让人想到Google的F1、Spanner，开源领域的代表TiDB。TiDB是个分布式的MySQL，对OLTP的支持很好，其有一个子项目叫做TiSpark，依赖Spark与TiKV做些OLAP的请求，但是这些复杂SQL执行的优先级(DistSQL API)是低于OLTP请求的，且当数据量大时(上亿条+多表join)，这些SQL执行的时间不是很理想。

    由于我们的需求是同时对流数据以及历史数据做OLAP查询，要求是快速的返回结果。Apache Flink等纯流式处理框架处理的是实时的数据，如果融入历史数据，那么实现起来也不是很方便。最主要的是如果OLAP查询的维度非常多，且不固定时，例如可以选择商圈、城市、省份、用户、时间等维度做聚合，那么flink去处理的话， 会发现key的选择很多，实现起来既麻烦也费时。如果选择druid或者kylin建立cube，那么由于我们的数据还会有些OLTP的操作，同时实时性也较差，因此也不太适合。

    因此我们注意到一个完全基于内存的分布式数据库(同步或异步写到磁盘)：SnappyData，其是一个行、列混和的内存分布式数据库，内部由GemFire(12306的商业版)+Spark SQL(支持列存可压缩)实现，既支持OLTP，也支持复杂的OLAP请求，且效率很高。

    上边说了来龙去脉，下面开始针对SnappyData发表的论文，对其进行简单的介绍。

二、SnappyData介绍

    在互联网时代，许多场景同时要求事务型操作、分析型操作以及流处理。企业为了应对这些需求，通常搭建各自用途的平台来分别处理OLTP类的关系型数据库，以及OLAP的数据仓库和Streaming流处理框架。在实现OLAP的过程中，已经有很多SQL On H