spark的那些事(三) Structured streaming 窗口期内存数据的查询

之前的文章中提过，structured streaming处理流数据，如果使用聚合，将会有window的概念，对应属性watermark.不知你是否了解过druid，druid处理数据同样有窗口期的概念，用于判断数据何时丢弃.超时的数据将被直接丢弃.
druid的实现比较完善.不管是窗口期的内存数据还是固化到hdfa中的数据，都可以实时联合查询.而structured streaming目前尚未见到类似实现.前文提到它支持三种输出模式.complete.append和update.对于支持update的sink类型还好.若使用的sink类型，如elastatic search，不支持update呢？

试想一下，如果你的流数据每分钟聚合一次.允许延迟十分钟到达的数据有效.那么，对于仅支持append格式的es来说，从es查询到的数据将一直延迟十分钟.因为窗口期的数据存在发生变化的可能性.所以直到数据有效期结束才会被写入es.这样的查询延时当然难以被接受.

对于该问题，或许可以期待structured后续版本更新完善.现阶段，如果使用es等仅支持append模式的sink，
方案一：
可以考虑使用上文提到的foreach模式，首先将数据以update写入redis等内存数据库.再通过控制redis的数据过期来触发es写入.该方式的实现有可行性.略微复杂.需要自己写逻辑控制数据的过期和同步.查询的时候需要联合es进行查询.
方案二：
也可以考虑两个sink同时使用.一方面实时写入redis.且redis数据过期时间为十分钟.另一方面写入es.查询时联合两者查询.这种方式的缺陷是数据会被消费和处理两遍.增加资源消耗.

方案三：使用foreach update直接写入es.而不直接使用es官方提供的api.这种方式的缺点是增加es写入负担和硬盘资源消耗.同时.会有大量冗余数据进入es.查询时需做过滤.

方案四：
更直接的.如果可以.换掉es吧.使用kudu等列式存储.像上文所写存储redis的方式将数据写入kudu.该方式简单易行.需要关注的就是kudu的update性能.