标签: lambda-architecture

我已经阅读了曼宁的大数据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架构的vs\cons与基于流的架构相比.

如您所知，Kappa体系结构是Lambda体系结构的某种简化。Kappa不需要批处理层，而是速度层必须保证历史数据重新计算的计算精度和足够的吞吐量（更多的并行性/资源）。

如果您需要基于历史数据进行分析，Kappa架构仍然需要两个服务层。例如，年龄小于2周的数据存储在Redis（流服务层），而所有较旧的数据存储在HBase的某个位置（批服务层）。

什么时候（由于Kappa体系结构）我必须将数据插入批处理服务层？ 如果流传输层将数据紧紧地插入批处理和流服务层中，那么迟到数据又如何呢？还是流层应该定期将速度服务层备份到批服务层？

示例：假设数据源是Kafka，数据由Spark结构化流或Flink处理，接收器是Redis和HBase。什么时候写入Redis和HBase？

我目前正在开发一个使用Azure Event Hub托管在Azure上的应用程序.基本上我是从Web API向Event Hub发送消息(或者我应该说,事件),我有两个监听器:

• 用于实时分析的Stream Analytics任务
• 标准辅助角色,根据收到的事件计算某些内容,然后将它们存储到Azure SQL数据库中(这是一个lambda体系结构).

我目前正在使用EventProcessorHost库从我的worker角色中的Event Hub中检索我的事件.

我正在尝试找到一些关于如何使用事件中心的最佳实践(使用事件中心比服务总线队列更难,即流式传输与消息消耗),我发现有些人说我不应该这样做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角色之间添加了一个队列(如果确实需要,则从评论中不清楚).

所以问题是:我应该在Event Hub之后直接执行所有处理工作(即在ProcessEventsAsnyc我的IEventProcessor实现方法中),还是应该在Event Hub和处理器之间使用队列？

任何有关如何正确使用事件中心事件的建议都会受到赞赏,文档目前有点......缺失.

我正在尝试使用以下工具实现Lambda架构:Apache Kafka用于接收所有数据点,Spark用于批处理(大数据),Spark Streaming用于实时(快速数据)和Cassandra用于存储结果.

此外,我收到的所有数据点都与用户会话有关,因此,对于批处理,我只对会话结束后处理数据点感兴趣.因此,由于我正在使用Kafka,解决此问题的唯一方法(假设所有数据点都存储在同一主题中)是批处理获取主题中的所有消息,然后忽略那些与会话相对应的消息尚未完成.

那么,我想问的是:

• 这是实现Lambda架构的好方法吗？或者应该使用Haddop和Storm？(我无法找到有关使用Kafka和Apache Spark进行批处理的人员的信息,Map Reduce)
• 有没有更好的方法来解决用户会话问题？

谢谢.

每次更改某些设备的属性时，我都会收集事件日志。为此，我决定使用：

1. Logstash - 我的代理 IoT 应用程序将日志以 JSON 格式发送到其中，
2. Elasticsearch - 用于存储数据（日志），
3. Kibana - 用于数据可视化。

带有日志的 JSON 正在定期发送，其形式如下：

{"deviceEventLogs":[{"date":"16:16:39 31-08-2016","locationName":"default","property":"on","device":"Lamp 1","value":"
false","roomName":"LivingRoom"}, ... ,]}

Elasticsearch 中的单个事件条目示例如下所示：

 {
            "_index": "logstash-2016.08.25",
            "_type": "on",
            "_id": "AVbDYQPq54WlAl_UD_yg",
            "_score": 1,
            "_source": {
               "@version": "1",
               "@timestamp": "2016-08-25T20:25:28.750Z",
               "host": "127.0.0.1",
               "headers": {
                  "request_method": "PUT",
                  "request_path": "/deviceEventLogs",
                  "request_uri": "/deviceEventLogs",
                  "http_version": "HTTP/1.1",
                  "content_type": "application/json",
                  "http_user_agent": "Java/1.8.0_91",
                  "http_host": "127.0.0.1:31311",
                  "http_accept": "text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2",
                  "http_connection": "keep-alive",
                  "content_length": "34861"
               },
               "date": "2016-08-08T14:48:11.000Z",
               "device": "Lamp 1",
               "property": "on",
               "locationName": "default", …

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

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