遷移到Apache Spark之前需要了解的5件事

似乎每個人都只是在談論最熱門的新技術，而忽略采用它的真正含義。 但這是自然的，對吧？ 新功能和承諾勝過其他一切，而艱巨的挑戰和決??定被拋在一邊。

這次不行。 軟件架構很難，權衡取勝是游戲的名稱。

在本文中，我們想退后一步，看看執行從頭開始轉向Spark的決定的真正含義。 非常感謝Kenshoo的開發人員和系統架構師Tzach Zohar ，他在本博文中與我們分享了他的經驗。

為什么還要煩惱呢？

如果您從一個可以從分布式數據分析中受益的全新項目開始，無論是批處理分析還是精簡分析，Spark都已將其優勢確立為MapReduce的最佳實現。 主要是因為它使用內存處理的方式。 否則，如果您在一臺服務器上獲得了所需的吞吐量，并且使用的數據不會超出該范圍，那么最好避免使用分布式的復雜性。 請注意，我們甚至一次都沒有說過大數據。 哦 此外，Spark具有一個很棒且易于使用的機器學習庫。
Spark與Hadoop

盡管您的起點很可能是您已經擁有的現有解決方案，但這會使事情變得多余。 我們將把重點放在那上面。 在難以應對規模的數據庫之上從Hadoop或本地解決方案遷移。 性能的提高最終可以減少硬件成本，提高生產力，或者實際上只是擺脫嘗試做的事情的唯一方法。

最大的好處來自批處理分析的角度，因此，如果這是您的用例–升級集群將變得更加緊迫。 就Kenshoo而言，單服務器MySQL解決方案已綽綽有余。 但是隨著公司的發展和幾年的過去，這已經不夠了–每天要處理成千上萬條記錄，數百張表，較大記錄上的十億條記錄以及TB級的數據。 不再是堪薩斯州了 。 有一點是，您無法進行所有優化，甚至TokuDB之類的高性能存儲引擎也無法實現。 您最終要做的是在類固醇上安裝了一個突變MySQL。

在海岸的另一端，有Spark公司，它解決了各種各樣的問題，這些新問題卻是長期存在的原則，并得到社區的Swift采用和許多積極的信號。

1. HDFS與Cassandra與S3

您為Apache Spark選擇的存儲服務器應該反映出您對系統最看重的東西。 這里的3個常見選項是Hadoop的HDFS，Apache Cassandra和Amazon的S3。 當數據局部性不是關鍵時，S3適合非常特定的用例。 例如，每天運行一次的作業，或者實際上不需要任何數據和處理能力來共享機器的任何事情。 沒有緊迫的工作。 至于HDFS與Cassandra的問題，運行HDFS的硬件成本較低，因為它旨在解決更簡單的用例。 多低 高達10倍。 主要區別在于HDFS解決了分布式文件系統運行的問題，而Cassandra專門設計為高吞吐量鍵值存儲。

盡管成本較高，但Cassandra在交互式流數據分析方面處于優勢地位–與運行批處理作業相反。 您可以說HDFS喜歡大文件，而Cassandra不必加載所有數據，僅使用所需的數據即可訪問

• S3 –非緊急批處理作業。
• Cassandra –非常適合流數據分析，并且對批處理作業有過高的要求。
• HDFS –非常適合批處理作業，而不會影響數據局部性。

2.綠地與重構

好吧，所以您現在決定遷移到Spark，您應該從全新的項目開始還是基于當前應用程序進行重構？ 每個人都有自己的警告，Kenshoo決定放棄綠地之路，以重構其當前系統。 該決定縮小為4個因素：

避免移動目標場景 –從頭開始構建新系統需要花費時間和數月的開發時間。 在此期間，舊系統也在發生變化，因此您的規范實際上是隨時間變化的移動目標。

零差異容限 –新系統應達到與舊系統相同的結果，對嗎？ 聽起來很簡單的過程是一個變相的問題。 經過多年的發展，針對特定分析過程的各種怪癖和定制已被硬編碼到較舊的應用程序中。 例如，某些假設，四舍五入的結果以及來自各個客戶的請求–已經創建了一個復雜的分析過程，很難從頭開始重新創建。

代碼是唯一的規范 –文檔很有可能……不存在。 如果確實存在，則很可能不能反映系統的當前狀態。 這是您可能與代碼中的那些黑角有關的示例：

“不應該”發生的事情，但是它發生了嗎？

測試重用 –您當前的測試與較早的實現結合在一起，并采用了不同的設置。 這里的另一個任務是重寫它們以匹配新的實現。

底線：在這種情況下，重構而不是完全重新啟動是最有意義的。

3.重構挑戰

選擇重構路徑還面臨挑戰，未經測試的舊代碼，與其他系統組件的緊密耦合以及新體系結構的范式轉換。 從類似的Hadoop架構進行切換比在單節點應用程序上進入分布式系統路徑更容易。 有許多新的知識要學習，要有調整的過程，還有很多摩擦。 不論是否新建，這都是艱巨的任務，但是如果您確定這是值得的–隧道盡頭便是一盞燈。

在Kenshoo的案例中，他們的任務是從一個擁有8年歷史的龐大系統中釋放瓶頸聚合器組件。 聚合器偶爾對數據執行批處理，并通過不同的鍵將其分組。

底線：在移動之前預先了解您的薄弱環節，并確保針對新實施中的關鍵路徑具有解決方案。

4.解決方法

4.1。 核心業務規則至上

重構的主要好處之一當然是代碼重用。 構建新系統的第一步是首先遵循核心業務規則，并從中創建一個獨立的jar。 這些方法被重構為Java靜態方法，以避免Spark中的序列化問題。

4.2。 Dropwizard指標和復雜的遺留代碼

繼續前進，還記得“不應該發生”的例子嗎？ Kenshoo使用Dropwizard Metrics計數器進行裝配：

而且你知道什么。 它確實發生了很多：

發生…..“這不應該發生”

底線：事實證明，使用度量標準來度量遺留代碼中的未知數是一個功能強大的工具，它可以將“隱藏”功能轉變為明確的，經過良好記錄和經過良好測試的功能。

4.3。 本地模式測試

為了應對測試挑戰，Kenshoo充分利用了Spark的本地模式并從中汲取了靈感–在新的聚合組件內部創建了一個類似Spark的嵌入式實例。 此外，他們然后采用了這個新組件，并將其嵌入到舊系統中，重用了較早的測試，并確保新系統滿足所有要求：

4.4。 石墨“ diffRecorder”

除了本地模式測試之外，最后的領域是測試生產中的實際數據，并查看Spark結果是否與舊系統的結果匹配。 為此，實現了與Graphite可視化掛鉤的“ diffRecorder”。 差異記錄器將這兩個版本有所不同的每個實際輸入表示為Graphite Metric（石墨度量），并指出與新實現不一致的確切輸入。

生成的數據有助于了解需要進行哪些調整以匹配舊系統（或發現系統中的隱藏故障）。 順便說一句，要了解有關Graphite的更多信息，可以查看有關為系統選擇最佳Graphite體系結構的文章 。

Kenshoo的Graphite儀表板

5.火花監控

Spark與Graphite進行了很好的集成，您可以在其中繪制任何您想要的圖形。 除此之外，這里的第二個工具是Spark Web UI，用于查看您的作業和性能指標。 任何嚴肅的Spark部署都需要在性能和監視方面投入大量精力。 這可能會成為一個非常棘手的問題，您需要熟悉內部結構才能調整系統。 為Spark編寫代碼很容易，但是性能又增加了另一層復雜性。 從這個意義上講，很容易在這里出錯并產生錯誤的代碼。

查看這篇文章，我們探討了Taboola的Spark監視架構 ，以及為什么他們要繼續將Takipi添加到其監視堆棧中。

推薦的Spark入門資源

基本文檔簡短，直接，可以完成工作。 有關Spark性能調整的更高級的主題主要可以在以前的Spark峰會的錄制演講中找到。

結論

存儲，重構技術，監視，測試重用和一致的結果–我們希望您發現所提供的解決方案有用，并且知道如何在需要時應用它們。 向新技術的過渡非常困難。 除了學習曲線外，它們還使您更容易出錯（也使您更有可能在半夜接聽電話以解決某些關鍵的生產問題）。 針對這種情況，我們啟動了Takipi對Spark的錯誤分析 。

我們要再次感謝Kenshoo的Tzach Zohar與我們分享他的經驗！

翻譯自: https://www.javacodegeeks.com/2015/08/apache-spark-5-pitfalls-you-must-solve-before-changing-your-architecture.html

總結

以上是生活随笔為你收集整理的Apache Spark：更改架构之前必须解决的5个陷阱的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。