0

我们正在 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 查询）。巴赫层每小时生产 500,000 到 6,000,000 行。仅应通过具有低延迟随机读取的服务层来查询最后一小时的结果。

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

我们应该引入第四种存储解决方案还是保留现有解决方案？

考虑的选项：

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

第一个选项不好，因为流式传输使用的 ElasticCache 批量插入。它是否也遵循 Lambda 架构——将批处理和速度层视图保存在相同的数据存储中？

第二个解决方案不好，因为第四个数据库存储，不是吗？

4

1 回答 1

1

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

Druid 可能在这方面更胜一筹，但根据您的要求，您需要 HBase，因为它在 EMR 上与 Amazon Hadoop 发行版一起提供，而 Druid 不提供托管产品。

于 2018-10-29T18:42:42.917 回答