我計劃旋轉我的開發集羣以進行基礎架構監視應用程序的趨勢分析，我打算使用Spark構建分析故障趨勢的卡路德，並分析故障趨勢並分析數據。 考慮從大約25000臺機器/服務器收集性能矩陣（可能在不同服務器上設置相同的應用程序）。我期望每臺機器的性能矩陣大小爲2MB/sec，我計劃推入帶有時間戳的Cassandra表，服務器作爲主鍵和應用程序，以及一些重要矩陣作爲集羣密鑰。我將在此存儲的信息之上運行Spark作業，以進行性能矩陣故障趨勢分析。具有6到7個節點的分佈式Spark和HDFS集羣硬件配置
考慮到上述情況，我需要啓動羣集才能啓動多少個節點（機器）以及CPU和內存的配置。
Cassandra需要一個精心策劃的數據模型來讓事情運行良好。在您擁有大量數據集之前，在這個階段花費大量時間進行規劃，並發現您可能會更好地重新安排數據模型！
「一般」的經驗法則是讓你的模型成形到查詢中，同時注意避免像真正的大行，大刪除，批次和諸如此類可能會有很大性能損失的事情。
該文檔給你一個良好的開端planning和testing你可能會發現有用的。我也建議使用Cassandra stress工具。您可以使用它將性能測試推送到您的Cassandra羣集中，以檢查延遲和任何性能問題。你也可以使用你自己的模式，我個人認爲它是超級有用的！
如果您使用的是像AWS這樣的基於雲的硬件，那麼可以相對容易地向上/向下擴展並查看哪些最適合您。你不需要在Cassandra上拋出大硬件，它比水平方向更容易水平縮放。
我假設您將數據拉回到分析端的獨立Spark集羣中，因此這些節點將運行普通Cassandra（較少硬件規格）。但是，如果您使用的是Datastax Enterprise版本（您可以在spark模式下運行節點），那麼您將需要更多更強大的硬件以及火花驅動程序，執行程序等所需的額外負載。另一個好的文檔鏈接是DSE hardware recommendations