今天要讲的文章是SOSP 2017年的一篇文章，Wukong+S ：Sub-millisecond Stateful Stream Querying over Fast-evolving Linked Data。本文主要解决的问题是：随着流数据和存储数据量的不断增加，及时查询有用的信息十分重要。对于公共数据集合数据流，可能有大量的用户不同的数据流查询请求，因此需要支持高并发的查询。而且流数据通常包含巨大的有用信息， 这样的数据应该被一致地和立即地整合到存储系统，以用于将来的连续查询。
然而目前现有的系统对于正在变化的数据集的侧重点在于流计算。流计算和流查询不同的是 前者通常倾向于对大部分流数据进行序列化计算，而后者侧重于对流和存储数据的特定集合的并发查询。大多数先前的系统也没有集成流数据为了并发的查询中，或者不查询持久化存储的历史数据来获得基础知识，因此是无状态的。 尽管大多数流处理数据库都明确支持语义和SQL接口，但是他们在快速演化的Linked 数据下，当面临大量并发的查询请求下，由于高昂的Join操作开销和一些ACID的语义，他们的查询性能是低效的。
Wukong+S为了尊重数据本地化并最大限度地减少数据传输，它使用由基于时间的临时存储和连续持久化存储组成的混合存储，为正在到来的数据和持久化的数据提供不同的存储管理。Wukong + S提供了流数据的快速访问流索引。流数据通过局部感知分区进行分片，其中一些流索引在节点间动态复制。这节省了查询成本并提供高效的负载平衡。为了在多个不同规模的流数据上提供一致的流查询，Wukong + S使用分散的矢量时间戳来推导出最近一致性状态的流式数据插入。Wukong + S使用有限的标量化方案将矢量时间戳投影到标量快照数量中，通过协调多个流的更新到底层持久存储区。这样的设计在有效的内存使用情况下扩展了Wukong + S节点和大量查询。
1. RDF and SPARQL
那么什么是RDF数据呢？RDF全称就是资源描述框架。他将我们生活中的描述成每一个实体和实体之间的关系。每一个实体就是图中的一个顶点，相邻顶点的边就是两个实体之间的关系。他通过一组基于主题、谓词、对象的三元组集合 来描述现实生活中的资源。
2. BackGround
在我们生活中，每时每刻都在产生着大量的数据。不同的数据源高速不断地生成实时流数据。比如说社交网络数据、城市监控数据、视频图像数据。
在各种各样的应用场景下，产生的大数据主要可以分为以下两类。一类是实时流数据：这样的数据是非常快速的产生。一类是存储数据：也就是历史数据（存在的有价值的历史数据），这些数据是非常巨大的并且它由于stremdata，它还会不断演化。
然而对于社交网络，城市监控和市场反馈等应用需要有状态的流式查询，状态流查询不仅要查询存储历史数据，也要从实时流数据从提出有用的信息，查询实时流数据。实时流数据提取的有用信息，也需要持续不断地整合到存储的数据中，以便为上述和未来提供查询服务。 然而目前现有的系统对于正在变化的数据集的侧重点在于流计算。流计算和流查询不同的是 前者通常倾向于对大部分流数据进行序列化计算，而后者侧重于对流和存储数据的特定集合的并发查询。大多数先前的系统也没有集成流数据为了并发的查询中，比如关系型数据库，或者不查询持久化存储的历史数据来获得基础知识，因此是无状态的。
3.Example Dataset for Stateful Stream Query
我们来举一个简单的状态流查询的实例。
LinkeData 表示就是实体和实体之间的关系信息，存储的静态数据。假设目前存在这样一个查询需求：在过去30分钟内，哪些IPADS 成员发布了一个推文。这个推文被其他IPADS的成员点赞了。当这个查询请求被用户提交后，这个查询请求将不断在后台服务器中计算，并且不断地产生查询结果。直到这个查询请求被用户取消。
我们仔细分析上面的Example，可以得出这样的一个抽象的系统。在这样的一个系统中，存在着连接属性图数据。状态流查询不仅读取Store数据还读取实时流数据。并且这个存储的数据还是随着时间不断演化的，它会从实时流数据中吸收永恒的数据。
4. Conventional Approach
传统的解决方案是将实时流处理系统和图储存系统相结合。一次性查询任务直接被发送到Graph Store System 中，直接查询历史存储数据。而连续查询将被拆分成分别在流处理系统中和面向查询为主的图处理系统两部分分别执行。这两部分的结果将被join连接起来以得到最终结果。然而这样的混合设计仍然不全是状态查询。因为一次性查询只会运行在静态的存储数据中而没有从实时流数据得到更新后的实时数据。除此之外，这里还存在一些关键性的缺陷。
由于目前存在的CSPARQL-engine运行在单机节点中。作者将Wukong（分布式RDF图存储数据库）与Apache Storm（高吞吐量低延迟的实时流处理系统相结合）。
作者通过实验发现通过将实时流处理系统和图处理系统简单组合存在高延迟、低吞吐量的问题。主要是由于以下的这几个原因：
1. 首先，它存在跨系统的开销。因为它是将实时流处理系统和图储存系统简单结合，在二个不同系统之间存在数据转换和数据传输的开销。
2. 其次，为了降低跨系统执行的次数，组合设计会改变查询计划。通过改变查询条件的执行顺序，Strom首先将两个实时流数据进行join，得到一部分中间结果。然后将这个中间结果发送到Wukong中去，Wukong进行检索，最终得到查询结果。然而，对于两个实时流数据进行join操作，这通常会造成巨大的冗余数据和时间开销。
5. System Desgin
Wukong + S使用一种新颖的集成设计，用于快速演化的链接数据的状态流查询。Wukong+S在一个系统中管理实时流数据和静态历史数据。如何正常整合实时流数据和存储的数据？永恒持久化的数据和时效性很强的数据。
为了保证一次性查询，它既查询存储数据，也可以对实数流数据吸收其中永恒数据。Wukong+S提出了一个集中化的设计，在这个设计中数据被分成两个类型。一种是永恒持久化的数据，他被存储在Continuos Persisten Store这样的一个结构中它还会不断地从实时流数据中提取一些永恒可以用来持久化的数据（比如Like流和Tweet流）。还有一种数据是Timing data 瞬时实时的数据。这种数据和时间关联性很大，比如一些GPS 地理位置数据。一次性查询直接查询永恒的数据，因为这种查询不关心实时性的数据。持久化的查询会不断地从Timing Data以及Timeless Data中查询结果。
流处理系统首先由用户定义的谓语。将实时流数据分成两类分别是Timing数据和Timeless数据。Timeless数据被底层数据存储吸收写入到服务器引擎的持久化存储中。Timing数据被存储在Time-based transient store存储中。
5.1 Hybrid Store
Wukong+S 对于这样的永恒持久化的数据和瞬时实时的数据采用一种混合存储的策略。对于这种永恒持久化的数据，Wukong+S采用一种Continuous Persistent Store的结构。持续持久化存储不断从实时流数据中吸收永恒持久化的数据。他的设计目标就是支持持续的状态流查询和最新的一次性查询。
对于这种瞬时实时的数据，Wukong+S采用一种Time-based Transient 存储（基于时间的瞬时存储）。瞬时数据只会在一个时间间隔内被相关的连续查询请求访问。它的设计目标是：对于一部分瞬时的数据流，它能够支持快速垃圾收集(GC)。定期扫除过期的瞬时数据。
具体的细节设计如下图所示：
使用混合存储来存储实时流数据和永恒持久化数据，存在以下两点优点：
1.在实时数据和永恒数据之间不存在互相干扰。
2.由于设计数据存储分开来存储，我们可以针对不同的操作模式进行优化。
对于永恒持久化数据采用continuous persistent store 对于实时Timed数据采用time-based transient store。
6. Wukong+S Architecture
数据是被分区存储在多个服务器上的。每个服务器引擎都可以提供状态流查询功能和支持数据被分区存储功能。
6.1 Stream Index
那么如何在一定的时间间隔内快速访问持续持久化存储？Wukong+S提供了Strem Index机制，方便查询根据时间戳快速定位到相应的KV-Strore相应的存储中。
Wukong+S采用Stream Index机制，方便查询根据时间戳快速定为到相应的KV-Store相应的存储中。
6.2 Locality-aware partitioning
分区存储流索引的一般方法是将流索引和数据一起放置存储，这可以为连续查询提供数据局部性。然而，这种分区策略会造成连续查询的执行被拆分成多个节点，即迁移执行。然而同实验表明：这种迁移执行的方式，会造成严重额的网络传输的开销以及额外的调度延迟。Wukong+S考虑到索引大小一般都比较小，连续流查询可以从远程的节点中抓取数据，并且在一个机器上执行查询任务。这种策略叫做迁移数据。连续流查询还需要将Stream Index复制到执行持续性查询任务的机器上去，这样执行查询任务的机器可以通过Stream Index快速访问到流数据。
7 Consistent Data Snapshot
Wukong+S设计用于处理大量的查询请求。在分布式系统的实现中，面对大量的并发查询请求的时候，以及不断演化的Liked数据的时候，如何去提供一个一致性查询视图成为一个重要的挑战。
7.1 Decentralized Vector Timestamp （VTS）
Wukong+S 针对持续的查询工作，提出了一个向量时间戳的解决方案。
因为不同的服务器执行实时流数据插入的速度不一样，导致系统在执行RDF查询的时候。系统要给出一个整个集群插入数据的一致性视图。VTS：就是用来做这个工作的，首先每个服务器都有一个本地Local_VTS,用来标识本地服务器已经插入批次的位置。然后每个服务器将自己本地的Local_VTS发送给Master协调器Coordinator，协调器Coordinator维持一个Stable_VTS服务器用来保存全局信息。这个全局信息可以用来进行Continous Query操作。
7.2 Bounded Snapshot Scalarization
VTS的这种解决方案要求与矢量时间戳相关联的值中的所有流数据，由于大量的Key/Value键值对造成大量内存的开销，并且无边界的数据流还会造成大量的资源浪费。因此Wukong+S提出了一种Bounded Snapshot Scalarization的解决方案。
Wukong + S通过将矢量时间戳（VTS）转换为标量快照编号（SN）来解决此问题。 首先，协调员将预先公布快照号（SN）与矢量时间戳（VTS）范围之间的映射计划（即，SN-VTS计划），其次，每个节点上的工作进程确保所有流批次与相同的快照号码（SN）连续存储在键/值对中; 以这种方式，每个键的快照仅与一个存储间隔相关联。 最后，每个查询将获得稳定的快照编号（Sta ble_SN）而不是Stable_VTS，并使用它从持久性存储中读取一致的快照。
8.Evaluation
8. Conclusion
Wukong+S提出了一种分布式流查询引擎采用新型集成设计，实现快速演进链接数据的状态流查询。实现超过每秒100万次查询的亚毫秒延迟和吞吐量。