问题标签 [lambda-architecture]

我已经阅读了 Manning 的大数据 Lambda 架构 ( http://www.manning.com/marz/BD_meap_ch01.pdf )，但仍然无法理解为什么它被命名为“Lambda”。它是这个架构所基于的系统的代号或名称吗？

免责声明：我不是实时架构专家，我只想提出一些个人考虑并评估其他人的建议或指出。

假设我们想设计一个实时分析系统。遵循 Lambda 架构 Nathan Marz 的定义，为了提供数据，我们需要一个批处理层（即 Hadoop），不断地从所有数据的数据集中重新计算视图，以及一个所谓的速度层（即 Storm），它不断处理视图的一个子集（由批处理层最后一次完全重新计算后进入的事件产生）。您可以通过将两者的结果合并在一起来查询您的系统。

这个选择背后的理由对我来说非常有意义，它结合了软件工程和系统工程的观察。拥有一个不断增长的不可变时间戳事实的主数据集使系统能够在计算视图时适应人为错误（如果你犯了错误，你只需修复它并在批处理层重新计算它们）并使系统能够回答几乎任何将来会出现的查询。此外，这样的数据存储只需要支持随机读取和批量插入，而用于速度/实时部分的数据存储需要有效地支持随机读取和随机写入，从而增加了其复杂性。

我对此讨论的反对/触发是，在某些情况下，这种方法可能是一种矫枉过正。为了讨论，假设我们做了一些简化：

• 假设在我们的分析系统中，我们可以预先定义小时系统需要能够提供的一组不可变的用例\查询，并且它们将来不会改变。
• 假设我们有有限的资源（工程能力、基础设施等）来实现它。存储进入我们系统的整个基本事件集，而不是预先计算视图\聚合，可能太昂贵了。
• 让我们假设我们成功地减少了人为错误的影响（...）。

该系统仍然需要可扩展并处理不断增长的流量和数据。鉴于这些观察，我想知道什么会阻止我们设计一个完全面向流的架构。我想象的是一种架构，其中事件（即页面视图）被推送到流中，可能是 RabbitMQ + Storm 或 Amazon Kinesis，并且此类流的消费者将通过随机写入/更新直接更新所需的视图NoSQL 数据库（即 MongoDB）。

乍一看，在我看来，这种架构可以水平扩展。Storm 可以集群化，也可以预先保留 Kinesis 预期的 QoS。更多的传入事件意味着更多的流消费者，并且由于它们是完全独立的，没有什么能阻止我们添加更多的。关于数据库，使用适当的策略对其进行分片可以让我们将越来越多的写入分配到越来越多的分片。为了避免读取受到影响，每个分片可以有一个或多个读取副本。在可靠性方面，Kinesis 承诺将您的消息可靠地存储长达 24 小时，并且正确使用确认机制的分布式 RabbitMQ（或您选择的任何队列系统）可能会满足相同的要求。

亚马逊关于 Kinesis 的文档故意（我相信）避免将您锁定在特定的架构解决方案中，但我的总体印象是，他们希望推动开发人员简化 Lambda 架构并实现类似于我的完全基于流的解决方案。暴露了。为了更符合 Lambda 架构要求，没有什么能阻止我们在消费者不断更新我们的视图的同时拥有一组消费者，这些消费者处理传入的事件并将它们作为原子不可变单元存储在不同的数据存储中将来用于生成新视图（例如通过 Hadoop）或重新计算错误数据。

你对这个推理有什么看法？我想知道纯基于流的架构在哪些场景下无法扩展，如果您有任何其他观察结果，Lambda 架构与基于流的架构的优缺点。

在“大数据”Lambda 架构书之后，我有一个输入目录，里面充满了类型化的 Thift 数据对象，其中包含一个 DataPailStructure 定义的 pail.meta 文件

我拍摄了这些数据的快照：

传入的文件和元数据文件是重复的，pail.meta文件也有

现在我想切碎这些数据，将其分成垂直分区。与本书一样，我创建了两个 PailTap 对象，一个用于 Snapshot 和 SplitDataStructure，一个用于新的Shredded文件夹。

/Shredded文件夹有一个 pail.meta 文件，其中包含structure: SplitDataPailStructure

按照说明，我执行 JCascalog 查询以强制减速器：

现在，在本地模式下，这工作正常。在 /Shredded 下创建了一个“临时”子文件夹，它以预期的“1/1”结构垂直分区。在本地模式下，然后将其移至 /Shredded 文件夹，我可以毫无问题地合并并合并到 master。

但是在 Hadoop 内部运行，此时它失败了，并出现错误：

不用说，如果我将 Shredded Sink 结构类型更改为 DataPailStructure，那么它可以正常工作，但这是一个相当没有意义的操作，因为一切都在 Incoming 文件夹中。现在没关系，因为我只使用一种数据类型，但这很快就会改变，我需要那个分区。

有任何想法吗？我最初不想在这里发布我所有的源代码，但我几乎可以肯定错过了一些东西。

我正在考虑实施 Lambda 架构以处理由多个设备传输的事件。在大多数情况下（平均值等），它似乎符合我的要求。但是，我一直在尝试为特定用例建模。简而言之...

每个设备都有一个device_id。每个设备每秒发出 1 个事件。每个事件的event_id范围为 {0-->10}。

event_id 为 0 表示开始，event_id 为 10 表示结束

START 和 END 之间的所有事件都应归为一个组 (event_group)。这将产生 event_groups 的元组，即{0,2,2,2,5,10} , (0,4,2,7,...5,10), (0,10) 这 (event_group) 可能很小即10分钟或非常大的说3小时。

根据 Lambda 架构，每台设备传输的这些事件都是我的“主数据集”。目前，事件使用 Kafka（Camus，Kafka Spout）发送到 HDFS 和 Storm。

在 Streaming 过程中，我按 device_id 分组，并使用 Redis 在内存中维护一组传入事件，基于每次 event_id=0 到达时生成的键。 问题在于HDFS。假设我每小时保存一个包含所有传入事件的文件。有没有办法区分这些（group_events）？

使用 Hive，我可以以相同的方式对元组进行分组。但是，每个文件也将包含“破碎”的 event_groups

• (0,2,2,3) 先前的计算（文件）
• (4,3,) 先前的计算（文件）
• (5,6,7,8,10) 电流计算（文件）

所以我需要根据device_id将它们合并到（0,2,2,3,4,3,5,6,7,8,10）（多个文件）

Lambda 架构是否适合这种情况？还是流式处理应该是唯一的事实来源？即写入 hbase，hdfs 本身不会影响整体延迟。

如果我现在正在构建一个应用 Lambda 架构的项目，我是否应该将批处理层和服务层分开，即程序 A 做批处理层的工作，程序 B 做服务层的工作？它们在物理上是独立的，但在逻辑上是相关的，因为程序 A 可以在 A 完成预计算工作后告诉 B 工作。

如果是这样，你能告诉我如何实现它吗？我在考虑IPC。如果IPC可以帮助，具体方法是什么？

顺便说一句，“批处理视图”到底是什么意思？为什么以及如何服务层索引它？

我正在实现 Lambda 架构，分别对批处理层和速度层使用 spark 和 spark 流。到目前为止，我将批处理视图和实时视图都存储在 HBase 中，但存储在不同的表中。

我被困在如何合并批处理视图生成的批处理视图和速度层生成的实时视图，以便进行查询。怎么做才对？我是否应该将它们转储到同一个 HBase 表中，然后客户端直接查询 HBase？

我目前正在开发一个托管在 Azure 上的应用程序，该应用程序使用 Azure 事件中心。基本上，我正在从 Web API 向事件中心发送消息（或者应该说是事件），并且我有两个侦听器：

• 用于实时分析的流分析任务
• 一个标准工作角色，它根据接收到的事件计算一些东西，然后将它们存储到 Azure SQL 数据库中（这是一个 lambda 体系结构）。

我目前正在使用EventProcessorHost库从我的辅助角色中的事件中心检索我的事件。

我正在尝试找到一些关于如何使用事件中心的最佳实践（使用事件中心比使用服务总线队列更难，即流式处理与消息消耗），我发现有些人说我不应该这样做EventData从我的事件中心检索事件后进行大量处理。

具体来说 ：

• http://blogs.msdn.com/b/servicebus/archive/2015/01/16/event-processor-host-best-practices-part-1.aspx

请记住，您希望保持您正在做的事情相对较快 - 即不要尝试从这里做很多流程 - 这就是消费者群体的目的。

• http://blogs.msdn.com/b/musings_on_alm_and_software_development_processes/archive/2014/09/03/azure-event-hubs-queues-and-workers.aspx

本文作者在 Event Hub 和 worker 角色之间添加了一个队列（从评论中不清楚是否真的需要）。

所以问题是：我应该直接在事件中心之后（即在ProcessEventsAsnyc我的IEventProcessor实现方法中）完成所有处理工作，还是应该在事件中心和处理工作之间使用队列？

任何有关如何正确使用事件中心的事件的建议都将不胜感激，文档目前有点......丢失。

Nathan Marz 在他的“大数据”一书中描述了如何在HDFS中维护数据文件，以及如何使用在Map Reduce上运行的Pail库优化文件大小以尽可能接近原生 HDFS 块大小。

1. 是否有可能在Google Cloud Storage中实现相同的结果？
2. 我可以为此目的使用Google Cloud Dataflow代替 MapReduce 吗？

我阅读了 Nathan Marz 关于 lambda 架构的书。我实际上是在证明这个解决方案的概念。

我很难构建我的 Jcascalog 查询。

这是我们感兴趣的节俭模式中的一部分：

我用 Pail 将一些数据存储到文件夹中：/home/tickets

现在我想对这个数据提出一个请求：我想得到按文章名称分组的数量总和。所以首先我需要得到名称，然后是数量。对于每个我可以获得文章的 ID。

例如，对于名称 request(id_article, name)，我将得到以下结果：(1, pasta) - (2, pasta2) - (3, pasta)

对于数量请求（id_article，数量）：(1, 2) - (2, 1) - (3, 1)

问题是我不怎么合并结果？如何在 HDFS 中加入 Cascalog 和数据？

新手来了 尝试使用 Pail 运行 Nathan Marz 的书 Big Data DFS Datastore 中的代码。我究竟做错了什么？尝试连接到 HDFS 虚拟机。尝试用文件替换 hdfs。任何帮助表示赞赏。

得到一个错误 -

将 HDFS 替换为 file:///