为运营分析而设计的数据系统

介绍一个有趣的数据系统Operational Analytics Processing，OPAP系统。不同于传统的OLTP和OLAP，它更注重于实时数据的即时分析。下面这篇文章加了我自己的一些理解和实践经验，原文请参考：https://www.rockset.com/blog/operational-analytics-what-every-software-engineer-should-know/

OPAP系统特征

OPAP系统构建了一个实时查询的系统可以使用者立马能够查询到实时数据。举个简单的例子，当用户参加一项活动时，产品经理或者是运营人员希望能够马上获得用户的参与效果，并且快速的探索用户的行为特征，从而立马改进活动以获得更好的效果。正所谓：越来接近实时的数据，越有价值。OPAP系统的意义便在于此。

为了达到这样的效果，OPAP系统必须具有以下的几个特征：

• 支持复杂查询：例如 joins, aggregations, sorting等类型的查询，最好能是SQL语句。
• 低数据延迟: 数据的任何变化都能够在几秒钟内被查询到。因为主要是用于分析，所以OPAP系统无需像OLTP系统一样支持事务。基于此，OPAP系统可以保持高吞吐的写入和在几秒钟内看到最新的数据（即最终一致性）。
• 低查询延迟：可以在几百毫秒内返回一个简单的查询结果。这一点类似于OLTP系统，每一次的查询都只牵扯到很少的数据量。
• 支持并发查询: 能够支持几百条每秒的并发查询。OPAP系统不追求高并发，但是需要支持用户可以进行频繁的查询。
• 数据源实时同步：能够持续的同步外部数据源，这个是保持OPAP系统的实时性的核心。
• 混合类型：允许在同一列出现不同类型的数据。可以避免OPAP系统无须在数据写入时对数据进行清理,这样就可以尽可能的实现数据低延迟。

架构设计的要点

The Database is the LOG。

从这个角度来看OLTP还是OLAP数据系统，数据都会先经过数据库客户端，然后将事务信息写入到log当中。此时的log是事务引擎。

而OPAP系统追求的是更低的时延，所以数据会先写入到log，然后再由数据库客户端处理后返回结果。这里的log只是数据缓冲。

查询的时候绑定数据类型而不是写入时

由于OPAP架构的独特性，导致了传统数据系统先定义表和数据类型的方式不再适用，而是允许数据以任意方式写入log，数据库客户端在查询数据时才绑定数据类型。

目前主流数据库的实现

与OLTP数据库的比较

OLTP要支持事务，每一次的更新和插入都是少量数据；但是OPAP系统不需要事务，且支持大规模写入数据。

与OLAP数据仓库比较

OPAP和OLAP数据仓库都支持复杂的查询和大规模写入，但是OLAP不能做到实时数据的即时查询，而OPAP系统可以。然后，OLAP系统在写入数据支持就需要很严格的格式，OPAP系统只在查询时检查数据格式并处理。

与HTAP系统比较

HTAP是OLTP和OLAP系统的混合物，因此上述提到的区别适用于HTAP。

与 key-value 存储的比较

像 Cassandra 和 HBase 之类的KV存储提供了低延迟和高并发，但是KV存储不像OPAP系统那样提供特别复杂的查询数据功能，例如Join、排序等等。

与类Log系统比较

类Log系统指的是 Kafka、Samza 这类基于log构建的系统，它们支持实时写入数据查询，但是不支持复杂的查询。

与文档系统比较

文档系统，例如MongoDB，原生支持复杂的数据存储格式，大规模数据写入和实时写入数据查询，但是不支持复杂的查询，例如Join等等。

与时间序列数据库比较

时间序列数据库是一种特别的OPAP系统，除了复杂的查询和混合格式写入外，其它的属性都支持了。

简单总结如下：

总结

OPAP系统并不太像传统的数据库，它单纯只是为了让数据能够更快的被分析。基于这个理念，便有了很多有趣的特性，比如不支持事务，直接将数据落盘到log。同样的也局限了它的用途，无法适用于更为广泛的场景。

在平时的实践中，如果是小数据量，传统的关系型数据库就足以解决了，数据量变大时，使用像Kudu一样的分布式数据库满足了大部分场景。

总的来说，作者的设想是很有意义的：对于某些分析场景，使用Flink、Spark Streaming实时计算引擎，算出结果显得太重，也不够灵活；类OPAP系统可以通过简单的SQL语句将工作量释放给产品和运营人员，大大减少了开发人员的压力，减少了不必要的沟通，更快的获知线上活动的情况，以期做出更好、更快的反应。