根据我的经验，我们使用hbase作为spark流数据的数据存储（我们也有相同的场景—多写少读），因为我们使用的是hadoop，hbase与hadoop进行了本机集成，运行得很好。。
在上面，我们习惯于储存来自慰藉中心的高速信息。
hbase非常适合进行基于范围的扫描。Cassandra以可用性和许多其他东西而闻名。。。
然而，在许多项目中，我也可以观察到一个总的趋势，即通过spark dataframe的spark流，将rawdata简单地存储在分区结构的hdfs（parquet+avro）中( SaveMode.Append) 他们正在用spark处理原始数据
hdfs中分区结构的ex: completion ofbusinessdate/environment/businesssubtype/message type 等。。。。在这种情况下，不需要转到hbase或任何其他数据存储。
但上述方法中的一个常见问题是，当您通过流式处理获得小而小的文件时，您需要 repartion(1 )或者 colelese 或者 FileUtils.copymerge 以满足单分区文件的块大小要求。除此之外，上述方法也可以。
这里有一个叫做cap定理的东西，可以根据它做出决定。

一致性（所有节点在同一时间看到相同的数据）。
可用性（每个请求都会收到一个关于它是成功还是失败的响应）。
分区容差（尽管由于网络故障而进行了任意分区，系统仍能继续运行）
Cassandra支持美联社。
hbase支持cp。
请看这里给出的详细分析