所以基本上我有不同平台上的应用程序，可以向我的服务器发送日志数据。它是一个节点服务器，基本上接受日志条目的有效负载，并将它们保存到各自的日志文件中（作为写流缓冲区，因此速度很快），并且每当一个日志文件填满时就创建一个新的日志文件。
我存储日志的方式本质上是每个“端点”一个文件，每个日志文件由与度量相对应的空间分隔值组成。例如，播放器事件日志结构可能如下所示： timestamp user mediatype event 然后日志条目将如下所示 1433421453 bob iPhone play 根据阅读的文档，我认为这种格式适合hadoop之类的东西。我认为这样做的方法是，将这些日志存储在服务器上，然后运行cron作业，定期将这些文件移动到s3。从s3开始，我可以使用这些日志作为使用amazon的emr的hadoop集群的源。从那里，我可以用Hive来查询它。
这种方法有意义吗？我的逻辑有缺陷吗？我应该如何为amazon的emr保存/移动这些文件？我需要把所有的日志文件连接成一个大文件吗？
另外，如果我将来在日志中添加一个度量值呢？那会把我以前的数据都弄乱吗？
我意识到我有很多问题，那是因为我对大数据不熟悉，需要一个解决方案。非常感谢您抽出时间，我很感激。
1条答案
按热度按时间q5iwbnjs1#
如果您有大量定期更改的日志转储，那么您制定的方法是有意义的。使用emrfs，您可以直接处理来自s3的日志（您可能知道）。
当您向配置单元“附加”新的日志事件时，将生成部件文件。因此，您不必在将它们加载到配置单元之前连接它们。
（在第0天，日志以某种分隔的形式加载到配置单元中，由于各种转换而生成部件文件。在随后的循环中，新的事件/日志将出现在这些零件文件中。）
不断增加新领域是一项挑战。您可以创建新的数据结构/集和配置单元表并将它们连接起来。但是连接会很慢。因此，您可能需要在模式中定义填充符/占位符。
如果您要接收日志流（许多小日志文件/事件），并且需要运行接近实时的分析，那么可以看看kinesis。
（也可以试驾 Impala 。速度更快）
.. 我的2c。