我们正在AWS堆栈上构建Lambda架构。devops知识的缺乏迫使我们更喜欢AWS管理的解决方案，而不是自定义部署。
我们的工作流程：
[Batch layer]
Kinesys Firehouse -> S3 -Glue-> EMR (Spark) -Glue-> S3 views -----+
|===> Serving layer (ECS) => Users
Kinesys -> EMR (Spark Streaming) -> DynamoDB/ElasticCache views --+
[Speed layer]
我们已经使用了3个数据存储：ElasticCache、DynamoDB和S3(使用Athena查询(。巴赫层每小时产生500000到6000000行只有最后一小时的结果才能由具有低延迟随机读取的服务层查询。
我们的两个数据库都不适合批量插入&随机读取要求。DynamoDB不适合批量插入-它太贵了，因为批量插入需要吞吐量。Athena是MPP，而且有20个并发查询的限制。ElasticCache由流层使用，不确定在那里执行批量插入是否是个好主意。
我们应该引入第四个存储解决方案还是继续使用现有的解决方案？
考虑的选项：
- 将批处理输出持久化到DynamoDB和ElasticCache(很少更新并且可以压缩/聚合的部分数据将转到DynamoDB；频繁更新的数据~8GB/天将转到ElasticCache(
- 引入另一个数据库(HBase on EMR over S3/Aamazon redshift？(作为解决方案
- 在镶木地板上使用S3 Select可以克服Athena并发查询的限制。这也将减少查询延迟。但是是否有S3选择任何并发查询限制我找不到任何相关信息
第一个选项不正确，因为流使用了批量插入ElasticCache它还遵循Lambda架构吗？将批处理和速度层视图保持在相同的数据存储中
由于第四个数据库存储，第二个解决方案很糟糕，不是吗
在这种情况下，您可能想要使用类似HBase或Druid的东西；它们不仅可以处理批量插入和非常低延迟的随机读取，甚至可以取代解决方案中的DynamoDB/ElastiCache组件，因为您可以从传入流(到不同的表(直接向它们写入。
Druid可能在这方面更出色，但根据您的需求，您会想要HBase，因为它可以在带有Amazon Hadoop发行版的EMR上使用，而Druid没有托管产品。