Question

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

Logstash - 我的代理IoT应用程序以JSON格式发送日志的地方，
Elasticsearch - 用于存储数据（日志），
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",
               "roomName": "LivingRoom",
               "value_boolean": true
            }
 }

我的目标是创建一个带有某种仪表板的网站，在合理的时间内显示分析的数据（几分钟应该是可以接受的），即：

显示能耗历史并预测功能消耗
检测能源消耗异常或其他因素，如灯光或供暖使用
显示基于某种非软化统计数据的推荐信息，即＆＃34;您可以将给定设备从location1移动到location2，因为它在那里需要更多（比其他地方使用得更集中）＆＃34;等等。

虽然最后一点非常简单 - 我可以在Elasticsearch中使用简单查询或聚合，然后将其与某个阈值进行比较，前两点需要深入分析，如机器学习或数据挖掘。

目前系统配备了大约50台设备，平均每10秒更新一次状态。将来，设备数量可以增加到50 000个。为一个事件日志承担100个字节，它可以在Elasticsearch中每年产生大约15TB的数据。

一般问题是 - 这种系统的合理解决方案/技术/架构是什么？

将所有日志存储在Elasticsearch中是否合理开始？
我认为es-hadoop库使用Elasticsearch和Apache Spark来使用Spark中的Mlib来处理我的数据 - 这是一个合理的方向吗？
我是否可以仅使用Elasticsearch将所有数据存储在其中，只使用Spark和Mlib提供深入分析，或者我应该考虑实施所谓的＆＃34; Lambda Architecture＆＃34;将Elasticsearch视为速度层？关于使用Kafka，Apache Storm但我不确定需要它的各种配置，我有点红了。由于项目应该在一个月内完成，我是初学者，我担心复杂性，因此需要时间来实施。
如果数据负载小10倍（每年大约1.5太字节）怎么办？ - 你的回答是否相同？

Answer 1

这是一个非常复杂的问题，让我试着将其分解：

您应该考虑的问题

您的数据可用于查询的端到端延迟是多少？你需要它是实时的吗？或者你可以延迟吗？
您愿意容忍的数据丢失是什么？
您正在考虑的分析/ ML算法的准确度是多少？您是否需要高度准确的结果，或者您对某些不准确之处感到满意？
只有在完成或需要某种推测结果时才需要结果吗？

这些问题以及数据负载增加时的空间限制和延迟等常规应该可以帮助您确定正确的解决方案。

通常，这些问题可以视为摄取 - ＆gt;处理 - ＆gt;介绍

摄取 - 需要消息总线

通常，人们选择像Kafka这样的消息总线来处理来自缓慢下游消费者的反压，并提供可靠性（通过持久保存到磁盘）以防止数据丢失。 Kafka在Spark流媒体，德鲁伊firehose支持，ES插件等集成方面也有很好的社区支持。

处理 - 需要可扩展的计算层

这是您需要决定实时与批处理，适用数据丢失，准确与投机结果等内容的对象。阅读Tyler Akidau关于https://www.oreilly.com/ideas/the-world-beyond-batch-streaming-101流媒体的文章一个详细的解释。

人们选择Spark流式传输用于实时用例，而简单的M / R工作应该可以完成批处理作业。如果您计划进行流式传输作业，那么窗口化和事件会话可能会使事情进一步复杂化。

演示文稿 - 需要互动查询和快速回复

这是前置应用程序要集成的地方，选择一种非常适合预期查询类型和所需响应准确性的工具是有意义的。

ES等工具在搜索，过滤和分面方面表现非常出色，但在需要复杂的数学聚合时却失败了。 AFAIK ES不支持像Druid那样的HyperLogLog等概率结构。

<强>改造

现在您必须将您对上述每个图层的要求进行映射。

显示能耗历史并预测功能消耗

检测能源消耗异常或其他因素，如灯光或供暖使用

如前所述，您显然需要机器学习库。拥有MLib支持的Spark非常棒。

显示基于某种非软化统计数据的推荐信息，即＆＃34;您可以将给定设备从location1移动到location2，因为它在那里需要更多（比其他地方使用得更集中）＆＃34;等等。

你甚至可以在Spark上使用MLib来实现这一点，并将建议提取到ES中的单独索引甚至是Kafka主题，您可以进一步将其下载到HDFS或ES。在这里你应该小心垃圾收集，因为这可能导致数据爆炸，你需要在这里保持积极性。此外，预先计算建议可以帮助您更快地执行诸如警报，推送通知甚至是来自UI的查询等反应性内容。

为一个事件日志承担100个字节，它可以在Elasticsearch中每年产生大约15TB的数据近似值。

这些是使用任何存储系统进行配置的常见问题。您可以通过计算历史数据的物化视图来优化此处，但您可以稍后再做出决定，因为这会导致过早优化。您最好先测量查询的存储和延迟，然后对容量进行追溯分析。

将所有日志存储在Elasticsearch中是否是一个合理的开始？

非常考虑你的用例。但是如果使用Spark流/ MLib或批量MR作业，那么你甚至可以使用哑数据存储，因为大多数计算都是在事先发生的。

我认为es-hadoop库使用Elasticsearch和Apache Spark来使用Spark中的Mlib来处理我的数据 - 这是一个合理的方向吗？

看起来您已经决定批量处理，在这种情况下，您可以使用标准MR或火花批次以及MLib。如果你需要实时，你需要像卡夫卡这样的东西并使用火花流。如果您对数据丢失没有问题，那么当您决定窗口/滑动间隔等时，您可能会积极地保留，甚至在Spark中。如果您对结果不准确，可以使用概率数据结构（如bloom） filter，hyperloglog - druid支持这个）来表示结果。

我是否可以仅使用Elasticsearch将所有数据存储在其中，只使用Spark和Mlib提供深入分析，或者我应该考虑实施所谓的＆＃34; Lambda Architecture＆＃34;将Elasticsearch视为速度层？

我不确定您是否可以将数据从ES传输到Spark作业。 lambda架构过度炒作，只有当你确定你的实时层不准确并且你无法处理数据丢失/不准确时才会有所帮助。否则，一个简单的火花流工作从Kafka读取数据并泵送到ES应该绰绰有余。在决定像Lambda这样精心设计的架构之前，请考虑测量数据丢失，因为运营成本（如重复代码，更多维护基础设施等）可能很高。

如果数据负载小10倍（每年大约1.5太字节）怎么办？ - 你的答案是否相同？

我仍然更喜欢相同的架构 - Kafka + Spark流媒体（MLib）+ ES /德鲁伊 - 这更容易实现，更易于维护。

使用Elasticsearch对事件日志进行实时分析

1 个答案: