星火流媒體應用stucks而寫，從卡桑德拉閱讀/同時

我在做一些基準測試，它由以下數據流：星火流媒體應用stucks而寫，從卡桑德拉閱讀/同時

卡夫卡 - >星火流 - >卡桑德拉 - > Prestodb

基礎設施：我的火花流應用程序運行在4個執行器上（每個內核2個內核4g）。每個執行器都運行在安裝了Cassandra的datanode上。 4 PrestoDB工作人員也位於數據節點中。我的集羣有5個節點，每個節點都有一個Intel Core i5,32GB DDR3 RAM，500GB SSD和1Gigabit網絡。

Spark流應用程序：我的Spark流式批處理間隔爲10s，我的kafka製作者每3秒產生5000個事件。我的流媒體應用程序寫入2 Cassandra表。

上下文中的一切工作正常：一切正常運行，流應用程序能夠處理事件並將它們存儲在Cassandra中。批處理間隔是足夠的，攝取率，調度和處理延遲在很長一段時間內幾乎保持不變。

上下文中的事情變得混亂和混亂：在我的基準測試中，每小時我對Cassandra表執行6次查詢。對於運行這些查詢的時間，Spark寫入Cassandra時，Spark流應用程序不再能夠支持寫入吞吐量並掛起。

我到目前爲止所做的工作：我在其他web帖子（包括stackoverflow）中搜索了這個現象，但是我找不到類似的現象。我見過的最好的辦法是增加可用於Cassandra的內存量。其他方面與連接器的讀取大小有關，但我不知道這是否是一個問題，因爲它只發生在同時讀取和寫入時。

問題：Cassandra不應該在讀取時鎖定寫入，對嗎？你們認爲我需要解決的問題的來源（或來源）是什麼？我應該考慮哪些配置？

我附加了一個打印a print，說明如前所述，當我使用6個查詢運行基準測試時，寫入Cassandra表之一的階段卡住的作業停滯不前。如果您需要更多信息來追蹤問題，請隨時詢問。我很感激！

非常感謝您對我們的支持，

希望我把這個問題以適當的方式，

最好的問候，

卡洛斯

來源

2017-08-02 Carlos Costa

什麼堆大小分配給火花執行人和卡桑德拉

最好的問候，

卡洛斯·科斯塔？在查詢過程中，您看到GC的堆或使用堆的利用率有所增加嗎？還要檢查對Cassandra開放的連接數（用於攝取以及查詢）？ –

每個Spark執行程序都有4GB的內存。我認爲他們有足夠的內存來處理這種工作負載，至少在我寫這篇文章時似乎綽綽有餘。沒有錯誤，沒有卡住的工作，沒有什麼。問題是當prestoDB查詢開始在Cassandra表上運行時。當prestoDB工作負載完成後，儘管有幾個「暫停」作業，Spark仍能夠恢復所有批處理，並且再次正常開始寫入Cassandra ... –

... Cassandra堆大小爲4GB，HEAP_NEWSIZE爲400M。你認爲我應該根據自己的工作負載將它碰撞嗎？在基準測試期間，我沒有檢查GC，堆的使用和打開連接，因爲它是自動化的，每個小時在夜間......但感謝提示，我將嘗試重現場景並立即查看這些方面。至少在尋找什麼方面有一個明確的道路是很好的。謝謝你的幫助！ –

這個問題看起來是在卡桑德拉 - 普雷斯托側並沒有因爲對星火原因/假設

火花執行人由RM（紗線/ mesos等）來處理你的查詢不能直接影響到這一點。在關閉查詢期間，如上所述，攝取順利進行。
只有當您直接與其他組件共享資源時，纔會出現Spark端資源匱乏。一般來說，Cassandra，Presto工作者/線程不是使用RM進行分配的，因此他們從節點角度而不是RM角度共享資源。

我懷疑原因攤位可能是，

在查詢，Cassandra是讀取大量數據，因此JVM內存使用率增加和大量的GC的正在發生。 GC暫停可能是暫停/攤位的原因。
對Cassandra的連接數（讀/寫）完全由查詢使用，因此Spark作業無法插入數據並在隊列中等待以獲取連接。
節點上的整體資源利用率增加，並且可能有一個組件已達到其限制（CPU，內存，磁盤等）。在這種情況下，IMO CPU，磁盤值得檢查。

驗證這些原因要麼通過監控堆UTIL和GC日誌，使用JMX對卡桑德拉，然後撞了這些值取決於可用的資源來解決這個問題，並嘗試調整普雷斯托查詢打開的連接所以影響最小。

一旦確認Cassandra問題，Presto調整可以作爲後面的部分。更多普雷斯托調整可在

https://prestodb.io/docs/current/admin/tuning.html 或者Teradata的解決方案是使用，那麼， https://teradata.github.io/presto/docs/current/admin/tuning.html

來源

2017-08-03 06:43:00

非常感謝您的詳細回覆@Nachiket凱特！我首先看CPU的使用情況（使用頂級），我認爲這可能是問題的最大來源。查看其中一個節點，cpu使用情況如下：cassandra進程（〜280％）; presto（〜90％）;火花（3.3％）。由於我使用英特爾酷睿i5四核CPU，我認爲在這些節點上Spark流作業沒有更多空間，因爲Cassandra和Presto會導致CPU匱乏。我想我會試圖找出如何限制Cassandra cpu的使用。再次感謝您的時間和關注。這有很大的幫助。 –

很高興我可以幫助:)不知道你是否使用Yarn，但如果是的話，那麼你可以使用隊列限制攝入資源，Cassandra和Presto可以在Linux中使用cgroups進行限制。 –

我不知道這有什麼關係與卡桑德拉。

什麼是Spark scheduling策略配置？默認情況下，它是FIFO。暗示，查詢作業可能會消耗所有內核，直到完成。而且，將會使流媒體工作捱餓。如果FIFO，更改爲FAIR並再試一次。

來源

2017-08-02 16:26:43 jagsr

謝謝你的提示，Spark的調度策略留給它的默認值（FIFO）。我只使用Spark進行流媒體作業。查詢我正在使用PrestoDB。因此，除非PrestoDB讓Spark流媒體作業陷入癱瘓，否則我更傾向於使用Cassandra內存或寫入/讀取性能/併發，正如@Nachiket Kate指出的那樣。監視這些場景相對困難，我會嘗試再次模擬上下文，並查看是否可以進行更多觀察。謝謝你的協助。 –

只是爲了完成這個問題，以下是由堆棧溢出成員，很友好地給我的提醒回覆：

1）我將Cassandra的jvm.options中的Java垃圾收集器更改爲G1，不需要像默認CMS那樣進行調整。 http://docs.datastax.com/en/cassandra/3.0/cassandra/operations/opsTuneJVM.html#opsTuneJVM__setting-g1-gc 我改變了它，因爲GC暫停在相似的情況下經常被指出爲一個問題。說實話，我對GC監控並不太熟悉，但Datastax Cassandra文檔告訴我要使用G1。我改變了它，並且我發現我的工作負載和基礎架構在性能和穩定性方面有所提升。

2）我意識到我對羣集的性能感到樂觀，並且在Cassandra上運行繁重的prestoDB查詢時，每10秒處理和寫入Cassandra 20 000個事件幾乎是不可能的。 PrestoDB和Cassandra正在使用我節點中幾乎所有的CPU。我在每個節點只有4個核心。 Cassandra的CPU使用率接近280％，Presto接近90％，因此Spark流媒體執行者在那裏捱餓。此外，Cassandra沒有更多的空間來適應這種寫入速度，火花傳輸工作開始掛起，並在很長一段時間內累積數批。因此，我將批次間隔設置得更高。我知道你失去了一些數據的時效性，但是如果基礎設施無法處理，我沒有資源去擴展：（

另一種可能性是通過使用linux cgroups，紗線cpu隔離和隊列來優化CPU限制，例如，看看它是否有幫助，對於我的集羣，如前所述，我認爲這個問題實際上是試圖「用小型遙控車來移動montain」:)每個節點都負責火花流工作+ cassandra + presto ，只有4個內核可用。 3）最後，我還調整了火花Cassandra連接器，這對我的工作負載起作用，但我認爲這取決於您的數據和其他變量。我改變了： *併發寫數從5到2; *從「分區」到「replica_set」將grouping.key分組，因爲我的分區鍵具有很高的基數（它們在RDD中幾乎是唯一的），因此根據分區鍵對批次進行分組毫無用處。但這當然取決於你的分區密鑰。 * batch.size.rows爲50.但這可能取決於您爲每個流式微批處理的數據量。 https://github.com/datastax/spark-cassandra-connector/blob/master/doc/reference.md

我希望這篇文章可以幫助其他人面臨流大數據項目有困難的，因爲事情可能會變得非常非常困難的，有時:)如果我的一些決定也錯誤或誤導性的，請讓我知道。每一個幫助表示讚賞。

謝謝大家，

來源

2017-08-03 15:45:05

星火流媒體應用stucks而寫，從卡桑德拉閱讀/同時

回答

相關問題