apache spark

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

似乎每個人都只是在談?wù)撟顭衢T的新技術(shù)，而忽略采用它的實際含義。 但這是自然的，對吧？ 新功能和承諾勝過其他所有事物，而艱難的挑戰(zhàn)和決??定被拋在一邊。

這次不行。 軟件架構(gòu)很難，權(quán)衡是游戲的名稱。

在本文中，我們想退后一步，看看執(zhí)行從頭開始轉(zhuǎn)向Spark的決定的真正含義。 非常感謝Kenshoo的開發(fā)人員和系統(tǒng)架構(gòu)師Tzach Zohar ，他在本博文中與我們分享了他的經(jīng)驗。

為什么還要煩惱呢？

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

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

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

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

1. HDFS與Cassandra與S3

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

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

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

2.綠地與重構(gòu)

好吧，所以您現(xiàn)在決定遷移到Spark，您應(yīng)該從全新的項目開始還是基于當(dāng)前應(yīng)用程序進行重構(gòu)？ 每個人都有自己的警告，Kenshoo決定放棄綠地之路，以重構(gòu)其當(dāng)前系統(tǒng)。 該決定縮小為四個因素：

避免移動目標(biāo)場景 –從頭開始構(gòu)建新系統(tǒng)需要花費時間和數(shù)月的開發(fā)時間。 在此期間，舊系統(tǒng)也在發(fā)生變化，因此您的規(guī)范實際上是隨時間變化的移動目標(biāo)。

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

代碼是唯一的規(guī)范 –文檔很有可能……不存在。 如果確實存在，則很可能不能反映系統(tǒng)的當(dāng)前狀態(tài)。 這是您可能與代碼中的那些黑角有關(guān)的示例：

“不應(yīng)該”發(fā)生的東西，但是會發(fā)生嗎？

測試重用 –您當(dāng)前的測試與較舊的實現(xiàn)結(jié)合在一起，并采用不同的設(shè)置。 這里的另一個任務(wù)是重寫它們以匹配新的實現(xiàn)。

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

3.重構(gòu)挑戰(zhàn)

選擇重構(gòu)路徑還面臨挑戰(zhàn)，未經(jīng)測試的遺留代碼，與其他系統(tǒng)組件的緊密耦合以及新體系結(jié)構(gòu)的范式轉(zhuǎn)換。 從相似的Hadoop架構(gòu)進行切換比在單節(jié)點應(yīng)用程序上進入分布式系統(tǒng)路徑更容易。 有很多新的知識要學(xué)習(xí)，要有調(diào)整的過程，還有很多摩擦。 不論是否新建項目，這都是艱巨的任務(wù)，但是如果您確定這是值得的–隧道盡頭便是一盞燈。

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

底線：在移動之前預(yù)先了解您的弱點，并確保針對新實現(xiàn)中的關(guān)鍵路徑具有解決方案。

4.解決方法

4.1。 核心業(yè)務(wù)規(guī)則至上

重構(gòu)的主要好處之一當(dāng)然是代碼重用。 構(gòu)建新系統(tǒng)的第一步是首先遵循核心業(yè)務(wù)規(guī)則，并從中創(chuàng)建一個獨立的jar。 這些方法被重構(gòu)為Java靜態(tài)方法，以避免Spark中的序列化問題。

4.2。 Dropwizard指標(biāo)和復(fù)雜的遺留代碼

繼續(xù)前進，還記得“不應(yīng)該發(fā)生”的例子嗎？ Kenshoo使用Dropwizard Metrics計數(shù)器進行裝配：

你知道什么。 確實發(fā)生了很多：

發(fā)生…..“這不應(yīng)該發(fā)生”

底線：事實證明，使用度量標(biāo)準(zhǔn)來度量遺留代碼中的未知數(shù)是一個功能強大的工具，它可以將“隱藏”功能轉(zhuǎn)變?yōu)槊鞔_的，經(jīng)過良好記錄和經(jīng)過良好測試的功能。

4.3。 本地模式測試

為了應(yīng)對測試挑戰(zhàn)，Kenshoo充分利用了Spark的本地模式并從中汲取了靈感–在新的聚合組件中創(chuàng)建了一個類似Spark的嵌入式實例。 而且，他們?nèi)缓蟛捎昧诉@個新組件，并將其嵌入到舊系統(tǒng)中，重用了較早的測試，并確保新系統(tǒng)滿足所有要求：

4.4。 石墨“ diffRecorder”

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

生成的數(shù)據(jù)有助于了解需要進行哪些調(diào)整以匹配舊系統(tǒng)（或發(fā)現(xiàn)系統(tǒng)中的隱藏故障）。 順便說一句，要了解有關(guān)Graphite的更多信息，可以查看有關(guān)為系統(tǒng)選擇最佳Graphite體系結(jié)構(gòu)的文章 。

Kenshoo的Graphite儀表板

5.火花監(jiān)控

Spark與Graphite緊密集成，您可以在其中繪制任何您想要的圖形。 除此之外，這里的第二個工具是Spark Web UI，用于查看您的作業(yè)和性能指標(biāo)。 任何嚴(yán)肅的Spark部署都需要在性能和監(jiān)視方面投入大量精力。 這可能會成為一個非常棘手的問題，您需要熟悉內(nèi)部結(jié)構(gòu)才能調(diào)整系統(tǒng)。 為Spark編寫代碼很容易，但是性能又增加了另一層復(fù)雜性。 從這個意義上講，很容易在這里出錯并產(chǎn)生錯誤的代碼。

查看這篇文章，我們探討了Taboola的Spark監(jiān)視架構(gòu) ，以及他們?yōu)槭裁匆^續(xù)將Takipi添加到其監(jiān)視堆棧中。

推薦的Spark入門資源

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

結(jié)論

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

我們要再次感謝Kenshoo的Tzach Zohar與我們分享他的經(jīng)驗！

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

apache spark

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。