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

似乎每個(gè)人都只是在談?wù)撟顭衢T的新技術(shù)，而忽略采用它的真正含義。 但這是自然的，對(duì)吧？ 新功能和承諾勝過(guò)其他一切，而艱巨的挑戰(zhàn)和決??定被拋在一邊。

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

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

為什么還要煩惱呢？

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

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

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

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

1. HDFS與Cassandra與S3

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

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

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

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

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

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

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

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

“不應(yīng)該”發(fā)生的事情，但是它發(fā)生了嗎？

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

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

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

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

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

底線：在移動(dòng)之前預(yù)先了解您的薄弱環(huán)節(jié)，并確保針對(duì)新實(shí)施中的關(guān)鍵路徑具有解決方案。

4.解決方法

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

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

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

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

而且你知道什么。 它確實(shí)發(fā)生了很多：

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

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

4.3。 本地模式測(cè)試

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

4.4。 石墨“ diffRecorder”

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

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

Kenshoo的Graphite儀表板

5.火花監(jiān)控

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

查看這篇文章，我們探討了Taboola的Spark監(jiān)視架構(gòu) ，以及為什么他們要繼續(xù)將Takipi添加到其監(jiān)視堆棧中。

推薦的Spark入門資源

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

結(jié)論

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

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

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

總結(jié)

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

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