问题标签 [lambda-architecture]

我想为预测性维护构建一个实时应用程序。我考虑过将 Hbase 与 Phoenix 一起使用。Phoenix 在 HBase 上提供 SQL 层。

我读到 Hbase 对大数据有好处，比如 1 亿行加++。但是我的应用程序数据目前没有数据。如果一开始只有少量数据，Hbase 数据库将如何反应？HBase 是实时 Web 应用程序的一个很好的解决方案吗？

我想要一个类似 lambda 架构的系统。用于批处理和流处理。HDFS 之上的 HBase 会成为我的 OLTP 和 OLAP 系统吗？

由于 lambda 架构具有 Batch 和 Speed 层。我可以将 HDFS 中的 HBase 数据也用于批处理并将结果保存回 Hbase 吗？

一般来说，我想知道 HBase 是否是构建实时 Web 应用程序以进行分析的好解决方案。

我正在构建一个 lambda 架构，我编写了流层，现在我正在做批处理层。为此，我使用 Spark 2 作为批处理器，使用 HDFS 作为主数据。

为了从 HDFS 读取数据，我编写了以下代码：

但是，使用此代码，在运行 Spark 后插入 HDFS 中的新数据不会被读取。我想知道我怎么可能做到这一点？

只有结构化流（http://spark.apache.org/docs/latest/structured-streaming-programming-guide.html）的解决方案还是有其他解决方案？

在为实时和批处理规划我们的Lambda 架构时，我看到我们需要使用 DC/OS 的多个 m3.xlarge 实例（请参阅 CloudFormation SMACK 堆栈模板）。

为了不为 POC 带来太多成本，是否有一种方法可以让我们创建本地 Docker 容器，然后将它们部署到我们的 VPC，只为测试而启动？

如果 Kappa-Architecture 直接对流进行分析，而不是将数据分成两个流，那么在 Kafka 这样的消息系统中，数据存储在哪里？还是可以在数据库中进行重新计算？

单独的批处理层是否比使用流处理引擎重新计算进行批处理分析更快？

Kafka 作为存储系统可以是长期数据的数据存储。它可以毫无问题地复制和分发。那么我可以从Kafka中的所有历史数据创建RDD并创建批处理视图然后将其与Spark Streaming Views结合起来吗？

我一直在阅读 Nathan Marz关于如何使用 Lambda 架构击败 CAP 定理的文章，但我不明白不可变数据如何降低最终一致性的复杂性。

以下段落摘自文章：

关键是数据是不可变的。不可变数据意味着没有更新之类的东西，因此一条数据的不同副本不可能变得不一致。这意味着没有分歧值、矢量时钟或读取修复。从查询的角度来看，一条数据要么存在，要么不存在。该数据上只有数据和功能。您无需执行任何操作来强制执行最终一致性，并且最终一致性不会妨碍对系统进行推理。

想象一下下面的例子：我有一个分布式的仅插入数据库，有两个节点 A 和 B 并且都保存记录[timestamp=1; id=1; value=10]。然后同时，对节点 A 进行插入，导致[timestamp=2; id=1; value=20]对节点 B 进行读取以获取记录id=1。

与具有更新可能性的数据库相比，该示例解决最终一致性问题的复杂性如何？

我正在从 Kafka 接收流数据，我正在使用结构化 Spark 流将其作为数据帧读取。

问题是我需要在同一列上执行多个聚合，并使用该结果执行非基于时间的窗口操作。

在 Spark Structured Streaming 中仍然无法实现的 AFAIK，因此我想在一段时间后启动 Spark 批处理作业。

我怎么能做到这一点？有没有办法像 spark submit 一样启动 python 脚本？

我对 spark 实现的 lambda 架构做了一些研究，从下面的文章中我们知道合并批处理和实时视图的方法是使用 "realTimeView.unionAll(batchView).groupBy......" ，但是当batchView 后面的数据很大，用这种方式会不会有性能问题？？？

比如batchView后面的行数是100,000,000，那么spark每次客户端请求合并视图时都要groupBy 100,000,000行，这显然很慢。

https://dzone.com/articles/lambda-architecture-with-apache-spark

Nathan Marz 使用下图来解释 lambda 架构

Marz 的 Lambda 架构可视化

但是，在网上我经常发现如下架构，其中服务层不仅是批处理层之后的下一步，而且是流层，即

DZone 示例

据我所知，我认为，Marz 使用他的可视化来区分所用组件的不同要求/属性，即批处理层有很多写入，而服务层只需要在随机读取方面表现良好。可以直接查询流组件（即使用 API），因此不需要额外的数据库。

但是，我也理解服务层结合了批处理和速度层的可视化，因为两者都公开了某种视图。所以我不明白为什么 Marz 没有为速度层添加流层或使用 DZone 示例中的合并服务层。

有人可以解释一下，为什么 Marz 架构中的 Speed 层没有流层，或者为什么 DZone 示例中有流层？

谢谢！

我们正在 AWS 堆栈上构建 Lambda 架构。缺乏 devops 知识迫使我们更喜欢 AWS 托管解决方案而不是自定义部署。

我们的工作流程：

我们已经使用了 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 架构——将批处理和速度层视图保存在相同的数据存储中？

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