我们在多个数据中心的许多机器上分布了大量应用程序。
在一天中，我们会收到信号（内部或外部），这会在每个应用程序中产生一连串事件。
因此，每个信号都会产生大量的事件日志数据。日志本身并不是特定的结构，它们在应用程序之间也有很大不同。他们确实遵循基本惯例：
<timestamp> <calling function/method> <payload>
我们在日志中有ID号可以帮助将事件链接到一个信号 - 但是，这些并非万无一失，我们有时需要使用其他方法来尝试将事件拼凑在一起。
我一直在阅读Twitter的Storm系统，我很想尝试实时分析这些大量的日志数据，并把它拼凑起来。
我想做的事情如下：
日志数据存储在本地日志文件中（这不太可能改变），因此我们需要一种方法将数据插入到Storm本身。日志文件也可能被压缩。我对使用Flume或Logstash感兴趣 - 人们对这些有什么看法？还是有其他方法可以与Storm一起使用吗？
我还需要一种方法来存储实时报告和图形的数据，以及事件数据本身。
这是我发现有点棘手的第二部分 - 哪种存储后端适合存储事件，以及它们之间的链接？某种图形数据库是否合适，其中一种新的无模式NoSQL，或者更传统的东西？
最后，Storm适合这个角色，还是其他更合适的东西？
如果我选择使用Storm，我可以用什么方法来解决这个问题？我希望其他人有类似问题集的经验。
干杯， 维克多
答案 0 :(得分：3)
根据数据中的趋势制作报告和流式图表 实时
这听起来非常合适。
查询信号，然后调出与之相关的整个事件链 所有应用程序中的信号，包括步骤之间的延迟 链。 （这很重要）。
如果您的查询仅限于最近的数据（=不是很多数据）＆amp;你可以允许数据丢失，我可以想象只使用Storm这样做。如果没有，我可能会将Storm与数据库结合使用，并主要使用Storm进行预处理＆amp;将数据存储到数据库中。在这种情况下，使用数据库可能更好地处理查询。
查看相关事件，并深入了解应用程序的其他内容 在某个事件发生的时候做。
如果您知道要执行的查询，并且您不需要访问大量查询数据，那么Storm就很棒。例如，提供显示相关事件的Feed非常合适。使用数据库提供执行即席查询（向下钻取）的方法可能会更容易。此外，如果您想允许用户查询大量数据（例如，一周的数据而不是一小时的数据等），那么您可能需要一个数据库。
至于输入数据，我会使用日志集中化产品。您可以创建一个与产品将提供的任何接口交互的Spout。或者，如果您正在使用允许通过套接字，通过JMS等发送日志的日志框架（如log4j），您可以从该套接字/ JMS队列中读取一个spout等。
至于数据库选择，它实际上取决于你想做什么。如果你不知道你将要记录什么样的活动并希望关联事件，我的赌注将放在图表数据库上，因为遍历事件很容易。
答案 1 :(得分：2)
这听起来很像我现在正在处理的情况，所以我会提出一些可能做的事情。
要获取数据，您可以查看Apache Kafka。 此消息传递系统可以使您的日志脱离应用程序并进入中间存储。从那里开始，不同的系统可以作为消费者附加，其中Storm之一使用特殊的Storm-Kafka喷口整合得很好。
在我们的案例中，我们有一些实时数据直接从Kafka经纪人消费到监控/仪表板以及需要通过Storm处理的其他数据流。后者存储在分布式数据库（MongoDB，Cassandra或Couchbase）中，具体取决于数据的性质，然后将其加载到仪表板和其他系统中。
对于批处理作业，您还可以将数据从Kafka加载到Hadoop中，所有这些都可以彼此独立完成，将相同的数据从Kafka提取到多个系统。
Kafka还通过镜像制作者支持多个数据中心。