我應該使用LSF還是實現我自己的作業調度程序？

我們在公司內部進行一些文件處理\計算簡單地說，我們有一份工作或一項任務涉及閱讀一個擁有超過十億條記錄的大文件，解析這些文件並進行一些清理並將清理後的數據寫入另一個文件。我們有數百個不斷被創建，提交，運行的工作。每項工作都會處理自己的文件，所以我們不必擔心併發問題。我應該使用LSF還是實現我自己的作業調度程序？

爲了實現這個目標，我們建立了自己的調度系統（一個組合或MainFrame和Java）。我們目前的吞吐量約爲每小時4000萬條記錄。爲了更好地實現這一目標（並提供更多的容錯能力），我們正在評估IBM的LSF，以幫助我們完成此計劃和創造工作。

你們有沒有感覺到使用LSF可能會導致這個問題的死亡？我可以考慮使用AKKA中的actor模型實現並在其周圍編寫我自己的Job Scheduler。

有什麼想法？

來源

2015-09-01 Karthik Balasubramanian

我不知道LSF是什麼，但對於您的問題描述，我寧願開始查看Hadoop堆棧（如果您有延遲要求，也許是Spark）。如果你有近乎實時的處理需求，你不能滿足批量Map/Reduce作業，我只會開始考慮Akka。 – Tim

我使用的文件範圍從數百MB到100個演出。 Hadoop的文件大小是否足夠好？我一直在閱讀並聽說文件大小必須在TB級以上才能看到任何實際的性能增益。另外，我的處理邏輯非常簡單，它將通過文件中的每一行/記錄並應用一些轉換並將其寫回新文件（沒有「減少」）。 –

我的評論太長了，所以我把它作爲答案，雖然它不是真的回答你的問題（還沒有反正）。

在引入新技術和推出自己的解決方案之間進行權衡。您是否需要在不同文件或一個文件中的記錄之間進行交叉引用？如果不是，並且您逐行處理文件，則有一百萬種腳本編寫方法，而無需使用任何框架。引入Akka（或者任何其他框架）可能會拖累一些基礎設施需求，這些需求可能比編寫實際服務更昂貴。 TLDR：是的，您可以使用Akka來做到這一點（以及其他許多方法），但是有太多的未知因素可以決定它是否是'最佳'解決方案（引號是因爲沒有'最好'的定義，在此刻）。

來源

2015-09-03 00:19:42 Tim

我同意你的觀點。在我的情況下，不僅需要緊縮文件，還需要監視進度等，這正是Hadoop帶來的一些技術。我猜AKKA和Hadoop不是競爭技術，只是不同的範例，不知道我在寫什麼時想的是什麼 –

嗯，我沒有太多的運氣與MapReduce監測工具（我一次使用豬），所以不知道使用Hadoop可以獲得多少進展和監控。如果你使用自己的東西，插入類似Graphite或statsd的東西相對容易，以獲得自定義指標和良好的用戶界面。 – Tim

我應該使用LSF還是實現我自己的作業調度程序？

回答

相關問題