處理日誌文件：Apache Storm或Spark

我有處理日誌文件數據的要求。這是相對微不足道的。我有4臺服務器，每臺服務器上運行2個Web應用程序，共計8個日誌文件。這些會定期輪換。我寫在下面的格式數據轉換成這些日誌文件處理日誌文件：Apache Storm或Spark

來源時間戳：9340398; 39048039; 930483; 3940830

當數字是在數據存儲的標識符。我想設置一個讀取這些日誌的進程，並且對於每個id，它將根據其id已經被記錄的次數來更新計數。它可以是實時的或批量的。我對數據存儲的界面語言是Java。該流程在生產中運行，因此需要具有強大的功能，但也需要具有相對簡單的體系結構以便維護。我們也運行zookeeper。

我最初的想法是每當在每個服務器上運行Apache Spark的日誌文件旋轉時都要這樣做。然而，我後來看到了像Apache Flume，Kafka和Storm這樣的日誌加速器，但是這看起來好像過火了。

鑑於衆多的選擇，任何人都有什麼好的建議，根據經驗使用哪些工具來處理這個問題？

也許像[logstash]（https://www.elastic.co/products/logstash）這樣的解決方案可以被使用嗎？一般來說，這些問題都是關於SO的話題。 –

嗨，我看了Logstash，它似乎更傾向於過濾類型的操作。我同意這個問題不適合SO章程。 –

8個日誌文件似乎不保證任何「大數據」技術。如果你確實想要玩這些技術，我建議你從Spark和/或Flink開始 - 兩者都有相對相似的編程模型，兩者都可以處理「業務實時」（Flink更擅長於流式傳輸，但兩者似乎都適用於您的情況）。風暴是相對剛性的（難以改變拓撲結構）並且有更復雜的編程模型

2016-05-15 07:18:39

我傾向於認同它不是一個「大數據」問題。我想到，即使對於小數據問題，也應該有一些合理簡單的工具來處理日誌聚合和處理問題。我可能甚至不需要日誌聚合，因爲數據源可以處理來自潛在應用程序的更新。因此，要麼尾日誌文件或做週期批處理可能是解決方案。 –

你考慮過ELK還是Fluentd？如果你想要純JAVA，Flume可能是另一個，但它沒有可靠的尾巴。本機尾部可能在1.7版本中可用，但不知道何時。我會建議非常簡單的logstash或filebeats配置並轉發到Elastic，您可以在術語上進行簡單聚合。 – YaRiK

我看着ELK，但可能會再看看你說的話。 –

回答