2016-05-15 184 views
0

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

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

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

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

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

+0

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

+0

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

回答

1

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

+0

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

+2

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

+0

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