AWS上的Lambda架构：选择数据库作为批处理层

Question

我们正在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查询）。巴赫层每小时产生50万至600万行。 仅最后一小时的结果应由具有低延迟随机读取的服务层查询。

我们的数据库都不符合批量插入和随机读取的要求。 DynamoDB不适合批量插入-由于批量插入所需的吞吐量，这太昂贵了。雅典娜是MPP，而且具有20个并发查询限制。流层使用ElasticCache，不确定在此执行批量插入是否是个好主意。

能否请您做出选择：引入第4种存储解决方案还是保留现有的？

考虑的选项：

1. 将批量输出持久化到DynamoDB和ElasticCache（很少更新并且可以压缩/聚合的部分数据移到DynamoDB；频繁更新的数据〜8GB /天移到ElasticCache）。
2. 引入另一个数据库（基于S3的EMR上的HBase / Amazon redshift？）作为解决方案
3. 使用S3 Select over parquet来克服Athena并发查询限制。这也将减少查询延迟。但是有S3选择任何并发查询限制吗？找不到任何相关信息
4. 您的解决方案？

第一个选项很糟糕，因为流式传输将批量插入ElasticCache。 它也遵循Lambda架构-在同一数据存储区中保留批处理和速度层视图吗？

第二种解决方案由于第4个数据库存储而不好，不是吗？

Answer 1

在这种情况下，您可能想要使用HBase或Druid之类的东西；它们不仅可以处理批量插入和极低延迟的随机读取，而且甚至可以从您的解决方案中替换DynamoDB / ElastiCache组件，因为您可以从传入流（到另一个表）中直接对其进行写入。

Druid可能对此更胜一筹，但是根据您的要求，您将需要HBase，因为HBase在Amazon Hadoop发行版的EMR中可用，而Druid不在托管产品中。